Tradycyjna monolityczna architektura aplikacji łączyła całą funkcjonalność w jednej usłudze. Bardzo utrudniało to wdrażanie nowych funkcji, bo wymagało długiego przestoju, co ograniczało możliwość aktualizowania aplikacji. Skalowanie takich aplikacji jest drogie, bo trzeba skalować całą aplikację, nawet jeśli duży ruch trafia tylko na jedną usługę.

Wejście chmury zrewolucjonizowało sposób, w jaki projektujemy, planujemy architekturę i wdrażamy aplikacje. Pomogło w szybszych wdrożeniach, lepszej dostępności, skalowaniu na żądanie i krótszym czasie wejścia na rynek. 

Tak właśnie pojawia się aplikacja oparta na mikroserwisach - architektura, której celem jest tworzenie małych, odizolowanych usług wdrażanych i skalowanych niezależnie od siebie, co zwiększa elastyczność.

Dowiedz się o tym więcej poniżej!

Czym są mikroserwisy?

Mikroserwisy - znane też jako architektura mikroserwisowa - to styl architektoniczny, w którym aplikacja jest zbiorem usług. Łatwych w utrzymaniu i testowaniu. Luźno powiązanych. Zdolnych do samodzielnego wdrożenia. Zorganizowanych wokół możliwości biznesowych.

Idea mikroserwisów polega na skupieniu się na tworzeniu osobnych usług, które robią jedną rzecz dobrze.

Mówiąc prosto, mikroserwisy to podejście do rozwiązywania dużego lub złożonego problemu biznesowego przy pomocy zestawu mniejszych i prostszych usług działających razem; mikroserwis uruchamia własny, unikalny proces, który przyczynia się do nadrzędnego celu biznesowego.

Czym jest architektura mikroserwisowa w .NET?

Ponownie: architektura mikroserwisowa to podejście do budowania aplikacji serwerowej jako zbioru małych usług. Każda usługa powinna działać we własnym procesie i komunikować się z innymi przy użyciu protokołów takich jak HTTP/HTTPS, WebSockets itd. Każdy element takiego szkieletu (czyli usługa) powinien być zaprojektowany jako samodzielna jednostka, którą da się wdrożyć niezależnie. Każdy mikroserwis musi mieć własny model danych domeny i logikę domenową, a może opierać się na różnych technologiach przechowywania danych. Co więcej, można go napisać w różnych językach programowania.

Kluczem do tworzenia mikroserwisów jest budowanie luźno powiązanych usług, dzięki czemu każdą usługę w aplikacji można niezależnie wdrażać, skalować i rozwijać. Jeśli mówimy o rozmiarze mikroserwisów, warto starać się, by były jak najmniejsze, ale z minimalną liczbą bezpośrednich zależności od innych mikroserwisów. Daje to długofalową elastyczność, skalowalność i lepsze utrzymanie w przyszłości.

Budowa drobnoziarnistej architektury opartej na mikroserwisach umożliwia ciągłą integrację (CI) i ciągłe dostarczanie (CD). Ułatwia to dokładanie nowych funkcji do działających już aplikacji. Możesz całkowicie zmienić jeden z mikroserwisów, by wdrożyć nową funkcjonalność, a nawet go zepsuć, nie uszkadzając całego zbudowanego systemu.

Wreszcie do każdego mikroserwisu możesz dodać testy jednostkowe, co ułatwi wykrycie problemów lub błędów w systemie, zanim trafią na produkcję. Nie trzeba wtedy sprawdzać całej aplikacji - wystarczy zdebugować mały fragment kodu, czyli bieżący mikroserwis.

Udane zbudowanie w pełni funkcjonalnej aplikacji mikroserwisowej i wdrożenie jej na konkretnej platformie do zarządzania mikroserwisami oznacza korzyści takie jak opłacalność, skalowalność i dostępność 24/7. Utrzymanie mikroserwisów w dobrej kondycji można osiągnąć, przenosząc instancje na sprawne maszyny wirtualne lub serwery platformy. Gdy więc oprogramowanie lub sprzęt, na którym działają, zawiedzie albo wymaga restartu w celu aktualizacji, system automatycznie przenosi je w bezpieczne miejsce, gdzie mogą dalej działać. 

Nawiasem mówiąc, mikroserwisy można w ten sam sposób skalować, po prostu kopiując usługę na nową maszynę wirtualną i uruchamiając kolejną instancję.

Zasady przewodnie mikroserwisów

Model oparty na obszarze biznesowym

Architektura mikroserwisowa pozwala podzielić możliwości systemu na różne domeny. Każda domena skupia się na jednej rzeczy i związanej z nią logice, może łatwo i niezależnie przejść na kolejną wersję oraz niezależnie się skalować, gdy zajdzie taka potrzeba.

Kultura automatyzacji

Ponieważ każdą usługę budujemy, testujemy, wdrażamy i śledzimy osobno, a liczba jednostek wdrożeniowych rośnie w porównaniu z architekturą monolityczną, musimy trzymać się kultury automatyzacji, tworząc ją pod ciągłą integrację i ciągłe dostarczanie.

Ukrywanie szczegółów implementacji

Mikroserwisy powinny być zaprojektowane tak, by nie ujawniać wewnętrznych szczegółów: ani implementacji technicznej, ani rządzących nią reguł biznesowych. Ograniczy to wzajemne powiązania i pomoże wprowadzać zmiany oraz usprawnienia bez wpływu na całą architekturę.

Decentralizacja

W tradycyjnych wdrożeniach monolitycznych oprogramowanie projektuje się pod jedną bazę danych z różnymi tabelami, a mikroserwisy projektuje się tak, by zarządzały własną bazą.

Niezależne wdrażanie

Aby w pełni skorzystać z tej architektury, mikroserwisy muszą być wdrażane niezależnie. Jeśli nie potrafisz tego zrobić, sprawdź aplikację pod kątem powiązań i je usuń.

Izolacja awarii

Skutki awarii są w architekturze mikroserwisowej mniejsze niż w monolicie, bo dotkną tylko konkretnych usług i tych z nimi powiązanych, podczas gdy pozostałe mogą działać dalej. Powiązane usługi powinny obsługiwać scenariusze takie jak brak odpowiedzi albo spowolnienie usługi, od której zależą.

Wysoka obserwowalność

Usługi powinny zbierać jak najwięcej informacji, by dało się analizować, co dzieje się w każdej z nich - na przykład logi zdarzeń i statystyki.

#1. Dostępność technologii związanych z mikroserwisami

Tradycyjne stosy technologiczne nie nadają się do wdrażania architektury mikroserwisowej. Każdy, kto interesuje się mikroserwisami, powie Ci, że „mikroserwisy są DZIŚ możliwe dzięki pojawieniu się kontenerów Docker”. 

Zgodzilibyśmy się z tym stwierdzeniem, ale dodalibyśmy, że trzeba też oddać sprawiedliwość technologiom PaaS. Ostatnio widzieliśmy kilka dużych przedsiębiorstw inwestujących w rozwiązania PaaS z zamiarem przejścia na architekturę mikroserwisową. Do udanego wdrożenia mikroserwisów konieczne jest danie sprawczości programiście (zespołowi) mikroserwisów. 

Zarówno technologia kontenerów Docker, jak i oferty PaaS dały zespołom technologicznym swobodę używania tego, co ma sens dla ich aplikacji - i to bez przechodzenia przez przestarzałe, biurokratyczne procesy dostarczania IT.

#2. Punkt malejących zwrotów z SOA

Przez ostatnią dekadę przedsiębiorstwa zainwestowały miliony w oprogramowanie budowane w oparciu o programy Service Oriented Architecture (SOA). W tej długiej dekadzie wdrażania SOA firmy wypracowały kompetencje, procesy i platformy (takie jak ESB). Wiele z nich doszło do punktu, w którym straciły kontrolę nad usługami na tych platformach SOA (ESB) - i choć umiejętności tworzenia i zarządzania usługami są, to elastyczność oczekiwana przez interesariuszy (klientów, biznes) jest nieosiągalna przez złożoną i monolityczną naturę usług budowanych na tych platformach. 

Innymi słowy, przedsiębiorstwa dotarły do punktu malejących zwrotów z SOA. Mikroserwisy postrzega się jako architekturę usług nowej generacji, która usuwa bolączki obecnego stanu SOA. 

Oczekuje się, że wdrożenie wzorca mikroserwisów (i technologii) na bazie SOA pozwoli zespołom deweloperskim zrealizować cyfrowe ambicje przedsiębiorstwa.

#3. Pionierzy i kaznodzieje mikroserwisów

Sukces Netflixa i Amazona w mikroserwisach to jeden z najczęściej omawianych przykładów tego, jak realne firmy korzystają z tego nowego wzorca architektonicznego. Firmy te nie tylko przyjęły praktyki mikroserwisowe, ale też podzieliły się wiedzą, a nawet narzędziami, ze społecznością technologiczną. Ich praktyczne pomysły zwiększyły wiarygodność tej społeczności. Do tego narzędzia stworzone przez te firmy pokazały luki, które trzeba wypełnić narzędziami automatyzacji.

#4. Powszechny DevOps

DevOps jest niezbędny do udanego wdrożenia mikroserwisów. Niemal każdy klient, z którym pracujemy, ma program DevOps. Firmy mają dziś do dyspozycji wiele narzędzi i technologii do budowy potoków ciągłej integracji, testów i dostarczania. Ta dojrzałość DevOps buduje w zespołach IT większą pewność, że poradzą sobie z budową i zarządzaniem aplikacjami opartymi na mikroserwisach.

#5. Szum tworzony przez dostawców technologii

Częstym motywem współczesnych konferencji są mikroserwisy oraz to, jak technologie oferowane przez danego dostawcę (sponsora) wspierają ich tworzenie i zarządzanie nimi. 

Jedną z obserwacji z tych konferencji było to, że każda sesja z mikroserwisami w tytule była wyprzedana. Blogi dostawców technologii pełne są dziś porad, jak budować mikroserwisy i zarządzać nimi przy użyciu ich produktów. 

Oczywiście cały ten marketing wielu dostawców zdecydowanie skłania decydentów IT do rozważenia przejścia na mikroserwisy.

Na koniec: raport O'Reilly z 2020 roku o wdrożeniach mikroserwisów pokazuje, że 92% organizacji odnosi z nimi sukces.

Jak podejść do budowy mikroserwisów w .NET? Jakie role i zasoby są potrzebne?

Jak pokazał poprzedni rozdział, przy inwestycji w architekturę mikroserwisową w .NET trzeba wziąć pod uwagę wiele rzeczy. Inna kwestia, tak podstawowa, że łatwo ją przeoczyć, to nie to, czy potrafisz stworzyć mikroserwis, ale jak powinieneś to robić z perspektywy biznesowej. 

Ponieważ ta decyzja mocno dotyczy wszystkich interesariuszy w firmie, przygotowaliśmy ten rozdział dla product ownerów i PM-ów, którzy nie tylko prowadzą zespół inżynierski ku swojej wizji technicznej, ale też kontaktują się z resztą biznesu. To wielowątkowe pytanie, więc zanurzmy się głębiej.

Zasoby ludzkie

Przejdźmy teraz do rekrutacji. Jak wiesz, zatrudnianie bardzo doświadczonych programistów .NET jest a) trudne; b) długotrwałe. 

Co więcej, każdy mikroserwis sam w sobie działa jak niezależna aplikacja, więc zespoły też muszą tak działać. 

Twórz osobne zespoły do pracy z różnymi mikroserwisami. Wymaga to też, by miały niezbędne umiejętności i narzędzia do samodzielnego rozwijania, wdrażania i zarządzania daną usługą. Zespoły muszą być wszechstronne i wystarczająco duże, by działać autonomicznie, nie tracąc czasu na komunikację.

Wybieraj programistów z mocnym zapleczem technicznym

Choć konkretny stos technologiczny może się różnić w zależności od istniejącej infrastruktury, dobry programista mikroserwisów w .NET musi mieć określone kwalifikacje. Oto przykład takich kwalifikacji od poziomu mid do seniora:

• zna wymagany język programowania (w naszym przypadku .NET);
• rozumie zasady DDD;
• solidnie rozumie usługi RESTful, programowanie sterowane zdarzeniami, proste magistrale komunikatów i strumienie zdarzeń.
• ma doświadczenie w komunikacji między systemami (REST, GraphQL, SOAP itd.).
• mile widziana chmura: AWS lub inni dostawcy, Docker, Kubernetes (EKS), RDS, S3.
• wcześniejsze doświadczenie z architekturą serverless będzie plusem.
• liderzy i osoby zarządzające potrzebują wiedzy z inżynierii systemów, architektury oprogramowania i podstawowych zasad projektowania, na których opiera się skalowalna i bezpieczna aplikacja.
• doświadczenie w procesach zwinnych (Scrum, Kanban itd.)
• dodatkowo, w małych i średnich projektach bez dedykowanego zespołu DevOps, praktyczne doświadczenie w budowie i wdrażaniu rozwiązań mikroserwisowych w chmurze będzie ogromnym atutem.

Wybieraj programistów o świetnych umiejętnościach interpersonalnych

Szukając programistów o konkretnych umiejętnościach technicznych, pamiętaj też, że muszą mieć określone kompetencje miękkie, by być skutecznymi w pracy z mikroserwisami.

• Mocne umiejętności analityczne i rozwiązywania problemów. Zdolność samodzielnego wskazania, przeanalizowania i rozwiązania problemu pomaga programistom pracować wydajniej;
• Nastawienie na ciągłą naukę. Mikroserwisy pozwalają wprowadzać nowe funkcje lub technologie niemal natychmiast. Programiści muszą więc być gotowi się uczyć i szybko wykorzystywać tę wiedzę w pracy.
• Angielski przynajmniej na poziomie upper-intermediate. Jeśli zlecasz budowę mikroserwisów na zewnątrz, dobry angielski to konieczność. Praca z mikroserwisami wymaga aktywnej współpracy między programistami, architektami, analitykami biznesowymi i innymi uczestnikami procesu.

Kolejne pytanie brzmi: ilu programistów zatrudnić? Sprawdźmy!

Struktura zespołu

Zrozumienie tego, co dzieje się przy przejściu z monolitu na mikroserwisy, jest kluczowe dla zrozumienia, jak działają procesy i jak buduje się zespoły.

Zaczynasz więc od istniejącej, zwykle ogromnej aplikacji legacy. 

1. Pierwszy etap to dekompozycja. Dzielisz istniejącą infrastrukturę na moduły lub części. Wciąż zachowujesz wszystkie powiązania w kodzie, ale sprawdzasz, czy nie ma duplikatów. Ten krok czyni kod stabilniejszym, szczuplejszym i łatwiejszym w utrzymaniu. 
2. Drugi etap to rozwiązanie węzła. Mówiąc prosto, zrywasz istniejące połączenia, zamieniając moduły w niezależne mikroserwisy. Ułatwia to zarządzanie częściami aplikacji (utrzymanie, wymiana itd.)

Zamiast dużej aplikacji programiści pracują więc z usługą o wąskiej funkcji i ściśle określonym miejscu w procesie biznesowym. 

Jak te zmiany wpływają na obciążenie programistów mikroserwisów i które role są kluczowe dla ich skutecznego tworzenia? Co powinien wiedzieć programista mikroserwisów?

Programiści mikroserwisów: role i obowiązki

Typowy skład zespołu przypomina ten z tradycyjnego wytwarzania oprogramowania. Przy mikroserwisach role różnią się jednak nieco.

Architekt oprogramowania

Przy tworzeniu mikroserwisów architekt oprogramowania (SA) odpowiada za budowę aplikacji mikroserwisowej. Musi nie tylko zaplanować podział i dekompozycję monolitu, ale też rozumieć potrzeby konkretnego obszaru biznesowego i odwzorować mikroserwisy na procesy w firmie. Architekt odpowiada również za wybór odpowiedniej metodyki i technologii dla magazynu zdarzeń, rejestru usług, wykrywania usług, kontenerów usług i ich wdrożenia. Wybiera też najbardziej odpowiednie metody integracji, takie jak bramy API dla rejestru usług, ograniczanie ruchu, orkiestracja itd.

Architekt pełni też rolę pojedynczego źródła prawdy (SPOT) w kwestiach pytań, wymagań i logiki biznesowej, a także ogólnej mapy drogowej.

Zespół produktowy

Ten zespół zwykle składa się z product ownera, product managerów, projektantów i analityków biznesowych, których zadaniem jest przełożenie potrzeb biznesowych na wymagania techniczne. Odpowiadają też za informowanie zespołów deweloperskich o potrzebach biznesu i zarządzanie budżetami zgodnie z bieżącymi potrzebami.

Zespół deweloperski

Aby odnieść sukces, każdy zespół musi odpowiadać za całościowe wytworzenie jednego lub dwóch mikroserwisów. Zespół powinien być mały (5-9 osób), autonomiczny i luźno powiązany. Im mniejsze usługi, tym lepsze możliwości (w tym utrzymywalność, testowalność i łatwość wdrażania). Jeśli pracujesz w Agile, w zespole znajdą się Scrum Master, programiści i inżynierowie QA.

Zespół DevOps/infrastruktury

W małym projekcie może wystarczyć jeden specjalista DevOps. Jeśli jednak mówimy o średnich i dużych projektach w rodzaju ERP, możesz potrzebować zespołu ekspertów od infrastruktury. Dbają oni nie tylko o CI/CD, ale też zarządzają takimi sprawami jak koszt środowiska.

DBA

W zależności od typu i wielkości projektów oraz obciążenia systemu możesz potrzebować usług administratora baz danych.

Przechodząc z monolitu, ustawiasz więc swoich programistów pod mikroserwisy, z którymi będą pracować.

Skala aktualizacji

Głównym elementem określania kosztu budowy aplikacji mikroserwisowych jest ustalenie zakresu modernizacji. Zawsze najlepiej zaczynać od małych rzeczy, bo to tanie i pozwala sprawdzić, czy aktualizacja działa. Mały start da Ci jasny obraz kosztu jednej fazy prac. Istnieje wiele narzędzi, które skutecznie utrzymują koszty w ryzach i pomagają zmieścić się w budżecie.

Koszty utrzymania

Gdy Twój zespół stworzy mikroserwis, staje się on Twoim dzieckiem. To Twoja odpowiedzialność, by o niego dbać i utrzymywać go w dobrym stanie. Jak przy każdym oprogramowaniu, trzeba usuwać pojawiające się błędy i problemy.

Poza utrzymaniem systemu Twój zespół odpowiada też za wprowadzanie potrzebnych usprawnień. Jeśli Twoja usługa pełni funkcję marketingową, zespół marketingu będzie chciał dodać do niej konkretne funkcje, by móc realizować swoje zadania.

Wypełnienie tych obowiązków zależy jednak od dostępnych mocy przerobowych. Utrzymanie oprogramowania to 75 procent całkowitego kosztu posiadania, co oznacza, że znaczna część czasu Twoich programistów idzie na utrzymanie.

W najprostszej definicji ukryty koszt mikroserwisów .NET Core to pieniądze wydawane na utrzymanie bardziej rozproszonego systemu, a można go rozbić na kilka kluczowych obszarów:

1. Zespół DevOps. Do zbudowania złożonego ekosystemu potrzebujesz sporej grupy ludzi, co oznacza, że koszt startu może być wyższy niż przy monolicie.
2. Zespół specjalny. Musisz mieć kilka osób, które będą stale monitorować system i reagować na wszelkie problemy.
3. Podwójny koszt zmiany. Ponieważ system jest rozbity na bardzo drobne mikroserwisy, nawet drobne prośby o zmianę mogą wymagać modyfikacji wielu usług.
4. Typowe błędy w wyborze usług. Branie odpowiedzialności za niewłaściwe rodzaje usług, które nie dają wystarczającej wartości biznesowej.

Kiedy używać mikroserwisów

Jak zdecydować, czy je stosować

Każdemu szumowi towarzyszy taka sama dawka euforii i rozczarowania. Bierze się to głównie z jednego: wskakiwania na modę tylko dlatego, że jest modna. 

Zaczynanie czegoś tylko dlatego, że robi to konkurencja, nie jest dobrym pomysłem. Twój biznes powinien korzystać ze strategii i rozwiązań pasujących do jego potrzeb. Dlatego warto się na chwilę zatrzymać i zastanowić, czy naprawdę potrzebujesz mikroserwisów.

Na początek zadaj sobie następujące pytania.

• Czy w pełni rozumiesz, czym są mikroserwisy i jak mogą wpłynąć na Twoje prace deweloperskie?
• Czy Twój biznes jest wystarczająco dojrzały, by wdrożyć mikroserwisy?
• Jak silne są Twoje praktyki dotyczące infrastruktury aplikacji?
• Czy masz sprawdzoną praktykę Agile lub DevOps?
• Czy Twój zespół zarządzania danymi ma kwalifikacje, by obsłużyć rejestrację? Jeśli nie, będzie tylko spowalniał to, co powinno być szybkim procesem.
• Czy Twój produkt jest sednem modelu biznesowego?
• Jakie są Twoje cele i wizja skalowania? Ta architektura powstała z myślą o skalowalności i jest idealna tylko wtedy, gdy masz przemyślany plan rozwoju zarówno produktu czy usługi, jak i rynku.
• Czy Twój model biznesowy został przetestowany?

Jeśli Twoje odpowiedzi Cię przekonają - niezależnie od strony - będziesz w stanie podejmować bardziej świadome decyzje.

Dla uproszczenia zebraliśmy kilka wskazówek, które pomogą zrozumieć, kiedy warto, a kiedy nie warto stosować mikroserwisów.

Używaj mikroserwisów, gdy...

Na dobry początek: oto sytuacje idealne, w których mikroserwisy mogą być lepsze od monolitycznych odpowiedników:

• Jeśli chcesz, by Twoja monolityczna aplikacja zyskała skalowalność, zwinność, łatwość zarządzania i szybkość dostarczania
• Gdy trzeba przepisać aplikacje legacy na nowoczesne języki programowania ​​lub stosy techniczne, by nadążyć za dzisiejszymi wymaganiami i rozwiązaniami biznesowymi.
• Gdy masz samodzielne aplikacje lub moduły biznesowe, które trzeba wykorzystać w różnych kanałach: usługi logowania, parametry wyszukiwania, narzędzia uwierzytelniania i podobne to dobre przykłady.
• Jeśli budujesz elastyczną aplikację (produkt lub usługę) wymagającą szybkiego dostarczania, innowacji i nie tylko.

Nie używaj mikroserwisów, gdy...

Współzałożyciel i CTO Contino, Benjamin Wootton, mówi, że mikroserwisy to nie darmowy lunch. Oznacza to, że nie są dla każdego. Od ich powstania - i odkąd Netflix nieco je zromantyzował, twierdząc, że na platformie działa ponad 700 mikroserwisów - firmy chętnie wprowadzają je do swoich biznesów.

Najczęściej przeoczano jednak to, że historie sukcesu pochodziły głównie od firm produktowych, które przeszły wiele iteracji i modeli, zanim miały produkt gotowy na rynek. Ta architektura stała się dla nich odpowiednia dopiero wtedy, gdy zrozumiały problem, który próbowały rozwiązać, i odniosły w tym sukces. Dlatego tak ważne jest, by wiedzieć, czy Twój biznes potrzebuje mikroserwisów.

Oto kilka czynników na początek:

• Mikroserwisy służą rozwiązywaniu złożonych problemów, a jeśli Twój biznes ich nie ma, to znaczy, że nie masz systemu, który udźwignie złożoność mikroserwisów.
• Sięgnięcie po mikroserwisy może się zemścić, jeśli nie masz zespołu, który poradzi sobie z zadaniami. Skończy się to tylko opóźnieniem dostawy.
• Wdrażanie mikroserwisów może też przeszkadzać. Jeśli Twoja aplikacja nie wymaga podziału na mikroserwisy, nie rób tego. Nie ma bezwzględnej potrzeby dzielenia każdej aplikacji na mikroserwisy. Są też takie proste z natury i funkcjonalności.

Miej pełne zrozumienie problemów, a nie tylko korzyści, bo to one mówią więcej o tym, czy warto zaczynać wdrażanie tej architektury. Jeśli potrafisz dostrzec dla swojego produktu prawdziwą wartość w mikroserwisach, śmiało.

Zalety i wady budowania mikroserwisów w .NET

Każdy styl architektoniczny ma swoje kompromisy: mocne i słabe strony, które trzeba oceniać w kontekście zastosowania. Dotyczy to również mikroserwisów. Choć w wielu przypadkach to przydatna architektura, w większości sytuacji lepiej sprawdzi się monolit.

Przejrzyj kolejny rozdział, by poznać wyzwania, które mogłeś wcześniej przeoczyć.

Zalety mikroserwisów w .NET

• Usługi można pisać w różnych językach programowania ​​i korzystać z nich w dowolnym frameworku.
• Niezależne tworzenie, wdrażanie, ponowne wdrażanie, wersjonowanie i skalowanie usług składowych w kilka sekund, bez naruszania spójności aplikacji.
• Lepsza izolacja awarii pozwala pozostałym usługom działać nawet wtedy, gdy jedna z nich padnie.
• Aktualizacje bez przestojów.
• Usługi mogą pochodzić z różnych serwerów, a nawet z różnych centrów danych.
• Komunikacja z innymi usługami przy użyciu dobrze zdefiniowanego protokołu.
• Monitorowanie, zbieranie i raportowanie diagnostyki kondycji.
• Niezawodność i samonaprawialność.
• Wsparcie ciągłej integracji i dostarczania.
• Łatwe przekazanie wiedzy nowej osobie w zespole.
• Łatwa integracja z podmiotami zewnętrznymi.

Wyzwania mikroserwisów w .NET

• Dodatkowa złożoność przy wdrażaniu mechanizmu komunikacji międzyprocesowej między usługami.
• Pisanie testów automatycznych obejmujących wiele usług jest trudne, a przygotowanie spójnego środowiska testowego bywa kłopotliwe.
• Zarządzanie wieloma instancjami różnych typów usług w środowisku produkcyjnym wymaga wysokiego poziomu automatyzacji.
• Każdy musi radzić sobie ze spójnością ostateczną, bo utrzymanie spójności silnej staje się skrajnie trudne.
• Zarządzanie wieloma bazami danych i ich transakcjami jest trudne.
• Wywołania międzyprocesowe są wolne.
• Debugowanie się komplikuje.
• Złożoność w DevOps.
• Koszty monitorowania produkcji są wyższe.
• Narzut oficjalnej dokumentacji.
• Brak kontroli.

Ogólnie rzecz biorąc, porównujemy tu zalety mikroserwisów .NET z zaletami monolitu. Czemu więc nie zestawić ich wprost?

Rodzaje mikroserwisów w .NET

Ogólnie mówiąc, w .NET są dwa rodzaje mikroserwisów:

1. mikroserwisy bezstanowe;
2. mikroserwisy stanowe.

Mikroserwisy bezstanowe

Mikroserwisy bezstanowe to dobrzy kandydaci na klocki systemu rozproszonego. Jak sama nazwa wskazuje, nie utrzymują stanu sesji między żądaniami - jeśli na przykład usuniemy dowolną instancję usługi, nie wpłynie to na ogólną logikę jej działania. Systemy rozproszone preferują mikroserwisy bezstanowe.

Patrząc na diagram: klient składa zapytanie o produkt przez usługę ORDER, a wewnętrzna usługa ORDER sprawdza stan produktu przez usługę INVENTORY. 

Bezstanowość oznacza, że każde żądanie wykonuje się niezależnie od poprzednich i przyszłych. Jedno wywołanie po szczegóły produktu zwróci ten sam wynik niezależnie od wcześniejszego kontekstu czy zapytań. Jeśli jedno wywołanie usługi ORDER się nie powiedzie, nie powinno zatrzymać całego procesu biznesowego. Inne instancje mikroserwisów muszą działać, by dokończyć zadanie.

Mikroserwisy stanowe

Mikroserwisy stanowe przechowują informacje o sesji w kodzie. Gdy dwa lub więcej mikroserwisów się komunikuje, utrzymują stan żądania usługi.

W realnym świecie usługi bezstanowe są dobrym wyborem, ale jest kilka przypadków, w których trzeba przechowywać informacje o stanie. Prosty przykład: transakcje wymagające wielu rund dostępu do bazy danych wymagają stanowości.

Aby dowiedzieć się więcej o mikroserwisach stanowych, przejdź do Overview of Azure Service Fabric - Azure Service Fabric 

Typowe różnice w przetwarzaniu aplikacji stanowych i bezstanowych

• Aplikacje bezstanowe mają tylko jedną funkcję lub usługę, a aplikacje stanowe przechowują bazy danych.
• Do aplikacji bezstanowych należą serwery WWW, serwery druku czy CDN-y, a do stanowych transakcje takie jak bankowość domowa.
• Serwer w usłudze bezstanowej obsługuje żądania na podstawie informacji przekazanych w danym momencie, a serwer w aplikacji stanowej na podstawie informacji zarówno wcześniejszych, jak i bieżących.
• W aplikacji bezstanowej różne serwery mogą przetwarzać różne informacje, podczas gdy w aplikacji stanowej wszystkie żądania dotyczące tej samej informacji o stanie obsługuje tylko jeden serwer.
• Aplikacje bezstanowe używają skonteneryzowanych aplikacji mikroserwisowych do generowania wyników. Aplikacje stanowe korzystają natomiast z przenoszenia kontenerów i ponownego montowania wolumenów bez zmian w aplikacji czy kodzie.

Mikroserwisy .NET - wpływ na produkt

Umiejętność dostosowania się do stale zmieniających się rynków to dziś jedyny sposób, by firma utrzymała się na powierzchni i rozwijała - dlatego skalowalność jest tak ważna.

Idea ​​skalowalności jest prosta: im więcej zasobów, tym lepsza wydajność Twojego przedsiębiorstwa. Możesz odnieść ją do firmy, gdzie więcej zasobów oznacza odpowiedni wzrost sprzedaży, albo do architektury oprogramowania, gdzie oznacza zdolność do rozwoju wraz z rosnącym popytem.

Architektura mikroserwisowa to planowanie z wyprzedzeniem i upewnianie się, że jesteś gotów na przyszłość. Jakie dokładnie są potencjalne korzyści z mikroserwisów i jak realizują skalowalność? Zaraz odpowiemy!

Korzyści biznesowe mikroserwisu tożsamości w ASP.NET Core

Głównym powodem budowania architektury mikroserwisowej jest chęć rozwijania określonej linii biznesowej w oderwaniu od reszty. Takie podejście pozwala dodawać do danego modułu nowe funkcje przy minimalnym wpływie na resztę systemu. Chodzi o niezależność w tworzeniu i wdrażaniu. Ponieważ mikroserwisy organizuje się według wymagań biznesowych, zespół deweloperski lepiej zna oczekiwania użytkowników i rozumie perspektywę biznesową. Im lepsze zrozumienie, tym lepsze dopasowanie do biznesu.

Pomyśl o architekturze mikroserwisowej jako o filozofii samodzielności, w przeciwieństwie do podejścia monolitycznego. W architekturze monolitycznej aplikację traktuje się jako jedną całość złożoną z wielu elementów służących jednemu celowi. Architektura mikroserwisowa zrywa powiązania między tymi elementami, czyniąc z każdego niezależną jednostkę.

Architektura mikroserwisowa jest z definicji lekka. Dzieląc każdy komponent aplikacji na osobny mikroserwis, możemy skupić się na konkretnych potrzebach biznesowych, za które odpowiada dany moduł. Te niezależne moduły współpracują ze sobą, działając jako zbiór jednostek, a nie jeden monolit. Ponieważ procesy biznesowe są rozdzielone, łatwiej skalować w danym momencie te najbardziej krytyczne niż całą aplikację.

Osiąganie skalowalności dla Twojego biznesu

W ekosystemach mikroserwisowych najważniejsza jest efektywność. Osiągnięcie efektywności i skalowalności architektury, w której zadania rozłożone są czasem na dziesiątki (jeśli nie setki) małych usług, bywa bardzo trudne.

Skupiając się na zaletach tego podejścia, nie można zapominać o problemach wynikających ze wzrostu złożoności. Aby osiągnąć pożądany poziom skalowalności architektury przy zachowaniu szybkiego i udanego wdrożenia, trzeba właściwie zorganizować przepływ pracy i proces wytwórczy. Sukces nie jest możliwy bez odpowiedniego planowania i organizacji. Możesz mieć najlepszych programistów, ale jeśli nie zarządzasz tym dobrze, projekt się nie uda.

Przyjrzyjmy się więc najpierw dokładniej procesowi wytwórczemu.

Jak powstaje produkt

Musisz wiedzieć, że przejście z monolitu do ekosystemu mikroserwisów bywa epicką podróżą. Jest kilka rzeczy, które trzeba zrobić, by wszystko poszło dobrze.

Przede wszystkim zidentyfikuj możliwości biznesowe, które chcesz zamienić w mikroserwisy. Zadbaj, by każdy mikroserwis zamykał w sobie konkretną zdolność biznesową. Możliwości biznesowe to to, co firma robi w danym obszarze, by realizować swoje cele i obowiązki.

Rozbijmy to teraz na bardziej szczegółowe kroki.

Krok 1. Zacznij od prostych zdolności

Zacznij od zdolności biznesowych, które łatwo odłączyć od aplikacji monolitycznej. Pozwoli to też Twojemu zespołowi DevOps przygotować potrzebne środowisko wdrożeniowe i potoki ciągłego dostarczania.

Oto kilka pierwszych przykładów: wydzielenie usługi uwierzytelniania użytkownika albo „profilu klienta”. To usługi brzegowe, które łatwo odłączyć.

Krok 2. Zbuduj system zarządzania API

Ponieważ będziesz mieć do czynienia z wieloma API, zabierz się za system zarządzania API. Często wiąże się to z postawieniem service mesh, który działa jako dedykowana warstwa infrastruktury do uruchamiania szybkiej, niezawodnej i bezpiecznej sieci mikroserwisów.

Meshing zwykle zaczyna się od systemów orkiestracji kontenerów, takich jak Kubernetes, by dać wyższy poziom abstrakcji nad infrastrukturą wdrożeniową.

Krok 3. Zminimalizuj zależności od monolitu

Ogranicz też zależności nowo tworzonych mikroserwisów od monolitu. Mikroserwis musi być niezależny i przyjmować żądania wyłącznie przez otwarte endpointy API. Jeśli będziesz ściśle przestrzegać tej zasady, skończysz z monolitem zależnym od zdolności tworzonych mikroserwisów, a nie odwrotnie.

Wskazówka: wcześnie wydzielaj głęboko zintegrowane zdolności

Aby przyspieszyć przejście na mikroserwisy, najlepiej odłączyć od monolitu głęboko zintegrowane zdolności. Gdy takie zdolności pozostają w monolicie, ograniczają dalszą migrację. Zawsze będzie bowiem istnieć ta zależność od monolitu w danym obszarze.

Aby móc się rozwijać, zespół musi wskazać taką lepką zdolność, rozbić ją na dobrze zdefiniowane pojęcia domenowe, a potem rozbić te pojęcia na osobne mikroserwisy.

Jak mikroserwisy mogą wpłynąć na wzrost biznesu?

Idea architektury mikroserwisowej to efekt lat ewolucji najlepszych praktyk w branży IT. Gdy firmy dążą do poprawy doświadczenia klienta, naturalna wydaje się decyzja o wydzieleniu każdego procesu w osobną jednostkę - dzięki temu masz pewność, że każdy komponent aplikacji działa najlepiej, jak potrafi.

Ponieważ funkcje biznesowe są podzielone na osobne byty, każdy z nich można tworzyć, testować i uruchamiać niezależnie. Oznacza to też, że można je zmieniać w izolacji, nie zakłócając działania biznesu. Stała, a nawet rosnąca szybkość dostarczania przy zachowaniu elastyczności we wprowadzaniu zmian to coś, czego szuka każdy CEO - a architektura mikroserwisowa to gwarantuje. 

Sprawdź więcej badań na ten temat!

Optymalizacja kosztów dzięki mikroserwisom i usługom chmurowym

Wdrażając aplikację mikroserwisową, firma buduje skalowalną infrastrukturę. Dodanie do tego rozliczeń na żądanie i za faktyczne użycie zwiększa efektywność operacyjną i optymalizuje koszty. Mikroserwisy w chmurze upraszczają dostarczanie aplikacji i pomagają produktom szybciej trafić na rynek.

Zwiększ skalowalność dzięki architekturze mikroserwisowej

Teraz, gdy wiesz, jak skuteczne są mikroserwisy .NET dla rozwoju firmy, podsumujmy ich bezpośrednie korzyści:

• Poprawiają skalowalność, pozwalając każdemu komponentowi skalować się niezależnie.
• Znacznie ułatwiają zrozumienie aplikacji, rozbijając je na małe części.
• Dostosowują się do nowych technologii

Pamiętaj: prostszych systemów często nie trzeba rozbijać na mikroserwisy, bo doprowadzi to tylko do zamieszania. Przy bardziej złożonych systemach architektura mikroserwisowa może być jednak dobrym wyborem.

Rynek specjalistów i popularność języka

Chęć Microsoftu, by dać programistom jedną platformę do rozwiązywania dowolnych problemów, zrealizowała się dzięki .NET. Platforma .NET od kilkudziesięciu lat wspiera aplikacje webowe, desktopowe i mobilne, zarówno w startupach, jak i w korporacjach.

Nie ma wątpliwości, że .NET odgrywa centralną rolę w branży wytwarzania oprogramowania. Popularność .NET w społeczności programistów jest faktem. Możesz ją zmierzyć liczbą projektów open source na świecie i obecnością C# w pierwszej piątce najpopularniejszych języków programowania. Ta popularność ma jeszcze rosnąć, zwłaszcza po ostatnim wydaniu (.NET 6), które zrewolucjonizowało branżę, tworząc koncepcję uniwersalnego wytwarzania oprogramowania.

Dziś, według wielu szacunków, programistów ASP.NET jest na świecie około 7-8 milionów. Większość z nich to programiści C#.

Skoro mowa o C Sharpie, może warto zajrzeć w porównanie .NET i C#?

Choć C# uchodzi za główny język .NET, możesz używać wielu innych języków do wyboru. Nie wszystkie jednak są dobrze przystosowane do budowy architektury mikroserwisowej.

Dlatego polecamy skorzystać ze zweryfikowanego marketplace'u specjalistów IT. Dzięki temu masz pewność, że zatrudniasz wyłącznie doświadczonych programistów webowych.

Czy .NET nadaje się do mikroserwisów?

Pojawienie się ASP.NET Core pomogło programistom budować wieloplatformowe mikroserwisy w .NET na wielu systemach operacyjnych, z łatwym wdrożeniem w chmurze.

Jest wiele powodów, dla których ASP.NET Core jest tak lubiany:

• otwartoźródłowość, 
• dobry do wdrażania wysokowydajnych rozwiązań, 
• wieloplatformowe środowisko uruchomieniowe, 
• szybsze wytwarzanie, 
• konfiguracja chmurowa, 
• i wiele więcej.

ASP.NET, platforma .NET do tworzenia aplikacji webowych, ułatwia budowanie API, które stają się mikroserwisami. Ma wbudowane wsparcie dla tworzenia i wdrażania mikroserwisów w kontenerach Docker. 

.NET zawiera API, które po prostu korzystają z mikroserwisów w dowolnej zbudowanej przez Ciebie aplikacji - desktopowej, mobilnej, internetowej, w grach itd. 

Jeśli masz aplikację, możesz zacząć wdrażać mikroserwisy .NET bez jej całkowitej przebudowy. Wstępna konfiguracja obrazów Dockera dla .NET jest już gotowa i dostępna na Docker Hubie, dzięki czemu skupisz się wyłącznie na budowie mikroserwisów.

Architektura mikroserwisów .NET pozwala kompilować technologię pomiędzy poszczególnymi usługami. Dzięki temu możesz użyć .NET w konkretnej części aplikacji, bez wciskania go wszędzie. 

Mikroserwisy .NET możesz mieszać z aplikacjami napisanymi w Javie, Node JS czy dowolnym innym języku (sprawdź, co jest lepsze: .NET czy Java).

Pozwala to stopniowo przechodzić na technologię .NET dla nowych mikroserwisów działających razem z innymi mikroserwisami i usługami zbudowanymi w innych technologiach. Podobnie mikroserwisy .NET mogą działać na wszystkich wiodących platformach chmurowych.

Podstawowe założenia, na których opierają się mikroserwisy i ASP.NET Core, są całkiem do siebie zbliżone. Ponieważ .NET jako jeden z pierwszych tworzył aplikacje oparte na Simple Object Access Protocol, jego metodykę uznaje się za nowoczesną architekturę mikroserwisową.

Przyjrzyjmy się teraz bliżej kluczowym cechom ASP.NET Core i jego atutom przy budowie mikroserwisów.

Kluczowe cechy ASP.NET Core przy budowie mikroserwisów

Lepsza i szybsza konteneryzacja

Każdą aplikację ASP.NET Core można umieścić w kontenerze Docker. Nawet tradycyjne oprogramowanie wspiera technologię kontenerów. Najnowsza wersja pozwala jednak uzyskiwać obrazy lepszej jakości i szybciej.

Zgodność z Kubernetesem i Dockerem

Zgodność z Kubernetesem jest opcjonalną funkcją w nagłówku ASP.NET Core, dzięki czemu można wykorzystać wszystkie możliwości Kubernetesa i skutecznie budować mikroserwisy. Nawet budowanie mikroserwisów w Dockerze jest efektywne dzięki całej dostępnej, szczegółowej dokumentacji.

Zgodność wieloplatformowa aplikacji

ASP.NET Core wspiera wiele systemów operacyjnych i jest zgodny z technologiami wieloplatformowymi. Wcześniejsza wersja była ograniczona, ale ta jest już wieloplatformowa. Dla mikroserwisów ważne jest, by nie były zależne od platformy ani architektury.

Większa szybkość i spójność

Z czasem i wraz z kolejnymi wersjami najnowsze wydania ASP.NET Core stają się szybsze, lepsze i bezpieczniejsze. Ostatnie badania pokazują, że efekty tej pracy są coraz lepsze. Liczba wydań wzrosła w ostatnich latach.

Rzut oka na najnowsze benchmarki ASP.NET Core pokazuje, że jego wydajność od premiery tylko rosła.

Swoboda w wyborze IDE

Budując aplikację w środowisku mikroserwisowym przy użyciu ASP.NET Core, programiści mogą wybrać IDE, które najbardziej im odpowiada. Nie trzeba wybierać Microsoft Visual Studio. Programiści mogą sięgnąć po darmowe oprogramowanie do budowy aplikacji opartych na mikroserwisach.

Zgodny z chmurą

Podstawowa natura ASP.NET Core wspiera skalowalność chmurową. Każdy rodzaj mikroserwisów zbudowanych w tej technologii z pewnością będzie działał płynnie na wszystkich ważnych usługach chmurowych. Przykładowo Azure to jedna z technologii chmurowych, które polecamy, bo powstała specjalnie dla społeczności .NET.

Modułowy i lekki

Dwie główne cechy ASP.NET Core - modułowość i lekkość - są kluczowe przy wyborze go do budowy aplikacji mikroserwisowej opartej na kontenerach.

Stabilność

Na początku 2017 roku, gdy ukazała się wersja 1.0, wielu funkcji jeszcze brakowało, wsparcie dla połączeń z bazami danych było słabe, a .NET Core wyglądał jak produkt w wersji beta z dużym potencjałem. 

Od tego czasu framework znacznie się poprawił: 

• biblioteki takie jak NHibernate wspierają dziś ASP.NET Core, 
• wydajność jego modułów znacznie wzrosła, 
• cała platforma jest o wiele lepsza i stabilniejsza. 

Wszystkie informacje o wydaniach poszczególnych wersji znajdziesz tutaj.

Zorientowany na wiersz poleceń

ASP.NET Core pozwala budować, kompilować, uruchamiać i wdrażać z poziomu wiersza poleceń.

Łatwy start

Za pomocą prostego polecenia w rodzaju „dotnet new webapi” otrzymujesz fundament swojego mikroserwisu.

Wytwarzanie w ASP.NET Core ugruntowało swoją pozycję na rynku IT i jest z powodzeniem uznawane za odpowiednie do budowy mikroserwisów. Do wyboru jest wiele języków programowania ​​przy tworzeniu idealnej architektury mikroserwisowej, ale ASP.NET Core okazał się wyborem doskonałym. Wykazanie wartości ASP.NET Core nie jest trudne. To udowodniony fakt!

Przykłady z życia

Globalne firmy, takie jak Amazon, Coca Cola czy Zalando, przekształcają swoje infrastruktury IT w architekturę mikroserwisową. Przy okazji przebudowują też wewnętrzne struktury organizacyjne i wyprzedzają konkurencję.

Większość dużych firm, a także startupów, buduje swoje systemy w architekturze monolitycznej. Zaczynają tak, bo na początkowym etapie projektu dużo szybciej jest stworzyć monolit i ruszyć z biznesem. Po jakimś czasie pojawiają się problemy wynikające z dojrzewania projektów lub przyrostu „tłuszczu”. Wraz ze wzrostem systemu kod staje się bardziej skomplikowany, architektura bardziej złożona, a do utrzymania potrzeba więcej programistów. 

Jednocześnie tracimy szybkość, elastyczność i zwinność, przez co trudniej odpowiadać na potrzeby rynku.

Zobaczmy, jakie firmy rozwiązały swoje problemy, sięgając po mikroserwisy w .NET!

Gdy BestBuy.com zajmował 10. miejsce wśród 500 największych sklepów internetowych, firma doszła do punktu, w którym nawet proste zmiany i aktualizacje systemu IT były skrajnie trudne, a nawet niebezpieczne, bo nie dało się skutecznie przygotować na szczyt ruchu w okresie świątecznym. Ekosystem aplikacji stał się zbyt złożony i po prostu utknął w miejscu.

Po tym momencie zaczęła się transformacja, będąca chyba najlepszym przykładem mikroserwisów w .NET Core. Proces ruszył w 2010 roku od budowy grafów zależności między połączonymi modułami monolitycznej platformy, a potem programiści zaczęli wdrażać mikroserwisy. Best Buy użył wzorca Strangler, by krok po kroku zastąpić stary system mikroserwisami.

Ciężka praca nad kulturą pozwoliła wielu zespołom przyspieszyć rozwój i zyskać swobodę. Zawsze skupialiśmy się na uczeniu się, by być lepszym

powiedziała programistka Kristen Womack.

Choć przejście na mikroserwisy było trudne, Best Buy wykorzystał je, by przebudować organizację i system tak, by do siebie pasowały i wspierały przyszłe procesy firmy.

Dowiedz się więcej o mikroserwisach w BestBuy.com tutaj.

The Coca-Cola Company - 3800 produktów na świecie i spółki zależne na całym globie - to kolejny świetny przykład architektury mikroserwisowej w .NET. Firma stanęła przed wyzwaniem połączenia biznesów na różnych kontynentach i wsparcia ich wzrostu. 

Globalny dział IT Coca-Coli postanowił użyć do tego mikroserwisów i API oraz stopniowo zastępować stare oprogramowanie. Szybka zmiana nie była tu możliwa ze względu na wiele rozwiązań wdrożonych globalnie (ERP, transformacje, repozytoria).

Firma wiedziała, że mikroserwisy można wdrożyć na wiele sposobów, i ostatecznie zdecydowała się przejść na nową architekturę w modelu DevOps. Wprowadziła w nim strukturę podzieloną na jedną aplikację, dzięki której może rozwiązywać wszelkie problemy z szybkością i zwrotnością. 

Z drugiej strony GIT stworzył bibliotekę modułów wielokrotnego użytku (nazwaną Anypoint Platform), pogrupowanych w domeny dostępne dla wszystkich podmiotów w grupie. Dzięki bazie gotowych do użycia usług projekty w całej organizacji i u partnerów zewnętrznych mogą powstawać szybciej i taniej.

W porównaniu z naszym starym rozwiązaniem integracyjnym Anypoint Platform pozwoliła nam zmniejszyć przepływ danych do sieci Coca Coli o 50%, a czas potrzebny na skalowanie pod kolejne maszyny freestyle skrócić z tygodni do minut.

- Dani Ang, Corporate Integration Architect w The Coca Cola Company.

Wraz ze zmianami w technologii i architekturze Coca-Cola skupiła się na procesach i ludziach. Firma przeszła z modelu COE na model C4E (Center 4 Excellence) i zyskała synergię dzięki współpracy i dzieleniu się w ramach systemu.

Dowiedz się więcej o mikroserwisach w Coca-Coli tutaj.

Podsumowanie

Przejście na architekturę mikroserwisową to innowacyjny sposób na szybkie dostarczanie oprogramowania przy jednoczesnym ograniczeniu ryzyka. To priorytet wielu firm patrzących w przyszłość. Gdy Twój biznes jest gotów na taką zmianę, warto dokładnie wiedzieć, czego potrzebuje Twoja aplikacja, by ostatecznie zapewnić oczekiwaną jakość usług, skalowalność, elastyczność i sukces biznesowy.

Analiza korzyści biznesowych z mikroserwisów może pomóc Twojemu przedsiębiorstwu, startupowi czy scaleupowi określić własne cele migracji i upewnić się, że masz wsparcie potrzebne do opanowania dodatkowej złożoności przejścia na architekturę kontenerową.

Pracując z firmami nad ich mapami drogowymi i celami przejścia na architekturę kontenerową, widzieliśmy niesamowity wzrost i sukcesy wynikające z nowoczesnego podejścia do tej zmiany. Do najczęstszych korzyści biznesowych należą:

Drzwi do elastyczności biznesu

Wprowadzanie zmian w aplikacjach legacy jest bardzo ryzykowne, bo zmiana jednego procesu może negatywnie wpłynąć na inny. Przy luźno powiązanych mikroserwisach aktualizacje można natomiast wykonywać niezależnie od reszty aplikacji. Przekłada się to na szybsze tworzenie i wersjonowanie aplikacji, dzięki czemu firmy mogą „szybko upadać” i trzymać się elastycznych harmonogramów rozwoju produktu.

Możliwość stosowania zaawansowanych praktyk bezpieczeństwa

W mikroserwisach ważne jest pełne zrozumienie i widoczność zależności sieciowych, a także spójny dostęp i bezpieczeństwo każdego mikroserwisu. Wykorzystaj dogłębną wiedzę o skanowaniu kontenerów i sieciach klastrów oraz zastosuj service mesh, by mieć pewność, że Twoje środowisko używa każdego możliwego narzędzia dla maksymalnego bezpieczeństwa.

Skalowalność

Mikroserwisy można skalować poziomo, uruchamiając dwie maszyny obok siebie, zamiast rozbudowywać istniejącą. Oznacza to, że możesz skalować w górę i w dół wtedy, gdy trzeba, oszczędzając pieniądze i poprawiając doświadczenie użytkownika.

Lepsza wydajność aplikacji

Gdy pojawiają się problemy, dotyczą jednej małej części aplikacji, a nie całości. Daje to użytkownikom końcowym najlepszą wydajność i eliminuje przestoje, podczas gdy IT usuwa usterkę i przywraca normalne działanie usługi.

Prostota i spójność

Wiele firm przechodzi na infrastrukturę kontenerową z potrzeby skalowania. Gdy mikroserwisy są zautomatyzowane i oparte na szablonach, łatwo nimi zarządzać oraz je powielać lub usuwać. Oznacza to spójne podejście do skalowania, orkiestracji i zarządzania aplikacją.

Specjaliści Ideamotive do Twojej dyspozycji

Mikroserwisy dają wyraźne korzyści: oszczędność kosztów i szybsze wejście na rynek. Zmniejszają liczbę awarii i zapewniają wyższą dostępność. Nadgorliwość albo błędne pokierowanie architekturą mikroserwisów potrafi jednak nadmiernie wszystko skomplikować. A wtedy stracisz wszystkie te korzyści.

Przechodząc na mikroserwisy, trzeba dobrze przemyśleć sprawę. Może zajść potrzeba zatrudnienia dodatkowych osób o nowych kompetencjach. Nie zapomnij też ocenić swojego obecnego zespołu DevOps.

Czujesz, że dodatkowa pomoc byłaby w tym procesie na wagę złota? Zwróć się do Ideamotive po najlepszych programistów C/C++! Potrzebujesz całego zespołu dedykowanych osób? Jesteśmy tu, by pomóc w każdej sprawie!