Hybrid Multicloud – czy o tym myślał Nicolas Carr?

Data: 2021-01-20
Autor: Sebastian Konkol
Hybrid Multicloud – czy o tym myślał Nicolas Carr?

Po wcześniejszych wpisach, szczególnie dotyczących bezpieczeństwa w chmurze, prowadziłem kilka interesujących dyskusji na temat docelowej (o ile coś takiego istnieje) wizji chmury. Choć znacząca część tej dyskusji toczyła się wokół tematów uzależnienia od dostawcy, podniesionej czujności w kontroli kosztów i bezpieczeństwa wartości firmy (danych), skupię się na innym, ciekawym aspekcie typowego środowiska działania informatyki firmy.

Choć na dziś przedsiębiorstwo „całe w chmurze”, jak na przykład Aion Bank, ciągle jest wydarzeniem, przyszłość jest raczej jasna – własne Data Centre jest już dziś kosztownym luksusem. O ile będzie potrzebne to częściej naprawdę będzie budowane w formie chmury prywatnej. Wykorzystanie różnych elementów chmur publicznych będzie tak „agnostyczne”, jak wykorzystanie języków programowania w dzisiejszych warunkach – czasami dlatego, że nie znam nic innego, czasami dlatego, że takie wyznaję, a czasami po dokonaniu świadomej decyzji. Osobiście preferuję to ostatnie, ale zdaję sobie sprawę z tego, jak marginalne jest to zachowanie. Co to oznacza? Znaczy to, że – w warunkach coraz słabszej pozycji Enterprise Architecture i przenoszenia „wiary w sukces” na DevOps, każda firma będzie działała w trybie multi-cloud, a te większe w (mam nadzieję) bardzo świadomie wybranym trybie hybrid multi-cloud. Do tego musimy się przyzwyczaić, choć niektórzy już rozpoczęli tę ścieżkę na poważnie.

Kontynuując analogię do języków programowania, na pewnym podstawowym poziomie wiemy, że mamy różne języki programowania. Jedne są lepsze w jednym, inne zaś w czymś innym (Java wybacza brak doświadczenia, Erlang bije na głowę wszystko inne w sferze współbieżności, C jest niedoścignionym wzorcem wydajności). Przechodzimy do chmury i cieszymy się, że mamy Infrastructure as Code (IaC), co „robienie informatyki korporacyjnej” uwalnia od jarzma blach, kabli, zasilnia i klimatyzacji oferując eleganckie i proste w obsłudze usługi. Oczywiście, inżynierska dusza przeżywa katusze, bo chmura upraszcza zagadnienia zawsze kosztem „wydajności z tranzystora” – bez wątpienia unifikacja w takiej skali nie pozwala na „dopieszczenie” konfiguracji i parametryzacji poszczególnych komponentów tak, jak w sytuacji posiadania pełnej kontroli nad sprzętem. Dokąd jednak o efekcie decydować będzie rachunek ekonomiczny, a nie inżynierska optymalizacja, nie ma co rejtanić. Poza tym, polegając nadal na analogii do języków programowania, mamy dokładnie tę samą sytuację już od dłuższego czasu – kiedyś kompletny kompilator Fortran z optymalizatorem mieścił się w 16 KB, a teraz „Hello World!” to megabajty. Chyba więc trzeba się pogodzić z marnowaniem zasobów dla prostot i łatwości użycia wybaczającej niewiedzę.

W typowym, docelowym środowisku działania systemów informatycznych firmy będzie więcej chmur, będziemy więc mieli po prostu kilka „języków” dla tworzenia chmury obliczeniowej (AWS, GCP, Azure, Salesforce, …). W sumie żadna nowość, bo dowolna aplikacja na dziś to jakaś baza danych (SQL), jakiś backend (Java, .NET) i jakiś frontend (HTML, jakiś framework JS). Całość warstwy chmurowej infrastruktury to będzie po prostu kolejny język lub zestaw języków do opanowania, dołączenia do CI/CD. Uproszczenie jest konieczne, bo nie uda się sprostać wymaganiom tempa rozwoju świata informatyki, gdyby musieć polegać na poziomie wiedzy inżynierskiej wymagającej zrozumienia sposobu działania tranzystora, czy pamiętania o zwalnianiu zajmowanych zasobów. Tu także świat poszedł na ilość kosztem jakości, a reszta jest konsekwencją.

Do trwających od pewnego czasu Cloud Wars dołączają spóźnieni (Oracle, IBM) i nowi (Alibaba) oraz gracze niszowi. Konkurencja będzie więc wzrastać, nasilając dodatkowo trendy multi-cloud. Coraz więcej będzie pokus i zachęt do „przesiadania się” pomiędzy ofertami konkurentów, co także przyspieszy cykle przenoszenia rozwiązań pomiędzy chmurami dla poszukiwania oszczędności. To wszystko będzie prowadzić do dalszych uproszczeń – Nicolas Carr was right, didn’t he…

Pozostaw komentarz