Jakiś (dłuższy) czas temu pisałem na blogu artykuł, w którym omawiałem różnice między On-premises a rozwiązaniem w chmurze. Poza moimi refleksjami zamieściłem w nim również krótki film z debaty oksfordzkiej, na której chłopaki wymieniali się swoimi przemyśleniami dotyczącymi właśnie tych rozwiązań. Jak to bywa na debatach, zdania były podzielone. W trakcie dyskusji padały wprawdzie ciekawe argumenty, niemniej brakowało mi w niej jednak konkretów – lub jak kto woli, przełożenia poruszanych kwestii na praktykę.
Od czasu, kiedy obejrzałem tę dyskusję, minęły już dwa lata – wystarczająco dużo, abym konkrety i praktykę zdobył we własnym zakresie 😊. Zdobywana wiedza skłoniła mnie do odkopania tego tematu i napisania niniejszego artykułu. Opisuję w nim znane mi z autopsji przypadki: zarówno takie, w których wygrała chmura, jak i te, gdzie triumfowało zastosowanie On-premises.
Przykład 1 czyli całkowite zwycięstwo chmury
Mój zespół miał za zadanie zintegrowanie 12 różnych firm z 12 różnych krajów, które miały agregować dane i wysyłać je do centrali. Zadanie było dość proste i polegało na stworzeniu łącznika, odbierającego dane z jednej strony, przetwarzającego je i w końcu wysyłającego dalej. Największym problemem, który napotkaliśmy było to, że każdy z tych krajów używał innego sposobu komunikacji. Jedni korzystali z REST API, inni z Plików .csv, jeszcze inni z soap service. Znalazł się nawet kraj, który dalej działał na bashu 😊 (to, jakie konkretnie było to państwo, pozostawiam Wam już jako zagadkę).
W tym projekcie wykorzystaliśmy całkowicie usługi serverless oraz PaaS, która z definicja dała nam nie tylko możliwości skalowania wertykalnie, ale również znacznie zmniejszyła koszy developmentu i ograniczyła udział osoby odpowiedzialnej za infrastrukturę. Przy wykorzystaniu Terraform.io byliśmy w stanie stworzyć całą infrastrukturę i w ciągu zaledwie kilku minut być gotowym do udostępnienia aplikacji produkcyjnie. Rozwiązanie chmurowe nie tylko obniżyło koszty, ale również bardzo mocno przyśpieszyło development.
Przykład 2, czyli zastosowanie hybrydowe
Pewien klient, który posiadał bardzo starą aplikację (bo napisaną jeszcze w okolicach roku 2010), chciał przejść do chmury, ponieważ zarządzanie aplikacjami i serwerami było dla niego kosztowne. Na start zastosowaliśmy rozwiązanie hybrydowe i przynieśliśmy tylko bazy danych do chmury, pozostawiając aplikację serwerową na starych serwerach. Pozwoliło nam to znacznie obniżyć koszty związane z administracją bazy danych oraz automatyzować wszystkie backupy. Kolejnym plusem było to, że bazy danych były centralnie zarządzane przez jednego klienta, więc gdy był zgłoszony jakikolwiek błąd, mogliśmy zareagować natychmiastowo.
Przykład 3, czyli wykorzystanie całkowicie serwera On-premises
Historia ta wydarzyła się u jednego z moich klientów w Niemczech. Na początku współpracy zauważyłem, że używa on serwera Windows przy bardzo małej firmie obejmującej jedynie 5 stanowisk biurowych korzystający z komputerów oraz 10 osób, które są w terenie i nie korzystają z systemu w ogóle. Zacząłem się zastanawiać, dlaczego zdecydowano się na płatną licencję w tak małej firmie.
Pierwsza moją myślą oczywiście było: zastosować chmurę, bo po co mamy wykorzystywać własny serwer, za który płacimy nie małe pieniądze. Do zarządzania komputerami możemy użyć Microsoft Endpoint Manager (MEM). A jeżeli potrzebują swój wewnętrzny ftp, to użyjemy Azure Storage, który jest skalowalny i znacznie tańszy niż utrzymywanie licencji Windows serwera. Po głębszej analizie rozmowy z klientem zauważyłem jednak kilka ciekawych rzeczy, o których na samym początku nie pomyślałem. I tutaj bazując na moim doświadczeniem pokazuje, jak dużo może być zmiennych, które musimy wziąć pod uwagę.
Mianowicie. Może nie wszyscy wiedzą, ale w Niemczech jest jeszcze bardzo wolny Internet. Bardzo dużo ludzi używa tam jeszcze zamiast światłowodów… złącz miedzianych. Zatem, jeżeli weźmiemy pod uwagę to, że chcemy używać aplikacji wewnątrz firmy, która wymaga przetworzenia kilkunastu lub kilkuset gigabajtów dziennie i wysłania ich do użytkowników, to wtedy okazuje się, że chmura całkowicie leży. Nie będąc podłączonymi do sieci światłowodowej, czy też do Internetu, jesteśmy całkowicie odcięci od pracy. A nic nie jest bardziej kosztowne niż bezczynność pracownika czekającego godzinę na na pobranie plików do pracy.
Podsumowując…
Doświadczenie pokazało mi, że powinniśmy patrzeć holistycznie na to jakie rozwiązanie wybieramy. W którą stronę chcemy iść i dla czego? Mimo że chmura marketingowo sprzedaje się bardzo dobrze, to sprawdzone, „stare” sposoby dalej są na chodzie i dalej mogą bardzo obniżyć koszty. Właśnie dlatego powinniśmy bardzo świadomie podchodzić do projektu i brać wiele czynników pod uwagę – nawet takich jak dostęp do Internetu podczas wyboru czy to softu, czy też rozwiązania, które chcemy hostować.
Wracając do wspomnianej na początku artykułu debaty. Uważam, że chłopaki skupili się w niej właśnie na rozwiązaniach bardzo mocno Enterprise, gdzie takie rzeczy jak dostęp do Internetu są standardem i nie ma w tym żadnych ograniczeń. W całej tej rozmowie pojawiły się bardzo fajne argumenty na rzecz takich sytuacji – niestety zabrakło wniosków, które pomogłyby nam inżynierom, czy też użytkownikom, planować wybór między serwerem On-premises a serwerem w chmurze.
Azure cloud code&cloud on-premises
Last modified: 7 września 2022
