Читать книгу Mikroserwisy. Wzorce z przykładami w języku Java - Chris Richardson - Страница 6

Jednym z moich ulubionych cytatów jest

Przyszłość jest już dziś, tylko nierówno rozłożona.

William Gibson, autor fantastyki naukowej

Istotą tego cytatu jest to, że nowe pomysły i technologie potrzebują czasu, aby rozpowszechnić się w społeczności i zostać ogólnie przyjęte. Dobrym przykładem powolnego rozprzestrzeniania się pomysłów jest historia odkrywania mikrousług. Zaczęło się w 2006 r., kiedy zainspirowany przemówieniem ewangelisty AWS, podążyłem ścieżką, która ostatecznie doprowadziła mnie do stworzenia Cloud Foundry. (Jedyną wspólną cechą z dzisiejszym Cloud Foundry jest nazwa.) Cloud Foundry to platforma odgrywająca rolę usługi (PaaS) do automatyzacji wdrażania aplikacji Java na EC2. Jak każda inna aplikacja, którą stworzyłem w Javie, moja Cloud Foundry miała architekturę monolityczną składającą się z jednego pliku WAR (Java Web Application Archive).

Połączenie różnorodnego i złożonego zestawu funkcji, takich jak udostępnianie, konfiguracja, monitorowanie i zarządzanie w monolicie, stworzyło wyzwania rozwojowe i operacyjne. Nie można było na przykład zmienić interfejsu użytkownika bez testowania i ponownego wdrażania całej aplikacji. W związku z tym, że komponent monitorowania i zarządzania opierał się na silniku złożonego przetwarzania zdarzeń (Complex Event Processing, CEP), który utrzymywał stan w pamięci, nie mogliśmy uruchomić wielu instancji aplikacji! To było żenujące, ale to, co mogę powiedzieć, to, że jestem programistą i że „kto jest bez grzechu, niech pierwszy rzuci kamieniem”.

Najwyraźniej aplikacja szybko przerosła swoją monolityczną architekturę. Ale jaka była alternatywa? Po pewnym czasie odpowiedź pojawiła się w społeczności programistów w firmach, takich jak eBay czy Amazon. Na przykład Amazon zaczął migrować z monolitu około 2002 r. (https://plus.google.com/110981030061712822816/posts/AaygmbzVeRq). Nowa architektura zastąpiła monolit kolekcją luźno powiązanych usług. Usługi są własnością tego, kogo Amazon nazywa two pizza teams, czyli zespołów wystarczająco małych, aby mogły zostać nakarmione dwiema pizzami.

Amazon zastosował tę architekturę, żeby przyspieszyć tempo opracowywania oprogramowania, tak by firma mogła szybciej wprowadzać innowacje i skuteczniej konkurować na rynku. Wyniki są imponujące: podobno Amazon wprowadza zmiany produkcyjne co 11,6 sekundy!

Na początku 2010 r., po moim przejściu do innych projektów, przyszłość architektury oprogramowania w końcu mnie dopadła. Właśnie wtedy przeczytałem książkę The Art of Scalability: Scalable Web Architecture, Processes and Organizations for the Modern Enterprise (Addison-Wesley Professional, 2009) autorstwa Michaela T. Fishera i Martina L. Abbotta. Kluczową ideą w tej książce jest sześcian skal, który, jak opisano w rozdziale 2, jest trójwymiarowym modelem skalowania aplikacji. Skalowanie w osi Y określone przez dekompozycję funkcjonalną rozkłada aplikację na usługi. Z perspektywy czasu było to dość oczywiste, ale dla mnie był to moment „aha”! Mógłbym rozwiązać problemy, przed którymi stanąłem dwa lata wcześniej, i zaprojektować Cloud Foundry jako zestaw usług!

W kwietniu 2012 r. wygłosiłem swoje pierwsze przemówienie na temat tego podejścia architektonicznego, zatytułowane „Decomposing Applications of Deployability and Scalability” (www.slideshare.net/chris.e.richardson/decomposing-applications-for-scalability-and-deployability-april-2012). W tamtym czasie nie było ogólnie przyjętego terminu na tego rodzaju architekturę. Czasami nazywałem to modułową architekturą poliglotyczną, ponieważ usługi można było pisać w różnych językach.

Ale w przypadku innego przykładu tego, jak przyszłość jest nierównomiernie rozłożona, termin „mikroserwis” został użyty podczas warsztatów architektury oprogramowania w 2011 r. do opisania tego rodzaju architektury (https://en.wikipedia.org/wiki/Microservices). Po raz pierwszy zetknąłem się z tym terminem wtedy, kiedy usłyszałem, jak Fred George wygłasza przemówienie na Oredevie 2013. I podobało mi się to!

W styczniu 2014 r. utworzyłem witrynę https://microservices.io w celu dokumentowania architektury i wzorców projektowych, jakie napotkałem. Następnie, w marcu 2014 r., James Lewis i Martin Fowler opublikowali post na blogu na temat mikroserwisów (https://martinfowler.com/articles/microservices.html). Popularyzując termin „mikroserwisy”, post na blogu spowodował, że społeczność programistów skonsolidowała się wokół tej koncepcji.

Idea małych, luźno powiązanych zespołów, szybko i niezawodnie rozwijających się i dostarczających mikroserwisy powoli rozpowszechnia się w społeczności programistów. Ale jest prawdopodobne, że ta wizja przyszłości różni się od współczesnej rzeczywistości. Obecnie wielkie, krytyczne biznesowo aplikacje firm to zazwyczaj duże monolity opracowywane przez duże zespoły. Wydania oprogramowania zdarzają się rzadko i często są bolesne dla wszystkich zainteresowanych. Dział IT często stara się nadążyć za potrzebami firmy. Możemy wtedy zastanawiać się, jak do licha można zastosować w takim przypadku architekturę mikroserwisową.

Celem tej książki jest odpowiedź na to pytanie. Pozwoli ona dobrze zrozumieć architekturę mikroserwisową, jej zalety i wady oraz kiedy z niej korzystać. Książka opisuje, w jaki sposób rozwiązać liczne wyzwania projektowe, w tym wyzwania zarządzania rozproszonymi danymi. Obejmuje także sposób refaktoryzacji aplikacji monolitycznej do architektury mikroserwisowej. Ale ta książka nie jest manifestem mikroserwisów. Zamiast tego jest zorganizowana wokół kolekcji wzorców. Wzorzec jest rozwiązaniem wielokrotnego użytku dla problemu występującego w określonym kontekście. Piękno wzorca polega na tym, że oprócz opisu zalet rozwiązania opisuje on także wady i problemy, które należy rozwiązać, aby pomyślnie wdrożyć rozwiązanie. Z mojego doświadczenia wynika, że tego rodzaju obiektywizm podczas myślenia o rozwiązaniach prowadzi do znacznie lepszego podejmowania decyzji. Mam nadzieję, że spodoba ci się ta książka i że nauczy cię, jak skutecznie rozwijać mikroserwisy.