Mikroslužby (microservices) jsou většinou menší, zpravidla jednoúčelové aplikace komunikující spolu prostřednictvím výměny zpráv.

Vycházejí z filozofie Linuxu, a to dělat jen jednu věc, ale zato pořádně. Snáze se vyvíjí, testují, spravují a mění.

Cílem tohoto příspěvku je zamyslet se nad tím, proč agilní vývoj leckde selhává, a co je skutečnou příčinou tohoto selhání.

Rozhodně nechci pohanit agile. On totiž selhává i ten vodopád, jenže od toho agile se jaksi naivně očekávalo, že určité problémy vyřeší. A on je nevyřešil a naopak je ještě více odhalil a poukázal na ně.

Hlavní myšlenkou SecDevOps je užší spolupráce mezi vývojem (Development, zkr. Dev) a provozem (Operations, zkr. Ops) a útvarem bezpečnosti (Security, zkr. Sec).

V rámci DevOps je důležité rychlé uvolňování a nasazování nových verzí, k tomu je třeba provádět nepřetržité testování, soustavný monitoring a neustále se zlepšovat.

Bezpečnost by měla být součástí životního cyklu vývoje software, protože čím později je bezpečnostní slabina odhalena, tím nákladnější je pak její odstranění.

Bezpečný životní cyklus vývoje software (Secure Software Development Life Cycle, zkr. SSDLC) je pak takový cyklus vývoje software, kdy je bezpečnost nedílnou součástí celého vývojového cyklu a nachází se v každé jeho fázi. Bohužel dost často se setkáváme s tím, že spousta firem o SSDLC jen mluví a jejich aplikace obsahují spoustu zranitelností. Pojďme si společně projít jednotlivé fáze SSDLC a podívejme se, jak je v nich řešena bezpečnost. Životní cyklus vývoje software se zpravidla skládá z těchto fází: analýza, návrh, kódování, nasazení a provoz.

V tomto příspěvku se pokusíme zamyslet nad tím, kdo by měl provádět analýzu a návrh, a kdo by měl podle specifikace vyvíjet.

Běžně se postupuje tak, že vývojářský tým v rámci životního cyklu vývoje SW (Software Development Life Cycle, zkr. SDLC) získá od zákazníka požadavky, analyzuje je, následně navrhne model aplikace, např. za pomocí UML diagramů, a nakonec provede i vlastní kódování a testy. Otázka je, zda by nebylo lepší tyto činnosti rozdělit mezi více firem.

V příspěvku věnovaném vícevrstvé architektuře bylo uvedeno, že komunikace mezi vrstvami by měla být omezena na minimum a proto je vhodnější používat chunky interface místo chatty.

Jaký je však mezi těmito dvěma interfacy rozdíl? Pro chatty interface (doslova ukecaný interface) je typické, že dochází k přenášení velkého množství zpráv o malé velikosti mezi vrstvami. Je tak náročnější na čas a na zdroje. Chunky interface je naopak navržen tak, aby komunikace mezi vrstvami byla minimální, to ale znamená, že je nutné přenést najednou větší objem dat. Nelze říci, že chatty interface je vyloženě špatný a chunky dobrý. Vždy jde o konkrétní případ, v jakém bude ten či onen interface nasazen.

V minulém díle jsme si popsali jednotlivé vrstvy vícevrstvé architektury, nyní je na čase se zamyslet nad výhodami a nevýhodami vícevrstvé architektury vůbec.

Výhody vícevrstvé architektury

Důsledné oddělení jednotlivých vrstev a volné vazby mezi vrstvami přináší mnoho výhod.  Především, že kterákoliv vrstva může být vyměněna nebo upravena, aniž by to mělo vliv na funkčnost aplikace jako celku.

V příspěvku „Vícevrstvá architektura: popis vrstev“ jsme si stručně charakterizovali jednotlivé vrstvy vícevrstvé architektury, nyní si popíšeme jednotlivé typy SW klientů a jejich výhody a nevýhody.

Tlustý klient (thick client)

Tlustý klient v sobě obvykle obsahuje jak presentační tak i aplikační vrstvu a připojuje se přímo k databázovému nebo jinému serveru. Další typickou vlastností tlustého klienta je, že si přes síť stahuje velký objem dat, která zpracuje a výsledek pak přenese zpět na server.

Vícevrstvá architektura se často označuje jako multi-tier nebo ještě častěji jako n-tier, kde n vyjadřuje počet vrstev, ze kterých se vícevrstvá architektura skládá.

Jako vícevrstvá se označuje proto, že funkčnost aplikace je rozdělena mezi několik vzájemně spolupracujících vrstev, které spolu komunikují přes definované rozhraní. Nejběžnějším příkladem vícevrstvé architektury je architektura třívrstvá, kterou používá mnoho webových aplikací. V takovém případě rozlišujeme vrstvu, která se stará o uživatelské rozhraní, vlastní logiku aplikace a databázi.

Pokud máte funkční aplikaci a uživatelé jsou s ní spokojeni, tak všechny požadavky na nové vlastnosti zamítejte a nové vlastnosti nepřidávejte. Proč?

Protože aplikace by měla obsahovat jen ty vlastnosti, které jsou opravdu potřeba. Zaměřte se spíš na to, aby vám ty stávající vlastnosti fungovaly naprosto perfektně a obsluha vaší aplikace byla co nejjednodušší a nejintuitivnější. Jestliže musí uživatel absolvovat školení nebo číst nějaký manuál, aby vůbec mohl začít s vaší aplikací pracovat, znamená to, že někde je něco špatně.