Subiektywne spojrzenie na AWS Cloud Development Kit
Gdy zaczynałem swoją przygodę z chmurą, jedynym oficjalnym sposobem opisywania infrastruktury w AWS był AWS CloudFormation.
Przez kilka lat pracy z chmurą, zdążyłem się z nim nawet zaprzyjaźnić 😍. Teraz przyszedł czas aby dać szansę nowemu, czyli AWS Cloud Development Kit. W tym artykule przedstawię wady i zalety nowego narzędzia oraz odpowiem na pytanie czy z CDK też da się polubić.
CDK… ale czym właściwie jest CloudFormation?
Nie sposób zrozumieć CDK bez choćby podstawowej znajomości usługi AWS CloudFormation. Do końca 2018 roku było to jedyne oficjalne narzędzie służące do zarządzania infrastrukturą jako kod w chmurze AWS. Serwis ten jest kluczowym narzędziem służącym do codziennej pracy programistów i architektów. W deklaratywny sposób umożliwia zdefiniowanie elementów infrastruktury, których potrzebujemy. Taka definicja zapisana jest w postaci szablonu w formacie JSON lub YAML.
Przykładowy kod oraz jego opis, możesz znaleźć tutaj: https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-s3-bucket.html
Następnie, silnik CloudFormation sam zdecyduje w jaki sposób stworzyć nam pożądaną infrastrukturę. Dzięki podejściu IaC (Infrastructure as Code) w łatwy sposób można powielać istniejące architektury i zapewnić ich reprodukowalność.
W części projektów AWSowych których miałem okazję pracować, szablony CloudFormation miały poziom skomplikowania podobny do stopnia skomplikowania budowy cepa. Na przykład, na potrzeby umiejętności Alexowej, wystarczy w uproszczeniu (i często jest to wskazane), zdefiniować jedną Lambdę, uprawnienia oraz bazę danych DynamoDB. Całość takiego szablonu to kilkadziesiąt linii kodu.
Przykład dostępny na platformie github: https://github.com/deanobalino/alexa-cloudformation-sample/blob/master/cloudformation.json
Większość projektów z którymi miałęm do czynienia, była jednak o wiele bardziej zaawansowa i skomplikowana. W rozwiązaniach tego typu, często dobijamy do twardych limitów CloudFormation, a czytelność kodu drastycznie spada, pomimo usilnych starań architektów i programisów.
AWS CloudFormation nie jest prostym narzędziem. Każdy klocek naszej układanki potrzebuje być jasno i bezpośrednio zadeklarowany. Chcąc wystawić 10 serwerów EC2 w każdej strefie dostępności, musimy opisać każdy z nich. Serwery wymagają sieci, uprawnień, skalowania…
Nasza architektura często przewiduje kilka wariacji np. dla środowiska testowego i produkcyjnego. Poleganie na wbudowanych warunkach często
nie wystarcza i musimy powielać nasze szablony. Do całości obrazu dochodzą takie koncepty jak makra, niestandardowe zasoby (custom resources) czy zagnieżdżanie stosów.
Alternatywy dla CloudFormation
Między innymi z powyższych względów, powstały narzędzia open source, które adresują niektóre wspomniane trudności. Dla osób chcących pozostać przy deklaratywnym podejściu do definiowania infrastruktury przykładem może być popularny Terraform. Dla fanów programowania przykładem może być ciekawe narzędzie, którym jest Troposphere.
Troposphere pozwala na użycie języka wysokiego poziomu jakim jest Python. Pisząc kod w Pythonie definiujemy nasz stos. Jego silnik sam zajmie się wygenerowaniem ostatecznego szablonu CloudFormation.
Podejście imperatywne w rozwiązaniach typu IaaC ma wiele zalet. Między innymi pozwala testować naszą architekturę w sposób jednostkowy, a także dodaje pewnej dynamiki i wszystkich zalet (i wad) związanych ze składnią danego języka.
Podążając za trendem i dostrzegając możliwe zalety, AWS stworzył Cloud Development Kit (AWS CDK). Podczas konferencji re:Invent 2018, projekt został ogłoszony, natomiast już kilka miesięcy później doczekał się swojej pierwszej stabilnej wersji.
Czym jest AWS CDK?
AWS CDK jest narzędziem służącym definiowaniu infrastruktury w jednym z dostępnych języków programowania, a następnie po syntezie kodu wynikowego zgodnego z CloudFormation, tworzy nam pożądaną infrastukturę.
CDK wspiera wiele języków programowania, m.in. TypeScript, Python, Java oraz C#.
Główną zaletą CDK jest możliwa zwięzłość kodu opisującego rozbudowane architektury.
Na stronie głównej dokumentacji, przytoczony jest przykład, gdzie 20 linii kodu CDK odpowiada ponad 500 linią natywnego szablonu CloudFormation.
Inne oficjalne CDK zalety to:
- Składnia oraz logika danego języka programowania
- Możliwość użycia paradygmatu programowania zorientowanego obiektowo
- Grupowanie projektu w logiczne moduły
- Udostępnianie i re-używanie kodu w postaci własnej biblioteki
- Testowalność kodu, przy użyciu popularnych narzędzi
- Uzupełnianie składni przez popularne środowiska programistyczne
Osobiście dodałbym jeszcze dwie zalety:
- Wbudowane wsparcie dla aspektów
- Ułatwione tworzenie własnych custom resources
Aspekty w AWS CDK pozwalają na weryfikację naszej infrastruktury podczas syntezy wynikowego szablonu CloudFormation. Przykładem może być weryfikacja, czy przypadkiem nie próbujemy stworzyć polityki IAM, która będzie zbyt otwarta.
Pisząc natywny kod CloudFormation konieczność tworzenia custom resources, wiąże się z wyborem języka programowania, w którym go stworzymy. Istotne jest dostarczenie często całej otoczki programistycznej w postaci linterów kodu, bibliotek testowych czy innych zależności. Startując z projektem CDK to wszystko już jest dane, a dodanie takiego custom resource wygląda całkiem podobnie do innych konstruktów.
Czym są CDK constructs?
Twórcy AWS CDK zdefiniowali podstawowy byt jakim jest konstrukt, aby stworzyć abstrakcję nad każdym elementem budowanej architektury. Konstruktem może być zarówno bucket S3 czy gotowy statyczny serwer webowy z pre-definiowanymi elementami składowymi jak i bucket S3, dystrybucja CloudFront oraz certyfikat SSL.
Poza możliwością użycia wbudowanych konstruktów, które w większej mierze umożliwiają już odwzorowanie 1 do 1 elementów CloudFormation, możemy tworzyć własne. Przykład z serwerem powyżej to tylko wierzchołek góry lodowej. Dzięki modularyzacji o enkapsulacji naszej logiki, można zdefiniować konstrukty odpowiadające naszym potrzebom biznesowym.
Command Line Interface
Skoro mamy już wyobrażenie czym AWS CDK jest, warto by wiedzieć jak z nim wystartować. Twórcy zdecydowali się pójść dobrze sprawdzoną drogą i udostępnili interfejs linii poleceń. Każdy programista jest w stanie w kilka chwil zainstalować AWS CDK CLI i wygenerować prosty projekt bazowy. Czy wspomniałem już, że mam nieodparte wrażenie że autorzy są przynajmniej z pochodzenia front-endowcami?
Do instalacji wystarczy uruchomić polecenie npm:
npm install -g aws-cdkNastępnie:
cdk init — language typescriptW rezultacie powstanie nam zestaw katalogów i plików. Główny plik opisujący nasz stos będzie wyglądał mniej więcej tak:
import core = require('@aws-cdk/core');
import s3 = require('@aws-cdk/aws-s3');export class HelloCdkStack extends core.Stack {
constructor(scope: core.App, id: string, props? :core.StackProps){
super(scope, id, props); new s3.Bucket(this, 'MyFirstBucket', {
versioned: true
});
}
}
Wygenerowany kod jest gotowy do zbudowania (inaczej mówiąc — syntezy wyjściowego kodu CloudFormation) i uruchomienia jego w środowisku AWS. Dla uproszczenia pomijam podstawową konfigurację AWS CLI oraz npm.
Ostatnia komenda potrzebna do stworzenia naszego stosu i wszystkich podległych mu elementów to:
cdk deployŁyk herbaty i nasza pierwsze aplikacja oparta o CDK gotowa do użycia w chmurze. Jak dla mnie proces jest łatwy w zrozumieniu, a Ty jak sądzisz?
Czy AWS CDK ma wady?
Wprowadzając warstwę abstrakcji, zawsze pojawiają się pewne wyzwania.
Pierwszym z nich jest potrzeba nauki i poznania kolejnego narzędzia. Pomimo możliwości pisania w znanym nam języku programowania, dalej musimy poznać podstawowe koncepty, architekturę samego rozwiązania czy choćby jakie są dobre i złe wzorce zastosowań.
Lista wad AWS CDK:
- Aktualna architektura, nie pozwala na łatwe uruchamianie naszej infrastruktury na wielu kontach.
- Brak przemyślanego wsparcia dla Continuous Integration, co wymaga od nas sporo pracy aby nasza architektura była zgodna z podstawowymi założeniami AWS Well Architected Framework.
- Pisanie kodu w języku wysokiego poziomu, pociąga za sobą prawdopodobieństwo powstawania typowych bugów. Bez odpowiedniego pokrycia testami jednostkowymi, nasze zmiany mogą być bardziej nieprzewidywalne niż dotychczas.
- W dość łatwy sposób można wpaść w twarde limity dotyczące np. rozmiaru paczki z naszym kodem dla AWS Lambda czy ilości elementów w jednym stosie AWS CloudFormation
- Skoro produkt ten jest wersjonowany, zawsze pozostaje ryzyko utrzymywania odpowiednio wysokiej wersji i radzenia sobie ze zmianami w kolejnych wersjach.
- Łatwość mieszania infrastruktury z logiką biznesową naszej aplikacji.
Czy warto dać szansę i zaprzyjaźnić się z CDK?
Krótko: Tak.
Już teraz można z powodzeniem próbować jego sił w prawdziwych projektach. Warto zacząć od zbudowania prostego prototypu, aby upewnić się że podstawowe koncepty są nam znane.
Kluczowym warunkiem sukcesu w pracy z CDK, jest trzymanie się wszystkich podstawowych zasad dobrej architektury w chmurze oraz pamięć o jego wadach i ograniczeniach.
Od momentu gdy wejdziemy w świat definiowania infrastruktury kodem wysokiego poziomu, wszystkie nasze wyzwania możemy odpowiednio zaadresować jeszcze jednym warunkiem, jeszcze jedną funkcją, …a problemy wynieść na wyższy poziom 😎
