Minęło już parę lat od kiedy przetwarzanie w chmurze wkroczyło na scenę, a jednym z pierwszych dostawców tego rozwiązania był Amazon. Wykorzystanie farm danych osiąga u nich maksimum w okresie Bożego Narodzenia, co oznacza, że w pozostałych częściach roku posiadają na sprzedaż wolne zasoby i ci, które chcą je nabyć, mogą to zrobić za ułamek kosztów, jakie mała firma musi ponieść w innym wypadku. Tak narodziła się nowa gałąź przemysłu.
Niemal natychmiast (jak na przemysł) przedsiębiorstwa zaczęły przekazywać swoje przetwarzanie do innych firm (AWS, Google, Microsoft i innych), które posiadały komputery, ludzi, fizyczne zakłady, bezpieczeństwo i wszystko inne, potrzebne do wykonania tego zadania.
Zalecałem korzystanie z wielu z tych usług w chmurze nowym, zaczynającym działalność firmom. Jeśli chodzi o przestrzeń otwartych źródeł, to można skorzystać z serwisów takich jak SourceForge, GitHub, GitLab i innych „usług w chmurze”, które ułatwiają rozwój i współpracę przy tworzeniu oprogramowania (a nawet sprzętu) oraz zmniejszają koszty pracy.
Problemem są dwie kwestie: rozrost i przywiązanie do jednego dostawcy. Obie towarzyszą przemysłowi komputerowemu od dziesięcioleci.
Przywiązanie do jednego dostawcy zdarza się, kiedy deweloperzy korzystają z interfejsów lub funkcji, które nie są standardowe. Nawet w czasach prostszych programów istniały standardy, które pozwalały na przenoszenie programów z komputera na komputer, pod warunkiem, że programista kodował korzystając z tych standardów. Niemal w każdym komercyjnym kompilatorze znajdowały się „rozszerzenia” tych standardów, które pozwalały programistom pisać łatwiej i efektywniej wykonywać kod. Rozszerzenia te zwykle opisywane były w szarej (czasami w innym kolorze) dokumentacji z ostrzeżeniem, że to jest rozszerzenie i jeśli programista chciał zachować przenośny kod, mógł go unikać.
Dobry programista mógł wtedy dodać „wyjście awaryjne”, które realizowało tylko standardowy kod, ale jeśli środowisko pozwalało na użycie rozszerzeń, to mogłyby one działać, albo przez ponowną kompilację, albo przez parametry uruchomieniowe.
Jest to prosty przykład, ale te „rozszerzenia” standardów zdarzają się na każdym poziomie, od języków programowania, przez biblioteki i wywołania systemowe, po interfejsy systemów w chmurze, które dostawcy udostępniają czasami jako coś, co daje przewagę nad konkurencją.
Wszystko to mogłoby być w porządku, jeśli nasza usługa w chmurze gwarantowałaby zawsze najniższe koszty, największą stabilność, czy udostępniałaby wszystkie usługi jakich potrzebujemy wraz z rozwojem firmy. Ja jednak pracowałem dla niektórych z największych firm na świecie, o których myślałem, że będą „wieczne”, a których już nie ma. Musimy być gotowi na zmiany i to czasami bardzo szybkie.
Drugim powodem, dla którego trzeba zachować elastyczność pod względem przenośności jest rosnąca cena usług w chmurze w stosunku do uruchomienia własnych serwerów, szczególnie w niektórych środowiskach. Koszty te mogą być natury ekonomicznej i politycznej. Im bardziej nasza firma rośnie, tym bardziej powinniśmy tworzyć plany na wypadek konieczności przeniesienia się lub wydzielenia naszego przetwarzania.
Inspiracją dla tego artykułu był opublikowany niedawno raport, pokazujący jak dla niektórych użytkowników gwałtownie wzrósł koszt usług w chmurze (ze względu na zwiększenie liczby danych lub obciążenia) – do tego stopnia, że dla niektórych dużych firm praktyczniejszym będzie utworzenie własnych centrów danych mimo tego, że kilka lat temu przeszły do chmury. Niestety, przejście do innego dostawcy w chmurze, nie mówiąc już o własnym sprzęcie, często jest złożonym i kosztownym procesem.
Poza zachowaniem elastyczności przez przenośność, pracując z narzędziami zmniejszającymi obciążenie procesora, wykorzystanie danych, sieci i Internetu, możemy zredukować (czasami drastycznie) opłaty za wykorzystanie usług w chmurze.
W ostatnim czasie programista, z którym kiedyś pracowałem przeglądał starszy kod projektu, w który był zaangażowany i odkrył aplikację, która wykonywała dynamiczną alokację pamięci potrzebnej dla każdej częściowej transakcji. Jest to zbyt skomplikowane, aby tu opisywać, ale sprowadza się do tego, że każda transakcja wydłużała się o 1,200 milisekund (tak, po przeliczeniu to jest 1.2 sekundy). Dla użytkowników to niezwykle powolne działanie, a dodatkowo niepotrzebnie obciąża serwer. Programista zmienił algorytm tak, aby obliczać jak dużo pamięci trzeba zarezerwować i tyle dokładnie alokował. W rezultacie obciążenie procesora spadło do zera. Takie oszczędności mogą nie robić wrażenia przy jednym użytkowniku lub pracy na laptopie, ale przy setkach użytkowników korzystających z serwera zużycie procesora rośnie gwałtownie.
