RegułyChaosu

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.

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.

Termin zwinności (agile, agility) robi karierę. Zachwycamy się podejściem zwinnym, w coraz to nowych obszarach. Wręcz zaczynamy to traktować jak nowe lekarstwo na „całe zło”. Jestem absolutnym fanem włączania cech zwinności w każdy z obszarów moich zawodowych zainteresowań. Agile jednak ponosi klęskę za klęską i wcale nie wynika to z tych cech, lecz z praktyki ich wykorzystania. No więc jak to jest w praktyce?

W kilku ostatnich projektach – w firmie z branży bankowości, branży bardzo świadomej zagadnień bezpieczeństwa – w których całość rozwiązania działała w oparciu o chmurę, miałem przyjemność pełnić rolę doradcy w zakresie architektury bezpieczeństwa. W tych projektach powtarzała się ewolucja myślenia o bezpieczeństwie w kontekście rozwiązań chmurowych – od robienia tradycyjnie (rozwiązania on-premises) do nowocześnie (chmura). Może być ciekawie?

Motywem, jaki często przewija się w dyskusjach o przyszłości IT jest temat wzrastającej trudności realizacji zadań inżynierii systemowej. Z jednej strony bowiem coraz trudniej o doświadczonych inżynierów. Z drugiej strony rosnąca złożoność, wielość możliwości i zależności między nimi stanowi coraz większy koszt realizacji rozwoju IT. A pomyłka w tej sferze potrafi się latami odbijać czkawką. Najczęstszą konkluzją z takich dyskusji jest „przejdźmy do chmury”, tylko co zrobić z dotychczasowym bagażem?

Odkąd Nicholas Carr opublikował “IT Doesn’t matter”, pomimo ówczesnego świętego oburzenia całej branży, rzeczywistość dowodzi po kawałeczku chyba każdą z jego tez. Wartość IT stopniowo przenosi się w kierunku od infrastruktury do aplikacji. Wieszczone przez Nicholasa „IT jak elektryczność” na dziś jest faktem dla infrastruktury sprzętowej, platformy operacyjnej i aplikacyjnej. Tę wizję wypełniły usługi chmurowe. Im bliżej aplikacji, tym sprawa jest mniej oczywista, ale dla większości „tego poniżej” sprawa jest raczej jednoznaczna.