Scott Tiger Tech Blog

Wielką popularnością obecnie cieszy się programowanie zwinne (ang. agile software development), które rozpoczęło żywot w 2001 roku, a z czasem zdobyło wielką popularność i dość skutecznie wyparło tradycyjny „wodospadowy” model tworzenia oprogramowania. Metodyki zwinne odnoszą się zwłaszcza do współpracy pomiędzy programistami a użytkownikami biznesowymi.

Tymczasem w czeluściach procesu tworzenia oprogramowania czai się jeszcze inny konflikt, tym razem w obrębie organizacji: pomiędzy deweloperami a osobami odpowiedzialnymi za wdrożenie oprogramowania. Tradycyjnie w dużych firmach IT deweloperzy chcą szybko tworzyć i modyfikować oprogramowanie, podczas gdy na drodze staje im dział eksploatacji (ang. IT operations, czyli administratorzy, architekci infrastruktury sprzętowej i personel wsparcia klienta) zainteresowany głównie stabilnością i niezawodnością, a nie zmianami (patrz kultowy rysunek obok, pochodzący z jednej z pierwszych konferencji DevOps w 2010 roku). Na konflikcie interesów traci cała firma.

DevOps to kombinacja kultury, praktyk i narzędzi które łącznie przyspieszają dostarczanie klientom kolejnych wersji aplikacji i usług. W środowisku deweloperów DevOps skupia się na pojęciach takich jak budowanie kodu (ang. code building), testy pokrycia, testy jednostkowe, pakowanie i wdrażanie. W środowisku eksploatacji mówimy o aprowizacji (ang. provisioning), konfiguracji, orkiestracji i wdrażaniu. Dla obu obszarów wspólne pojęcia to zarządzanie wersjami, wdrażanie, wycofywanie zmian (ang. roll back) i testowanie.

Można powiedzieć, że o ile klasyczne metodyki zwinne dotyczą zwinności biznesowej, DevOps odnosi się do zwinności IT.

Czytaj więcej »

PowerPoint wciąż rządzi w świecie prezentacji, ale od dawna już istnieje szereg narzędzi do prezentowania slajdów w przeglądarce.

Mają one sporo zalet:

• przeglądarka WWW jest popularniejsza niż Windowsy z PowerPointem, co bardzo poszerza grono potencjalnych widzów,
• można podać URL do konkretnego slajdu,
• dzięki najnowszym możliwościom przeglądarek (HTML5, CSS3) nie jesteśmy zmuszani do instalowania pluginów takich jak Flash/Java; ponadto dostajemy przyjemne dla oka efekty przewijania slajdów, nawet 3D (patrz Impress.js demo),
• osoby z uzdolnieniami plastycznymi i webmasterzy mogą popisać się swoimi umiejętnościami aby uczynić pokaz wyjątkowym, pozostali mogą uzyskać zadowalające efekty niskim kosztem,
• na slajdach można zagnieździć działające aplikacje webowe,
• pokaz slajdów może na ogół działać na przeglądarkach mobilnych, obsługując przewijanie slajdów dotykiem.

Wbrew pozorom, funkcjonalność oferowana przez tego typu narzędzia jest w stanie całkiem sensownie zaspokoić potrzeby przeciętnego prelegenta. Dzisiaj chciałbym krótko zaagitować na rzecz narzędzia Reveal.js, które zwróciło moją uwagę. Dobrym punktem wyjścia jest przykładowa prezentacja, ukazująca możliwości narzędzia (patrz też obok).

Slajdy można przewijać klawiaturą (strzałki, spacja), klawisz ESC otwiera podgląd slajdów (można wybrać myszką ten do którego chcemy przejść).

Czytaj więcej »

Architektura mikrousług

Idea mikrousług nie powstała znikąd, obejmuje szereg sprawdzonych koncepcji takich jak programowanie zwinne (ang. agile development), architektura zorientowana na usługi (SOA), podejście API-first czy ciągłe dostarczanie (ang. continuous delivery, CD).

Główne cechy mikrousług:

• Decentralizacja, zarówno jeśli chodzi o sposób działania (i np. spojrzenie na modele danych), ale również sposób tworzenia.
• Niezależność – każdy komponent można zmienić niezależnie od pozostałych. Każdy komponent jest też tworzony przez osobny zespół.
• Mikrousługa robi jedną rzecz, ale dobrze, skupiając się na jednej dziedzinie.
• Można użyć wiele technologii – każda mikrousługa może być tworzona przy użyciu technologii najlepiej pasującej do dziedziny problemu i umiejętności zespołu.
• Każda usługa jest czarną skrzynką z dobrze zdefiniowanym API.
• Zespół który tworzy usługę jest odpowiedzialny za jej wdrożenie i utrzymanie – jest to jedna z najważniejszych zasad DevOps, o tyle istotna że zgodnie z prawem Conwaya architektura systemów tworzonych przez firmę odzwierciedla jej strukturę organizacyjną.

Najważniejsze zalety mikrousług:

• Zwinność. Mikrousługi sprzyjają organizacji małych niezależnych zespołów przejmujących swoje usługi we władanie. Zespoły działają w obrębie swoich małych i dobrze zrozumiałych światów, co pozwala im skracać cykle produkcji.
• Innowacja. Wiąże się ze swobodą wyboru technologii, języków programowania i narzędzi do tworzenia każdej usługi. Metodyki zwinne, DevOps i ciągła integracja zachęcają do eksperymentów, które można szybko przetestować i łatwo wycofać w razie niepowodzeń. Niski koszt porażki tworzy kulturę podatną na zmiany i innowacje.
• Skalowalność i dostępność. Ponieważ mikrousługi są niezależne, można je na produkcji łatwo podmieniać i rozmnażać.

Rzecz jasna nie ma darmowych obiadów i architektura mikrousług ma również swoje wady:

• Jest to architektura rozproszona, ze wszystkimi wadami. W szczególności nie można założyć że sieć jest niezawodna, opóźnienia komunikacji pomijalne a przepustowość interfejsów sieciowych nieskończona. Architektura mikrousług to problemy z asynchroniczną komunikacją, spójnością danych (transakcje!), odnajdywaniem się mikrousług, czy uwierzytelnianiem komunikacji.
• Migracja. Przy przejściu z architektury monolitycznej na architekturę mikrousług trzeba podjąć właściwe decyzje dotyczące podziału – wszelkie błędy będą się później srodze mścić.
• Wersjonowanie. W praktyce często jedna usługa będzie działać w wielu kopiach, ale w różnych wersjach. Trzeba umieć nad tym zapanować.
• Organizacja. Skuteczne wdrożenie systemów opartych na mikrousługach wymaga często zmian organizacyjnych w firmie, która może być przystosowana do tworzenia oprogramowania w stary sposób.
• Inne problemy. Każda mikrousługa może być tworzona przy użyciu innych technologii, ale powinien istnieć jakiś spójny mechanizm logowania czy monitorowania takiego systemu – pojawia się pytanie jak uniknąć duplikowania narzędzi i procesów, a także jak to zorganizować żeby nie poświęcać temu zbyt dużo czasu i skupić się na funkcjach biznesowych aplikacji.

Czytaj więcej »

Z chmury Amazonu korzysta już ponad milion aktywnych klientów. Poniżej krótki opis co ciekawszych z przeszło 100 dostępnych obecnie usług AWS. Jest to uzupełnienie wcześniejszego artykułu na ten temat.

Moc obliczeniowa

AWS Lambda

Problem z instancjami EC2 jest taki, że kosztują nawet gdy nic nie robią i dodatkowo wymagają konfiguracji i pielęgnacji (choćby np. aktualizacji systemu operacyjnego). W AWS Lambda wrzucasz kod obsługujący zdarzenia — usługa sama podejmuje wszystkie czynności niezbędne do uruchomienia i skalowania kodu, nie wykonujesz działań administracyjnych. Płacisz jedynie za czas obliczeń – w szczególności nic gdy nie ma zdarzeń do obsłużenia. Zdarzenia mogą być wyzwalane z innych usług AWS lub z Internetu/aplikacji mobilnych/urządzeń IoT itp. Większość aplikacji i usług da się zaimplementować w architekturze Lambda.

Amazon EC2 Container Registry

Rejestr obrazów Dockera.

Amazon EC2 Container Service

Usługa zarządzająca kontenerami Dockera na klastrze instancji EC2.

Pamięć masowa

Elastic File System (EFS)

Sieciowy system plików, który w przeciwieństwie do EBS może być jednocześnie współdzielony przez wiele instancji EC2 i nie wymaga rezerwacji miejsca na dysku — płacisz za dokładnie tyle miejsca ile zapisałeś, a system plików rozrasta się praktycznie w nieskończoność w miarę jak zapisujesz kolejne pliki. Przy użyciu VPNa możesz podmontować wolumen EFS do swojej lokalnej sieci i traktować jak „wirtualny dysk w chmurze” o nieograniczonej pojemności, np. na użytek backupu.

AWS Storage Gateway

Pozwala w lokalnej serwerowni podmontować zasoby S3, Glacier i EBS Amazonu za pomocą protokołów NFS i iSCSI.

Czytaj więcej »

Jak duża jest dokumentacja chmury Amazona (AWS) i jak się mają do siebie – pod względem wysiłku potrzebnego do pełnego ogarnięcia – wielkości poszczególnych usług? Napisałem skrypt, który ściąga pliki PDF dokumentacji każdej usługi, zlicza strony każdego dokumentu (łącznie ponad 50 tys. stron!) i generuje wizualizację w postaci tzw. treemapy – pole powierzchni każdego prostokąta jest proporcjonalne do liczby stron dokumentacji na temat odpowiadającej mu usługi. Po najechaniu kursorem myszki nad prostokąt w dymku pokazuje się pełna nazwa usługi, jej krótki opis i liczba stron dokumentacji. Przy okazji można więc pobieżnie zaznajomić się z ofertą dostawcy chmury.

Patrz także pełny ekran.