Obsah
2. Od klasických monolitických služeb k mikroslužbám
3. Reálně provozované monolitické služby a jejich škálování
4. Koncepty, na nichž jsou postaveny mikroslužby
5. Myšlenka ze světa Unixu: smart endpoints and dumb pipes
6. Decentralizace na všech úrovních, škálování
7. Automatizace při nasazování, testování a provozování mikroslužeb
8. Další vybrané přednosti mikroslužeb
9. A pochopitelně i některé zápory
10. Synchronní vs. asynchronní volání
12. Časté omyly, kterých se vývojáři dopouští (nejenom) při tvorbě mikroslužeb
13. Síť jakožto problematický prvek
14. Špatné uplatnění konceptu mikroslužeb
15. Sdílení databáze mezi mikroslužbami
17. Rozdíly v přístupu SOA a MSA
1. Mikroslužby
V dnešním článku se seznámíme se základními principy, na nichž je postaven koncept takzvaných mikroslužeb (microservice). Jedná se o poměrně často skloňovaný termín, kterým se v informatice označuje nový (či spíše přesněji řečeno staronový) způsob realizace služeb (service), tj. implementací nějaké funkcionality, která je typicky nabízena servery, ať již na Internetu či „pouze“v rámci Intranetu. Mezi typické služby patří například správa uživatelů (zaměstnanců), správa tiskových úloh, docházkový či skladový systém, CMS či dokonce celý publikační systém, mapové portály, dále služby typu Google Drive apod. Podle způsobu návrhu architektury takových služeb dnes rozlišujeme mezi monolitickými službami na straně jedné a právě mikroslužbami na straně druhé. A pochopitelně můžeme nalézt i mnohé návrhy architektury, které leží mezi těmito dvěma v podstatě extrémními kategoriemi (viz například dále zmíněnou metodologii SOA).
V souvislosti s mikroslužbami se často mluví i o různých nástrojích a technologiích, mezi něž patří například Ansible, Docker, Kubernetes, Knative, OpenShift atd. Ty se skutečně pro projekty založené na mikroslužbách používají, ovšem pro samotné pochopení principů, na nichž jsou mikroslužby postaveny, se prozatím těmito nástroji nemusíme podrobněji zabývat (alespoň nikoli v úvodním článku).
2. Architektura klasických monolitických služeb
Pravděpodobně každý čtenář Roota se již setkal s nějakou monolitickou aplikací či s monolitickou webovou službou (ostatně i samotný Root je s poměrně velkou pravděpodobností postaven podobným způsobem). Typicky je taková aplikace rozdělena na tři části: vrstvu zajišťující uživatelské rozhraní, vrstvu s vlastní implementací business logiky a konečně většina služeb používá i nějaké datové úložiště, do něhož se vstupuje přes datovou vrstvu. V tom nejtypičtějším případě může být služba realizována na základě čistě třívrstvé architektury:
Obrázek 1: Klasická (stále poměrně často používaná) třívrstvá architektura.
Mezi typické znaky takto navržených a provozovaných služeb patří především:
- Samotný programový kód, i když může být vnitřně velmi dobře strukturovaný a modularizovaný (knihovny, jmenné prostory, třídy, funkce, programové bloky), je většinou napsán v jednom programovacím jazyku, uložen v jediném repositáři a spravován jako monolit.
- Podobně i datové úložiště (databáze) bývá monolitická – jedno úložiště pro celou aplikaci/službu.
- Moduly, z nichž se případně aplikace skládá, jsou těsně svázány a případné změny v rozhraních modulů mohou mít velký dopad na celou aplikaci (její nasaditelnost, stabilitu atd.).
- Aplikace se typicky nasazuje a testuje jako celek; při každém nasazení bývá (v tom lepším případě :-) kompletně otestována, což může být časově náročná operace.
- Samotná aplikace většinou závisí na mnoha knihovnách, které mají tranzitivní závislosti (tedy „závislosti závislostí“). Jakékoli zvýšení verze závislých knihoven (například v důsledku nalezené CVE) je opět nutné otestovat v kontextu celé aplikace; chyba v knihovně může celou aplikaci znepřístupnit, v případě CVE pak způsobit například únik dat.
3. Reálně provozované monolitické služby a jejich škálování
Ve skutečnosti je však reálná aplikace či služba realizována ještě poněkud komplikovanějším způsobem, protože vlastní realizace frontendu a business logiky bývá „schována“ za mezivrstvu realizovanou HTTP serverem (například Apache či Nginx), který dokáže kromě jiného zajistit i posílání statického obsahu atd. Frontend a business logika může v tomto případě běžet například v nějakém aplikačním serveru, servlet kontejneru, může se jednat o aplikaci napsanou v Pythonu založenou na knihovně Flask, samostatnou aplikaci vyvinutou v programovacím jazyce Go pomocí standardního balíčku net/http:, aplikaci pro Node.js atd.:
Obrázek 2: Služba v reálném provozu při použití HTTP serveru, k němuž se připojují klienti.
V případě, že je takovou službu nutné naškálovat, je to pochopitelně možné, i když v poněkud omezeném rozsahu (této problematice se budeme podrobněji věnovat v navazujících kapitolách):
Obrázek 3: Jedna z možností škálování monolitické služby, kdy HTTP server současně zajišťuje load balancing.
Jeden z problémů při škálování monolitických služeb je jejich příliš velká granularita a z toho plynoucí větší náklady na HW či na prostředky dostupné v cloudu. Taktéž bývá obtížné či prakticky nemožné vybalancovat požadavky na potřebnou kapacitu operační paměti, výpočetní výkon mikroprocesoru, rychlost vstupně-výstupních operací a kapacitu síťového připojení. Totéž lze říci o případu, kdy aplikace využívá jedinou databázi a potřebuje ji horizontálně či vertikálně naškálovat.
4. Koncepty, na nichž jsou postaveny mikroslužby
Monolitické služby se v praxi používají už několik desítek let a vývojáři i administrátoři v tomto období postupně zjišťovali, jaké jsou limity této architektury, a to jak z hlediska rychlosti vývoje, kvality služby, její udržovatelnosti a rychlosti, tak i s ohledem na dostupnost takových služeb. Postupně rostoucí složitost aplikací vedla ke vzniku nových konceptů architektury služeb, které by (pochopitelně v ideálním případě) měly odstranit největší problémy klasických monolitických služeb a současně nepřinést mnoho problémů nových. Výsledný koncept, či možná lepe řečeno sada konceptů, principů a idiomů, byl pojmenován mikroslužby; někdy se též setkáme s označením MOA (Microservice Oriented Architecture), což je vtípek vycházející ze zkratky SOA (Service Oriented Architecture)).
Obrázek 4: Mnoho monolitických služeb se snaží nabídnout funkce, které spolu prakticky vůbec nesouvisí.
Samotná základní myšlenka, na níž jsou mikroslužby postaveny, vlastně není nijak objevná – celá aplikace se skládá z obecně většího počtu několika služeb či dokonce několika desítek takzvaných mikroslužeb, přičemž každá taková mikroslužba má přesně definovanou roli (většinou pouze jednu!), běží v samostatném procesu (procesech) a komunikuje buď přímo či nepřímo s ostatními mikroslužbami, typicky s využitím nějakého standardního protokolu (REST API přes HTTP a HTTPS popř. nějaký protokol pro messaging). Povšimněte si, že tato myšlenka skutečně není nijak nová, protože na velmi podobných principech je založen i celý Unix s mnoha nástroji, z nichž každý má přísně omezenou roli, ovšem tuto roli zvládá velmi dobře. I samotná myšlenka komunikace mikroslužeb mezi sebou není nová – opět ji podporuje Unix se svými rourami, pojmenovanými rourami, sockety a frontami zpráv. Mikroslužby tento lety prověřený koncept rozšiřují do systému s větším množstvím počítačů a systémů (popř. kontejnerizovaných systémů).
Partner seriálu o mikroslužbách
V IGNUM mají rádi technologie a staví na nich vlastní mikroslužby, díky kterým je registrace a správa domén, hostingů a e-mailů pro zákazníky hračka. Vymýšlet jednoduchá řešení pro obsluhu složitých systémů a uvádět je v život je výzva. Společnost IGNUM miluje mikroslužby a je proto hrdým partnerem tohoto seriálu.
Důležité je, že každou z takto navržených mikroslužeb je možné vyvíjet, nasazovat, aktualizovat a pochopitelně i restartovat samostatně, v ideálním případě takovým způsobem, aby to nezasáhlo ostatní součásti vyvíjené aplikace. I možnosti škálování jsou lepší díky jemné granularitě jednotlivých mikroslužeb.
Dále se u mikroslužeb velmi často setkáme s použitím systémů pro automatizaci jejich nasazení a aktualizaci, protože s rostoucím počtem mikroslužeb se stává velmi neefektivní či dokonce nemožná jejich manuální správa. Automatizace se pochopitelně týká i testování mikroslužeb, samotnému vývoji integračních testů atd. Tomuto velmi důležitému tématu se budeme věnovat v dalších částech tohoto seriálu.
5. Myšlenka ze světa Unixu: smart endpoints and dumb pipes
V předchozí kapitole jsme se zmínili o tom, že koncept mikroslužeb má mnoho společného s filozofií Unixových nástrojů. Z Unixu pochází i další princip, který se uplatnil v mikroslužbách. Martin Fowler tento princip nazval „smart endpoints and dumb pipes“. Ve stručnosti se jedná o to, že jednotlivé mikroslužby se samy interně starají o validaci vstupních dat, aplikaci transformací dat, atd. Z pohledu uživatelů takto navržených mikroslužeb se jedná o operace prováděné uvnitř mikroslužeb (ty jsou, nebo by alespoň při jejich správném návrhu měly být, zapouzdřeny). Na druhé straně zvolený komunikační mechanismus (pipe), což může být například protokol HTTP, žádné podobné operace, jakými jsou validace či transformace dat, neprovádí, podobně jako je v Unixu NEprovádí klasická roura (taktéž pipe), která pouze zajišťuje přenos dat mezi dvojicí procesů. Díky tomu jsou z celé architektury aplikace odstraněny zbytečně složité věci, které se týkají jak používaných nástrojů, tak i knihoven, způsobů nasazení mikroslužeb atd.
Obrázek 5: Jednotlivé mikroslužby mezi sebou mohou komunikovat například s využitím protokolu HTTP (REST API), STOMP atd.
6. Decentralizace na všech úrovních, škálování
Při použití mikroslužeb se taktéž do značné míry využívá konceptu decentralizace. Samozřejmě se to týká především samotných mikroslužeb, ovšem nesmíme zapomenout ani na ty mikroslužby, které potřebují využít nějakou databázi. V ideálním případě jsou i databáze rozděleny a decentralizovány, což ovšem není vždy lehký úkol, protože je nutné zajistit validitu i dostupnost dat pro další mikroslužby.
Velkou předností mikroslužeb je jejich dobrá škálovatelnost, která plyne z toho, že mikroslužby mají oproti monolitické aplikaci jemnější granularitu. Rozdíly mezi naškálováním monolitické aplikace a aplikace založené na mikroslužbách jsou znázorněny na následující dvojici obrázků.
Obrázek 6: V levé polovině je znázorněna monolitická služba, v pravé polovině pak aplikace složená z několika mikroslužeb. Plocha jednotlivých obrazců může například znázorňovat paměťové požadavky, potřebný výpočetní výkon atd. atd.
Obrázek 7: V případě, že se nám podaří získat výkonnější počítač, můžeme v případě monolitické služby provést její naškálování, ovšem jen 2× pro celou službu. Bílá plocha (výkon, paměť) zůstane nevyužita. Naproti tomu mikroslužby můžeme „naskládat“ s větší svobodou; můžeme se například rozhodnout, která mikroslužba bude naškálována vícekrát a kterou postačí mít v systému pouze jedenkrát. Bílá plocha je zde pochopitelně menší.
7. Automatizace při nasazování, testování a provozování mikroslužeb
U mikroslužeb hrají velkou roli nástroje určené pro jejich nasazování, testování, provozování a v neposlední řadě taktéž pro monitoring jejich činnosti. Toto téma je velmi rozsáhlé a nabídka nástrojů velká (a jedná se mnohdy o komplexní nástroje), proto se tomuto tématu budeme podrobněji věnovat v dalších částech tohoto seriálu.
8. Další vybrané přednosti mikroslužeb
Mezi další vybrané přednosti mikroslužeb patří například:
- Možnost souběžného vývoje jednotlivých částí aplikace různými týmy.
- V podstatě automatické přijetí myšlenek, na nichž stojí CI/CD.
- Samotné API mikroslužeb je většinou tak jednoduché, že ho vývojář dokáže udržet v hlavě.
- Taktéž je možné jednotlivé služby vyvíjet v různých programovacích jazycích, což může být výhodné v případě, že aplikaci vyvíjí několik týmů.
- Samozřejmě sem spadá i mnohem lepší možnosti distribuce mikroslužeb mezi více servery s možností replikace.
- Nesmíme zapomenout ani na testování mikroslužeb, které může probíhat na několika úrovních testování mikroslužeb sice není snadnější, než je tomu v případě monolitické aplikace, ovšem může být (podobně jako samotný vývoj mikroslužeb) vhodným způsobem škálováno.
9. A pochopitelně i některé zápory
V IT, ostatně podobně jako i v dalších oborech, platí Heinleinovo pravidlo nejízda („není jídlo zdarma“), proto mají i mikroslužby mnoho záporů:
- Nemusí se jednat o dobré řešení pro menší vývojové týmy, protože se vyžadují větší znalosti a více rolí, než při nasazení monolitických služeb na (aplikační) servery.
- Celý systém je fragmentovaný a je nutné zajistit spojení jednotlivých částí, vytvořit systém pro vyhledávání služeb, jejich monitoringu atd.
- Prozatím neexistence jednotných návrhových vzorů popř. standardů.
- Pokud je systém špatně navržen, bude výpadek jedné mikroslužby znamenat výpadek celého systému.
- Úpravy a změny v rozhraní jednotlivých mikroslužeb je nutné nějakým způsobem plánovat, verzovat atd., protože opět může dojít k velkým výpadkům aplikace.
- Komunikace mezi procesy (každá mikroslužba je jeden proces), které mnohdy běží na jiném počítači, je pochopitelně pomalejší, než interprocesová komunikace (což je přímé volání funkcí a metod).
- Celý systém je nutné monitorovat, aby se předcházelo nežádoucím výpadkům, zejména pokud je nějaká část systému kritická (SFoF – single point of failure).
Příklad výpadku systému založeného na mikroslužbách a současně i na cloudovém řešení: A Closer Look at the Christmas Eve Outage.
10. Synchronní vs. asynchronní volání
„Since cloud-based applications are also Internet-based applications, many developers new to the cloud scene are intrinsically approaching each service design as simply micro-web-servers. Since the public interface for an API level service uses REST with JSON packets, it’s reasonable to utilize this format for each of the internal services, too.“
Ne vždy je vhodné používat REST API pro komunikaci mezi všemi mikroslužbami. Typicky například message brokery používají vlastní efektivnější protokoly, ovšem i v dalších situacích je dobré se zamyslet, zda protokol založený na principu dotaz-odpověď je to nejlepší v daném okamžiku a pro daný problém. Podobně je možné JSON nahradit například BSONem, protocol buffers atd., podle konkrétní situace.
11. Message brokery
V souvislosti s asynchronním voláním popř. vůbec s asynchronním zpracováním úloh, se musíme zmínit i o message brokerech, které se v architektuře s mikroslužbami pochopitelně taktéž uplatní. Tomuto tématu se podrobněji věnujeme v samostatném seriálu, v němž jsme si již popsali některé často používané implementace message brokerů, zejména projekty Redis Queue, Celery, RabbitMQ a ApacheMQ (popř. jeho novější variantu Artemis). Kromě klasických message brokerů se setkáme i s použitím tzv. streamingu podporovaného systémem NATS a pravděpodobně nejpopulárnějším nástrojem v této oblasti – Apache Kafkou.
Obrázek 8: Interní konfigurovatelná struktura systému RabbitMQ. Jak producenti, tak i konzumenti mohou být realizováni formou mikroslužeb.
S message brokery se komunikuje s využitím několika široce podporovaných protokolů, zejména protokolu STOMP (Streaming Text Oriented Messaging Protocol), MQTT (MQTT is a machine-to-machine connectivity protocol) a AMQP (Advanced Message Queuing Protocol).
Obrázek 9: Jedna z možných konfigurací rozvětvení. První směrovač (exchange) zkopíruje přijatou zprávu do tří front. Poslední (čtvrtá) fronta není v tomto případě nijak využita – rozvětvení se provádí jen do předem vybraných front.
12. Časté omyly, kterých se vývojáři dopouští (nejenom) při tvorbě mikroslužeb
Při vývoji mikroslužeb se samozřejmě nevyhneme mnoha omylům, které mohou zapříčinit například problémy s výkonností popř. dokonce nekonzistencí dat či časté výpadky celé aplikace. Velmi pěkně jsou některé omyly shrnuty ve videu 10 Tips for failing badly at Microservices by David Schmitz a postupně se jimi budeme zabývat v navazujících částech tohoto seriálu. V dalších kapitolách se zmíním o některých základních problémech, s nimiž se setkáme již na samotném začátku návrhu architektury aplikace. Tyto problémy souvisí se dvěma důležitými prvky, bez nichž se aplikace většinou neobejdou – počítačová síť a databáze (či obecněji datová úložiště).
13. Síť jakožto problematický prvek
Mnoho omylů při návrhu a nasazování (nejenom) mikroslužeb vychází ze samotného principu konstrukce a fungování počítačových sítí. Z hlediska návrhu aplikace je síť – a velká (kritická) závislost celé architektury na síti – skutečně velmi problematická, protože architektura aplikace založené na mikroslužbách spadá do kategorie distribuovaných aplikací. Mezi velmi časté omyly patří například následující předpoklady, které shrnul L. Peter Deutsch ještě v dobách existence společnosti Sun Microsystems (ani jeden z těchto předpokladů pochopitelně neplatí):
- Síť je spolehlivá
- Zpoždění při přenosu zpráv je nulové či velmi nízké
- Přenosová kapacita je nekonečná či dostatečně vysoká
- Síť je bezpečná
- Topologie sítě se nemění
- O síť se stará pouze jeden (dohledatelný) administrátor
- Cena přenosu dat je nulová či prakticky nulová
- Síť je homogenní
Největší problém – alespoň podle mého názoru – spočívá v tom, že výše uvedená (chybná) tvrzení někdy mohou (částečně) platit, typicky ve chvíli, kdy vývojáři mají k dispozici kvalitní vybavení a vyvíjí aplikaci na lokální síti. Ovšem v reálném provozu se dříve či později všechny nepěkné vlastnosti sítě ukážou (většinou v ten nejnevhodnější okamžik).
14. Špatné uplatnění konceptu mikroslužeb
Někdy se setkáme i s kombinací komplexnosti architektury založené na mikroslužbách s nepružností a „křehkostí“ monolitických služeb. Ve výše zmíněném videu je ukázán možná velmi typický příklad – aplikace sice používá mikroslužby, ale samotné UI je monolitické; v podstatě jediná dynamicky generovaná stránka (dnes populární SPA). Problémem zde je především fakt, že mnoho požadavků na změnu v UI (přidání nějakého atributu) je nutné nějakým způsobem reflektovat i v mikroslužbách, ale nemusí být zcela patrné, ve kterých.
15. Sdílení databáze mezi mikroslužbami
V případě, že je v aplikaci založené na mikroslužbách použita databáze, která je sdílená mezi jednotlivými mikroslužbami, může se stát, že tento návrh povede ke špatné funkci aplikace jako celku, a to například z hlediska škálovatelnosti, dostupnosti či stability. Jádro problému tohoto návrhu totiž spočívá v tom, že se porušil jeden z principů mikroslužeb – zajistit co nejmenší závislosti mezi jednotlivými mikroslužbami. A to, že dvě či více mikroslužeb přistupuje ke stejné databázi, je pochopitelně velká závislost. Při snaze o rozdělení databáze na menší celky je vždy důležité si uvědomit, která mikroslužba je skutečným vlastníkem onoho menšího celku (zákazníci, prodávané výrobky, sklad, logy, B2B transakce atd.)
16. SOA versus mikroslužby
Ještě před vznikem konceptu mikroslužeb se začaly používat aplikace navržené s využitím metodologie SOA neboli Service Oriented Architecture. I metodologie SOA je založena na rozložení aplikace na jednotlivé komponenty, které by měly být na sobě nezávislé a měly by spolu komunikovat. A i zde se doporučuje jednotlivé komponenty navrhovat tak, aby byly v ideálním případě bezstavové, což zjednodušuje například škálování, náhradu komponenty při jejím výpadku apod. Na mikroslužby – někdo je v tomto kontextu nazývá MOA (Microservices Oriented Architecture) – se můžeme dívat jako na jednu z extrémnějších (v pozitivním slova smyslu) variant metodologie SOA, kdy se klade ještě větší důraz na rozdělení architektury na menší části a taktéž na to, aby bylo možné jednotlivé části vyvíjet, nasazovat a testovat nezávisle na ostatních částech.
Navíc se zjednodušila i samotná metodika, protože v SOA jsou definovány čtyři typy služeb (business, enterprise, application a infrastructure), zatímco u mikroslužeb se většinou rozlišují jen dva typy služeb (functional a infrastructure), popř. se takové rozlišení ani nepoužívá.
Pokud se podíváme na architekturu typické SOA aplikace a aplikace založené na mikroslužbách, můžeme vidět několik rozdílů ve způsobu nasazení jednotlivých komponent. U mikroslužeb typicky odpadá použití aplikačního serveru, protože je to zbytečně „těžkotonážní“ nástroj:
| SOA | Mikroslužby |
|---|---|
| Služba a její API | |
| Aplikace | |
| Aplikační server | Služba a její API |
| Prostředí pro běh (JVM atd.) | Prostředí pro běh |
| Operační systém | Operační systém |
| Hypervisor | Hypervisor |
| Datové úložiště | Datové úložiště |
| Síťové rozhraní | Síťové rozhraní |
17. Rozdíly v přístupu SOA a MSA
Největší rozdíly mezi koncepty SOA a MSA však nalezneme v přístupu (možná můžeme říci že dokonce v ideologii), které jsou vývojovými týmy dodržovány. Ostatně to je patrné i z následující tabulky, v níž jsou některé rozdíly vypsány:
| SOA | MSA |
|---|---|
| spíše hrubší granularita služeb („mikromonolity“) | jemnější granularita služeb |
| zaměření na standardizaci procesů, nástrojů atd. | zaměření na spolupráci lidí a možnost svobodného výběru technologií |
| použití ESB (Enterprise Service Bus) | jednoduché systémy pro posílání zpráv |
| podpora většího množství protokolů pro přenos zpráv | zaměření na použití jednoduchých protokolů (HTTP, STOMP, …) |
| založeno na jednom programovacím jazyku a sadě knihoven | volnost výběru jazyka i knihoven podle potřeby |
| běh ve více vláknech | typicky běh v jednom vláknu s non-locking I/O, použití zelených vláken |
| služby dělené podle business požadavků | dělení spíše podle kontextu |
| jediná databáze pro celou aplikaci | každá mikroslužba používá vlastní datové úložiště |
| požadavek na změnu: úprava (mikro)monolitu | požadavek na změnu: vytvoření nové mikroslužby |
18. Odkazy na Internetu
- Vision of a microservice revolution
https://www.jolie-lang.org/vision.html - Microservices : a definition of this new architectural term
https://martinfowler.com/articles/microservices.html - Mikroslužby
http://voho.eu/wiki/mikrosluzba/ - Microservice Prerequisites
https://martinfowler.com/bliki/MicroservicePrerequisites.html - Microservices in Practice, Part 1: Reality Check and Service Design (vyžaduje registraci)
https://ieeexplore.ieee.org/document/7819415 - Microservice Trade-Offs
https://www.martinfowler.com/articles/microservice-trade-offs.html - What is a microservice? (from a linguistic point of view)
http://claudioguidi.blogspot.com/2017/03/what-microservice-from-linguisitc.html - Microservices (Wikipedia)
https://en.wikipedia.org/wiki/Microservices - Fallacies of distributed computing (Wikipedia)
https://en.wikipedia.org/wiki/Fallacies_of_distributed_computing - Service (systems architecture)
https://en.wikipedia.org/wiki/Service_(systems_architecture) - Microservices in a Nutshell
https://www.thoughtworks.com/insights/blog/microservices-nutshell - What is Microservices?
https://smartbear.com/solutions/microservices/ - Mastering Chaos – A Netflix Guide to Microservices
https://www.youtube.com/watch?v=CZ3wIuvmHeM&t=17s - Messaging in Microservice Architecture
https://www.youtube.com/watch?v=MkQWQ5f-SEY - Pattern: Messaging
https://microservices.io/patterns/communication-style/messaging.html - Microservices Messaging: Why REST Isn’t Always the Best Choice
https://blog.codeship.com/microservices-messaging-rest-isnt-always-best-choice/ - Protocol buffers
https://developers.google.com/protocol-buffers/ - BSON
http://bsonspec.org/ - Apache Avro!
https://avro.apache.org/ - REST vs Messaging for Microservices – Which One is Best?
https://solace.com/blog/experience-awesomeness-event-driven-microservices/ - How did we end up here?
https://gotocon.com/dl/goto-chicago-2015/slides/MartinThompson_and_ToddMontgomery_HowDidWeEndUpHere.pdf - Scaling microservices with message queues to handle data bursts
https://read.acloud.guru/scaling-microservices-with-message-queue-2d389be5b139 - Microservices: What are smart endpoints and dumb pipes?
https://stackoverflow.com/questions/26616962/microservices-what-are-smart-endpoints-and-dumb-pipes - Common Object Request Broker Architecture
https://en.wikipedia.org/wiki/Common_Object_Request_Broker_Architecture - Enterprise service bus
https://en.wikipedia.org/wiki/Enterprise_service_bus - Microservices vs SOA : What’s the Difference
https://www.edureka.co/blog/microservices-vs-soa/ - Pravda o SOA
https://businessworld.cz/reseni-a-realizace/pravda-o-soa-2980 - Is it a good idea for Microservices to share a common database?
https://www.quora.com/Is-it-a-good-idea-for-Microservices-to-share-a-common-database - Pattern: Shared database
https://microservices.io/patterns/data/shared-database.html - Is a Shared Database in Microservices Actually an Anti-pattern?
https://hackernoon.com/is-shared-database-in-microservices-actually-anti-pattern-8cc2536adfe4 - Shared database in microservices is a problem, yep
https://ayende.com/blog/186914-A/shared-database-in-microservices-is-a-problem-yep - Microservices with shared database? using multiple ORM's?
https://stackoverflow.com/questions/43612866/microservices-with-shared-database-using-multiple-orms
ČLÁNKY DO MAILU