Cześć,
Przy okazji kolejnego hobbistycznego projektu planuję zaprzyjaźnić się z Azure, z którym dotychczas nie miałem przyjemności pracować. Sam projekt idealnie wpisuje się w ideę architektury opartej o mikroserwisy i taką planuje właśnie wykorzystać. Same mikroserwisy nie są mi obce, ponieważ mój poprzedni projekt również je wykorzystuje. Nie oznacza to, że moja wiedza na ich temat jest duża. Niestety, zatrzymałem się już na samym początku poprzez mnogość rozwiązań na Azure, które nadają się do obsługi takiej architektury. Niestety przez brak expa z Azure/Dockerem/K8S wszystko, co znalazłem, nie jest dla mnie do końca zrozumiałe i potrzebowałbym pomocy w wyborze odpowiednich modułów Azure, wskazania drogi, jaką podążać i w jakiej się doszkolić.
Pozwolę sobie zacząć od tego w jaki sposób dotychczas implementowałem architekturę mikroserwisów. Może w tym procesie/rozumieniu też będzie trzeba coś zmienić. Na VM1 miałem wystawiony frontend w React, który komunikował się z ApiGateway opartym na .NET Core i Ocelocie. Na tym VM miałem również postawionego Consula, którego używałem do service discovery. W samym Consulu miałem 2 node, które były reprezentowane przez osobne VM. Na czwartej VM miałem zainstalowaną instancję MSSQL oraz RabbitMQ. Wszystkie mikroserwisy korzystały z jednej instancji SQL, a komunikacja między serwisami odbywała się poprzez message w RabbitMQ. Wiem, że wspólna baza dla wszystkich serwisów była błędem i burzyła całą "niezależność" mikroserwisów. Niestety zabrakło pomysłu i samozaparcia, by się dowiedzieć jak to rozwiązać. Teraz już wiem również to, że gdybym chciał to wystawić na świat, to koszt 4VM z licencjami Windowsa zabiłby ten projekt w przedbiegach.
Z początku sprawa wyglądała w miarę jasno. Front oraz poszczególne API miałem wystawić poprzez App Service, komunikacja między frontem i backendem miała odbywać się za pomocą Application Gateway. Każdy serwis miał mieć osobną bazę, a sama komunikacja między serwisami miała się odbywać za pomocą Azure Service Bus Messaging. Zaczęły mi się nasuwać pytania.
- Czy jak wystawię dwa razy API na osobnych App Service to, czy Application Gateway zadziała jak loadbalancer?
- W jaki sposób usunąć wąskie gardło w postaci baz danych, jak wystawiać ich 2 instancje i zachować spójność danych dla nich? Jednocześnie jak nie zbankrutować przy tym
Zacząłem szukać jakichś poradników/kursów/przykładów implementacji mikroserwisów z użyciem Azure. I tu zderzyłem się z rzeczywistością. Okazuje się, że nie ma za dużo treści do takiego podejścia, jakie sobie wymyśliłem, że będzie dobre. Za to dużo jest o Azure Kubernetes Service oraz o Service Fabric, ale nie do końca potrafię to skleić w całość. Głównie zainteresowałem się tym drugim, lecz nie do końca rozumiem w czym jest to lepsze od mojego pomysłu. Oraz dlaczego jest to aż tak promowane. Nie do końca rozumiem jak w tym zaimplementować API Gateway czy komunikację między serwisami za pomocą kolejek wiadomości. Co więcej, we wszystkich przykładach wszystkie serwisy są w jednym pliku solucji wraz z projektem typu Service Fabric Application, a ja bym wolał to rozbić, tak by każde API miało swoje osobne repozytorium. Dodatkowo rozmawiałem ze znajomym, który zasiał mi w głowie kolejne wątpliwości, pytając po co mi więcej niż jedna instancja danego API, skoro Azure dla App Service zapewnia wysokie SLA i skalowalność w dowolnej chwili.
Czy ktoś by mógł mi pomóc z uporządkowaniem wiedzy i wyznaczeniem szlaku, tak by zrobić to dobrze?
C# 
Microsoft Azure 
