7 стратегии за миграция на бизнеса към облака
Правилният преход дава преимущества, само че би трябвало да се регистрират рисковете и напъните за поддръжка
Мигрирането към облака е комплицирана задача, която изисква изчерпателен разбор на настоящите проблеми и съпоставянето им с нужните промени за реализиране на бизнес целите
(снимка: CC0 Public Domain)
Стратегиите за миграция в облака са набор от способи за подкрепяне на организациите да възнамеряват, внедрят и усъвършенстват своите клауд планове. Те дават пътна карта за установяване на най-хубавия метод за пренасяне на приложения и данни от локалната инфраструктура в облака.
В зората на облачните калкулации Gartner показа модел за миграция 5 Rs. По това време доста компании бяха изправени пред предизвикването да мигрират наследени приложения и данни към новата среда, а моделът 5 Rs даде потребна рамка за оценка на разнообразни тактики.
С развиването на облачните калкулации и възстановяване на метода на организациите към миграцията се появи нужда от по-цялостен метод. Amazon Web Services предложи своя лична версия. Тя разшири 5 Rs, като първо добави Retire и по-късно Retain. В последната версия 7 Rs на AWS компанията признава, че не всички приложения и данни могат и би трябвало да бъдат мигрирани в облака.
1. Rehost („ Повдигане и пренасяне “)
Стратегията за миграция Rehost включва потребление на облачна инфраструктура като услуга (IaaS) за преразпределение на натоварването. Този метод разрешава на предприятията да реалокират приложението в облака по този начин, както е, без да трансформират главната инфраструктура. Освен това всички данни и работни процеси на приложението се трансферират към облачни услуги. Тъй като структурите на работното натоварване остават непокътнати, тактиката Rehost е лесна за осъществяване и е подобаваща за компании без опит в тази област.
2. Relocate („ Повдигане и изместване на равнище хипервизор “)
Стратегията Relocate включва мигриране на работни натоварвания, без да се засягат интервенциите, пренаписване на изходния код на приложението или придобиване на нов хардуер. Предприятията мигрират от местна платформа като Kubernetes или VMware към облачна версия на същата платформа. Времето за престой и спиранията са сведени до най-малко, защото клиентите остават свързани по време на процеса на миграция. Стратегията не изисква обилни промени в конфигурацията и архитектурата на работните натоварвания, няма потребност от преквалификация на личния състав или вложение в осъвременено съоръжение, което понижава оперативните разноски.
3. Replatform („ Повдигане и преоформяне “)
Като част от тактиката Replatform едно дружество може да мигрира приложение към облака, като в същото време ползва избрани оптимизации на платформата, с цел да се възползва от облачните технологии. В същото време изходният код и главната архитектура на приложението остават непроменени, което разрешава на предприятието да поддържа старите приложения работещи и да подсигурява сходство и сигурност в облака. Тази тактика за миграция усилва гъвкавостта и разрешава автоматизация, както и избор кои съставни елементи да бъдат надстроите, което след това усилва гъвкавостта на приложението и максимизира възвръщаемостта на вложенията.
4. Refactor („ Ре-архитект “)
Често Refactor се счита за най-трудният вид за миграция. Рефакторингът включва преструктуриране на работните натоварвания, с цел да се поддържат опциите на облака “от нулата ”. Въпреки че тази тактика изисква големи старания и пари, тя се смята за най-обещаващият метод към миграцията. Рефакторингът разрешава на предприятията да разбият монолитно приложение на микроуслуги, което им обезпечава висока наличност и нараснали равнища на автоматизация, постоянно сложни за използване, когато се внедряват вътрешно.
5. Repurchase („ Извадете и пазарувайте “)
Стратегията Repurchase планува подмяна на вътрешно ръководените системи с услуги, ръководени от трети страни. Това оказва помощ на екипите да се отдалечат от наследените системи и да преминат към модел на абонамент SaaS (софтуер като услуга). Тъй като услугите се ръководят от трети страни, моделът Repurchase понижава оперативните старания за ръководство на инфраструктурата за вътрешните чиновници.
6. Retire („ Пенсионирайте “)
Стратегията Retire се употребява при изключване или понижаване на приложения, които към този момент не са нужни в производството. В такива случаи неефективните наследени платформи се извеждат от употреба. И това е първата стъпка към прехода към съвременни системи за внедряване в облак.
7. Retain („ Revisit “, „ Посетете още веднъж “)
Стратегията Retain е подобаваща за приложения, които не могат да бъдат изведени от употреба и би трябвало да продължат да работят в границите на съществуващата конструкция. Обикновено предприятията вземат решение да запазят работното натоварване, в случай че то зависи от друго приложение, което първо би трябвало да бъде мигрирано. Друг претекст за потребление на тази тактика е, когато преместването на приложението в облака няма непосредствена бизнес стойност.
Мигрирането към облака е комплицирана задача, която изисква изчерпателен разбор на настоящите проблеми и съпоставянето им с нужните промени за реализиране на бизнес задачите. Стратегиите за миграция нормално се избират въз основа на сложността на работното натоварване, разноските и разстройствата в системата. Макар че добре извършеният преход дава доста много преимущества, организациите би трябвало също да вземат поради рисковете и напъните, нужни за настоящата поддръжка.
Мигрирането към облака е комплицирана задача, която изисква изчерпателен разбор на настоящите проблеми и съпоставянето им с нужните промени за реализиране на бизнес целите
(снимка: CC0 Public Domain)
Стратегиите за миграция в облака са набор от способи за подкрепяне на организациите да възнамеряват, внедрят и усъвършенстват своите клауд планове. Те дават пътна карта за установяване на най-хубавия метод за пренасяне на приложения и данни от локалната инфраструктура в облака.
В зората на облачните калкулации Gartner показа модел за миграция 5 Rs. По това време доста компании бяха изправени пред предизвикването да мигрират наследени приложения и данни към новата среда, а моделът 5 Rs даде потребна рамка за оценка на разнообразни тактики.
С развиването на облачните калкулации и възстановяване на метода на организациите към миграцията се появи нужда от по-цялостен метод. Amazon Web Services предложи своя лична версия. Тя разшири 5 Rs, като първо добави Retire и по-късно Retain. В последната версия 7 Rs на AWS компанията признава, че не всички приложения и данни могат и би трябвало да бъдат мигрирани в облака.
1. Rehost („ Повдигане и пренасяне “)
Стратегията за миграция Rehost включва потребление на облачна инфраструктура като услуга (IaaS) за преразпределение на натоварването. Този метод разрешава на предприятията да реалокират приложението в облака по този начин, както е, без да трансформират главната инфраструктура. Освен това всички данни и работни процеси на приложението се трансферират към облачни услуги. Тъй като структурите на работното натоварване остават непокътнати, тактиката Rehost е лесна за осъществяване и е подобаваща за компании без опит в тази област.
2. Relocate („ Повдигане и изместване на равнище хипервизор “)
Стратегията Relocate включва мигриране на работни натоварвания, без да се засягат интервенциите, пренаписване на изходния код на приложението или придобиване на нов хардуер. Предприятията мигрират от местна платформа като Kubernetes или VMware към облачна версия на същата платформа. Времето за престой и спиранията са сведени до най-малко, защото клиентите остават свързани по време на процеса на миграция. Стратегията не изисква обилни промени в конфигурацията и архитектурата на работните натоварвания, няма потребност от преквалификация на личния състав или вложение в осъвременено съоръжение, което понижава оперативните разноски.
3. Replatform („ Повдигане и преоформяне “)
Като част от тактиката Replatform едно дружество може да мигрира приложение към облака, като в същото време ползва избрани оптимизации на платформата, с цел да се възползва от облачните технологии. В същото време изходният код и главната архитектура на приложението остават непроменени, което разрешава на предприятието да поддържа старите приложения работещи и да подсигурява сходство и сигурност в облака. Тази тактика за миграция усилва гъвкавостта и разрешава автоматизация, както и избор кои съставни елементи да бъдат надстроите, което след това усилва гъвкавостта на приложението и максимизира възвръщаемостта на вложенията.
4. Refactor („ Ре-архитект “)
Често Refactor се счита за най-трудният вид за миграция. Рефакторингът включва преструктуриране на работните натоварвания, с цел да се поддържат опциите на облака “от нулата ”. Въпреки че тази тактика изисква големи старания и пари, тя се смята за най-обещаващият метод към миграцията. Рефакторингът разрешава на предприятията да разбият монолитно приложение на микроуслуги, което им обезпечава висока наличност и нараснали равнища на автоматизация, постоянно сложни за използване, когато се внедряват вътрешно.
5. Repurchase („ Извадете и пазарувайте “)
Стратегията Repurchase планува подмяна на вътрешно ръководените системи с услуги, ръководени от трети страни. Това оказва помощ на екипите да се отдалечат от наследените системи и да преминат към модел на абонамент SaaS (софтуер като услуга). Тъй като услугите се ръководят от трети страни, моделът Repurchase понижава оперативните старания за ръководство на инфраструктурата за вътрешните чиновници.
6. Retire („ Пенсионирайте “)
Стратегията Retire се употребява при изключване или понижаване на приложения, които към този момент не са нужни в производството. В такива случаи неефективните наследени платформи се извеждат от употреба. И това е първата стъпка към прехода към съвременни системи за внедряване в облак.
7. Retain („ Revisit “, „ Посетете още веднъж “)
Стратегията Retain е подобаваща за приложения, които не могат да бъдат изведени от употреба и би трябвало да продължат да работят в границите на съществуващата конструкция. Обикновено предприятията вземат решение да запазят работното натоварване, в случай че то зависи от друго приложение, което първо би трябвало да бъде мигрирано. Друг претекст за потребление на тази тактика е, когато преместването на приложението в облака няма непосредствена бизнес стойност.
Мигрирането към облака е комплицирана задача, която изисква изчерпателен разбор на настоящите проблеми и съпоставянето им с нужните промени за реализиране на бизнес задачите. Стратегиите за миграция нормално се избират въз основа на сложността на работното натоварване, разноските и разстройствата в системата. Макар че добре извършеният преход дава доста много преимущества, организациите би трябвало също да вземат поради рисковете и напъните, нужни за настоящата поддръжка.
Източник: technews.bg
КОМЕНТАРИ