IT technologie v roce 2019

Zkusili jste někdy předvídat budoucnost? Není to jednoduché, že? Svět se mění a změny přicházejí rychleji a častěji.  Pokud se pokusíte odhadnout technologické trendy budoucnosti, tak ke zkušenostem a znalostí z oboru je potřeba přidat důležité, ale nevyčíslitelné zrychlení. Co tím myslím?

Třista let v prvohorách neznamenalo ve vývoji téměř nic. Za to třista let mezi 13. a 16. stoletím znamenal významný posun znalostí a vědomostí lidstva.V období mezi 17. s 20. stoletím se vše ještě zrychlilo a posunulo lidstvo do moderního věku. Stejný časový úsek a čím dál tím rychlejší změny. A to samé platí i na kratší období, než jsou stovky let. Nevěříte?

Teenager který se narodil v roce 1989 žil v modernějsím světě, oproti tomu výrostkovi, který se narodil  v letech padesátých. Svět padesátých a osmdesátých let byl jiný, ale teď si představte dnešního teenagera  jak se dostane do roku 89. Bez internetu, mobilů, osobních počítačů, tabletů, GPS, sociálních sítí. Kluk ze současnosti se bude cítit více v “pravěku”, když by se propadl o třicet let zpět, než ten komu by se to podařilo dříve.

Takže pokud byste před třiceti lety předpovídali budoucnost a vycházeli z toho co vše se událo od padesátých let tak kompletně minete, protože rychlost změn neúprosně vše mění.

Ja se pokusím odhadnout jak se asi v roce 2019 změní pár IT technologií. Jako produktový člověk bez vize bych dlouho nepřežil, ale obávám se, že má představivost nebude dostatečně odvážná na ty změny, které nás čekají.

Softwarový vývoj a IT odbornost

S tím jak jsme vstoupili do nového roku 2019 tak je evidentní, že bude pokračovat hlad po rozšířených zkušenostech a znalostech vývojářů a IT odborníků. Odpovědnost a požadavky na ně se stále zvětšují. Důležitá je nejen znalost ”své” technologie, ale i umění řídit a znát celý cyklus výroby a provozu aplikací. Důležité pro ně letos  bude schopnost pochopení potřeb zákazníků a schopnost s ními komunikovat a předávat si znalosti navzájem mezi sebou. To firmám přináší tolik požadovaný “time to market” a zákazníkům kvalitu.

Letos je velká příležitosti pro ty, kteří dokáží myslet a pracovat v širším kontextu než je jedna role. Také to bude znamenat větší rivalitu a snahu přetáhnout takové zaměstnance mezi společnostmi.  Firmy již dnes vynakládají velké prostředky na nábor a udržení zaměstnanců, ,kteří dokážou splnit zadání a to je být “inženýrem celého vývojového cyklu”. Zdá se mi, čím dál tím více, že specializace na jeden obor nestačí. Je potřeba umět “svoje řemeslo” a současně mít značný přesah.

Kontejnery

Pro kontejnerizaci aplikací byly minulá léta dost divoká. V roce 2018 se situace začíná stabilizovat.  Dvě technologie se dostávají do popředí, jako “defacto” standard. Je to kontejnerová technologie Docker a orchestrace kontejnerů Kubernetes. To, že se zdá že tyto technologie zvítězily ukazuje i 8000 učastníků Kubeconu v prosinci 2018 v Seattlu. Je potřeba také zmínit, že většina nadšení pochází od vývojářů aplikací a provoz IT se s nástupem kontejnerizace dosud plně nevyrovnal.

Rok 2019 vidím jako rok, kdy kontejnery a Kubernetes překročí hranici oddělující vývoj od IT provozu a nadlouho se usadí v IT prostředích středních a velkých firem. Technologie už dozrála do bodu, kdy bezpečnost a shoda se standardy je téměř vyřešena a tak je cesta do datacenter otevřena. Stejně tak, je zde příležitost poskytnout tyto technologie v podobě služeb cloudu nebo jako spravovaného prostředí.  Stále však přetrvává komplexita a náročnost kontejnerizovaných prostředí. Zde vidím v letošním roce prostor pro zlepšení a zpřístupnění exponenciálně více uživatelům než dnes. Kubernetes dozrál do bodu, kdy jsem si jist, že uvidím mnoho realizovaných projektů v produkčním prostředí.

Data

Data stále zůstávají nejcennějším aktivem co firmy vlastní. Samozřejmě, že objem dat bude růst, nicméně ve větší míře se na nich bude projevovat strojové učení a  umělá inteligence. Čím více budou aplikace provozovany v microservice prostředích tím bude potřeba analyzovat dostupná data a telemetrie aplikací a jejich chování bude vyžadována čím dál tím více. Očekávám také v letošním roce méně experimentování s proprietárními “data lake” systémy a více využívání opensource nebo cloud nástrojů provozovaných v IaaS nebo PaaS prostředích. Rok 2019 bude generovat na velkou poptávku po kvalifikovaných inženýrech v oblasti zpracovaní a nalýzy dat, kteří jsou v této vlně inovativního přístupu k datům rozhodující.

DevOps

Ze schopnosti spojit několik oddělení a dohodnout se jak nejrychleji nasazovat aplikace tak, aby přinesly obchodní výsledky se pomalu stává klasický “buzzowd”. Motivace spojovat teamy a nástroje napříč přišla od velkých společností. Vynutila si to potřeba provozu rozsáhlých microservice systémů, kdy jsou desítky nových verzí denně nasazovány s co nejvyšší diskrétností a  bez vědomí uživatelů. Rozsáhlé aplikace nejen, že musí fungovat, ale hlavně plnit obchodní zadání a snižovat čas potřebný k tomu aby se inforace dostaly ke koncovým uživatelům.

Ve světě výrazně menších společností to v roce 2019 bude o položení si otázky: “Jsme schopni udělat nový release aplikace alespoň jednou denně nebo kdykoliv kdy je potřeba tak abychom získali konkurenční výhodu?” Myslím, že každý kdo je odpovědný za vývoj a provoz by si letos tuto otázku měl umět zodpovědět. DevOps není univerzální řešení nebo technologie, ale schopnost reagovat na cíle vlastní firmy. Letos toto čeká střední a někde i menší firmy. Stejně tak jako čím dál tím větší dilema zda zůstat u monolitického vývoje, anebo vše pomalu změnit a začít vyvíjet cloud native aplikace

Open Source

Do Open Source světa vkročila doba konsolidací a nákupů, které by před pár lety nikdo nečekal. V končícím roce 2018 překvapila IBM koupí RedHatu a tim díky jejich OpenShiftu získala nečekaně silnou pozici v oblasti kontejnerů. Microsoft nakoupil GitHub a stal se de facto nepřímým “influencerem” milionů Open Source projektů. VMware si nechal odejít klíčové zaměstnance na poli Kubernetes, aby o něco později jejich firmu Heptio koupil a začlenil do svého portfolia. Předpokládám, že doba nákupů a konsolidací open source projektů ještě nekončí a obzvláště zajímavé dění vidím v roce 2019 v oblasti Kubernetes a jejich nástrojů pro lepší správu nebo monitoring.    

Aplikace umělé inteligence (Artifical Inteligence) a strojového učení (Machine Learning)

To, že by opadl zájem o umělou inteligenci asi nečeká nikdo. Naopak, témata související s neuronovými sítěmi a deep learningem se staly předmětem nejedné debaty u piva. Pokud se však podívám na svět pohledem AI realisty, tak ve firmách vidím více slov než reálných aplikací. “Je impozantní jak umíme rozeznávat objekty na fotografiích, ale jak to dnes mohu reálně využít u mě ve firmě?” Běžná otázka, kterou si pokládám vždy, když se rozhoduji zda investuji čas a zdroje u nás do AI. Zatím AI vždy odložím, s vědomím, že ještě počkám a uvidím. Ano mohu analyzovat logy a dělat prediktivní statistiky, ale ještě to není ten pravý “business driver”.  Věřím tomu, že v následujícím roce, bude docházet k masivním investicím do společností, které vytváří produkty reálné aplikace strojového učení. Stejně tak předpokládám veliké investice firem do lidí, kteří problematice rozumí a do jejich znalostí. Stejně tak tuto oblast čeká veliký boom a to skoro ve všech sektorech podnikání. AI nás nemine. Rád bych teď měl křišťálovou kouli a mohl se podívat třeba na oblast čtení lidských myšlenek a uvidět jak moc se tato oblast za rok posune.   

Blockchain

Zdá se, že minulý rok, blockchain narazil na bariéru ve finančním sektoru. FinTechové společnosti stále hledají cestu jak blockchain využít pro transakce, ale velké finanční ústavy se této technologií spíše vyhýbají, i když navenek se tváří jinak. Kde blockchain nachází uplatnění jsou dodavatelsko odběratelské řetězce. Zajímavá je řešení dua Maersk a IBM s názvem TradeLens, které využívá blockchain pro spojení hlavních světových přístavu a nabízí všem zapojeným subjektům, včetně celních orgánu, jednotný pohled a kontrolu nad dopravou nebo nad stavem zásilky včetně i takových dat jako jsou regulace teploty přepravních kontejnerů a nebo informace z různých senzorů. Sledování informací celého dodavatelského řetězce bude téma blockchainu i pro rok 2019. Spotřebitelé budou mít větší jistotu, že to co objednali opravdu obdrží a dodavatelé mohou důvěryhodně identifikovat a sledovat jednotlivé položky po cestě k zákazníkovi. Opět zde vidím prostor pro startupy, které dokáží správně identifikovat a doručit hodnotu blockchainu v této oblasti.

Lokální datacentra a cloud

Můj primární zájem a také, místo kde jsem nejvíce ve střetu zájmů, ale pusťme se do toho. Kde kdo by očekával, že lokální datová centra zmizí a vše v bude v cloudu. Nemyslím si to. Vidím spíše transformaci a změnu určení zákaznických datacenter. Dnes je hlad po výkonu větší než kdykoli dříve a provoz AI/ML, BI nebo obdobných analytických nástrojů je v cloudu drahé.  Věřím, že lokální datacentra se budou měnit na místa s specializací. To znamená, že běžné aplikace jsou již v cloudu a ty které ještě nejsou sem přijdou, ale stejně tak je třeba si uvědomit. že hybridní spojení mezi cloud poskytovatelem a lokálním datacentrem bude čím dál více důležitější. Bude vyhrávat ten, kdo dokáže navrhnout a levně provozovat lokální datacentra spojená s cloud prostředími.  Nicméně je třeba si uvědomit proč tomu tak je a jak moc se určení firemních datacenter mění.

Společnost G2 server změnila jméno na Geetoo a představila i nové logo

Cloudový provider společnost G2 server změnila s koncem roku původní jméno i logo a nově působí na trhu jako Geetoo. S novým názvem bylo představeno i nové logo z dílny přední české agentury Symbio,  nové webové stránky a spouští se cloudová platforma Geetoo Space.

„Z původně malé české firmy G2 server se postupem času s rostoucím počtem zákazníků a narůstajícím množstvím technologií stává mezinárodní cloudový provider. Dosavadní název G2 server se začal postupně stávat limitující, nereflektoval nejmodernější technologie a inovativnost společnosti. Navíc s plánem stát se evropským providerem cloudu s portfoliem jak pro provozovatele infrastruktury, tak i pro softwarové vývojové týmy, začalo docházet k nejednotnosti v rámci výslovnosti dosavadního názvu G2 server za hranicemi České republiky. Proto k rozhodnutí přejmenování názvu společnosti z G2 server na Geetoo došlo,“ upřesňuje CEO společnosti Vladimír Kvaš.

„Poměrně dlouho jsme hledali cestu, jak zachovat kontinuitu s historií společnosti a zároveň se představit v novém, mezinárodním a moderním stylu, a to jak samotným názvem společnosti, tak v rámci vizuální komunikace. Nový název Geetoo je ve skutečnosti anglickým názvem dosavadního jména G2. V rámci vizuální komunikace zůstala společnost u hlavní barvy tyrkysově modré, ke které přibyla nově i malinově červená,“ uvedla ke změnám Eva Čerešňáková, marketingová manažerka společnosti.

K novinkám Geetoo patří i vlastní cloudová platforma Geetoo Space, kterou produktové oddělení společnosti představí detailněji v následujících týdnech. 

Společnost G2 server byla založená v České republice v roce 2004 a zaměřuje se na cloudové technologie a poskytování cloudových služeb. V současné době má Geetoo datacentra ve čtyřech evropských státech a působí již v několika zemích. Geetoo nabízí řešení a služby jak zákazníkům ze segmentu SMB, tak enterprise společnostem nadnárodní úrovně. Podle společnosti VMware patří Geetoo mezi nejrychleji rostoucí cloud providery v regionu CEE. Go-to-market model je pomocí partnerské sítě a v rámci nového partnerského programu nabídne Geetoo svým partnerům mnoho výhod. Vizí společnosti je přinést jakoukoliv cloudovou službu, umístěnou v datacentru nebo ve firemním IT zákazníka, ovládanou pomocí jednoduché platformy Geetoo Space s konzumací po celém světě.

The Twelve-Factor Application

Cesta k úspěchu při provozu aplikací v cloudu

Už nějakou dobu je známo, že G2  nabízí Kubernetes v cloudu zákazníkům. Upřesním-li, Kubernetes v beta testu. Postupně přicházejí zajímavá témata a zkušenosti z provozu. Jedno z častěji diskutovaných je o tom, jak vlastně upravit nebo napsat aplikace tak, aby byly co nejlépe provozovatelné v Kubernetes prostředí.

Faktem je, že dnes je téma kontejnerů a jejich orchestrace velmi populární. Téměř všichni o něm hovoří či o něm už slyšeli a nebo dokonce vědí, že Kubernetes se za poslední dobu stal “de-facto” standardem na poli kontejnerové orchestrace. I přes to, že pojmy jako cloud native aplikace a mikroservices nejsou nijak nové, ne všichni je znají. Přitom pochopení základních principů ulehčí zpravidla provoz a nasazení aplikací. Stejně tak šetří výpočetní zdroje, což při provozu v cloudu přímo snižuje finanční nákladnost.

Dobré znalosti a zkušenost mají vývojáři, kteří se již s cloud native vývojem setkali.  Ne však ti, kdo přecházejí z virtuálních serverů na kontejnery.

Jednou z osvědčených cest je metodika pocházející původně z PaaS služby Heroku: “dvanáctifaktorová aplikace.”  The Twelve-Factor Application. Jedná se o sadu dvanácti doporučení.
Pokud se jich budete při návrhu a vývoji držet, velmi si zjednodušíte práci a předejdete nejběžnějším problémům při nasazení aplikace do cloudu.

Není potřeba, abyste si všechny zapamatovali jako básničku. Jde spíše o to zmínit je a říct si, proč jsou důležité a proč usnadní život aplikace v cloudu.  

The Twelve-Factor Application

Rozepsané detaily jednotlivých bodů najdete na 12factor.net.

1. Codebase - Používejte jeden repozitář pro svůj kód. Zjednodušeně “aplikace = repozitář”. Je jedno, zda použijete Git, Mercurial nebo Subversion. Více branches (větví) je OK. Více repozitářů jedné aplikace už ne. Z toho repozitáře pak můžete nasazovat aplikace do různých “stages”, ve kterých mohou být různé verze commitů kódu.

2.Dependencies - Nikdy slepě nepředpokládejte existenci knihoven nebo systémových nástrojů. Programovací jazyky mají deklaraci závislostí vyřešenou sami. Například Ruby má Bundler s gemfile. Java má Maven ap. Používejte je.  Stejně tak nepředpokládejte automatickou přítomnost nástrojů jako je ImageMagic. Ideální by bylo, kdyby tento nástroj byl vždy “zabalen” s vaší aplikací. Myslím si však, že než strávit dny práce s tím, jak to udělat,  plně postačí nějaký skript, který při deploymentu zjistí přítomnost potřebných nástrojů, a pokud tam nejsou, tak správně zareaguje.

 

3.Config - Striktně oddělte konfiguraci od kódu. Ve zdrojovém kódu by neměly být proměnné  „zadrátované“ uvnitř.

Zde platí jedno cvičení. Představte si, že přijde šéf a řekne: “Od teď je náš kód veřejně dostupný na Githubu a každý si ho může stáhnout a použít.”  Zamyslete se, zda tam nemáte odkazy na interní IP adresy nebo proměnné, které by byly platné pouze ve vašemu prostředí. To, že v kódu nemáte hesla, je samozřejmé a ani mě nenapadne se o tom zmiňovat, že? :)

Metodika 12factor doporučuje používat “environment variables” pro ukládání proměnných. Nejsem si jistý, zda je nejvhodnější ukládat proměnné do souboru. Dle mého názoru to porušuje závislost na podkladovém operačním systému. Moje preference je key-value store nebo aplikace typu Vault, nicméně doporučení z metodiky je jasné. Kód a vstupní proměnné držet odděleně.

4.Backing Services jsou odpůrné služby jako SMTP, MYSQL databáze nebo hostované monitorovací systémy typu New Relic. Z pohledu 12factoru je jedno, zda je to lokální nebo hostovaná služba.  Měla by být dostupná pomocí URL nebo přístupná přes přístupové údaje v konfiguračním souboru. Aby bylo jednoduché změnit třeba lokální MYSQL na cloudovou pouhou změnou URL a přihlašovacích údajů.
 

5. Build, Release, Run Striktně oddělujte vývojové “stages”. Každý takový stupeň by měl své “release ID” se svou konfigurací a možnost rollbacku. Je jasné, že pro menší společnosti je potřeba méně stupňů a pro velké je staging zahrnut v CI/CD procesech.

6. Stateless Processes Pokud si myslíte, že kontejnery by měly mít své stavové informace na lokálních discích nebo v paměti serverů, tak je to špatně.   Dvanácti faktorová aplikace musí být bezstavová (stateless) a “share-nothing”. Veškeré stavové informace by měly být v podpůrných systémech typu databáze.

Toto by se mělo dodržovat i v aplikacích, které si udržují tzv “sticky sessions”, a tyto potřebné informace by měly být udržovány v systémech typu Memcahed nebo Redis.

7. Port binding Vaše aplikace by neměla být přímo dostupná na portech otevřených aplikačním serverem. Místo toho by měly být instance aplikace sloučeny do “služby”, která dokáže routovat a udržovat spojení nad mnoha aplikačními porty. V Kubernetes je to například “Service” který se stará o toto slučování, vytváření virtuálních IP a portů ap.

8. Concurrency  Pokud navrhujete cloud native aplikace v principech 12 factor, tak vás moc nebude zajímat vertikální škálování. Tedy zvyšování výkonu aplikace přidáváním výkonu na jednom serveru. Naopak. Aplikace by měla být velmi jednoduše škálovatelná horizontálně přidáváním dalších “nodů” nebo serverů. Důvodů je mnoho. Jeden z nich je ten, že vertikální škálování má své limity. Jak technické, tak ekonomické. Škálování horizontální je levnější a technicky dostupnější.

Obdobně je také možné přemýšlet o procesech, ve kterých běží vaše aplikace. Mělo by je být možné zastavit a spustit bez toho, aniž by ovlivnily chod ostatních. Tedy psát aplikace co nejmenší a co nejvíce izolované.

9. Disposability Velkou změnou myšlení je nahlížet na aplikaci úplně jinak než jsme dosud zvyklí ze světa virtuálních serverů, kde každý server má své jméno. Víte, co na něm běží, a pokud se něco rozbije, tak o něj máte strach a jdete ho opravit. Klidně o půlnoci.

V cloud native  je na infrastrukturu  nahlíženo jako na množství výpočetních nodů. Žádný z nich nemá pěkné jméno, ale své ID. Pokud se rozbije, tak se neléčí, ale ničí a místo něho se hned vytvoří nový klon.  Toto je myšlenka “jednorázového použití”. Vaše aplikace by měla bez problémů přežít SIGTERM, ale pro uživatele to neznamená nedostupnost služby.

10. Dev/Prod Parity Držte vývojové, testovací a produkční prostředí co nejvíce podobné, ne-li stejné. 12factorové aplikace jsou připraveny na CI-CD  (Continous Integrations Continous Delivery pipeline. Jsou tedy připraveny na situace, kdy vývojáři publikují své změny téměř okamžitě a nečekají na sprinty trvající týdny.

Prostě zajistěte co nejjednodušší cestu od vývoje do produkce. Využívejte knihovny, které dělají transparentní přístup k podpůrným službám, napříkad ActiveRecord v Railsech pro přístup k databázím.

11. Logs Každá aplikace by měla zapisovat logy na STDOUT bez cachingu. Externím procesem mimo aplikaci by potom mělo dojít k cílovému nasměrování logu na nějaké centrální místo, například do Log Insight nebo Splunk. Tedy nasměrovat logy mimo proces aplikace a teprve tam je potom obsluhovat, aby nedošlo k možné ztrátě důležitých informací.

12. Admin Processes Jednorázové administrátorské úkony, třeba jako je migrace schémat databáze nebo spuštění předpřipravených scriptů, by měly probíhat ve stejném stage,kde běží aplikace. I tyto jednorázové administrační scripty a nástroje by měly být součástí centrálního kódu v repozitáři a měly by se distribuovat spolu s ostatním kódem.

Celkově si myslím, že tato metodika je souhrnem velmi dobrých doporučení, kterými je dobré se zabývat, pokud přemýšlíte o „cloud native“ aplikacích a Kubernetes. Sledujte další příspěvky, ve kterých se podíváme na konkrétní použití metodiky pro aplikaci nasazenou do Kubernetes.

Vojtěch Morávek
Chief Product Officer