Този сайт използва бисквитки (cookies). Ако желаете можете да научите повече тук. Разбрах

Новини Технологии и концепции
бр. 5, 2017

Какво трябва да знаете за микроуслугите

от , 23 май 2017 0 88 прочитания,

Контейнерите и микроуслугите стават все по-популярни, предоставяйки допълнителни възможности. Но както всяка друга нова технология, те поставят пред разработчиците и нови задачи

Черните петъци и киберпонеделниците са радост за хората, които обичат да пазаруват, но и дни на огромно натоварване за работещите в търговския сектор. В компанията Hudson’s Bay Company (HBC), която притежава брандовете Lord & Taylor, Saks 5th Avenue и др., предпразничната лудница в навечерието на миналата Коледа се оказа най-подходящия момент за изпробване на нови функции в уеб сайтовете.

HBC използва типичен сървър за приложения Oracle WebLogic и платформата за електронна търговия Blue Martini, развивана от компанията RedPrairie. Функционалността на решението е създавана и усъвършенствана в продължение на много години. “Платформата работеше, но имахме проблеми с нейното разгръщане, беше сложно да се обновява и да се въвеждат промени”, казва Матю Пик, ръководител на отдел “ИТ инфраструктура” в HBC.

Проучвайки различни варианти за разрешаване на проблемите инженерите от екипа на Матю Пик разгледали няколко идеи. Накрая се спрели на решение базирано на микроуслуги и контейнери.

Като първа стъпка от реализацията на проекта за смяна на платформата Пик и екипът му избрали Product Detail Page (PDP). PDP представлява част от приложение за електронна търговия, в което се съдържат описания и снимки на стоки. Вместо да вградят PDP в приложение, програмистите от HBC го разбили на 12 отделни микроуслуги, които разположили в контейнери. Един контейнер зареждал изображенията, друг обслужвал текстовата част и т.н.


В архитектурата базирана на микроуслуги Матю Пик открил редица предимства: станало по-лесно да се разработват и внедряват обновления, както и да се откриват и разрешават проблеми. Ако, например, престане да работи функцията осигуряваща отчети за цените, проблемът (теоретично) остава в рамките на една услуга и екипът, отговарящ за това, може да я отстрани.

В същото време, внедряването на контейнери и микроуслуги е част от по-широка стратегия, насочена към поддръжката на мобилни устройства и адаптивен дизайн.

И така, в края на 2016 г., HBC се присъедини към нарастващия брой организации, които експериментират с приложения, изградени на базата на архитектурата на микроуслугите. През последните 2 години тази тенденция привлича все повече внимание, предизвикано от желанието на разработчиците на приложения да ускорят написването на нов код и да опростят управлението н а сложни приложения. Но, както и всяка друга нова технология, микроуслугите поставят пред разработчиците и нови задачи.

Какво представляват микроуслугите?

Няма общоприето определение за микроуслугите. Същността на идеята за тях е вместо монолитни приложения да се проектира набор от компоненти, от които да се сглобяват приложения. Анализаторът от IDC Ал Хилуа описва микроуслугите като “децентрализирана програмна архитектура, в която компонентите на приложенията се проектират и развиват независимо един от друг”. Връзката между отделните компоненти се поддържа чрез общи приложни програмни интерфейси (API). По такъв начин, дадено приложение или услуга се разбива на множество компоненти, които си взаимодействат с помощта на API.

Сигурно всичко това ви звучи познато. Очевидно, микроуслугите напомнят за модния в предишните години термин – сервизно ориентирана архитектура (SOA), въплъщаващ идеята компонентите на приложенията да се изграждат отделно.


Интересът на предприятията към микроуслугите се обяснява с търсенето на нов подход към изграждане на сервизно ориентирана архитектура, а също към използване на микроуслуги с контейнери”, пояснява Дейвид Линтикум, вицепрезидент на консултантската компания Cloud Technology Partners.

Повечето експерти подчертават, че възможностите на SOA, като правило, са ограничени от използването на един език за програмиране и една среда за разработка с традиционни инфраструктурни компоненти. Микроуслугите са по-гъвкава методология за разработка на сложни приложения, състоящи се от неголеми и независими процеси. Микроуслугите, изграждащи приложението, могат да бъдат написани на различни езици, да взаимодействат помежду си с помощта на стандартни API и да се разполагат в инфраструктура от ново поколение – виртуални среди или публични облаци, в които се използват контейнери за приложения.

Предимства

Архитектурата на микроуслугите осигурява няколко важни предимства:

>> Гъвкавост. Тъй като приложението се разбива на компоненти, всяка отделна част от него може да се разработва независимо. “Вече няма нужда да се тревожите за синхронизирането на работата на програмистите”, отбелязва Сид Сиджбрандидж, изпълнителен директор на стартъпа GitLab, който в конкуренция с GitHub предлага уеб-базирана услуга за разполагане на софтуерни проекти. Вместо да управлявате екип от 100 човека, които да работят по едно приложение, можете да формирате 10 екипа от по 10 човека, които да проектират отделни компоненти и щом някой от тях е готов, да го внедряват. Не е необходимо да се съставя график за обновленията и да се чака докато приложението е напълно готово – новите функции се появяват веднага, след като бъдат реализирани.

>> Плавно разграждане. Ако даден компонент на приложение престане да работи, няма опасност да спре цялото приложение. “Целта е да стесним кръга от неизправности и да минимизираме техните последствия”, пояснява анализаторът от 451 Research Дони Беркхолц. Например ако сайта на една банка е създаден с подхода на микроуслугите, функцията за превеждане на пари може да откаже, но това няма да пречи на клиент, който иска да провери баланса по своята сметка.


>> По-малко усилия за синхронизиране на действията на разработчиците. Екипите от разработчици създават компоненти, които се включват в приложението независимо от дейността на другите екипи. Интеграцията на компонентите се осъществява с общи API. Тъй като усилията на даден екип изцяло са фокусирани върху един компонент, производителността му се повишава. Участниците в колектива, който разработва само една функция, стават експерти в съответната област.

И все пак на думи разработката на приложения на базата на микро услуги изглежда доста по-лесна отколкото е в действителност.

Предизвикателства

Според Дони Беркхолц, екипите които следват подхода agile или концепцията DevOps имат повече шансове за успех в създаването на микроуслуги, отколкото останалите.

DevOps (акроним от англ. development и operations) е методология за разработка на програмно осигуряване, която има за цел да осигури активно взаимодействие и интеграция на специалистите по разработка на софтуер и специалистите по информационно и техническо обслужване. Основната идея е да се осигури тясна връзка между разработката и експлоатацията на софтуер, така че организациите да могат по-бързо да създават и обновяват програмни продукти и ИТ услуги.

В DevOps среда кодът се пише, тества и внедрява по-бързо. Много компании, които следват концепцията DevOps, имат автоматизирана инфраструктура с възможности за самообслужване – например, виртуализирани или облачни среди за тестване и разработка или за разпространение на готовите приложения в експлоатационна среда. Проучвания, проведени от 451 Research, показват, че две трети от организациите прилагат при разработката на приложения подхода agile, а около 40% - концепцията DevOps. Именно в такива организации вероятността за успешно внедряване на микроуслуги е най-висока. В компаниите, които не следват тези тенденции, преходът към микроуслуги ще протича по-сложно.

В предприятията, използващи agile проектиране и DevOps, както правило, се създават контейнери с приложения.

Какво представляват контейнерите? При традиционната виртуализация, базирана на хипервайзор, изолирани процеси се изпълняват върху техните собствени индивидуални операционни системи, като всеки е свързан независими с контролиращия хипервайзор. Системата за виртуализация заделя памет и изчислителна мощ за всеки процес.

При виртуализацията, базирана на контейнери, отделните процеси споделят обща операционна система – те просто имат различни контейнери в които са “опаковани” библиотеки и други ресурси.

Матю Пик обръща специално внимание на симбиозата между контейнери и микроуслуги. Когато разбивате монолитно приложение на компоненти, пускането на услугите в контейнери помага на разработчиците на приложения и екипа, изграждащ инфраструктурата, да действат в синхрон. Разработчиците знаят, какво трябва да опаковат в контейнер, а екипите, занимаващи се с оперативна дейност, знаят как да подготвят инфраструктурата за настаняването на контейнерите.

Инфраструктурата оказва на микроуслугите и друго въздействие. Анализаторът от Forrester Дейв Бартолети отбелязва, че когато разработчиците в организацията започнат да следват новите тенденции, ролята на ИТ инфраструктурата се променя.

Разработчиците, изграждащи микроуслуги, не отиват в ИТ отдела за да подадат заявка за нова виртуална машина. При agile проектирането разработчиците са в правото си да очакват, че необходимите им инфраструктурни ресурси ще бъдат заделяни автоматично чрез API и еластично мащабиране”, пояснява Бартолети.

За поддръжката на инфраструктурна среда от този тип съществуват множество различни инструменти. Може да се изгради вътрешен облак с помощта на програмно осигуряване за частни облаци, предлагано от VMware или OpenStack. Ако ИТ подразделението не желае да се занимава с изграждането на инфраструктура, то може да се обърне към публичните облаци на Amazon, Microsoft, Google и други доставчици. Управлението на инфраструктурата може да се автоматизира с помощта на платформите PaaS Cloud Foundry или аналогично решение на Red Hat. За приложения, които са управлявани от събития (например за сценарии на Интернет на нещата), много подходящи са така наречените безсървърни изчислителни платформи. Всяка такава платформа променя ролята на ИТ отдела – сега пред него могат да възникнат най-разнообразни задачи, започвайки от доставка на инфраструктура и завършвайки с изграждане на среда, в която разработчиците могат самостоятелно да разгръщат микроуслуги.

За какво са най-подходящи микроуслугите

Архитектурата на микроуслугите не е еднакво подходяща за всички приложения. За да бъде разбито на компоненти дадено приложение, то трябва да бъде достатъчно сложно. Ако приложението е предназначено само за изпълнението на една функция (например маркетингова кампания на сайта, която ще приключи за седмица), няма нужда от микро услуги. Но сложните приложения (например софтуер за управление на потоци данни от Интернет на нещата), определено печелят при разбиването им на компоненти.

Също така важно е да се разбира, кои функции има смисъл да се разбиват на компоненти, и кои – не. Според вицепрезидентът на компанията DISYS Ахмар Абас, различните микроуслуги трябва да работят относително независимо една от друга. “Ако за взаимодействие между компонентите отива повече време отколкото за обработка вътре в компонента, губите ефективност”, пояснява Абас.

В заключение, анализаторът от 451 Research Дони Беркхолц обобщава, че ограниченото прилагане на микроуслуги при създаване на нови приложения се дължи на една основна причина – цената за пренасянето на съществуващите приложения към нова платформа може да се окаже доста висока. С по-добри шансове да спечелят от новата концепция са компаниите, на които не се налага да харчат допълнително за провеждане на необходимите преобразувания.

Източник: Brandon Butler. What you need to know about microservices. Network World. November 9, 2016

КОМЕНТАРИ ОТ  

КОМЕНТАРИ

Трябва да сте регистриран потребител, за да коментирате статията
"Какво трябва да знаете за микроуслугите"



    

Полезни страници
    За нас | Аудитория | Реклама | Контакти | Общи условия |
    Действителни собственици на настоящото издание са Иво Георгиев Прокопиев и Теодор Иванов Захов