Přeskočit na obsah

Mikroslužby

Z Wikipedie, otevřené encyklopedie

Mikroslužby (případně i jako mikroservisy) je pojem z oblasti vývoje software. Jedná se o jednu z variant softwarové architektury orientované na služby (SOA), kde jsou aplikace definovány jako soubor volně provázaných služeb.[1] V mikroservisní architektuře (MSA) se vyskytují tzv. „fine-grained“ služby a „lightweight“ protokoly.

Úvod

[editovat | editovat zdroj]

Pro mikroslužby neexistuje žádná přesná definice. Postupem času došlo ke shodě na tom, co jsou mikroslužby nebo co si pod nimi představovat. Často se citují tyto charakteristiky:

  • podle Martina Fowlera a dalších odborníků jsou služby v MSA procesy, které pro dosažení svého cíle komunikují po síti pomocí technologicky nezávislých protokolů, jako je HTTP,[2][3][4]
  • služby v MSA lze nasadit nezávisle na sobě,[5][6]
  • služby v MSA jsou seskupeny podle business funkčností, které poskytují,[7]
  • služby v MSA mohou být implementovány pomocí různých programovacích jazyků, databází, hardwarového a softwarového prostředí – podle toho, co se nejvíc hodí,[6]
  • služby v MSA jsou malé, umožňují zasílání zpráv, jsou ohraničeny svým kontextem, autonomně vyvíjené, nezávisle nasaditelné, decentralizované a sestavené a nasazené do produkce pomocí automatizovaných procesů.[5]

Mikroslužby nelze chápat jako jednu z vrstev v monolitické aplikaci (na rozdíl od například web controlleru nebo třeba backendu pro frontendovou aplikaci apod.).[8] Jedná se spíše o samostatnou business funkčnost, která má jasná rozhraní a která v sobě může (ale nemusí) implementovat více vrstev. Ve své podstatě se tedy jedná o aplikaci filozofie Unixu: „Dělej jednu věc a dělej ji dobře“.[9]

Martin Fowler popisuje architekturu založenou na mikroslužbách takto:[2]

  • umožňuje vývoj softwaru s využitím „continuous delivery“; to znamená, že změna malé části aplikace vyžaduje změnu a nasazení pouze malé části – jedné služby nebo malého počtu služeb,[10]
  • dodržuje principy jako jsou fine-grained rozhraní (pro nezávisle nasaditelné služby), vývoj řízený business potřebami (např. domain-driven design), atd.[11]

MSA se často používá pro cloud nativní aplikace a aplikace využívající nasazení s pomocí „lightweight“ kontejnerů. Podle Fowlera, vzhledem k velkému počtu mikroslužeb (ve srovnání s implementací pomocí monolitických aplikací) je potřeba zavést decentralizovaný „Continuous Delivery“ a mít DevOps s uceleným monitorováním služeb, aby bylo možné efektivně vyvíjet, udržovat a provozovat mikroservisní aplikace.[12] Díky tomu pak mohou být jednotlivé mikroslužby např. snadno individuálně škálovány ve srovnání se službami v monolitické aplikaci. V monolitickém přístupu by např. aplikace podporující tři funkce musela být škálována jako celek, i kdyby pouze jedna z těchto funkcí měla vysoké nároky na zdroje.[13] U mikroslužeb je potřeba škálovat pouze konkrétní mikroslužby, které mají vyšší nároky na zdroje, což poskytuje výhodu optimalizace zdrojů a nákladů.[14]

Historie

[editovat | editovat zdroj]

Na workshopu softwarových architektů, který se konal v květnu 2011 poblíž Benátek, byl použitý termín „microservice“ k popisu architektonického stylu, se kterým se účastníci workshopu potkávali v praxi a který mnozí z nich právě zkoumali.[15] V květnu 2012 stejná skupina architektů rozhodla o pojmu „microservices“ jako o nejvhodnějším názvu pro tuto architekturu. James Lewis prezentoval některé z myšlenek v případové studii v březnu 2012 na 33rd Degree v Krakově, „Micro services – Java, Unix Way“[16] stejně jako Fred George[17] přibližně v tu samou dobu. Adrian Cockcroft, bývalý ředitel cloudových systémů v Netflixu[18] popsal tento přístup jako „fine grained SOA“ a propagoval tento styl na webu, stejně jako mnoho dalších – Joe Walnes, Dan North, Evan Bottcher a Graham Tackley.[2]

Mikroslužby jsou jednou z mnoha možností, jak vytvořit servisně orientovanou architekturu (SOA) – architekturu pro vytvoření flexibilních a nezávisle nasaditelných softwarových systémů.[7] Ale mikroslužby byly první realizací SOA, která plně využila DevOps a budování tzv. continuously deployed systémů.[19]

Granularita služby

[editovat | editovat zdroj]

Klíčovou otázkou při definování MSA je, jak velká má být jednotlivá mikroslužba. Na to ale není jednoduchá odpověď, protože záleží na fungování dané organizace a taky na business kontextu služeb, pro které se má používat mikroservisní architektura.[20] Například přístup Amazonu je, že tým vytvářející mikroslužby by měl být tak malý, aby ho nakrmily dvě pizzy.[2] Další organizace si prostě vytvoří malé „jednotky“ vývojářů (squads) – obvykle 6 až 8 vývojářů, kteří tvoří mikroslužby. I tak ale musí vždy řešit otázku, jak velkou business oblast by měla obsáhnout jedna mikroslužba a kde je „hranice“ mezi business oblastmi jednotlivých týmů.

V čem existuje shoda je to, že mikroslužby by neměly být příliš malé, protože vysoké režijní náklady na jejich provoz pak převáží výhody mikroservisního přístupu. Místo rozdrobení na velmi malé služby jsou možné alternativní přístupy – například zabalení funkce do knihovny, přemístění funkce do jiných mikroslužeb[7] nebo snížení nároků na provoz mnoha malých mikroslužeb pomocí Istio a Kubernetes.[21]

Lingvistická definice

[editovat | editovat zdroj]

Lingvistická definice[22] zavádí pojem „mikroslužba“ ve vztahu ke službám takto: „Pro každou službu může existovat více než jedna mikroslužba, ale každá mikroslužba je pouze běžící instancí služby“.

Pojem „služba“ pak definuje takto: „Služba je jednotka programovatelného softwaru schopná vyměňovat si zprávy s jinými službami, jejichž chování je vyvoláno příchozími zprávami, a je definována sadou konečných výpočtových logik nazývaných operace, které jsou deklarovány v strojově čitelném rozhraní. Běhající instance služby se nazývají mikroslužby a jejich vnitřní instance spuštěných operací se nazývají relace. Relace jsou prováděny nezávisle a jejich proměnné jsou nezávisle určovány.“

Výhody

[editovat | editovat zdroj]

Výhody rozpadu aplikace na menší služby jsou:

  • Modulárnost: Díky tomu je aplikace srozumitelnější, snazší na vývoj, snazší na testování a odolnější proti zastarání architektury.[6] Tato výhoda se často používá jako hlavní argument při srovnání se složitostí monolitických architektur.[23]
  • Škálovatelnost: Mikroslužby jsou implementovány a nasazovány nezávisle na sobě, tj. běží v nezávislých procesech, a proto je lze nezávisle na sobě sledovat a škálovat.[24]
  • Integrace heterogenních a zastaralých systémů: Mikroslužby mohou být jednou z možností, jak modernizovat existující monolitické softwarové aplikace.[3][4] Existuje několik společností, které už úspěšně nahradily (části) svého existujícího softwaru mikroslužbami, nebo se o to snaží.[25] Pro tuto modernizaci používají taky inkrementální přístup.[26]
  • Distribuovaný rozvoj: Umožňuje paralelní vývoj, kde malé autonomní týmy mohou vyvíjet, nasazovat a škálovat své služby nezávisle na sobě.[27] Umožňuje taky průběžný refaktoring jednotlivých služeb dle potřeby.[28] A jak už je asi patrné, architektury založené na mikroslužbách umožňují naplno využívat Continuous delivery a Continuous deployment.[29]

Kritika

[editovat | editovat zdroj]

Mikroservisní přístup je předmětem kritiky v několika oblastech:

  • Služby vytváří informační bariéry (jedna služba čeká na zpracování jiné služby, která ji tím blokuje).[30]
  • Vzájemné volání mezi službami klade vyšší nároky na síť (latence sítě, doba zpracování zpráv), než je tomu u volání v rámci monolitického procesu.[2]
  • Testování a nasazení je komplikovanější (viz distribuovaný rozvoj).[31]
  • Přesun odpovědnosti mezi službami je obtížnější.[6] Může dojít k přesunu služby do jiného týmu a to může znamenat např.: zvýšenou komunikaci pro hladké předání různými týmy; přepsání funkčnosti do jiného jazyka; umístění do jiné infrastruktury apod.[2] Není to ale tak složité jako přesun u monolitické aplikace, protože mikroslužby mohou být nasazeny nezávisle na zbytku aplikace, zatímco týmy pracující na monolitech musí být synchronizovány, aby mohly být aplikace nasazeny společně.[32]
  • Při rozdělení monolitického systému na mikroslužby může dojít k vytvoření příliš velkého počtu služeb tam, kde by lepším řešením byla vnitřní modularizace.[33] Správa tak velkého počtu služeb pak může vyžadovat zavedení dalších systémů pro přehled o celkové architektuře aplikací a vzájemné závislosti mezi komponentami.[34]
  • Nedoporučuje se dělat dvou-fázové commity transakcí u mikroslužeb, protože by to vedlo k úzkému propojení všech účastníků na transakci (commit napříč týmy, které mají být nezávislé). To ale znamená, že je potřeba se domluvit se všemi účastníky, kteří implementují transakci (komunikace napříč týmy), aby se zachovala konzistence dat (jsou potřeba commity v každém ze zúčastněných týmů).[13]
  • Vývoj a podpora služeb je náročnější, pokud se používají různé nástroje a technologie – to může být problém zvlášť při častém přesunu vývojářů mezi projekty.

Kognitivní zatížení

[editovat | editovat zdroj]

Mikroservisní architektura zvyšuje komplexnost a přináší nové výzvy k řešení, jako je latence sítě, návrh formátu zprávy,[35] zálohování / dostupnost / konzistence (BAC),[36] vyvažování zátěže a odolnost proti chybám.[31] Všechny tyto problémy je navíc potřeba řešit ve větším měřítku (ve srovnání s monolitickými aplikacemi).

Komplexnost monolitické aplikace se nesníží jen tím, že bude znovu implementována jako sada mikroslužeb. Částečně se totiž zvýší složitost na provozování mikroslužeb.[37] Taky se projeví zvýšený síťový provoz díky komunikaci mezi mikroslužbami a z toho plynoucí pomalejší výkon mikroslužeb. Důležité je taky zvýšení počtu přístupových bodů k jednotlivým mikroslužbám, což zase zvyšuje architektonickou složitost. Pro snížení těchto dopadů mikroservisní architektury je proto potřeba aplikovat další organizační principy (jako jsou HATEOAS, dokumentace rozhraní a datového modelu pomocí Swagger atd.).

Technologie

[editovat | editovat zdroj]

Počítačové mikroslužby mohou být implementovány pomocí různých programovacích jazyků a mohou používat různou infrastrukturu. Nejdůležitější technologickou volbou je proto způsob, jakým spolu budou mikroslužby komunikovat (synchronní / asynchronní komunikace, případně rovnou integrace uživatelského rozhraní) a jaké protokoly budou používat pro komunikaci (RESTful HTTP, messaging, …). Ve srovnání s tradičním systémem, kde např. volba programovacího jazyka ovlivní celý systém, je tedy přístup k výběru technologií u mikroslužeb zcela odlišný.[38]

Servisní síť (síť služeb)

[editovat | editovat zdroj]

V servisní síti je každá instance služby spárována s instancí reverzního proxy serveru, který se nazývá „service proxy“, „sidecar proxy“ nebo jen „sidecar“ (postranní vozík). Instance služby a její „sidecar proxy“ spolu sdílejí kontejner, který je spravován nástrojem pro správu kontejnerů jako jsou Kubernetes, Docker Swarm nebo DC / OS. „Sidecar proxy“ zodpovídá za komunikaci s jinými instancemi služeb a umožňuje funkce, jako je vyhledávání služeb (instance), vyvažování zátěže, autentizace a autorizace, zabezpečená komunikace a další.

V servisní síti tvoří instance služeb a jejich „sidecar proxy“ datovou úroveň („data plane“), což zahrnuje nejen správu dat, ale také zpracování žádostí a odpovědí (request a response). Servisní síť ale potřebuje taky nějakou „kontrolní úroveň“, tzn. řízení interakce mezi službami zprostředkovanou přes jejich „sidecar proxy“. Existuje několik řešení pro servisní sítě, jako např.: Istio (společný projekt společností Google, IBM a Lyft), Linkerd (projekt CNCF vedený Buoyant[39]) a další.

Porovnání platforem

[editovat | editovat zdroj]

Implementace architektury mikroslužeb je obtížná. Existuje mnoho oblastí (viz tabulka níže), které je potřeba řešit, ale naštěstí už existují platformy/frameworky, které lze použít.

Netflix Open Source Software (OSS)

[editovat | editovat zdroj]

Netflix vyvinul vlastní framework pro mikroslužby, který používal ve svých interních aplikacích, a později ho dal částečně k dispozici jako open source.[40]

Spring Cloud

[editovat | editovat zdroj]

Mnoho z nástrojů Netflix OSS bylo popularizováno prostřednictvím Spring frameworku – kde byly tyto nástroje znovu implementované na základě Springu a pod záštitou projektu Spring Cloud.[41]

Srovnání Spring Cloud / Netflix OSS a Kubernetes

[editovat | editovat zdroj]

Níže uvedená tabulka ukazuje srovnání ekosystému Kubernetes s ekvivalentem ze světa Spring Cloud.[42] Jedním z pozoruhodných aspektů ekosystému Spring Cloud je to, že se jedná o technologie založené pouze na Javě, zatímco Kubernetes je více-jazyčná runtime platforma.

Oblast mikroslužeb Spring Cloud a Netflix OSS Kubernetes
Správa konfigurace: Konfigurace pro mikroservisní aplikaci musí být oddělena od kódu a je možné ji získat pomocí jednoduchého volání služby. Spring Config Server i Netflix Archaius podporují uložení konfigurací v Gitu. Archaius podporuje datové typy v konfiguraci. Kubernetes ConfigMaps vystavuje konfiguraci uloženou v etcd prostřednictvím služeb. Kubernetes Secrets podporuje zabezpečené nasazení a používání citlivých konfiguračních informací (jako jsou hesla, certifikáty atd.). přes služby.
Zjištění služby: Udržovaný seznam instancí služeb, které jsou k dispozici v rámci dané domény mikroslužeb. Spring Cloud Eureka umožňuje klientům se zaregistrovat, udržuje spojení s registrovanými klienty a umožňuje jim vyhledání služby podle názvu služby, které průběžně mapuje. Kubernetes Services poskytují registraci služeb v okamžiku nasazení instance služby, která je interně dostupná v rámci daného klastru. Ingress je mechanismus, kterým může být služba vystavena klientům mimo klastr.
Vyrovnání zátěže: Klíčem ke škálování distribuovaného systému je možnost spouštět více než jednu instanci komponenty. Zátěž pak musí být rozdělena do těchto instancí prostřednictvím vyrovnávače zatížení. Spring Cloud Ribbon umožňuje klientům služeb, aby srovnali zátěž napříč instancemi služby. Služba Kubernetes Service umožňuje, aby byla zátěž služby vyrovnána napříč instancemi služby. Toto není ekvivalent toho, co poskytuje Ribbon.
API gateway: Granularita API, které poskytují mikroslužby, je často odlišná od toho, co klient služeb potřebuje. API gateways implementují fasádu API a poskytují další služby, jako je proxy, překlad mez protokoly a další funkce pro správu API. Spring Cloud Zuul poskytuje fasádu API na základě konfigurace Kubernetes Service a Ingress zdroje (Istio, Ambassador) jsou řešení, která poskytují funkce API gateway jak pro provoz do a z datového centra, tak i pro provoz napříč datovými centry nebo cloudy nebo regiony).
Bezpečnost: Mnoho obav se týká zabezpečení API gateway. U distribuovaných aplikací nad mikroslužbami je potřeba umožnit definování bezpečnostní politiky a její implementaci v komponentách, které jsou sdíleny napříč všemi službami. Spring Cloud Security řeší bezpečnost prostřednictvím Spring Cloud Zuul Ekosystém Kubernetes poskytuje servisní sítě, jako je Istio, které jsou schopny zajistit bezpečnost prostřednictvím svých API gateway.
Centralizované logy: Je důležité mít centralizovanou infrastrukturu pro sběr a analýzu logů, protože je potřeba obsluhovat velké množství služeb z nichž některé fungují distribuovaně. ELK Stack (ElasticSearch, LogStash, Kibana) EFK Stack (ElasticSearch, Fluentd, Kibana)
Centralizované metriky: Pro správné fungování mikroslužeb je nezbytný centralizovaný monitoring, kde lze sledovat zdraví a výkon jednotlivých služeb i celého systému. Spring Spectator a Atlas Heapster, Prometheus a Grafana
Distribuované trasování: Pro komplexní procesy napříč distribuovanými službami už nestačí „jen“ logování jednotlivých procesů a jejich měření. Je navíc potřeba i distribuované trasování napříč celou platformou mikroslužeb. Spring Cloud Sleuth Hawkular
Odolnost a tolerance chyb: Distribuované systémy musí být schopny automatického přesměrování v případě poruch a musí být schopny směrovat požadavky na tu instanci služby, která poskytne optimální odpověď. Spring Hystrix, Turbine a Ribbon Kontrola stavu, servisní sítě (příklad: Istio)[43]
Automatické škálování a samo-léčení: Distribuované systémy reagují na vyšší zátěž horizontálním škálováním: platforma musí takové podmínky detekovat a automaticky na ně reagovat. Kromě toho musí systém detekovat poruchy a pokusit se o automatické restartování bez zásahu operátora.
Kontrola stavu, samo-léčení a automatické škálování
Tvorba balíčků, nasazení a plánovače: Velké systémy vyžadují robustní správu balíků a systémy pro nasazení, aby mohly rollovat nebo dělat tzv. blue-green deployment a nebo případně rollback, pokud je potřeba. Plánovač pak pomáhá určit, co konkrétně se má nasadit za jakých podmínek. Spring Boot, Apache Maven. Spring Cloud nemá skutečný plánovač. Docker, Rkt, Kubernetes Scheduler & Deployment, Helm[44]
Správa úloh: Lze spouštět naplánované výpočty nezávisle na individuálních požadavcích uživatelů. Spring Batch Kubernetes Jobs and Scheduled Jobs
Aplikace typu Singleton: Omezení konkrétní služby tak, aby byla spuštěna jen jediná instance této služby v celém systému. Spring Cloud Cluster Kubernetes Pods

Související články

[editovat | editovat zdroj]

Odkazy

[editovat | editovat zdroj]

Reference

[editovat | editovat zdroj]

V tomto článku byl použit překlad textu z článku Microservices na anglické Wikipedii.

  1. ↑ JAMSHIDI, P.; PAHL, C.; MENDONÇA, N. C. Microservices: The Journey So Far and Challenges Ahead. In: IEEE Software. 3. vyd. [s.l.]: [s.n.], 2018. ISSN 0740-7459. DOI 10.1109/MS.2018.2141039. Svazek 35. S. 24–35.
  2. ↑ a b c d e f FOWLER, Martin; LEWIS, James. Microservices [online]. 2014-03-14 [cit. 2019-11-22]. Dostupné online. 
  3. ↑ a b NEWMAN, Sam. Building Microservices. [s.l.]: O'Reilly Media, 2015. Dostupné online. ISBN 978-1491950357. 
  4. ↑ a b WOLFF, Eberhard. Microservices: Flexible Software Architectures. [s.l.]: [s.n.], 2017. Dostupné online. ISBN 978-0134602417. 
  5. ↑ a b NADAREISHVILI, I., MITRA, R., MCLARTY, M., AMUNDSEN, M. Microservice Architecture: Aligning Principles, Practices, and Culture. [s.l.]: O’Reilly 2016 ISBN 978-1491956250. 
  6. ↑ a b c d CHEN, Lianping. Microservices: Architecting for Continuous Delivery and DevOps [online]. [cit. 2019-11-22]. Dostupné online. 
  7. ↑ a b c PAUTASSO, Cesare. Microservices in Practice, Part 1: Reality Check and Service Design. In: IEEE Software. 1. vyd. [s.l.]: [s.n.], 2017. DOI 10.1109/MS.2017.24. Svazek 34. S. 91–98.
  8. ↑ Backends For Frontends Pattern [online]. Microsoft, 2017-06-23 [cit. 2019-11-22]. Dostupné online. 
  9. ↑ KRAUSE, Lucas. Microservices: Patterns and Applications. [s.l.]: [s.n.] ISBN 978-0692424278. 
  10. ↑ Designing microservices: Continuous integration [online]. Microsoft [cit. 2019-11-22]. Dostupné online. 
  11. ↑ JOSUTTIS, Nicolai M. SOA in Practice: The Art of Distributed System Design. [s.l.]: Sebastopol, CA, USA: O'Reilly Dostupné online. ISBN 978-0-596-52955-0. 
  12. ↑ FOWLER, Martin. Microservice Prerequisites [online]. 2014-08-28 [cit. 2019-11-22]. Dostupné online. 
  13. ↑ a b RICHARDSON, Chris. Microservice Patterns. [s.l.]: [s.n.] ISBN 9781617294549. 
  14. ↑ MENDONCA, Nabor C.; JAMSHIDI, Pooyan; GARLAN, David; PAHL, Claus. Developing Self-Adaptive Microservice Systems: Challenges and Directions [online]. [cit. 2019-11-22]. Dostupné online. 
  15. ↑ DRAGONI, Nicola; GIALLORENZO, Saverio; LAFUENTE, Alberto Lluch. Microservices: yesterday, today, and tomorrow. In: Present and Ulterior Software Engineering. [s.l.]: [s.n.], 2017. ISBN 978-3-319-67424-7. DOI 10.1007/978-3-319-67425-4_12. S. 195–216.
  16. ↑ LEWIS, James. Micro services – Java, the Unix Way [online]. [cit. 2019-11-22]. Dostupné online. 
  17. ↑ GEORGE, Fred. MicroService Architecture: A Personal Journey of Discovery [online]. [cit. 2019-11-22]. Dostupné online. 
  18. ↑ FARROW, Rik. Netflix Heads into the Clouds [online]. [cit. 2019-11-22]. Dostupné online. 
  19. ↑ FARCIC, Viktor. Continuous Deployment: Strategies [online]. [cit. 2019-11-22]. Dostupné online. 
  20. ↑ ZIMMERMANN, Olaf. Domain-Specific Service Decomposition with Microservice API Patterns, Microservices 2019 [online]. [cit. 2019-11-22]. Dostupné online. 
  21. ↑ TSANG, Ray. Reducing Microservices Architecture Complexity with Istio and Kubernetes [online]. [cit. 2019-11-22]. Dostupné online. 
  22. ↑ GUIDI, Claudio. What is a microservice? (from a linguistic point of view) [online]. 2017-03-29 [cit. 2019-11-22]. Dostupné online. 
  23. ↑ YOUSIF, Mazin. Microservices. In: IEEE Cloud Computing. [s.l.]: [s.n.], 2016. Dostupné online. S. 4–5.
  24. ↑ DRAGONI, Nicola; LANESE, Ivan; LARSEN, Stephan Thordal. Microservices: How to make your application scale. In: [s.l.]: [s.n.], 2017. Dostupné online. DOI 10.1007/978-3-319-74313-4_8. S. 95–104.
  25. ↑ KNOCHE, Holger; HASSELBRING, Wilhelm. Drivers and Barriers for Microservice Adoption – A Survey among Professionals in Germany. In: Enterprise Modelling and Information Systems Architectures. [s.l.]: [s.n.], 2019. Dostupné online. DOI 10.18417/emisa.14.1.
  26. ↑ TAIBI, Davide; LENARDUZZI, Valentina; PAHL, Claus. Microservices in agile software development: a workshop-based study into issues, advantages, and disadvantages. In: Proceedings of the XP2017 Scientific Workshops. [s.l.]: [s.n.], 2017. Dostupné online.
  27. ↑ RICHARDSON, Chris. Microservice architecture pattern [online]. [cit. 2019-11-22]. Dostupné online. 
  28. ↑ CHEN, LIANPING; ALI BABAR, MUHAMMAD. Towards an Evidence-Based Understanding of Emergence of Architecture through Continuous Refactoring in Agile Software Development. In: IEEE Software. [s.l.]: [s.n.] Dostupné online. DOI 10.1109/WICSA.2014.45.
  29. ↑ BALALAIE, Armin; HEYDARNOORI, Abbas; JAMSHIDI, Pooyan. Microservices Architecture Enables DevOps: Migration to a Cloud-Native Architecture. In: IEEE Software. 3. vyd. [s.l.]: [s.n.] Dostupné online. ISSN 0740-7459. DOI 10.1109/ms.2016.64. Svazek 33. S. 42–52.
  30. ↑ STENBERG, Jan. Experiences from Failing with Microservices [online]. 2014-08-11 [cit. 2019-11-22]. Dostupné online. 
  31. ↑ a b Developing Microservices for PaaS with Spring and Cloud Foundry [online]. [cit. 2019-11-22]. Dostupné online. 
  32. ↑ TAIBI, Davide; LENARDUZZI, Valentina; PAHL, Claus. Microservices in agile software development: a workshop-based study into issues, advantages, and disadvantages. In: Proceedings of the XP2017 Scientific Workshops. [s.l.]: [s.n.] Dostupné online.
  33. ↑ TILKOV, Stefan. How small should your microservice be? [online]. 2014-11-17 [cit. 2019-11-22]. Dostupné online. 
  34. ↑ LANZA, Michele; DUCASSE, Stéphane. Understanding Software Evolution using a Combination of Software Visualization and Software Metrics. In: In Proceedings of LMO 2002 (Langages et Modèles à Objets). [s.l.]: [s.n.], 2002. Dostupné online. S. 135–149.
  35. ↑ PAUTASSO, Cesare. Microservices in Practice, Part 2: Service Integration and Sustainability. In: IEEE Software. 2. vyd. [s.l.]: [s.n.], 2017. DOI 10.1109/MS.2017.56. Svazek 34. S. 97–104.
  36. ↑ PAUTASSO, Cesare. Consistent Disaster Recovery for Microservices: the BAC Theorem. In: IEEE Cloud Computing. 1. vyd. [s.l.]: [s.n.], 2017. DOI 10.1109/MCC.2018.011791714. Svazek 5. S. 49–59.
  37. ↑ FOWLER, Martin. Microservice Trade-Offs [online]. 2015-07-01 [cit. 2019-11-22]. Dostupné online. 
  38. ↑ WOLFF, Eberhard. Microservices – A Practical Guide. [s.l.]: CreateSpace Independent Publishing Platform Dostupné online. ISBN 978-1717075901. 
  39. ↑ MORGAN, William. What's a service mesh? And why do I need one? [online]. eclipse.org, 2017-04-25 [cit. 2019-11-22]. Dostupné v archivu pořízeném dne 2019-03-10. 
  40. ↑ Netflix Open Source Software Center [online]. github.org [cit. 2019-11-22]. Dostupné online. 
  41. ↑ Spring Cloud [online]. spring.io [cit. 2019-11-22]. Dostupné online. 
  42. ↑ BILGIN, Ibryam. Spring Cloud for Microservices Compared to Kubernetes [online]. developers.redhat.com [cit. 2019-11-22]. Dostupné online. 
  43. ↑ Managing microservices with the Istio service mesh [online]. kubernetes.io, 2017-05-31 [cit. 2019-11-22]. Dostupné online. 
  44. ↑ Helm: Kubernetes Package Manager [online]. [cit. 2019-11-23]. Dostupné online. 

Literatura

[editovat | editovat zdroj]
Citováno z „https://cs.wikipedia.org/w/index.php?title=Mikroslužby&oldid=23843831“