Jak jsem technologicky postavil startup

Tento příběh pojednává o technologiích, nástrojích a vůbec o všem, co jsem potřeboval k tomu, abych byl schopen, postavit startup na zelené louce.

Každý správný příběh začíná stejně: "Jednou jsem...."

Kapitola první: Nápad

Jednou jsem se setkal s člověkem, který měl nápad na produkt, který se v průmyslu zatím nevyskytuje. I přes prvotní skepsi, kdy jsem si říkal: "Tohle už přeci dávno v průmyslu existuje, ne?", jsem došel ke zjištění, že nikoli.

Tím jsem se dostal ke svému prvnímu poučení. Průmysl je technologicky dost zabržděný. Osobně se domnívám, že těch důvodů, proč tomu tak je, je několik. Za prvé je to fakt, že většina lidí, kteří se pohybují v tomto odvětví jsou často konzervativní a za správné považují pouze léty osvědčené věci. Druhým důvodem je to, že jakákoli změna znamená riziko. Ať už z pohledu finanční ztráty tak i z pohledu stability výroby. No a třetím a nejzásadnějším důvodem je to, že ač zde máme spousty technologických vymožeností, narážíme na to, že je obrovský nedostatek lidí. Tedy nejsou programátoři a další specialisté, kteří by dané vymoženosti transformovali do reálné praxe.
Budoucnost nám jistě nabídne spousty nových a zajímavých produktů a jediné, co nás bude brzdit je pracovní síla, která by dané produkty oživila.

Ale zpět k nápadu.

Pochopil jsem, že tohle by mohlo být ono. Zajímavý produkt, postavený na jednoduchém principu. I když zde budete očekávat, že Vám blíže popíši onen nápad, musím Vás zklamat. Neudělám to. Důvodem ani není to, že bych to chtěl tajit, ale spíše to, že tento příběh není zrovna dobrou platformou, kde bych chtěl zabíhat do těchto detailů. Jen zmíním to, proč jsem se rozhodl, opustit projekt, na kterém jsem v té době pracoval a šel do neznáma, které sebou přináší velké riziko neúspěchu.

Tím důvodem byla pouze jediná věc: "Jednoduchý nápad". Co to znamená? Pokud máte nápad na startup, tak platí jedno pravidlo. Měli byste být schopni jednou větou, nebo ještě lépe, pár slovy popsat, o co vlastně jde. Pokud to nelze, máte bud špatný nápad, nebo jste stále nebyli schopni svůj nápad uchopit tak, jak byste měli.

A nyní už více zůstanu u technologií a nástrojů.

Onen nápad znamenal následující:

1. Napsat android aplikaci
2. Napsat server aplikaci
3. Napsat webovou aplikaci
4. Současně s tím myslet na to, že aplikace musí být multitenantní a v cloudu.

Kapitola druhá: Nástroje

Ještě před tím, než jsem se pustil do prvních proof of conceptů, jsem si navrhnul nástroje, které budou pro takový projekt stěžejní.

Prvním nástrojem, který jsem věděl, že bude bezpodmínečně nutný je repozitář kódu.
Ať už projekt bude v Jave, PHP či Perlu, vždy potřebujete někde uchovávat svůj kód. Samozřejmě, že volba byla jasná: Git. Proč volit něco jiného, když Git už znám a vím, že splní všechny moje požadavky.
Po prozkoumání dostupných možností, jsem nakonec zvolil BitBucket. Jednak z důvodu toho, že i zdarma umí privátní repozitáře a jednak i pro to, že v rámci ekosystému se mi hodilo to, že od stejné firmy máme i další nástroje.

Druhou nutnou věcí byl tracking systém.
Ať už pro bugy, tak i pro samotný vývoj. Nechcete přeci tyto věci udržovat v excelu, mailu či si psát vlastní systém. Zde byla volba velice jednoduchá. Asi nikoho nepřekvapí, že volba padla na Jiru.
Jira splňuje opět všechno, co potřebuji. Mohu ji provozovat v cloudu, aniž bych musel hloupě instalovat systém na vlastním železe a současně s tím pokrývá velkou část důležitých aspektů. Jednak je to zmíněný tracking pro bugy, ale také možnost Jiru využít pro plánování, ať už pro SCRUM či vlastní upravenou metodiku.
Třešničkou na závěr je samozřejmě propojení BitBucketu s Jirou a tím k jednotlivým ticketům přiřazovat commity z GITu.

Třetím nástrojem byla znalostní databáze, nebo chcete-li wiki. 
Jelikož jsem od Atlassianu využíval BitBucket a Jiru, tak volba byla opět jasná. Confluence. Proč používat něco jiného? Confluence znám a navíc vím, že mi třeba umožní zobrazení dat i z Jiry. Stejně jako u předešlých nástrojů, je opět možné Confluence využívat jako službu v Cloudu a proto není stále nutné mít vlastní servery.

Čtvrtým nástrojem byl komunikační kanál. 
Jestli někdo očekává něco ve stylu: "Máme přeci mail, tak pořídíme vlastní mail server či gmail pro firmy, musím ho zklamat." Mail je jeden z nejhorších možných komunikačních kanálů a využití tohoto nástroje jsem se rozhodl minimalizovat na jeho nutnou potřebu.
Jako komunikační kanál jsem zvolil Slack. Znáte Slack? Ne? O hodně přicházíte. Nechci zde rozepisovat, co všechno Slack umí, ale vyjmenuji pouze to, k čemu ho používámě my.
Tak za prvé je to samotná komunikace mezi uživateli. Chcete Frantovi napsat o nových poznatcích? OK. Napiš mu přes chat. Chceš, aby to viděl i Pepa? Pozvi ho do konference a založte si vlastní místnost. Chceš někde projednávat pouze technické věci? Založ místnost a pozvi lidi, kterých se to týká. Sdílej ukázky kódu, apod. Slack toho nabízí skutečně hodně.
Dalším důvodem, proč Slack, je jeho možnost integrace s ostatními systémy. Nejprve jsem integroval Slack s Jirou. Skvělé, mám možnost si přes Slack prohlížet Jira tickety. Nic složitého.
Další integrací byl samotný BitBucket. Chci notifikace o tom, co se děje v GITu? Není problém, přihlásím se o notifikace a vídím, že Franta provedl commit do GITu, kterým rozbil celý build.
Slack stále nemusím instalovat a mohu ho využívat jako službu v Cloudu.
Stále nepotřebuji vlastní server. Díky bohu.

Pátým a posledním nástrojem je testing tool.
Nejsme neomylní a mít nástroj na zápis testovacích scénářů a současně s tím, mít možnost vyhodnocování jednotlivých exekucí testů, je tedy nutné.
Testovacích nástrojů existuje nepřeberné množství.
Nejdříve jsem se vydal slepou uličkou a tou byly ruzné pluginy do Jiry. Bohužel jsem se dostával do stavu, že plugin byl buď nefunkční a nebo byl dost neefektivní. Nakonec jsme skončili u TestTrail. Jednoduchý nástroj na tvorbu testovacích scénářů a současně s tím i exekuci. Samozřejmostí je opět integrace na Jiru, kde Bug do Jiry vytvoříte přímo v TestTrail. Integrace je obousměrná. Tedy na samotném Jira ticketu máte možnost vidět exekuci z TestTrailu. Ideální. Co víc si přát.

Tím bychom měli samotné nástroje. Pojdmě dál...

Kapitola třetí: Google Cloud

Jelikož jsem na začátku zmínil, že samotná aplikace je multitenantní a v Cloudu, tak potřebujete sami nějaký Cloud, kde byste provozovali svojí aplikaci. Stavět si vlastní servery je stejné, jako se střílet do vlastní nohy. A to přeci nikdo nechce.
Variant, které připadají v úvahu je několik. Ať už zvolíte řešení od Amazonu AWS, Microsoftu Azure nebo Googlu, vždy uděláte dobře. Nakonec jsem zvolil Google Cloud. Důvod proč, není postaven tolik na rozumu, jako emocích. Jednak je to z důvodu toho, že mám firmu Google raději než třeba zmíněný Microsoft a jednak i pro to, že víc důvěřuji firmě, která má svůj hlavní byznys postaven na internetu a Cloudu.
Až později jsem zjistil, že Google do samotného Cloudu investuje nemalé peníze a rozvoj je téměř raketový. Jakožto roční uživatel, mohu sám potvrdit, že se opravdu snaží postupně nabízet a vypiplávat jednotlivé možnosti samotného Cloudu. To je skvělé.
Jednou z věcí, kterou na Google Cloudu skutečně miluji, je připojení na server pomocí SSH ve webu. Ano, ve webu. Není nic jednodušího, než kliknout na daný virtuální server, dát "SSH Connect" a v té chvíli se Vám otevře okno s konzolí samotného serveru. Už není nutné žádné otravné předávání SSH klíčů či jiného zabezpečení pro přístup k serveru.

Kapitola čtvrtá: Programovací jazyk a architektura

Možná by se hodilo tyto dvě věci od sebe odlišit, ale osobně si myslím, že daný jazyk dost ovlivňuje samotnou architekturu. Proto psát o těchto věcech rozděleně, nedává smysl.

Jakožto javista jsem měl volbu jasnou. Backend bude na Tomcatu se Springem, JPA a nějakou relační databází. Webové API bude REST. Frontend udělám Angularem či Reactem a mobilní aplikaci hezky v Jave přes Android Studio.

Tak jsem se pustil do práce. Napsal jsem backend přes Spring Boot a Spring Data REST. Databázi jsem zvolil MySQL s tím, že bude možné jí změnit v případě "požadavků". Přeci jen mám JPA, ne? :)
Současně s tím jsem napsal Android aplikaci, která dělala to, co jsem potřeboval. Fungovala na principu, na kterém jsme se na začátku domluvili.

Poté přišel na řadu web.

Teď bych mohl napsat o tom, jak jsem zvolil Angular či React a napsal SPA webovou aplikaci. Jenže zde něco končí a něco nového začíná....

Měl jsem zkušenosti s Angularem 2, ve kterém jsem si napsal aplikaci, která mi pomáhala, jako team leaderovi, vyhodnocovat skutečnost. I když byl Angular 2 v alfa verzi, tak mi to nevadilo. Nešlo o kritickou aplikaci.

Jenže shodou okolností jsem se v té době dostal k přenášce dvou mladých kluků, kteří, ač angularisti, začali hrozně shazovat Angular a velebit React. V té době jsem React znal spíše teoreticky. Veděl jsem, že má virtuální DOM a že bla bla bla...
Jenže oni mě tak moc nahlodali, že jsem se rozhodl, že do toho proniknu více a frontend tím Reactem přeci jen napíšu.

V té době u mě došlo k tomu, že jsem se zamiloval. Ne, slečna to nebyla, tu už jsem měl :) Ale došlo k tomu, že jsem jednak našel krásu v Reactu, ale hlavne ve funkcionálním a deklarativním programování. Na to jsem z Javy nebyl příliš zvyklý. Přeci jen, i když již existovala Java 8 (lambda funkce), tak většinou nemáte moc možností se s ní setkat.

A tak jsem začal přemýšlet, zda bych javascript nemohl využít i jinde. A ono to šlo! Najednou jsem zjistil, že existuje něco, co se jmenuje React Native a že vlastně i mobilní aplikaci mohu napsat stejnou technologií. A jelikož jsem od přírody liný člověk, tak jsem si řekl, že se přeci nebudu učit více věcí najednou, když mi stači jedna s drobnou obměnou.

A tak došlo k tomu, že jsem zavřel Android Studio, smazal projekt v Jave a přepsal ho do React Native. A vše fungovalo. I to zatracené Bluetooth LE mi v Reactu šlapalo.

Poté přišel na řadu backend. Web a mobil mám v javascriptu/typescriptu a backend v Jave. A v té době mi z nějakého neznámého důvodu začala Java vadit. Sakra, psal jsem v tom jazyku více jak 9 let a měl jsem ten jazyk skutečně rád. Jednoduchý, staticky typový a navíc na server aplikace ideální volba. Jenže v té době jsem objevil další Facebook technologii. GraphQL....

Psát o tom, co je GraphQL není předmětem tohoto příbehu. Jen v rychlosti řeknu, že Vám umožňuje napsat webové API tak, jak byste v RESTu či SOAPu nikdy nebyli schopni. Deklarativně a s možností si psát vlastní dotazy do API, kterým budete říkat, co vlastně chcete vrátit.

Tak došlo na první fázi. GraphQL v Jave. Po zjištění, že pro GraphQL existuje knihovna i do Javy, jsem zajásal. Ale jen do doby, než jsem pochopil, že to je asi jako kdybyste traktor pomalovali jako závodní auto. Zjednodušeně řečeno, díky samotnému deklarativnímu zápisu GraphQL to bylo dost neefektivní.

A jelikož jsem se rozhodl, že GraphQL se už nevzdám, tak jsem musel, se slzou v oku, celý java backend zahodit a přepsat ho pomocí Node.JS/Express. Výsledkem bylo, že jsem měl asi desetinový kód, který toho ve výsledku uměl víc, než v samotné Jave.

Timto jsem se rozloučil s Java světem a stal se už pouze nezávislým pozorovatelem. Jazyka, na kterém jsem sám vyrostl a který jsem považoval za nejlepší variantu na backend.

Výsledkem bylo, že jsem získal "full stack", který používal stejný jazyk na všech úrovních. Díky zaplacenému NPM serveru jsem si začal tvořit vlastní privátní balíčky, které poté sdílel mezi mobilem, webem a serverem.

Ideální kombinace. Funkcionální programování je zábava a navíc je o tolik efektivnější.

V té době se ze mě stal evangelista javascriptových technologií a současně s tím i fanatik, který vyznává pouze jednu pravdu :)

Kapitola pátá: Deployment

Co by to bylo za systém, kdyby neuměl automaticky nasazovat aplikaci na server?

První věcí, kterou jsem k tomuto účelu začal využívat je Jenkins. Jenkins je nástroj pro continuous integration. Uložíte projekt do GITu a on provede nějakou událost. Ať už je to spuštění buildu, testu či samotný deploy aplikace.

Jenkins má spoustu výhod a spoustu nevýhod.
Jednou z velkých nevýhod, alespoň pro naše učely, je to, že na svou robusnost nepřináší tolik výhod. Tím myslím to, že sice přes něj mohu provádět všechny potřebné úkony, ale musím si ho nainstalovat na vlastní server (samozřejmě v Google Cloudu), ale za cenu toho, že musím nakonfigurovat mraky věcí.

Po zralé úvaze jsem Jenkins server smazal a přešel na BitBucket Pipelines.
Co jsou to vlastně Pipelines? Je to takový jednoduchý Jenkins, který na základě změny v GITu, může vykonat událost. Tou událostí může být opět cokoli. Kromě toho, že díky BitBucketu, máme Pipelines zadarmo, tak je i možné Pipelines integrovat se Slackem, takže opět win/win.
A jelikož se vracíme k původní myšlence, že naše aplikace má být v Cloudu a multitenantní, tak samotný deploy aplikací musíme nějak rozumně řídit. A k tomuto účelu nám stejně nemůže sloužit ani Jenkins, ani Pipelines, ale něco jiného.

Třetí a nejlepší variantou je vlastní aplikace, hlídající deployment, servery či stav v GITu. Nechci přesně rozepisovat, jak to funguje, ale vychází z jednoduché myšlenky, která říká: "Chci mít možnost, na jednoduchý klik tlačítka nasadit verzi X/Y na server A a přitom kontrolovat, že server A je v té či oné verzi a je na to připraven."

Kapitola šestá: Shrnutí

Rozepisovat o všech technologiích a knihovnách, které používáme, by bylo příliš vyčerpávající a asi i nudné. Jednou z věcí je třeba error tracking systém přes Sentry.io, který nám hlídá stav aplikací. Ale o tom někdy příště v samostatném článku.

Výsledkem mého snažení bylo několik věcí, které teď v bodech shrnu:

1. Unifikované prostředí pro vývoj
2. Jednoduchá správa
3. Rychlá adaptace vývojářů, testerů
4. Využití moderních technologií, které jsou přínosné
5. Připravit firmu na větší počet zaměstnanců v IT
6. Schopnost řídit systém jak technologicky tak projektově
7. Minimalizovat náklady na vývoj

Závěrem jedno doporučení. 

Zda chcete vědět, jak správně navrhovat aplikace či celé technologické firmy, musíte mít hlavně zkušenosti s tím, jak to nedělat.