Kilkukrotnie już znalazłem się w położeniu, lub zaobserwowałem je u innych zespołów, w którym architektura rozwiązania zaproponowana przez konsultantów reprezentujących dostawcę chmury wyglądała jakby komuś bardzo zależało na tym, by zastosować każdą dostępną "zabawkę", ze znacznym lub nawet dominującym udziałem rozwiązań typu PaaS. Mogłoby to wyglądać np. tak (źródło: https://docs.aws.amazon.com/wellarchitected/latest/financial-services-industry-lens/artificial-intelligence-and-machine-learning.html):

Co w tym złego? Przede wszystkim:

Uzależnienie od dostawcy (z ang. vendor lock-in) - sytuacja taka ma miejsce, gdy rozwiązanie jest zaprojektowane i wykonane w sposób, który utrudnia lub wręcz uniemożliwia zmianę dostawcy rozwiązania. Projektując system z myślą o konkretnym dostawcy i konkretnych jego rozwiązaniach (bazach danych, systemach kolejkowych itp.) siłą rzeczy uzależniamy się od niego. W przypadku zmiany warunków rynkowych niezmiernie trudno będzie przenieść taki system do innego dostawcy. Bardzo dobrym przykładem takiej sytuacji jest rok 2017, w którym Oracle (nieco spóźnione w chmurowym wyścigu) diametralnie zmieniło model cenowy swojego kluczowego produktu - relacyjnej bazy danych - powodując podwojenie kosztów jego utrzymania w infrastrukturach innych dostawców chmury (https://www.infoworld.com/article/3164517/oracle-is-pricing-itself-out-of-amazons-cloud.html).

Nieprzewidywalne koszty - bardzo często powtarzanym hasłem mającym zachęcić nas do migracji do chmury jest "płacisz tylko za to co używasz" i tak często jest w istocie, problem pojawia się jednak wtedy, gdy nie wiemy czego tak naprawdę i w jakim zakresie będziemy używać. Widać to bardzo dobrze w przypadku rozwiązań PaaS gdzie płacimy np. za każdy 1 tys. przetworzonych komunikatów lub zapisanych obiektów, w warstwie IaaS możemy być już naliczani np. za każdy przetransmitowany 1 GB danych lub po prostu za każdą godzinę pracy jakiejś usługi. Próby określenia tych miar to często wróżenie z fusów a niedokładność takich wycen jest niesłychanie wysoka - słyszałem o nawet dwu- lub trzykrotnym niedoszacowaniu finalnych kosztów!

Jak się przed tym bronić? Ciężko... trzeba uważać. Ja chciałbym zaproponować kilka wskazówek:

Unikać przedwczesnych decyzji - branża IT zdominowana jest przez mężczyzn, a u nas przoduje mentalność zadaniowa. Co z głowy, to z serca - działając w myśl tej zasady czujemy potrzebę jak najszybszego "zamknięcia" kluczowych kwestii. Podjęcie na bardzo wczesnym etapie decyzji typu systemem kolejkowym zastosowanym do integracji komponentów A i B ma być SuperQueue(zmyślone) jest bardzo kuszące bo możemy odhaczyć kolejny "ptaszek" na naszej liście (bez wyrzutów sumienia, przecież dostawca oprogramowania przekonuje nas o zaletach swojego rozwiązania!) i przejść do kolejnych zadań. Z tą pokusą trzeba zdecydowanie walczyć i jak najdłużej posługiwać się swego rodzaju Jokerem, w którego miejsce będziemy mogli osadzić konkretne rozwiązanie dopiero kiedy przyjdzie na to czas. Starajmy się generalizować. Najdłużej jak się da. Zamiast o SuperQueue myślmy po prostu o systemie kolejkowym. Spróbujmy zbadać badać zagadnienie bo może się okazać, że są standardy komunikacji z takim rozwiązaniem i nasz system może nie być nawet świadomy z jakim rozwiązaniem się komunikuje (np. protokół Stomp).

Skłaniać się w stronę IaaS - zachęcałbym do trzymania się tej podstawowej "warstwy" chmury gdzie tylko się da. Dzięki temu możemy w bardziej precyzyjny sposób określić koszt rozwiązania (np. serwer z usługą systemu kolejkowego będzie działał 24/7 a płacimy za każdą godzinę jego pracy). Oferta rozwiązań open-source jest naprawdę bogata i bardzo często jesteśmy w stanie znaleźć na prawdę porządne rozwiązania, które nie wprowadzają kosztu licencji i można je swobodnie instalować na wirtualnych serwerach dostarczanych w modelu IaaS. Bardzo częstym kontrargumentem dla takiego podejścia, podnoszonym przez dostawców chmury, jest utrudnione skalowanie w porównaniu do rozwiązań PaaS, które rzekomo mogą skalować się w nieskończoność. Być może, jednak należy zadać sobie pytanie czy rzeczywiście na takim skalowaniu nam zależy. Czy nasza usługa może stać się nowym hitem i z dnia na dzień dziesięciokrotnie zwiększyć obsługiwany ruch. W polskich i europejskich realiach raczej nikłe są na to szanse.

Opracować plan wyjścia - proponuję zawsze z "tyłu głowy" mieć plan wyjścia z infrastruktury danego dostawcy i na każdą architektoniczną decyzję patrzeć z tej perspektywy; zadać sobie pytanie - jak będziemy mogli przenieść to rozwiązanie do innego dostawcy, być może małego, lokalnego lub nawet do własnej, firmowej serwerowni, gdyby koszty utrzymania rozwiązania jednak nas przerosły. Bo pamiętajmy, że owszem - w chmurze płacimy tylko za to, czego używamy - co jednak nie stanowi gwarancji tego, że takie rozwiązanie będzie tańsze. To bardzo często popełniany błąd logiczny.

Jeśli czujesz na swojej szyi (lub portfelu) pętlę zaciskaną przez swojego dostawcę chmury, zapraszam do kontaktu. Porozmawiajmy o możliwych wyjściach z tej sytuacji.