Í dag eru spennandi tímar ef ráðast á í endurbætur eða þróun á hugbúnaðarkerfum sem byggð eru til að stækka og dafna. Þar vegur einna þyngst að velja réttar lausnir af þeim sem eru í boði í opna hugbúnaðarsamfélaginu og ekki síður skiptir miklu hvernig þessum lausnum er beitt. Erfitt getur verið að velja rétt þar sem úrvalið er mikið og margt spilar inni í við val á viðeigandi tólum. Í grunninn er það tilfinning teymisins og reynsluheimur þess sem er mikilvægasti þátturinn við val og mat á því hvernig hugbúnaðurinn getur tengst við aðra þætti þeirra lausnar sem er í smíðum. Fjárhagslegi þátturinn kemur einnig sterkt inn í þessa mynd og þar þarf líka að meta kostnað út frá framtíðarsýn um fjölda notenda, t.d. fjögur ár fram í tímann. Þar er oft mikilvægt að huga að því hvort frí útgáfa af viðkomandi lausn nái ekki örugglega að sinna því sem stefnt er að og öruggt sé að ekki þurfi að greiða leyfisgjöld. Að þessu þarf að huga sérstaklega og meta gagnvart hugsanlegri þörf á þjónustu frá hugbúnaðarframleiðanda eða þriðja aðila.

Almennt spilar menning teymis mikilvægan þátt, samanber metnaður þess gagnvart sjálfsnámi og hugsanlegur vilji til þess að vera óháðir sölumönnum. Þannig hafa fyrirtæki tækifæri til þess að festast ekki í þjónustusamningum nema þar sem þörfin er brýn. Í mörgum tilfellum getur fjöldi fyrirtækja boðið upp á trygga þjónustu á opnum hugbúnaði sé þess óskað.  

Auðvitað eru heilmikil verðmæti og tímasparnaður í boði í fjölda lausna á vefnum fyrir hóflegt áskriftargjaldi. Þar má nefna tól eins og Pagerduty, Pingdom, Flowdock og Geckoboard. Til þess að auðvelda keyrsluumhverfi á framangreindu er spennandi að nýta lausnir frá fyrirtækjum eins og Joyent, Heroku eða Amazon AWS. Svo má ætla að samkeppnisfærni muni aukast frá bæði Google og Microsoft á þessu sviði. Allt er þetta þróun sem er til þess að lækka kostnað og upphafsfjárfestingar í okkar hugbúnaðarkerfum.

Til þess að byggja upp grunn og þekkingu fyrir ákvarðanir um val á tækni þá getur verið gott að nýta sér umræðuvettvanga eins og Quora, Stack Overflow og Hacker News og taka þar virkan þátt. Einnig er snjallt að fylgjast með áhrifamiklum forriturum á GitHub, fylgja því sem þeir gera og auðvitað ættu allir forritarar á Íslandi að vera meðlimir á GitHub. Tíma á þessum sérhæfðu samfélagsvefjum er vel varið og skrifast tíminn þar á endurmenntun og sjálfnám.

Teiknaðu upp þitt tæknilega hagkerfi

Þegar ráðist er í hönnun eða endurbætur á kerfum er gott að ná að teikna upp heildar hagkerfið fyrir heildarlausnina. Þannig mætti bera saman tæknilega innviði á kerfinu við raunverulegt hagkerfi því þar erum við með Hagstofu, banka, pósthús, markað, upplýsingaveitu og ýmsa sérhæfða þjónustu. Sama má segja um tæknilega hönnun kerfa þar sem hver “stofnun” er endurspegluð í hverri forritunarvél eða módúl (e. module).

Ein af ástæðum fyrir þessa aðgreiningu er að tryggja að kerfið verði viðráðanlegt og auðvelt að gera breytingar eftir á. Sér í lagi þegar teymið er lítið í upphafi. Þess vegna geta sumir módúlar aðeins verið nokkrar línur af kóða. Enda ber að hafa í huga að færri línur af kóða bjóða uppá færri mögulegar villur!

Þegar velja skal umhverfið til að smíða viðkomandi forritunarvél í er þegar búin að eiga sér stað afar spennandi þróun með lausnum eins og Node.js.  

Merkilegustu nýjungarnar koma úr grasrótinni

Hinir merkilegustu hlutir koma oft úr óvæntustu átt. Dæmi um það er hugmynd sem ungur stærðfræðinemi að nafni Ryan Dahl kom upp með fyrir nokkrum árum og kallast Node.js. Hugmynd hans var einföld og byggði í raun á röð annarra hugmynda, m.a. út frá útfærslu kerfa. Ryan var ekki forritari heldur áhugasamur stærðfræðinemi sem í raun slysaðist óvart inn í heim forritunar og vefforrita fyrir nokkrum árum. Það er líklegast einn af kostum Ryan, að hafa ekki verið of mótaður um hvernig hlutirnir eigi að vera. Hann byrjaði á því að leika sér í vefþróun í Ruby on Rails ásamt því að smíða einfalda vefþjóna með tólum eins og Mongrel. Ryan fannst  þessi umhverfi vera hægvirk og ekki ná utan um þá hugmynd að blanda vafra og vefþjóni betur saman. Eftir talsverða vinnu datt Ryan inná JavaScript forritunarmálið, sem hingað til hafði aðeins verið notað til að smíða aðgerðir inni í vafranum. Hugmynd Ryan með JavaScript var þó allt önnur og byggði á því að nýta JavaScript miðlara megin. Þegar Ryan fór að leita að lausnum í JavaScript fyrir vefþjóna í byrjun árs 2009 þá var ekkert að finna. Þetta taldi hann vera jákvætt þar sem ekki væri allt fullt af gömlum úreltum tólum eða kóða sem byggði á úreltum aðferðum.

Það sem skipti hinsvegar einna mestu máli er sú einfalda hugmynd að nýta V8 vélina í Chrome vafranum sem gerir JavaScript ofur hraðvirkt. V8 er opinn hugbúnaður sem lætur JavaScript keyra mjög hratt í vafra. Node.js nýtir V8 vélina, en í staðinn fyrir að keyra inni í vafranum á vél notandans þá keyrir vélin á miðlara.

Þessi aðferð gerir það að verkum að lausnir sem forritaðar eru í JavaScript og keyra á Node.js á miðlurum eru hraðvirkari en flestar aðrar lausnir á markaðnum. Auk þess er veruleg hagkvæmni fólgin í að nýta allan þann kraft og samkeppni sem ríkir á markaðnum þar sem verið er að gera hvern vafrann á fætur öðrum hraðvirkari en það sem fyrir er á markaðnum. Öll samkeppni á milli Chrome, Firefox, Opera og Explorer byggir að nokkru leyti á því hvaða JavaScript vél er hraðvirkust. Þessi þróun og samkeppni nýtist því fullkomlega fyrir Node.js umhverfið.

Það má því búast við að Node.js nái að halda vel velli sem eitt hraðvirkasta keyrsluumhverfið í vefbransanum, þar sem meira og minna allt vafrahagkerfið bakkar það upp með almennri samkeppni á markaði.

Annar styrkur Node.js er hið svokallaða NPM pakkakerfi (e. Node Package Manager) sem gerir það einfalt að halda utan um módúla og forritshluta á skipulagðan miðlægan máta innan þróunarsamfélagsins. Með NPM er afar einfalt að sækja módúla utan úr heimi og aðlaga inn í eigin kóða. Með þessu er hægt að halda sjálfum forritunarkjarnanum litlum og byggja að stórum hluta á þróuðum módulum úr opna Node.js samfélaginu.

Í raun er JavaScript líklega eitt vanmetnasta forritunarmálið í heiminum í dag, sér í lagi þegar horft er til menntakerfisins. Það væri því óskandi að JavaScript verði tekið upp með meiri krafti í almennri kennslu. Sjálft JavaScript málið er þó ekki endilega það besta, heldur er útbreiðsla þess mikil.

Það að velja Node.js sem almennt umhverfi á vefþjóna endanum býður upp á tæknilega kosti ásamt rekstrarlegum ávinningi, sem felst í aukinni þekkingu.  

Til þess að prófa veflausnir sem þróaðar eru með Node.js er hægt að prófa t.d. veftól eins og Trello. Þetta er frábært tæki til þess að halda utan um framgang mála í verkefnum og er gríðarlega skemmtilegt verkefnastjórnunar tól.

Svo er hægt að fylgjast með þróuninni á Node.js í gegnum GitHub, sem er samskipta- og geymslusvæði fyrir forritunarkóða. GitHub er í grunninn ókeypis fyrir meðlimi en til þess að hýsa læstan hugbúnaðarkóða hjá fyrirtækjum þarf að kaupa áskrift. Forritarar ættu að nýta sér GitHub umhverfið til hins ýtrasta og elta þar aðra áhugaverða forritara og verkefni þeirra.

Forritunarvélar sem tala saman JSON

Hver forritunarvél býr yfir ákveðnum stöðluðum verkfærum og oft búa þær yfir eigin gagnagrunni. Þar af leiðandi er í raun frekar hægt að tala um forritunarvél (e. engine) heldur en módúl, þ.e. þær eru sjálfstæðar - óháðar öðrum forritunarvélum - og eiga oftast sína eigin gagnagrunna.  

Varðandi val á gagnagrunnum

Þegar kemur að vali á gagnagrunnum þá getur verið ávinningur í því að vera ekki með einn miðlægan gagnagrunn sem allir kerfishlutar tala við. Það getur verið mun betri kostur að velja léttari gagnagrunna og dreifa þeim frekar niður á hverja forritunarvél.

Hver forritunarvél eða módúll er með sínar kröfur um hverskonar gögn þarf að geyma og hvort þau eru langlíf, statísk eða hvort reiknað sé með að uppbygging gagnanna gæti verið breytileg. Í þessu mati geta margvíslegir gagnagrunnar komið inn í myndina.

Sumir ganga svo langt að ígrunda í hvaða forritunarumhverfi sjálfir gagnagrunnarnir eru þróaðir. Ef horft er til áreiðanleika, skölunar og einfaldleika þá er forritunarmálið Erlang góður kostur. Þetta er forritunarmál sem t.d. íslendingar hafa reitt sig á síðustu 20 árin í gegnum Ericsson símstöðvarnar og til viðbótar má nefna að Facebook valdi að byggja sitt spjallkerfi á Erlang, sem segir sína sögu um viðhorf til áreiðaleika þess.  Á þessum forsendum getur verið snjallt að velja gagnagrunn keyrðan á Erlang og þar kemur CouchDB gagnagrunnurinn sterkastur inn.  

CouchDB flokkast undir svokallaða NoSQL aðferð.  Þeir sem eru vanir að vinna með SQL aðferðina þurfa ekki að óttast það frelsi sem felst í skjala geymslu (e. document store) eins og CouchDB býður uppá. Einfaldleikinn sem þessir nýju grunnar bjóða upp á leysir margan vanda og opnar ótal tækifæri hvað varðar nýja hugsun í hugbúnaðarhönnun. Annar kostur við einfaldleikann í kringum CouchDB er að hann talar JSON og nýtir REST samskiptaformið. CouchDB er auk þess ekki að reyna að vera allt fyrir alla heldur leggur áherslu á einfaldleika í meðhöndlun.

Forritunarvélarnar

Við standsetningu á hverri forritunarvél fyrir sig er úr nógu að velja hvað varðar kóða til að auka verðmæti hverrar vélar. Gera má ráð fyrir að í stærri kerfum séu þessar vélar 8 til 12. Sumar vélar búa yfir beinni virkni gagnvart endanotenda í gegnum vefviðmót og þar má velja um algengar lausnir eins og jQuery, Less, Amplify, Backbone, Underscore, Showdown og fleiri. Einnig má meta lausnir eins og Coffeescript þegar horft er til vinnu með einfaldari JavaScript kóða. Varðandi vefþjónahlutann má nýta lausnir eins og Restify, Up, Dtrace og Redis.

Kjarninn

Það má segja að góð útfærsla á Message Queue sé kjarninn í hönnuninni.  Hér má beita sömu hugsun við val á Message Queue og gert er fyrir gagnagrunna. Þannig gæti verið snjallt að velja tól eins og RabbitMQ sem er einmitt þróað í Erlang.  Hugsunin með Message Queue er að lágmarka ósjálfstæði (e. dependencies) sem m.a. minnkar líkur á hverskonar tjóni í keyrslu umhverfinu. Þannig má ræsa fleiri forritunarvélar og módúla eftir álagi og þannig er þessi gátt að sinna ákveðinni álagasstjórnun. En aðalega gefur þetta tækifæri á að vinna með smærri módúla, þannig að lítið þróunarteymi getur með auðveldara móti gert breytingar eða ráðist í nýþróun á ákveðum verkþáttum án þess að þurfa að setja sig inn í spagettí af forritunarkóða.

Message Queue þarf ekki endilega að tala REST innbyrðis, heldur má nýta mun hraðvirkari samskipti eins og Advanced Message Queuing Protocol (AMQP). Hinsvegar stöðlum við okkur við JSON snið á gögnunum.

Reglan er þó að módúlar bjóði einnig uppá REST viðmót, sem auðveldar frekari tengingar á milli utanaðkomandi kerfa. AMQP og REST er þó ótengt, þar sem REST talar við umheiminn en AMQP innan kerfis. Meira og minna allur nýsköpunarbransinn í heimi veflausna hefur verið að staðla sig á REST sem hina opnu samskiptaaðferð, sem opnar fyrir endalausa möguleika til þess að nýta opinn hugbúnað.

Eftir að kerfið vex og hýsir stærri hluta notenda má svo áfram nýta Message Queue sem öflugt eftirlitskerfi, m.a. til að fylgjast með getu kerfisins, stöðugleika, hugsanlegum stíflum eða óvæntu álagi.  Með vel útfærðu fyrirkomulagi má standsetja þetta á þann máta að gera kerfið sjálfskoðandi og sjálflæknandi. Þannig er Message Queue notað til að senda upplýsingar um ástand á hverjum módúl. Til að mynda ef einhver módúll er ávallt of seinn að svara að þá er hægt að laga hann, t.d. með því að keyra hann upp af annarri vél.  Þannig er sífellt hægt að byggja inn aukna greind í kerfið til þess að bregðast við ýmsum vandamálum sem geta komið upp.

Í umhverfinu er mikið úrval af vélum sem má byggja inn. Þar má nefna tól eins og ElasticSearch til að annast almenna leit og fleira í þeim dúr. Það má svo vissulega skrifa hverja forritunarvél eða módúla í því sem hentar best, reglan er þó að tala JSON til að halda sig við einhverja stöðlun. Þegar unnið er að endurbótum getur í stöku tilfellum verið betra að skrifa nýja forritunarvél eða módúl frá grunni í stað þess að vinna í eldri kóða. Þannig má meta á hverjum tíma hvaða þróunarumhverfi hentar best við hvern módúl. Með þessu er því einnig einfaldara að viðhalda kerfinu.

“Message Broker”

Ef dæmi er tekið af notanda úti í heimi, sem gerir fyrirspurn frá notendaviðmóti með “http request” þá fer sú fyrirspurn á svokallaðan Message Broker (API Router). Þetta er í raun gáttin við umheiminn. Samskiptin við þessa gátt er REST og JSON. Þessi Message Broker kann að taka fyrirspurnir og senda þær inn í Message Queue.  Þannig fá allir módúlar og vélar sömu fyrirspurn, en hver um sig, með sína ólíku þekkingu á viðfangsefninu, sendir sín svör eftir bestu getu. Þessi svör fara til baka á Message Queue ásamt upplýsingum um samhengi hlutanna. Þegar Message Broker er kominn með fullnægjandi svör eru gögnin pökkuð saman og send til baka.

Með því að vinna eftir þessari leið er auðvelt að bæta inn aukinni greind inn í kerfið. Auk þess er mun auðveldara fyrir nýja forritara að koma ferskir inn í verkefnið. Þannig má forrita nýja módúla eða forritunarvélar sem kunna meira um viðfangsefnið en þeir sem fyrir eru og byggja kerfið þannig upp án þess að brjóta arkitektúr eða jafnvel keyrsluumhverfið.

Hver forritunarvél eða módúll þarf ekki að vita um aðra, heldur aðeins að kunna að taka þátt í samræðunum sem fara fram á Message Queue. Þannig hefur það ekki áhrif á heildar virkni kerfisins þó stakir módúlar hrynji. Þessar aðferðir gefa einnig mjög góð tækifæri til að byggja inn alla skölun (e. scalability) ef álag mundi myndast á lausnina. Auðvelt er að bæta inn nýjum módúlum í rauntíma eftir álagi. Auk þess má dreifa þeim eftir þörfum um netið og meira út á jaðarinn, nær þeim mörkuðum sem geta búið til álag á kerfið.

Þannig má byggja öfluga notendaupplifun ofan á þennan kjarna, hvort sem sú upplifun sé hluti af vefsíðu, iOS forrit, Facebook forriti, Android forrit eða jafnvel tölvuleik í leikjavélum.

Umrædd lausn er í raun lýsing á klassískri Service Oriented Architecture með ákveðna áherslu á rauntíma vefinn. Þetta er einnig sú aðferðafræði sem við beitum í því fyrirtæki þar sem ég starfa sem framkvæmdastjóri.

Vert er þó að hafa í huga að án viðskiptavina skiptir flottur arkítektur eða skölun á tækninu litlu máli. Fyrirtæki þurfa ávalt að hugsa um raunverulega verðmætasköpun fyrir endanotandann fyrst og svo um tæknilegu útfærslur. Hér er gert ráð fyrir því að gott jafnvægi sé á milli vörustjórnar og svo tæknilegrar útfærslu lausnanna.

Gangi ykkur vel!

Höfundur Guðjón Már Gudjónsson, Twitter: @gudjon