fbpx

Dowiedz się jak AWS może pomóc przy budowie MVP…

Created with Sketch.

Dowiedz się jak AWS może pomóc przy budowie MVP…

kalendarz adwentowy 5

Paradoks Budowniczego

Zaraz po tym jak sprawdzisz swój pomysł na papierze, i przygotujesz BMC, o którym Kamila wczoraj napisała artykuł przychodzi czas na przygotowanie tego o czym mowa na tym płótnie.

Projektowanie jest cudowne. Greenfield jest taki wspaniały. W szczególności Ci, którzy pracują na co dzień w systemach zwanych brownfield mają w nowej rzeczywistości wszystko, czego im brakuje na co dzień. Wolność, możliwość eksperymentowania, stawianie sobie kolejnych wyzwań, ekscytacja nowym – to wszystko przyczyna dlaczego nasze inżynierskie mózgi uwielbiają nowości. Nie chodzi przecież o to, żeby króliczka złapać – pogoń daje nam adrenalinę i dopaminę.

Ale projektowanie trzeba w końcu zakończyć. Wydzielamy najmniejszy fragment naszego nowego produktu, który daje wartość grupie docelowej (tworzymy MVP – Minimum Viable Product) i rozbijamy go na mniejsze elementy, aby rozpocząć budowę.

I teraz w zależności od Twoich doświadczeń i nastawienia, oblewa Cię zimny pot lub ogarnia euforia. Jeśli na co dzień pracujesz w korporacji, oczami wyobraźni widzisz ile pracy przed Tobą, ile tematów trzeba ogarnąć, żeby wypuścić działający produkt. Ale jesteś świadomą osobą, wiesz co Cię czeka – po prostu czas wyruszyć pod tę górę.

Jeśli na co dzień pracujesz przy produktach, euforia bierze górę i zaczynasz przygotowywać plan, rozpracowujesz ważne szczegóły pomijając to co wydaje się nieistotne – i dobrze, dzięki temu masz mniejszą górę do zdobycia przez co łatwiej się na nią wspiąć. Ale w tej euforii często pomijamy ważne szczegóły – security, performance, reliability, evolvable architecture, quality. Twój produkt powstanie szybko, ale zaciągnięty dług techniczny zniweczy całe przyspieszenie, a nawet może przyczynić się do fiaska całego przedsięwzięcia (np. nietrudno sobie wyobrazić scenariusz, gdzie wyciek danych naraża Ciebie i Twoje „nowe dziecko” na pozwy).

W obu przypadkach mamy do czynienia z całym szeregiem wyzwań budowniczych produktów. O ile prościej byłoby, gdybyśmy mogli skorzystać z platformy i zestawu narzędzi, który zdejmie z nam z głowy wiele z tych problemów, dzięki czemu będziemy mogli skupić się na tym co stanowi najważniejszą część naszego produktu.

Oczywiście – Ci z Was, którzy kolejny raz przystępują do działania i chcą się skupić na dostarczaniu wartości dla klienta, mają w swojej skrzynce narzędziowej całą masę produktów typu SaaS lub Serverless (dla przykładu: Auth0 – uwierzytelnianie i autoryzacja, Stripe – płatności, Mailgun – programowe wysyłanie emaili, Zapier – automatyzacja i „klej” pomiędzy usługami itp.). Musimy jednak tą wiedzę mieć, sprawdzić te narzędzia oraz musimy nauczyć się ich obsługi (a każde z nich jest inne).

W takim przypadku, warto zastanowić się czy skorzystanie z pomocy gigantów nie będzie najlepszym co możemy zrobić, jeśli zależy nam na dostarczeniu produktu do grupy docelowej najszybciej jak się da.

Dlaczego w takim razie AWS?

Bo jest to firma, która w swoim motto i DNA, skupia się właśnie na budowaniu i dostarczaniu wartości. Jeśli spojrzymy na wartości Amazona na pierwszym miejscu jest Customer Obsession, co idealnie pasuje do tego co powinno przyświecać twórcom nowych produktów.

Image result for go build aws
„Go Build” to motto AWS. To prawdziwa platforma dla budowniczych, którzy pragną się skupić na tworzeniu produktu.

Tworzę ten artykuł gdy w Las Vegas odbywa się konferencja re:Invent – coroczne wydarzenie, gdzie ogłaszane są nowości dla platformy Amazon Web Services, ale i bez tego wiadomo, że ten konkretny dostawca chmury publicznej jest nie tylko liderem tego sektora, ale posiada najszersze portfolio produktów dostępne w jego ofercie.

Nie chodzi tylko o standardowe produkty które widzimy u każdego z dostawców chmury (compute, storage, networking), ale także i wysoce wyspecjalizowane usługi w gałęziach takich jak robotyka (AWS RoboMaker), Machine Learning (Amazon SageMaker), IoT i systemy embedded (Amazon FreeRTOS), stacje naziemne do komunikacji z satelitami (AWS Ground Station), narzędzia do budowy, skryptowania oraz dostarczania scen VR/3D (Amazon Sumerian) czy integracja z technologiami 5G (AWS Wavelength).

Mamy też do dyspozycji te bardziej typowe, takie jak wysyłka maili (Amazon SES), przechowywanie danych (Amazon S3), serverless (AWS Lambda), w pełni zarządzane platformy do konteneryzacji (AWS Fargate, Amazon Elastic Kubernetes Service), wysyłka powiadomień i webhooki (Amazon SNS), komunikacja z klientami (Amazon Pinpoint), uwierzytelnianie i autoryzacja (Amazon Cognito), testy na wielu urządzeniach mobilnych (AWS Device Farm) i tak mógłbym wymieniać jeszcze bardzo długo.

Z perspektywy osób tworzących nowe produkty, najważniejsze będą usługi, które są w pełni zarządzanie przez AWS oraz te, które reklamowane są jako Serverless. Dodatkowo, wiele z ważnych problemów, których nie chcesz rozwiązywać od nowo zostało przygotowanych w formie API, które są przystępne cenowo i łatwe od strony integracji. Przykładem może być wykrywanie nagości na obrazach za pomocą Amazon Image Rekognition, analiza sentymentu tekstu za pomocą Amazon Comprehend, usługi text-to-speech z użyciem Amazon Polly, automatyzacja konwersacji w chatbotach z użyciem Amazon Lex, analiza dokumentów i OCR z użyciem Amazon Textract, algorytmy personalizacji (Amazon Personalize), przewidywania trendów (Amazon Forecast) i oszustw (Amazon Fraud Detector) czy w pełni programowalne contact center z użyciem Amazon Connect.

I pomimo mnogości usług, większość z nich obsługujemy w podobny sposób – szczególnie mam tu na myśli programowe zarządzanie od strony API, jak i narzędzi Infrastructure as Code. Większość z nich integruje się ze sobą bez problemów, pokrywając najważniejsze potrzeby i wymagania. Oprócz tego, mamy szereg serwisów, które pozwalają na łączenie usług ze sobą w prosty sposób – niekoniecznie z wymaganiem, że musimy umieć programować.

Możesz powiedzieć: no dobra, ale ja nie chcę się uczyć nowego dostawcy, jeszcze o tak szerokim ekosystemie – ja tego nie potrzebuję. To po części prawda, większość pomysłów nie potrzebuje więcej niż kilku usług połączonych razem. Jeśli to Ci wystarcza – korzystaj i buduj, przecież dokładnie o to nam chodzi z MVP.

Natomiast miej na uwadzę, że jeśli chcesz w przyszłości ewoluować z tym produktem, może warto zainwestować odrobinę więcej czasu i zbudować ten produkt w oparciu o usługi AWS. Tak, żeby skorzystać z ramion gigantów i wspiąć się wyżej. Jeśli nie wszystko rozumiesz, albo masz wątpliwości – spróbuj poszukać wśród kontaktów. Może masz znajomego architekta/pasjonata AWS, który chętnie Ci pomoże (a jeśli nie, to napisz do mnie – chętnie Ci pomogę).

I na koniec dwa słowa o kosztach. Pewnie masz wątpliwości, bo to pewnie musi słono kosztować. Zakładam, że jeśli jesteś tutaj, to nie masz jeszcze konta na AWS (a nawet jeśli masz, nic nie stoi na przeszkodzie, żeby założyć nowe) – tuż po założeniu konta, w przypadku wielu wymienionych serwisów masz do dyspozycji tzw. free tier czyli darmowe zasoby do wykorzystania przez co najmniej 12 miesięcy, a bardzo przez nielimitowany czas (przykład: pierwsze 50 000 aktywnych użytkowników w skali miesiąca jest darmowych w usłudze Amazon Cognito). Znając cenniki i można naprawdę zbudować znaczne aplikacje, które będą produkcyjnie używane i nic nie płacić, lub zapłacić przysłowiowego „dolara na miesiąc”. Dodatkowo, jeśli uważasz, żę Twój pomysł jest wartościowy, możesz spróbować odezwać się do partnerów AWS w celu uzyskania wsparcia w postaci środków (tzw. credits) na przygotowanie Proof of Concept lub nawet udział w programach akceleracyjnych (AWS Activate).

No to jak? 😉 Zabierasz się za budowanie swojego MVP na AWS, czy masz jeszcze jakieś obiekcje, których tutaj nie poruszyłem.