Kohti Reinvent 2017 seminaaria

Vannoin itselleni että jättäisin tänä vuonna ulkomaan seminaarit sikseen, osittain iloisten perhetapahtumien johdosta, osittain kiristyvän maailmanpoliittisen tilanteen johdosta. Etenkin jenkkeihin on aika raskasta lentää, ja rajalla saa varautua kaikenlaisiin kummallisuuksiin, riippuen juuri sen viikon tilanteesta. Mutta kaikesta huolimatta näyttää että nokka vie kohti Las Vegasia, muutaman viikon päästä. Tuli tilaisuus lähteä, ja en voinut sitä missata.

https://reinvent.awsevents.com/

Re:Invent on AWS pilvipalveluiden suurin tapahtuma. 40 000 uuden rakentajaa kokoontuu yhteen, opiskelemaan ja yhdistämään tietojaan siitä, miten moderneilla pilvipalveluilla voidaan tuoda ihmisten arkea helpottavia ratkaisuja. Ja tietystikin, miten voidaan luoda uusia, ennennäkemättömiä innovaatioita.

Olen hivenen innoissani. Seminaarireissuja on tullut nähtyä aiemminkin, ja ne ovat aina mukavia tilaisuuksia ristiinpölyttää vähän kokemuksia ja näkemyksiä. Suomessa on lopulta aika pienet piirit ja ennen pitkää on tullut nähtyä variaatiot mitä tulee vastaan, ja tietysti projektejakaan ei aina tehdä siinä mittäkaavassa, mitä jenkkilässä voi osua tutkaan. On yksi asia kuulla jostain AWS palvelusta tai teknologiasta teoriatietoa, ja aivan toinen asia on kuulla mitä sillä on tehty, ja miten homma on onnistunut – tai ei.

Taas kerran on valinnan vaikeutta ilmassa. Yli 1000 perussessiota, ja kaikenlaisia ihania workshoppeja luvassa. Mahdottoman vaikeaa priorisoida ne parhaat. Onneksi meidän pajasta lähtee tällä kertaa vähän isompi iskuryhmä, niin voidaan vähän jakaa mielenkiinnon aiheita. Esim. analytiikan koneoppimisen puolelta on jo vahvaa edustusta. Itse aion sukeltaa tuonne devaajahattu päässä. Eniten kiinnostaa tietysti kaikki.

Omaan kalenteriini menee siis syväsykelluksia palveluihin, jotka jo tunnen, sekä pieniä tutustumisia aivan uusiin asioihin. Yksi kenttä, jota en ole vielä päässyt työhommissa luotaamaan, on Alexa puhekäyttöliittymä käytännön ongelmanratkaisussa, eli otin sitä puuhasteltavaksi vähän. Kuten olen useasti todennut, näppäimistö ja hiiri on niin arkaainen käyttöliittymä koneälyyn, että edelleen ihmetyttää että niitä käytetään kaikkialla. Johonkin ne sopivat, ja tietysti jossain ne ovat varsin nostalgisia. Mutta kun mietitään nykypäivän laitteiden verkostoitumista ja älykkyyden ja oppimisen tasoa (ja vääntöä ja muskelia), on ainakin mahdollisuus kokeilla jotain uutta. En tiedä onko se äänikäyttöliittymä, mutta omassa varovaisessa käytössä, ja muutamassa toteutuneessa digitalisaatiossa, jota olen seurannut, se on ainakin alustavasti hitonmoisen lupaava suunta.

Mitäs muuta otan mukaan? Suunta kohti serverless teemaa ainakin kiinnostaa. Meidän pajan Data Science-poppoolle se on jo arkipäivää, mutta devauspuolella voitaisiin ottaa rohkeampiakin askelia. Uudet (no uudet ja uudet…) teknologiat kuten Lambdat, streamit, kaipaavat devauspuolella tuekseen automaatiota, johon ollaan laadukkassa softatoimituksessa totuttu. Jatkuva integraatio, jatkuva testaus, jatkuva toimitus, vaativat vähän yhteensovitusta kun avataan käyttöön koko AWS paletti. Tästä teemasta otin pari sessiota ajatusteni tueksi, ja odotan mielenkiinnolla.

Kaikken eniten kuitenkin odotan taas sitä tilaa sessioiden välissä. Sessioista suurin osa valuu kuitenkin verkkoon ennen pitkää, ne voisi katsella kotisohvaltakin. Se mitä ei kotisohvalta koe on ne vertaiskeskustelut, innovointi, ideointi, haaveilukin, kontaktit, verkostot, omien ajatusten ravistelu ja kyseenalaistus, monipuoliset näkökulmat, ja miksei myös uudet tuotteet ja palvelutkin, mitä on tarjolla. Siinä on se syy, miksi jaksaa veivata toistakymmentätuntia ahtaassa metallituubissa kahteen suuntaan, jet lagien kera.

P.S. Jos luit tämän, ja olet itsekin menossa, voidaan vaikka moikata paikan päällä!

 

Mainokset

AWS Certified Solutions Architect – Associate

Kävin viime viikolla suorittamassa tuon otsikossa mainitun sertifikaatin – vaikeampi kuin odotin mutta läpi meni. Ajattelin kirjailla tähän vähän fiiliksiä, ajatelmia ja vinkkejäkin tuohon liittyen.

Nykyisessä pajassani (Solita) ollaan aika pilvinatiiveja. Meillä on omaa pilveä, ja aina kun projektit sen sallivat, pyritään tarjoamaan alustaksi jotain pilven nurkkaa. Syyt tähän ovat ilmeisiä. Pilvi tarjoaa parhaimman DevOps kokemuksen (tai ainakin mahdollistaa sen), koska on mahdollista välttää siiloutumista, ja pääsy ja työvälineet ja hallinta ovat ensiluokkaisia. Pilvi tarjoaa loistavan alustan kokeilulle edukkaasti, investoimatta raskaaseen rautaan, ja sieltä saa resursseja nopeasti, nappia painamalla. Pilven skaalautuvuus on myös (hyvin tehdyille sovelluksille) lähes rajaton, ja vikasietoisuutta saa globaaleilla pilvillä ruuvattua todella erinomaiseksi. Juuri mitään näistä hyödyistä ei saa paikallisesta konesalista, ja siihen on monissa paikoin suorastaan totuttu.

Itse olen puljaillut AWS EC2 koneiden kanssa jo pitkiä aikoja, mutta oikeastaan vasta nykyisissä hommissa havahduin siihen, mitä muuta AWS tarjoaa. Kiitokset siitä Data Science-puolen väelle. Yksi ensimmäisiä hommiani Solitalla oli tukea Data Science projektia teknisessä mielessä, jossa haluttiin vertailla kalliin kaupallisen datan rouskutusvälineen kyvykkyyksiä open source pinoon. (Kallis kaupallinen veti kokonaiskustannuksiltaan liput kotiin mennen tullen tässä skenaariossa). Myös firman HipChat kanavalla huhuillaan aika ajoin kiinnostavia juttuja mm. Lambdoista ja Serverless-malleista, tai S3-website hostauksesta. Vanhana hardcore koodinvääntäjänä jolle aiemmin oli kunnia-asia tehdä kaikki työkalut itse, olen sittemmin kokenut tietynlaista tuottavaa laiskuutta, ja näin tällaiset ovat nykyään kiinnostavia huhuiluja, kun pyritään tekemään entistä enemmän entistä fiksummin.

Mitäs niitä serttejä löytyy?

No niin, joka tapauksessa, AWS pilvestä löytyy sertifiointeja joka lähtöön. Kovan ytimen muodostaa viisi sertifikaattia, joista kolme on perustasoa, ja kaksi on professional-tasoa. Jenkkien palkkavertailuissa jo perustason arkkitehtisertifikaatti oli arvostetuin ja paraspalkkaisin mitä sertifiointeihin tulee. Pro-tason arkkitehtisertifikaatti on jo käytännössä hyvän työpaikan tae, etenkin jos sen mukana tulee kykyä kommunikoida ja oikeasti ratkoa ongelmia. Näiden viiden päälle löytyy sitten erikoistumissertifikaatteja, mm. tietoturvasta, ja verkoista.

Sertifikaatit ovat vain monivalintakysymyksiä, ja niitä usein kritisoidaan. Ne eivät ole hyvä osaamisen ja soveltamisen mittari. Mutta samoin kuin aikanaan Java-sertifikaateissa, itse puolustan niitä silti. Koska jos on henkilö, joka on suorittanut tietyn sertifikaatin, se kertoo minulle, että hän on ainakin jossain vaiheessa hallinnut kokonaiskuvan teknologia-alustasta, yksityiskohtia myöden. Henkilö jolla ei sertifikaattia ole, voi osata jonkun nurkan erinomaisesti, toisen surkeasti, ja kolmatta ei ollenkaan. Hänestä en tiedä siis mitään.

Jos työhaastattelussa haastateltavalla on esittää sertifikaatti, se ei kerro että hän on loistava ohjelmoija, mutta antaa silti tietyn baseline-tason laadulle. Henkilö jolla ei sertifikaattia ole, vaatii huomattavasti pidempää tenttausta jos haluaa päästä osaamisesta selville. Projekteissa olen havainnut, että sertifioitumattomat henkilöt voivat olla suorastaan hasardeja: Tehdä enemmän vahinkoa kuin hyvää. Tämä johtuu siitä, että työkalupakki on, metaforaa käyttääkseni, vajavainen. Siellä voi olla yksi upea, kiiltävä vasara, mutta ei mitään muuta. Palkkaan mielummin työmaalle tyypin jolla on kulunut pakki jonka kaikkia perustyökaluja on käytetty tasapuolisesti. Häneltä löytyy hihasta vaihtoehtoja ja joustavuutta. Se kiiltävän vasaran kaveri etsii vain kaikkialta nauloja.

No liittyykö sertifikaatti sitten juuri tähän? Ei välttämättä, sama oire voi olla sertifioituneillakin. Mutta käytännnössä olen suuri fani sille että jos haluaa syvälle tekkiin, aloitetaan sertifikaatista, ja siitä alkaa opiskelu. Vähän kuin taistelulajeissa, musta vyö aloittaa varsinaisen oppimispolun – ei päätä sitä.

Vinkkejä

Vinkkejä opiskeluun? AWS sertifikaatit ovat huomattavasti vaikeampia kuin esim. SUN/Oracle Java-sertifikaatit, vaikka puitteet ovat suunnilleen samat. Perustason sertifikaateissa on yleensä n. 60 kysymystä, ja muutama tunti aikaa. Läpäisyyn piisaa 65-70% oikein. Mutta AWS on yhä vain laajempi kokonaisuus, palveluiden määrä lisääntyy koko ajan, tätäkin kirjoittaessa. Ja sertifiointikysymykset ovat todella yksityiskohtaisia, sieltä voi tulla esim. kysymyksiä koskien kapasiteettia, kaistaa, jne. Osa on onneksi ihan terveen järjen kysymyksiä, niistä selviää jos on oikeasti tehnyt jotain AWS konsolissa.

Mutta tässä pari vinkkiä:

  • Kaikkein tärkeintä on mock exam/testi-testit, että totut kysymyksien tyyppeihin, tapaan, ajoitukseen. Niitä löytyy jonkun verran ilmaisia, mutta parhaat maksavat jonkun verran. Amazonin kautta saa ’virallisen’ harjoitustestin, mutta itse löysin loistavia harjoitustehtäviä myös android-sovelluksista, joita voi mukavasti naputella tabletilla läpi vaikka työmatkalla
  • Valmistautumiseen tärkeintä on lukea AWS Whitepaperit ja FAQ lätyskät, ainakin tärkeimpien palveluiden osalta. Core palveluita ovat EC2, S3, VPC, RDS, ja DynamoDB, mutta niiden ohella yllättävät paljon tulee myös kysymyksiä myös esim. SNS, SQS ja SWF osista.
  • Ehdottomasti kannattaa investoida johonkin online-preppaukseen koskien sertifikaattia. Niitä saa alennus-aikaan muutamalla kympillä, itse käytin acloud.guru kursseja (jotka ovat itsessään tehty AWS Serverless+Lambda arkkitehtuurilla, kustannustehokkuussyistä)

Itse ajattelin jatkaa sertifioitumista tällä suunnalla, koska tämä on hyvin kiinnostava suunta, ja viimein antaa mukavan oppimishaasteen. Osa asioista on jo käytännön tasolla tuttuja, mutta osa ei. Bonuksena kakun päällä olen myös kiinnostunut AWS Alexa rajapinnoista, ja harrastepuolella olen jo niiden kanssa näperrellyt. Acloudguru sitella on tehty muuten Alexan päälle botti joka kyselee AWS sertifiointiin testikysymyksiä 😉

 

 

 

 

Spring Boot, Java 8, AngularJS, ja Heroku pilvipalvelu

Tuli ajankohtaiseksi puskea Spring Boot sovellus Herokun alle tarjoiltavaksi. Heroku on siitä vänskä palveluntarjoaja että sieltä saa ilmaisella jäsenyystasolla jo jonkun verran prosessoriaikaa, ja resursseja – samoin kuin Google App Enginestä (ainakin aikoinaan).

Homma ei mennyt ihan heittämällä, joten kirjailen taas vähän kokemuksia ja säätöjä tähän. Omassa tapauksessani muutama kiemura johtui siitä että olin yhdistänyt sekä Javaa että Angularia samaan pakettiin – ja Heroku parka meni sekaisin sen suhteen mitä pitäisi buildata ja miten. Muuten Spring Boot + Heroku on taivaassa tehty liitos, mahtava yhdistelmä!

Mitä tarvitaan/esivalmistelut:

– Yksi Spring Boot sovellus, jossa esim. In-Memory tietokanta ja AngularJS UI sisään paketoituna – ei niin välttämätöntä, mikä hyvänsä Spring Boot käy lopulta, mutta kannat vaativat toki esim extratyötä

– Projekti pitäisi olla git versioitu, se tekee heroku käytön suorastaan naurettavan helpoksi

– Tietty Heroku free tier tunnukset tarvitaan, ja ne tulisi olla tiedossa

– Heroku Toolbelt asennettuna omalle käyttöjärjestelmällesi

– Pientä lisäjännää: Haluat ehkä lisätä bower_components tyyppiset vendor javascript kirjastot gittiin, koska jos buildaat projektin Java builderillä, mitään automatiikkaa javascript/angular puolelle ei ole, eli sen mitä lähetät Herokuun tulisi olla joko Mavenin kautta buildattua automaattisesti, tai sitten esirouskuteltua staattista sisältöä. bower_components pusku gittiin on muutenkin paras käytäntö koska ulkomaan repositoryt tai interweb eivät noin muutenkaan ole aina buildatessa saatavana, joten näillä mennään!

Ja sitten touhuamaan. Aluksi kannattaa lisätä projektiin muutama tiedosto, ellei niitä jo ennestään löydy. Tarvitset settings.properties tiedoston, Procfile tiedoston, ja application.properties tiedoston. Näistä kaksi ensimmäistä liittyy Heroku-alustaan, ja viimeinen on Spring Boot standarditiedosto – joka on luontevaa tallettaa /config kansioon.

Tässä niiden sisältö:

  • /settings.properties (asettaa JDK versioksi 8)
    • system.properties=1.8
  • /Procfile (kertoo mikä sovellus ja mistä käynnistyy)
    • web: java $JAVA_OPTS -jar target/*.jar
  • /config/application.properties (määrittää käyttäämän serveriporttina PORT ympäristömuuttujaa, tai 8080 jos sitä ei löydy)
    • server.port: ${port:8080}

Näistä tosiaan application.properties saattaa olla jo tehtynä, ja voi olla muussa kansiossakin, eli ole tarkkana. Se on Spring Boot perustiedostoja.

Nyt voidaan alkaa touhuamaan. Lisää kaikki edellämainitut git repositoryyn, commitoi, ja jatka näillä Heroku komennoilla:

  • heroku login (tänne sitten tunnareita ja salasanaa Herokun mukaan)
  • heroku create (luo sovelluksen, ja käytännössä määrittelee uuden remote repositoryn nimeltä heroku)
  • heroku buildpack:set https://github.com/heroku/heroku-buildpack-java (asettaa builderiksi juuri Java, eikä esim. NodeJS tms)
  • heroku ps:scale web=1 (asettaa käyttöön yhden dynon, ellei ole jo – nyt on resursseja ajamaan sovellusta)

Voiton puolella jo! Nyt voidaan puskea sovellus herokuun, tähän tapaan:

git push heroku master

Seuraa tarkkaan ilmoituksia mitä näkyy – etenkin jos virheilmoituksia ilmenee. Jos kaikki sujui hyvin, voit nyt avata sovelluksen:

heroku open

Toimiko? Onnittelut! Jos ei pelannut, tässä muutama debugging niksi:

  • Tarkista Heroku logit komennolla: heroku logs –tail
  • Tarkista web dynojen status komennolla: heroku ps

Huomioi että jos dynoja on vain yksi käynnissä, Heroku nukuttaa sen jos tuntiin ei ole ollut käyttöä. Näin ollen se käynnistyy hitaanlaisesti kun sitä taas tarvitaan. Tämän voi kiertää laittamalla kaksi dynoa – tai enemmän:

heroku ps:scale web=2

Huomaa että free tier antaa vain 750 dyno-tuntia, joten kahden dynon voimalla ei piisaa tehoja kuin puoleen kuukauteen ilmaistasolla. Muista myös sammutella dynot kun et niitä enää tarvitse, komennolla:

heroku ps:scale web=0

Näin! Spring Boottia voi siis tunkea Raspberry Pi kakkoseen, tai pilveen. Vaikuttaa aika toimivalta alustalta nykymuodossaan.

Tässä hyvä linkki myös artikkeliin jossa käsitellään Heroku multi-buildpack strategiaa – eli miten voit buildata sekä Java että JavaScript puolen erikseen sillä suunnalla.

https://devcenter.heroku.com/articles/using-grunt-with-java-and-maven-to-automate-javascript-tasks

Itse käytin joskus aikanaan Eirslett Maven-Grunt pluginia, joka osaa imaista node, npm, bower jne työkalustot paikallisiksi ja käyttää niitä projektin alta – mutta se oli aika monimutkainen ja kömpelökin ratkaisu. Monella on tarpeista riippuen ollut menestystä myös ihan exec-maven pluginin kanssa javascript prosessoinnissa, mutta sen ongelmana on että node pitäisi olla koneeseen asennettuna etukäteen.

Pilven reunalle istumaan JEE serverin kera

Tänään koulutellessa Java EE ohjelmointia tuli vastaan kysymys siitä, mitkä suomalaiset web-hotellit tukevat Java EE softan asennusta ja ajamista. Itselle on tutuksi tulleet lähinnä Google App Engine sekä Amazon pilvipalvelut entuudestaan, mutta suomalaista tarjontaa en juuri tuntenut joten ei kun tutustumaan.

Tarjokkaita löytyi lopulta – pun intended – pilvin pimein. Mutta jostakin syystä käteen jäi itselle Jelastic, pystytin sinne trial hengessä pienen glassfish serverin, mysql kannan, ja noin 10 minuutin uurastuksella perinteiseen tapaan vältellen ohjeiden lukemista pystyssä oli hetken päästä toimiva ympäristö kurssin harjoituksille. Itse harjoitustehtävälle en tehnyt mitään muutoksia, tuuppasin paketoidun JPA:ta ja servlettejä sisältävän .war paketin suoraan Jelastic pilveen, mutta etukäteisvalmisteluna loin toki mysql kantaan uuden scheman, sille sopivat käyttäjätunnarit, kirjauduin glassfish hallintakonsoliin, loin mysql connection poolin, ja sen päälle datasourcen nimeltä jdbc/sample – jota harjoitustehtävä käytti.

Forum war paketti tuupattuna serverille

Yllättävän kivuton ja hauska prosessi. Toki trial serverillä serverien resurssit on kuristettu niin alas että sain sähköpostiin motkotuksia vähistä resursseista ja serverin kriittisestä tilasta. Mutta nehän korjautuvat rahalla, pilven idean mukaan sellaisen viipaleen saa mistä maksaa – ja mitä käytetään.

mysql_admin

 

glassfish_admin

Hauskaa oli havaita, että jopa serverin tiedostoihin pääsi vapaasti käsiksi. Serverin lib kansioon piti tietysti ladata mysql connector/j ajuri.

Näyttää että pilvet alkavat suomessakin olemaan elinvoimaisia. Odotellessa kummoisempia pilvistandardeja Java-maailmaan Java EE tekniikat toimivat jo hyvin ja sovellukset siirtyvät paikalliselta testipalvelimelta pilveen – toki oma oppimiskäyränsä on resursoinnissa ja hallinnassa, sekä vasteaikojen hiomisessa, mutta lupaavaa kumminkin. Taitaa olla takana ajat kun itsekin linux purnuja webin nurkalle pystyttelin oman huoneen nurkkaan :p

accesstoserverfilesandfolders

 

Tervetuloa vain mukaan pilven reunalle istuksimaan! 😉