Klient mówi: kupmy osobny serwer, aplikacja będzie działać tylko przez 18 miesięcy. Brzmi rozsądnie przez pierwsze pięć minut. Potem pojawiają się pytania o zakup, termin dostawy, administrację, kopie zapasowe, odtworzenie po awarii i to, co stanie się ze sprzętem po zakończeniu projektu. Nagle prosty serwer staje się zobowiązaniem, które żyje dłużej niż sama aplikacja.
Dla firmy tworzącej oprogramowanie to nie jest tylko decyzja techniczna. To decyzja wpływająca na marżę projektu, tempo wdrożenia i zaufanie klienta. Jeżeli zespół zgodzi się na zakup sprzętu bez porównania wariantów, bierze na siebie rozmowę o utrzymaniu, awariach i kosztach, które nie zawsze mieszczą się w pierwotnej wycenie.
Projekt czasowy potrzebuje infrastruktury czasowej.
Aplikacja uruchamiana na około 18 miesięcy ma inną logikę niż system budowany na wiele lat. W takim projekcie liczy się szybkie uruchomienie, przewidywalny koszt miesięczny, jasne granice odpowiedzialności oraz możliwość bezpiecznego zakończenia utrzymania. Zakup sprzętu często daje pozorne poczucie kontroli, ale zamraża budżet i przesuwa uwagę zespołu z aplikacji na administrację.
Środowisko usługowe w prywatnej chmurze zmienia tę rozmowę. Klient nie kupuje urządzenia, którego później musi pilnować. Finansuje środowisko potrzebne do działania aplikacji w konkretnym okresie. Firma tworząca oprogramowanie może wtedy rozmawiać o dostępności, kopiach zapasowych, odtworzeniu i oknach serwisowych zamiast o specyfikacji sprzętu.
Porównanie zacznij od całego cyklu życia.
Najgorsze porównanie brzmi: ile kosztuje serwer, a ile kosztuje usługa. Takie zestawienie pomija najważniejsze elementy. Do zakupu sprzętu dochodzi administracja, miejsce, energia, aktualizacje, monitoring, kopie zapasowe, częściowy lub pełny plan odtworzenia oraz koszt pracy ludzi. Dochodzi też koniec projektu, czyli moment, w którym aplikacja przestaje być potrzebna, ale sprzęt nadal istnieje.
Lepsze porównanie obejmuje 18 miesięcy od decyzji do zamknięcia. Sprawdzasz, kiedy środowisko będzie gotowe, kto nim zarządza, jak często powstają kopie, kto wykonuje test odtworzenia, kto odpowiada za dostęp administracyjny i jak wygląda wyłączenie po zakończeniu umowy. Dopiero wtedy klient widzi, czy zakup sprzętu naprawdę jest tańszy, czy tylko wygląda taniej na pierwszej stronie oferty.
Izolacja klienta to fundament, nie dodatek.
Firma tworząca oprogramowanie często prowadzi kilka wdrożeń równolegle. Dlatego środowisko dla klienta powinno być oddzielone od innych projektów. Chodzi o dostęp, dane, konfigurację, konta administracyjne i odpowiedzialność za zmiany. Izolacja ogranicza ryzyko, że test jednej aplikacji wpłynie na drugą albo że dane klienta trafią do nieuprawnionego zespołu.
W prywatnej chmurze można zaprojektować osobne środowisko dla aplikacji, bazy danych i usług pomocniczych. Nie trzeba przy tym deklarować nadmiarowych parametrów na zapas. Ważniejsze jest ustalenie, kto ma dostęp, jakie dane są produkcyjne, jakie są testowe i kto akceptuje zmianę przed wdrożeniem. To porządkuje technikę i komunikację z klientem.
Migawki pomagają przy zmianach, ale nie zastępują kopii zapasowych.
Przed aktualizacją aplikacji, migracją bazy albo większą zmianą konfiguracji warto wykonać migawkę środowiska. Daje ona możliwość szybszego powrotu do wcześniejszego stanu, gdy wdrożenie zachowa się inaczej, niż zakładał zespół. To bardzo praktyczne narzędzie dla projektów, w których zmiany są częste, a okna techniczne krótkie.
Nie wolno jednak sprzedawać migawek jako pełnej strategii bezpieczeństwa. Migawka pomaga przy cofnięciu konkretnej zmiany. Kopia zapasowa i plan odtworzenia odpowiadają na szersze ryzyka: błąd użytkownika, awarię, utratę danych albo konieczność przywrócenia usługi po poważniejszym incydencie. Klient powinien rozumieć tę różnicę przed podpisaniem umowy.
Plan odtworzenia ustala się przed awarią.
Jeżeli aplikacja ma obsługiwać procesy klienta, rozmowa o SLA, RTO i RPO nie może pojawić się dopiero po wdrożeniu. Firma tworząca oprogramowanie powinna ustalić, jak długo klient może czekać na powrót usługi, ile danych może odtworzyć z ostatniej poprawnej kopii i kto uruchamia procedurę awaryjną. Bez tego każda awaria staje się negocjacją prowadzoną pod presją.
Dobry plan obejmuje także test odtworzenia po ważnym wdrożeniu. Nie chodzi o pokaz techniczny. Chodzi o potwierdzenie, że aplikacja, baza i zależności wracają do działania w sposób zgodny z ustaleniami. Taki test porządkuje odpowiedzialność między zespołem tworzącym oprogramowanie, administratorem środowiska i klientem.
Migracja bez przestojów wymaga scenariusza powrotu.
Przeniesienie aplikacji do nowego środowiska nie powinno opierać się na nadziei. Najpierw spisujesz zależności: baza danych, integracje, zadania cykliczne, konta użytkowników, certyfikaty, dostęp zdalny i powiadomienia. Potem przygotowujesz okno techniczne, testujesz aplikację w nowym środowisku i ustalasz, kiedy następuje przełączenie.
Plan powrotu jest tak samo ważny jak plan migracji. Jeżeli po przełączeniu pojawi się błąd krytyczny, zespół musi wiedzieć, kto podejmuje decyzję o cofnięciu, ile czasu ma na diagnozę i jak komunikuje status klientowi. Bez tego nawet dobrze przygotowana migracja może zamienić się w chaotyczne spotkanie wielu osób bez jednej decyzji.
Jak rozmawiać z klientem o prywatnej chmurze.
Najlepszy argument nie brzmi: nie kupuj serwera. Lepszy brzmi: dobierzmy model do czasu życia aplikacji i ryzyk projektu. Jeżeli system ma działać przez 18 miesięcy, klient potrzebuje przewidywalnego kosztu, izolowanego środowiska, kopii zapasowych, planu odtworzenia oraz jasnego zakończenia utrzymania. Sprzęt jest tylko jednym ze sposobów realizacji tego celu.
W takim modelu NSIX może dostarczyć prywatną chmurę i serwery wirtualne na potrzeby środowiska aplikacyjnego, baz danych, dostępu zdalnego, backupu, firewalli oraz VPN. Opis pozostaje ogólny, bo właściwy zakres wynika z aplikacji, wymagań klienta i ustaleń dotyczących odpowiedzialności. Dla firmy tworzącej oprogramowanie najważniejsze jest to, że rozmowa wraca do projektu, a nie do posiadania sprzętu.
Decyzja powinna być policzona, a nie przeczuta.
Jeżeli klient chce kupić osobny serwer na 18 miesięcy, nie zaczynaj od polemiki. Przygotuj porównanie dwóch wariantów. Po jednej stronie wpisz zakup, utrzymanie, administrację, kopie zapasowe, odtworzenie, ryzyko końca projektu i koszt pracy. Po drugiej stronie wpisz środowisko usługowe, izolację, migawki przed zmianami, plan odtworzenia i przewidywalny koszt miesięczny.
Taka rozmowa jest uczciwa i konkretna. Czasem zakup sprzętu będzie miał sens. Często jednak projekt czasowy lepiej pasuje do środowiska usługowego, które można uruchomić, utrzymywać i zakończyć zgodnie z życiem aplikacji. Skorzystaj z kalkulatora decyzji: zakup sprzętu czy środowisko usługowe na czas projektu, i przygotuj klientowi wariant, który da się obronić technicznie oraz biznesowo.