W tematach związanych z aplikacjami na ogół wszyscy skupiają się na warstwie programistycznej, w jaki sposób zostanie całość napisana, pomijając element architektury całości pod kątem dłuższej perspektywy czasowej oraz administracyjnej. W końcu Ffinalnie, wytworzony program musi zostać gdzieś uruchomiony. Do tego dochodzą pytania związane z tym, w jaki sposób oprogramowanie jest dostarczane na docelowe środowisko, jak przebiega proces testowania, czy mamy na bieżąco informacje na temat tego, jak platforma / nasz produkt działa. Niewątpliwie. mamy tu bardzoto rozbudowany ekosystem, w którym to jednak możemy znaleźć coraz więcej wartościowych narzędzi dostarczających wymierną wartość i minimalizujących popełniane błędy.
Cuda z chmury
Obecnie sporo elementów da się dodać w formule oprogramowania jako usługi. Potrzebujesz widzenia komputerowego? Najpewniej Amazon lub Google oferują to w swojej chmurze. Chcesz bramkę płatności? Wybierasz odpowiadającego ci operatora płatności, przechodzisz weryfikację i gotowe. Ten schemat powielany jest w wielu krokach, co pozwala szybciej tworzyć i dostarczać gotową aplikację. Niewątpliwie, podejście wszystkiego jako usługi jest elastyczne i kusi szybkością wdrożenia, jednak trzeba zawsze przekalkulować całość, czy rzeczywiście ta szybsza implementacja przełoży się w dalszej perspektywie na zyski z tego tytułu.
Z perspektywy tworzenia prototypowych rozwiązań to ciekawe podejście. Nic dziwnego, że rozwiązania typu no-code czy low-code cieszą się rosnącą popularnością, skoro osoby nietechniczne mogą z ich pomocą stworzyć pierwszą wersję aplikacji. Kiedy jednak chcemy tworzyć bardziej rozbudowane oprogramowanie, wówczas niezbędne jest zatrudnienie programisty czy zespołu, który i tak może sporo zyskać korzystają z obecnych dobrodziejstw.
Niewątpliwie, samo wykorzystanie chmury publicznej jest rozsądne, ponieważ pozwala ułatwić sporo elementów związanych z przygotowaniem infrastruktury. Na ogół za tą wygodą idą w parze wyższe koszty, jednak nie ma nic za darmo. Tu warto pamiętać o tym, że nawet w takim środowisku mamy mnóstwo opcji niezbędnych do ustawień, takich jak tworzenie kont użytkowników i ról technicznych, przypisywania im uprawnień, konfiguracji ustawień sieciowych, dobór odpowiednich serwisów dla naszego przypadku, weryfikacja zabezpieczeń. Cały element operacyjny w przypadku chmury zasługuje na co najmniej osobny artykuł.
Architektura na nowo
Poruszyliśmy już wątek chmury, który niektórzy zdają się przedstawiać jako rozwiązanie wszystkich problemów. Tymczasem trzeba podejść z dystansem do używanych komponentów. Na start zaczynamy od elementów związanych z analizą biznesową i systemową, dokładnego zrozumienia funkcjonalności oraz wartości, która aplikacja ma dostarczać. Tu niezwykle ważne pozostaje zrozumienie wymagań. Sztuka polega na spełnieniu założeń, a nie na wykonaniu kilka razy większej pracy niż ta realnie oczekiwana. Nie da się zresztą ukryć, że problem z nadmiernym rozbudowywaniem oprogramowania zdarza się i warto zawsze zadawać sobie pytania na poszczególnych etapach projektowania architektury: po co? Dlaczego? Czy to odpowiednie rozwiązanie?
Jednocześnie w przypadku większych systemów należy analizować możliwości późniejszej rozbudowy w zakresie nowych funkcji. Nie sposób zapomnieć o elemencie skalowania się z uwagi na rosnące zainteresowanie użytkowników. Tu niezwykle przydają się nowe rozwiązania, w których to infrastruktura jest zarządzana przez dostawcę, z kolei my możemy skalować samą aplikację przy wykorzystaniu różnych podejść, typu konteneryzacja lub tworzenie grup instancji opierających się o maszyny wirtualne. Warto spojrzeć, jakie technologie używane są w firmie, kiedy szukamy nowej pracy, aby dobrze trafić - wszystkie szczegóły znajdziemy w ofertach na portalu the:protocol.
Czy potrzebna jest wiedza, co dzieje się pod spodem?
Rynek przeżywa oblężenie rozwiązań zapewniających nam coraz więcej funkcji, które w teorii wymagają minimalną ilość programowania. Na start wypada zapoznać się z dokumentacją i forami dyskusyjnymi, na których można zweryfikować pięknie brzmiące zapowiedzi. Często okazuje się, że dane rozwiązanie nie może być użyte w aplikacji, ponieważ nie wspiera specyficznego przypadku, który musi być obsłużony przez aplikacje. Na pewno w obszarze wyboru usług należy kierować się spokojem i z dystansem czytać broszury sprzedażowe.
Warto zrozumieć także, w jaki sposób działają dane usługi czy dostarczana infrastruktura. Pozwala to lepiej poznać jej działanie, przygotować się na ewentualną migrację na inne rozwiązanie (unikanie vendor locka jest zalecane, o ile ma to sens) oraz zrozumieć potencjalne sytuacje, w których dane rozwiązanie może zadziałać niezgodnie z oczekiwaniem. Na szczęście firmy często publikują techniczne artykuły lub whitepapery, które pozwalają zapoznać się z wnętrznościami danego produktu. Zawsze przydatne jest zapoznanie się z profilem firmy, tak jak możemy to zrobić poszukując nowych wyzwań zawodowych na the:protocol.
Obserwowalność środowiska
Temat każdego dodatkowego elementu naszej platformy należy zacząć od podstawowego pytania: po co? W tym przypadku chodzi o zapewnienie kompleksowego monitoringu wszystkich istotnych procesów, jakie dzieją się na naszym środowisku. Na ogół mówimy tu o narzędziach, które mają działać nieprzerwanie cały czas, element pozwalający na szybkie sprawdzenie ich stanu jest nieoceniony.
Monitoring to obowiązkowa rzecz przy dowolnej platformie danych. Pozwala na bieżąco sprawdzać działające procesy i reagować od razu w przypadku wystąpienia jakichkolwiek problemów i nawet zapobiegać poważnym kłopotom, np. utracie danych czy nieprzetworzeniu danych. Dodanie alertów dla występowania zbyt dużej liczby błędów lub ostrzeżeń pozwala skutecznie usprawnić sprawdzanie działania platformy i pozwala wejść na kolejny poziom przeciwdziałania jakimkolwiek dalszym problemom.
Testowanie i wdrażanie
Pipeliny CICD odpowiadają za automatyzację uruchamiania testów, budowania aplikacji oraz wdrażania ich na docelowo środowisko to kluczowy element pracy. Pozwala on zdecydowanie poprawić stosunki między działem deweloperskim, a administracyjnym; nie ma mowy o wprowadzaniu zmian, o których ktoś zapomni za kilka dni; całość odbywa się w ściśle określonych scenariuszach.
Obecność testerów w zespole nie jest aktualnie dla nikogo zaskoczeniem. Dodanie natomiast elementu automatyzacji pozwala być pewnym, że każda zmiana przed automatycznym wdrożeniem zostanie przetestowana przez system. Takie ograniczenia mogą brzmieć jak strata czasu, ale w praktyce pozwalają uniknąć kosztownych problemów.
Dobrodziejstwa automatyzacji
Obecnie mamy szeroki wachlarz możliwości w zakresie projektowania, wdrażania i utrzymania aplikacji, niezależnie od skali o jakiej mówimy. Co ciekawsze, sporo rozwiązań jest dostępnych bezpłatnie (do konkretnego poziomu lub z ograniczonym zestawem funkcji), co tym bardziej ułatwia testowanie różnych rozwiązań oraz ich implementację w projekcie.
Zdecydowanie obecny trend związany z automatyzacją wszystkich kroków związanych z testowaniem i wdrażaniem to znakomita rzecz. Zapewnia powtarzalność, całość jest prosta w obsłudze, a czas dodawania nowej wersji aplikacji jest zminimalizowany do minimum. Jednocześnie brak manualnych kroków pozwala uniknąć drobnych pomyłek, które mogłyby wywołać błędy na środowisku produkcyjnym. Dodając do tego tworzenie infrastruktury jako kod z użyciem narzędzi pokroju Terraform czy AWS CDK, otrzymujemy realnie zwinne metodyki wytwarzania kodu. Do tego to znacznie uprzyjemnia pracę, w której mamy dokładną wiedzę na temat obecnego stanu oraz w jaki sposób chcemy wprowadzać zmiany na poszczególnych środowiskach.
Bogactwo dostępnych usług wymusza jednak na etapie projektowania dokładne przeanalizowanie potrzeb i dobór odpowiednich rozwiązań, które nie będą na wyrost, nie będą zbyt kosztowne i przełożą się na konkretne efekty. Kluczowe pozostaje tu doświadczenie w tworzeniu architektury oraz używaniu różnych usług. Cóż, środowisko IT jest na tyle dynamiczne, że cały czas trzeba testować i sprawdzać różne warianty.
