Administracja chmurą

Pod jednym słowem kryją się dwie różne rzeczy i pomylenie ich kosztuje najwięcej na samym starcie. Pierwsza to praca biurowa: skrzynki pocztowe, dokumenty, spotkania online i służbowe urządzenia pracowników. Druga to infrastruktura: maszyny wirtualne, sieci, magazyn danych, uprawnienia do zasobów i automatyczne wdrożenia. Ta kategoria opisuje wyłącznie tę drugą warstwę.

Granicę widać najlepiej po sposobie liczenia. Warstwa biurowa rośnie z liczbą osób, więc rozlicza się od użytkownika i mieszka w kategorii Usługi Microsoft 365. Warstwa infrastrukturalna rośnie z liczbą maszyn i zasobów, więc rozlicza się od środowiska. Większość firm potrzebuje obu, tylko zamawia je osobno i osobno o nie pyta.

Jest jeszcze trzecia grupa: to, co nie jedzie nigdzie. Sterowniki maszyn produkcyjnych, wydruk, kontrola dostępu do drzwi i systemy branżowe bez wersji chmurowej zostają tam, gdzie stoją. To nie jest porażka projektu, tylko jego normalny wynik, i właśnie dlatego w tabeli poniżej stoi osobna pozycja o modelu mieszanym.

To dwie usługi o innym rytmie i innej fakturze. Migracja ma początek, koniec i protokół odbioru: przenosi ustalony zakres i w kolejnym miesiącu już jej nie ma. Administracja zaczyna się dzień po odbiorze i trwa tak długo, jak pracuje środowisko, bo tożsamość, uprawnienia, kopie i rachunek wymagają uwagi co tydzień, a nie raz.

Samą migrację warto kupić wtedy, gdy macie własnego administratora gotowego przejąć środowisko wraz z dokumentacją. Samą administrację wtedy, gdy jesteście już w chmurze, bo ktoś postawił ją przed nami. Najgorszy jest wariant trzeci: projekt zamknięty bez wskazanego następcy, po którym pół roku później nikt nie potrafi powiedzieć, kto miał patrzeć na logi i na rachunek.

Fakturę za serwer podpisuje się raz na kilka lat, rachunek za chmurę powstaje co godzinę i nie podpisuje go nikt. Zasób uruchomiony na jedno popołudnie pracuje potem miesiącami, bo jego wyłączenie nie jest niczyim zadaniem. To różnica organizacyjna, nie techniczna, więc samo narzędzie do analizy kosztów jej nie usunie.

Panowanie nad kwotą zaczyna się od wskazania właściciela każdego zasobu. Tagi kosztowe, budżety z alertami, harmonogramy dla środowisk nieprodukcyjnych i rezerwacje pod obciążenia stałe są konsekwencją tej decyzji, a nie jej zamiennikiem. Raz w miesiącu ktoś po Waszej stronie musi jeszcze przeczytać rozbicie rachunku i zapytać o największą pozycję.

Warto też trzymać osobno dwie faktury, bo w rozmowach zlewają się w jedną. Opłata za zużyte zasoby idzie do dostawcy platformy i zmienia się z miesiąca na miesiąc. Opieka nad środowiskiem jest stała i przewidywalna. Mieszanie ich powoduje, że po roku nie wiadomo, która część rachunku faktycznie urosła.

Obie pozycje to warsztat inżynierski, nie usługa dla każdej firmy, i lepiej powiedzieć to wprost, niż sprzedać komuś narzędzie, którego nie będzie miał kto używać. Docker pracuje przy oprogramowaniu wydawanym w kolejnych wersjach, więc ma sens tam, gdzie jest własny zespół programistów, dostawca aplikacji na utrzymaniu albo system uruchamiany w kilku środowiskach naraz.

Terraform stoi po stronie infrastruktury, nie aplikacji, więc korzysta z niego administrator. Opłaca się tam, gdzie środowisko ma więcej niż kilka zasobów i zmienia je więcej niż jedna osoba: opis w kodzie zastępuje wtedy pamięć, a plan zmiany zastępuje nadzieję. Przy jednej maszynie i jednym administratorze ta inwestycja się nie zwraca i mówimy to na rozmowie, a nie po wdrożeniu.