- http://michalostruszka.pl/blog/2014/05/18/geecon-2014-braindump/
- http://tomaszdziurko.pl/2014/05/geecon-2014-brain-dump-day-1/
- http://tomaszdziurko.pl/2014/05/geecon-2014-brain-dump-day-2/
Zwykły acz niezwykły slajd
Powyższy slajd zaprezentował Sam Newman podeczas swojej prezentacji o Mikroserwisach.
To jest arcyciekawy slajd gdyż jedzie walcem po pseudo-perfekcjonistycznej nasyconej strachem przed porażką kulturze wielu korporacji. Tutaj jest wyraźnie narysowane, że będziemy testować po deployu i trzeba się szykować na ewentualną "cofkę". Na slajdzie użyte jest słowo remediation zamiast rollback ale chyba chodzi mniej więcej o coś podobnego.
Problem polega na tym, że jak coś wrzucimy na produkcję a później się cofamy to metryki stoją w miejscu. W tematyce samorozwoju istnieje takie pojęcie jak learning experience co też trochę trąci bullshitem ale jednocześnie ma za zadanie pokazać, że pewne zdarzenia owocują jedynie niematerialnym zastrzykiem wiedzy, który generuje zmiany w połączeniach neuronowych - niestety nichuja z tego nie da się wyrysować fajnego wykresu do powerpointa na spotkanie.
Jakby np. wyglądała nauka jazdy na rowerze według korpo procesu? Najpierw potrzebny jest jakiś ambitny target metodą smart więc jebnijmy sobie "przejechać 100m", co zostanie zmienione na "100km" przez innego managera posługującego się formułkami "push harder" i "reach higher". Teraz koleś wsiada na rower i gleba. Jego mózg przetwarza nowe informacje jak tu się utrzymać na dwóch kółkach ale zanim będzie miał okazję wsiąść na rower musimy odbyć meeting dlaczego się nie udało, "This situation makes me very concern" i inne takie "postmortem analysis".
Dobra, koleś siada drugi raz - 5 metrów i znowu gleba. Trzeba zrobić meeting z "root cause anlysis" dlaczego wciąż ponosimy porażki - a przecież ponosimy porażki bo według flow chartu rower stoi w miejscu a przecież na kursie z zarządzania pan Zdzichu wyraźnie mówił, że jak "stoimy w miejscu to się cofamy".
I tutaj nagle na dużej konferencji pojawia się slajd, który mówi, że to w sumie dobra opcja wyskoczyć do świata rzeczywistego, zebrać rzeczywiste info z tego świata rzeczywistego i ewentualnie się wycofać - "Reality driven development".
I nawet ci ludzie od robotów odnieśli spektakularny sukces bo zdobyli niesamowicie cenną wiedzę "co może pójść źle w czasie prezentacji" - i teraz jak wyskoczą przed potencjalnych inwestorów maja szansę zabłysnąć.
Apropo robotów to nawet one były najebane.
Do rozwiązania ponadto pozostaje standardowy problem wszystkich konferencji IT czyli blokowanie się wątków przy wejściu do męskiego kibla.
Hmmm, zastanawia mnie koncepcja "reality driven development". No bo jak tu powiedziec klientowi (zewnetrznemu czy wewnętrznemu), czasem tez partnerom, z ktorych systemami sie integrujemy, ze nasza najnowsza aplikacja nie przeszla "testu reala", i musza zrollbackowac swoje systemy, procesy i kampanie marketingowe i poczekac az sprobujemy ponownie za 3 sprinty...
OdpowiedzUsuńKoncepcja pasuje mi do startupow, ale ktos musialby mi opowiedziec cos wiecej jak to zrobic gdy wchodza w gre zaleznosci i powiazania wielu roznych osob/dzialow/firm.
Tutaj raczej chodzi o to abyś to ty zrolbakował i im nie rozjebał, bo z UMLa mogło ci nie wyjść jasno, że im rozjebiesz. Sukces? Koleś ma niedługo wydać ksiażkę i tam powinno być więcej info -
OdpowiedzUsuńhttp://shop.oreilly.com/product/0636920033158.do
Ano i to nie jest wpis o mikroserwisach bo ten jeden slajd wyjęty z kontekstu był tylko wymówką do rozważań bardziej filozoficznych o naturze pewnych środowisk z przerysowaniem cech negatywnych i wygląda na to, że nie napisałem tego jasno co kategoriach korporacyjnych może oznaczać, że poniosłem porażkę ;)
UsuńPoza tym z tego co zrozumiałem, te mikroserwisy są dlatego "mikro", że zostały pomyślane w ramach jednej aplikacji by móc je niezależnie rozwijać i wdrażać. Także twój przypadek to inna skala i zupełnie inne problemy,wyzwania oraz rozwiązania.
Ja np. mam w jednej aplikacji cały czas architekturę "przed amazonową" - czyli duże monolityczne wary - co oznacza, że jak chcę zmienić coś w wysyłaniu maili to raczej trzeba będzie deployować całą paczkę - a że paczka ma sesje i zapisuje dane do bazy to sobie tak zwyczajnie endpointa nie przełączę i jest downtime. Jest to dosyć słabe dlatego ta opcja z mikroserwisami jest dla mnie bardzo ciekawa.
Jakkolwiek nie o tym miał być ku*wa ten artykuł ;)