Софтуер

Подходът на микроуслугите опростява сложните софтуерни решения

Computer World

На 25 и 26 октомври в Младежки театър в София ще се проведе конференцията за ИТ архитектура 2doIT ITARC Sofia 2016. Сред лекторите на нея ще е Игор Стоянов, Director of Engineering for Cloud Automation Platform във VMware. Презентацията му е озаглавена „Evolving Microservices-based architecture in enterprise products and solutions“. Ето какво сподели за Computerworld той преди събитието.

Г-н Стоянов, на предстоящата конференция 2doIT ITARC Sofia 2016 ще говорите за микроуслуги. Това ли е новия начин за изграждане на софтуерни системи?

В последните няколко години това се утвърди като основна тенденция за изграждане на софтуерни системи. Причините за това са няколко и включва непрекъснатата тенденция за повече облачни услуги, така наречената „DevOps“ тенденция, както и появата на нови технологии и решения, като Докер (Docker) Контейнери и кворум базирана синхронизация на данни.

Началото на тази архитектура от микроуслуги е доста по-рано обаче. Корените започват от емблематичната книга „Domain Driven Design“ (Дизайн базиран на определен домейн) от 2003 г. и концепцията за „Bounded Context“ (ограничен контекст). Доста сходни идеи бяха заложени в популярната до скоро архитектура от типа „Service Oriented Architecture“ – SOA.

За някои хора отделянето на функционалности като услуги на много малки части може да звучи като нещо нелогично. Какво налага функции да бъдат изолирани и оформяни като микроуслуги?

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

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

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

Има ли случаи, когато по-удачният вариант е едно „традиционно“, монолитно, решение? Може ли да бъде дефинирана разделителна линия, отвъд която е по-подходящ единният подход?

Да, определено има случай, когато едно „традиционно“ монолитно решение е по-удачният вариант. Като начало, няма едно архитектурно решение, което да е подходящо за всички проблеми и всяко такова архитектурно решение винаги има позитивни характеристики, както и някои по-негативни.

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

Обикновено, за софтуерни системи, които се програмират от малки екипи, не се очаква да станат много големи в бъдеще и не се очаква да са много натоварени, „традиционно“ монолитно решение е много по-удачният вариант. Програмирането на такива системи с микроуслуги ще направи решението по-сложно от начало поради дистрибутирането на различните функционалности в различни микроуслуги, без това да може да се изплати в по-далечна перспектива. 

Може ли да се каже, че Интернет на нещата е потенциално „поле за изява“ за микроуслугите? Какви предизвикателства по отношение на софтуера води със себе си IoT?

IoT се идентифицира като следващата голяма промяна в софтуерната сфера, но този път ще обхване доста други сфери. IoT е огромен брой малки устройства и сензори, които са свързани към Интернет. Един от начините, по които IoT може да се адресира, е като се разглежда като група от микроуслуги в облака, които разменят информация с тези устройства по много добре дефинирани REST API, които се използват от Интернет дори и днес. Микроуслигите дават възможност да се направи много специфична задача и да се изпрати на друга такава микроуслуга за друга задача. Например, един сензор може да изпрати данни, че вече съм вкъщи. След това, друга микроуслуга може да реагира на първата, като сигнализира да се включат лампите.

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

В лекцията си ще говорите за разработката на корпоративно-ориентирани облачни платформи. Кои са основните тенденции в тази насока?

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

Като цяло, тенденциите са да се върви към облачни услуги или към вътрешни услуги, които имат същите характеристики както публичните облачните услуги. Голямата разлика, за която и аз ще говоря в лекцията, е допълнителните изисквания към тези корпоративно-ориентирани облачни платформи, включващи голямо ниво на персонализиране към дадени потребители или бизнес модел, както и голямо ниво на гъвкавост и интегрираност с много други корпоративни системи, които дефинират цялостното бизнес решение и модел на опериране.

Въпросите зададе АлександърГлавчев





© Ай Си Ти Медиа ЕООД 1997-2019 съгласно Общи условия за ползване

X