RegułyChaosu

Elastyczność, to jedno z najczęściej spotykanych wymagań stawianych przed rozwiązaniami informatycznymi, wynikające z braku wiedzy o przyszłych potrzebach. Pomijając powody, dla których miejsce otwartej dyskusji o unknowns zajmuje amorficzne i efemeryczne wymaganie elastyczności, jakoś trzeba się z nim zmierzyć i pomóc – szczególnie tym wstydliwym lub zobowiązanym do „wszystkowiedzenia” – dać sobie z nim radę.

Realia współczesnego „robienia biznesu” nie dają komfortu podejmowania decyzji posiadając wszystkie dane. Podejmując decyzje biznesowe menedżerowie kierują się heurystykami i wyczuciem. Coraz częściej bowiem nawet suboptymalna decyzja podjęta we właściwym tempie okazuje się lepsza, niż super optymalna decyzja podjęta „chwilkę później”. Wszak chodzi o to, żeby nie wypaść oraz żeby nie popełniać dużych błędów. A jak w tej sytuacji podejmowane są decyzje architektoniczne?

Jak podpowiada doświadczenie w każdej z dziedzin działalności człowieka, także rozwój w IT jest procesem cyklicznym. Co pewien czas następuje przewartościowanie – terminy i praktyki uznawane za obowiązujące muszą ustąpić z pierwszych miejsc, przy czym ustępują często miejsca terminom i praktykom uznawanym przez jakiś wcześniejszy czas za co najmniej passé. Wygląda na to, że konfigurowanie sucks, kodowanie rocks!

Oczywiście, że ma, jak (prawie?) wszystko – a w naszej branży chyba wręcz „wypada, żeby miało”. Większość decyzji w IT podejmowana jest pod wpływem wyliczeń TCO. Byłem przez jakiś czas „w okolicy” szeregu takich decyzji. Upłynął jednak pewien czas, wystarczająco długi, aby pozwalał na wnioskowanie. No i coś poszło nie tak z tym TCO zwinności, bo nie wychodzi.

Rok 2021 co prawda należy do Stanisława Lema, ale Janusz Zajdel też daje radę, if You know, what I mean. Lektura dzieł obu Panów zawsze wywoływała we mnie refleksje o naturze człowieka oraz o powiązaniach filozofii i technologii. Ostatnimi czasy – po części z powodu wątków chmurowych – filozofia i technologia splatały mi się w obszarze architektury mikroserwisów. No właśnie, ale czy to na pewno mikroserwisy? A może bardziej mikreserwisy?

Czytając wpisy z serii Hybrid Multicloud można byłoby dojść do wniosku, że za chwilę całe ogólnocywilizacyjne IT będzie w rękach i pod pełną kontrolą kilku firm. Czyżby świat IT uzyskał ostateczną postać poukładania, w której wszystko jest już jasne i wszystko wreszcie wiadomo?

Kiedy słucham o złożoności budowy aplikacji działających w środowisku hybrydowym lub multi-cloud, odnoszę wrażenie, że aby cokolwiek zrobić w takim scenariuszy trzeba łączyć zdolność inżynieryjną Mr Spocka ze szczęściem Arsena Lupin. Większość takich opowieści wygląda jak film Alfreda Hitchcocka – zaczyna się od trzęsienia ziemi, a potem napięcie zaczyna narastać. Czy naprawdę tak musi być?

Skoro już prawie wiemy, że IT będzie z gniazdka (choć po prawdzie to w kilku gniazdek), trzeba zacząć się z tym oswajać. Skoro to nieuniknione, warto spojrzeć, co to zmienia w zakresie typowych obowiązków ludzi z informatyki. Moja ulubiona sfera takiej działalności to Operations & Maintenance (O&M) i to jest ciekawy przykład ilustrujący inną stronę złożonej chmurowości, czy też złożoności chmurowej.