Chmurowy dylemat CIO: samodzielna budowa czy zakup gotowego rozwiązania?

Ostatnie lata w polskim świecie IT upłynęły pod znakiem topniejących budżetów, ciągle zmniejszającej się dostępności specjalistów na rynku oraz nieustannie przyśpieszającego wyścigu w stronę innowacji. Nieodłącznym motywem przewodnim, pozwalającym na utrzymanie konkurencyjności, jest model operacyjny ITaaS (IT as a Service), wdrażany na poziomie infrastruktury za pomocą chmury obliczeniowej.

Stając przed wyzwaniem wdrożenia chmury (co wpłynie praktycznie na każdy z obszarów organizacji) , mamy do wyboru dwie opcje: podejście BYO (ang. Build Your Own), czyli integrację dostępnych na rynku komponentów, lub kupienie gotowego rozwiązania od jednego z dostawców.

Które z tych podejść jest lepsze? To oczywiście zależy od realiów biznesowych danej organizacji. Jeżeli jej głównym zadaniem ma być tylko i wyłącznie dostarczanie usług na poziomie infrastruktury, a równocześnie ma ona odpowiednią liczbę kompetentnych pracowników, to podejście BYO i zbudowanie szytej na miarę platformy może być dobrym pomysłem. Ale nie wszystkie organizacje mają taki profil działania i dla zdecydowanej większości chmura będzie tylko jednym z elementów – narzędziem, które przyśpiesza dostarczanie infrastruktury dla biznesu, zapewnia zwinność oraz rozliczalność. Stosując analogię do otaczającego nas świata, z chmurą jest jak z samochodami –kupujemy gotowy produkt, a producent zapewnia serwis i integralne działanie całości, co nie przeszkadza nam, jako kierowcom, z niego korzystać. Podobnie jest z implementacją chmury. Jeżeli nie jest to nasza główna kompetencja, to nie potrzebujemy znać całego stosu, który tworzy platformę chmurową. Kupujemy gotowe rozwiązanie, które wykorzystujemy do wdrożenia katalogu usług i jako bazę do stworzenia wyższych warstw, takich jak np. aplikacyjna PaaS.

Przy podejmowaniu decyzji o rozpoczęciu wdrożenia chmury obliczeniowej zawsze najistotniejszym czynnikiem decyzyjnym jest koszt całego projektu oraz koszty operacyjne utrzymania platformy. Główną składową kosztów stanowi praca ludzka potrzebna do zintegrowania rozwiązania w jedną całość, a także tzw. operacje dnia drugiego (ang. day 2 operations), czyli wszystkie procesy związane z późniejszym utrzymaniem całości. Kupując gotowe rozwiązanie przenosimy odpowiedzialność za wspomniane kwestie na dostawcę. Zadba on o to, żeby cały stos architektoniczny rozwiązania, czyli część obliczeniowa, sieć, zasoby pamięci masowych, warstwa wirtualizacji oraz automatyzacji i orkiestracji CMP (ang. Cloud Management Platform) działał przez cały okres użytkowania i aby podnoszenie wersji poszczególnych elementów nie wpływało na całość platformy. Tworząc plan biznesowy na chmurę należy bardzo dokładnie przyjrzeć się, jak powyższe czynności obciążą naszych specjalistów i zastanowić, czy nie będziemy potrzebować ich czasu do bardziej innowacyjnych działań.

Bardzo ważnym aspektem w przypadku chmury jest również zapewnienie bezpieczeństwa platformy oraz ochrona inwestycji. Dostawca gwarantuje nam, że produkt będzie rozwijany i pojawią się nowe funkcjonalności, zapewnia ponadto ścieżkę aktualizacji, która nie spowoduje przestoju w działaniu tak krytycznego zasobu, jakim jest chmura. W przypadku podejścia BYO, wewnętrzny zespół IT musi oddzielnie testować każdą aktualizację wersji poszczególnego komponentu, co przy braku środowiska testowego (a przeważnie klienci nie budują go ze względu na koszty), może być bardzo trudne i czasochłonne. Ponadto nawet dokładne testowanie w niektórych przypadkach nie uchroni przed awarią, spowodowaną zmianą w API jednego z komponentów.

Na zakończenie warto podkreślić, że jeśli w danej organizacji chmura nie została jeszcze wdrożona, oznacza to, że część jej konkurencji w obszarze IT jest już w stanie dużo szybciej reagować na potrzeby biznesu. Typowe projekty wdrożeniowe chmury obliczeniowej trwają od ok. 6-8 miesięcy do kilku lat, w zależności od zakresu projektu. A więc najszybszą drogą do dogonienia konkurencji będzie kupienie gotowego produktu, zintegrowanie go z wewnętrznymi systemami i skupienie się na budowaniu wartości dodanej na wyższych warstwach niż infrastruktura – zamiast budowania platformy od zera.

About the Author: Filip Kata