DevSecOps dla aplikacji chmurowych

Zmiana w podejściu do wytwarzania oprogramowania i przejście z kaskadowej metodologii (ang. waterfall model) do trybu zwinnego (ang. agile) spowodowały, że kwestia bezpieczeństwa tworzonych aplikacji stała się jeszcze ważniejsza niż dotychczas. Zamiast pojawiać się na samym końcu liniowego modelu waterfall, bezpieczeństwo jest obecne na każdym etapie rozwoju w metodologii zwinnej. W międzyczasie, żeby jeszcze bardziej usprawnić prace nad oprogramowaniem, pojawił się DevOps, czyli kultura stanowiąca połączenie Development and Operations – rozwoju i utrzymania. Dzięki DevOps zespół przyspiesza tworzenie i zwiększa jakość aplikacji, jednak tradycyjne podejście do kwestii bezpieczeństwa – czyli prace realizowane przez odrębny dział – często nie jest w stanie nadążyć za tempem całego procesu. W ten sposób, odpowiadając na pilne potrzeby oraz w zgodzie z Cloud Culture, pojawił się termin DevSecOps.

 

 

Czym tak właściwie jest DevSecOps?

 

Połączenie ze sobą działów dotychczas odpowiedzialnych za różne rzeczy w projekcie – rozwój oraz utrzymanie – działa świetnie, jeśli chodzi o zwiększenie wydajności i prędkości, z jaką wytwarza się oprogramowanie. Jak wspomnieliśmy we wstępie, w mieszance DevOps zabrakło jednak odpowiedzi na pytanie: co z bezpieczeństwem tak szybko tworzonego kodu? Jak łatwo można się domyślić, do DevOps (Development and Operations) dodano kolejny człon – „Sec”, czyli Security (pl. bezpieczeństwo). Dzięki podejściu DevSecOps bezpieczeństwo jest wpisane w samo centrum od pierwszych etapów istnienia danego rozwiązania – dosłownie i w przenośni. Jest to ewolucja dobrze działającego modelu. Dzięki niej wyniki zespołu projektowego są jeszcze lepsze i bardziej efektywne, zwłaszcza w przypadku rozwiązań chmurowych, gdzie integracja procesów jest najłatwiejsza.

 

 

DevSecOps vs DevOps

 

Stosunkowo nowy DevSecOps jest coraz lepiej znanym w środowisku IT terminem, ale jak bardzo różni się od funkcjonującego od kilkunastu lat DevOps? W paragrafach poniżej dokładniej odpowiadamy na to pytanie, porównując obie metodyki.

Samo wykorzystywanie DevOps w projektach znacznie przyspieszyło i usprawniło rozwój oprogramowania, ponieważ połączyło ze sobą dwa do tej pory odrębne działy, które pracują w zupełnie inny sposób – Development, czyli rozwój, oraz Operations, czyli dział operacji IT. Z zasady osoby odpowiedzialne za wytwarzanie oprogramowania działają szybko, powinny móc sprawnie i w krótkim czasie odpowiedzieć na zadania i zmiany, które czasem pojawiają się niespodziewanie, na przykład na prośbę klienta. Z kolei operacje IT utrzymują istniejące aplikacje i programy, oczekuje się od nich stabilności, dużej wydajności i unikania błędów – a ryzyko wystąpienia bugów pojawia się przy każdej kolejnej szybkiej zmianie, którą implementuje dział Development. Te dwa sprzeczne podejścia powodują, że w projektach często powstaje dług technologiczny, który bardzo ciężko w późniejszym czasie zniwelować (więcej szczegółów w artykule: „Historia metodyki DevOps”).

Ten problem rozwiązuje wdrożenie metodyki DevOps. Dwa działy pracujące w inny sposób bardzo blisko współpracują i są w stałym kontakcie, mają wspólne procedury i są w stanie o wiele szybciej identyfikować i usuwać pojawiające się problemy; warto dodać, że najczęściej odpowiedzialni za ten proces są inżynierowie posiadający stanowisko o nazwie DevOps Engineer, lub po prostu DevOps. Automatyzacja przebiega znacznie sprawniej, ponieważ zespół używa wspólnych narzędzi i razem działa tam, gdzie do tej pory prace przebiegały całkiem osobno.

Wiele iteracji oraz wypuszczanie kolejnych porcji kodu w krótkim czasie jest wydajne i efektywne, jednak jest jeszcze jeden dział, bez którego oprogramowanie tak naprawdę nie może istnieć – dział bezpieczeństwa. W modelu DevOps nadal działa on w pewnym oderwaniu od reszty zespołu, zwykle na początku i na końcu projektu, i nawet jeśli przedstawiciel działu Security pojawia się na spotkaniach i bezpośrednio współpracuje z programistami, to zabezpieczenia nie są projektowane i wdrażane na bieżąco, tylko po zakończeniu kolejnych etapów prac – to powoduje, że odkryte luki czy bugi są naprawiane wolniej (w późniejszym czasie) i jest to bardziej kosztowny proces. Biorąc pod uwagę świetne wyniki po połączeniu dwóch działów – dlaczego nie zrobić tego z jeszcze jednym? W ten sposób, po powstaniu DevSecOps, bezpieczeństwo zostało wpisane na stałe we wszystkie etapy życia projektu – od samego pomysłu do dostarczenia gotowego produktu. Dzięki temu w każdym momencie security jest obecne i jest odpowiedzialnością wspólną, a nie tylko dedykowanego zespołu – problemy są rozwiązywane zaraz po tym, jak się pojawiają, co zmniejsza koszty i przyspiesza ogólne prace. Kod jest analizowany pod względem bezpieczeństwa przez cały czas i może być poprawiony od razu, na wczesnym etapie powstania ewentualnej luki.

 

 

Jakie są dobre praktyki DevSecOps?

 

Należy pamiętać, że człon „Sec” zostaje dodane do istniejącego pipeline’u DevOps, dlatego zasady zapewnienia bezpieczeństwa nie mogą być takie same, jak do tej pory – zmiana jest konieczna, bo przecież stąd powstała metodyka DevSecOps, że działy Security nie nadążały za pracami nad oprogramowaniem w starym modelu, zwłaszcza w chmurze. Wdrażanie i trening DevSecOps powinny odbywać się w zgodzie z istniejącymi już procesami i pipeline CI/CD (ang. Continuous Improvement/Continuous Deployment) oraz wykorzystywanymi narzędziami programistów, a nie na odwrót. Przynosi to świetne rezultaty, zwłaszcza jeśli postawimy na automatyzację – testy bezpieczeństwa są wykonywane jeszcze sprawniej, ponieważ duża ich część jest powtarzalna i można je ubrać w proces, także z wykorzystaniem inteligentnej automatyzacji.

 

Bardzo bliska współpraca pomiędzy działami niesie za sobą wielkie korzyści także w temacie edukacji. Teza, że w modelu DevSeOps bezpieczeństwo to odpowiedzialność wspólna, pozwala na trening wszystkich zaangażowanych, aby posiadali wiedzę wystarczającą do podejmowania decyzji zgodnie z wcześniej ustalonymi zasadami Security i tymi samymi standardami. Testy i ich wyniki powinny być przeprowadzane w istniejącym środowisku DevOps – być z nim zintegrowane i, tak jak wspomnieliśmy, zautomatyzowane w jak największym stopniu oraz przeprowadzane na bieżąco. Wymaga to zmiany nie tylko w sposobach użycia narzędzi, ale także w podejściu programistów i ekspertów do spraw bezpieczeństwa do ich własnej pracy. Jest to wyzwanie same w sobie dla organizacji wdrażającej DevSecOps, jednak jest bardzo wartościowe.

 

 

Narzędzia DevSecOps

 

Idąc za tropem zestawienia SANS Institute, instytutu wydającego certyfikaty bezpieczeństwa i oferującego kursy Cloud cybersecurity w USA, narzędzia DevSecOps powinny być jak najprostsze w integracji z istniejącymi narzędziami CI/CD oraz mieć opcję jak największej możliwości automatyzacji. Aby zapewnić najwyższy poziom bezpieczeństwa tworzonych aplikacji, w trakcie rozwoju oprogramowania dobrze zwrócić się do znanych rodzajów narzędzi testowania poziomu bezpieczeństwa i wiedzieć, kiedy ich używać: SAST (statyczne skanery aplikacji, ang. Static Application Security Testing), SCA (skanery analizy składu oprogramowania, ang. Software Composition Analysis) i DAST (dynamiczne skanery aplikacji, ang. Dynamic Application Security Testing). Prócz tego, istnieją narzędzia do śledzenia i zarządzania zgłoszeniami i konfiguracją, do komunikacji, weryfikacji środowiska oraz narzędzia używane już po wdrożeniu aplikacji, takie jak RASP (ochrona własna aplikacji w czasie pracy, ang. Runtime Application Self-Protection), które chronią aplikacje w czasie rzeczywistym ich działania. Wdrożenie rozwiązań DevSecOps zdecydowanie ułatwi także przetwarzanie bezserwerowe, czyli Serverless.

 

 

Jak zostać DevSecOps?

 

Przede wszystkim trzeba zdać sobie sprawę, że bycie DevSecOps Engineer wiąże się z dużą wszechstronnością oraz nieustannym rozwojem, żeby być w stanie nadążyć za zmianami we wszystkich obszarach – programowania, utrzymania oraz bezpieczeństwa. Praca w tym charakterze jest zwykle związana z częstymi zmianami projektów, więc zdarza się, że pomiędzy jednym a drugim konieczna jest nauka innych narzędzi czy języków i wykorzystywanych technologii. Znajomość kodowania pozwoli DevSecOpsowi na łatwiejsze komunikowanie się z zespołem oraz wykonywanie niektórych czynności samodzielnie, tak samo obycie w środowiskach chmurowych, np. AWS, oraz wiedza o praktykach ciągłej integracji i ciągłego dostarczania (CI/CD). DevSecOps jest łącznikiem pomiędzy deweloperami, ekspertami bezpieczeństwa oraz zespołem operacyjnym, powinien więc poruszać się swobodnie i być w stanie monitorować, komunikować oraz koordynować działania między nimi.

 

 

Gdzie uczyć się na DevSecOps?

 

Pierwszym, najbardziej oczywistym krokiem są studia – DevSecOps wiąże się z pracą w obszarach cyberbezpieczeństwa, a to wymaga kwalifikacji i sporej wiedzy technicznej, dlatego pracodawcy zwykle skupiają się na kandydatach z taką historią edukacji, jak informatyka czy cyberbezpieczeństwo. Samej osobie zainteresowanej takie kierunki na pewno pomogą w dalszej nauce potrzebnej do zostania DevSecOps, dostarczając już podstawy i najważniejszą wiedzę. Kursy także są w cenie – najbardziej pożądane i efektywne będą oficjalne certyfikaty.

 

Trzeba pamiętać, że znaczna większość DevSecOpsów nie zaczyna pracy od razu w tej roli. Zwykle potrzebne jest doświadczenie na różnych stanowiskach, zwłaszcza że sama rola DevSecOps wymaga znajomości innych obszarów, niż tylko samo cyberbezpiecześntwo – wspomnieliśmy już programowanie, pisanie kodu, ale także mocne kompetencje miękkie (komunikacja, praca z zespołem na różnych płaszczyznach) czy umiejętności oceny ryzyka i modelowania zagrożeń. Te wszystkie wymagania określają dojrzałego i doświadczonego pracownika, gotowego do przejęcia roli DevSecOps.

 

 

Kiedy firma potrzebuje DevSecOps?

 

Rozwiązania chmurowe i przyspieszenie prac deweloperskich przez DevOps stworzyły już lukę pomiędzy świetnymi wynikami zespołów a pracami ekspertów bezpieczeństwa, które są przeprowadzane późno i generują większe koszty. Tak naprawdę, jeśli chcemy nadążyć za obecnym tempem rozwoju i zniwelować wspomniane problemy oraz ograniczyć cyberzagrożenia, powinniśmy zacząć przejście do modelu DevSecOps jak najszybciej. Dzięki niemu firma jest zdecydowanie bardziej chroniona a oprogramowanie szybciej dostarczane i bezpieczne – koniec końców jest również tańsze, ponieważ Security działa na każdym etapie jego rozwoju, a nie z opóźnieniem. Możemy śmiało stwierdzić, że w dzisiejszych czasach DevSecOps jest potrzebne każdemu, kto chce nadążyć za szybko zmieniającymi się realiami i wykorzystywać w pełni potencjał swojej organizacji.

Liderzy biznesu na całym świecie zastępują starsze technologie on-premise elastyczną, skalowalną i ekonomiczną mocą obliczeniową w Chmurze. Od obniżenia kosztów IT po przyspieszenie innowacji — istnieje wiele ważnych powodów, dla których warto rozpocząć proces migracji. Tego typu przejście nie będzie jednak łatwe bez dobrze opracowanego planu i dostępu do eksperckiej wiedzy. Dziś uchylamy rąbka tajemnicy, jak migrować do Chmury we właściwy sposób.

 

 

Kiedy warto przenieść przedsiębiorstwo do Chmury?

 

Cloud migration, czyli migracja do Chmury, to nie lada przedsięwzięcie, zwłaszcza dla małych i średnich firm. Oto kilka sygnałów świadczących o tym, że nadszedł na to właściwy moment.

 

Przestarzała technologia

Migracja do Chmury jest znacznie bardziej opłacalną opcją dla firm niż inwestowanie w drogi sprzęt IT. Rozwiązania cloudowe umożliwiają również dostęp do najnowocześniejszych technologii.

 

Technologia, która nie nadąża za rozwojem firmy

Nadążanie za wymaganiami rozwijającej się firmy nie jest łatwe. Częstym problemem jest m.in. radzenie sobie z brakiem przestrzeni dyskowej w urządzeniach lokalnych. Migracja danych do Chmury, która zapewnia możliwość wydajnego skalowania, to sposób na uniknięcie tego wyzwania.

 

Brak planu odzyskiwania po awarii (tzw. Disaster Recovery Plan)

Przetwarzanie w Chmurze umożliwia przesyłanie wszystkich najważniejszych danych na serwery zewnętrzne. W razie ich utraty spowodowanej nieumyślnym usunięciem jakichś elementów lub incydentem związanym z cyberbezpieczeństwem będą więc one łatwo dostępne.

 

Wysokie koszty IT

Zarządzanie lokalną infrastrukturą IT małych i średnich firm jest bardzo drogie. Wraz z biegiem czasu kończy się również okres gwarancji na serwery. Z uwagi na kwestie związane z cyberbezpieczeństwem, konieczne jest jej przedłużenie, co także wiąże się z dodatkowymi wydatkami. Współpraca z dostawcą Chmury pozwoli na obniżenie kosztów związanych z utrzymywaniem infrastruktury IT.

 

Personel pracujący zdalnie

Migracja do Chmury umożliwia pracownikom swobodne korzystanie z opcji home office, co korzystnie wpływa na morale zespołu i pozwala zachować work-life balance.

 

 

Dlaczego warto przenieść firmę do Chmury?

 

Migracja danych do Chmury dostarcza licznych korzyści związanych m.in. z RPA/RPAaaS czy ochroną środowiska. Ich zrozumienie jest kluczowe do tego, by podjąć świadomą decyzję odnośnie Cloud migration. Poniżej wylistowaliśmy najważniejsze z nich.

 

Efektywność kosztowa i skalowalność

Chmura pomaga poprawić wyniki finansowe firmy m.in. poprzez możliwość skalowania bez konieczności inwestowania w drogą infrastrukturę lokalną. Co więcej, wraz z biegiem użytkowania korzyści biznesowe będą ciągle rosnąć.

 

Wydajność i niezawodność

Przestoje w pracy mogą powodować poważne problemy i generować znaczące koszty. Współpraca z dowolnym z głównych dostawców usług w Chmurze jest więc o wiele rozsądniejsza niż poleganie wyłącznie na własnych serwerach i infrastrukturze IT.

 

Bezpieczeństwo

Podjęcie dodatkowych kroków w celu ochrony przed cyberprzestępcami ma kluczowe znaczenie dla firm. Aby zapewnić bezpieczeństwo informacji, dane w Chmurze są całodobowo monitorowane, szyfrowane i wielokrotnie archiwizowane w różnych centrach danych, zaś aplikacje – na bieżąco aktualizowane.

 

 

Jakie są najczęstsze problemy z przeniesieniem firmy do Chmury?

 

Oprócz korzyści, migracja do Chmury może się jednak wiązać z szeregiem wyzwań. Są one najczęściej wypadkową braku strategii i planu działania. Stąpanie po omacku może znacznie wydłużyć cały proces i negatywnie wpłynąć na optymalizację kosztów. Dlatego też kluczowe jest znalezienie odpowiedniego partnera/dostawcy usług IT.

 

 

Jak wybrać partnera w przeniesieniu firmy do Chmury?

 

Przed wyborem firmy zewnętrznej i podjęciem z nią współpracy, warto zwrócić uwagę na aspekty takie jak:

 

  • bogate doświadczenie w zakresie migracji do Chmur prywatnych, publicznych i środowisk hybrydowych,
  • stosowanie tzw. best practices,
  • know-how w zakresie zmian kulturowych i ich wpływu na użytkowników końcowych,
  • dostępność przejrzystych raportów w czasie rzeczywistym dotyczących postępów migracji,
  • współpraca z wiodącymi w branży dostawcami narzędzi do migracji,
  • elastyczność w zakresie nearshore i offshore delivery,
  • dostarczenie proof-of-concept, który uzasadni w jaki sposób nowe technologie dopasują się do obecnych i przyszłych celów biznesowych oraz pozwoli sprawdzić, czy można wykorzystać istniejące zasoby, aby zmaksymalizować zwrot z inwestycji.

 

 

Strategie migracji do Chmury

 

Gartner opisał pięć modeli migracji do Chmury, znanych pod nazwą „5R” (Rehost, Refactor, Revise, Rebuild, Replace). Poniżej ich krótka prezentacja.

 

Rehosting, czyli przenieś i korzystaj

Rehosting to inaczej model Infrastructure-as-a-Service (IaaS). Polega na przeniesieniu istniejących baz danych i aplikacji na serwery w Chmurze. Jest to łatwe do wykonania i dlatego też odpowiednie dla organizacji mniej zaznajomionych ze środowiskami chmurowymi. Będzie to również dobra opcja w przypadkach, w których trudno jest zmodyfikować kod, a konieczne jest zachowanie aplikacji w nienaruszonym stanie.

 

Refactoring, czyli przeprojektuj i korzystaj

Refactoring polega na dostrajaniu i optymalizowaniu aplikacji pod kątem Chmury. W tym przypadku stosowany jest model Platform-as-a-Service (PaaS). Podstawowa architektura aplikacji pozostaje wówczas niezmieniona, ale wprowadzane są poprawki, aby umożliwić lepsze wykorzystanie narzędzi opartych na Chmurze.

 

Revise, czyli ulepsz

Strategia „Revise” przekłada się z kolei na znaczące zmiany w architekturze oraz kodzie. Mają one na celu umożliwienie aplikacjom pełnego dostępu do usług cloudowych. Podejście to wymaga rozbudowanego planowania i zaawansowanej wiedzy.

 

Rebuild, czyli przebuduj i zyskaj

Metodologia “Rebuild” całkowicie odrzuca zaś istniejącą bazę kodu i zastępuje ją nową. Proces ten zajmuje dużo czasu i jest brany pod uwagę tylko wtedy, gdy firmy uznają, że ich istniejące rozwiązania nie spełniają bieżących potrzeb biznesowych.

 

Replace, czyli zastąp, zamiast przenosić

Wreszcie, w strategii „Replace”, jak sama nazwa wskazuje, wszystkie elementy starych systemów zastępowane są nowymi. Jedyną rzeczą, która jest przenoszona w nienaruszonej formie są dane. Firma nie tworzy jednak w tym przypadku samodzielnie aplikacji natywnej, lecz korzysta z gotowego rozwiązania zewnętrznego dostawcy.

 

 

Migracja do Chmury… Google? Jak migrować do Chmury – krok po kroku

 

Sam proces migracji powinien zaś składać się z czterech etapów: planowania, uzasadniania biznesowego, realizacji i bieżącego utrzymania. Innymi słowy, należy m.in.:

 

  • określić, jakim celom służyć będzie środowisko chmurowe,
  • przeprowadzić analizę czynników, które będą kluczowe dla migracji (jak np. krytyczne dane aplikacji),
  • ustalić, jakie narzędzia będą potrzebne,
  • zapoznać się z odpowiednimi usługami oferowanymi przez dostawców Chmury oraz ich kosztami,
  • przygotować listę oczekiwanych korzyści,
  • obliczyć TCO dla każdej aplikacji, która ma zostać przeniesiona do Chmury,
  • oszacować przyszłe wydatki,
  • współpracować z dostawcami Chmury, aby poznać opcje oszczędności kosztów dla proponowanej opcji wdrożenia,
  • przeprowadzić migrację z minimalnymi zakłóceniami codziennej pracy, przy najniższych kosztach i w jak najkrótszym czasie,
  • zsynchronizować zmiany wprowadzane w danych źródłowych podczas trwania migracji,
  • ocenić bezpieczeństwo danych w spoczynku,
  • monitorować dane w czasie rzeczywistym oraz na bieżąco przeprowadzać testy wydajności i dostępności.

Wcale jeszcze nie tak dawno debatowano czy biznes w ogóle może i powinien korzystać z zasobów chmury publicznej. Jednak obecnie tego rodzaju dyskusje wydają się należeć już do przeszłości. Dzisiaj, zwłaszcza po doświadczeniach związanych z pierwszymi miesiącami pandemii Covid-19, coraz więcej organizacji przyjmuje raczej podejście cloud first, w ramach którego chmura publiczna jest domyślnym środowiskiem dla nowych projektów IT, a żeby uruchomić coś w lokalnym centrum danych potrzeba naprawdę mocnych argumentów. Do chmury przenoszone są systemy ERP, CRM oraz rozwiązania RPA. Za chmurą przemawiają także kwestie związane ze zrównoważonym rozwojem. Kultura chmury zdominowała biznes. To jednak nie wszystko. Coraz częściej uznaje się, że jedna chmura to za mało. Dlatego ze wszystkich stron słychać o multi cloud.

 

 

Czym jest multi cloud?

 

Multi cloud to strategia polegająca na wykorzystywaniu dwóch lub większej liczby platform chmury obliczeniowej do dostarczania usług IT klientom wewnątrz i na zewnątrz organizacji. Oferty cloud poszczególnych dostawców różnią się pod wieloma względami na tyle, że dzięki multi cloud można tworzyć zróżnicowane rozwiązania cloud doskonale dopasowane do unikalnych potrzeb. Podejście multi cloud przekłada się na większą elastyczność, daje lepszą kontrolę kosztów i otwiera nowe możliwości technologiczne. Co niezwykle ważne, nie prowadzi jednocześnie do uzależnienia od jednego dostawcy, ponieważ obciążenia można swobodnie, zgodnie ze zmieniającymi potrzebami przenosić od jednego dostawcy na infrastrukturę drugiego.

Ten model może dotyczyć nie tylko samej mocy obliczeniowej, ale także pamięci masowej, usług SaaS (Software as a Service), PaaS (Platform as a Service) oraz IaaS (Infrastructure as a Service). Dzisiaj właściwie wszystko może być usługą, nawet rozwiązania RPA. Przy tym powstające w wyniku realizacji strategii multi cloud hybrydowe środowiska IT składają się nie tylko z wielu chmur publicznych, ale także chmur prywatnych, tradycyjnej infrastruktury lokalnej oraz systemów działających na brzegu sieci. Rozwiązania multi cloud zwykle budowane są w oparciu o natywne technologie chmurowe open-source. Niemalże standardem w tym obszarze stała się platforma orkiestracji kontenerów Kubernetes.

 

 

Jakie są główne różnie między multi cloud a hybrid cloud?

 

Praktycznie, żadna organizacja nie polega w 100% na chmurze publicznej. Główny powodem są kwestie związane z regulacjami prawnymi, kontrolą nad danymi, ochroną danych wrażliwych albo własności intelektualnej, czasem wewnętrzne kwestie finansowe czy podatkowe. Dlatego większość współczesnych środowisk IT to mieszkanka chmur publicznych i prywatnych, infrastruktury w lokalnym centrum danych i działającej na brzegu sieci, czasem zasobów kolokowanych – wszystko to tworzy właśnie jedną hybrydową chmurę firmowych zasobów.

Nie każda chmura hybrydowa musi uwzględniać podejście multi cloud. Organizacja może w ramach swojej hybrydy wykorzystywać usługi tylko jednego dostawcy chmury publicznej. Może jednak równie dobrze wykorzystywać usługi wielu dostawców – w takim wypadku powiedzielibyśmy o hybrydowej chmurze multi cloud.

Z drugiej strony czy podejście multi cloud zakłada hybrydyzację? Teoretycznie nie, ale w praktyce – jak zostało to napisane wcześniej naprawdę niewiele organizacji opiera się w 100% na chmurze publicznej – jeśli realizowana jest strategii multi cloud, z dużym prawdopodobieństwem możemy mówić o hybrydzie.

 

 

Czy warto implementować w przedsiębiorstwie

 

Jeśli firma obawia się uzależnienia od jednego dostawcy usług cloud i potrzebuje dużej elastyczności a zarazem musi szybko reagować na zmieniającą się sytuację, wówczas strategia multi cloud może być wartością. Podobnie jeśli firma nie może pozwolić sobie nawet na minimalne przestoje, wówczas strategia multi cloud może okazać się najlepszym wyborem. Choć dostawcy cloud oferują wysoki poziom dostępności i bezpieczeństwa, nie można zupełnie wykluczyć „czarnego łabędzia”, który doprowadzi do katastrofalnej awarii u jednego z nich. Chcąc ograniczyć to ryzyko warto zaimplementować strategie multi cloud.

Multi cloud można także potraktować jako proaktywne podejście do kwestii shadow IT, czyli korzystania przez pracowników i działy biznesowe z usług cloud w niekontrolowany sposób, bez wiedzy IT i czasem z pogwałceniem firmowych polityk bezpieczeństwa. Wybierając multi cloud można się przed tym zabezpieczyć, udostępniając użytkownikom z góry więcej dostępnych opcji w chmurze.

 

 

Największe zalety podejścia multi cloud

 

O korzyściach płynących ze strategii multi cloud wspomnieliśmy już wcześniej: uniezależnienie od jednego dostawcy, większą elastyczność i responsywność oraz kontrolę kosztów, a także dostęp do szerszego wachlarza opcji technologicznych – oferty nawet największych dostawców nie pokrywają się w pełni. Wszystko to przekłada się na lepszy zwrot z inwestycji w usługi chmurowe. Muli cloud daje przedsiębiorstwom dodatkowe możliwości w zakresie maksymalizacji wartości oferowanej przez chmurę.

To jednak z pewnością nie wszystkie zalety, o których warto wspomnieć. W zależności od specyficznej sytuacji organizacji pośród korzyści należałoby wymienić także zaawansowane możliwości równoczesnego skalowania u kilku dostawców, mniejsze opóźnienia, dzięki możliwości wyboru konkretnych ośrodków różnych dostawców, które zapewniają najlepsze parametry pod tym względem, a także większy wybór w kontekście regulacji prawnych czy branżowych. Multi cloud oferuje także wyższy poziom bezpieczeństwa. Zmniejsza bowiem ryzyko skutecznych ataków DDoS (Distributed Denial of Service).

 

 

Największe wady podejścia multi cloud

 

Jednak tak jak nie ma darmowych lunchów, korzyści oferowane przez mutli cloud mają swoją cenę. Składają się na nią wzrost skomplikowania całego hybrydowego środowiska firmowego i wyższy poziom złożoności zarządzania nim. Nie ma standaryzacji w tym obszarze. Każdy dostawca cloud oferuje swoje własne narzędzia a uniwersalne platformy unifikują oferowane możliwości tylko w pewnym zakresie. Z tym wiąże się kwestia kadr. Wejście w nową chmurę wymaga poznania jej specyfiki – wymaga to wysiłku i czasu. Na rynku brakuje specjalistów, którzy są ekspertami multi cloud. Podobnie jest zresztą z bezpieczeństwem. Do tego trzeba dodać wysiłek związany z kontrolą kosztów. Chociaż można je kontrolować, to porównywania poszczególnych cenników i sposobów rozliczania usług przez różnych dostawców nie jest łatwe.

 

 

Jak powinna wyglądać architektura multi cloud?

 

Pomimo trudności i wyzwań korzyści oferowane przez multi cloud przeważają. Pytanie brzmi zatem raczej nie czy, ale jak wdrażać. Kluczowym zagadnieniem będzie ograniczenie potencjalnych problemów poprzez określenie najważniejszych celów biznesowych, jakie chcemy dzięki multi cloud osiągnąć. Optymalna architektura, to taka, która będzie dostosowana do specyficznych potrzeb i wymagań technicznych organizacji.

Dobór poszczególnych elementów, dostawców i usług należy poprzedzić dokładnym rozpoznaniem rynku, w wielu aspektach, m.in. zakresu oferty, bezpieczeństwa, zgodności z regulacjami, możliwości technicznych, kwestii związanych z zarządzaniem. Warto wziąć pod uwagę także możliwości w zakresie multi cloud oferowane przez kluczowe systemy i aplikacje posiadane w firmie.

 

 

Co jest istotne w planowaniu architektury Multi-Cloud?

 

Kluczem do maksymalizowania korzyści z podejścia multi cloud będzie minimalizowanie wysiłku wkładanego w zarządzanie. Konieczne jest maksymalne scentralizowanie zarządzania z poziomu jednej platformy. Im więcej zadań można będzie wykonać z poziomu jednego ekranu, tym lepiej. Istotna jest także integracja logowania i raportowania, zwłaszcza w obszarze bezpieczeństwa. Wybór platformy, która pozwoli na monitorowanie i zarządzanie zasobami w skali całego środowiska – nie tylko multi cloud, ale także hybrydowego – jest zatem kluczowy.

 

 

Bezpieczeństwo multi cloud

 

Na koniec warto wrócić do bezpieczeństwa, jednego z kluczowych zagadnień związanych ze strategią multi cloud. Jakie są najlepsze praktyki w tym zakresie? Odpowiednie podejście w tym obszarze to fundament skutecznej i zapewniającej maksymalizację korzyści strategii multi cloud. Podobnie jak w przypadku wyboru tylko jednej chmury, zasadnicze jest zrozumienie modelu współdzielonej odpowiedzialności, w ramach którego za pewne elementy odpowiada dostawca, a za inne – sam klient. W przypadku multi cloud dodatkową trudnością będzie to, że poszczególni dostawcy mogą różnie dzielić się odpowiedzialnością z klientami.

Mając to na uwadze, trzeba dążyć do zapewnienia spójności w skali całego środowiska. Konieczne jest zatem wprowadzenie tych samych reguł i polityk bezpieczeństwa we wszystkich środowiskach składających się na multi cloud.

Wreszcie, wszelkie działania w tym zakresie należy w jak największym stopniu automatyzować. Z jednej strony uwalniamy ludzi od dużej ilości powtarzalnych, rutynowych zadań, a z drugiej minimalizujemy ryzyko wystąpienia błędów.

O potencjale drzemiącym w technologii Cloud Native, w szczególności w zakresie implementacjioutsourcingu rozwiązań RPA, przekonała się niejedna duża organizacja, której zależało na tym, by uniknąć uzależnienia od jednego dostawcy.  

Czy jednak optymalizacja w zakresie rozwiązań prywatnych, publicznych i on-premise pozwoli na stworzenie prawdziwego i funkcjonalnego „Hybrid Cloud enterprise”, w którym kwestie kosztów, prędkości i bezpieczeństwa są dopasowane do unikalnych potrzeb danego biznesu? Oto jest pytanie! Próbę odpowiedzi podjęliśmy poniżej.

 

 

Cloud + hybrid, czyli Hybrid Cloud (chmura hybrydowa) – podstawowe informacje

 

Na początek kilka kluczowych informacji, tytułem przypomnienia. W przypadku technologii Cloud Computing, aplikacje i dane są hostowane na zdalnych serwerach w różnych data centers. Te ostatnie nie mają zwykle nic wspólnego z lokalizacją użytkowników, których obsługują.

 

Idąc za tym, Chmura publiczna to usługa, z której korzysta wielu klientów, nie wchodząc ze sobą w żadne interakcje. Przypomina to pracę banku, w którym konto ma wiele osób nieczerpiących nawzajem ze swoich funduszy. Analogicznie rzecz biorąc, Chmura prywatna jest usługą przeznaczoną dla pojedynczego klienta.

 

Istnieje jednak trzecia, hybrydowa opcja. Odnosi się ona do mieszanego środowiska przetwarzania i przechowywania danych w ramach technologii Cloud Computing. Jest ona połączeniem infrastruktury lokalnej (on-premise) z usługami prywatnych oraz publicznych dostawców Chmury, takich jak Amazon Web Services czy Microsoft Azure. Orkiestracja tego typu kombinacji przebiegać będzie więc z udziałem kilku różnych platform, które składają się na tzw. Hybrid Cloud Architecture.

 

 

Hybrid Cloud a Multi-Cloud – główne różnice

 

Hybrydowa Chmura, o której dziś mowa, bywa czasem mylona z podejściem Multi-Cloud. Jednak choć pomiędzy oba terminami można znaleźć wspólny mianownik, odnoszą się one do dwóch strategii, które nieco się od siebie różnią.

 

Multi Cloud w praktyce oznacza integrację kilku Chmur publicznych. Firma może wykorzystywać jedną z nich jako bazę danych, kolejną jako warstwę PaaS (Platform as a Service), a z jeszcze innej korzystać w przypadku uwierzytelniania użytkowników.

 

Chmura hybrydowa łączy zaś rozwiązania publiczne z prywatnymi lub opcją on-premise. Ta ostatnia może posłużyć jako data center lub jakakolwiek inna infrastruktura IT w obrębie sieci firmowej.

 

Podejścia Multi-Cloud i Hybrid-Cloud łączy więc to, że oba odnoszą się do integracji kilku rozwiązań chmurowych. Różnią się zaś w zakresie infrastruktur, które ze sobą wiążą. W przypadku Chmury hybrydowej mowa jest o różnych elementach, które można porównać np. do jabłek i pomarańczy. Strategia Multi-Cloud zakłada zaś kombinację kilku składników tego samego typu (lub – w przypadku owocowej metafory – odmiany).

 

Skąd więc cały ten terminologiczny ambaras? Otóż jeśli elementy wdrożenia hybrydowego obejmują kilka Chmur publicznych, można je również uznać za przykład Multi-Cloud. Z tego powodu terminy te są czasem używane wymiennie, mimo że w rzeczywistości odnoszą się do nieco innych sytuacji.

 

 

Dlaczego Hybrid Cloud jest bardzo popularne? Kiedy warto zaimplementować w przedsiębiorstwie Chmurę hybrydową?

 

Wdrożenia hybrydowe są dosyć powszechne z kilku powodów. Dla przykładu, niektóre firmy migrują do Chmury jedynie częściowo ponieważ całościowy transfer byłby dla nich zbyt kosztowny lub wymagający pod względem zasobów. Niektóre elementy pozostawiane są więc po stronie starszej infrastruktury on-premise.

 

Organizacje mogą również zdecydować się na przyjęcie strategii hybrydowej w celu utrzymania niektórych procesów i danych w bardziej kontrolowanym środowisku (takim jak Chmura prywatna lub lokalne centrum danych) przy jednoczesnym wykorzystaniu większych zasobów i niższych kosztów przetwarzania, które oferują dostawcy public Cloud.

 

Ważną rolę odgrywa w tym wszystkim także kwestia bezpieczeństwa. W przypadku firm, które mają wysokie standardy regulacyjne dla dowolnego podzbioru swoich danych lub logiki biznesowej, wdrożenie chmury hybrydowej może okazać się najlepszym rozwiązaniem. Dostawcy Chmury publicznej dysponują bowiem często większymi zasobami i budżetami na cyberbezpieczeństwo, które umożliwiają instalowanie patchy i zwiększenie ochrony.

 

 

Największe zalety Hybrid Cloud

 

Chociaż usługi chmurowe mogą generować oszczędności i pozwalać na realizację zielonych strategii, największą wartość dostarczają tak naprawdę poprzez wspieranie szybko postępującej transformacji cyfrowej. Każda z organizacji wykorzystujących nowoczesne technologie powinna więc brać pod uwagę zarówno agendę IT, jak i kwestie związane z DX (Digital Transformation). Ta pierwsza skupia się zwykle na aspekcie oszczędności finansowych. Plany transformacji cyfrowej wykraczają zaś znacznie dalej i koncentrują się na inwestycjach, które będą na siebie same zarabiać.

 

W jaki sposób wiąże się to z Chmurą hybrydową? Otóż największą korzyścią, jaką oferuje jej wdrożenie jest zwinność. A zdolność do szybkiej adaptacji i zmiany kierunku to podstawowa cecha cyfrowego biznesu. Łącząc ze sobą wszystko to, co najlepsze w komponentach, aplikacjach i architekturach, które oferują prywatne, publiczne i lokalne rozwiązania chmurowe, przedsiębiorstwa wypracowują sobie przewagę konkurencyjną na rynku.

 

 

Największe wady Hybrid Cloud

 

Choć podejście hybrydowe okaże się dla wielu biznesów zbawienne, niektóre z przedsiębiorstw mogą jednak napotkać nie lada wyzwania.

 

Pierwsze z nich daje o sobie znać już na samym początku. Jako, że infrastruktura Chmury hybrydowej stwarza duże wymagania w zakresie sieci, pamięci masowej i serwerów, może być ona trudna do wdrożenia, zaś sama implementacja – okazać bardzo czasochłonna. Bez odpowiedniej dozy dokładności nie sposób będzie też zapobiec problemom, które mogłyby wystąpić w przyszłości. Niezbędne jest więc skorzystanie na tym etapie z partnera technologicznego, który ma duże doświadczenie w praktykach wdrożeniowych.

 

Hybrydowa architektura może być również ciężka w zarządzaniu. Migracja do Chmury publicznej sama w sobie jest nie lada wyzwaniem, biorąc pod uwagę ilość dostępnych opcji i komponentów, których wciąż przybywa. A gdy środowisko cloudowe jest rozszerzane o kolejne elementy, operacje stają się jeszcze bardziej skomplikowane. Niełatwo jest też uzyskać jasny obraz całej infrastruktury.

 

 

Jak zabezpieczyć infrastrukturę Chmury hybrydowej?

 

Kwestia security wymaga w Chmurze innego podejścia niż w przypadku sprzętu lokalnego. Dla przykładu, narzędzia i strategie wykorzystywane do zarządzania siecią WAN nie są wystarczające do zapewnienia bezpieczeństwa sieci i danych cloudowych.

 

Połączenie rozwiązań publicznych, prywatnych i on-premise może jednak uchronić infrastrukturę Chmury od zagrożeń takich jak włamania między sąsiadującymi ze sobą środowiskami. Aby było to możliwe, niezbędny będzie dobry zespół ds. security i compliance. Pomoże on nie tylko w codziennej nawigacji, ale i zapewni firmie krytyczną kontrolę nad danymi, m. in. minimalizując tzw. data exposure.

 

Chcesz porozmawiać o jeszcze jakimś aspekcie związanym z Chmurą? Czekamy na kontakt.

Kubernetes to system open-source do automatyzacji wdrażania, skalowania i zarządzania skonteneryzowanymi aplikacjami. System był rozwijany w Google na wzór Borga, innego narzędzia wykorzystywanego w tej firmie do zarządzania klastrami. Głównym zadaniem Kubernetes jest grupowanie i orkiestracja kontenerów, czyli wykonywalnego kodu wraz ze wszystkimi zależnościami, który może być wdrożony na dowolnej infrastrukturze IT a później swobodnie przenoszony – to niezwykle istotne w dobie cloud culture. Takie grupowanie kontenerów w logiczne jednostki ułatwia zarządzanie i ich odkrywanie, co ma z kolei szczególne znacznie w przypadku dużych aplikacji korporacyjnych, które mogą składać się z setek czy nawet tysięcy kontenerów.

Firmy są zainteresowane wdrożeniem Kubernetes, ponieważ większość dużych organizacji to dzisiaj, przynajmniej w pewnej mierze, producenci oprogramowania. Aplikacje stały się fundamentem działania nowoczesnych przedsiębiorstw. Kontenery ułatwiają rozwiązywanie problemów, które pojawiają się zwykle w takiej sytuacji: przyspieszają dostarczanie oprogramowania, ułatwiają aktualizacje i modernizację programów czy zarządzanie kodem w skali całego cyklu użytkowania aplikacji

Z pewnością wdrożenie Kubernetes nie jest jednak zadaniem prostym. W poniższym tekście postaramy się odpowiedzieć na najczęściej zadawane przez firmy pytania stawiane w związku z takim projektem.

 

 

Czy warto wdrożyć Kubernetes w przedsiębiorstwie?

 

Niewątpliwie warto, zwłaszcza, że jeśli firma produkuje duże ilości oprogramowania i chce robić to jeszcze szybciej, łatwiej i bezpieczniej. Niemniej warto podkreślić już w tym miejscu, że Kubernetes jako platforma orkiestracji kontenerów nie jest panaceum na wszelkie zło związane z budowaniem i zarządzaniem aplikacjami. Sam Kubernetes to duży pojazd, którym będziemy transportować różne rzeczy. Jeśli nie mamy jednak czego wozić, to kupowanie takiego pojazdu nie ma sensu.

„Kubernetes to tylko narzędzie, którego instalacja w firmowym środowisku nie sprawi magicznie, że będziemy uruchamiać aplikacje niwelując wszystkie problemy powstające w skali całego cyklu ich życia. Potrzebny jest jeszcze framework, aplikacje wspierające i wiele innych drobnych elementów. Samo wdrożenie Kubernetes to tylko początek drogi do usprawniania developmentu” – mówi Łukasz Sztachański, Cloud Engineer w Mindbox.

 

 

Jak przebiega proces wdrożenia Kubernetes w firmie?

 

Zasadniczo mamy do wyboru dwie drogi: budowanie Kubernetes od podstaw albo użycie rozwiązania komercyjnego, takiego jak np. OpenShift, który jest dzisiaj de facto standardem. Zacznijmy od tej drugiej opcji. Komercyjni dostawcy zapewniają gotową receptę na idealny zestaw technologii, które stworzą platformę Kubernetes. Ogromną zaletą tego podejścia jest to, że cały proces instalacji jest maksymalnie uproszczony. Finalnie otrzymujemy platformę, która wspiera wszystkie procesy DevOps i łatwo można z niej korzystać.

Najczęściej używaną, najbardziej popularną platformą bazującą na Kubernetesie jest OpenShift. Zaproponowany przez RedHat stos technologiczny jest [i]optymalny. Posiada komponenty do logowania zdarzeń, oferuje panel graficzny, kompletne rozwiązania dla baz danych oraz platformę do rozwoju oprogramowania.

Niewątpliwym minusem wyboru gotowego rozwiązania, poza kosztem licencji, który jest nietrywialny, jest jednak to, że gotowa recepta, pomimo tego, że bardzo dobra, nie pasuje jednak do wszystkich zastosowań.

Ten problem rozwiązuje podejście polegające na zbudowaniu Kubernetesa od zera. Pozwala bowiem stworzyć idealnie dopasowaną do potrzeb i wymagań firmy platformę. Wymaga jednak posiadania ludzi, którzy mają bogatą wiedzę i doświadczenie oraz silnej edukacji. Dodatkowo potrzeba znacznie więcej czasu niż w przypadku wdrażania rozwiązania komercyjnego.

Ile czasu potrzeba w obu przypadkach? „Zakładając, że nie ma żadnych ograniczeń w środowisku organizacji, które mogłyby opóźniać wdrożenie, takich jak np. brak dostępu do pewnych systemów, to platformę bazującą na gotowym rozwiązaniu można wdrożyć w tydzień. Na instalację potrzeba kilka godzin, ale później trzeba jeszcze dostosować platformę do firmowego środowiska. Po tygodniu zespoły programistycznie przy minimalnym tarciu mogą wdrażać aplikacje na uruchomiony klaster przy pomocy procesu CI/CD (Continuous Integration/Continuous Delivery). Oczywiście także w tym przypadku potrzebna jest wiedza ekspercka dotycząca integracji centrum uwierzytelniania czy konfiguracji ustawień sieciowych, ale wszystko to jest relatywnie proste w porównaniu do budowania od podstaw, które może potrwać kilka miesięcy. Zbudowanie platformy o funkcjonalnościach porównywalnych z rozwiązaniami komercyjnymi oceniłbym na dwa miesiące” – komentuje Łukasz Sztachański.

 

 

Jakie są symptomy źle wdrożonego Kubernetes?

 

Podstawowym założeniem architektury Kubernetes jest pełna, zautomatyzowana redundancja infrastruktury i działających aplikacji. Dlatego wszelkie awarie powinny być praktycznie niezauważalne. Przy tym konfiguracja platformy powinna być utrzymywana w kodzie. Nikt nie powinien niczego robić manualnie. Całe zarzadzanie i rozwój platformy powinno odbywać się z poziomu kodu. Dzięki temu, jeśli nagle z dowolnego powodu nasza aplikacja znika, to ten sam klaster z tą samą konfiguracją i aplikacjami jesteśmy w stanie zestawić w innym centrum danych w ciągu kilku godzin, ponieważ mamy już receptę, którą przygotowaliśmy wcześniej.

Jeśli jednak nadal posiadamy pojedynczy punkt awarii albo zauważamy awarie części centrum danych to jest to coś niepokojącego, coś co sugeruje, że wdrożenie Kubernetes nie poszło po naszej myśli.  Podobnie jest z aplikacjami. Jeśli są napisane w sposób, który nie pozwala na przenoszenie ich bez zauważalnego przestoju na inną część klastra Kubernetes, to znaczy że mamy problem. Przy dobrym wdrożeniu powinniśmy być odporni na awarie.

 

Czym odznacza się dobrze wdrożony Kubernetes?

 

Przeciwnie, jeśli jesteśmy odporni na awarie, nie trzeba działać manualnie i można szybko odtwarzać konfiguracje. Jeśli jesteśmy w stanie wycofywać eksperymentalne zmiany, to znaczy, że najprawdopodobniej wszystko działa znakomicie.

„Zadajmy sobie kilka pytań dotyczących wykorzystania naszego klastra Kubernetes. Przykładowo: czy mamy procesy CI/CD przy tworzeniu oprogramowania? Albo: czy dostarczamy oprogramowanie w szybki i zautomatyzowany sposób? Odpowiadając sobie na takie pytania, szybko dowiemy się czy mamy dobrze wdrożony Kubernetes” – mówi Łukasz Sztachański.

 

 

Strategie wdrażania Kubernetes

 

Przygotowując się do wdrożenia organizacja ma zasadniczo dwie strategie do wyboru: Big Bang lub selekcja jednego projektu. Pierwsza opcja to całkowita, gwałtowna rewolucja, budowa jednej platformy, na którą przeniesiemy wszystkie projekty programistyczne. Od ustalonego momentu wszystkie aplikacje będą działać na tej platformie (lub kilku platformach wykorzystywanych w organizacji). W jednej chwili zaprzestajemy rozwoju oprogramowania w starym modelu i przechodzimy na nowy. Programiści mają jeden punkt interakcji. To z jednej strony dobre rozwiązanie. Oferuje wysoki potencjalny zysk, ale jest obarczone jednocześnie wysokim ryzykiem porażki. Bardzo szybko spłacamy dług technologiczny, ale wymuszamy coś na organizacji i testujemy na żywym organizmie. Czasem może powinąć się noga.

Drugi model polega na wyborze jednego projektu. Przykładowo w banku może to być czat dla klientów. Dla tego jednego elementu w całym firmowym środowisku tworzymy szablon, który będzie opisywał jak stworzyć platformę, jak ją zainstalować, jak pisać kod i jakie narzędzia CI/CD zastosujemy. Po zbudowaniu takiej platformy wraz ze wszystkimi dodatkowymi elementami, uruchomimy nową aplikację czatu z klientami. Później ten sam szablon możemy odtworzyć dla innego projektu w organizacji np. w przypadku naszego banku może to być aplikacja wspierająca wyświetlanie salda czy interakcje z BIK.

 

 

Wdrożenie Kubernetes vs Docker

 

Docker to silnik do uruchamiania kontenerów. Kubernetes to orkiestrator kontenerów, kompletny, złożony system, który dba o to, żeby kontenery zachowały stan opisany przez programistów. Przykładowo, jeśli zespół programistów ustali, że ich aplikacja skonteneryzowana przy pomocy Dockera ma działać w czterech kopiach, to platforma Kubernetes będzie odpowiedzialna za to, żeby zostały one uruchomione i cały czas będzie utrzymywać te cztery kopie. W przypadku awarii Kubrenets zareaguje w odpowiedni sposób i uruchomi kolejną kopię. Oczywiście te mechanizmy są o wiele bardziej skomplikowane, topologia może być bardziej skomplikowana, można tworzyć bardziej skomplikowane reguły, ale zasada się zawsze ta sama.

„Jeszcze do niedawna na polu orkiestracji kontenerów można było mówić o konkurencji. Alternatywą był np. Docker Swarm, ale oferował on, podobnie jak inni konkurenci o wiele mniej niż Kubernetes. I właśnie dlatego Kubernetes stał się dzisiaj de facto standardem” – podsumowuje Łukasz Sztachański.

 

 

Holistyczne podejście do automatyzacji i konieczność zdalnego zarządzania projektami to tylko niektóre z powodów, dla których zapotrzebowanie na aplikacje kontenerowe wciąż rośnie, jak podaje Garnter. Ręczne monitorowanie kosztów infrastruktury Kubernetes może zaś stanowić nie lada wyzwanie.

 

Jednym z rozwiązań w tym przypadku będzie zainstalowanie zautomatyzowanego systemu zarządzania wydatkami, które pozwoli skrócić czas i wysiłek związany z obliczeniami dla poszczególnych kontenerów, a także zmniejszyć ryzyko błędów. Przykładem takiego narzędzia jest Kubecost (open source i premium).

 

 

Do czego służy Kubecost?

 

Kubecost to system do raportowania danych w czasie rzeczywistym dla zespołów korzystających z platformy Kubernetes. Zapewnia on stały wgląd w koszty, pomagając tym samym w obniżaniu wydatków związanych z Chmurą.

 

Należy jednak pamiętać, że Kubecost został zaprojektowany specjalnie do pracy z Kubernetes. Nie służy zatem do wyliczania całkowitych kosztów wdrożeń z udziałem technologii cloudowych, które często są wykorzystywane np. w implementacji RPA. W takim przypadku należy posiłkować się odpowiednimi metodami obliczeniowymi, tj. TCOTCA.

 

Kubecost korzysta za to z określonych metryk i kategorii należności, które pozwalają określić m.in. wysokość zużytych i zarezerwowanych zasobów (w tym wdrożeniowych) oraz ich koszt, a także miesięczną opłatę za klaster. Tego typu kalkulacja pozwala z kolei na przygotowanie rekomendacji dotyczących obniżenia wspomnianych wydatków dla Microsoft Azure, AWS czy Google Cloud Platform.

 

Jak zarządzać kosztami dzięki Kubecost?

 

Model alokacji, według którego działa Kubecost, pozwala na  analizę kosztów na dowolnym poziomie Kubernetes, obsługując przy tym jego natywne obiekty, takie jak przestrzeń nazw, kontenery, woluminy czy klastry. Pozyskane w ten sposób dane są używane np. do optymalizacji węzłów. Jeśli okaże się, że jakieś z nich są niewykorzystywane, można nimi efektywniej zarządzić lub po prostu je wyeliminować. To samo tyczy się pamięci masowej.

 

Jedna z nowszych funkcji Kubecost pomaga również znaleźć optymalny zestaw węzłów, dając zalecenia dotyczące konfiguracji klastrów Kubernetes. Może to pomóc użytkownikom osiągnąć oszczędności rzędu nawet 60%. Kubecast wyposażony jest także w zestaw powiadomień, które są aktywowane np. gdy osiągnięty został wcześniej ustalony próg kosztów. Cykliczne aktualizacje raportów pozwalają zaś na określanie realnych celów finansowych.

 

 

Dlaczego warto zaimplementować Kubecost? Wady i zalety stosowania kubecost

 

Dodanie Kubecost do narzędzi Kubernetes może pomóc w obniżeniu kosztów i zwiększeniu produktywności firmy. Szczegółowe analizy pozwalają bowiem na dostosowanie wykonywanych operacji i chronią przed marnotrawstwem środków. Do pozostałych korzyści należą zaś:

 

  • Alokacja kosztów w czasie rzeczywistym, konfigurowalna za pomocą etykiet. Pozwala ona na zmierzenie wydatków powiązanych z produktami i zespołami. Jest to możliwe dzięki interfejsowi Kubecost Allocation API.
  • Dynamiczna wycena zasobów po zintegrowaniu Kubecost z AWS czy Google Cloud Platform.
  • Wskaźniki alokacji kosztów dla procesora, karty graficznej i pamięci masowej.
  • Alerty i cykliczne raporty.
  • Długoterminowy dostęp do wskaźników.

 

Kubecost nie posiada jednak mechanizmów automatycznego skalowania (np. dla węzłów), które oferują konkurenci. Co więcej, narzędzie to koncentruje się głównie na optymalizacji kosztów. Będzie ono więc prawdopodobnie stanowić lepsze rozwiązanie dla większych firm, których wydatki obejmują wiele jednostek biznesowych, a słabiej sprawdzi się w przypadku start-upów.

 

 

Jak zaimplementować Kubecost? Kubecost & GitHub

 

Kubecost oferuje wersję bezpłatną i premium. Pierwsza z nich dostępna jest za pośrednictwem serwisu GitHub. Otwarty Kubecost wyposażony jest oczywiście w znacznie uboższe funkcje, a pamięć masowa jest ograniczona w tym przypadku do piętnastu dni. Można go jednak wdrożyć bezpośrednio w klastrze, samodzielnie uruchomić model i wprowadzić pożądane modyfikacje. Dla wprawnej ręki całość nie będzie wiele trudniejsza niż wpisanie w Google magicznej frazy typu „Kubecost: create by Google”.

 

Miesięczny koszt wersji płatnej zależy natomiast od ilości dostępnych węzłów. W ramach planu biznesowego, Kubecost zapewnia obsługę wielu klastrów i dostęp do pomocy technicznej. W przypadku przedsiębiorstw z ponad dwustoma węzłami możliwy jest wybór planu Enterprise, który oferuje nieograniczoną pamięć masową i dedykowane wsparcie.

 

Technologie kontenerowe, konteneryzacja aplikacji, oprogramowanie do orkiestracji kontenerów i absolutnie wszystko, co z kontenerami związane to dzisiaj jeden z głównych tematów dyskusji prowadzonych w przestrzeni biznesowego IT. Jest tak dlatego, ponieważ aplikacje są obecnie fundamentem funkcjonowania większości organizacji. Większość dużych przedsiębiorstw stała się praktycznie firmami programistycznymi i w konsekwencji została zmuszona zmierzyć się ze wszystkimi wyzwaniami, z jakimi mierzą się producenci oprogramowania. Nie we wszystkich przypadkach sprawdzą się platformy low-code. Duże firmy nadal będą tworzyć oprogramowanie przy wykorzystaniu rozwiązań dedykowanych.

Właśnie dla nich rozwiązaniem są kontenery. Rozwiązują bowiem kilka kluczowych problemów programistycznych, w tym w szczególności przyspieszają dostarczanie oprogramowania, ułatwiają aktualizacje i modernizację programów, zarządzanie kodem w skali całego cyklu użytkowania aplikacji oraz zapewniają nieograniczone wręcz możliwości jego przenoszenia między platformami. Zwłaszcza to ostatnie, w dobie powszechnej migracji do chmury, popularyzacji cloud culture oraz „zielonego podejścia”, ma niebagatelne znaczenie. Kontenery zapewniają więcej korzyści niż tradycyjna wirtualizacja, ponieważ są prostsze, mniejsze i można je szybciej wdrażać – nie potrzebują jak maszyny wirtualne pełnego systemu operacyjnego.

Stąd właśnie zainteresowanie kontenerami oraz ich niekwestionowanym władcą, Kubernetesem, który – jak niektórzy mówią – zdetronizował nieco starszego od siebie Dockera. Czy jednak obie technologie to konkurenci? Kubernetes vs Docker? Docker vs Kubernetes? Czy mogą ze sobą współpracować? Na czym polegają różnice między Docker a Kubernetes? Którą technologię warto wybrać? Na wszystkie te pytania odpowiadamy poniżej.

 

 

Różnice między Kubernetes a Dockerem?

 

Zacznijmy od tego, czym w ogóle są wspomniane technologie. Docker, którego pierwsza wersja została udostępniona w marcu 2013 r. to działająca na poziomie systemu operacyjnego technologia wirtualizacyjna, udostępniana w modelu open source, umożliwiająca dostarczanie kontenerów, czyli wykonywalnego kodu wraz ze wszystkimi zależnościami. Takie podejście pozwala na uruchamianie kontenera na dowolnej infrastrukturze IT i późniejsze swobodne jego przenoszenie – to jedna z głównych zalet konteneryzacji. Docker to zarazem format plików – Docker File, przy pomocy którego tworzy się obrazy kontenerów – Docker Image oraz środowisko do uruchamiania kontenerów – Docker Engine. Jednocześnie Docker to dzisiaj również firma, która oferuje komercyjnie produkty Docker.

Kubernetes, albo inaczej K8s, to mający swoją genezę w firmie Google, opublikowany w czerwcu 2014 r. system do orkiestracji kontenerów, czyli automatyzacji wdrażania, skalowania i zarządzania skonteneryzowanymi aplikacjami. Kubernetes również dostępny jest w modelu open-source. Grupuje on kontenery tworzące aplikacje w jednostki logiczne ułatwiające zarządzanie i wyszukiwanie – to tzw. klastry. Składają się one z węzła nadrzędnego (master), który orkiestruje pracę pozostałych kontenerów (workerów). Dzięki swojej otwartości zapewnia pełną swobodę wyboru infrastruktury, na której są uruchamiane aplikacje – możemy wdrażać je lokalnie, w chmurze publicznej czy hybrydowej a później swobodnie je przenosić.

 

 

Różnice między Kubernetes a Docker Swarm

 

Zatem pierwsza technologia nie jest bezpośrednim rywalem drugiej. Wdrożenie Kubernetes, czyli systemu orkiestracji kontenerów może zostać zrealizowane po wdrożeniu Docker, czyli platformy kontenerowej. Na czym polega orkiestracja? System pomaga zarządzać i obsługiwać dużą liczbę kontenerów eliminując potencjalne nieefektywności, równoważy obciążenia w skali całego złożonego środowiska i odpowiada za uwierzytelnianie oraz bezpieczeństwo.

Oczywiście, choć obecnie najbardziej popularny, Kubernetes nie jest jedynym systemem orkiestracji kontenerów. Alternatywą jest np. Docker Swarm – i to jest właśnie bezpośredni konkurent Kubernetes.

Docker Swarm, a właściwie tryb pracy swarm mode, to sposób orkiestracji klastrów Docker. Swarm składa się z węzłów Docker Engine manager, które zarządzają i obsługują wykonujące konkretne zadania workery. Jedną z największych zalet Docker Swarm jest ścisła integracja z innymi narzędziami Dockera oraz technologiami, które zostały stworzone dla kontenerów Docker. Wadą – względem – Kubernetesa – mniejsza funkcjonalność i ogólna mniejsza elastyczność.

 

 

Wady i zalety Kubernetes i Docker

 

Jeden kontener to jeden proces. Na marginesie to istotna zaleta konteneryzacji. Kiedy chcemy zainstalować poprawki lub zmodernizować aplikację, nie musimy jej całkowicie zatrzymywać. Prowadzone prace ograniczone są bowiem tylko do konkretnego kontenera. To zaleta, ale zarazem potencjalny problem. Jak sobie poradzimy w sytuacji, w której mamy bardzo dużo kontenerów, które powinny ze sobą płynnie współpracować?

W przypadku prostych aplikacji, Docker sprawdza się świetnie. Jednak jeśli mamy do czynienia z aplikacjami korporacyjnymi, w których trzeba zarządzać setkami czy nawet tysiącami kontenerów, sprawa zaczyna przerastać nawet najbardziej liczne i doświadczone zespoły IT.

Jak bowiem koordynować równoczesną pracę wszystkich kontenerów? Jak płynnie aktualizować kod bez przerywania pracy całej aplikacji? Wreszcie, pojawia się problem z monitorowaniem stanu aplikacji. Jak śledzić pracę setek kontenerów i restartować je w odpowiednim momencie?

Z tym wszystkim doskonale radzi sobie system orkiestracyjny, a jak to zostało już powiedziane wcześniej Kubernetes oferuje największą funkcjonalność i elastyczność spośród dostępnych na rynku technologii. Wokół Kubernetesa działa także największa, najbardziej aktywna i prężna społeczność. Wreszcie jest to technologia sprawdzona na naprawdę dużą skalę, m.in. przez Google. Sam Docker Engine i nawet Docker Swarm nie są pod tymi względami równorzędną konkurencją.

 

 

Czy Kubernetes i Docker dobrze działają razem?

 

Odpowiedź na to pytanie brzmi: zdecydowanie, tak. Obie technologię mają komplementarny charakter i rozwiązują wiele problemów, na jakie napotykają programiści tworzący aplikacje korporacyjne. Docker pozwala na „pakowanie” aplikacji w kontenery, a Kubernetes umożliwia ich orkiestrację – sharmonizowanie i zautomatyzowane ich uruchamianie w dowolnych środowiskach IT, bez względu na ich skalę.

Co więcej, najnowsze wersje Docker posiadają wbudowaną integracje z Kubernetes, dzięki czemu można skutecznie automatyzować i efektywnie zarządzać aplikacjami skonteneryzowanymi z użyciem Docker. Dzięki wykorzystaniu obydwu technologii możemy osiągnąć większą niezawodność i dostępność oraz skalowalność aplikacji.

 

 

Który system do konteneryzacji warto wybrać dla firmy?

 

Docker to sprawdzona technologia kontenerowa umożliwiająca budowanie bezpiecznych aplikacji, które można szybko uruchamiać i łatwo przenosić między środowiskami. Zwłaszcza kontenerów linuxowych – w tym obszarze Docker to de facto standard. Na swojej stronie WWW Docker chwali się, że wspiera go ponad 13 mln. developerów i obsługuje ponad 7 mln. aplikacji. Jeśli zatem zależy nam na szybkim, efektywnym produkowaniu przenośnego oprogramowania, Docker to doskonały wybór. W przypadku, jeśli nasze aplikacje są stosunkowo nieskomplikowane, poradzimy sobie bez systemu orkiestracji. Ewentualnie możemy skorzystać z Docker Swarm.

Jeśli jednak działamy na dużą skalę, nasze aplikacje są złożone, lepszym wyborem niż Docker Swarm może okazać się Kubernetes. Oferuje on dodatkowe korzyści w postaci równoważenia obciążenia, zautomatyzowanych, inteligentnych funkcji, które zapewniają poprawne działanie a także wprowadzanie i wycofywanie zmian. Dodatkową zaletą jest także graficzny interfejs użytkownika.

Technologie mające największy wpływ na rozwój cyfrowych procesów biznesowych można podsumować jednym słowem: wydajność. Tyczy się to zarówno rozwiązań związanych z automatyzacją procesów, w tym z udziałem RPA i Chmury, jak i wszelkich metod mających na celu zwiększenie dostępności do aplikacji. Jednym z najpopularniejszych obecnie sposobów jest zaś wykorzystanie przeglądarek internetowych wspomaganych przez maszyny wirtualne, takie jak np. WebAssembly.

 

 

WebAssembly (WASM) – definicja

 

WebAssembly (lub WASM) to niezależny od języka i platformy format kodu binarnego. Może on zostać wykonany po stronie klienta, w jego przeglądarce (z użyciem interfejsu API sieci Web) lub na maszynie wirtualnej. Wydajność WebAssembly jest zbliżona do natywnej, zaś sam standard zachowuje kompatybilność z istniejącymi ekosystemami. Co więcej, pliki binarne zajmują naprawdę niewiele miejsca (czasem są to pojedyncze kilobajty). Nie jest to bez znaczenia, jeśli w grę wchodzą urządzenia mobilne, ograniczone mocą baterii.

 

Choć technologia ta jest stosunkowo młoda (jej premiera miała miejsce w 2017 roku), nietrudno o znalezienie przykładów WebAssembly w sieci. Jednym z nich jest program AutoCAD firmy Autodesk, który jest wykorzystywany do dwuwymiarowego i trójwymiarowego komputerowego wspomagania projektowania. Wpisując w wyszukiwarkę frazę „WebAssembly demo” można z kolei sprawdzić m.in. jak WASM współpracuje z JavaScript oraz przekonać się, że na ogół działa szybciej (od 10 do nawet 800%).

 

Bardzo dobrze spisuje się także główny framework. Blazor WebAssembly pozwala bowiem nie tylko uruchomić np. C#, ale i w łatwy sposób manipulować DOM przeglądarki, dzięki czemu stanowi konkurencję chociażby dla Angular. Aplikacja może być też aktywowana po stronie serwera.

 

 

Jakie są zalety korzystania z WASM? Bezpieczeństwo WebAssembly (WASM)

 

WASM został stworzony z myślą o osiągnięciu prawie natywnych prędkości. Jest przy tym czytelny, bezpieczny i łatwy do debugowania. Do niewątpliwych zalet należy też wspomniana już niezależność językowa i platformowa – WebAssembly działa we wszystkich najpopularniejszych przeglądarkach (Mozilla Firefox, Google Chrome, Safari oraz Edge). To samo tyczy się sprzętu.

 

Koszt opracowania i utrzymania samego oprogramowania również będzie niski. Wynika to z faktu, że dystrybucja aplikacji ogranicza się do przeglądarki i jednocześnie obejmuje wszystkie możliwe systemy operacyjne. Przejście z opcji desktopowej na webową także nie będzie wiązało się z dużymi wydatkami z uwagi na to, że można wykorzystać już istniejący kod. Sam format jest zaś rozwiązaniem typu open-source.

 

 

Czy istnieją duże wady korzystania z WASM?

 

Należy jednak pamiętać, że WebAssembly jest technologią stosunkowo nową i posiada jeszcze pewne ograniczenia, które utrudniają podjęcie decyzji o jej wdrożeniu. Należą do nich m.in.:

 

  • brak bezpośredniego dostępu do internetowych interfejsów API,
  • brak wielowątkowości,
  • brak obsługi wyjątków,
  • brak funkcji tzw. odśmiecania pamięci,
  • brak wsparcia przez starsze przeglądarki.

 

 

Do czego używane jest WebAssembly? Przykłady użycia WebAssembly

 

Technologia WebAssembly skupia się głównie na zadaniach mocno obciążających procesor. Może być więc z powodzeniem stosowana w przypadku:

 

  • gier,
  • streamowania i edycji zdjęć oraz plików audio i wideo,
  • sztucznej inteligencji,
  • uczenia maszynowego, które nierzadko stanowi nieodzowną część automatyzacji wprowadzania danych,
  • wirtualnej i rozszerzonej rzeczywistości,
  • aplikacji P2P,
  • rozwiązań IoT, których sercem jest najczęściej Chmura,
  • progresywnych aplikacji webowych,
  • rozszerzania aplikacji desktopowych o wersje webowe,
  • aplikacji mobilnych,
  • modernizacji starszych aplikacji (stworzonych np. w Silverlight).

Rewolucja technologiczna ostatnich, pandemicznych lat to nie tylko cyfryzacja rynku pracy. Wiele firm rozważa również migrację do Chmury czy outsourcing usług z wykorzystaniem technologii cloudowych. Kusi je przede wszystkim możliwość zdalnego zarządzania projektami, aspekt ekologiczny tego rozwiązania i perspektywa oszczędności. Biorąc pod uwagę te czynniki, szczególnie atrakcyjnie prezentuje się zaś przetwarzanie bezserwerowe.

 

Czym jest przetwarzanie bezserwerowe (serverless)?

 

Serverless to model programowania oparty na natywnych technologiach cloudowych. Umożliwia on tworzenie i uruchamianie aplikacji bez konieczności zarządzania serwerami. Kod przechowywany jest wówczas w systemach zwanych kontenerami. Rutynowa praca związana z udostępnianiem, konserwacją i skalowaniem infrastruktury serwerowej spoczywa zaś na barkach dostawcy Chmury i jest zupełnie oderwana od procesu tworzenia oprogramowania.

 

Po wdrożeniu, aplikacje bezserwerowe mogą być skalowane zgodnie z zapotrzebowaniem, co stanowi część outsourcowanej usługi. Co więcej, możliwe jest pobranie wtyczek typu serverless offline, które umożliwiają dostęp do najważniejszych funkcji z poziomu maszyn lokalnych. Istnieje również szereg rozwiązań open-source (takich jak np. Serverless Framework), dzięki którym można je dowolnie konfigurować. Możliwe jest np. stworzenie aplikacji składającej się zarówno z tradycyjnych, jak i bezserwerowych komponentów.

 

Warto wiedzieć też, że oferty usług serverless computing zazwyczaj dzielą się na dwie grupy: Backend-as-a-Service (BaaS) i Function-as-a-Service (FaaS). Pierwsza opcja zapewnia programistom dostęp do szerokiego wachlarza usług. Dla przykładu, dostawca Chmury może również zająć się uwierzytelnianiem, dodatkowym szyfrowaniem czy bazami danych. W przypadku BaaS funkcje bezserwerowe są zwykle wywoływane za pośrednictwem interfejsów API.

 

Jeśli zaś chodzi o model FaaS, to programiści nadal są w nim odpowiedzialni za stworzenie niestandardowej logiki po stronie serwera, lecz działa ona w obrębie kontenerów, które są w pełni zarządzane przez dostawcę Chmury. Większość z nich ma przynajmniej jedną opcję tego typu usługi w swojej ofercie (np. AWS Lambda, Azure Functions czy IBM Cloud Functions).

 

 

Czy przetwarzanie chmurowe jest drogie? Ile kosztuje wdrażanie przetwarzania bezserwerowego?

 

Dostawcy public Cloud proponują najczęściej usługi on-demand (tzw. event-driven model), co oznacza, że użytkownik płaci tylko za to, z czego aktualnie korzysta. Jest to jedna z podstawowych różnic pomiędzy serverless computing a innymi opcjami przetwarzania w Chmurze.

 

W przypadku standardowego modelu (Infrastructure-as-a-Service), użytkownicy określają i wykupują pożądaną zdolność obliczeniową z wyprzedzeniem. Płacą zatem dostawcy rozwiązania za to, że elementy serwera, które są potrzebne do uruchomiania danych aplikacji będą zawsze aktywne.  To do użytkownika należy zaś skalowanie jego pojemności w zależności od zapotrzebowania.

 

Z kolei w przypadku architektury bezserwerowej, aplikacje są uruchamiane tylko w razie potrzeby. Gdy zdarzenie uruchamia kod, dostawca Chmury publicznej (np. AWS Serverless Computing) automatycznie przydziela mu zasoby. Po tym, jak zostanie on wykonany, użytkownik przestaje ponosić opłaty.

 

Różne czynniki będą miały wpływ na to, ile ostatecznie kosztować będzie wdrożenie przetwarzania bezserwerowego i czy okaże się ono tańsze od rozwiązanie on-premise. Dla wielu organizacji jest ono jednak często bardziej opłacalne z uwagi na brak wydatków związanych z dodatkowym sprzętem i licencjami oraz niższe koszty użytkowania, konserwacji, energii elektrycznej i chłodzenia. Należy przy tym zaznaczyć, że aby to potwierdzić konieczna byłaby szczegółowa estymacja.

 

 

Zalety przetwarzania bezserwerowego

 

  • Przetwarzanie bezserwerowe może obniżyć koszty operacyjne i zwiększyć produktywność programistów. Odciążeni od rutynowych zadań (udostępnianie serwerów, wprowadzanie poprawek do zabezpieczeń, skalowanie i zarządzanie pojemnością oraz wiele innych), developerzy mają więcej czasu na tworzenie i rozwój aplikacji.
  • Serverless ułatwia również wdrożenie rozwiązań DevOps. Programiści nie muszą bowiem szczegółowo opisywać niezbędnej do tego infrastruktury.
  • W przypadku modelu BaaS możliwe jest także skorzystanie z usprawnień aplikacji i innych komponentów z oferty dostawców.
  • Wreszcie, w modelu bezserwerowym dostawca chmury obsługuje serwery fizyczne i dynamicznie przydziela zasoby w imieniu użytkowników, którzy mogą wdrażać kod bezpośrednio do środowiska produkcyjnego, co oznacza optymalizację cyklu rozwoju oprogramowania.

 

 

Wady przetwarzania bezserwerowego

 

  • Brak obsługi własnego serwera (i kontrolowania logiki po jego stronie) może jednak powodować trudności. Dla przykładu, dostawcy Chmury mogą mieć ograniczenia dotyczące interakcji z ich komponentami, co z kolei negatywnie wpłynie na elastyczność i integracje z istniejącymi systemami.
  • W przypadku środowisk BaaS, programiści mogą zaś nie mieć żadnej kontroli nad kodem oferowanych usług.
  • Serverless to także model, który naraża na uzależnienie się od jednego dostawcy. Decydując się na jego zmianę, prawdopodobnie będzie trzeba liczyć się z kosztami modernizacji systemów i dostosowania ich do nowej specyfikacji.

 

 

Do jakich projektów warto stosować podejście serverless?

 

Architektura bezserwerowa jest idealna dla asynchronicznych, bezstanowych aplikacji, które mogą być uruchamiane w trybie natychmiastowym. Będzie też dobrym rozwiązaniem w przypadku nieprzewidywalnych (aczkolwiek dość rzadkich) wzrostów zapotrzebowania. Idealnie obsłuży więc zadania takie jak np. przetwarzanie wsadowe plików graficznych czy sprawdzanie wprowadzanych w bazie danych zmian pod kątem standardów jakości. Sprawdzi się także w przypadku aplikacji webowych, chatbotów, integracji wielosystemowych czy automatyzacji procesów biznesowych.

 

W tym ostatnim mamy szczególnie duże doświadczenie, którym chętnie się dzielimy. Zapraszamy zatem serdecznie do kontaktu i rozmowy!