TABLE OF CONTENTS:
Według raportu “2022 Service Mesh Adoption Survey” 85% firm modernizuje swoje systemy w kierunku architektury mikroserwisów. Co sprawia, że monolityczne podejście do tworzenia aplikacji odchodzi w niepamięć? Efektywność, elastyczność i minimalizowanie ryzyka – trzy cechy, które charakteryzują to, już nie tak bardzo nowe, podejście do wytwarzania oprogramowania. Jednak istnieje w świecie IT ogromna ilość systemów czy aplikacji, które w przeciwieństwie do mikroserwisów, zostały wytworzone jako jeden wielki monolit, albo inaczej – monolityczny kloc. I żaden developer ani DevOps nie powinien być tym stwierdzeniem zaskoczony, wręcz przeciwnie. Mikroserwisy w odróżnieniu do monolitycznej architektury, umożliwiają łatwe dostosowanie się do szybko zmieniających się wymagań biznesowych.
Przede wszystkim luźno połączone mikroserwisy, które składają się na całość systemu, to łatwiejsze, szybsze i częstsze deploymenty. Dzięki tej architekturze nie musimy robić deployu wszystkiego, a tylko tych serwisów, które zostały zmienione. Oszczędność czasu, zasobów, a dzięki temu budżetu – biznes na pewno będzie zadowolony. Mikroserwisy sprzyjają też skalowalności systemów. Możemy dostosowywać jedynie te, które potrzebują większej mocy obliczeniowej.
Dzięki wyodrębnianiu serwisów możemy łatwiej je testować – o korzyściach nie będę wspominać, bo są oczywiste, zarówno z technicznego jak i biznesowego punktu widzenia. Warto jednak wspomnieć o jednym, istotnym szczególnie dla nas punkcie – potencjalne błędy są izolowane do poszczególnych mikroserwisów, dzięki czemu nie musimy szukać źródła problemów po całym (często bardzo dużym) systemie.
Może się wydawać, szczególnie po przeczytaniu powyższych pochwał, że nie. Przekornie – wady mikroserwisów istnieją, jednak ujawniają się, kiedy nie podchodzimy do tworzenia architektury z wizją i planem. Design for fail powinien wyznaczać kierunek rozwoju oprogramowania, a zespół projektowy działać interdyscyplinarnie. Przy wdrażaniu mikroserwisów warto pamiętać jeszcze o jednym – zdrowym rozsądku. Architektura mikroserwisowa nie jest niezbędna w prostych aplikacjach lub w początkowych fazach tworzenia projektu (np. Proof of Concept). Raczej nie zauważymy tam jej zalet, a tylko wprowadzimy niepotrzebną (na tym etapie) komplikację.
Świat IT poznał Kubernetesa 9 lat temu, gdy Google otworzył ten projekt jako open-source, więc nie jest to żadna nowość. Przez ten czas Kubernetes bardzo mocno się rozwinął i coraz więcej firm przenosi swoje workloady właśnie na tę platformę. Jeśli jednak chodzi o adaptację tej technologii w organizacjach, to jest jeszcze ogromny potencjał, podobnie jak w przypadku architektury mikroserwisowej. Trend wzrostowy z pewnością zostanie utrzymany – biznes w chmurze to przyszłość, ale i teraźniejszość.
Jak sama nazwa wskazuje, jest to sposób na tworzenie serwisów czy aplikacji bez zajmowania (czy może lepiej przejmowania się) serwerami, na których miałyby być one uruchamiane. Dostawcy chmury publicznej (Google Cloud Platform, AWS, Azure) mają w swojej ofercie wiele usług pozwalających na uruchomienie własnego kodu, w postaci pojedynczych funkcji lub całych kontenerów.
Takie podejście pozwala na:
Szacuje się, że rynek serverless computing osiągnie wielkość 21 mld USD w roku 2025 i 30 mld USD w roku 2030. Dla porównania w 2020 było to “tylko” 7,5 mld USD.
Szerokopojęte technologie devopsowe rozwijają się w zawrotnym tempie, by sprostać wymogom, jakie stawia przed nimi biznes.
Kluczowymi powodami wzrostu popularności technologii devopsowych są:
Mikroserwisy i technologie z nimi związane mogą ułatwić spełnienie wymogów biznesowych oraz dać impuls do szybszego rozwoju systemów czy organizacji, które zdecydują się je zaadaptować u siebie.
