Дизајнирање на архитектура на микросервиси: развој на бот базиран микросервис за управување со анкети

Transcription

1 Универзитет Св. Климент Охридски - Битола Факултет за информатички и комуникациски технологии Битола Отсек за информатика и компкутерска техника Дизајнирање на архитектура на микросервиси: развој на бот базиран микросервис за управување со анкети -магистерски труд- Ментор Проф. Д-р Илија Јолевски Кандидат Мехмет Алче Битола, 2017

2 2

3 Содржина Вовед... 6 Мотивации за микросервисите Мали и фокусирани Лабава спојка Неутрални Граничен контекст Компарација на микросервисите и монолитната архитектура Придобивки од микросервисите Предизвици со монолитната архитектура Перспективата на програмер Перспектива на тестер Перспектива на бизнис сопствениците Перспектива на управувачите со услугите Што да се избегне со миркосервисите Кога не треба да се почнат со микросервисите Микросервисите не можат да се размислат без DevOps Не треба да се управуваат со своја инфраструтура Не треба да се креираат многу микроесервиси Не треба да се заборааваат на проблемите со каснување Што е разликата од сервисно-ориентираната архитектура? Што претставаува СОА Студии на случај и најчестите архитектонски шеми Е-commerce discount site Financial services company Large brick-and-mortar retailer Сценарија каде што се користат микросервисите Cloud Trader Online Store Acme Air Елементи на микросервисната архитектура Бизнис-ориентиран Дизајн за неуспех

4 Модел на прекинато струјно коло Трупови Децентрализирано управување со податоци Откриеност Интер-услуга комуникациски дизајн Синхорнизирани HTTP во споредба со асихрони пораки Справување со комплексноста Еволутивен дизајн Дизајнирање на микросервиси Користење на дизајн на размислување Ридови Hills Playback Сценарио Кориснички приказни Приказни Спонзор корисници Идентификување на можностите на микросервисите Избор на начинот за имплементација Определувањето на големината на микросервисите REST API и пораки REST Пораки REST и пораките заедно Иднината на микросервисите Микросервиси и DevOps DevOps DevOps е предуслов за успешно усвојување на микросервисите Организирање на тимовите за поддршка на микросервисите Организирање на тимовите за поддршка на други микросервисни тимови DevOps можности за микросервисната архитектура Континуирано бизнис планирање Континуирана интеграција и соработка за развој Континуирано тестирање

5 3.2.4 Континуирано деплоирање Континуирано мониторирање Континуирани повратни информации од клеинтот и оптимизација DevOps способности: Тестирање на стратегии за микросервисите Значителен методи на тестирање Unit тестирање Интеграционо тестирање Компонентно тестирање Контракт тестирање Крај до крај тестирање Перформанс тестирање Градење на доволно стратегија за тестирање Бот за управување со анкети во Slack Опис на софтверот Како работи Slack Slack апликации Испраќање на известувања со webhooks Праќање пораки Додавање линкови Персонализација за сопствени интеграции Форматирање на изгледот Дистрибуција како Slack апликација Slash команди Бот корисници Повикување на веб и RTMP API Чекори при креирање на апликацијата Бот интеграција во Slack Botkit - Mongoose (конфигурации и спецификации) Заклучок Користена Литература

6 Вовед Живееме во свет каде што технологија се повеќе навлегува во животните активности. Денес не можеме да замислиме ден поминат без употреба на интернет. Особено со појавата на Android и IOS оперативните системи, луѓето своите секојдневни активности ги извршуваат преку мобилните телефони (без разлика дали се користат за социјално дружење или за работа). Овој тренд ја нагласува потребата од развивање на мобилни-веб апликации, кои што ќе им ја олеснат рабoтата на човекот. Тоа се една од причините што во последните 2-3 години се повеќе се бараат програмери кои работат на развивање на мобилни-веб апликации. Овие апликации се градат со помош на т.н. микросервиси. Микросервисите денеска претставуваат еден од најважните пристапи за развивање на апликации, тие се мали сервиси кои што цело време комуницираат меѓусебно користејќи различни протоколи. Денеска микросервисите им овозможуваат полесен пристап при решавање на проблемите. Заради тоа голем број на компании во светот секојдневно развиваат нови апликации користејќи го пристапот на микросервисите. Денеска во Македонија се поголем е бројот на софтверските компании кои што го имплементираат овој пристап. Сепак за разлика од другите земји во Европа кај нас микросервисната архитектура не е многу искористена меѓутоа со текот на времето се надевам дека бројот на компании што ја користата оваа архитектура ќе биде многу поголем. Токму тоа односно предмет на овој магистерски труд ќе биде дефинирање на поимот микросервис, нивното влијание врз креирање на мобилни и веб базирани апликации. Целта на магистерскиот труд е креирање на бот корисник за Slack (алатка за тимска колаборација, основан во Август 2013 година денеска, број еден софтвер за тимска комуникација во компаниите). Како алатка за креирање на ова апликација ќе биде бот корисникот, тие имаат многу сличности како и обичните корисници. Најголемата разлика помеѓу бот корисниците и обичните корисници е тоа што бот корисниците се контролирани програмабилно со помош 6

7 на бот токенот кој што има пристап до повеќе Slack API-ја. Бот корисниците не можат да се логираат и тие немаат лозинки. Постојат и таканаречени персонализирани бот корисници и бот корисниците за користење од страна на други тимови. Така да истиот (бот корисникот) ќе биде искористен за креирање на бот, базиран на микросервис за управување со анкети. 7

8 Мотивации за микросервисите Микросервисите всушност претставуваат една архитектура, во која големи комплексни софтверски решенија се составени од еден или повеќе сервиси. Микросервисите можат да бидат распоредени независно еден на друг. Секој од тие микросервиси се фокусирани на завршувањето на една задача. Сликата 1 ни покажува пример на апликација со користење на микросервиси. Слика 1: Апликација за користенње на микросервиси Микросервисите можат да бидат развиени во било кој програмски јазик. Тие меѓусебно комуницираат со помош на Апликативен програмски интерфејс (APIs) како и со Репрезентативен членски трансфер (REST). Микросервисите исто така имаат ограничен 8

9 контекст. Тие немаат потреба да знаат ништо за основната имплементација или за архитектурата на другите микросервиси Мали и фокусирани Микросервисите треба да бидат фокусирани во една единица на работа, иако како такви тие се мали. Не постои некое правило за големината на микросервисите. Како пример можат да се наведат два пица тима, каде што треба да направат пица во големина доволно да се нахранат двајца. Така да микросервисите треба да бидат доволно мали каде што еден инжинер ќе можи да ги одржува и преработи истите, без потреба на останатите членови од тимот. Некомплексен интефејс: Фокусот треба да насочен кон интеграција на некомплексен односно мал интерфејс. Тоа значи мала инплементација но не значи дека секогаш треба да важи оваа. Микросервисите исто така треба да бидат третирани како некоја апликација или производ. Истата треба да има свој изворен код и начин за лесно билдање и деплоирање на нови верзии. Иако сопственикот на производот може да се залага за повторна употреба микросервисот, повторната употреба не е бизнис мотивација на микросервисите. Исто така постојат и таканаречени локализирани оптимизации кои што се користат за подобрување на корисничкиот интерфејс (responsive), за да бидат одговорни на потребите на клиентите. Грануларноста на микросервисите можат да се утврдат врз основа на бизнис потребите. Временска прогноза, следење на патека на некоја кола, претставуваат услуги кои можат да се добиваат од некои други (third party) сервиси, така да може да се каже дека за некои комплексни или големи продукти поврзаностна со некоја трет сервис е незамислив. Проблем со брзината. Изработка на микросервиси кои што се зависни од други микросервиси можат да влијаат негативно на брзината на крајниот продукт. 9

10 1.1.2 Лабава спојка Лабавата спојка е од апсолутно суштинско значeња карактеристика на микросервисите. Притоа сите микросервиси треба да бидат деплоирани како свои, односно не треба да има никаква врска со некој друг микросервис Неутрални За правилна работа, користење на точна алатка е многу битно. Микросервисите треба да бидат изградени со користење на програмски јазик и технологија што најмногу му одговара на микросервисот. Микросервисите се составени заедно за да формираат комплексни апликации и истите не треба да бидат напишани со користење на ист програмски јазик. Во некои случаи Java може да биде точниот јазик, во други случаи Python, Ruby on Rails. Пример комуникацијата со микросервисите се воспоствавува преку неутрални API, типичен HTTP (хипер текст трансфер протокол) базиран на ресурсите на API, исто како REST. Исто така треба да се стандардизира во интеграцијата а не во платфромата коpиcтена од страна на микросервисот. Со помош на неутралните јазици многу лесно можат да се искористат постоечките вештини Граничен контекст Под граничен контекст се подразбира дека одреден микросервис не знае ништо за основната имплементација на другите микросервиси околу него. Но доколку заради некоја причина микросервисот има потреба да дознава за другиот микросервис (пр. што работи или како треба да биде повикуван) тогаш не станува збор за граничниот контескт Компарација на микросервисите и монолитната архитектура Во табелата подолу содржи компарација помеѓу микросервисна и моно архитектура 10

11 Категорија Моно Микросервисна Код Единствен код за целата апликација Секој микросервис има свој код Разбирливост Често збунувачко и тешко за одржување Деплоирање Копмплексност во деплоирање заради големината Јазик Типично е составен од еден програмски јазик Скалирање Потребно е скалирање на целата апликација Подобра за читливост и полесен за одржување Едноставност во деплоирањето секој микросервис може да се деплоира индивидуално. Секој микросервис може да биде имплеменитран во различен програмски јазик Овозможува скалирање на одредени сервиси, без да се скалира целата апликација 1.2 Придобивки од микросервисите За опишување на придобивките на архитектурата на микросервисите треба да се погледне во контекстот на архитектурата на повеќето решенија за информатичка технологија и архитектуралниот систем за развој на апликации, така да со текот на годините развиени се повеќе сложене и монолитни решенија (апликации). Има повеќе пристапи за употреба на архитектуралниот модел, еден од нив претсватува (MVC). Што претставува монолитна апликација? Монолитна апликација претставува апликација каде што целата логика се наоѓа во еден апликациски сервер. Типичните монолитни апликации се големи и изградени од повеќе тимови, каде што треба да се работи внимателно особено при менување на верзија на апликацијата. Една апликација може да биде монолитна додека има API сервиси за обезбедување на целата бизнис логика или ако 11

12 целиот презентациски слој претставува голема веб апликација. Во двата случаеви микросервисната архитектура може да биде алтернатива. [1] Слика 2: Монолитни апликации со архитектура од повеќе нивоа Предизвици со монолитната архитектура За подобро разбирање на предизвиците на монолитната архитектура, треба да се разгледат сите аспекти од страна на програмерите, тестерите, бизнис сопствениците како и стручните лица за управување со услуги Перспективата на програмер Голем дел од монолитните апликации содржат огромно количество на код, која често е опасно за програмерите. При приклучување на нови членови во тимот, времето потребно за адаптирање односно запознавање со кодот е големо. Новите членови се во двоумење при промена на код поради страв, бидејќи при промена на еден мал дел од кодот, може целиот концепт на апликацијата да не функционира. Притоа не се знае секогаш што треба да се менува во кодот при додавање на нова функција или менување на истата. Големите броеви на линии на код исто така може негативно да влијае и врз околина (IDE) во кое се развива апликацијата или во некои случаеви истата може и да не функционира вопшто. Во 12

13 случаевите кога сервисите се развиваат во облак, тоа значи трошење на повеќе време за туркање на истата во облак (Cloud). Овој начин на пристап дава подобри резултати при преглед на кодот и враќање на истиот код во работна состојба (доколку нешто не функционира како што треба). Монолитните апликации бараат подолги прегледи на код. Монолитните апликации имаат подолг животен век во споредба на микросервисните, заради тоа во тимот можат да се приклучат нови програмери, воедно и да заминат, што резултира во повисоки трошоци за поддршка. Оваа ситуација предизвикува неконзистентности во кодот и документацијата. од сите овие елемети може да се сумира дека за монолитните апликации им е потребно повеќе време за одржавање и предизвикуваат големи тешкотии. Микросервисните апликации им овозможуваат полесен начин на работа на програмерите и истите можат да се поделат во повеќе групи, така да работата ќе виде завршена побрзо и поефикасно. Слика 3: Разлика помеѓу монолитна и микросервисна архитектура Микросервисите ги обезбедуваат следните бенефиции за програмерите: Овозможува да се избегнат проблемите со големите кодови и нивно лесно одржување Овозможува користење на постоечки вештини или најоптимален јазик 13

14 Го подобрува времето за деплориање и ја намалува оптовареноста на IDE Полесно дебагирање Овозможува подобра тимска работа (индивидуална) Поедноставен начин на следење на кодот Овозможува комплетна сопственост и автономност на еден тим, од дефиниција преку развој, распоредување Перспектива на тестер Бројот на тестирањата во големи апликации е многу голем, бидејќи потребно е подолго време за стартување на истите. Во секој момент има промени во кодот, каде што истата бара рестарт на апликацијата а притоа продуктивноста на тестерите се намалува. Исто така се поставува прашањето Што ако повеќе тимови на тестери работаат во нивните случаеви. За сите дополнителни промени на компонентите целиот контејнер (апликациајта) мора да се рестартира, без оглед на големината и обемот на промените. Со монолитните апликации, дури и мала промена на кодот може да има домино ефект при тестирањето. Типично, монолитните апликации имаат потреба од чување на историја на регресивни тестови Перспектива на бизнис сопствениците Бизнис сопствениците имаат желба нивните тимови да бидат способни и да им одговараат на потребите на новите клиенти и пазарот. Микросервисите овозможуваат побрз пристап и побрзо време на испорака. Микросервисите им овозможува на бизнис сопствениците да добиваат побрзи повратни информации и да направат корекција во нивните инвестиции. Со помош на микросервисите можат да се креираат помали тимови кои ги усогласуваат бизнис приходите. Истата им овозможува на бизнис сопствениците да ги погледнат распореденоста на нивните ресурси со тоа можат да го зголемат влијанието од помали во поголеми области. 14

15 Бизнис сопствениците со ново софтверско решение сакаат да ги восхитат нивните корисници. Микросервисите обезбедуваат подобро корисничко искуство, овозможувајќи скала на микросервиси каде бавните (тесни грла) можат да се отстранат. Микросервисите се дизајнирани така што истите се еластични што значи подобра услуга и непрекинато корисничко искуство. Бизнис сопственициите заради големиот обем на работа сакаат да имаат можност да соработуваат и со трети лица без ризик од губење на интелектуалната сопственост. Притоа со користење на архитектонскиот стил, лесно може да се увиди каде станува збор за дуплирање на услугите. Има заеднична платформа за развој, градење и менаџирањето со микросервисите овозможува лесно да се елиминираат дупликатите, и да се намалат трошоците Перспектива на управувачите со услугите Големите монолитни апликации често пати имаат голем бизни обем и многу допирни точки со ИТ ифраструктурата. Секоја промена на апликацијата резултира со зголемување на временскиот циклус на деплоирање. Минимално централизирано управување значи помалку состаноци за координација. Со користење на микросервисната архтектура, истата овозможува стручните лица за управување со услугите да подржуваат повеќе продукти. Ефикасноста може да се реализира со автоматизирање на деплорањето, логирањето како и следење на одделните тимови. На првиот состанок со клиентот очекуваат трошоците колку што можат да се помали со автоматизирање на поголемиот дел од инфраструктурата и платформата како сервис. Доколку има некој проблем во продизводство, истата ќе може многу лесно да се идентификува и да се решава. Со идентификување на мали не-одговорни микросервисни процеси или со преглед во логот на апликацијата лесно може да се идентификва кој член од тимот може да го отстрани проблемот. Апликациите стануваат се поеластични со користење на микросервисниот архитектонски стил, особено со организиранње во DevOps. Тимовите имаат поголем свест, одговорност и контрола. Притоа доколку се јави некој проблем тимот којшто е сопственик 15

16 на микросервисот има поголем поттик за спроведување на мерките за спречување на сличните инциденти во иднина. Во ново време постојат толкав број на јазици што програмерите можат по нивниот вкус да го изберат програмскиот јазик што најмногу им одговара на софтверското решение што би требало да се имплементира. Во cликата 4 се прикажува микросервисна архитектура со повеќе јазици и со повеќе техники за чување на податоци. [1] Слика 4: Микросервисна архитектура со повеќе јазици и со повеќе техники за чување на податоци 1.3 Што да се избегне со миркосервисите Архитектурите, одредените пристапи вообичаено се претворени во трендови, бидејќи постојат голем број на случаеви каде што нивната употреба е многу корисно при решавање на одреден проблем или класа на проблеми. 16

17 Во случај на микросервисите, пред да бидат познати, голем број на компании своите работи ги извршувале со монолитни апликации. Меѓутоа имале голем проблем во нивните раце бидејќи апликациите биле големии, истите се судрија со современиот начин на скалирање, управаување и развој на големи системи во Cloud. После многу обиди и грешки тие успеале да го најдат точниот начин односно со микросервиси. Важно е исто така да се дознае и другата страна на микросервисите, односно нивната популарност може да биде и закана на програмерите, односно истата да ги принуди програмерите да корист и да пробуваат различни контексти што резултира со неуспех на системот во некои случаи. Ова е лоша вест за практичарите кои имаат вистински корист од такви архитектури. Во продолжение ќе се објасни во кои сличаеви не треба и не е препорачливо да се користат микросервисите. Истата има корист во многу случаи бидејќи користењето на микросервисите со себе носи и големи трошоци. Така да практично би било да се користи кога е најпотребно и најбезбедно. [1] Кога не треба да се почнат со микросервисите При креирање на нова апликација, не треба да се поставува прашањето Дали треба да се користат микросервиси. Така да на почетокот, апликацијата е мала. Дури и ако не е мала, има само мал број на програмери што работат во истиот проблем. Голем дел од програмерите знаат како да го преработат кодот за еден викенд Микросервисите не можат да се размислат без DevOps Микросевисите можат да предизвикат експолизија на подвижните делови. Не е добра идеја да се имплементираат микросервисите без сериозни деплоирања и мониторирања. Деплоирањето на апликацијата треба да се сведи на тој начин што со помош на едно копче да може да се избилдат нови верзии од апликациите. 17

18 Програмерот не треба ништо да прави. При коммит на кодот истата треба да биде спремна за деполирање, меѓутоа сепак во некои случаеви можат да имаат некои мануелни чекори од страна на програмерите Не треба да се управуваат со своја инфраструтура Микросервисите често пати имаат повеќе бази на податоци, кеширани податоци, брокери на пораки и други слични сервиси што треба се одржуваат, истите се гурпирани и лесно достапни. PaaS како и IBM, Bluemix или Cloud Founders, овозможува поголема и побза функционалност без главоболки Не треба да се креираат многу микроесервиси Секој нов микросервис користи ресурси. Кумулативните ресурси можат да ги надминат придобивките од аргутектурата, ако се надмине бројот на микросервисите што DevOps организацијата може да се справи. Исто така она што треба да се спомни е дека микросервисите не треба да бидате споделени помеѓу системите Не треба да се заборааваат на проблемите со каснување Изработка на премногу грануларни услуги или барање на повеќе зависности во микросервисите може да доведе и до намалување на каснување. Притоа треба да се внимава при воведување на долполнителни миркосервиси. При поделба на системот на помали автономни микросервиси, треба да се зголемат бројот на повици напраени преку границите за да се извршат барањата. Овие повици можат да бидат сервис-сервис повици или сервис-компонентни повици. Истите дополнителни повици можат да го забават брзината на работа на системот. Заради тоа додавање на тестови за перформансите на системот се многу клучни и знајачни. Прегледот на перформансите на системот е несомнено важно, бидејќи со тоа, можат да се следат сите активности на системот (фунцкионалсноста, оптовареноста...). Пример 18

19 може да се користи IBM Bluemix Monitoring за следење и анализа на системот. Надвор од ова, сервисите морат да бидат кеширанни агресивно. 1.4 Што е разликата од сервисно-ориентираната архитектура? Во овој сегмент ќе се направи компарација помеѓу СОА и микросервисната архитектура, односно ќе ги откриеме разликите помеѓу нив. Споредбата момеѓу овие две системи е комплексна, бидејќи оние кои користат микросервисна архитектура никогаш немаат тврдење дека тоа претставува нов пристап кон градење на дистрибуирани системи. Во таа смисла споредбата помеѓу СОА и микросервисите предложено е од страна на корисниците (поборниците) на СОА кои сакаат да докажат дека таква разлика не постои. Што претставаува СОА Сет од сервиси и бизнис-ориентирани функционалности кои што бизнисот им обезбедува на клиентите, партнерите и други области на организацијата Архитектурален стил кој бара сервис провајдер, барател на сервис со опис на сервис. Сет на архитектурални принципи, модели и критериуми кои се однесуваат на карактеристики како модуларност, повторна употреба итн. Програмерски модел со комплетирани стандарди, алатки и технологии кои што подржуваат REST сервиси и други видови на сервиси Middleware решение оптимизиран за мониторирање, вклопување на сервиси и управување Од тука може да се увиди дека СОА има сеопфатен сет на цели и проблеми со кои се обидува да ги реши. Таа исто така ни овозможува за да се почнат и да се забележат разликите помеѓу СОА и микросервисната архитектура. 19

20 И покрај тоа што и во двата случаи станува збор за сет на сервиси, амибициите на овие сервиси се различни. СОА се обидува истите сервиси да ги стави на место каде што сите ќе можат да ги користат. Микросервисите алтернативно се креирани со поголем фокус и цел, кој што дејствува како дел од еден дистрибуиран систем. Слика 5: Пример на микросервисна архитектура Овој дистрибуиран систем често е создадено при распаѓање на големa монолотна апликација, негоавата основна намера е тоа дека колекција од микросервиси продолжуваат да работат заеднички како една апликација. Типично нема амбиција за служење на повеќе системи во исто време. За разлика од СОА, микросервисите егзистираат имплицитно и истите се добро познати од страна на луѓето, со тоа не се бара опис на услугата. Некои од пософистицирани микросевисни системи можат да го прифатат степенот на откривање, со тоа истите стануваат пофлексибилни и поцврсти. Поентата е дека таков архитектонски модел не е потребен. Микросервисен систем каде што сите микросервиси комуницираат еден со друг, користаат релативни едноставни конфигурациски фајлови и 20

21 истата може да биде ефективно решение. Тимовите можат да отркиваат кои микросервиси се достапни за нив при развој на софтвер користејќи каталог, регистер или алатки за управување со API-то. Сепак СОА и микросервисната архитектура имаат многу заеднични принципи, патеки и програмерски модели. Впрoчем микросервисната архитектура е еден вид на СОА. Исто така може да се каже дека мирксоервисите претставауваат и како продолжение или специализација на СОА, со која границите на функционалност се користат за дефинирање на домаин модели и доделување на истите на тимовите кои што можат да ги избираат нивните развојни јазици, фрејмворк и деталите за деплораиње. Слично на тоа, мониторирањето и управувањето се едни од најбитните точки во микросервисните архитектури во споредба на СОА системи. За разлика од СОА, бизнис и техничките мотивации за микросервисите се различни. Компаниите се помалку сакаат да инвестираат во големи и долги транформационални иницијативи. Микросервисите овозможуваат постепена трансформација користејќи локални оптмизации. Некои од СОА системите во реалниот свет имаат стекнато угледот на сложеност како и потреба за многу комплексна обработка и слоеви на апстакција за да се зголеми употребливоста од страна на луѓето. Најважната причина за оваа комплексност е за да се постигне поголем успех. Како директна последица на прекумерниот обем, стандарди и алатките кои СОА имало во минато време, микросервисната архитектура намерно е фокусиран во решавање на еден проблем. Истата е повеќе фокусирана за постепено развивање на големи, монолитни аппликации во дистрибуриани системи на микросервисите, коишто лесно можат да се управуваат и да се деплоираат користејќи постојани интеграциони практики. Никој од софтверските развивачи немаат идеја нивниот микросервис да биде дел од некој друг микросервис кои што се користи од некој друг систем. Иако што има некој степен на употреба сепак истата не се случува на сервисно ниво. Сите микросервиси во еден микросервисeн систем се предводени од една Master 21

22 апликација. Истите микросервиси доколку е потребно, можат да бидат користени како други постоечки или нови апликации за да се постигнат слични бенефиции. Не е тешко да се разбере како е создадено оваа разлика. СОА е дизајниран со амбиција за решавање на покомплексни проблеми. Спротивно на тоа, микросервисната архитектура е прифатена од страна на повеќе компании кои што се обидуваат да имаат континуиран развој, да имаат посилни инжинерски тимови, односно користење на исти технологии во сите проекти. Притоа не е изненадувачко кога се соочува со истиот област на дистрибуирани системи составени од независни сервиси, крајниот резултат е сосема разлинчен. Како директна последица на пофокусиран и ограничен обем, може да се каже дека микросервисните системи се поатрактивни во бизнисите кои инвестираат повеќе во инфрастрктурата. Ваквиот пристап е поефтин и поекспериментален, односно се плаќа како што се трансформира. Спротивно на тоа СОА обично бара повеќе финанциска и архитектонса постевеност. На крај како заклучок може да се наведи дека СОА и микросервисните архикетури се видови на сервисни архитектури, бидејќи и двата се справуваат со дистрибуирани системи на сервиси кои комнуицираат преку мрежата. Сепак практичните резултати се прилично различни, бидејќи фокусот на СОА е во користење и откирвање, од друга страна пак фокусок на микросервисите е во замена на монолитните апликации со системи кои што се лесни за одржување, управуање и имаат голем потенцијал за понатамошно развивање на системот. [1] 1.5 Студии на случај и најчестите архитектонски шеми Неколку компанни имаат усвоено микросервисниот архитектонски модел за развој на нивниот бизнис. Подолу ќе се опишат некои примери на микросервиси кои што се општо прифатени од страна на компаниите. Табелатa ги содржи студиите и најчестите архитектонски модели што се користат. 22

23 студии патеки бенефиции Е-трговија Монолитни апликации со користење на NodeJS -Пократко време за лоадирање на страниците Фининциски сервиси Инкрементирано репрограмирање / Распаѓање на монолитни апликации креирани со NodeJS -Побрза испорака -Намалување на трошоците за пресметување -Овозможување креирање на софтверски решенија за мобилните телефони -Подобреност перформансите во Е-commerce discount site Ова компанија нуди намалени електронски купони кои што можат да се откупат од лоцалкните и национални компании. Истата првично е креирана како Ruby on Railѕ апликација, но како компанија постојано почнал да се прошири, почнувајќи да биди тешка за одржување, исто така се додавале и нови карактетистики. Компанијата го започнал едногодишниот проект за претворање на монолитната Ruby on Railѕ апликацијата во NodeJS. Во почетната фаза на трансформацијата фронтендот бил редизајниран и поделен во мали, независни парчиња. Секој голем дел од веб страната била изградена како независна NodeJS апликација. Тие изградиле Api слој во секоја бекенд платформа и мобилните клиенти биле поврзани во Api ендпоинтот врз основа на нивната географска локација. Во следната фаза, секоја главна карактеристика на вебсајтот бил поделен на посебни веб апликации. 23

24 Следнава листа ги вклучува некои од придобивките од трансформацијата Страниците се лоадираат побрзо Тимовите се помалку зависни Побрзо деплоирање на нова верзија Повторна употреба на функциите во тие држави каде што се користело е- трговија Financial services company Оваа американска компанија треба да го прошири еден од нивните основни системи за поддршка на нови надворешни партнери, нови пазари на глобално ниво и повеќе уреди. Моменталната конфигурација е монолитен и е создадено од следните компоненти: Презентациски слој: Околу 3270 екрани и веб слој (JavaServer Pages (JSP) и сервлети) Бизник логика IBM CICS, Common Business Oriented Language (COBOL) Извор на податоци IBM DB2, Virtual Storage Access Method (VSAM), Flat files Притоа некои од следниве предизвици го пренасочил компанијата да го модернизира системот: Тешко за одржување модифицирање Долги циклуси за објавување на нови верзии Проблеми во перформанските на системот 24х7 достапност и безбедносни прашања Оваа компанија одлучил поедниечна модернизација околу микросервисите за да се минимизира ризикот. Главната стратегија вклучува соживот на постојните модули и нови услуги за време на фазата на транзиција. Главната цел е распаѓање на тековната апликација кои што можат да се развиваат со текот на времето, независно еден од друг. 24

25 архитектура Притоа следните сет на заеднички услуги се потребни за поддршка на оваа Централен сервис за логирање Мониторирање на сервисите Компонента за следење на работата на системот Придобивките кои што се остваруваат со оваа архитектура се Флексибилност и полесен начин на проширување на компонентите Забрзување на развојниот циклус Намалување на трошоците Large brick-and-mortar retailer Постоечкиот систем за е-трговија не е дизајнирана за поддршка на мобилни платформи. Платформата за е-трговија е монолитна, дизајниран за консктурирање на веб страницата на сервер. Исто така постоечкиот проект односно систем бил при крајот на животниот век и поради тоа тимот одлучил да ја замени платформата со нова платформа каде што е поагилна за промени. Некои од причините за донесување на тавка одлука се и следните: Долго време за одговор Ниска присполобливост Високи напори за одржување и трошоци Високи потрошувачки ресурси ИТ тимот се одлучил на NodeJS како главна компонента и нов оркрестрациски слој за замена на постоечкото API. Во новата архитектура, NodeJS бил кореистен како прокси и оркестрациски слој. Притоа доколку новиот слој се справи успешно со промените потребни за корисниците, целата логика би била кодирана во NodeJS. Доколку се потребни повеќе трансфоpмации или калкукации, прокси слојот привремено би ги снабдувал корисниците со барање се додека не се креира новиот сервис со NodeJS. Со овој пристап се добиваат следните предности: 25

26 Миграција на поединечни услуги Повеќе контрола врз корисничко искуство, за отркивање на прекините на клиентите Поголема ефикасност заради кеширање Побрзо деплоирање, во споредба на традиционалните јава билдови 1.6 Сценарија каде што се користат микросервисите Подолу ќе се објасни различни видови на апликации и предности при вклулување на микросервисна архитектура во нив. Ќе се објаснат три апликации кои што ги користат микросервисните техники: Cloud Trader, oнлајн систем за трговија Online Store, онлајн продавница изградена со користење на облак услуга Acme Air, фиктивна апликација која се справува со резервација на летови, вклучувајќи ги податоците на клиентите, автентификација и багаж услуги Cloud Trader Оваа сценраио демонстрира како една монолитна јава апликација да се претвора во апликација што користи индивидуални микросервиси. Притоа сервисот ќе биде имплементиран во NodeJS. Таа исто така демострира како можат да се користат услугите на DevOps. Cloud Trader овозможува корисниците да можат да се логираат, да ги видат нивните портфолија да ги видат акциите и истите да ги споделат. Таа е монолитна апликација, каде што основната идеја е да се транфсормира во мали архитектурални компоненти. Во неговиот оргинален дизајн, таа е голема и тешко е да се додавааат нови функционалности. Исто така таа не е толку флексибилна за да користни различни сервис провајдери Online Store Оваа апликација содржи три различни микросервиси кои што се имплементирани во три различни програмски јазици. Online Store апликацијата користи Bluemix. Притоа 26

27 програмерите имаат право да го изберат оној јазик на кој што најмногу им одговара на нивните потреби. Истите се во можност да ја претворат апликацијата во мали архитектурални компоненти. Оваа овозможува секој микросервис да биде изградени и предадена многу брзо до клиентот. Слика 6: Монолитна - Микросервисна архитектура Секоја од индивидуалните компоменти на Online Store, Catalog, Order и UI претставуваат индивидуални компоненти. Севкупниот дизајн го намалува ризикот на апликацијата да биде нефункциоанлна. Но ова не значи дека во апликацијата нема да се случи никаква грешка, туку изградбата на апликацијата ја толерира грешката Кога апликацијата е скалирана во Cloud во повеќе различни инстанци и секоја со индивидуални компоненти, и ако едниот сервис не е функционален другиот сервис може да одговара на барањата. Притоа програмерите можат да работат независно во нивните индивидуални сервиси, и можат лестн да ги поправат грешките и да деплоираат нови верзии. Оваа сценарио ја истакнува флексибилноста која постои кога апликацијата е дизајнирана со помош на микросервисна архитектура: 27

28 Доколку Online Store има голем обем на сообраќај, можеби само каталог апликцијата треба да искалира. Доколку е потребно некоја друга заштита, истиот дел од апликцијата може да се смени без потреба од дополнителни барања од другите апликации Доколку делот за мобилните уреди треба да се програмира RESTful комуникацијата помеѓу компонентите го прави истот многу лесно за додавање на нов интерфејс Acme Air Acme Air е фиктивна авионска компанија која апликацијата треба да се гради со неколку клучни бизнис барања: Способна да одговори на милијарди повици во еден ден Истата треба да се програмира во Cloud Апликацијата треба да подржи повеќе канали за корисничка интеракција (мобилна и веб прелистувач) Сценариото демонстрира како може да се претвори една монолитна апликација за да користи индивидуални микросервиси. Истата покажува како да се прави мониторниг служба. Acme Air апликацијата ги опфаќа следните активности кои се однесуваат на една авиокомпанија: Летови Информации за сметката на клиентите Пореврка на автентификација Багаж услуги При конвертирање на монолитната верзија во микросервисна верзија, веб делот на апликацијата ќе работи со автентициран микросервис. Комуникациајта помеѓу микросервисите се прави преку RESTful повици. 28

29 Елементи на микросервисната архитектура Бизнис-ориентиран При поделба на системот на посебни услуги (сервиси), има голем ризик дека распаѓањето може да се изврши по постојните граници во рамките на организацијата. Ова значи дека постои потенцијал за системот да биде повеќе кревка, бидејќи постојат повеќе независни делови за управување, деловите кои што не се интегрираат како што треба, сепак меѓусебно можат да комуницираат. Понатаму доколку сервисот што го држи системот не е интегриран како што е опишано во целта, истата не може да се користи. Трошоците за програмирање и одржување исто така може да се зголеми доколку сервисите се дизајнирани надвор од организиционито и техлоношките граници. Слика 7: Стар стил на сервисниот дизајн Критично е да се дизајнира микросервис со крајна цел на бизнисот, во умот. Истата може да бара тимови во границите на организацијата да се здружат и да дизајнираат заеднички услуги, наместо користење на микросервиси за да се рутираат повиците помеѓу тимовите. 29

30 Во претходниот случај комуникациската структура на организацијата е имитирана во рамките на дизајнот на системот. Системот за нарачки не може да скалира, бидејќи секоја организација има своја активација и систем за управување со нарачките, секоја организација има свој поглед, корисникот и нема два дела на организацијата каде што еден корисник има ист поглед. Сервисите дизајнирани во претходното сценарио можат да бидат погодени од промените кои обично влијае на организацијата, како спојување, превземање и промени во мрежните уреди кои што се користат за испорака на услуги. Тоа не би било неразумно да се очекува дека таквата услуга се мери од страна на секој оддел со свој параметар на грешки и перформанси. Пристапот на микросервисите работи добро ако дизајнерите и програмерите од секој оддел на организацијата комуницира меѓусебно за дизајн на услуга за некој бизнис цел. На сликата 8 се покажува апликацијата редизајниран со микросервисна архитектура. [1] Слика 8: Редизајнирана апликација со микросервисна архитектура Во претходниот случај, крос-функционалните тимови заеднички се подготвуваат за да дизајнираат еден сервис за примање на нарачка. Така да при примање на една нарачка, 30

31 истата се запишува во база, обезбедување еден преглед на клиентот. По приемот нарачката се испраќа до сервисот за оркестар каде што го повикува секој индивидуален систем за нарачка. Поважното од актуелната системска архитектура е фактот дека дизајнот не ја имитира организацијата, технологијата или комуникациските граници. Сервисите исто така можат да издржат промени во организацијата (како нов продукт или услуги кои се додадено или нови аквизиции) и промени во бројот на вработени. Покрај тоа сервисите се изолирани во знак на поддршка на бизнис функција Дизајн за неуспех Софтверското инжинерство како една гранките на информатичкото општество може да зема повеќе примери од градежништвото каде што инжинерите се занимаваат со преоектирање, изградба и одржување на животната средина како што се патишта, мостови, канали, бранови и згради. Градежните инжинери дизајнираат такви системи каде што во секоја индивидуална компонента го пресметуваат степенот на грешката за да бидат истите постабилни и побезбедни. Истото може да се примени и во софтверското инжинерство. При тое не треба да се заборави на фактот дека грешките во системот се неизбежни меѓутоа еднистениот цел е да се задржи функционалност на системот да трае најдолго колку што може. Инжинерските практити, како моделирање на систем без никакви проблеми од хакертски напади треба да бидат вклучени како дел од континуираниот процес за да се дизајнираат по доверливи системи. Постојат неколку шеми на дизајн за грешки и стабилност. Неколку од нив ќе бидат објаснати подолу. Модел на прекинато струјно коло Моделот на прекинато струјно коло, најчесто се користи за да се осигура кога постои некој проблем, истото не вијае врз целовкупниот систем, односно системот ќе работи безпрекорно. Ова може да се случи доколку обемот на повиците кон неуспешниот сервис е голем и за секој нареден повик треба да се чека пред да се продолжи со обработката. 31

32 Праќање на повик кон сервисот што не функционира и чекање на одговор од него може да користи ресурси кои што го прават системот нестабилен. Слика 9: Прекинато струјно коло Моделот на прекинато струјно коло се однесува исто и како прекинатото струјно коло во домаќинствата. Повиците кон микросервисите се завиткани во струјно коло. Кога сервисот не функционира струјното коло овозможува некои подоцнежни повици да се извршат се додека системот не е целосно функционален. Оваа резултира со заштеда на драгоцени ресусри и одржување на целовкупната стабилност на системот. Кога патот на струјното коло е отворен и колото е отворена, логиката за заштита на системот при појавување на некоја грешка е стартувана. Истата логика има мала обработка или можи и да не прави никакви обработки бидејќи враќа вредност. Оваа логика не треба да биде нестабилна, бидејќи таа работи за да се одржи системот во добра кондиција. 32

33 Трупови Трупот на бродот е составен од повеќе поединечни недвосмислени прегради. Причината за ова е тоа што ако еден од преградите се оштети, оштетата останува во неа односно нема никакво влијание врз бродот. Овој вид на пристап може да се искористи и во софтверското инжинерство, за да се изолира грешката во малите делови од системот. Сервисот (всушност микросервисот) служи како преграда за да се изолира било какви грешки во системот. Поделбата во повеќе микросервиси исто така служи и за да се изолира ефектот на неуспех на системот. Слика 10: Користење на повеќе thread-ови, го намалува ризикот од неуспех Моделот на преграда исто така може да се примени и во рамките на микросервисите. Kако на пример доколку еден од сервисите поради некоја причина не ја изврши неговата функцијата како што треба, заради thread pool може да има негативни ефекти и врз другите системи. Поради оваа причина сите системи морат да имаат и свои thread pool-ови за да не се случуваат вакви грешки кои што можат да влијаат и негативно и врз корисничкото искусто. 33

34 2.1.3 Децентрализирано управување со податоци Во монолитните апликации, лесно е да се справи со трансакциите, бидејќи сите компоненти се дел од монолитот. Меѓутоа кога истата ќе се претвори во микросервисна архитектура, односно кога ќе биде дистрибуирана, тогаш можат да се појават проблеми со трансакциите. Во микросервисната архитектура, најбитно е BASE (Basically Available, Soft state, Eventual consistency) over ACID (Atomicity, Consistency, Isolation, Durability). Треба да се избегнат дистрибуирани трансакции доколку е возможно Идеално голем дел од софтверските инжинери сакаат секој микросервис да има своја база. Со ова се овозможува користење на различни бази (пример, CloudАНТ наспорти MongoDB, двата се NoSQL), и различни типови на бази на податоци (како Structured Query Language (SQL), NoSQL, графици). Сепак може да има потреба и повеќе микросервиси да користат иста база поради различни причини. Без оглед на причината, пристапот за споделувње на податоците преку микросервисите е добра идеја. Притоа мора да се има и во предвид дека истото може да има и позитивни и негативни страни. Споделувањето на базите на податоците не ги прекршува принципите на архитектурите базинари на микросервиси. Пример два микросервиси морат да комуницираат меѓусебно бидејќи ја споделуваат истата база. Така да промената во едниот микросервис треба да биде познато и од другиот микросервис Откриеност Како што е опишано претходно микросервисната архитектура бара изработка на сервисите сигурни и толерантни. Ова значи изградба на микросервисите на таков начин што сервисите ќе можат да се реконфигурираат со локациите на други сервиси кои што сакаaт да се поврзат во него. Со користење на Cloud Monitoring и контејнери за деплоирање на микросервисите, истите ќе можат да се реконфигурираат динамички. Притоа кога нова сервисна инстанца е креирана, останатиот дел од мрежата многу лесно може да се наоѓа и да се почне да се комуницира со него. 34

35 2.1.5 Интер-услуга комуникациски дизајн Кога микросервсиите се шират во повеќе платформи (сервери, виртуелни машини или контејнери), како ќе можат истите да комуницираат меѓусебно? За еднонасочните комнуникации, редици на пораки би било доволно, меѓутоа истата нема да работи синхроно односно при двонасочна комуницкација Во монолитните апликации, клиентите на апликациите, како и веб прелистувачите и мобилните апликации прават Hypertext Transfer Protocol (HTTP) повици до лоадбалансер, истиот е одговорен за безбедноста на системот. Но во микросервисната архитектура монолитот е заменет со колекција на сервиси. Едно сценарио е тоа дека клиентите на системот прават RESTful API (application programming interface) повици. [6] Слика 11: RESTful Api повици помеѓу клиент и сервиси Притоа голем број на клиентите можат да бидат несигурни, додека пак другите можат да барат повеќе повици за да ги добиваат потребните податоци. Бидејќи истите сервиси можат да се скалираат различно, има и други предизвици кои што треба да бидат адресирани како ракување со делумни неуспеси. 35

36 Меѓутоа подобриот пристап за клиентите би било да се прават повеќе повици, можеби само една, користејќи API Gateway. API Gateway-от се наоѓа помеѓу клиентите и микросервисите, и ги обезбедува APIјата кои што се прилагодени за клиентите. API Gateway-от воглавно се користи за криење на комплексноста во технологијата наспорти комплексноста на интерфејсот. Неформално еден API Gateway претставува фасада. Сепак фасадата обезбедува единствен поглед на комплексните, интерните и екстерните клиенти, од друга страна API Gateway-от обезбедува преглед на екстерните ресурси на интерните клиенти на апликацијата. Слично како и шемата на дизјанот на фасадата, API Gateway-от овозможува едноставен интерфејс на клиентите, со тоа им овозможува сервисите да бидат полесни за користење, разбирање и тестирање. Истата може да обезбедува и различни нивоа на грануларност на десткоп и веб прелистувачите. API Gateway-от обзебедува различни APIја за мобилните клиенти, различни за десктоп клиентите. Слика 12: Микросервис - API Gateway Во оваа сценарио, API Gateway-от го оптимизира разговорот со праќање на повеќе повици во еден повик за еден клиент (како на пример клиент што користи мобилен уред). Користот во ова е тоа што уредот се соочува со конекцијата на мрежата еднаш и после тоа 36

37 се поврзува со таа иста конекција за наредните повици а со тоа се добива помоќен хардвер од страна на серверот. Синхорнизирани HTTP во споредба со асихрони пораки Постојат две главни пристапи кон интерпроцесната комуникација Синхрони HTTP-базирани механизми, како што се (Representational State Transfer (REST), SOAP - каде што го држи отворен каналот помеѓу серверот и веб прелистуваот Асинхрони пораки користејќи брокер на пораката Синхроните пораки се едноставни и познати меганизми. Она што недостасува кај нив е тоа што немаат поддршка за другите модели, како објавување/претплата моделите. Стилот на објваување/претплата е пофлексибилен од точка-точка, бидејќи истата овозможува повеќе применици да бидат претплатени во протокот на пораките. Истата овозможува повеќе микросервиси да бидат додадени во апликацијата. Истата не дозволува барањата да чекаат ред за да се извршат. Асинхроните пораки ги раздвојуваат сервисите еден со друг, овозможувајќи thread-от за праќање на порака да работи, системот за пораката ја продолжува работата за порката, преземајќи ја одговорноста за да биде истата пратена во вистинската дестинација. Со синхроните апликации клиентот и серверот морат да бидат истовремено достапни, и клиентот треба да го знае хостот и портата на серверот. Во вакви типови на сценарии еден од механизмите за откривање на сервиси е потребен. Алтернативно асинхроните механизми користат брокери на пораки кои што ги раздвојуваат испраќачите и примачите. Брокерот на пораките ги баферира пораките, се додека примачот е во можност да ги процесира истите. Друг корист на пораките е тоа што бекенд апликациите можат да го дистрибуираат обемот на работи помеѓу повеќе клиенти. Ваков тип на сценраио овозможува програмерите да креираат скалабилни и респонсивни апликации. При имплементирање на еден или 37

38 повеќе инстанци од бекенд-worker апликацијата овозможува апликациајта да работи без чекање на бекенд апликацијата да заврши неговата работа. Постајат добри и лоши страни на двата пристапи. Меѓутоа повеќето од апликациите користат комбинација од двете пристапи. [7] Справување со комплексноста Микросервисната архитектура создава дополнителни ресусри за употреба на други операции. Има огромен пораст на подвижни делови и комплексност. Рационализацијата на однесувањето на секоја индивидуална компомента е лесна, меѓутоа разбирањето на однесувањето на целиот систем е потешко. Подесувањето на микросервисно-базираните системи кои што се состојат од огромен број на процеси, лоадбалансери и слоеви на пораки, потребно е следење со висок квалитет и голема инфрастурктура. Подолу ќе биде опишано некои главни точки за разбирање на комплексноста при микросервисната архитектура: Тестирање: Тестирање на комплексен систем бара многу интеграциони тестови и тестирање на фрејмворкот кои што ги симулира оние компоненти кои што не функционираат како што треба, стрес тестирање и однесувањето на целовкупниот систем. Со ваквите тестови се зацврстува коректноста на системот. Исто така она што треба да се нагласи е тоа што не треба да се извршуваат ваквите тестови во производство. Автоматизираните тестови кои со сила ги форсираат компонентите на распад, овозможуваат тестирање на целовкупната способност на системот и мониторирање на истиот. Мониторирање: Во прилог на конвенционалните системит за следење, добро дизајнирани сервисите можат да обезбедат дополнителни информации за состојбата на системот. На овој начин, информациите можат да бидат собрани од страна сервисот за следење, обезбедувајќи богати и здрави конфигурациони индикатори. Истите индикатори можат да се користат за да 38

39 се обезбеди дека сервисите кои што имаат доволно капацитет да ги служат барањата на клиентите. Сите овие информации собрани на едно место можат да се обработат и за се мониторираат во еден админ панел за да бидат достапни до сите кои што ја следат работата на системот. DevOps: За здржувањето на микросервисите во работна состојба потребни се да се има високи DevOps вештини во развојниот тим. Тимот треба да биди фокусиран во производот цело време. Polyglot programming: Идиоматичниот начин на упореба на микросервисите значи дека системот што се добива треба да биде полиглот. Како резултат администраторите на базите на податоците треба да бидат заменети со програмери кои што можат да деплоираат нови верзии и да оптимизираат nosql продукти. Особено главна точка овде претставува и квалификуваните програмери и нивните програмерски способности за одржување на софтверските продукти и дизајнирање на нови. Исто така треба да се нагласи дека голем број од организациите имаат краток список на програмски јазици кои што можат да ги користат, бидејќи има голем корист од повторна употреба на кодот Еволутивен дизајн Микросервисната архитектура овозможува еден еволутивен дизајн. Главната идеја е тоа што можат да се воведат нови карактеристики и можности во апликацијата само со менување на еден микросервис. Едноставно треба да се деплоира микросервисот кој што се менува, притоа промената може да се забгележи само кај корисниците што го користат тој микросервис. Микросервисите се мали фокусирани и лабави така да промената во истата може да се направи многу брзо и едноставно без никаков ризик. Притоа бидејќи микросервисите се мали и обично се дизајнирани, разработени и се одржуваат од страна на мали пица тимови типично истите можат да се препишуваат, повторно да се наградуваат и да се одржуваат. 39

40 Каде што може да се кажи дека ако бројот на микросервисите е голем во една апликација исто така и бројот на мали микросервиси ќе биде голем. И колку што е помал микросервисот толку лесно може истата да се деплоира и да се одржува Меѓутоа има еден недостаток бидејќи доколку има повеќе мали микросервиси, тогаш ќе треба повеќе време за нивно деплоирање а со тоа се зголемува ризик од пад на дел од системот или апликацијата. Принципот на микросервисите како и нивното независно деплоирање и оджување треба да се зема во предвид при одредување кој дел од системот треба да се претвори во микросервис, бидејќи доколку се процени нешто погрешно во овој дел, во иднина програмерите можат да имаат голема работа врз истот доколку се случи некој пад или неочекуван напад врз системот. [1] 2.2 Дизајнирање на микросервиси Еден од големите предности на микросервисната архитектура е слободата при донесување на одлуки за технологијата и големината на микросервисот по одделни сервиси. Меѓутоа како што е во животот колку поголема слобода толку поголема одговорност. Иако е точно дека многу опции за достапни, меѓутоа сите не се исти и треба да се внимава при донесување на одлука. Треба да се започни со јасно разбирање на микросервисот, а тоа се постигнува само со корисничко искуство Користење на дизајн на размислување Размислување за дизајнот е цел процес во кој што бара големо корисничко искуство. Наместо да се фокусира на функција треба да се фокусира во корисничко искуство (што луѓето мислат, чувстуваат). Размислување за дизајнот е корисно за определување на обемот на работа на одредени функции. Дизајнот ја олеснува идентификацијата на микросервисите. Размислување за дизајнот ги вклучува следниве концепти: Сценарио Приказна за корисникот 40

41 Спонзор корисници Идентификување на можностите на мирксоервсиите Ридови Hills Playback Приказни Ридови Ридовите обезбедува бизнис цел за временската рамка за пуштање на продуктот во продажба. Ридот дефинира кој, што и како сакате она да го достигнете. Еден тим обично идентификува три рида по проект и техничка основа. Со помош на ридовите, се спроведуваат решение што обезбедува корисничко искуство. Hills Playback Hill Playback обезбедува преглед на она што тимот ќе има за цел. Истата го поставува опсегот за одреден временски период. Таа е 0 кога тимот има завршено задачи што бизнисот му ги пребарува. Hill Playback се врши неделно со учество од кросфункционални тимови и спонзор корисниците кои се обидуваат да го извршат истото. Сликата подолу ја покажува временската рамка. Слика 13: Hills Playback Сценарио Сценариото всушност ја поставува приказната и конкестот користен во Hill Playback-от. Големи сценарија можат да бидат поделени во сцени и кориснички приказни. 41

42 Кориснички приказни Корисничката приказна е автономна каде што може да се развие во една или два дена, изразена во смисла на корисничко искуство како програмерот, сакам да најдам примероци и лесно да деплоирам истото во Bluemix и ќе можам да го пробам Приказни Приказните претставуваат група на прикази кој што можат да се користат повеќе пати низ сценраиото. Спонзор корисници Спонзор корисници се оние корисници кои се вклучени во рамките на проектот за да ги претстават важните личности на проектот. Тие се очекуваат да ги водат репродукциите. Спонзор корисниците можат да бидат и клиентот кои користаат апликации со микросервиси. Тие исто така можат да бидат и интерни програмери кои користат микросервисни алатки. Идентификување на можностите на микросервисите За секој дизајн треба да се идентификува потенцијалната повторна употреба на услугата од страна на другите дизајни. Притоа доколку се одлучи за деплоирање во Bluemix, тимот импленетира сервиси и функциски тестови на приказните во кои што микросервисот ги користи. Сервисот вклучува логирање на податоците. Со ова се овозможува да се измери бизнис влијанието на услугата што треба да се обезбеди Избор на начинот за имплементација Како што е опишано претходно микросервисите се составени од индивидуални сервиси кои што се извршуваат како одделни процеси, очигледно е да се очекуваат надлежни технологии способни за поддршка на комуникацискиот протокол како HTTP REST или messaging protocol како MQ Telemetry Transport (MQTT) или Advanced Message 42

43 Queuing Protocol (AMQP). Сепак треба добро да се разгледа при изборот на начинот на споредување на процесот на имплементација: Синхрони наспроти асинхрони. Класично како што е Java платрофмата (Java EE), работи со синхроно блокирање на барањата на мрежата. Како резултат на тоа мора да работат во различни thred-ови за да бидат во можност да се справуваат си сите сите повици. Асинхрониот пристап може да процесира мовеќе повици, каде што при ракување со нив бара iınput/output(i/o) операции. И/О наспроти процесорска поврзаност. Решенијата како NodeJS се добри за микросервисите кои претежно се занимаваат со (I/O) операции. NodeJS обезбедува начин за чекање за (I/O) повиците за да се завршат без притоа да се блокира цел thread. Меѓутоа доколку микросервисот врши операции што траат многу долго, тогаш едни од двете понудени опции треба да се извршат o Имплементирање на сервисот за MultiThreading o Изршување на сет операции за оптимизација на работата на процесорот Меморија и барања за процесорот. Микросервисите се секогаш изразени во множина, бидејќи се извршува неколку а не еден. Постојат повеќе процеси за справување притоа процесорскиот и меморискиот капацитет се едни од најбитните параметри при оценување на трошоците на целовкупниот систем. Традиционалните Java ЕЕ Stack-овите не се погодни за микросервисите од оваа гледна точка, бидејќи тие се оптимизирани за водење на единствена апликација. Сепак NodeJS и Go како нови технологии се поатрактивни при користење на микросервисите бидејќи бараат помала процесорска моќ и меморија. Теоретски можат да се креираат микросервиси, каде што секој сервис користи различен пристап. Во повеќето од ситуациите, тоа не е препорачливо. Економијата на подем, кодот и програмерските вештини го лимитираат овој број на

44 Во повеќето од микросервисните системи програмерите користат NodeJS микросервиси за сервирање на веб страни заради големиот афинитет на NodeJS каде што се користи Javascript при работа на веб прелистувачот. Истите користат добри платформи (Java, GO) за градење на бекенд сервисите. Меѓутоа повеќе од два пристапи не е препорачливо за користење. Сепак постои можност за испорбување на пристапи при развојот на микросервисната архитектура при определување на точниот начин за имплементација Определувањето на големината на микросервисите Еден од најпознатите фрустрирачки и непрецизни задачи при креирање на микросервисна архитектура е донесување на одлука за бројот и големината на микрсервисите. Не постои строго правило во оптимална големина, но постојат некои практики кои се докажани во досегашните имплементирани системи. Неколку техники можат да се користат сами но некои можат да бидат и во комбинација со други: Број на датотеки. Големината на микросервисот во системот може да се измери со помош на бројот на додадени фајлови. Меѓутоа истата може да биде и непрецизна. Големите сервиси се тешки за работење, тешки за деплоирање за стартување и за стопирање. Меѓутоа кога микорсервисите се мали (често познати како наносервиси), цената за ресурите за имплеметирање и финкционирање на такови сервис фрла сенка врз нејзиниот корист. Иако честопати микросервисите се споредуваат со Unix дизајнот, подобро е да се стартуваат со големи сервиси бидеќи големиот сервис секогаш може да се подели во две нови мали сервиси Премногу одговорности. Сервисот кој што цело време работата на процесорот е во највисоко ниво, е тешка за тестирање, одржување. Иако сите повици се REST, сепак не е препорачливо да се одржува. Тип на сервис. Добро правило е дека микросервисите треба да прават една работ на пример: 44

45 o Проверка на автентификација o Сервирање на REST повици o Сервирање на веб страни Гранична поделба на контекстот. Ова правило е особено важно кога веќе постоечки систем е поделен во микросервиси. Името доаѓа од моделот предложен од Мартин Фаулер. Тоа претставува дел од системот кои се релативно само-доволни, така што постојат неколку врски за да ги прекине истите да се претворат во микросервиси. Ако микросервисот треба да се комуницира со 10 други микросервиси за да ја заврши неговата задача, тоа значи дека моделот не е смислено како што треба. Тимска организација. Не е тајно дека многу микросервисни системи се организирани во повеќе тимови одговорни за пишување на код. Впрочем на тоа еден од клучните причини за популарноста на микросервисите е архитректураната и организационата шема со која тимовите можат да програмираат да планираат и да деплоираат нови верзиите од апликациите. А со тоа може да се нагласи дека бројот на микросервиисте е тесно поврзан со организациониоте и техничките принципи на тимовите На крајот може да се каже дека добро дизајниран микросервисен систем ги користи комбинација од сите горенаведени правила. Истите бараат висок степен на организационираност со кои се стекнува со текок на времето и искуството во системот. Меѓутоа она што е препорчливо е дека на почеток доколку програмерите го немаат искуството со микросервисите, треба да започнат со мали микросервиси. Исто така во еден добро дизајниран систем, реорганизацијата на системот може да се изврши без прекин. Онаму каде што еден микросервис опслужува две патеки, две нови микросервиси можат да послужат по една патека за секоја од нив. Поуката во оваа е тоа што дизајнот на микросервисниот систем е приказна кој цело време е во тек. Тоа не е нешто што мора да се направи се одеднаш. [1] 45

46 2.3 REST API и пораки REST REST е архитектурален стил за мрежните апликации, во главно за користи за креирање на веб сервиси кои што се лесни, одржливи и скалабилни. Сервисот кои што е базиран врз REST се нарекува RESTful сервис. REST не зависи од било кој протокол, меѓутоа речиси сите RESTful сервиси користат HTTP како основен протокол. REST-от често за користи за веб апликациите како начин за комуникација на ресурсите за размена на информации. Доколку се смета веб како апликациска платформа, REST овозможува апликациите да бидат сврзани заедно и да бидат скалирани (прилагодени) и да обезбедат функционалност помеѓу сервисите. Во текот изминатата деценија, REST-то бил појавен како доминантен модел за веб сервиси и речиси сите поголеми јазици го вклучуваат framework за создавање на RESTful веб сервиси. REST API-то воспоставува мапирање помеѓу CREATE, READ, UPDATE и DELETE операциите, како и соодветни POST, GET, PUT и DELETE HTTP повици. [2] RESTful интерфејсот е фокусиран во улогите на компонентите и ресусрите, истата ги игнорита нивните внатрешни импленетациони детали. Интеракцијата треба биде независна, бидејќи повиците се пренесуваат помеѓу клиентите и сервисите. Сликата 14 ја покажува REST архитектурата Слика 14: REST Архитектура 46

47 Како што е прикажано на сликата еден или повеќе proxy или gateway можат да постојат помеѓу клиентот кои што бара информации и серверот. Одговорот од серверот исто така има свој механизам. Притоа добро-дизајниран систем за кеширање ја подобрува скалабилноста и перформанските на RESTful сервисот. Бидејќи REST-от е дизајниран како повик/одговор моделот, доколку одговорот не е достапен, апликацијата мора да прави уште еднаш повик до серверот Пораки Во денешно време пожелно е да се имплементира микросервисна архитектура за повеќе сценарија. Оддалечувањето од монолитните апликации во коалиција од мали апликациите бара начин за исите мали дискретни микросервисите да комуницираат меѓусебно. Притоа ова е местото каде што пораките можат да помогнат. Пораките се критични компоненти во светот на програмерите, тие овозможуваат програмерите да го претвораат нивните апликации во мали компоненти и лабаво поврзување на истите. Пораките подржуваат асинхрона спрега помеѓу компонентите, со пораките пратени користејќи message queueus. Ваквиот модел (објави/претплати) на пораките ги намалува непотребните врски и мрежниот сообраќај помеѓу апликациите. Наместо да се користат чести REST повици, апликацијата ќе биде во мирување додека пораката е пуштена до сите потребни корисници. Во тој момент клиентот ја прима порката. Во суштина, наместо да се користи REST таму сме уште повик, корисниците добиваат друга порака при што се покажува дека пораката што му е потребен ма корисникот е достапен. Во (објави/претплати) топологијата, најпрвин клеинтот испраќа порака до некоја дестинација, често пати тоа е стринг. Способноста на клиентот да ја пушти пораката не зависи од дестинациската апликацијата. Во било кое време, претплатникот (оној што ја прима пораката) може да е недостапен. Брокерите на пораката можат да ја задржат пораката се додека претплатникот е во состојба да ја прими истата. Нивото на сигурност на примената порака е управувана од страна на QoS. 47

48 Една од најзначајните предности при користење на пораки message queueus е карактерситиката раст. Така што апликацијата од една едноставна мала може да се претвори во голема апликацијата со низа на нови карактеристики. Притоа со зголемување на комплексноста на апликацијата програмерите бараат лесен начин за да ги додаваат истите карактеристити во тековната апликацијата, но без нарушување на концептот на работната апликација. Како што е опишано подолу со помош на пораките можат да се одвојат компонентите на апликацијата, со тоа карактеристиките на новата апликација може да се запише за користење на пораките како алатка за комуникација со постојната апликација, и не бара промени или прекин на главната апликацтија при додавање на нова функционалност. Алтернативно, големите компани можат да имаат големи монолитни апликации кои што сакаат да ги прошират нивните претпријатија со нови интеграциони системи. Притоа пораките може да биде како инструмент во интегрирање на постоечкиот систем со нови карактеристики, со овозможување на комуникација помеѓу двата без потреба да бидат од апликациите да бидат во работна состојба или напишани во ист јазик. Многу постоечки системи веќе можат да интегрираат еден тип систем за праќање на пораки. Заради тоа оптимален дизајн за нови микросервиси би било оној систем кој што може да биде врзан со постоечкиот систем и да комуницира со постоечкиот систем за праќање на пораки.некои заеднички имплементациски сценaрија за користење на пораки би било известувањата за настаните како што е прикажана на сликата 15. [8] Слика 15: Употреба на пораките 48

49 На пример, апликацијата за некоја продавница објавува надградба на цените на производите со помош на извествуање на настаните. Притоа корисниците не праќаат индивидуално пораки до серверот, тие едноставно само имаат означено продуктот што сакаат да добиваат известувања за промените на цените. Притоа кога продавницата ќе ги пушти промените известувањата стигнуваат до корисниците индивидуално без никакви барање од серверот. Друг пример на пораки можат да бидат и веб апликациите, кои што треба да процесираат одредена работа пред истата да биде респонсивна (адаптивна) на корисниците. Доколку една апликација има голема интензивна работа, истата може да биде дистрибуирана во повеќе независни процеси кои што работаат асинхроно. Неколку инстанци од бекенд апликацијата може да работи, овозможувајќи на веб апликцијата да прати барање за процесирање од еден до неколку апликациски инстанци за работа. Слика 16: Известување на настан за цената на акциите 49

50 Пораките исто така помагаат и при имплементација на сценарио каде што доколку има големо оптоварување, дополнителни воркер апликации можат да бидат креирани без потреба од менување на веб апликацијата. Со помош на пораките апликациите стануваат по флексибилни со додавање на микросервисите за процесирање на асинхрони повици. При додавање на систем за пораки во микросервисниот дизајн, може да биде корисно и при случај кога едниот од системите не е во функција. IBM MQ Light сервисот во Bluemix целосно менаџира Cloud сервис, каде што сите оперативни активности како одржување, достапност и надградби, сите се дел од Bluemix сервисот. IBM MQ Light нуди различни квалитетни сервиси REST и пораките заедно REST и пораките можат да се дополнуваат едни со други. Во некои случаи може да биде оптимално да се комбинираат REST со апликации кои користат системот за пораки. REST-от може да преставува проблем кај оние сервиси каде што имаат зависност со податоците кои што не ги поседуваат и не ги управуваат. За податоците во реално време, пожелно е да се испраќаат податоци кои што се менуваат, а не да се прашува (да нема гласање) дали нешто е сменато. Притоа во овие ситуации протоколот со пораките (MQTT или AMQP) може да биде покорисно од REST-от. Кога некоја апликација користи моделот на барање/одговор поврзан со RESTful сервисите, невалидната врска може да значи дека не постои некаква соработка. Слично на тоа што ако брокерот на пораката не е достапен? Во тој случај пораките нема да бидат доставени. За да се заштити нарушувањето на системот за праќање на пораките, конфигурацијата не треба да се имплементира. Исто така апликациите можат да се скалираат така да можно е да има повеќе инстанци од една апликација и доколку едната не функционира другата може да ја презема одговорноста. Во повеќето од случаевите, микросервисите мораат да знаат кога се случува промената без гласање. Меѓутоа комбинирањето на REST-от со пораките може да биде 50

51 моќна комбинација. Истата може да помогни при зголемување на динамичноста на системот и неговата одржливост. При праќање на повиците до корисниците, обврската за чување на податоците се преминува во примачот. Складирањето на податоците во примачите им овозможува истите да бидат самостојни и еластични. Тие можат да работат дури и ако има некој прекин со испраќачот на пораката. Во дизајнот каде што сервисите се истовремено поврзани со брокерот на пораката, API сервисите испраќаат порака за промена на податоците и во овој момент клиентите кои се поврзани со таа информација можат да реагираат при примање на пораката. При користење на пораките како замена на REST-от, клиент сервисите немаат потреба од чување на податоците. Тие сеуште ќе треба да ги пратат основните податоци добиени преку REST повиците. Пораките кои што ги користат испраќачите и примачите, овозможуваат користење на разделувачи на структурата, коса црта ( / ), како начин за синхронизирање на REST адресите и темите, овозможувајќи преслукување на REST-от и пораките. За да се изврши истото без гласање, со користење на типичен ендпоинт линк како тема на пораката, овозможува друг микросервис за биде претплатен во таа тема и да прима информации при некоја промена. Доколку се користи REST API и се додаваат пораки за REST ендпоинтот кои дава некој резултат (POST, PUT или DELETE), еден HTTP GET повик може да се користи за преземање на одредени ресурси. Со оваа техника можат да се намалат REST повиците и притоа апликацијата ќе биде цело време ажурирана. 2.4 Иднината на микросервисите Денеска има голема возбуда околку микросервисната архитектура. Идејата за модерна системска архитектура која може да се подели во помали сервиси денеска се користи од страна на голем број на компаннии. Програмеритe деплоираат само сервиси на кои што им е потребно, истите ги ажурираат многу лесно и додаваат нови инстанци. 51

52 Меѓутоа оваа нова технологија како што има големи предности исто така има и некои недостатоци кои што микросервисите не можат да ги решаваат, истите бараат посебно внимание: Неправилни барања. Доколку се започнува со грешни барања, не е важно колку брзо се деплоира или се скалира системот Забележително користење на ресурсите. Како што беше објаснато погоре, монолитните системи веќе се по малку се користат, наспорти тоа се креираат се помали сервиси кои што бараат повеќе ресурси за работа. Потребни значителни DevOps вештини. Предизвиците за водење на микросервисите и држење во работна состојба бара високо-квалитетни DevOps вештини и автоматизираност при работа на програмерскиот тим. Имплицитни интерфејси. При поделба на монолитниот систем во повеќе сервиси, воедно треба да се воведуваат нови интерфејси помеѓу нив. Секој од интерфејсите бара одржување, исто така и компатибилност со претходните верзии. Водечките практики укажуваат дека секој интерфејс е третиран како строг договор, а во дистрибуираниот свет не е лсено да се задржат договорите низ изданија кои се регулирани некогаш и со спротиставени бизнис потреби. Во иднина се очекува да се видат стандардите за опишување на микросервисите. моментално можат да се користат повеќе технологии при креирање на микросервисите, JavaScript Object Notation (JSON) или Extensible Markup Language (XML) преку HTTP за да се обезбеди REST API. Овие стандардите можат да обезбедат упатства за тоа како да се опише, одржува или да се откаже од микросервисна архитектура Со текот на времето, наместо да се раздвојат слоевите на архитектурата, треба да се фокусира во креирање на концептуални сервисни граници и повеќе процесни граници. Организациите стануваат попаметни во решавање на законот на Конвеј и ќе се воспостави крос-функционални тимови кои што работаат во одделни микросервиси, достапувајќи иста деловна способност во склопот на претпријатието. 52

53 3. Микросервиси и DevOps DevOps DevOps претставува множество на концепти, практики, алатки и тимска организацниона структура кои што овозможува побрз начин на креирање на апликации за клиентите. Организациите кои што се напраени со DevOps се многу полесни за мониторирање на нивните микросервиси. Истите можат брзо да им одговараат на новите барања а исто така и за проблемите кои можат да се јавуваат во продукција. DevOps вообичаено ги вклучува следните процеси: Агилни практики Континуирана интеграција Автоматизација при објавување на нови верзии Функционална единица за тестирање Тестирање на системската интеграција Мониторирање на услугите и инфраструктурата DevOps е предуслов за успешно усвојување на микросервисите Како што монолитните апликации постепено се распаѓаат и се претвораат во платформски сервиси и вертикални сервиси, компаниите веќе нема да имаат потреба од само еден тим за билдање, деплоирање и тестирање на апликацијата. Со микросервисната архитектура се зголемува бројот на мали апликации (микросервиси) кои што се деплоираат. DevOps е она што овозможува да се направат повеќе деплоирања и да се има повеќе тимови при креирање на нови микросервиси. DevOps е предуслов за да се биде во можност да се донесе успешна микросервисна архитектура во организацијата. Тимовите кои не се адаптирани во DevOps треба да поработат значително во процесите на автоматско деплоирање на верзии и нивно одржување. Ова е начинот на ефикасна работа на тимовите при тестирање и објавување на микрсервисите. Без него секој микросервисен тим мора да креира своја DevOps инфраструктура и сервиси, кои што резултира во повисоки трошоци за развој. Тоа исто така 53

54 значи и неконзистентни нивоа на квалитет, безбедност и достапност на микросервисите помеѓу тимовите Организирање на тимовите за поддршка на микросервисите Обично постојат две нивоа за имплементирање на микросервисите, за големи организации или за покомплексни апликации постојат и повеќе нивоа. Тимовите се усогласени околку деловните функции и ги поседуваат сите фази на животниот цилкус во апликацијата: Барање Тестирања Деплоирање Оперативно следење на услугата Организирање на тимовите за поддршка на други микросервисни тимови При почнување со реорганизација на тимовите со бизнис компонентите и сервисите, исто така треба да се креирааат и микросервисни DevOps тимови кои што ги обезбедуваат оние кроси-функционални тимови со алакти за поддршка, следење на зависност, управување како и видливост во сите микросервиси. Оваа работа на бизнис и техничките чинители им овозможува поголема видливост и микросервисните инвестиции. Мали, фокусирани, автономни тимови овозможуваат компаниите да бидат фокусирани во способноста на основните услуги кои што можат да биде независно распоредени. DevOps сервис тимот овозможува преглед на сите сервиси кои што се деплоирани, користени од другите тимови и тие што се користени од страна на клиентите. 3.2 DevOps можности за микросервисната архитектура DevOps го остварува целта за континуирана испорака кои што се потребни за микросевисната архитектура преку своите пристапи: Автоматизација 54

55 Стандардизација Обајвување на нови верзии Како што е прикажана на слика 17 секоја од точките е автоматизирано со пристапот на DevOps. Автоматизацијата почнува со обезбедување на инфраструктурата и конфигурација на платформата. Ова е проследено и со автоматизација при деплоирање на апликацијата, менување на базата и други апликациски конфигурации. На крај максималниот корист при користење на пристапот на DevOps се добива преку автоматизација на тестовите како системско интеграциони тестови, Unit тестови и кориснички тестови. Слика 17: DevOps пристап кон развој на софтвер: Континуирана испорака Аспектот на стандардизација во DevOps може лесно да се измеша со флексибилноста која микросервисната архитектура обезбедува во врска со технологијата и чување на податоците. Во DevOps стандардизацијата за намалување на ризикот се однесува на следните фактори: Користење стандардни платформи Сигурни и повторливи процеси Високо ниво на доверба при објавување на верзија Честите објавувања на нови верзии од апликациите може да ги задоволува барањата на бизнисот. Оваа исто така знали мали промени во кодот и го намалува ризикот од 55

56 појавување на некои грешки во системот. Со честите објавување на верзии исто така лесно можат да се најдат и грешките во кодот при процесот на развивање на апликацијата. Сите овие карактеристики на DevOps се дел од важните процеси при развивање на микросервисите. IВМ DevOps framework-от се однесува на континуирана испорака преку серија на континуирани чекори. Неколку заеднички точки кои влијаат на традиционалните софтверски решенија, како што е прикажана на сликата 18, се избегнуваат во користење на DevOps при развој на микросервисите. Слика 18: Заеднички предизвици со традиционални софтверски испораки IBM Bluemix DevOps сервисите претставуваат софтвер како сервис (Saas) во Cloud кој што поддржува континуирана испорака. Со помош на IBM Bluemix DevOps сервисите, лесно може да се деплоира, да се следи процесот, да се планира и да се деплоира софтверот на едно место. Така да преку проектот може да се пристапи до се што е потреба за билдање на различни типови на апликации. За поедноставна тимска работа можат да се користат алактите за соработка. По билдање на апликацијата, истата може да се деплоира во IBM Bluemix Cloud платформата. За неколку минути можат да се креираат апликации. 56

57 IBM Bluemix DevOps сервисите ги обезбедуваат следните услуги: Агилно планирање, преку услугата Track & Plan Веб интегрирана развојна околина (IDE) за уредување и управување со изворниот код Верзионирање на апликацијата преку Git, Jazz SCM или GitHub Автоматсо билдање и деплоирање преку Delivery Pipeline service [1] Континуирано бизнис планирање Континуираното бизнис планирање, исто познато како континуирано управување, помага при постојано планирање, мерење и донесување на многу важни бизнис стратегии и одлуки. Истата обезбедува и алакти и практити за да им помогне на организацијата за да ги изврши коректните активност: Предвидување и мерење на резултатите и ресурсите Учење за тоа што им е потребно на клиентите Управувач со агилност Континуираното бизнис планирање овозможува со помош на мали сервиси да се предвидат резултатите од работата што ќе биде извршена и со тоа да се превземат соодветни мерки. Континуираното бизнис планирање ги има следнте предности: Помага при континурано планирање на бизнис потребите и нивно приоритизирање Интегрирање на реакциите на клиентите со бизнис стратегијата Фокусирање во точни работи Приоритизирање на бизнис потребите кои што имаат најмногу вредност Некои од најчесто користените алатки во индустријата се: IBM Rational Team Concert IBM Rational DOORS Next Generation 57

58 Collaborative Lifecycle Management as a service (CLMaaS) JIRA Kanboard.net Континуирана интеграција и соработка за развој Континуираната интеграција се однесува на водечката практика за интегрирање на кодот на целиот тим, за да се потврди дека работи добро како што треба. Континуираната интеграција е практика кој што бара членовите на тимот да ги интегриаат нивните работи почесто. Интеграциите се верифицираат со автоматските билдови кои што извршуваат тестови за детекција на грешки колку што е можно. Притоа доколку има одреден проблем во кодот тимот веднаш реагира и започнува процесор на програмирање. Соработката за развој овозможува соработка помеѓу бизнис, развој и Quality Assurance (QA) организациите, за донесување на иновативни софтверски решенија. Оваа исто така вклучува поддршка за полиглот програмирање, мулти-платформски начин на деплоирање, елаборација на идеи и креирање на кориснични приказни. [1] Соработката за развој исто така склучува и практиката за постојана интеграцијата, кој промовира честите тимски интеграции и автоматските билдови. Со честите интеграции на системот, интеграционите грешки можат да се идентификуваат многу рано и истите се полесни за решавање. Целовкупниот интеграциски напор се намалува со користење на континуирани повратни информации, со тоа проектот покажува постојат раст и напредок. Континуираната интеграција ги има следниве предности: Секој програмер интегрира дневно, што додевува до повеќе интеграции на ден Интеграциите се верифицирани со автоматските билдови кои што се извршуват за пронаоѓање на грешките во кодот Соработката за развој ги има следниве предности: Ги здружува клеинтот и ИБМ тимот за разговор на она што му е потребно на клеинтот 58

59 Фокусирање во постигнување на бизнис исход Користење на заеднички алатки и платформи Долната листа ги опишува некои од најчестите индустриски алатки и придонеси во цонтинуираната интеграција и соработка за развој: Rational Collaboration Lifecycle Management Rational Lifecycle Integration Adapter Rational Developer for System IBM Worklight Studio IBM UrbanCode Build Git Jenkins Gerrit Bugzilla Континуирано тестирање Континуираното тестирање ја намалува цената на тестирање, а истовремено им помаѓа на развојниот тим во брзина и квалитет. Истата ја елиминира тесните грла преку виртуелно зависните сервиси и поедноставува начинот на креирање на виртуелизирани тестни средини, кој што лесно може да се деплоираат нови верзии да се ажурираат и да се поделат. Овие способности ги намалуваат трошоците за обезбедување и одржување на тестните средити. Како придобивки на континуирано тестирање можат да се набројат: Избегнување на неочекувани прекини во бизнисот Посигурни апликации Помалку работа Поефикасни и посреќни работници 59

60 3.2.4 Континуирано деплоирање Континуираното деплоирање претставува серија на практики дизајнирани за обезбедување на кодот кои што лесно и безбедно може да биде објавена во производство. Бидејќи сите промени на кодот се наоѓаат во Cloud, програмерите треба да имаат доверба дека апликацијата може да биде деплоирана со едно копче. Континуираното деплоирање обезбедува систем кои што го автоматизира тестирањето и објавување на новите верзии. Притоа неспоредливо е времето потрошено при автоматско и рачно деплоирање-тестирање на верзии. Следната листа ги вклулува некои од најчести индустриски алатки и придонеси за континуирано деплоирање: IBM UrbanCode Deploy with Patterns IBM UrbanCode Release Chef Puppet Juju Docker Ansible Salt Континуирано мониторирање Континуираното мониторирање нуди претприемачка класа, лесна за користење кои што им помаѓа на програмерите да тестираат и да добиваат информации за перформансите и достапноста на апликацијата. Известувањата пред да се случат грешките се многу битни, таа помаѓа при справување со грешките и промените исто така и за управување со проектот како и еден од клучните алатки за постигнување на успех во бизнисот. Во производство, операцискиот тим управува и гарантира дека апликацијата работи како што треба и работната средина е стабилна со негово контунуирано следење. Иако OPS тимот има свои алатки за мониторирање на нивните срединит и системи, DevOps 60

61 принципите исто така ги мониторираат и апликациите. Тие треба да бидат осигурени дека апликациите работат на оптимално ниво. Со тоа може да се заклучи дека OPS тимовите користат алатки што можат да мониторираат пеформанските на апликацијата и грешките. Исто така потребно е да изградат и свои посебни анализи кои што директно ќе можат да ги користат во апликациите при билдање. Континуираното мониторирање ги има следните предности: Водечка практика при менаџирање на инфрастурктурата, платформата и апликациите за да се обезбеди нивно правилно работење Логовите при мониторирање исто така можат да се користат за операциони анализи Програмерите ги добиваат анализите во живо Секакви известување при голема преоптовареност Овој сервис може да се користи во различни апликации (програмирани во различни јазици) како IBM Liberty, Node.js и Ruby. Овој сервис исто така нуди и разни дополнителни можности покрај собирање на логовите. Меѓутоа логовите можат да се видат само за последните 24 часа. Затоа доколку се потребни логовите и по стари од 24 часa тогаш потребно е да се користи некоја трета апликација. Исто така едни од најзнајачните придобики е тоа што може многу лесно да се пребарува на назад во историјата од логовите. Следната листа ги вклучува неки од најчестно користените алакти при континуирано следење на системите: SmartCloud Application Performance Management (APM) IBM Service Engage Nagios Nmon Cacti Logstash 61

62 Fluentd New Relic [1] Континуирани повратни информации од клеинтот и оптимизација Ефикасниот DevOps овозможува побрзи повратни информации. Континуираните повратни информации и оптимизацијата дава визуелен доказ и целовкупниот контекст да се анализира од страна на корисникот, односно тестирање на корисничкото искуство со помош на мобилните и веб апликациите Експериметирањата, учењето од прва рака преку клеинтот и континуираните повратни информации се многу критични аспетки за успех на бизнисот. Целта е по прав пат да се овозможи едниот од тимовите да иновира, а другите да останат поврзани со тимот за евиденција на податоците и трансакциите во живо. Наоѓање на оваа рамнотежа и модел на кој работи е од суштинско значење. Континуираните клиентски повратни информации и оптимизацијата обезбедува следниве предности: Обезбедува клеинтот да биде способен да добие увид со интуитивни известувања оптимизирани за веб, мобилни уреди и социјални канали Брз увид во надградбите Зголемени конкурентни предности Обезбедува важна повратна информацијата на клиентот со користење на апликацијата во живо Следната листа ги вклучува некои од најчесто користените алатки во индустријата за повратни информации од страна на клиентите: IBM Tealeaf Customer Behavior Analysis Suite IBM Digital Analytics Mobile First Quality Assurance Open Web Analytics (OWA) Webalizer 62

63 W3Perl 3.4 DevOps способности: Тестирање на стратегии за микросервисите Микросервисната архитектура се смета за еден еволутивен начин за креирање на ИТ системи, кој што доаѓа со неколку предности. Сепак тоа исто така претставува еден вид на типичен предизвик, кои што можат да се претворат во големи проблеми доколку не се решаваат соодветно. Тестирањето се смета како еден од најзначајните предизвици во еден ИТ систем. Подолу ќе биде објаснато следнте црти: Методи за тестирање Креирање на стратегии за тестирања Значителен методи на тестирање Како едни од најкористените методи за тестирања можат да се набројат следнте: Unit тестирање Интеграционо тестирање Компонентно тестирање Контракт тестирање Крај до крај тестирање Перформанс тестирање Unit тестирање Unit тестовите во микросервисите се прилично исти како и во другите системи, истата може да се разбере како најмал дел од тстираниот софтвер за да се утврди дали тоа се однесува како што се очекува. Иако не постои точна дефиниција за тоа колку големи треба да бидат софтверите за да се изврши unit тестовите, типична единица за да се тестира треба да ги има следните заеднични елементи: 63

64 Единицата е едно парче од најниското ниво на системот и се фокусира на специфичен мал обем на системот. Тоа може да биде класа на код, некоја функција или група на функции. Тестирањето против единицата треба да биде значително побрзо од сите други видови на тестови Скрипата за unit тестирање е напишана од страна на програмери кои го градат кодот кој што е во фаза на тестирање Оваа тестирање е местото каде што се очекува да се најдат најмногу грешки во системот, и тоа е еден од најлесто користените тестови во споредба на другите тестови. Примарната цел на unit тестирањето е да ни даде брза повратна информација за тоа дали кодот што се тестира е во добра состојба. Овој тест исто така е критичен во code refactoring активностите, каде што малите тестови можат да се докажат навремено за да обезбедат квалитет при реконструктирањето на кодот за развој. Unit тестирањата исто така претсавуваат еден тип на тест-воезење (се користи за добивање на брзи информации уште од почетокот). Слика 19: Хиерархиски приказ на тестирањата 64

65 Интеграционо тестирање Интеграционото тестирање е метод на тестирање кои што собира соодветните модули заедни и ги верифицира истите дека работаат како што се очекува. Интеграционото тестирање ова го постигнува преку комуникациски патишта помеѓу соодветните модули за откривање на било какви погрешни претпоставки кој што секој модул го има. Во микросервисната архитектура, оваа тестирање типично се користи за верифицирање на интеракциите помеѓу слоевите на интеграцискиот код и некој надворешен компонент што треба да се интрегрира во него. Надворешните компоненти можат да бидат база на податоци или некои други микросервиси. Интеграционото тестирање на базите на податоците или екстерните компоненти гарантира тека шемата што се користи од страна на кодот се совпаѓа со вистинскиот од надворешната база. Во повеќе случаеви објектно-релационите техники за мапирања се користат за претворање на податоците. Исто така податоците можат да се чуваат и во различни сервери кои што можат да предизвикуваат и одредени каснења и тешкотии при воспоставување на конекцијата. Интеграционото тестирања може многу лесно да ги најди сите вакви грешки што можат да се случат во системот. Другиот важен надворешен интеракциски тест е тестот против комуникацијата помеѓу два микросервиси. Многу често, прокси компонентата се користи за да се капсулира пораките кои што поминуваат помеѓу двата оддалечени услуги, барањата и одговори од и до модулите кои што всушност ги процесираат барањата. Proxy-то обично е придружена од страна на клиентот кои што го разбира основниот протокол за да се справи со циклусот барања-одговор. Интеграционото тестирање во овој случај треба да открие било каква грешка во протоколот, како непостоење на Secure Sockets Layer (SSL), непостоење на HTTP хедери или неусогласеност на телото на барањето-одговорот. Справувањето со грешките во специјалните случаеви исто така треба да биде тестирано за да се осигура дека услугата е предвидено во исклучителните околности. 65

66 Бидејќи интеграционото тестирање се потпира на одреден збир на достапни информации, техниката кои што може да се користи и во двете страни се договоараат за фиксен збир на податоци кои што е загарантирано да биде на располагање доколку е потребно. Понекогаш е тешко да се предизвика не нормално оденсување, како на пример бавниот одговор на надворешната компонента. Во овој случај тестот може да користи stub верзија од надворешната компонента. [1] Компонентно тестирање Компонентата е дел од системот кој што претставува кохерентен и независтен од другите делови. Компонентното тестирање го манипулира системот преку внатрешни кодни интерфејси и користи различни техники за да го изолира кодот под тестот од другите компоненти. Со ограничување на опсегот на тестирање во рамките на една компонента, може да се елиминира бучавата воведена од страна на секое можно комплексно однесување на надворешните компоненти кои што можат да влијаат врз резултатот на тестот. Ова овозможува целосно фокусирање на тестирање на една компонента. Изолирањето исто така резултира и со побрз тест и овозможува контролирана тестна околина каде што грешките можат да се ре-тригерираат по волјата на програмерот. Во микросервисната архитектура, компонентите всушност претставуваат самите сервисите. Изолацијата за тестирањето на сервисите обично се постигнува со застапување на поврзаните надровершни соработници со нивните симулатори преку низа на внатрешни API ендпоинти за испитување на сервисот. Подолу листата ги вклучува двете заеднички компоненти во микросервисната архитектура: Компонент тестирање во процесот на работа. Овозможува сеопфатно тестирање додека се намалуваат подвижните делови. 66

67 Овој тест создава full in-memory микросервис, со in-memory сервисните симулатори и чуварите на податоците, помага при елиминирање на мрежниот сообраќај, исто така помаѓа и при забрзување на времето на тестирање и ги минимизира бројот на подвижните делови за да се намали комплексноста при билдање. Недостатокот на оваа техника е тоа што работните продукти под тестот мора да се менуваат соодветни на целите на тестирањето. Тестирање надвор од процесот. Вежба за целосни деплоирани работни производи. Овој тест е против микросервисот деплоиран како посебен процес. Таа овозможува остварување на повеќе слоеви и интеграциони поени. Интеракциите се прават преку вистински мрежни повици, каде што нема потреба од менување на компонентата во тестирање со специфични тестлогики. Овој пристап исто така создава и комплексност во темпераментниот тест, тестирањето кој што е одговорен за стартување и стопирање на надворешните stub-ови, координирање на мрежните порти и конфигурацијата. Времето за извршување на тестот се зголемува како резултат на реалните податоци и мрежната интеракција. Сепак овој пристап е посоодветен за тестирање на микросервиси кои што има комплексна интеграција и голема зависност. Контракт тестирање Договорот, концептуално претставува зголемување на бројот на интерфејсите помеѓу два сервиси. Договорното тестурање всушност претставува гранично тестирање на некој надворешен сервис за верифицирање дека ги исполнува очекувањата на договорот формиран помеѓу услугата и неговите потрошувачки услуги. Договорот се состои очекувани услови за влез и излез на податочната структура, перформанси, конкурентни карактеристики итн. Компонентот може да се менува со текот на времето и од суштинско значење претставува задоволството на потропувачите, односно да бидат задоволни после промените. Во микросервисната архитектура договорот е исполнет преку збир на API-ја кои се изложени од страна на секој сервис. Сопственикот кој што ги користи сервисите е 67

68 одговорен за пишување на независен тест пакет, кој само ја верификува аспектите на услугата за производството кои што се во договорот. Истиот овој пакет треба од страна на сопственикот на производството да се провери за да биде информиран за ефектот на промените на своито потрошувачи. Целовкупниот договор може да се дефинира со сумирање на сите тестови на потрошувачите. Потрошувачките договори формираа точки за разговор со сервисите на споственикот, врз основа на тоа кои од тестовите можат да бидат автоматизирани за да се обезбеди индикација за подготвеност на API-то. Постојат неколку алатки кои што помагаат при пишување на контракт тестови како Pact и Pacto. [1] Крај до крај тестирање Ова тестирање служи за верифицирање дека системот како целина ги исполнува барањата на бизнисто и ги постигнува целите. Тестот ги постигнува ова со поминување низ целиот систем од крај до крај. Поради природниот автономен карактер на микросервисната архитектура, тоа исто така има повеќе подвижни делови за разлика од другите системи. Крај до крај тестови може да помогне и при покривање на недостатоците помеѓу сервисите. Овој тест исто така обезбедува и дополнителна доверба во точноста на пораките поминати помеѓу сервисите. Тестот исто така осигурува дека сите дополнителни мрежни инфраструктури како firewall, прокси и лоадбалансери се правилно конфигурирано како што требаат Со текот на времето микросервисната архитектура постојано развиваат. Крај до крај тестовите исто така додаваат вредност на тој начин што на бизнис функции предвидени со тој вид на систем, остануваат непроменети во текот на таквите моќни рефакторирања. Границите за крај до крај тестирањата се многу поголеми за разлика од другите видови на тестови, бидејќи целта е да се тестира однесувањто на целосно интегрираниот систем. Како што обемот на тестот се зголемува така се зголемува и бројот на подвижните делови што може да воведе тест неуспеси. Овие проблеми не покажуваат дека системот не функционира, туку дека има некои други проблеми во системот. 68

69 Идеално сите надворешни сервиси во системот можат да се управуваат за да бидат вклучени во крај до крај тестирањето. Сепак во повеќе случаеви сервисите се управувани од некоја сосема друга страна. Резултатот од тоа е дека тестот пропаѓа заради факторите кои што се надвор од контролата на човекот. Во таквите случаеви би требало да се жртвуваат некои крај до крај тестови. Поради дополнителните комплексности при пишување на крај до крај тестовите, тестниот тим треба селективно да ја дефинира тестната стратегија. Следнава листа ги вклучува некои насоки за да се направи ефикасен крај до крај тест: Крај до крај тестовите морат да бидат мали колку што е можно. Главната цел кај крај до крај тестовите е тоа што треба да е сигурно дека сите услуги кои што го сочинуваат системот работат добро како целоина. Исто така соодветно ниво на доверба во однесување на системот може да се добие и при фокусирање на другите тестови наместо да се даде премногу напор во крај до крај тестирањето. Избегнување на зависност од претходно постоечките податоци. Бидејќи податоците цело време можат да се менуваат и потпирање на претходно постоечките податоци може да предизвика и големи неуспеси во системот. Исто така овие дефекти не се доказ за неуспехот на системот. Решението за ова би било автоматизирање на податоците, така што системот може да ги иницијализира податоците за конкретниот тест. Мимичката производствена средина во целосно автоматизиран начин. Комплекснота при деплоирање на микросервисната архитектура може да резултира и со големи тешкотии во репликацијата на средината за крај до крај тестирањето. Еден од решенијата би било користење на инфраструктура како код IaaS, со помош на некои автоматизирани framework-ови, како што е Chef или Puppet, којшто може да помогне при билдање на средини како што се потребни. Тестот треба да биди потрошувачки управуван. Моделирање на тестот околу потрошувачите на сервисот. Може дури и да се тестира и во производство со нови функциналности. [1] 69

70 Перформанс тестирање Перформанс тестирањето треба да се изврши против сервис до сервис повиците и против одреден сервис во изолација за да се прати микросервисот поединечно и за да биде во контрола текот на работата на системот. Обично добар начин е да се започне со идентификување на главните точки на системот, и сите сервиси да бидат во рамките на постепено зголемениот број на повици. На овој начин можат да се следат и перформансите на системот како што се мрежните проблеми (односно дали има забавување во системот...). Идеално, компонентата или системот под перформансно тестирањето треба да биде поставена во средина која што е многу слична на производството. Перформанс тестирањето исто така треба да се направи заедно со следење во реално перформансите на системот. Идеално треба да ги користи истите алатки како што се оние во продизводство за визуелизација на однесувањето на системот, бидејќи со тоа може да се направи полесно да се спроведат двете. Сеопфатна алатка за централизирано најавување е добар пример за тоа да се види точко како микросервисите дејствуваат. Подолу на листата се опишани некои црти за да се заврши тестирањето против микросервсиниот сситем: Да се користи колку што е можно по реални податоци Оптоварување на тестот колку што е можно да биде слична со продукциската верзија Условите да бидат колку што е можно по слични на продукциските услови Тестот треба да се направи во раните периоди на системот, односно пред системот да се пресели во продукциската околина Заедно со перформансното тестирање исто така треба да се направи и мониторско следење на системот Градење на доволно стратегија за тестирање Автоматскиот режим на тестирање има напредно значење со текот на времето, особено со појавување на нови алатки и техники за работа. Сепак и понатаму предизвиците остануваат во тоа како да се тестира ефикасно функционалните и не-функционалните 70

71 аспекти на системот, особено во дистрибуирани модели. Со повеќе независни компоненти и модели на соработка меѓу нив, микросервисите природно додаваат ново ниво на сложеност при тестирање. Очигледно е дека идентификувањето на проблемите пред да се оди на производство е критична потреба, меѓутоа факт е дека никогаш не може да се детектираат сите проблеми што можат да се јавуваат во системот пред неогово префрлување во производство. Извршување на тестовите со соодветен модел и алатка на деплоирање може да ги намали проблемите на системот и да ги доведе блиску до нула. Чад тестот и сино/зелено деплоирање се добри примери на техники за да се постигне истото. Разбирање на тоа колку различни тестови можат да се извршат и кои се нивните предност и недостатоци се едни од најбитните основи за да се направи добра тестна стратегија. Оваа овозможува да се балансираат потребите на сервисите и нивно побрзо преминување во производство. Доколку се извршат сите чекори заедничко, тогаш можат да се истакнат следните чекори за да се има сеопфатен пристап при тестирање на микросервисниот систем Изградба на тестовите на тој начин што ќе можат да бидат поблиску до клиентот, односно истиот ќе може да го има системот при рака Оптимизирање на тестовите за брза повратна информација за било кој тип на тестирање Оптимизирање на тест стратегијата, така што бројот на потребни крај до крај тестови ќе бидат помалку [1] 71

72 4. Бот за управување со анкети во Slack 4.1 Опис на софтверот Slack е алатка за тимска колаборација, основан од страна на Stewart Butterfield. Slack-от на почеток се користел како интерен софтвер во компанијата, меѓутоа со текот на времето почнале да користат повеќе луѓе односно повеќе компании, така да денеска е број еден софтвер за тимска комуникација во компаниите. Првата верзија е објавена во Август 2013 година. Slack-от нуди повеќе IRC фунцкии: виртуелни канали за разговори организирани по теми, приватни групи и директни пораки. Сите содржини во Slack-от можат да се пребаруваат вклучувајќи ги и датотеките, разговорите и луѓето. Slack-от може да се интегрира со голем број на други сервиси. Како најпознати сервиси можат да се набројат Google Drive, Trello, Dropbox, Box, Heroku, IBM Bluemix, Crashlytics, GitHub, Runscope и Zendesk. Во Декември 2015, Slack-от објави и свој апликациски директориум кој што се сости од огромно голем број на интеграции околку 150 кои што корисниците можат да ги инсталираат. Исто така корисниците можат да додаваат и емоции во пораките. [3] Slack-от во глобала е без пари. Притоа бесплатната верзија на Slack има и ограничување до најнови пораки на тимот и ограниченост до 5ГБ за датотеки и до 10 апликации односно интеграции. Во моментот има на располагање три нивоа на цени: Бесплатен, Стандард ($ 6.67 еден месец), и плус ($ еден месец). 4.2 Како работи Slack Подесувања: При кликнување на табот кај што се наоѓа корисничкото име или на стрелката надолу веднаш до Slack тимското име за пристап до менито со ставки. Во тоа 72

73 мени можат да се направат различни подесување (тема за левата лента, пораки, стил и многу повеќе), може да се провери профилот сметката, пристап до помошната страна/повратни информации, Slack апликации итн. Доколку корисникот е администратор исто така има и пристап до подесувањата на тимот исплата. Членовите на тимовите исто така имаат пристап до интегрираните апликации. Слика 20: Приказ на листата од канали и пораките Известувања: При кликнување на симболот на камбаната во горниот десен агол на лентата, можат да се прилагодат сите параметри за известувањата. Можат истите да се одложат, исто така можно е и подесување по сат. При првото најавување секој тип на известувања се отвортени. Но услугата нуди и голем број на различни начини за нивно управување. Исто така овозможено е и прилагодување на известувањата и по канал, така да корисникот доколку сака известувања само од еден канал истото може да го направи многу едноставно. Омилени: Се што е штиклирано како омилено ќе се појави над делот на каналите. Оваа опција е особено важно доколку корисникот сака повторно да види некоја важна 73

74 порака или датотека може само да го обележи како омилено и веднаш ќе има пристап до него во секој момент. Канали: Лената за канали е една од најважните алакти на оваа апликација, таа се наоѓа во левата страна на софтверот. Притоа каналите се виртуелни простории за разговор. Името на каналот може да се смени врз основа на темата што се разговара во него. Каналите можат да бидат приватни или јавни. Доколку каналот е јавен сите од тимот можат да имаат пристап до тој канал но ако е приватен тогаш само избраните луѓе имаат пристап до него. За креирање на канал доволно е само да се кликне на + копчето и потоа да се изберат неговите основни подесувања(јавноста и приустапот на корисниците). Дирактни пораки: Директните пораки возможуваат корисниците да испраќаат дирекни пораки до одредени корисници а не во група. Директните пораки исто така можат да вклучат најмногу девет лица (основоположник плус осум лица). При започнувањето на директната порака истата може да се претвори и во приватен канал. Покана на луѓе: Доколку корисникот е администратор, тогаш истиот може многу лесно да ги покани луѓето во нивиот тим. Притоа новите членови треба да креираат нови сметки а потоа ги имаат истите привилегии како и другите членови во тимовите. Пребарувања: Пребарувањето е едно од клучните карактеристики на Slack-от, пораките и датотеките можат да се пребаруваат. Резултатите се многу брзи и при впишување на едната буква веднаш се појавуваат и понудените корисници пораки итн. Исто така може дури и да се сортираат најновите и најрелевантните датотеки. Mentions and Reactions: во текот на разговорите може да се за да се извести одреден користник. Исто така од горниот десен агол со може да се направи увид пораки и обележаните зборови со кликнување на Mentions & Reactions "@" симболот. Уплоадриање споделување на датотеки: Постојат неколку лесни начини за испраќање на било како тип на датотека (документ, слика, видео линк итн). Може едноставно со влечење на елементот или пак со кликлување на копчето + до прозорецот со порака. Исто така не треба да се заборави и дека лесно можат да се споделуваат датотеките од Google Drive, Dropbox или Box со пастирање на линкот во прозорецот со пораката. 74

75 Поставување на потсетници: Во Slack постои можност и за додавање на потсетници. На пример доколку е потребно да се потсетам себеси за кафе за 30 мин, само треба да се напиши следното во прозорецот со пораката: "/remind me in 30 minutes to drink a coffee", и Slack приватно ќе го потесети корисницот за горенаведената акција. Постојат голем број на апликации кои што можат да се додаваат во Slack-от. Тоа може да се прави со влечење на податоци од други сервиси, пребарување на документи потсетници вклучувајќи ги и видео повиците. Денеска може да се пристапи и до Skype преку Slack-от. Поставауање на интеграцијата е многу едноставно само треба да се оди на страната за интеграција со Slack-от и при кликнување на Add to Slack, копчето операцијата ќе биде завршена. При воспоставување на Skype интеграцијата секој член од тимот може да направи Skype повик со командата /skype. За да се приклучи корисникот во Skype повикот треба да виде најавен од веб или да користи Skype апликација од мобилен. Секој може да се придружи како гостин од компјутер или да се пријави со Microsoft сметка или Skype име. Како што е Skype-от, во Slack постојат многу други вакви апликации кои што ни го олеснуваат разговорите во тимотиве. За таа цел треба да се поседи страната на Slack каде што се наоѓаат сите апликации кои што можат да се интегрираат со Slack. [4] 4.3 Slack апликации Како што е објаснато погоре во Slack-от можат да се креират различни апликации кои потоа истите можат да се користат од страна на други корисници. Имаат повеќе начини за креирање на Slack апликациите: Испраќање на известувања со webhooks Slash команди Бот корисници Повикување на веб и RTMP API 75

76 Најпрвин треба да се наведат потребните дозволи каде што корисниците при инсталирање на апликацијата ќе може истите да ги види и да ги конфигурираат подесувањата во рамките на Oauth базиран автентификациски циклус. Слика 21: Процесот на преземање на токен По завршување со апликацијата истата треба да се достави до app директориумот. Тимот на Slack ја проверува апликацијата и доколку се е во ред истата се пушта во продукција. Притоа програмерите исто така можат да додаваат Slack копче во нивните страни за полесна нивна интеграција. [5] Испраќање на известувања со webhooks Испраќањето на известувања со webhooks е еден од најлесните начини за креирање на апликации. Со него едноставно можат да се испраќаат пораки од надворешни извори во Slack. Тоа се прави со користење на HTTP повици со JSON порака кој што во себе го содржи текстот и некои други опции. Исто така можат да се пратат и фајлови со помош на webhooks. Сетирањето на webhooks се состои од неколку чекори: 76