About Arto Santala

Olen töissä räätälöityjen ohjelmistoratkaisujen parissa Solita- nimisessä firmassa, tämä blogi on kuitenkin omia, henkilökohtaisia mietteitäni varten. Käsittelen pitkälti ohjelmistokehitykseen liittyviä teemoja kuten Agile, SOA, ja erilaisia Java kirjastoja ja trendejä. Blogi on ennen muuta muistio itselleni, mutta sitä saa myös kernaasti kommentoida ;)

Java 10- Docker, ja mieletön automaatio

Meno on ollut niin vinkeää, etten ole hetkeen ehtinyt blogailla. Enkä ehdi vieläkään. Mutta jos seuraat vielä, niin tässä pari tärppiä, joiden parissa olen viime aikoina viihtynyt:

Java 10, Sprint Boot 2, modular jre, ja Docker mikropalvelut:

https://www.lyyti.fi/reg/Java_Workshop_Tre

Automatisoi ihan kaikki!

 

Mainokset

Spring Boot 2.0.0RC1 julkaistu

En ole hetkeen kirjoitellut omaa blogiani, olen pahasti laiminlyönyt sitä ja kirjoitellut firmablogin puolelle englanniksi. En paranna pahoja tapojani vieläkään, mutta linkkaan mehukkaan artikkelini Java 9 moduuleista, jlinkistä, Spring Boot 2.0 versiosta, ja Dockerista, ja miten ihania mikropalveluita niillä saakaan aikaan.

http://dev.solita.fi/2018/01/24/Java9-modules-Spring-Boot-2-Docker.html

Ja tähän tarpeeton kuva koiranpennusta

Ja tähän tarpeeton kuva koiranpennusta

Tänään Spring Boot pääsi 2.0 beta ja snapshot statuksesta eroon, ja julkaistiin release candidate 1. Se tarkoittaa, että rajapinnat on jo melkolailla hyydytetty, ja muutokset tapahtuvat syvemmällä ennen julkaisuversiota. Sen saa Mavenista imaistua mm. näin:

<parent>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-parent</artifactId>
    <version>2.0.0.RC1</version>
</parent>
<dependencies>
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-web</artifactId>
    </dependency>
</dependencies><repositories>
    <repository>
        <id>spring-milestones</id>
        <name>Spring Milestones</name>
        <url>https://repo.spring.io/libs-milestone</url>
        <snapshots>
            <enabled>false</enabled>
        </snapshots>
    </repository>
</repositories>

Mitä ihmeellistä siinä sitten on? No paljonkin. Itseä kiehtoo ensinnäkin se, että se toimii Java 9 version kanssa suoraan yhteen. Mikään Spring 1.x versio ei toimi, eikä tule toimimaan. Sen lisäksi siellä on mm. reaktiivista ohjelmointimallia tuotu perinteisen service mallin rinnalle, ja turvapuolen asioita möyhitty parempaan suuntaan. Laajempaa tarinointia mikä on uutta löytyy mm:

https://github.com/spring-projects/spring-boot/wiki/Spring-Boot-2.0.0-RC1-Release-Notes

Java 9 taas on ihanuutta mm. Stream api parannusten, jshellin, ja etenkin modulaarisuuden myötä. Tuossa linkkaamassani dev blogi artikkelissa mm. kuvataan, miten parisataamegaisesta JDK:sta saadaan tiristettyä muutaman kymmenen megaa kooltaan oleva virtuaalikone, joka pyörittää kyllä Spring Boot REST palveluita, mutta omaa paljon vähemmän turhaa kirjastoa ja koodia kuin ennen. Eli vähemmän tietoturvahaavoittuvuuksia, vähemmän levyn ja muistinkäyttöä.

Tuohon kun länttäät päälle Dockerin, aletaan olla jännän äärellä. Jos et tee jo serverlessiä, tuo on pino jolla taas pärjää pitkään.

Alunperin Java versio 8 oli menossa jo kohti elinkaarensa loppua tämän vuoden syyskuussa – mikä olisi tarkoittanut, että esim. tietoturvapäivityksiä ei siihen enää tipu. Mutta mene ja tiedä, joku ehkä tajusi miten iso paukku Java 9 siirtymä voi olla. Joten Java 8 EOL deadlinea lykättiin ja pehmennettiin isosti.

https://blogs.oracle.com/java-platform-group/extension-of-oracle-java-se-8-public-updates-and-java-web-start-support

Eli, Java versiolla 8 voi hyvin räpytellä vielä 2019 tammikuuhun asti, ja miksei pidemmällekin jos tykkää elää vaarallisesti. Tai voi maksaa tuesta Oraclelle tai IBM:lle ja räpytellä vuoteen 2025. Mutta toisaalta Java versioon 9 voi siirtyä vaikka nyt, heti, tänään. Itselläni se on jo ensisijainen JDK koneessa, ja ensisijainen valinta uutta tehdessä.

Eli ehkä tuosta taas vähän mietintöjä potkimaan vuosi 2018 käyntiin. Tietysti katsoessa tulevaisuuteen, Java versio 9 on jo aika legacyä – sehän on jo monella käytössä. Kiinnostaako Java version 15 julkaisuaikataulu ja tuki?

Lähde: https://www.infoq.com/news/2018/01/JavaSupportJan18

Tuosta ehti jo jokunen vääräleuka päättelemään, että turha päivitellä ysiin, kun samantien voi hypätä versioon 11, kun Java 8 tuki päättyy? 😉 Siitä lisää ehkä myöhemmin.

 

 

 

AWS Reinvent – ja Andy Jassyn keynote

No niin, AWS pilvipalveluiden julkistuksia on ammuttu taas matkaan sellaiseen tahtiin että päätä huimaa. Blogautin jo aiemmin esimaistiaisista, Sumerian ja Amazon Media Services. Nyt oli sitten Andy Jassyn keynote ja uutta palvelua pukkasi tiukkaan tahtiin, kaikille kentille. Sinällään fiilis on vähän sama kuin yleensäkin AWS palvelupalettia seuratessa, mutta nyt tapahtui parin tunnin sisään kaikki.

2017-11-29 07.17.34.jpg

Katsotaanpas muistiinpanoja..

Itse povailin jo etukäteenkin että Kubernetes saisi vähän rakkautta – ja se saikin, Amazon Elastic Container Service for Kubernetes eli tuttavallisemmin EKS julkaistiin. Kubernetes on yksi ihastuttava vaihtoehto konttien hallintaan kun puhutaan pikkasenkin suuremmista kokonaisuuksista, tai havitellaan rolling updates/canary deployment/green-blue deployment/etc tyylisiä ratkaisuja. Samalla julkaistiin Fargate palvelu – konttien hallintaa palveluna, tarvitsematta itse provisioida resursseja pysyvästi. Minä touhotan aina konteista, Dockerista ja Kuberneteksesta, joten olen miedosti innostunut.

2017-11-29 08.05.25

Uusia instanssityyppejä on julkaistu muutama, samoin Bare Metal instanssit. Summattakoon, että vääntöä löytyy tarvittaessa, ja nyt pääsee lähemmäs rautaa. Ei kuitenkaan ole tullut itsellä vastaan vielä tarvetta, joten let’s move on.

Pieniä juttuja jotka herättävät mielenkiintoa – Lambdoille CodeDeploy tuki, ja Weighted Routing. Lambdat nostavat enemmän ja enemmän päätään myös devaajan työkalupakissa, ja noiden avulla saa paremman tuen pipelineille, versioiden hallinnalle, rollbackeille, em. canary deploymentille (päästetään esim. 10% liikennettä uuteen versioon ja haistellaan tuotannossa onko kaikki kunnossa – ihanaa continuous deployment-microserviceille)

2017-11-29 08.06.09

Muita uusia palveluita jotka herättivät mielenkiintoa – Amazon Appsync on käytännössä GraphQL-kerros-palveluna, ja tarkoitettu eri asiakasohjelmien väliseen tilanhallintaan. Amazon MQ on käytännössä ActiveMQ-as-service. Storage-puolelle Aurora sai vahvistusta, siitä tuli Serverless ja Multi-Master vaihtoehdot, joten sekin alkaa vahvasti nostamaan profiiliaan vielä entisestä – muistuttaa paljolti Googlen Spanner-tarjontaa. DynamoDB veti AZ-replikoinnista Regionien väliseen replikointiin Global Tables-muodossa, ja sai parempia backup-vaihtoehtoja. Lopulta julkaistiin Neptune uutena palveluna – graph-database-as-service. Tämä vaatii itseltä vähän paneutumista ennen kuin uskallan sanoa juuta tahi jaata.

Mutta noista yhteenvetona, entistä enemmän saa taas palveluna, jolloin ei tarvitse maksaa tyhjästä ajasta, ja skaalautuminen ja päivitykset ovat vielä entistäkin automaattisempaa. Aurora ja DynamoDB vahvistavat kovasti asemiaan, ja uutta kivaa tulee. Eikä siinä vielä kaikki…

2017-11-29 08.29.29.jpg

S3 sai vahvistusta – nyt esim. analytiikan tarpeisiin pystyy louhimaan S3 tiedoista esisuodatuksella valikoiden, mitä haluaa sillä kertaa analysoida. Tässä siis kyseessä S3 select. Vieläkin huimempaa on Glacier select – valikoivaa louhintaa arkistoista. Aiemmin Glacier toimi lähinnä arkistoihin, joita ei koskaan/kovin usein kaivattu, ja sieltä tiedon haku kestää – otetaan ikäänkuin iso mappi kerrallaan tavaraa, vaikka käytettäisiin vain hippusta.

Machine Learning puolelle tuli vahvistusta, Deeplens, SageMaker muodossa. En sano näistä mitään kun en ole vielä syvällä teemassa, mutta isot pojat kohisevat näistä. SageMaker on käytännössä machine-learning-as-service, eli nostaa abstraktiotasoa tuoden sen helpommin muidenkin kuin superkoodaajien ulottuville. Deeplens laitteita on arvonnoissa luvassa per heti, ja jatkossa niitä saa muutamalla satalappusella. Niiden avulla voi opettaa koneita kuvamateriaalilla, ja siihen liittyen…

Amazon Rekognition Video ja Amazon Kinesis Video Streams – tunnistusta suoraan videolta/videovirrasta, ja tehokasta videovirtojen keruuta ja varastointia. Cool – and a bit scary stuff! Jo käytössä virkavallalla ainakin täällä jenkeissä… Suattaapi luoda jänniä hetkiä GDPR parissa täällä peräpohjolassa..

Ja lopulta, Amazon Translate, Amazon Comprehend, ja Amazon Transcribe. Kielen ymmärrystä ja käännöksiä, reaaliaikaisesti tai pidemmän, luonnollisen kielen mukaan. Puhetta tekstiksi. Palasia on ollut jo olemassa, mutta lisää korkeamman abstraktiotason palveluita, joissa koneoppiminen on jo sisäänrakennettuna. Sattuneesta syystä kiinnostaa kyllä!

Eikä siinä vielä kaikki, mutta onhan tätä jo tässsäkin! Huom! Julkistuksissa elinkaari vaihtelee, osa jo hienosti valmiina, osa vasta esimaistiaisena.

Kaiken kaikkiaan, AWS on pilvialustana isoin, vapain, ja energisin. Täällä tapahtuu ja on sykettä. Kehittäjillä ja rakentajilla on valinnan vapautta runsaasti. Vapauden myötä tulee tietysti myös suuri vastuu, kyllä näillä rakennuspalasilla voi ampua itseään pahasti jalkaan, ja yritys joka syöksyy suinpäin pilveen takamus edellä, maksaa kalliit läksyt virheistään. If you got one account for all you’re doing it wrong! If you’ve got personal accounts for builders you’re doing it wrong! Onneksi asiansa osaavat pilviarkkitehdit auttavat näissä asioissa mielellään. *oman hännän nosto*

Luonnollisesti keynoteen sisältyi myös ystävällismielistä ja vähän vähemmän ystävällismielistä kettuilua Oracle, Microsoft ja Google suuntaan. Syystäkin – AWS on iso, innovatiivinen, innostava ja … ihana? 😉 Lisää detaileja mm. Solitan dev-blogissa. Tällä alustalla tapahtuu!

2017-11-29 08.41.34

Linkkejä:

http://dev.solita.fi/

https://aws.amazon.com/blogs/aws/

https://aws.amazon.com/blogs/aws/introducing-amazon-appsync/

https://aws.amazon.com/blogs/aws/amazon-mq-managed-message-broker-service-for-activemq/

https://aws.amazon.com/blogs/aws/amazon-elastic-container-service-for-kubernetes/

https://aws.amazon.com/blogs/aws/aws-fargate/

https://aws.amazon.com/blogs/aws/in-the-works-amazon-aurora-serverless/

https://aws.amazon.com/blogs/aws/new-for-amazon-dynamodb-global-tables-and-on-demand-backup/

https://aws.amazon.com/blogs/aws/amazon-neptune-a-fully-managed-graph-database-service/

https://aws.amazon.com/blogs/aws/s3-glacier-select/

https://aws.amazon.com/blogs/aws/sagemaker/

https://aws.amazon.com/blogs/aws/deeplens/

https://aws.amazon.com/blogs/aws/launch-welcoming-amazon-rekognition-video-service/

https://aws.amazon.com/blogs/aws/amazon-kinesis-video-streams-serverless-video-ingestion-and-storage-for-vision-enabled-apps/

https://aws.amazon.com/blogs/aws/amazon-transcribe-scalable-and-accurate-automatic-speech-recognition/

https://aws.amazon.com/blogs/aws/introducing-amazon-translate-real-time-text-language-translation/

https://aws.amazon.com/blogs/aws/amazon-comprehend-continuously-trained-natural-language-processing/

https://aws.amazon.com/blogs/aws/aws-iot-device-management/

https://aws.amazon.com/blogs/aws/in-the-works-aws-sepio-secure-your-iot-fleet/

 

Ensivaikutelmia Re:Invent 2017 tapahtumasta Las Vegasissa

Fuck the desert.

Jotain tuonsuuntaista ovat varmaan Las Vegasin perustajat ajatelleet, kun alkoivat rakentamaan. Koko kaupunki on mielipuolinen esitys jossa korostuvat pöyhkeys, liiottelu, ja vastakohdat. Tottakai täytyy rakentaa jättimäisiä uima-altaita ja suihkulähteitä keskelle autiomaata, jossa vedestä on pulaa. Tottakai pystytetään neon-kylttejä kaikkialle ja rakennetaan teemapuistoja ja kaikenlaisia huomion kiinnittäjiä kunnes öisin voisi kuvitella astuneensa Blade Runner elokuvaan. No niin, paitsi tietysti sade. Las Vegas on ahnas, julma koneisto joka on suunniteltu rutistamaan vierailijoista kaikki raha ulos viimeiseen tippaan. Se on myös kaunis, ja ihastuttavan kunnianhimoinen yli kaikkien järkevien rajojen.

PB270158.JPG

Tällaiseen ympäristöön posahti tänä vuonna yli 40 000 pilvi-ninjaa tekemään vuosittaisen pyhiinvaellusmatkansa, osallistuakseen AWS Re:Invent konferenssiin. Viikko hullua ja hektistä menoa, niin paljon tietoa sulateltavaksi, logistisia haasteita ratkottavaksi, niin paljon ihmisiä. Ehkä konferenssista alkaa tulemaan vähän liiankin iso: Jonot olivat valtavia, järjestelyt pettivät pahastikin aika ajoin, ja Redditissä syntyi ihan vihasäie tämän vuoden konferenssia koskien. Matka hotellien välillä kesti noin 30-60 minuuttia, jo saman hotellin sisällä paikasta toiseen menee helposti 20 minuuttia siirtymiseen. Ellei ole varannut etukäteen paikkaa esitykseen, on turha unelmoida pääsyst sisään. Jonot olivat täysin mielettömiä. Mutta kaiken kaikkiaan – täysin kaiken tuon arvoista.

2017-11-27 07.14.41

Olen ollut pilvipalveluiden käyttäjä ja fani jo pitkiä aikoja, mutta softaa rakentaessa käyttö osui pääosin peruselementteihin kuten S3, EC2, ja IAM. Kun aloitin nykyisessä työpaikassani, Solitalla, altistuin data ja analytiikkapuolen kuvioille, ja uusi maailma aukeni edessäni. En ollut huomannutkaan miten paljon AWS oli kasvanut palveluiden suhteen niin nopeasti. Nykypäivänä alkaa olla aika typerää kohdella AWS:ää vain virtuaalipalvelin-pilvenä. Jos haluaa löytää aitoa skaalautuvuutta ja kustannustehokkuutta, hyvä ajatusleikki on miettiä mitä tapahtuu jos EC2 osan poistaa kokonaan yhtälöstä. Paletista löytyy niin hurjasti kaikenlaista mistä voidaan koostaa uutta – ja lisää tulee koko ajan. Ja siitä puheenollen…

Mitä uutta?

Seminaari ei ole ohi – se jatkuu edelleen muutaman päivän verran, ja varsinaiset keynotet ovat vasta tulossa. Olen varma, että niissä julkaistaan mehukkaita uusia juttuja, jotka saavat alkuviikon julkaisut kalpenemaan. Mutta ihan mielenkiintoista uutta löytyi jo alkuviikostakin.

Esim. Amazon Sumerian julkaistiin. Kyseessä on uusi VR/AR työkalupakki, esim. Oculus Rift ja HTC Vive tyyppisille laitteille, ja kun Amazon seisoo sen takana, voin kuvitella että työntövoimaa piisaa. Kun lisäksi VR settien hinnat ovat juuri about puolittuneet, ja sitä myöden ostomäärät kohisten nousseet, voin nähdä tässä kentässä aika mielenkiintoisia mahdollisuuksia. Amazonin ansiosta ne tulevat helpommin saavutettavaksi. Rekisteröidyin itse kiinnostuneeksi tästäkin tekkipinosta, ja pengon lisää jahka saan jotain konkreettista. Olen itse työskennellyt viime aikoina paljon paikkatiedon ja karttojen parissa, ja on pari ideaa miten ne voisivat kohdata VR:n.

Toinen kiinnostava aihe oli useat sessiot Devops ja Secops teemoista, sekä automaatiosta, mikä on oma kiihkoilun kohde. Jos teet saman asian kahdesti, kannattaa jo automatisoida se. Mitään uutta järisyttävää julkaisua ei vielä ole tullut, mutta paljon parhaita käytäntöjä ja kokemuksia siitä miten tämä toimii eri ympäristöissä. Uskon vahvasti siihen, että tietoturva-vaste kannattaa automatisoida niin pitkälle kuin sen voi. 2010-luvulla kun joudut hyökkäyksen kohteeksi, minuutitkin voivat ratkaista. Automatisoimalla fiksusti pystyt suodattamaan kiinnostavan taustahälystä, ja ratkaisemaan osan tilanteista vaikka keskellä yötä, ennen kuin ihmispäivystäjä ehtii edes sen huomata. Automatiikka myös skaalautuu hienosti alaspäin, projekteihin joissa ei voida unelmoidakaan SOC tiimeistä tai päivystyksestä ympäri vuorokauden. Lisäksi GDPR tietosuoja-asetuksenkin suhteen saadaan paljon hyötyä siitä, että vältetään ns security misconfiguration – konfiguraatiovirhe joka johtaa tietoturva-aukkoon. Näitä on sattunut… (katso linkki lopussa)

Tietoturvan automatisointi

Korvaako Lambda SOC tiimisi? Tietystikään ei, mutta olisi idioottimaista olla viemättä automaatiota niin pitkälle kuin se taipuu. Hyvä mittapuu on se, kun ihmisten elämä käy pitkäveteiseksi. Se on merkki siitä, että rutiinitehtävät on onnistuneesti automatisoitu, ja on aika hakea lisää haasteita, korkeampia tasoja tekemiseen. Automaatiolla voidaan saavuttaa nopeampi vaste, ja esim. DDOS hyökkäyksen tapahtuessa nopeampi automaattinen toipuminen. Useimmissa tapauksissa manuaalinen vastaus tietoturvahyökkäykseen tai tapahtumaan on aivan liian myöhässä auttaakseen – siinä kohtaa vain kerätään forensiikkaa ja yritetään ymmärtää mitä tapahtui.

DDOS hyökkäyksistä puheenollen, ne ovat aina vain yleisempiä näinä päivinä, ja AWS tarjoaa paljonkin niitä vastaan. Lisääkin on tulossa. Tavoitteena on ns no-op security, koska mitä näkymättömämpää tietoturva on, sitä paremmin se toimii. Jos tietoturva riippuu monista manuaalisista askeleista, se on kovin altis inhimillisille virheille ja viiveille. Jotta DDOS hyökkyksestä voi toipua, on syytä pysäyttää helposti havaittavat hyökkäykset jo etuporteilla, ja skaalata taustaa moneen suuntaan hienostuneempia hyökkäyksiä vastaan. Vain pilvi voi tosiasiassa tarjota tätä.

2017-11-27 13.44.12.jpg

Mediatiedostojen käsittelyyn tuli myös uutta, AWS Elemental tuoteperhe. Videotiedostojen elinkaari ei ole tähän asti ollut tärkeänä osana projekteissa joita teen, mutta näistäkin vaihtoehdoista on mukava tietää, ei koskaan tiedä jos vaikka seuraava projekti sukeltaisi näihinkin syvyyksiin. Tottakai myös Helsinki on saanut tässä kuussa lisää AWS rakkautta: Jo ennen ReInvent tapahtumaa julkistettiin DirectConnect saatavuus Helsingissä, ja nyt julkistettiin CloudFront Edge Location, myös Helsingissä. Käytännössä: Soundcloud striimaa nyt nopeammin 😉

Jo muutaman päivän jälkeen olen väsynyt, mutta samaan aikaan latautunut ja innostunut. Kuten useinkin suurissa seminaareissa, ihmisten energia ja kokemukset ja näkemykset ovat se paras anti. Pilvi on juuri nyt se paikka missä tapahtuu, ja pilven rakentajina meillä in suuri vastuu tehdä asiat oikein, ja näyttää suuntaa. Odotan malttamattomasti, mitä jää vielä haaviin tulevina päivinä – otin sinne mm. annoksen Alexaa koska povailen sille menestystä ensi vuoden aikana, ja näyttää että se on tämän vuoden ReInventin hittitavaraa muutenkin.

Links:

Solita dev-blogi
Sumerian VR/AR
Cloudfront edge locations, Directconnect new locations
Amazon Mediastore
S3 breaches
AWS Elemental MediaStore
AWS Elemental MediaConvert
AWS Elemental MediaLive
AWS Elemental MediaPackage
AWS Elemental MediaTailor

 

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ä!

 

Java 9 on ulkona

No niin, tällä kertaa vain nopea heads-up, eli Java 9 putkahti juuri putkesta:

http://www.oracle.com/technetwork/java/javase/downloads/index.html

Olen blogaillut tästä jo useampia kertoja, mutta nyt on aika asentaa se ja ottaa ensisavut, katsoa miten release versio toimii käytännössä.

jrepl ja modulet paukkumaan.

[edit]

Tuikataan nyt heti tähän huomio: Spring 1.x ei futaa JDK 9 kanssa, ei siis käänny, eikä tulekaan kääntymään. Siellä on sorkittu JDK internalseja joita ei enää ysissä saa sorkkia.

Spring 2 tulee tukemaan Java versiota 9 – Milestonesta 4 alkaen pitäisi jo periaatteessa tukea. En ole vielä ehtinyt varmentamaan.

GDPR – Tietosuoja ja sovelluskehitys osa 1

Pyydän jo etukäteen anteeksi, tämä jos mikään on TL;DR settiä. Asiaa on vain aika vaikeaa kuvata ytimekkäästi, tahoja on monia. Jos artikkelin pituus haittaa lukemista, asennoidu lukemaan vaikka yksi kappale päivässä. Ota mukaan yhtälöön kupillinen mielijuomaasi, ja hyvää musiikkia taustalle, niin kyllä se siitä. Lupaan että substanssi on rautaa, kuittaa kommentteihin jos olet eri mieltä – saa toki kuitata vaikka olisi samaakin 😉

Totean myös, että en ole lakimies, ja tällä hetkellä tietosuoja-asetuksessa on monia alueita joista edes lakimiehet eivät voi sanoa mitään varmaa. Paras viisaus on jälkiviisaus, ja vuonna 2027 osaan kertoa faktaa. Tässä kohtaa kaikki blogautusten pointit edustavat omia näkemyksiä, jotka ovat ilman muuta ainutlaatuisen arvokkaita ja fiksuja. Mutta osa niistä on väistämättä tässä kohtaa ennustellessa väärin, ja tulkinnat tulevat sen aikanaan todistamaan. Toivon kuitenkin että mahdollisimman pieni osa.

Miksi jotain kannattais tehdä?

Tietosuoja-asetuksen siirtymä-ajan päättyessä 2018, sovellukset jotka eivät tue uusia vaatimuksia ja käyttäjän oikeuksia, muodostavat merkittävän liiketoiminnallisen riskin yrityksille. Olemassaolevien sovellusten, järjestelmien, rekisterien ja infran osalta muutos on kivuliaampi. Helpompi on alkaa tutkailemaan ihannetilaa uusien sovellusten osalta, joita vielä vasta suunnitellaan tai rakennetaan, ja tulevaisuuden sovellusten osalta, joita tullaan rakentamaan jatkossa. Ajatuksena on, että aikaa myöten opitaan ottamaan tietosuojavaatimukset huomioon automaattisesti, ja niistä tulee yhtälailla sisäänrakennettu osa kaikkea tekemistä kuin esim. sovelluksen toimivuuden testauksesta eri selaimissa. Ja tätä myöden myös kuluja saadaan alas/opitaan laskemaan ne luonnolliseksi osaksi tekemistä ja testaamista.

Ok, tylsä johdanto. Terästetäänpä tätä toisin. Kun Harri H Hakkeri eräänä päivänä penetroi systeemin ytimeen, haluamme rajoittaa riskiä siitä miten paljon sakkoja tulee maksettavaksi, ja kuinka laajaa osaa asiakasrekisteriä joudut kontaktoimaan tietosuojamurron osalta, sekä millä sävyllä iltapäivälehdet repostelevat asiaa.

On väärinkäsitys ajatella myös, että tämä koskee vain suuria organisaatioita. Sen verran uskaltaudun ennustamaan tulevaisuutta, että muutamakin keskikokoinen paja tulee ajautumaan konkurssiin jos tietosuojan kanssa ollaan leväperäisiä tai peräti röyhkeitä. Tietämättömyys tai pää puskaan-strutsiefekti ei ole tässä puolustus tai suojautumiskeino, päinvastoin. Se että yrittää vaikkei 100% onnistuisikaan, lasketaan todennäköisesti eduksi ja sakkoja tai sakon uhkaa merkittävästi pienentäväksi tekijäksi.

TL;DR

No, tässä kuitenkin tiivistelmä, mitä tulisi huomioida sovelluskehityksessä vuonna 2017, ja projekti/järjestelmätasolla noin muutenkin. Jos muistan, rupattelen infratason ratkaisuista ja hallinnasta, ja organisaatiotason prosesseista lisää toisella kertaa.

  • Riskilähtöisyys: tunnista, minimoi, dokumentoi
  • Henkilötietojen esiprosessointi: Tunnista, minimoi, dokumentoi
  • Sama juttu 3. osapuolien riippuvuuksien osalta: tunnista, minimoi, dokumentoi
  • Sama juttu henkilötiedon prosessoinnin osalta myös sisäisesti: tunnista, minimoi, dokumentoi
  • Tiedon elinkaari: määrittele,minimoi, toteuta, dokumentoi
  • Varmuuskopiot ja arkistointi, huomioi kaikki edellämainitut
  • Testidata, huomioi kaikki edellämainitut
  • Testiympäristöt, tarkkana myös tämän kautta
  • Verkkoinfra, verkkosegmentointi, minimoidaan vahingot, maksimoidaan jäljet
  • Tietoaineiston suojaus: anonymisointi,pseudonymisointi,salaus
  • Käytön valvonta, monitorointi, hälytykset
  • Kyvykkyys osoittaa tehdyt toimenpiteet, ja prosessien toteutuminen
  • Murtautumistapauksessa: prosessien tuki, forensiikka, hälytykset
  • Tietoturva-ja muut päivitykset
  • CI- ja CD- toimitusputkien suojaus ja tietoturva
  • Huom. Myös availability, saatavuus, on tietosuoja-huolenaihe
  • Henkilön oikeudet uuden tietosuoja-asetuksen alaisuudessa, käytännön toteutus?

 

Oletusarvoinen tietosuoja tähtää aikalailla samaan asiaan kuin itse tietosuoja-asetuskin – riskipohjaiseen lähestymistapaan. Ja se taas tarkoittaa että matalan riskin järjestelmiä voidaan suojata keveämmin kuin korkean riskin järjestelmiä. Eli askel numero 1…

Tunnista henkilötiedot, tunnista riskit

Tietosuoja-asetuksen kannalta riskin näkökulma on vähän eri kuin yrityksen kannalta – mutta riskin kohde on silti sama, henkilötiedot. Aiemmin puhuttiin jo siitä, miten tietoa voidaan tunnistaa, luokitella. Järjestelmissä on paljon tietoa, joka ei ole tietosuoja-asetuksen mielessä kiinnostavaa, mutta on silti ollut – ja tulee olemaan – hyvin tarpeellista suojata, esim. tuotetiedot, strategiat, ennusteet. Se mitä ei tietosuoja-asetus määritä henkilötietoksi, on kuitenkin oman harkinnan mukaan edelleenkin vapaasti suojattavissa ja käytettävissä, miten halutaan. Henkilötiedon suojaamiseen taas löytyy GDPR suunnalta kättä pidempää.

Se, minkä voi rajata pois tietosuojalain tarkoittaman henkilötiedon piiristä, voidaan salata – tai jättää salaamatta – vapaasti miten halutaan.

Tietosuoja-asetuksen välineenä käytetään pitkälti DPIA analyysiä. DPIA, eli Data Protection Impact Analysis, on vaikutusten arvioinnin malli, jolla voidaan analysoida riskikulmaa. Ennestään käytössä on monessa yrityksessä ollut PIA, Privacy Impact Assessment, joka on tähdännyt samalle alueelle, mutta hieman laveammalla pensselillä. Molemmissa on ajatuksena määrämuotoinen ja kattava tarkastelu järjestelmässä kerättävälle tiedolle. Molemmat perustuvat riskien hallinnan ajatukseen. Eli analysoidaan kerättävän tiedon riskien taso, ja sen jälkeen, riskipohjaisesti, sovelletaan sopivia kontrolleja, kunnes riski saadaan laskettua hyväksyttävälle tasolle.

DPIA mallia ei tarvitse soveltaa joka järjestelmään, mutta jonkinmoinen esikarsinta olisi tietysti aina hyvä tehdä. Periaatteessa järjestelmän tavoiteltu tietosuojataso määräytyy aika yksinkertaisesti sen mukaan, mikä on sen sisältämä riskialttein yksittäinen tieto, eli vaikka muu järjestelmä olisi aika tylsä, jos yhdestä taulusta löytyy sairauspoissaolojen syitä, se määrittää aikalailla järeimmän kautta suojaustarpeen.

Tähän väliin on hyvä todeta oma lempiteesini. Sataprosenttista tietoturvaa ei ole. Sataprosenttista tietosuojaakaan ei ole. Jokainen järjestelmä voidaan murtaa, jokaiseen dataan päästä käsiksi, jos tarkastellaan asiaa rajattoman ajan, ja rajattoman budjetin suunnasta. Lisäksi tietojärjestelmät elävät mutatoituvassa maailmassa – järjestelmä joka on tänään 99% turvallinen, kokee muutoksia vuoden aikana, ja voi ensi vuonna ollakin vain 70% turvallinen, koska sen ympäristöön on vuoden aikana tullut uusia komponentteja, avauksia, muutoksia, tai vanhoista komponenteista on löytynyt haavoittuvuuksia. Yksi suurimmista tietoturva-haavoittuvuuksista on security misconfiguration, eli virhe ympäristöjen asetuksissa, ja niitä pujahtaa sisään helposti myös järjestelmiin jotka olivat luotaessa arkkitehtuurisesti kauniita ja täydellisiä. Kun huomioidaan prosessit, ympäristöt, teknologiat, muuttujia on vain niin paljon, ettei kukaan voi väittää hallitsevansa niitä kaikkia, nyt ja aina, ja vaikka istuisit palvelimen päällä haulikko kädessä vahdissa 24 tuntia vuorokaudessa, niin mörkö pujahtaa sisään heti jos herpaannut hetkeksi. Ja ensi vuonna voi olla että istut väärän palvelimen päällä.

Eli, ainoa oikea lähestymistapa on tunnistaa suurin riski, madaltaa sitä sopivin keinoin, ja jatkaa kunnes ollaan hyväksyttävällä riskitasolla. Lisäksi tätä ei voi tehdä kertarysäyksenä, projektina, vaan tietosuojan täytyy olla jatkuva prosessi.

Tai vielä mielummin sisäänrakennettu, läpinäkyvä osa prosesseja, kaikkea tekemistä. Siihen on vielä useimmilla yrityksillä pitkä aika. Valitettavasti monet ottavat lähtölaukauksen tekemiseen vasta ensi kesänä, kun uhat alkavat toden teolla realisoitumaan.

Tietosuoja-asetuksen kannalta erityisriskin muodostavia tietoja, joihin tulee kiinnittää erityistä huomiota, ovat mm.

  • Alaikäisistä rekisteröidyistä kerätyt tiedot (vaikka rekisteröity sittemmin olisi jo täysi-ikäinen)
  • Rotu,uskonto,politiikka,terveydentila,rikosrekisteri eli eiheet jotka monen mielestä eivät ole hyviä ruokapöytäkeskustelun aiheita (mutta omasta mielestäni niitä kiintoisimpia, moukka kun olen!)
  • Biometriset tunnisteet

Eli näitä tietysti suojataan rankimman kautta. Hyvä huomata kuitenkin, että ns kovan ja yksilöivän henkilötiedon ohella, myös identiteettiin liittyvää tietoa koskee moni tietosuoja-vaatimus, esim. henkilön oikeudet. Ja se mikä liittyy identiteettiin voi joissain tapauksissa olla yksilöivää, ’jos yksilöinti voi tapahtua kohtuullisella vaivalla tietoja yhdistelemällä’ – esim. muutama erillinen paikkatieto, tai erityinen tietopaketti harvaan asutulla alueella, jne – eli samalla lailla kuin itse identifioivaa tietoa, voi varautua suojaamaan myös identiteettiin liittyviä tietoja.

Toinen tapa lähestyä riskiä on miettiä ihan terveellä järjellä, miten suuren riskin REKISTERÖIDYLLE muodostaa, jos tämä tieto julkaistaisiin iltapäivälehden etusivulla. On hyvin tärkeää muistaa, että tietosuoja-asetuksen riskianalyysissä riskin näkökulma on aina rekisteröity, ei rekisterinpitäjä. Se näkökulma määrää, miten raskaasti tietoa tulisi suojata ja vartioida.

Toisaalta samoja periaatteita voi myös soveltaa muuhun sensitiiviseen tietoon, vaikka ei henkilötietoa olisikaan. Se ei ole tietosuoja-asetuksen kannalta mielenkiintoista, mutta voi olla liiketoiminnan kannalta hyvinkin mielenkiintoista.

Minimoi ja dokumentoi kerättävä tieto

No niin, nyt tulee se hyvä uutinen. Paras tapa keventää kuluja ja suojauskontrollien tarvetta, on olla keräämättä sitä henkilötietoa alunperinkään. Ennen vanhaan oli tapana keräillä kaikenlaista ihan vain varmuuden vuoksi, ties vaikka sitä jossain raportissa tai analyysissä kaivattaisiin, ja miksikäs ei. Sellainen lähestymistapa ei enää tietosuoja-asetuksen aikana kanna pitkälle.

Nyt kannattaa aloittaa miettimällä, mitä tietoa todella tarvitaan, ja millä oikeudella sitä kerään, varastoin, prosessoin. Tämä osa kannattaa dokumentoida hyvin, ja keskustella niistä harmaista alueista, joista ei olla varmoja. Voi myös miettiä sitä, voiko henkilötietoja eristää esim. omaan erilliseen järjestelmään, palveluun, kantaan, tauluun, jota voidaan suojata järeämmin kuin muita.

Sen ohella että minimoidaan siis ’leveyssuunnassa’ kerättävää tietoa – kyseenalaistamalla jo alun alkaen mitä kenttiä laitetaan, mitä tietoja kysellään – kannattaa myös huomioida aikadimensio, eli minimoida miten pitkään tietoja säilytetään. Minimointi ei tarkoita, että kaikki tieto pitäisi heti pyyhkiä, mutta tiedon elinkaaren suunnittelu on erittäin hyvä käytäntö ottaa mukaan tietomalliin alusta alkaen. Elinkaari voi olla vaikkapa puoli vuotta, tai viisi vuotta, kymmenen vuotta, jne. Mutta kun se ymmärretään, dokumentoidaan, ja toteutetaan, on taas pienennetty merkittävästi hyökkäyspinta-alaa.

Jos tapahtuu se pahin, eli huomataan tietomurto tai väärinkäytös järjestelmän ytimessä, muualle arkistoitu ja erikseen suojattu, tai täysin poistettu tieto voi olla sellaista, jota tietomurron ei katsota koskevan, ja näin ollen joudutaan kontaktoimaan vain niitä, joiden tiedot ovat aktiivisessa kannassa. Lisäksi tämäntyyppinen elinkaariajattelu ja suojauskontrollit lasketaan eduksi jos joudutaan jotain sakkorangaistuksia tai muita sanktioita miettimään.

Mutta siis, vanha tapa kerätä kaikki mahdollinen, ja säilyttää sitä ajan tappiin on huono käytäntö, ja sitä ei enää pitäisi harrastaa. Ja jos tiedon pinta-alaa tai säilytysaikaa ei pysty fiksusti minimoimaan, ainakin se kannattaa dokumentoida. Dokumentaatiota tulisi tuottaa sekä järjestelmäkehityksen ja ylläpidon tarpeisiin, että myös rekisteröidyn selosteeseen, jotta läpinäkyvyyden periaate toteutuu. Ja jos rekisteröity pystyy ymmärtämään kerätyn tiedon laajuuden, syyt, ja elinkaaren sen perusteella, pyynnöt esim. poistaa tietojaan järjestelmästä saattavat harventua.

Varaudu kuvaamaan MITÄ kerätään, MIHIN tarkoitukseen, ja MITEN sitä prosessoidaan (aka keiden toimesta). Varaudu tarjoamaan yhtä helpot keinot myöntää lupia tiedon keruuseen ja käyttöön, kuin lupien tarkistamiseen ja poistamiseen.

Minimoi pääsy

Tietosuojassa ei ole kyse vain ulkoisista tietomurroista, yli 30% väärinkäytöksistä tapahtuu verkon sisäpuolella, usein omien työntekijöiden, nykyisten tai entisten, toimesta. Huonosti suunnitellussa (tai monimutkaisessa, suurikokoisessa, iäkkäässä) verkossa voi olla myös pääsyä partnereilla, ulkoisilla työntekijöillä, konsulteilla, vuokratyöntekijöillä, tai miksei myös sovelluskehittäjillä, ylläpitäjillä, järjestelmätoimittajilla, jne.

Motiiveja voi olla esim. uteliaisuus, pyrkimys hyötyä, vandalismi, jne. Tietosuoja-asetus on tältä osin hyvin yksinkertainen. Henkilötietoon ei tulisi olla pääsyä enempää kuin mitä on tarpeen. Se mitä on tarpeen tulisi olla dokumentoituna. Eli ei ole kiellettyä että ylläpitäjillä on pääsy tietoon, kunhan se on läpinäkyvää. Eri asia on millaisen riskin se muodostaa.

Jos jotain tapahtuu, pääsyn minimointi myös voi rajoittaa vahinkoja, tai parantaa mahdollisuuksia näyttää toteen, mitä osaa tietoja tietomurto tai tietosuojaloukkaus koskee.

Näissä on hyvä suunnata huomiota terveydenhuollon järjestelmien suhteen, Suomessa ja muualla. Niissä on jouduttu jo iät ja ajat huomioimaan potilastietojen luottamuksellisuus, ja sieltä löytyy hyvin ideoita, käytäntöjä, toimintatapoja. Eri asia on, onko niitä terveydenhoidon järjestelmissäkään aina toteutettu ideaalisti. Mutta siellä on jouduttu jo pitkät ajat vastaamaan tällaiseen vaatimukseen.

3. osapuolen prosessointi

Tietosuoja-asetus ei estä sitä että dataa voi nyt ja jatkossakin prosessoida myös 3. osapuoli. Itse asiassa, prosessoijaksi kun lasketaan myös esim. pilvipalvelutarjoajat, kuten Amazon AWS, ja Microsoft Azure, enenevässä määrin toimitaan ympäristössä jossa on useampia osapuolia prosessoijina.

Nyt mennään alueelle joka ei ole omaa vahvinta aluetta: Lakipykälät ja niiden tulkinta. Mutta vapaasti oman ymmärryksen mukaan tärkeää on huomioida tämän osalta dokumentointi, ja sen mukana tulee luonnollisesti muut hyveet, kuten tiedon ja pääsyn minimointi ja suojaus, sekä sopimukset. Sopimustekniikka tulee varmaan tässä vielä kehittymään vuoden sisään, esim. Amazon on luvannut että ensi vuoden kesään mennessä tulee olemaan tietosuoja-asetuksen edellyttämät asiat huomioituna palvelusopimuksissa.

Se missä tulee olla tarkkana, on yhteisen vastuualueen kasvu, ja se missä rajat kulkevat. Moderni tietojärjestelmä on kokonaisuus jossa on aika monia tahoja. Jos nyt sattuisi että esim. AWS vastuunjakomallin mukaisesti tietosuojaloukkaus on tapahtunut 3. osapuolen tontilla, esim. medioiden huolimattoman hävityksen, tai fyysisen tietoturvan puutteen vuoksi, kantaako Amazon myös rahallista vastuuta sakoista, ja minkä firman liikevaihdon mukaan se menee? Entä jos 3. osapuoli ei olekaan AWS, joka sinällään on rutinoitunut ja ison talon koneisto, vaan autotallissa majaileva analytiikkafirma?

Mitä ajan takaa tässä, on pari huomiota. Tulkinnat tulevat elämään ja muotoutumaan vielä vuosia, sitä mukaa kun ikäviä asioita tapahtuu. Ja jatkossa ei riittäne pestä käsiään tietoturvasta ja tietoturvasta siinä kohtaa kun data siirtyy 3. osapuolen käsiin. Yhteisvastuullisuus on päivän sana, ja hyvä niin.

 

Jatkuu ensi numerossa…

No niin, kuten varoittelin, tästä tulee pitkä juttu. Kulmia on monia. Kirjailen lisää ajatuksia toisella kertaa, mennen lähemmäs kehittäjän konkretiaa. Osa näistä asioista, kuten 3. osapuolen sopimukset, eivät ole välttämättä heti toimittajan mielestä ehkä asioita joihin voi vaikuttaa, mutta softaprojektissa tulisi asianmukaisen matkaopastelijan kiinnittää huomiota siihen, miten asiat kokonaisuutena tehdään. Jos joku osa-alue on rempallaan, siitä kannattaa keskustella, ja kiinnittää huomiota, vaikka sieltä voisikin löytyä lisäkuluja.

Osittainen tietoturva on hyödytöntä tietoturvaa.