Idzie nowsze w świecie aplikacji i narzędzi programistycznych. Kod w kontenerach
Obecnie programiści, tworząc oprogramowanie, stosują podejścia takie jak "serverless", jak i "serverfulu". Serverless to sposób na uruchamianie aplikacji bez udziału serwerów, choć to jedynie pozory, bo serwery zawsze są angażowane. "Brak serwera" polega na tym, że w tym podejściu nie trzeba nic robić na etapie uruchomienia aplikacji, są one wstępnie skonfigurowane. Podejście serverful przenosi praktykę serverless do kontenerów.
I w tym momencie konieczne jest wprowadzenie kolejnego nowego słowa klucza - Kubernetes (K8S). Nazywa się tak platformę open source do zarządzania, automatyzacji i skalowania aplikacji kontenerowych. Jej pierwotna wersja została stworzona w 2014 roku przez Google, a obecnie rozwijany jest przez Cloud Native Computing Foundation. Kubernetes (1) obsługuje narzędzia kontenerowe. Jest również wspierana przez większość chmur publicznych. Wielu dostawców oferuje także własne dystrybucje Kubernetes pod inną nazwą.
Wracając do kontenerów. Nazwą tą określa się we współczesnym programistycznym świecie nic innego jak jednostki oprogramowania, czyli kod aplikacji wraz z jego bibliotekami i zależnościami. Idea kontenerów polega na ich spakowaniu w uniwersalny sposób, tak jak ma to miejsce z kontenerami w transporcie, aby umożliwić uruchamianie w dowolnym miejscu - na komputerze biurkowym, w tradycyjnym środowisku IT lub w chmurze. Ponieważ kontenery i narzędzia do orkiestracji kontenerów są technologicznie neutralne, można budować aplikacje na dowolnej platformie, co ułatwia pracę, obniża koszty i w dużym stopniu przyspiesza wejście na rynek produktów.
Jest jeszcze jeden wyraźnie widoczny nurt w programowaniu w ostatnich latach. Jednostki programistyczne o dużych rozmiarach odchodzą do przeszłości. Dziś normą staje się dzielenie wielkich, monolitycznych baz kodu na mniejsze aplikacje, mikroserwisy. To zmniejsza częstotliwość błędów, czyniąc aplikacje bezpieczniejszymi w przypadku, gdy wydarzy się coś nieprzewidzianego. Minusem takiego rozwiązania jest wzrost trudności testowania, do którego potrzeba więcej zasobów. Dla zespołów mniejszych nadal bardziej sensowne wydaje się utrzymywanie obszernych monolitów.
Od prostych instrukcji po świat DevOps
React stworzony przez Meta (kiedyś Facebooka), Angular Google’a i Zuul Netflixa to platformy, których używa dziś niezliczona liczba programistów na świecie. Bez narzędzi, które te organizacje udostępniły za darmo dla wszystkich chętnych, wiele znanych dziś serwisów nie ujrzałoby w ogóle światła dziennego, gdyż napisanie tych aplikacji "od fundamentów" byłoby zbyt trudne, zbyt czasochłonne i nieopłacalne.
Jak wiadomo, w tworzeniu oprogramowania obowiązuje zasada - nie wymyślaj koła na nowo. Warto pamiętać, że prawdopodobnie wcześniej ktoś stanął przed tym samym problemem, przed którym teraz stoimy my. Duża część współczesnych fragmentów oprogramowania wykorzystuje gotowce i wzorce takie jak CQRS i Event Sourcing.
Jednocześnie nie jest niespodzianką, że powstają nowe języki programowania. Te przychodzą i odchodzą, by zostać zastąpione przez inne. Nikt już raczej nie koduje w Algolu czy Pascalu. Niektóre "stare" języki, takie jak C, wciąż żyją, ale to szczególne przypadki i dłuższe historie.
Języki programowania ewoluowały. Na początku były języki imperatywne i funkcyjne. Potem nastała era języków obiektowych. Teraz, jak się zauważa, są one wypierane przez języki, które są znacznie bardziej elastyczne, mieszając cechy języków imperatywnych, funkcyjnych i obiektowych. Ogólnie w historycznym ujęciu języki programowania stają się coraz bardziej niezależne od systemów, w których pracują odbiorcy końcowi, użytkownicy. Nowoczesne języki są wieloplatformowe. Dzięki rozwojowi DevOps, wybór języka staje się coraz mniej istotny. Kładzie się nacisk na coś innego.
Czym jest ów tajemniczy DevOps? Nazywa się tak metodykę zespolenia rozwoju i eksploatacji oraz zapewnienia jakości. Kładzie się w niej nacisk na ścisłą współpracę i komunikację profesjonalistów z zakresu utrzymania IT (administratorów) oraz specjalistów od rozwoju oprogramowania (programistów). Uwzględnia współzależność rozwoju i utrzymania IT. Skracać to ma czas wdrożenia funkcji w oprogramowaniu. Pojęcie DevOps zostało zaproponowane w 2009 przez Patricka Debois w trakcie dni DevOps w Gandawie.
Klasyczna infrastruktura na fizycznym serwerze jest wypierana przez dostawców chmury i platformy z nią związane. Mamy maszyny wirtualne jako usługę, bazy danych jako usługę i wiele innych elementów infrastrukturalnych jako usługę. Większość planowania w rozwiązaniach programowych przeniosła się na wysokopoziomowy projekt infrastruktury, ponieważ wiele można na jego podstawie zautomatyzować. Dodatkowo mamy kontenery i ich orkiestrację. Przejmuje ona złożoność, ponieważ możemy podzielić system na mniejsze i prostsze części. Kod aplikacji staje się bardziej niezależny od platformy. Złożoność nie znika, ale teraz rezyduje w infrastrukturze i operacjach. Programiści aplikacji coraz bardziej skupiają się na logice biznesowej. Inżynierowie DevOps zajmują się resztą.
Z desktopu do internetu
I tak mamy język WebAssembly, wydany w 2017 roku przez Mozillę, został przyjęty jako standard przez W3C i jest obecnie wspierany przez Mozillę, Microsoft, Google, Apple, Fastly, Intel i Red Hat. WebAssembly (skrót Wasm) to binarny format instrukcji dla maszyny wirtualnej opartej na stosie. Wasm jest zaprojektowany jako przenośny cel kompilacji dla języków programowania, umożliwiając wdrożenie w sieci dla aplikacji klienckich i serwerowych. Jest obsługiwany we wszystkich głównych przeglądarkach z obsługą ponad czterdziestu języków programowania jako cel kompilacji (2). Można uruchomić kod binarny Wasm (napisany w obsługiwanym języku) za pomocą JavaScript. Otwiera to szeroki wachlarz możliwości w pisaniu wysokowydajnych aplikacji internetowych.
WebAssembly jest, jak się to ujmuje, "celem kompilacji". Programiści nie piszą programu w WebAssembly bezpośrednio. Piszą w wybranym przez siebie języku programowania, który jest następnie kompilowany do kodu bajtowego WebAssembly. Kod bajtowy jest następnie uruchamiany po stronie klienta, zazwyczaj w przeglądarce internetowej, gdzie jest tłumaczony na kod maszynowy i wykonywany z dużą prędkością. Kod WebAssembly jest przeznaczony do szybszego ładowania, parsowania i wykonywania niż JavaScript. Ma działać szybciej. To jest jego główny sens.
Przez dwie dekady mieliśmy do dyspozycji tylko jeden język programowania dostępny do użycia natywnie w przeglądarce internetowej. Był to JavaScript. Powolna śmierć binarnych wtyczek firm trzecich wykluczyła inne języki, takie jak Java czy ActionScript z Flasha. Inne języki internetowe, takie jak CoffeeScript, są kompilowane jedynie do JavaScript. WebAssembly został zaprojektowany tak, by być celem kompilacji dla każdego języka, JavaScript jest tylko jednym z nich. Warto zaznaczyć, że aplikacje WebAssembly nie są przeznaczone do zastąpienia aplikacji JavaScript - przynajmniej jeszcze nie teraz. Zamiast tego należy myśleć o WebAssembly jako o towarzyszu JavaScriptu.
Za najlepiej wspierane przez Wasm uchodzą języki C, C++, Rust i Golang. Na konferencji PyCon 2022, gromadzącej programistów używających Pythona, ogłoszono powstanie PyScript dla WebAssembly. Do grupy wsparcia dołączyła również Java, GraalVM, Wasmer, JWebAssembly i TeaVM. Nic dziwnego, że popularność Wasm szybko rośnie.
Jak się zdaje, najbardziej rozwojowi platformy sprzyja integracja z szalenie ostatnio popularnym językiem Rust. Fundacja Rust powstała w 2020 roku przy wsparciu takich firm jak AWS, Google, Huawei, Microsoft i Mozilla. W ankiecie deweloperskiej Stack Overflow Rust jest najbardziej przez programistów kochanym językiem szósty rok z rzędu. Rust for WebAssembly (wasmpack) wykorzystuje język Rust do budowy szybkich aplikacji internetowych.
WebAssembly dobrze sprawdza się jako narzędzie do przenoszenia aplikacji desktopowej do środowiska WWW, co jest bardzo cenione przez deweloperów.
Nowe rozwiązania jeszcze się nie zadomowiły w programistycznym świecie, a Google już buduje kolejną generację aplikacji internetowych. Firma ogłosiła w maju 2022 r. powstanie funduszu Advanced Web Apps Fund, który ma objąć swoim zakresem wszystko, co "poprawia sieć jako platformę dla zaawansowanych aplikacji". Google przyznaje, że nie potrafi podać dokładnej definicji tego, czym są owe "zaawansowane aplikacje", ale ogólnie uważa je za strony internetowe, które mają interfejs podobny do aplikacji i znaczną funkcjonalność po stronie klienta. Jako przykład podaje się wdrożenie aplikacji webowej odpowiadającej znanemu programowi Photoshop (3).
Google czeka więc na nowe rozwiązania. Autorzy projektów, a także ci, którzy chcieliby nowe projekty wesprzeć, muszą korzystać z platformy Open Collective. Nie ma terminu składania wniosków, a Google zapowiedziało, że będzie oceniać propozycje na bieżąco.
Mirosław Usidus
