Analiza problemu w istniejącym środowisku VMware vSphere: wydłużony czas provisioningu nowych maszyn wirtualnych, wydłużone oczekiwanie na first deployment nowych aplikacji/mikroserwisów, wysoki overhead i narzut infrastrukturalny/sprzętowy dla dużej liczby VM-ek na baremetalu.
Analiza możliwych rozwiązań i adresacja korzyści klastra Kubernetes jako potencjalnie przyszłościowego kierunku dla organizacji:
- Obniżenie narzutu sprzętowego, organizacyjnego i "ludzkiego" nad kontrolą dużej liczby VM-ek i ich provisioningiem
- Przyspieszenie zarówno first deploymentu, jak i kolejnych deploymentów
- Możliwość wdrożenia alternatywnych procesów QA do obecnych
- Konteneryzacja i eliminacja problemu "works on my machine"
- Możliwość postawienia oddzielnych środowisk developerskich, QA i stagingowych
Przygotowanie PoC na własnej infrastrukturze połączonej z firmową (VPN/SSH) — na klastrze K3s opisanym w poprzednim punkcie — z uruchomieniem i podłączeniem w pierwszej kolejności mniej istotnych mikroserwisów. Połączenie do firmowego staging config service przez VPN site-to-site do prywatnej infrastruktury z klastrem, w celu minimalizacji niezbędnych zmian w aplikacjach po zmianie metody deploymentu.
Przedstawienie planu, analiz, rozwiązań i PoC kluczowym pracownikom. Po zdobyciu aprobaty: zorganizowanie spotkania dla kluczowych deweloperów i pełne omówienie plusów, minusów oraz ryzyk, z którymi należy się zmierzyć. Wdrożenie rozwiązania w pierwszym kroku na środowisku stagingowym i oczekiwanie na greenlight produkcyjny.
Domknięciem procesu było wewnętrzne szkolenie/konferencja dla ~15 inżynierów (w tym CIO), tłumaczące decyzje architektoniczne za migracją i sposób korzystania z niej w codziennej pracy zespołów.