Представяме акценти от презентациите на Виктор и Миро, а ако Dev Bites концепцията ви звучи интересно, имаме добри новини! Първото събитие за 2023 ще се проведе в Пловдив, в Networking Premium (ул. Райко Даскалов 19-21) на 30 март от 19:00!

За микросървисната архитектура с любов

от Виктор Минковски

Има ли истинско противопоставяне Microservices vs. The World? По-скоро не. Защото микросървисите са част от света и важна част от заобикалящата ни среда. Те са и естествено продължение на основната цел на всеки софтуер – да помага на хората. Когато е използвана правилно, микросървисната архитектура е изключително удобна и полезна.

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

Друго тяхно предимство можем да обединим под понятието Agility. Микросървисите дават възможност за бързи и лесни ъпдейти на изолирани части от системата, върху която работим, а това е от особено голямо значение в съвременния бизнес свят, когато е нужно максимално да се скъсява TTM (Time To Market). Благодарение на тях можем да пускаме изолирани части от системата, да правим маркетингови проучвания и AB тестове, да експериментираме. Или пък лесно да подготвяме различни версии на системата за различни клиенти.

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

И все пак, защо точно микросървиси?Защото можем. В последните години технологиите много се развиха. И така, благодарение на микросървисите и на DevOps, всичко става лесно. И още по-важно – всичко работи. Но и защото са готини. Микросървисите ни дават прекрасната възможност да сме яки, да сме в час с новите технологии, да ги учим бързо.

За сблъсъка на микросървисите с реалността

от Мирослав Кошутански

Ще започна с няколко важни професионални съвета, авторството на които не е мое. Кое е първото правило за микросървисите според гуруто в нашата индустрия Мартин Фаулър? “Винаги започвайте с монолита!“. А кое първото правило за Domain-Driven Design, според Ерик Еванс? “Опознайте домейна”. А какъв е най-добрият начин за това? Монолитната архитектура. Забелязвате ли нещо общо?

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

Например, идеята за малки, фокусирани екипи звучи добре. Това обаче означава, че когато 20-30 такива екипа работят върху една и съща платформа, те трябва да се координират. А това е доста, доста трудно и със сигурност не е “бърза и лесна работа”. Същото се отнася и до микса от технологии при подобен тип работа. Златното правило е, дори при микросървисите, да се ползват не повече от 2-3 различни езика, тъй като иначе при споделяне на ресурси синхронизацията е просто кошмарна.

И нещата не стават по-прости! Ако трябва да разберем архитектурата на един микросървис, това не е проблем, защото е малък. Но когато става дума за цялата платформа, където много микросървиси си комуникират с хореография, а не с оркестрация, задачата става ненужно сложна. Ако пък сте решили да започнете работа с Kubernetes – не забравяйте с колко сложно начинание се захващате! Това е добър, изключително мощен инструмент, но използването на пълния му потенциал е всичко друго, но не и “лесно”.

И това не е всичко – проблемите продължават с изолирането на грешки, изолирането на данни, големия брой фреймуърки; distributed logging, tracing, monitoring; броя на микросървиси, за които отговаря всеки екип, дебъгване, repository management… И така стигаме до логичния въпрос: Какво можем да изберем вместо микросървиси?

Можем, например, да се придържаме към монолитната архитектура. Тя все още е нещо добро, все още съществува. Или пък да изберем предшественика на микросървисите – макросървисите. Ако са добре направени, те работят чудесно. Или пък да пробваме хибриден модел от монолит + микросървиси/макросървиси. В крайна сметка, проектът и изискванията трябва да са определящи за този избор. Ако клиентът ни не работи за Google, Microsoft, Netflix, Spotify или Amazon, то тогава отговорът е не, микросървисите не са задължителни.

Професионалистите в Немечек България използват широк набор от технологии (C++, C#, Java, Go, Python, PHP, JS, TypeScript, React.JS, Angular, Vue.js, Microsoft Azure, AWS, Native Аndroid and iOS applications) и разчитат на различни подходи към различните проекти. Прочетете повече на careers.nemetschek.bg

Защо толкова често днес споменаваме DevOps?

Тодор Тодоров: Темата е важна, защото става дума за съществена промяна и оптимизиране на работата в софтуерните екипи. Също така е силно поляризирана. В единия лагер са уверени, че всичко в софтуерните екипи трябва да се случва според писаните и неписани правила на DevOps. Хората от анти-лагера, пък, най-често са фенове на тясната специализация. Но мисленето, че всеки трябва да има една експертиза и колкото се може по-малко да отвлича вниманието си с нещо различно, вече е остаряло.

Значи ли това, че DevOps изисква да бъдеш специалист по всичко?

Тодор Тодоров: Нищо подобно. Физически е невъзможно да имаш перфектни познания и по мрежи, и по инфраструктура, и по програмиране. Важното е, обаче, всеки да знае какво се случва в кошничката на другия, хората да работят в екип, да комуникират много добре помежду си. Така си гарантираш бърза обратна връзка и много къси луупове.

Мирослав Кошутански: За, сравнение, преди години имаше чисто . NET програмисти и чисто Java програмисти. Но дойдоха микросървисите и стана ясно, че трябва да си полиезичен, да разбираш от повече неща. И навсякъде се появиха обяви за full stack developers. Така започна надграждането към DevOps. Днес, особено когато говорим за Agile екипи, всеки в тях трябва да познава инфраструктурата, макар и не в детайл. Така хората могат да си позволят да я правят максимално лесна за deploy, максимално близка до продукцията. Това е и сред основните предимства на методологията – бързо пускане на продукта за реален тест на пазара, което увеличава както производителността на екипите, така и бизнес ползите.

И двамата се занимавате с въвеждане на DevOps практики във вашите екипи през последните 4-5 години. Как се случва тази трансформация?

Тодор Тодоров: В началото бях убеден, че нещата могат да се получат с магическа пръчка. Или поне – доста плавно и лесно. Бях се подготвил с много четене и гледане на конференции по темата. Видях как в други компании са направили крачката към DevOps, разбрах нужното за микросървисите, видях екипи от 10 човека, които могат всичко. Казах си, че при нас ще се получи по същия начин! Истината е, че ако очакваш бързи промени и подходиш с рогата напред, получаваш голям отпор, който пък значително забавя процеса на трансформация. С времето научаваш и какъв е начинът нещата да се получат.

Мирослав Кошутански: Всички сме хора с опит, но когато навлязохме в света на микросървисите, се оказа, че трябва коренно да променим нагласата си. Трябва да мислим за контейнери, за нетуъркинг между тях, да задълбаем в service discovery. Така започва онова класическо психологическо преминаване през пет етапа – от пълно отричане до пълно приемане.

За какво трябва да се внимава при тази голяма трансформация?

Мирослав Кошутански: За да бъде успешен един екип, е от особено значение DevOps знанията да не се свеждат до един-единствен човек в него. Защото, ако този специалист напусне, заедно с него изчезва цялата тази информация и екипът се връща месеци, дори години назад. Всичко трябва да бъде документирано правилно и много подробно. И никога не забравяйте за infrastructure as a code.

Тодор Тодоров: DevOps промяната  трябва да засегне всички по веригата в една компания – и R&D екип, и акаунт, и маркетинг, и мениджмънт. Иначе ставаш заложник на старите си процеси, нищо че си мислиш, че си направил крачка напред.

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

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

Какви всъщност са ползите от DevOps?

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

Тодор Тодоров: Ако мислиш логично, практиката и решаването на проблемите на дистрибутираната среда сами ще те доведат до DevOps. Без дори да си съвсем наясно с тези практики или lean теориите. Някога всичко се случваше в рамките на дълги цикли – практиката беше всеки софтуерен продукт да бъде ъпдейтван веднъж на 6 месеца. Това даваше фалшивото чувство за спокойствие и стабилност, защото тези ъпдейти всъщност бяха пълни с бъгове.

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

Проучването за разработчици на Jakarta EE 2020 се основава на отговори от хиляди разработчици на Java. Има 19% увеличение на участието от 2019 г.

Според данните на фондацията броят на сертификатите за продукти, съвместими с пълна платформа за Jakarta EE, е бил по-голям през последните 8 месеца, отколкото сертификатите за Java EE са били за повече от 2 години.

Нараства интересът и към самата общност на Jakarta EE. “В допълнение към значителния интерес към Jakarta EE и напредъка на общността към Jakarta EE 9, Eclipse Foundation отбелязва рекорден ръст на членството, тъй като добавихме повече членове през Q1 2020 от всеки момент от нашето създаване”, каза Табанг Машологу, вицепрезидент на маркетинг за Eclipse Foundation. “Това е свързано с повишения интерес към модела с отворен код в световен мащаб.”

Според проучването, Jakarta EE е вторият най-популярен фреймруърк за cloud-native Java след Spring/Spring Boot, с 35% използване. Освен това Quarkus на Red Hat, който е фреймуърк за Kubernetes-native Java, сега се използва от 16% от разработчиците, след като бе обявен едва миналата година.

Докладът показа, че интересът към микросървисите от разработчиците на Java всъщност е намалял с 4% от миналата година. Фондацията смята, че това може да се дължи на разработчиците, осъзнаващи, че микросервизите не са общо решение. Все пак микросървисите остават топ архитектурен подход за внедряване на Java системи в облака, като 39% от разработчиците го мислят. Все още има увеличение на желанието за по-добра поддръжка на микросърсиси в Jakarta EE.

Интересът към Eclipse Che също нараства. Eclipse Che е облачен IDE, базиран на Java, за създаване на Kubernetes приложения. Използването на Eclipse Che е нараснало до 11% тази година, спрямо 4% през 2019 г.

Накрая организацията установи, че приемането на Java 8 е спаднало от 84% през 2019 г. на 64% през 2020 г. Смята се, че това е индикация, че Java 11 замества Java 8 по подразбиране.

Наред с резултатите от проучването, Eclipse Foundation пусна и визуализация на Jakarta EE 9. Според фондацията Eclipse, това е основен етап и е завършване на прехода от Java EE. Това е също критична стъпка в еволюцията на native-cloud Java.

“Основният етап на Jakarta EE 9 е първият поглед на нова ера, която въвежда ново пространство на имена, което ще ни даде свободата да актуализираме спецификации, да въведем нови функции, да добавим нови технологии и да засилим темпото на иновациите“, каза Цезар Ернандес, старши софтуерен инженер в Tomitribe, член на Eclipse.