Nie możesz tego zwirtualizować!

Słyszymy to w IT bardzo często — dostawca mówi nam, że danego systemu nie można zwirtualizować. Powody bywają różne. Po stronie IT zawsze jesteśmy zszokowani, że dostawca stawia tak absurdalne twierdzenie; i równie często jesteśmy zszokowani, że klient (lub menedżer) mu wierzy. Dostawcy przez lata dopracowywali tę technikę sprzedażową i uważam, że warto ją dokładnie przeanalizować.

Główną przyczyną problemu jest fakt, że dostawcy niemal zawsze szukają sposobów na obniżenie własnych kosztów przy jednoczesnym zwiększaniu zysków ze sprzedaży klientom. To właśnie napędza wiele zachowań, które w innym kontekście wydawałyby się dziwne.

Jedną z rzeczy, którą próbuje robić wielu, wielu dostawców, jest ograniczanie scenariuszy, w których ich produkt będzie wspierany. Dzięki temu ustawiają się w pozycji, gdzie mogą po prostu odmówić wsparcia — wsparcie jest kosztowne i nieprzewidywalne. To powszechna strategia. W niektórych przypadkach jest ona tak agresywna, że żaden akceptowalny scenariusz wdrożenia produkcyjnego w ogóle nie istnieje.

Bardzo powszechnym sposobem na to jest brak wsparcia dla jakiegokolwiek obsługiwanego systemu operacyjnego, co de facto deprecjonuje własne oprogramowanie dostawcy (na przykład dziś oznaczałoby to wsparcie wyłącznie dla Windows XP i starszych). Innym przykładem jest wspieranie wyłącznie produktów, które nie są licencjonowane do danego zastosowania (przykładem byłby wymóg używania produktu takiego jak Windows 10 jako serwera). A jednym z najczęstszych przypadków jest zakaz wirtualizacji.

Scenariusze te stawiają klientów w trudnej sytuacji, bo z jednej strony mają branżowe najlepsze praktyki, standardowe wytyczne wdrożeniowe, wewnętrzne narzędzia i zasady, których muszą przestrzegać; z drugiej strony dostawcy często zabraniają właściwego projektowania, planowania i zarządzania systemami. Te potrzeby są ze sobą sprzeczne.

Oczywiście nikt nie oczekuje, że każdy dostawca będzie wspierał każdy możliwy scenariusz. Limity muszą istnieć. Ale jest ogromna przepaść między wspieraniem rozsądnych, prawidłowo wdrożonych systemów a aktywnym wymuszaniem niedopuszczalnie złych wdrożeń. Liczymy na to, że nasi dostawcy będą zachowywać się jak partnerzy biznesowi i będą mieć wspólny interes w naszym sukcesie lub przynajmniej w sukcesie swojego produktu — a nie będą aktywnie podkopywać tych celów. Mielibyśmy nadzieję, że przynajmniej wsparcie na zasadzie „najlepszych starań” byłoby dostępne dla każdego rozsądnego scenariusza wdrożenia, a wsparcie gwarantowane byłoby oferowane dla właściwie zaprojektowanych scenariuszy zgodnych z najlepszymi praktykami.

Wyobraźcie sobie świat, w którym jazda z dozwoloną prędkością i zapięty pas bezpieczeństwa unieważniałyby gwarancję samochodu, a wsparcie uzyskiwalibyście tylko wtedy, gdy jeździcie lekkomyślnie i bez zabezpieczeń!

Ważne jest zrozumienie kilku istotnych kwestii dotyczących wirtualizacji. Po pierwsze, wirtualizacja jest od dawna uznaną branżową najlepszą praktyką i oczekuje się jej stosowania w każdym scenariuszu wdrożenia produkcyjnego usług. Wirtualizacja nie jest w żaden sposób nowością — nawet na rynku małych firm jest w kategorii najlepszych praktyk od ponad dekady, a w przestrzeni enterprise od wielu dziesięcioleci. Dawno minął już czas, gdy uruchamianie systemów bez wirtualizacji było uznawane za akceptowalne — dotyczy to również starszych wdrożeń, które funkcjonują od dłuższego czasu.

Oczywiście zawsze istnieją rzadkie wyjątki od niemal każdej reguły. Niektóre systemy potrzebują dostępu do bardzo specjalistycznego sprzętu i wirtualizacja może nie być możliwa, choć przy nowoczesnym passthrough sprzętowym jest to dziś niemal niespotykane. Istnieją też systemy o ekstremalnie niskim latency, których nie można zwirtualizować, ale zazwyczaj ograniczają się one do największych międzynarodowych banków inwestycyjnych i najbardziej agresywnych funduszy hedgingowych — i nawet większość tych tradycyjnych przypadków użycia została wyeliminowana przez postęp w wirtualizacji. Ale konkluzja jest taka: jeśli nie możesz czegoś zwirtualizować, powinieneś tego żałować i będziesz wyraźnie wiedział, dlaczego jest to niemożliwe w twojej sytuacji. We wszystkich innych przypadkach twój serwer musi być wirtualny.

Czy to w ogóle jest ważne?

Jeśli dostawca nie pozwala ci przestrzegać standardowych najlepszych praktyk dla zdrowych wdrożeń, co to mówi o opinii dostawcy na temat własnego produktu? Gdybyśmy mówili o jakimkolwiek innym wdrożeniu, natychmiast zadalibyśmy pytanie, dlaczego wdrażamy system tak źle, skoro planujemy na nim polegać. Jeśli nasz dostawca zmusza nas do takiego zachowania, powinniśmy reagować w ten sam sposób — jeśli dostawca nie traktuje produktu z taką samą powagą, z jaką traktujemy nawet najmniej istotne nasze usługi IT, to dlaczego my mielibyśmy?

Jest to „niedopasowanie impedancji”, jak mówimy w kręgach inżynierskich, między naszymi potrzebami (systemy produkcyjne) a tym, jak dostawca tworzący ten system zdaje się je traktować (systemy hobbystyczne lub rozrywkowe). Jeśli musimy polegać na tym produkcie w naszych firmach, potrzebujemy dostawcy, który to rozumie i ma nastawienie produkcyjne. Jeśli produkt nie jest skierowany do biznesu lub nie jest gotowy do użytku biznesowego, musimy to wiedzieć. Musimy zadać sobie pytanie, dlaczego uważamy, że powinniśmy używać danej usługi produkcyjnie — usługi, od której zależymy i której wsparcia wymagamy — jeśli nie jest ona przeznaczona do takiego użycia.

Czy jest wspierany? Czy jest testowany?

Czymś, co klienci często pomijają, jest kwestia tego, czy niezbędne zasoby wsparcia dla produktu w ogóle istnieją. Nierzadko zdarza się, że zespół wspierający produkt zostaje okrojony, a nawet znika, podczas gdy firma kontynuuje sprzedaż produktu w nadziei na wyciśnięcie z niego jak najwięcej i licząc na to, że albo jakoś poradzi sobie z problemem, albo zwróci środki klientom, gdy okaże się, że po prostu nie jest w stanie go wesprzeć.

Większość umów na oprogramowanie stanowi, że maksymalne odszkodowanie, jakie można wyegzekwować od dostawcy, to koszt produktu lub kwota wydana na jego zakup. W takiej sytuacji dostawca nie ponosi żadnego ryzyka, oferując produkt, którego nie może wesprzeć — nawet pobierając premium za wsparcie. Jeśli klientowi uda się używać produktu, dostawca dostaje zapłatę. Jeśli klient nie może i dostawca nie może wesprzeć, traci tylko pieniądze, których i tak by nie dostał. Całe ryzyko ponosi klient, nie dostawca.

Sugeruje to oczywiście, że produkt jest mało lub w ogóle nie testowany na bieżąco — i powinno to być dodatkowym powodem do niepokoju. Sam fakt, że produkt działa, nie oznacza, że będzie działał nadal. Uruchomienie nieobjętego wsparciem — lub co gorsza, niemożliwego do objęcia wsparciem — produktu oznacza, że z czasem coraz bardziej polegasz na produkcie z prawdopodobnie malejącym poziomem potencjalnego wsparcia, który powoli się pogarsza, podczas gdy potrzeba wsparcia i zależność od oprogramowania będą wzrastać.

Jeśli zastrzeżony produkt jest wdrożony produkcyjnie i podjęto decyzję o rezygnacji z wdrożeń zgodnych z najlepszymi praktykami w celu spełnienia wymagań wsparcia, jak to może wpisywać się w macierz decyzyjną? Czy powinno to sugerować, że właściwe wsparcie nie istnieje? Znowu, jak poprzednio, implikuje to niedopasowanie naszych potrzeb.

 

Czy jest nadal rozwijany?

Jeśli wymagania dotyczące wdrożenia oprogramowania są zgodne ze starymi, przestarzałymi praktykami lub wymagają przestarzałego (lub nieaktualnego) oprogramowania bądź projektu, musimy kwestionować prawdopodobieństwo, że produkt jest aktualnie rozwijany. W niektórych przypadkach możemy to ustalić obserwując cykl wydań oprogramowania przez pewien czas, ale nie zawsze. Istnieje uzasadniona obawa, że produkt może być martwy, bez żadnego pozostałego zespołu deweloperskiego pracującego nad nim. Kod może być po prostu stary — technicznym długiem sprzedawanym w nadziei na zarobienie ostatnich kilku złotych ze starej bazy kodu, która została porzucona. Ten proceder jest w rzeczywistości znacznie powszechniejszy, niż się zazwyczaj sądzi.

Mniejsze firmy programistyczne często zdołają opracować wstępny pakiet oprogramowania, wprowadzić go na rynek i udostępnić do sprzedaży, ale nie są w stanie pozwolić sobie na utrzymanie lub uzupełnienie zespołu deweloperskiego po wstępnych wydaniach. Jest to w rzeczywistości bardzo powszechny scenariusz. Pozostawia to klientów z produktem, który z czasem będzie coraz mniej opłacalny, a scenariusze wdrożenia będą coraz bardziej ryzykowne, a dane coraz trudniejsze do wyodrębnienia.

 

Jak można wspierać coś, co nie ma wsparcia na poziomie platformy?

Powszechnym paradoksem niektórych bardziej ekstremalnych sytuacji jest oprogramowanie, które — aby kwalifikować się jako „wspierane” — wymaga innego oprogramowania, które albo jest poza wsparciem, albo nigdy nie było wspierane dla zamierzonego przypadku użycia. Typowymi przykładami są wymóg uruchamiania systemu serwerowego na desktopowym systemie operacyjnym lub wymaganie wersji systemów operacyjnych, baz danych lub innych komponentów, które w ogóle nie są już wspierane. Ten ostatni scenariusz jest przerażająco powszechny. W takiej sytuacji trzeba zapytać: czy istnieje kiedykolwiek wdrożenie, w którym oprogramowanie może być uznane za „wspierane”? Jeśli część stosu jest zawsze poza wsparciem, to cały stos jest nieobsługiwany. Zawsze znajdzie się powód do odmowy wsparcia, niezależnie od okoliczności. Właśnie ten powód, dla którego wymagalibyśmy rezygnacji z najlepszych praktyk, w równym stopniu dyskwalifikowałby wybór samego oprogramowania na wstępie.

Czy brakuje umiejętności i wiedzy branżowej?

Być może problem, z którym się borykamy w związku z takimi problemami ze wsparciem oprogramowania, polega na tym, że zespoły tworzące oprogramowanie po prostu nie wiedzą, jak tworzy się dobre oprogramowanie i/lub jak wdraża się dobre systemy. To jeden z najbardziej rozsądnych i uzasadnionych powodów, które mogłyby nas doprowadzić do tej sytuacji. Ale podobnie jak inne hipotetyczne przyczyny, budzi obawy co do jakości oprogramowania i możliwości uzyskania prawdziwego wsparcia. Jeśli nie możemy ufać dostawcy w prawidłowym obsłużeniu najbardziej widocznych elementów systemu, dlaczego mielibyśmy zwracać się do niego jako do ekspertów w zakresie tych części, których nie możemy zweryfikować?

Główny problem

Główny, nadrzędny problem z oprogramowaniem, które stawia wątpliwe wymagania dotyczące wdrożenia i utrzymania w zamian za odblokowanie w innym razie wstrzymywanego wsparcia, nie jest — jak zwykle zakładamy — kwestią ogólnej jakości oprogramowania, ale opłacalności praktyk wsparcia i rozwoju. Fakt, że te kwestie sugerują poważne obawy dotyczące długoterminowego wsparcia, powinien skłonić nas do mocnego kwestionowania, dlaczego w ogóle wybieramy te pakiety, oczekując od nich silnego wsparcia, gdy od samego początku mamy bardzo widoczne i bardzo poważne zastrzeżenia.

Istnieją oczywiście przypadki, gdy nie istnieje żadne inne oprogramowanie spełniające daną potrzebę lub żadne o bardziej rozsądnej opłacalności. Taka sytuacja powinna być niezwykle rzadka i jeśli istnieje, powinna być postrzegana jako poważna szansa rynkowa dla dostawcy chcącego wejść w tę niszę.

Z biznesowego punktu widzenia konieczne jest, aby najlepsze praktyki infrastruktury technicznej nie były całkowicie ignorowane na rzecz ślepego lub niemal ślepego podążania za wymaganiami dostawcy, które w każdym innym przypadku byłyby uznane za lekkomyślne lub nieprofesjonalne. Dlaczego tak często zaniedbujemy wymaganie doskonałości od kluczowych produktów, od których zależą nasze firmy? Naraża to nasze przedsiębiorstwa na ryzyko — nie tylko ze względu na samo działanie, ale w o wiele większym stopniu ze względu na ryzyko, które jest implikowane przez istnienie takich wymagań.