Chmura obliczeniowa wychodzi już dziś z każdej szafy i każdego portalu traktującego o IT. Wszyscy o niej mówią i stają po jednej z stron barykady. Pyta o nią tzw. biznes, który nauczony korzystania z popularnych usług SaaS (jak choćby Netflix, Dropbox czy Xbox Life) widzi w niej szansę na przyspieszenie swojego modelu pracy, przy jednoczesnym obniżeniu kosztów oraz pchnięciu swojej firmy na ścieżkę innowacyjności.
A potem przychodzi bolesna codzienność, gdzie owszem, chmura tak…, ale nie na zasadach SaaS (kupujesz gotowy produkt o skończonych możliwościach) ale na moich, własnych i jedynych, dopasowanych do mojego modelu i mojej organizacji. I tu zaczynają się schody.
Jeśli bliżej przyjrzymy się 3 największym dostawcom chmurowym wg. Gartnera, cały koncept chmury dla potrzeb tej dyskusji możemy uprościć do 4 faktów. Chmura obliczeniowa to:
Teoria brzmi prosto, ale teraz zaczynają się schody - inaczej bowiem uruchamia się konto na Netflix czy dodaje backup iPhone do iCloud, a inaczej zmienia się pryncypia architektury w firmie i dostarcza aplikację z chmury.
A miało być prościej… I będzie, ale nie pierwszego dnia i w pierwszym momencie. Jak każda rewolucja w IT - wymaga choćby odrobiny planowania.
Chmura, sama w sobie, nie dostarcza żadnej wartości dodanej - potrafi byś szybsza, bardziej efektywna, elastyczna, czasem tańsza. Oferuje również często usługi, których nie musimy tworzyć od zera. Jednak ten marketingowy przekaz nie zmieni przecież od razu naszego IT czy biznesu.
Potrzeba określić sobie cel, dla którego cały ten wysiłek podejmujemy. Tym celem może być chęć nauki i rozwoju, która w przyszłości pozwoli wykorzystać chmurę jako naturalne środowisko tworzenia aplikacji.
Ciekawszy cel to wykorzystanie chmury jako środowiska rozwoju dla projektów innowacyjnych, na wczesnej fazie, gdzie możemy wykorzystać choćby strategię Cloud Native dla swoich aplikacji czy przetestować często wymieniany Serverless. Albo zająć się analizą danych, o ile wcześniej je w chmurze umieścimy.
Automatyzacja - to słowo rzadko pada z ust kogokolwiek. Zgódźmy się, że nie brzmi tak atrakcyjnie jak innowacja czy redukcja kosztów. Automatyzacja to co najwyżej roboty i RBA a nie jakaś chmura przecież. A jednak automatyzacja jest kluczem i efektem. Dzięki niej mogę szybciej tworzyć środowiska, sprawniej wdrażać zmiany, lepiej budować procesy wydań aplikacji czy skalować rozwiązania ze względu na ruch. Automatyzacja i potraktowanie infrastruktury, tak samo jak kawałka kodu, który może nam ja utworzyć, daje potężny efekt. A czyż nie można tego zrobić on-premise? Można. Są narzędzia i podejście, dopiero jednak w chmurze widać wszystkie możliwości - automatyzacja tworzenia i konfiguracji w środowiskach on-premise nie jest bardzo powszechna.
Niektórzy mówią, że redukcja kosztów, to najciekawsza z obietnic i jedyna, która ma dla nich sens. Moim zdaniem, jest ona bardzo źle rozumiana, bowiem nastąpi faktycznie tam, gdzie wprowadzimy duży poziom automatyzacji, wykorzystanie usług PaaS/Serverless czy kontenerowych i ew. zmianę architektury. Dla mnie redukcja kosztów wcale nie jest taka istotna, jeśli poprzez szybkość i elastyczność mogę wpłynąć na zadowolenie klientów a przez to na efekt biznesowy, to wolę więcej zarabiać niż dodatkowo oszczędzić.
Bez jasnego celu i kryteriów mierzenia tego celu, proponuję nawet nie zaczynać i nie robić kroku dalej w chmurowym świecie. Tylko mając cel i wybierając kolejne kroki na ścieżce realizacji mam szansę na sukces, inaczej mamy murowaną szansę na chaos i udowadnianie, że "prawie się udało".
Nie lubię plotek i gminnych opowieści. A już w przypadku chmury, z reguły forują te stwierdzenia ci, którzy jeszcze nic i nigdy w niej nie zrobili.
Nawet jeśli model liczenia kosztów w chmurze jest skomplikowany, to niech rzuci pierwszy kamień ten, kto w swoim środowisku wie ile dokładnie kosztuje go pojedyncza aplikacja. Ale dokładnie, bez oszukiwania, estymacji i prawdopodobieństwa… No właśnie - to wcale nie jest proste. Tu przynajmniej jest to policzalne, model jest znany i dostępny, są nawet kalkulatory, które pozwolą to estymować.
Morał z tego jest prosty - warto wskazać kogoś, niekoniecznie od razu z działu, który zajmuje się licencjami, by zrozumiał ten model, zarówno pod kątem źródła kosztów, optymalizacji ale też predykcji dla nowych aplikacji.
Chmura, eksponując tak jawnie koszty środowisk i usługi, tylnymi drzwiami wprowadziła jeszcze jeden trend - optymalizacji rozwiązania ze względu na model koszty a co za tym idzie, wybrane usługi.
Koncepcja wielu chmur brzmi dobrze - część rozwiązań umieszczę u dostawcy A, część u dostawcy B a niektórzy jeszcze proponują by dynamicznie przenosić usługi pomiędzy dostawcami by było taniej… Od koncepcji do realizacji droga kręta, szczególnie jeśli koncepcja jest nie praktyczna. Przeniesienie usług od dostawcy A do B potrwa minimum tyle i przenoszenie danych.
Patrząc na fakt, że większość firm w Polsce (wg. badań Eurostatu) jest na początku swojej drogi, proponuję zacząć z jednym dostawcą, poznać jego wszystkie dobre i złe strony i ew. sięgnąć po drugiego czy trzeciego jeśli jest silny powód technologiczny i biznesowy. I tylko w całości per wybrana aplikacja i środowiska a nie pomiędzy.
Czy jednej chmura prowadzi do vendora locka dla firmy? Sam wybór chmury nie implikuje wyboru technologii, co najwyżej, dostawcę usług. Implikuje pewne decyzje architektoniczne czy podejście do projektowania, ale umówmy się, te koncepcje też są podobne. Czy w związku z tym plan wyjścia nie jest potrzebny?
Plan wyjścia z technologii, to coś, czego w Polsce wiele lat nie musieliśmy robić.
Rozwiązania były młode, dług technologiczny nie postępował, nie martwiliśmy się kosztami pracy. To już nie wróci.
Dziś żyjemy w zupełnie innej rzeczywistości i plan wyjścia to po prostu podejście do problemu starzejącej się technologii czy środowiska. Wyjście z chmury i powrót do świata hybrydowego to element tych dywagacji.
Kiedy już wszystko jest za nami, wiemy po co nam ta chmura, już wiemy, że nie zrobi się samo i że nie jutro, i nawet wiemy, że trzeba to wszystko zaplanować, zdobyć wiedzę czy wdrożyć, pojawia się dział bezpieczeństwa, który nie mówi nie… Czasem mówi, że wykorzystamy te same pryncypia, co w środowisku on-premise.
Pryncypia jak najbardziej, technologie czy podejście już nie zawsze.
Bo kiedy wchodzimy w szczegóły implementacji i pokazuje jak od poziomu architektury budować bezpieczne aplikacje, to okazuje się, że żaden z tych pryncypiów nie jest stosowane on-premises. Co więcej, rekomendacje bezpieczeństwa są ale tylko na poziomie sieci, infrastruktury czy kont katalogu użytkowników. Ale nie na etapie implementacji i kodu.
Dlatego warto swój dział bezpieczeństwa włączyć na wczesnym etapie, dostarczyć porcję wiedzy w temacie i bardzo szybko wypracować standard, który będzie obowiązywał na początku w naszej firmie.
Standard, prędzej czy później i tak się przyda. Wypracowanie go zajmuje chwilę czasu, ale potem pozwala wszystkie decyzje sprowadzić do standardu.
Z Chmurą nie jest inaczej.
Czas ją zaplanować w swojej firmie, nawet jeśli korzystanie z tego typu rozwiązań, skończy się na testach i informacji zwrotnej, że jeszcze nie teraz…. Jeśli jeszcze nie teraz… warto sobie zadać inne pytanie, czy gdyby organizację, w której pracujemy budowano od początku, czy jeszcze ktoś miałby czas i budżet na budowę wszystkich usług i warstw Centrum Danych od początku?
Zapewne nie.
Wiosenna edycja spotkań cyfrowych liderów!
Marszałkowska 18 lok 5
00-590 Warszawa
office@degroup.pl