Blogi

Asiakas edellä – Teemu Peräkylä osaksi Webscalea

Wed, 22 Apr 2026 06:32:22 GMT

Rekrytointiprosessi vakuutti

Webscale herätti Teemun kiinnostuksen jo rekrytointivaiheessa erityisesti osaavan organisaation ja sujuvien keskustelujen ansiosta. Prosessin aikana syntyi selkeä kuva tekemisestä ja siitä, millaiseen tiimiin hän olisi tulossa.

Ensimmäiset kuukauden Webscalella ovat vastanneet odotuksia ja jopa ylittäneet ne. Teemun mukaan erityisen positiivista on ollut se, että rekrytointivaiheessa käydyt keskustelut ovat pitäneet paikkansa myös arjessa.

Sovitut asiat näkyvät konkreettisesti tekemisessä, eikä kyse ole ollut vain rekrytointivaiheen aikana luodusta illuusiosta. Vastaanotto on ollut lämmin, ja omaa osaamista sekä näkemyksiä on ollut helppo tuoda esille heti alusta alkaen.

Asiakkaan ymmärtäminen keskiössä

Teemun työssä korostuu ennen kaikkea asiakkaan ymmärtäminen sekä yhteistyö. Hän ei näe rooliaan ainoastaan uusien asiakkuuksien avaamisena, vaan ennen kaikkea lisäarvon tuottamisena ja asiakkaiden auttamisena eteenpäin sekä asiakassuhteiden kehittämisenä.

Käytännössä tämä tarkoittaa pilvipalveluiden ja asiantuntijatyön yhdistämistä asiakkaan tarpeisiin sopivaksi kokonaisuudeksi. Tavoitteena on tarjota ratkaisuja, jotka ovat sekä tietoturvallisia että aidosti liiketoimintaa tukevia.

Teemun mukaan keskeistä on asiakkaan tilanteen ymmärtäminen ja siihen oikean ratkaisun löytäminen. Häntä motivoi erityisesti se, että työssä näkee oman tekemisen vaikutuksen – se, kun ratkaisut toimivat käytännössä ja auttavat asiakasta kehittämään omaa toimintaansa.

Lupaukset näkyvät käytännössä

Ensimmäisten kuukausien aikana yksi asia on noussut erityisen vahvasti esiin: asiakaspalaute.

Teemun mukaan on poikkeuksellista, miten vahvasti asiakkaiden tyytyväisyys näkyy arjessa. Webscale toimii niin kuin lupaa, ja se heijastuu suoraan asiakaskokemukseen.

Myös sisäinen tekeminen saa kiitosta. Webscalen keskustelukulttuuri on avoin, ja eri rooleissa työskentelevien asiantuntijoiden kanssa on helppo sparrata. Luottamus näkyy arjessa ja työnantaja tukee työssä onnistumisessa.

Hyvä fiilis ja toimiva arki

Työn vastapainoksi Teemu viettää aktiivista arkea liikunnan ja harrastusten parissa. Judosta on muodostunut tärkeä laji, jossa hän toimii juniorivalmentajana sekä treenaa myös itse aktiivisesti. Vuoden 2026 tavoitteena on sinisen vyön saavuttaminen. Arkea tasapainottavat perheen kanssa vietetty aika, ja Teemun voi löytää myös veneilemästä, maastopyöräilemästä ja talvisin harrastejääkiekkoilemasta. Lisäksi Teemu toimii aktiivisesti Loviisan kunnallispolitiikassa ja oman asuinalueensa kyläyhdistyksen puheenjohtajana.

Ensimmäisistä kuukausista Webscalella Teemulle on jäänyt ennen kaikkea hyvä kokonaisfiilis. Työvälineet ja puitteet ovat kunnossa niin toimistolla kuin etänäkin, mutta erityisesti yhteishenki on tehnyt vaikutuksen: tekemisessä on sopivaa rentoutta, avoimuutta ja halua kehittää asioita yhdessä.

Tervetuloa tiimiin!

On ollut mahtava saada Teemu osaksi työyhteisöämme. Yhteistyö Teemun kanssa on sujuvaa ja mutkatonta, ja hän tarttuu asioihin oma-aloitteisesti hyvällä asenteella. Teemun kanssa on helppo tehdä töitä, ja hän on päässyt hyvin mukaan porukkaan heti alusta alkaen.

On hienoa saada lisää kokemusta ja hyvää fiilistä meidän porukkaan!

Hyperscaler vai eurooppalainen pilvipalvelu?

Wed, 08 Apr 2026 08:44:13 GMT

Pilvipalveluiden markkina on viimeisen vuosikymmenen aikana keskittynyt vahvasti muutamien suurten toimijoiden käsiin. Amazon Web Services (AWS), Microsoft Azure ja Google Cloud Platform (GCP) eli niin sanotut hyperscalerit, hallitsevat globaalisti merkittävää osaa pilvi-infrastruktuurista.

Samaan aikaan markkinoilla on myös useita pienempiä ja erikoistuneita toimijoita, jotka keskittyvät paikallisen markkinan tarpeisiin omalla infrastruktuurilla. Tällaisia toimijoita ovat esimerkiksi suomalainen UpCloud ja ranskalainen Scaleway , jotka tuovat markkinaan vaihtoehdon erityisesti eurooppalaisille yrityksille.

Mutta miten nämä vaihtoehdot oikeastaan eroavat toisistaan?

Hyperscalerien vahvuudet

Hyperscalerit tarjoavat yrityksille useita merkittäviä etuja. Näihin lukeutuu pilvi-infrastruktuurin skaalautuvuus, nopeus, kustannustehokkuus sekä korkea käytettävyys. Suuren mittakaavan ratkaisujen etuja ovat lisäksi teknologian nopea kehitys mm. tekoälyyn (AI) ja dataan liittyvissä työkaluissa sekä prosesseissa.

Suurten pilvipalveluiden vahvuus on myös niiden globaali infrastruktuuri. Datakeskuksia on useilla mantereilla, mikä mahdollistaa palveluiden tarjoamisen lähellä loppukäyttäjiä. Hyperscalereilla on laajat ekosysteemit, joiden ympärille on syntynyt valtava määrä integraatioita, kumppaneita ja työkaluja. Moni ohjelmisto ja SaaS-palvelu rakennetaan suoraan näiden alustojen päälle.

Eurooppalaisen pilven merkitys

Euroopassa keskustellaan yhä enemmän digitaalisesta suvereniteetista. Tällä tarkoitetaan sitä, että yritykset ja julkiset organisaatiot haluavat säilyttää paremman datan ja infrastruktuurin hallinnan. Viimeaikaisten geopoliittisten riskien takia eurooppalaisten palveluiden suosio on ollut kasvussa. Paikalliset pilvipalveluntarjoajat korostavat markkinoinnissa usein suvereniteettia, tietoturvaa ja GDPR-säädösten noudattamista.

Hyperscalerit ovat vastanneet tarpeeseen ottamalla entistä paremmin huomioon suvereniteettitarpeita ja tuomalla läpinäkyvyyttä toimintaansa. Monet niistä tarjoavat eurooppalaisia datakeskuksia sekä erilaisia compliance-ratkaisuja. Silti eurooppalaiset palveluntarjoajat voivat joissakin tilanteissa tarjota selkeämmän juridisen toimintaympäristön, datan hallinnan Euroopan sisällä sekä vaihtoehdon markkinoiden keskittymiselle muutamille suurille toimijoille.

Eurooppalaisia vaihtoehtoja

UpCloud

UpCloud on riippumaton ja johtava eurooppalainen pilvipalveluntarjoaja, joka on perustettu Suomessa vuonna 2011 ja toimii globaalisti neljällä mantereella. Yritys on panostanut tallennusteknologiaan ja tarjoaa niin sanottua MaxIOPS-tallennusta, joka on suunniteltu korkeaan suorituskykyyn.

Suuriin pilviympäristöihin verrattuna, UpCloudin vahvuutena on selkeä infrastruktuurimalli ja yksinkertaisempi hinnoittelu. Lisäksi eurooppalainen tausta voi olla monille organisaatioille tärkeä tekijä datanhallinnan näkökulmasta.

Upcloudilla on yli 10 000 asiakasta eri toimialoilta, kuten julkiselta sektorilta, terveysalalta että finananssialalta.

Scaleway

Ranskalainen Scaleway on yksi Euroopan tunnetuimmista pilvipalveluntarjoajista ja sen palveluvalikoima on varsin laaja. Scaleway tarjoaa esimerkiksi hallittuja Kubernetes-ratkaisuja, object storagea, serverless-palveluita sekä GPU-infrastruktuuria tekoälysovelluksiin. Monipuoliset palvelut yhdistettynä eurooppalaisten lakien ja asetusten alla toimimiseen, tekee siitä vahvan vaihtoehdon globaaleille hyperscalereille.

Scalewaylla on yli 38 000 asiakasta monilta eri toimialoilta, ulottuen startupeista aina suuriin korporaatioihin.

Mikä on soveltuvin vaihtoehto?

Käytännössä valinta riippuu usein käyttötapauksesta. Hyperscaler sopii hyvin tilanteisiin, joissa tarvitaan erittäin laajaa palveluvalikoimaa, rakennetaan globaalia palvelua tai hyödynnetään paljon valmiita platform-palveluita.

Eurooppalaisen pilvipalvelun vahvuudet nousevat esille, kun infrastruktuuri halutaan pitää yksinkertaisena, kustannusten ennakoitavuus on tärkeää tai datan hallintaan liittyvät sääntelykysymykset korostuvat.

Pilvimarkkina ei ole enää yksiselitteinen. Monessa organisaatiossa ratkaisu ei ole joko tai. Yhä useammin käytetään monipilvistrategiaa, jossa eri pilviä hyödynnetään niiden vahvuuksien mukaan. Jokaisen yrityksen on tehtävä myös oma riskiarvio, miten esim. geopoliittiset riskit ja kilpailukyvyn ylläpitäminen suhteutuvat heidän nykyiseen sekä tulevaan toimintaympäristöön.

Lopulta pilvipalvelun valinnassa tärkeintä ei ole se, mikä palvelu on suurin, vaan se mikä sopii parhaiten omaan käyttötarkoitukseen.

Webscale toimii AWS:n, Microsoft Azuren, Google Cloudin sekä eurooppalaisten pilvipalveluiden, kuten UpCloudin ja Scalewayn, kumppanina. Laaja kumppaniverkosto mahdollistaa sen, että lähestymme pilveä aina riippumattomasti asiakkaan näkökulmasta. Autamme valitsemaan, yhdistämään ja hyödyntämään eri pilvipalveluita niin, että ratkaisu tukee liiketoimintaa, kustannustehokkuutta ja tulevaisuuden tarpeita.

Teemu Peräkylä

Sales Executive, Cloud Services

AWS European Sovereign Cloud

Thu, 29 Jan 2026 07:24:53 GMT

AWS European Sovereign Cloud (EUSC) on nyt saatavilla ensimmäisellä regionilla Brandenburgissa, Saksassa (eusc-de-east-1). EUSC on erillinen kokonaisuus AWS:n tavallisesta commercial-pilvestä. Se on rakennettu tilanteisiin, joissa pelkkä eurooppalaisen regionin käyttö ei enää riitä, vaan vaatimukset koskevat myös sitä, miten palvelua operoidaan ja kenellä on siihen pääsy. EUSC:ssä asiakasdata, mukaan lukien metadata, varmuuskopiot ja lokitiedot, säilytetään ja käsitellään Euroopassa. AWS mainitsee kuitenkin, että sisäisen järjestelmän metriikoita voidaan joissain tapauksissa lähettää Euroopan ulkopuolelle.

European Sovereign Cloud on suunniteltu niin, että mitään kriittisiä riippuvuuksia ei ole Euroopan alueiden ulkopuolella. AWS:n mukaan EUSC pysyy toiminnassa myös tilanteessa, jossa transatlanttiset yhteydet katkeavat. Tämä korostaa sitä, että kyse ei ole pelkästään datan sijainnista, vaan myös palvelun jatkuvuudesta ja operointimallista äärimmäisissä poikkeustilanteissa.

EUSC:n tavoitteena on, että palvelua kehittävät ja operoivat yksinomaan EU-kansalaiset EU-alueella. Tämä koskee koko ketjua johdosta operointiin ja tukihenkilöstöön. Myös pääsy fyysiseen infrastruktuuriin ja loogisiin järjestelmiin on rajattu EUSC:n henkilöstölle, eikä AWS:n EU:n ulkopuolella työskentelevillä työntekijöillä ole niihin pääsyä.

Palvelut ja käyttökokemus AWS European Sovereign Cloudissa

Käyttökokemuksen kannalta AWS European Sovereign Cloud pyrkii olemaan mahdollisimman tuttu AWS:n käyttäjille. Perusajatus on sama: useita regioneita, joissa jokaisessa on useampi saatavuusalue (availability zone) sekä laaja valikoima palveluita. Ainakaan tätä kirjoittaessa European Sovereign Cloudin eusc-de-east-1 -regionissa ei ole vielä kaikkia samoja palveluita käytössä kuin muissa Euroopan regioneissa, mutta AWS tuo palveluita lisää ajan myötä.

Koska EUSC on erillinen cloud partition, sitä varten täytyy luoda erilliset AWS-tilit. Identiteetin hallinta ja laskutus ovat myös erillään AWS:n tavallisesta commercial-pilvestä. Käytännössä resursseihin ei voi tehdä suoria viittauksia pilviosioiden välillä, joten esimerkiksi EUSC:n IAM-roolille ei voi myöntää oikeuksia yrityksen nykyisessä AWS-ympäristössä olevaan S3-säiliöön.

European Sovereign Cloud vaihtoehtoa kannattaa arvioida silloin, kun organisaatiolla on tiukkoja dataan liittyviä vaatimuksia. Tällaisia tilanteita löytyy usein julkiselta sektorilta, kriittisen infrastruktuurin palveluista sekä vahvasti säännellyistä ympäristöistä, joissa hankinta- ja auditointivaatimukset eivät jousta. Monille organisaatioille tavalliset AWS:n regionit ja hyvällä arkkitehtuurilla toteutettu tietoturva ovat kuitenkin edelleen täysin perusteltu valinta.

CLOUD Act ja AWS European Sovereign Cloud

Paperilla tämä kuulostaa hyvältä: tuttu AWS-ekosysteemi, mutta tiukemmat dataan liittyvät vaatimukset, jotka ovat tärkeitä osalle organisaatioista. Kriittiset äänet kuitenkin huomauttavat, että AWS on edelleen yhdysvaltalainen yritys, ja Yhdysvaltojen lainsäädäntö, kuten CLOUD Act, voi edelleen vaikuttaa EUSC:hen. CLOUD Act antaa Yhdysvaltojen viranomaisille valtuudet vaatia pilvipalveluntarjoajia luovuttamaan dataa riippumatta siitä, missä data fyysisesti sijaitsee. Jos yritys tai emoyhtiö on yhdysvaltalainen, se voi olla alttiina Yhdysvaltojen lainsäädännölle, vaikka data olisi tallennettu EUSC:hen.

AWS on ilmaissut, että se aikoo noudattaa EU:n tietosuojalainsäädäntöä ja tarjota asiakkailleen turvallisen tavan säilyttää dataa Euroopan alueella. AWS on viestinyt myös, että se aikoo haastaa mahdolliset Yhdysvaltojen viranomaisten vaatimukset oikeudessa, mikäli ne ovat ristiriidassa EU:n tietosuojalainsäädännön kanssa. Käytännössä jää kuitenkin epäselväksi, miten tämä toimii todellisissa tilanteissa ja mitä hyötyä siitä lopulta on, varsinkin jos geopoliittiset jännitteet kasvavat ja päätöksiä joudutaan tekemään nopealla aikataululla.

Lopulta mikään yksittäinen pilvipalvelu ei poista organisaation omaa vastuuta arvioida dataan, lainsäädäntöön ja jatkuvuuteen liittyviä riskejä kokonaisuutena. Erilaisiin riskeihin varautuminen lisää usein kustannuksia, ja jokaisen organisaation on itse punnittava, millainen riskitaso on hyväksyttävä suhteessa liiketoiminnan tarpeisiin ja kilpailukykyyn. Täydellinen irtautuminen yhdysvaltalaisista pilvipalveluista voi joissain tapauksissa kasvattaa kustannuksia ja hidastaa palveluiden kehitystä, minkä vuoksi ratkaisuja on usein perusteltua tarkastella monipilvi- ja hybridipilvimallien kautta osana laajempaa riskien- ja jatkuvuudenhallinnan kokonaisuutta.

Heikki Ma

Cloud Consultant, CloudOps Lead

AWS Lambda durable functions

Wed, 21 Jan 2026 07:04:59 GMT

AWS julkaisi joulukuussa 2025 Lambdaan uuden ominaisuuden nimeltä Lambda durable functions. Se tuo Lambdaan pitkäkestoisen ja monivaiheisen suoritusmallin, jossa työ voidaan pilkkoa hallittaviin osiin ja suorittaa jopa vuoden ajan. Tämä on merkittävä muutos, koska Lambda on perinteisesti ollut parhaimmillaan lyhyissä, nopeasti loppuun asti ajettavissa tehtävissä. Durable functions laajentaa Lambdan käyttötapauksia kohti pidempiä työnkulkuja, integraatioprosesseja ja monivaiheisia automaatioita.

Monessa järjestelmässä Lambda ei yleensä ole vain “yksi kutsu ja vastaus”-tyypinen funktio. Usein joudutaan rakentamaan logiikkaketju, jossa ensin haetaan dataa, validoidaan tilaa, kutsutaan ulkoisia palveluja, tehdään muutoksia, odotetaan jonkin muun prosessin valmistumista ja jatketaan vasta myöhemmin. Tällaisissa toteutuksissa on perinteisesti ollut kaksi tyypillistä ratkaisua: joko rakennetaan oma tilanhallinta käsin (esimerkiksi DynamoDB:n ja retry-logiikan avulla), tai otetaan käyttöön AWS Step Functions. Durable Functions tarjoaa tähän väliin luontevan vaihtoehdon: se mahdollistaa monivaiheisen logiikan toteuttamisen suoraan Lambda-funktiossa ilman erillistä orkestrointikerrosta.

Durable functions perustuu mekanismiin, jossa suoritus jaetaan useisiin työvaiheisiin (step). Kun työvaihe valmistuu, sen tulos tallennetaan checkpoint-tyyppisesti talteen. Jos suoritus keskeytyy tai myöhemmässä työvaiheessa tapahtuu virhe, funktio voidaan käynnistää uudelleen “replay”-mallilla. Tällöin aiempia onnistuneita työvaiheita ei ajeta uudelleen, vaan palautetaan aiemmin tallennettu tulos ja suoritus jatkuu kohdasta ennen virhettä. Käytännössä tämä vähentää turhaa uudelleen ajoa ja tekee suorituksesta kustannustehokkaampaa erityisesti silloin, kun alun työvaiheet ovat hitaita tai sisältävät kalliita integraatiokutsuja.

Durable functions tuo mukanaan myös hyödyllisiä operaatioita kuten wait() ja WaitForCallback(). Näiden avulla suoritus voidaan jättää odottamaan ja jatkaa myöhemmin ilman, että Lambda jää roikkumaan ja laskuttamaan koko odotuksen ajan. Tämä on tärkeä parannus moniin käytännön skenaarioihin: välillä työnkulku joutuu odottamaan hyväksyntää, ulkoisia järjestelmiä tai jonossa etenevää prosessia. Aiemmin tällainen logiikka on usein vaatinut erillistä orkestrointia, mutta Durable Functions tuo odottamisen osaksi koodia.

Vaikka Durable Functions tekee monivaiheisen logiikan toteutuksesta helpompaa, koodia kirjoittaessa täytyy huomioida pari tärkeää asiaa: ulospäin vaikuttavat toimenpiteet ja tilanhallinta. Ulospäin vaikuttavia toimenpiteitä ovat esimerkiksi API-kutsut ja muut operaatiot, joilla on vaikutusta muihin järjestelmiin. Näitä ei kannata tehdä työvaiheiden ulkopuolella, koska replay-tilanteessa nämä koodit ajetaan uudelleen ja ulkopuolinen operaatio voi suoriutua toistamiseen, pahimmillaan seurauksena on kaksoisoperaatioita tai muuta epätoivottua käyttäytymistä. Tilanhallinnan osalta hyvä käytäntö on ottaa jokaisen työvaiheen tulos talteen muuttujaan ja viedä se eteenpäin seuraaville työvaiheille. Näin myöhempi logiikka voi hyödyntää aiemmin laskettuja arvoja turvallisesti myös replay-tilanteissa, ja koodi pysyy ennustettavana.

Checkpoint-tilan koko on vain 256 KB. Tämä on hyvä pitää mielessä, kun rakennetaan työvaiheita. Työvaiheiden tulokset kannattaa pitää kohtuullisen kokoisina. Jos työvaihe tuottaa ison datamassan, on usein parempi tallentaa se esimerkiksi S3:een ja välittää seuraaville työvaiheille vain viite, kuten objektin avain. Tällöin checkpointit pysyvät kevyenä ja työvaiheet keskittyvät tekemään yhden selkeän asian kerrallaan.

Kokonaisuutena AWS Lambda Durable Functions avaa kiinnostavan uuden tavan rakentaa workflow-tyyppistä logiikkaa. Se ei korvaa Step Functionsia kaikissa tilanteissa, mutta tarjoaa erinomaisen vaihtoehdon silloin, kun halutaan pitää kokonaisuus Lambda-funktion koodin sisällä ja samalla saada checkpointtien, retryjen ja wait-operaatioiden hyödyt. Lopputuloksena saadaan vähemmän turhaa työtä, parempi vikasietoisuus ja huomattavasti suoraviivaisempi toteuttamistapa moniin tuotannon automaatioihin ja monivaiheisiin prosesseihin. Tämä on erittäin hyödyllinen uusi työkalu, mitä en tiennyt tarvitsevani.

Heikki Ma

Cloud Consultant, CloudOps Lead

AI-agentti on-call tiimikaveriksi

Mon, 08 Dec 2025 06:58:16 GMT

AWS julkaisi re:Invent 2025 -tapahtuman alussa uuden tuoteperheen, Frontier Agents. Ajatuksena on tuoda operatiiviseen tekemiseen autonomisia “AI-tiimikavereita”, jotka osaavat ratkoa kokonaisia ongelmia eivätkä vain yksittäisiä kysymyksiä. DevOps Agent on yksi näistä ensimmäisistä agenteista, ja se on selvästi suunnattu tuotantoympäristöjen operointiin ja operational excellenceen (OE).

Tyypillisesti business-kriittisillä sovelluksilla on SRE- ja/tai on-call-vastuu, jossa häiriötilanteessa pitää nopeasti tehdä useita asioita yhtä aikaa: paikantaa juurisyy (RCA), palauttaa palvelu käyttökuntoon, laatia korjausehdotus kehitystiimille ja pitää major-incident-management (MIM) -kanavat ajan tasalla. Pahimmassa tapauksessa aikaa kuluu jo pelkästään siihen, että ihminen kerää ja analysoi dataa eri järjestelmistä ja ylläpitää tilannekuvaa samalla kun ympäristö palaa. DevOps Agentin idea on tulla tähän väliin keventämään ihmisen kuormaa.

DevOps Agent toimii käytännössä virtuaalisena on-call-jäsenenä. Kun hälytys tulee, agentti pystyy käynnistämään tutkinnan automaattisesti tuettujen integraatioiden kautta, esimerkiksi WebSocket-triggerillä, webhookeilla tai manuaalisesti erillisestä DevOps Agent -web-sovelluksesta. Agentti lähtee autonomisesti tutkimaan hälytyksen syytä niillä työkaluilla ja oikeuksilla, jotka sille on Agent Spacessa annettu. Agentin tehtävänä on tuottaa raportti löydöksistä sekä konkreettinen korjaus-/mitigaatiosuunnitelma. Agentti tukee multi cloud- ja hybridi ympäristöjä, joten tutkinta voi hyödyntää dataa AWS:n ulkopuolisista työkaluista myös.

DevOps Agent voidaan integroida erilaisiin telemetriapalveluihin, kuten Dynatrace, Datadog, New Relic, Splunk ja AWS CloudWatch. Lisäksi agentille voidaan sallia pääsy versiohallintaan, kuten GitHub ja GitLab, jotta se pystyy yhdistämään ongelmatilanteet viimeisimpiin koodi- ja deploy-muutoksiin. Built-in kommunikointikanavia ovat esimerkiksi Slack ja ServiceNow. Jos edellä mainitut integraatiot eivät riitä, käyttäjä voi tuoda oman työkalunsa agentille käyttöön MCP-protokollan kautta. Kaikki tämä konfiguroidaan Agent Spaceen, jossa määritellään agentille IAM-rooli, käytettävät työkalut sekä mahdollinen cross-account-pääsy eri AWS-tileihin.

Vaikka agentti on autonominen, sen tarkoitus ei ole täysin korvata SRE:tä tai on-call-henkilöä. Ihmisen pitää edelleen varmistaa agentin löydökset ja tehdä itse muutokset. Agentti ei tee korjauksia tai koodimuutoksia puolestasi, vaan ehdottaa niitä. AWS suosittelee myös, että agentille annetaan read-only oikeudet eri järjestelmiin. Ajan myötä agentti oppii tuntemaan valvottavan sovelluksen ja tämän eri komponentit. Tämän tiedon avulla se kykenee antamaan ennakoivia ehdotuksia toimintavarmuuden parantamiseksi. Tuloksena on vähemmän tulipalojen sammuttelua ja enemmän järjestelmällistä luotettavuuden kehittämistä.

Heikki Ma

Cloud Consultant, CloudOps Lead

AWS muutti Lambdan serverless-luonnetta

Thu, 04 Dec 2025 08:19:16 GMT

Rehellisesti sanottuna en odottanut tällaista muutosta. Lambda on koko urani ajan ollut minulle synonyymi serverlessille: kirjoitat funktiot ja AWS hoitaa loput. Nyt AWS hämärtää tätä rajaa tuomalla Lambda Managed Instances -uudistuksen, jossa yhdistyy Lambdan serverless-kehitysmalli ja EC2-tason hallinta. Lambda funktion voi jatkossa halutessaan viedä EC2 instanssiin ajettavaksi. Käyttäjä valitsee itse, millä EC2-instanssityypeillä funktiot pyörivät, ja AWS huolehtii edelleen ylläpidosta, autoskaalauksesta ja kuormantasauksesta.

Yksi näkyvimmistä vaikutuksista on cold start -tilanteiden väheneminen. Aiemmin Lambdan cold startit olivat arkipäivää etenkin harvoin kutsutuissa tai nopeasti skaalautuvissa funktioissa. Managed Instancesissa ympäristöt pysyvät lämpiminä käyttäjän määrittelemän minimikapasiteetin puitteissa, joten invokaatiot osuvat useammin valmiiseen ajo-ympäristöön ja latenssi tasoittuu.

Toinen iso muutos liittyy resurssien mitoitukseen. Klassisessa AWS-sertifikaattikokeen kysymyksessä on kysytty miten Lambdan vCPU:n määrää voidaan nostaa. Tähän vastaus on ollut, että muistia pitää lisätä jos haluaa lambdalle allokoida enemmän vCPU:ta. Tämä on johtunut siitä, että muisti ja vCPU skaalautuvat käsi kädessä. Nyt näin ei enää ole. Managed Instancesin myötä käyttäjä voi valita esimerkiksi CPU-optimoidun instanssityypin ja hallita vCPU:n ja muistin suhdetta selvästi joustavammin.

Lambda on mielestäni aikaisemmin sopinut täydellisesti ympäristöön, jossa kuorman määrä on vaihtelevaa tai hyvin vähäistä. Kun kuorma on kasvanut, kustannussyistä on ollut järkevämpää siirtyä esimerkiksi ECS- tai EKS- ympäristöön. Tämän uudistuksen ansiosta käyttäjän ei välttämättä tarvitse tehdä tätä siirtoa vaikka kuorma kasvaisi. Käyttäjä voi pysyä Lambda-ympäristössä, hyödyntää EC2-tason kontrollia ja kustannusetuja. Lambda Managed Instanssiin on mahdollista hyödyntää mahdolliset EC2-alennukset kuten savings plans tai reserved instances sopimukset.

Tämä uudistus muuttaa Lambdan rajoja: cold startit vähenevät ja resurssit ovat käyttäjien hallinnassa. Jos käyttäjä tykkää Lambdan käyttäjäkokemuksesta, hän voi pysyä Lambda-ympäristössä vaikka kuormat kasvavat eikä tarvitse pelätä laskun kasvavan. Tämä mahdollistaa enemmän liikkumavaraa ja joustavuutta. Tämä on iso askel eteenpäin Lambdan kehityksessä.

AWS:n julkaisu: Introducing AWS Lambda Managed Instances: Serverless simplicity with EC2 flexibility

Heikki Ma

Cloud Consultant, CloudOps Lead

Image build evolution in EC2

Mon, 24 Nov 2025 08:35:03 GMT

Deploying software on EC2 instances nowadays feel like going backwards in time - most of the applications would be usually preferably deployed as Docker containers or serverless functions. With containers and serverless we wouldn’t have to worry about the instance management but rather just on the application packaging as long as the use case fits the given limitations of the serverless platform or ECS/Kubernetes cluster.

Industrial use cases still more often than not involve running off the shelf software that has been built for physical servers running on-site. Building a cloud environment to run such software in this scenario led me recently back to using EC2 VMs.

No snowflakes

Setting up the environment started off experimentally, but regardless of how experimental system I am building, I’ll never again make the mistake of manually configuring snowflake virtual machines. Snowflake VMs is what you get when you configure the system manually to try out a system prototype, and due to hurry and too much work load, you fail to make the changes into version controlled code.

Downside of the snowflake VMs is that you cannot replicate them, and if you happen to lose one, you cannot rebuild it without a lot of experimenting and trying to remember which essential services are misbehaving without the configuration.

Security requirements also favor immutable infrastructure. Immutability in this case means that we never update the servers themselves. When we need to update something, the whole new machine image is created, released and pushed to production use as an immutable image that is used to launch new virtual machines. We will always exactly know how each VM version is configured because we have the image where we can check it.

Building immutable images also means that the virtual machines we run never need to have access to public internet, as they will never update themselves. They will only ever be replaced. Reality is that there will still be a break-glass SSH access to the servers, and this increases the risk of creating snowflakes in the VM fleet. To avoid this, we intend to both enforce a maximum lifetime of 30 days for the VMs as well as a best before date of 30 days after creation for the machine images. Once a snowflake VM is terminated, it will be replaced by a new VM without any of those modifications. This will at least reveal any temporary local hacks that were needed for fixing an instance.

Playbooks for configuration

To operate a VM fleet with immutable infrastructure properly we need to have automation for creating the images. The starting point towards enabling automation in AWS is writing the whole server configuration into an userdata script file.

I very much prefer to avoid using bash scripts nowadays for full configuration setup, just because they are less modular and too easily become a mess of disjointed script pieces. For ages, my preferred solution for these cases has been Ansible. So in this case, I write my server configuration playbook for Ansible, copy it via S3 to new instances, and run them with the userdata bash script. This is different from how Ansible was originally used as a tool to update fleets of machines, but Ansible supports the local operation well.

Once we have a bash userdata scrip initiating Ansible playbook-based deployment, we already have a modular, version controlled Ansible playbook defining the system changes we want to be running, so we are pretty well off.

Automatic recovery

Next thing to ensure is of course checking that the instances get properly recreated whenever a single VM dies. Whether it is tomorrow or two years from now, they will die.

Autoscaling group is the trusty AWS way of doing this, and the advantage of ASGs is that it supports the userdata scripts easily.

In the legacy software case we usually have to also worry about the state of the system, and in this specific case even the MAC address was significant. This forces us to use a specific type of system, at least when I want to rely on autoscaling rather than have Lambda functions run more complex startup configurations.

The system state was stored on disk, so we are mounting a persistent EBS data volume on the instance. This had to be done on startup, as ASG does not support mounting specific volumes. As there is only one Volume, I have the ASG running in “Exactly one”-configuration, meaning that the ASG will never spawn more than one instance at a time, and it will spawn exactly one instance if there are none in healthy state. The instance itself will use its own metadata to query AWS API for the correct EBS volume, and mount it on startup.

There is also a requirement from licensing logic that the server must retain its MAC address - this is achieved by configuring the Exactly-one-ASG with a fixed network interface identifier. There is a failure condition where ASG tries to spawn a new instance immediately after the previous one is terminated, because the ENI is not released from the old one yet. I needed to ensure that the ASG will just keep retrying until it succeeds.

One part of the automatic recovery is preparing for low probability but still likely events - in this case the most likely event is the loss of an EBS data volume. Our organization is using AWS Backup to create automatic backups of EBS Volumes, so it is enough to enable the backup by tagging the volume correctly. Now that the backups are getting created, we are good to go after documenting the recovery procedure in case of Volume failure. I chose to store the correct Volume ids in AWS Parameter Store from which the instances query the intended volume id and then attach the volume during startup.

For backup purposes, we can also disable backing up any VMs, as they are immutable and will not have relevant changes that would have to be replicated. Only the data volume contains information worth backing up.

Reliability and speed with prebaked AMIs

Installing the instance with userdata scripts is a reasonable solution for a first automation effort. Even if the security considerations would not require isolating the instances from public internet there are significant downsides to using that solution in a production environment directly, instead of using immutable images.

First issue is the reliability of the build script: With the mindset that everything breaks all the time, we must assume that at some point in time the instances are in state that they cannot connect to package repositories, or other remote resources that they require for installation. Prebuilding a machine image solves this problem: The possible network failures will fail at build time and on a build instance, instead of causing a problem in end user-visible production servers.

Second issue is the time required to spin up a new server: If you start downloading updates and for example a 1GB application installation file, it will take a lot longer to get the new instance running. Assuming a moderately bad case of problems with instances, this would occur at a time where the whole redundant clusterful of instances go down at approximately same time, leading to a very long loss of service.

Starting a new instance from a prebaked AMI and only mounting an EBS volume takes about 30-120 seconds. Building a new instance from scratch on an empty OS-image takes anything from 5-20 minutes, depending on the amount of installation we wanted to build.

Third issue that may cause problems is that if you always build the instance upon starting it, you will have a cluster of unique instances which are each running the version of the OS that got installed at the startup time. When you instead build the AMI and use that AMI for all the instances, you will at least have identical base setup on all the instances.

The simplest implementation for building the AMI was to just deploy the instance with build commands in the userdata script, and then using a local shell script to take a snapshot of that VM once it is completed. Fairly quick to do, low development effort, slightly ugly because it will be run on a developer machine or possibly a CI machine.

AWS tooling for building AMIs

Running local scripts is not very suitable for a large team, and it is even less suitable for cases where the responsibility for operating this system will be handed over to an operations team at some point in the future. This is a reality that should be addressed in every project that is intended for production. Very often it gets overlooked if the schedule is tight and there is a pressure to deliver as many working features as possible.

Since our responsibility as developers is to build a clean, understandable and useful system to the people who will be maintaining it, I want to simplify running all pieces of the system into simple UIs that can be explicitly documented in the user manual.

AWS provides the EC2 Image Builder for this purpose. The build components are defined as YAML files, and you can define build, validate and test stages with those components. Ideally you build the AMI in a build stage, validate the recently built instance before creating the AMI and then launch a fresh instance from that AMI to run the test components on it. After this you should have a well tested image that can be deployed via the autoscaling group. Previously I would have used Terraform Packer for this use case, but Image Builder provides a decent UI in AWS console so that is my preferred choice for that reason.

In this case we are using AWS CDK (Cloud Development Kit) to define our infrastructure as code, and there is a AWS-provided CDK library that supports the Image Builder pipeline creation.

This lets us easily reference other resources that need to be passed into the build pipeline, such as IAM roles and network interfaces.

Once the AMI is built, the Image Builder also applies sharing and distribution settings to copy the AMI to multiple accounts and regions. This lets us build a single AMI, run functional tests on instances based off that AMI in dev and qa environments and only then deploy the new AMI to production.

Layered image creation

A benefit of using an AMI building pipeline is that we can also split the AMI creation between several responsibilities. The application developers should have to worry only about the working of the application, and any maintenance and security features required by corporate IT should come from corporate IT.

In this case we must be compliant with the industry standard security practices, and one aspect of that is complying with the CIS benchmark. We can separate the concerns by creating the base AMI with CIS hardening, reporting and instrumentation, and only then using that base AMI for creating the application AMI.

This same hardened base AMI can be used by other teams of the organization, and all application teams benefit from security improvements done on the base image.

Future development

With AMIs getting built automatically by Image Builder, using a layered approach with OS security updates being baked to the first image and application specific configuration on the second image on top of those, we are well off in terms of using infra as code to codify what gets done. The user manual can focus on just the simple tasks of triggering the build pipeline and monitoring the progress of deployments through dev-qa test stages and the deploying to production.

There are still gaps in the automation pipeline that would speed things up and reduce the possibility of errors. Each step should publish their results into EventBridge event bus, and each dependent step should listen for relevant events that should trigger their own build or deployment step.

One straightforward improvement to our system is to move from updating the generated AMI IDs in CDK configuration files to instead updating a SSM parameter store value with the new AMI ID and having the autoscaling group launch configurations refer to that parameter store key directly. This lets us avoid making IaC code changes when we want to do a routine update of the machine image to include latest security updates without actually touching the build configuration. To ensure that the whole instance cluster is using the same AMI, an instance refresh for the autoscaling groups needs to be triggered.

Looking back at the gradual improvement of the build pipeline, it’s easy to see that refactoring older implementations would improve the readability of the whole - for example there is still logic in bash scripts that could be done in Ansible playbooks. Essentially upgrading these components should be done at the latest when we touch those components next time: Developing the whole new abstraction layer is a large task to do, but once it has been done elsewhere in the system, it is a fairly small thing to adapt the old code to the new way of working.

Using reusable and modular solutions for the build pipeline we can also easily present these improvements to our other teams and to the development world as a whole.

Jukka Dahlbom

Senior Cloud Architect

Webscale Tukholmassa: Aurinkoa ja AWS-pilveä

Wed, 18 Jun 2025 11:02:25 GMT

Kesäkuun alussa suuntasimme aurinkoiseen Tukholmaan AWS:n järjestämään Partner Summitiin ja sitä seuranneeseen Summit -päätapahtumaan. Tiistain Partner Summittiin osallistuivat Miro ja Max ja keskiviikkona mukaan liittyivät Ville ja Janne. Matka yhdisti ajankohtaisia pilviteemoja, kiinnostavia kohtaamisia ja ripauksen Tukholman kesäfiilistä.

Partner Summit ja Summit -tapahtumat

Partner Summitissa korostui, kuinka tärkeässä roolissa kumppanit ovat AWS:n strategiassa. Päivän aikana saimme kurkistuksen AWS:n suunnittelemaan European Sovereign Cloud -kokonaisuuteen, joka on kehitetty vastaamaan Euroopan turvallisuus- ja sääntelyvaatimuksia. Lisäksi AWS Marketplace nousi esiin satsauksien kohteena olevana kanavana, jonka avulla kumppanit voivat tuoda palveluitaan suoraan asiakkaiden ulottuville. Tapahtuma keräsi laajasti osallistujia Skandinaviasta ja Baltiasta. Oli kiinnostavaa kuulla, miten eri maissa ratkotaan samanlaisia haasteita ja kehitetään samansuuntaisia ratkaisuja.

Summit -päivän aikana AWS kertoi merkittävistä investoinneista muun muassa Ruotsin ja Saksan infrastruktuuriin sekä osaamisen kehittämisestä esimerkiksi re/Start-ohjelman kautta. Painotuksena oli, että pilvipalvelut eivät ole vain teknologiaa, vaan perusta kestävälle ja osallistavalle digitaaliselle kehitykselle.

Yksi päivän keskeisiä teemoja oli generatiivinen tekoäly. AWS panostaa voimakkaasti oman Bedrock-alustansa ympärille rakentuvaan GenAI-ekosysteemiin. Tämä tuo tarjolle välineitä, joiden avulla organisaatiot voivat rakentaa sekä hyödyntää tekoälyratkaisuja turvallisesti ja skaalautuvasti. Tekoäly ei ollut esillä vain teknologiana vaan myös merkittävänä liiketoimintamahdollisuutena erityisesti silloin, kun kokeiluvaiheesta siirrytään tuotantoon.

Tapahtuma sai meidät pohtimaan, kuinka monella tavalla AWS-ympäristöön perehtynyt asiantuntija voi auttaa asiakkaitamme. Uusien teknologioiden hyödyntäminen vaatii usein rinnalle osaajaa, joka pystyy neuvomaan, avaamaan mahdollisuuksia ja auttamaan konkreettisessa käytäntöön viemisessä.

Asiakastarinat keskiössä

Esiin nousi myös kiinnostavia asiakastarinoita, kuten Novo Nordiskin kehittämä tutkijaportaali, joka mahdollistaa nopean ja hallitun pääsyn lääketieteelliseen dataan yliopistotutkijoille. Toinen mieleenpainuva esimerkki oli ruotsalainen start-up Lovable, joka rakentaa visuaalista ohjelmointiympäristöä käyttäjille ilman kooditaustaa. Molemmissa näkyi, kuinka laajasti AWS:n teknologiaa voidaan hyödyntää hyvin erilaisissa tarpeissa.

Yksi pysäyttävimmistä puheenvuoroista kuultiin Ukrainan puolustusministeriön edustajalta. Hän kertoi, miten pilviratkaisut mahdollistivat hallinnon toimintakyvyn säilymisen sodan alkaessa. Pilvipalveluiden tuoma ketteryys ja kestävyys ovat kriisitilanteessa paljon enemmän kuin vain teknologisia etuja.

Teknologia mahdollistajana

AWS:n palvelutarjonnan kulmakivi on ollut alusta lähtien tietoturva, jota tekoäly uudistaa vauhdilla. Tietoturvan puolella generatiivinen AI pääsee rooliin, kun tekoäly tuodaan AWS:n tietoturvapalveluihin mukaan. Pääsimme kuulemaan esimerkkejä, miten AWS Securityhubin tunnistamia tietoturvariskejä voidaan AI-työkalujen avulla käsitellä tuottaen automaattisia ratkaisumalleja tai tehostaa integraatioiden toimintaa uhkien käsittelyssä. Ruotsalainen Ikano-pankki esitteli heidän toimintamalliaan, jossa SecurityHubin keskitetystä tietoturvapalveluista tuotetaan integraatioiden avulla löydöksistä oleellisia tietoja asiantuntijoille.

Pilvipohjainen moderni sovellusarkkitehtuuri on monelta osin tapahtumavetoista (Event-driven) ja siksi monissa teknisissä breakout-sessioissa esiteltiin AWS:n palveluita ja näiden tuoreimpia ominaisuuksia event-driven-arkkitehtuurin saralla. Kun hyödynnetään erilaisten jono- ja tapahtumavälityspalveluiden (kuten AWS EventBridge) ominaisuuksia, pystytään tehokkaammin hallitsemaan yhä kasvavaa tapahtuma- ja tiedonvälitysmäärää.

Vihreys on vaihtunut turvaan ja hallintaan

Aikaisemmilta vuosilta tutuista teemoista ns. vihreä IT (green IT) ei juuri näkynyt esityksissä tai messualueella. Ohi oli ajanut myös julkisen sektorin haasteisiin vastaaminen kustannusten hallinnassa ja niiden operointiin liittyvät ratkaisut. Näin AWS Summitin teemat noudattavat joissakin määrin isompia globaaleja virtauksia: Vihreys on vaihtunut turvaan ja hallintaan.

Kokonaisuutena matka oli täynnä oivalluksia ja inspiraatiota. Palasimme kotiin väsyneinä mutta innostuneina ja uusia ajatuksia pursuavina. Kesän aikana ehtii varmasti jalostaa monia ideoita, joita tapahtumassa syntyi.

Max Niskanen , Head of Sales

Miro Nissilä, Sales Specialist

Janne Lavila , Lead Developer

Ville Välimäki , Cloud Architect

Mitä jäi käteen Tech Days 2025 -tapahtumasta?

Thu, 12 Jun 2025 11:12:41 GMT

Tech Days 2025 tarjosi meille paljon muutakin kuin Fiskarsin idyllistä maisemaa. Tapahtuma yhdisti ajankohtaiset esitykset, käytännön oppimista ja rennon yhdessäolon sopivassa tasapainossa. Mutta mitä tapahtumasta jäi erityisesti mieleen?

Tietokantaohjattua infraa ja EU-pilveä

Tekoälyä unohtamatta

Tietoturvaa yhdessä mallintaen

Amazing Fiskars ja muita yhteisiä hetkiä

Varpu Kekkonen

People and Organizational Development Lead

Viisi vinkkiä pilvikulujen hallintaan

Wed, 23 Apr 2025 08:24:05 GMT

Julkinen pilvi on tuonut mukanaan ennennäkemätöntä skaalautuvuutta, joustavuutta ja nopeutta, mutta pilven käyttöönoton seurauksena myös kulut saattavat karata pilviin. Julkisen pilven hyödyntäminen vaatii myös erilaista suhtautumista kuluihin, kun pääomaa ei tarvitse varata omaan laitteistoon ja sen ylläpitoon. Vaikka pilven käyttöönotto onnistuukin ilman suuria alkuinvestointeja, monimutkaisempi laskutuslogiikka saattaa kuitenkin paisuttaa kokonaiskustannuksia. Seuraavien käytännön vinkkien avulla pääset alkuun pilvikustannusten hallinnassa.

1. Hyödynnä automaattista skaalautumista

Yksi julkisen pilven keskeisimmistä hyödyistä on kyky skaalautua kuormituksen mukana. Oikein konfiguroidun automaattisen skaalautumisen avulla varmistut, että maksat vain käytetystä kapasiteetista. Esimerkiksi AWS Auto Scaling mahdollistaa resurssien kuten EC2 instanssien dynaamisen säädön kuorman perusteella. Automatisointi vähentää manuaalista työtä sekä pienentää riskejä ylikuormittumisesta ja ylimitoitetusta kapasiteetista.

2. Sammuta käyttämättömät resurssit

Kehitys- ja testiympäristöt jäävät usein tarpeettomasti päälle iltaisin tai viikonloppuisin, jolloin kustannukset raksuttavat ilman liiketoiminnallisia hyötyjä. Ajastuksia ja automaatioita hyödyntämällä saat sammutettua turhat resurssit silloin, kun niitä ei käytetä. Esimerkiksi IaC -työkalujen kuten Terraformin avulla voit myös pystyttää ja purkaa ympäristöjä nopeasti tarpeen mukaan, jolloin niitä ei tarvitse pitää jatkuvasti käynnissä.

3. Sovella eri hinnoittelumalleja

Pay-as-you-go laskutusmalli, jossa pilvestä maksetaan käytön mukaan, mahdollistaa pilvipalveluiden kokeilun matalalla kynnyksellä. Pilvialustat tarjoavat kuitenkin lukuisia joustavia hinnoitteluvaihtoehtoja ja säästöohjelmia erilaisiin käyttötarkoituksiin. Jos tietyt resurssit ovat jatkuvassa käytössä, sitoutumalla määräajaksi ja hyödyntämällä Reserved Instances hinnoittelumalleja voidaan saavuttaa jopa 70% kustannussäästöjä. Vastaavasti epäsäännöllisiin ja vähemmän kriittisiin tehtäviin kannattaa hyödyntää edullisempia spot-instansseja.

4. Seuraa ja analysoi kustannuksia säännöllisesti

Pilvikustannusten hallinta alkaa siitä, että ymmärrät mistä ja millaisia kustannuksia pilvestä syntyy. Kun ympäristö elää jatkuvasti ovat yllättävät lisäkustannukset väistämättömiä ilman reaaliaikaista seurantaa. Resurssien tagituksen ja luokittelumenetelmien avulla saat läpinäkyvyyttä siihen, mitkä tiimit ja sovellukset tuottavat mitäkin kuluja. Pilvialustat tarjoavat käyttöön myös omia kustannustenhallintatyökaluja, kuten AWS Cost Explorer tai Azure Cost Management, joita kannattaakin hyödyntää kustannusten seuraamisesta. Budjettien määrittäminen ja automatisoidut hälytykset auttavat tarttumaan poikkeukselliseen kulutukseen heti.

5. Tee yhteistyötä jälleenmyyjän kanssa

Pilvipalveluiden ostaminen on usein aloitettu helposti luottokortilla. Ympäristöjen kasvaessa ja resurssien lisääntyessä laskutus jää kuitenkin helposti myös tämän varaan. Kun pilvipalvelut hankitaan jälleenmyyjän kautta, avautuu mahdollisuus sekä parempiin ehtoihin, että suoraan kustannussäästöihin ja muihin etuihin. Laskutukseen saadaan myös selkeyttä, kun useampien tiimien tai yksiköiden kulut on mahdollista yhdistää yhteen laskuun.

Pilvikulut kuriin kumppanin avulla

Pilvikulujen hallinta ei ole yksittäinen projekti, vaan jatkuva prosessi, joka vaatii näkyvyyttä, suunnitelmallisuutta ja oikeita työkaluja. Hyödyntämällä automaatiota, eri hinnoittelumalleja ja kumppaneita voit saada pilviympäristöstäsi irti täyden hyödyn, ilman että kustannukset karkaavat pilviin.

Me Webscalella olemme erikoistuneet auttamaan asiakkaitamme pilviympäristöjen optimoinnissa sekä kustannustehokkuuden että hallittavuuden näkökulmasta. Jos pilvikulunne kaipaavat tarkempaa selvitystä, tai jos laskutus kulkee yhä luottokortin kautta, ota yhteyttä, niin käydään tilanne yhdessä läpi.

P.s. Pääset syventymään aiheeseen kuuntelemalla Pilvipilotit -podcast jakson FinOpsista.

Miro Nissilä
Sales Specialist

Ensituntuma SST-työkaluun

Thu, 17 Apr 2025 06:01:26 GMT

Päätin tutustua SST-nimiseen työkaluun, joka herätti kiinnostukseni erityisesti sen lupausten ja modernin lähestymistavan vuoksi. Koska toimin työkseni AWS-pilviarkkitehtinä ja käytän IaC-työkaluja päivittäin, päätin kokeilla tätä ratkaisua puhtaasti mielenkiinnosta – ei siis asiakasprojektin tarpeesta, vaan halusta ymmärtää, mitä SST oikeasti tarjoaa ja missä sen vahvuudet tai rajoitteet piilevät.

Mikä SST on – ja mitä uutta v3 tuo mukanaan?

SST on kehys, joka helpottaa full stack -sovellusten rakentamista omalle infrastruktuurille. Se tarjoaa abstraktoidun tavan määritellä koko sovelluksen rakenteen – mukaan lukien sovelluksen backend, frontend, tietokannat, cron-jobit ja ulkoiset integraatiot – yhdellä TypeScript-tiedostolla ( sst.config.ts ).

Alkujaan SST hyödynsi AWS CDK:ta ja CloudFormationia infrastruktuurin luomiseen. V3-versiossa tiimi kuitenkin päätti siirtyä käyttämään Pulumia ja Terraformin providereita. Tämä muutos tehtiin, koska CDK:n ja CloudFormationin käytössä ilmeni merkittäviä haasteita. Esimerkiksi CloudFormationin läpinäkymättömyys vaikeutti logiikan ja tilanhallinnan ymmärtämistä ja mukauttamista. Lisäksi AWS CDK pyrkii hallitsemaan omaa tilaansa CloudFormationin ohella, mikä voi johtaa ristiriitoihin ja hallinnan monimutkaistumiseen.

Uusi Pulumi-pohjainen toteutus antaa SST:lle mahdollisuuden rakentaa infrastruktuuria suoraan ilman CloudFormation-kerrosta, ja samalla mahdollistaa Pulumin sekä Terraformin laajan ekosysteemin ja modulaarisuuden hyödyntämisen. Tämän koettiin parantavan kehittäjäkokemusta ja laajentavan työkalun käyttökelpoisuutta huomattavasti.

Havaintoja ja fiiliksiä työkalun kokeilun pohjalta

SST tekee infran luonnista yllättävän yksinkertaista. Työkalussa on paljon valmiita kokonaisuuksia perinteisen full stack -sovelluksen rakentamiseen. Esimerkiksi Next.JS -sovelluksen Lambdalla tai ECS-konteilla pystyi määrittelemään muutamalla rivillä koodia.

SST käyttää oletusasetuksia monessa kohtaa, mikä nopeuttaa kehitystä huomattavasti. Näitä oletuksia voi säätää transform-ominaisuuden kautta, jolloin säilytetään helppous, mutta saadaan tarvittava joustavuus.

SST tukee tällä hetkellä suoraan AWS:llä ja Cloudflarella toteutettuja sovelluksia, mutta koska taustalla toimii Pulumi, on käytettävissä yli 150 Terraform-pohjaista provideria. Näin ollen SST soveltuu myös monipalveluympäristöihin, joissa tarvitaan esimerkiksi Stripe-, Azure AD- tai Github-integraatioita.

Yksi SST:n vaikuttavimmista ominaisuuksista on Live Lambda Development. Tämä mahdollistaa Lambda-koodin ajamisen ja testaamisen paikallisesti, aivan kuin se toimisi AWS:n pilvessä. Kun sst dev on käynnissä, SST ohjaa Lambda-kutsut kehittäjän omalle koneelle, jolloin koodimuutokset näkyvät heti ilman uutta deployta. Kehityskokemus on huomattavasti ketterämpi verrattuna perinteiseen CDK:lla toteutettuun kehitykseen.

Toinen yllättävän helppo asia oli bastion-instanssin luonti suljetun VPC-verkon sisään. SST hoitaa tämän yhdellä komponentilla ilman tarvetta manuaalisille EC2-konfiguraatioille tai monimutkaisille security group -asetuksille. Tämä on erityisen arvokasta, jos tarvitset tilapäistä pääsyä esimerkiksi tietokantaan staging-ympäristössä tai haluat pääsyn sisäverkkoon ilman VPN:ää.

AWS-komponenttien kattavuus: hyvä, mutta ei täydellinen

SST tarjoaa valmiita komponentteja keskeisimmille AWS-palveluille, mutta aivan kaikkea ei löydy suoraan. Yritin esimerkiksi luoda Lambda-funktion, joka olisi liitetty Load Balancerin listeneriksi, mutta tätä ei ollut suoraan mahdollista tehdä. Load Balancer näyttäisi olevan saatavilla osana toisia komponentteja, kuten ECS:ää, mutta suoraa tukea sen käytölle Lambdan kanssa ei löytynyt. Tämä on hyvä esimerkki siitä, missä kohtaa SST:n korkea abstraktiotaso voi kääntyä rajoitteeksi. Jos tarvitset tarkempaa kontrollia tai erityisiä AWS-komponentteja, joudut helposti tilanteeseen, jossa SST voi olla enemmän este kuin apu.

SST voi olla loistava työkalu silloin, kun rakennetaan nopeasti full stack -sovellusta, jossa tarvitaan frontend, backend, autentikointi ja tietokanta. Työkalu toimii erinomaisesti prototyyppien ja MVP-projektien kanssa, sekä sisäisten työkalujen rakentamisessa. Monimutkaisissa, erityisesti verkon eristämiseen, VPC-suunnitteluun ja matalan tason infrastruktuuriratkaisuihin liittyvissä tarpeissa turvautuisin edelleen muihin IaC-työkaluihin kuten Terraformiin.

Yhteenveto

SST tarjoaa modernin ja tehokkaan tavan rakentaa sovelluksia infrastruktuurin päälle. Sen kehittäjäystävällisyys, valmiit komponentit ja live-kehitysympäristö tekevät siitä todella kiinnostavan vaihtoehdon. SST on erityisesti suunniteltu kehittäjille, jotka haluavat nopeuttaa full stack -sovellusten kehitystä ilman, että jokainen infra kerros tarvitsee erillistä konfigurointia.

Omassa työssäni SST ei välttämättä korvaa perinteisiä IaC-työkaluja monimutkaisissa projekteissa, mutta se on ehdottomasti kokeilemisen arvoinen ja todennäköisesti tulee vielä vastaan esimerkiksi nopeissa integraatio projekteissa tai proof-of-concept-vaiheissa.

Heikki Ma

Cloud Consultant, CloudOps Lead

Vaihtoehdot Serverless Framework v4:lle

Thu, 20 Mar 2025 08:48:27 GMT

Serverless Framework on suosittu avoimen lähdekoodin työkalu, joka helpottaa serverless-sovellusten kehittämistä ja hallintaa pilviympäristöissä, kuten AWS:ssä. Vuoden 2024 lopussa Serverless Frameworkin v3 saavutti elinkaarensa päätepisteen, eikä siihen enää julkaista virallisia päivityksiä tai tietoturvakorjauksia. Uudemmassa v4 versiossa työkalu muuttui maksulliseksi organisaatioille, joiden liikevaihto on yli 2 miljoonaa dollaria vuodessa. Tämä muutos on saanut monet yritykset pohtimaan, miten jatkaa eteenpäin olemassa olevien serverless-sovellustensa kanssa.

Tässä kirjoituksessa tarkastelemme kolmea vaihtoehtoa Serverless Framework v4:lle: AWS Cloud Development Kit (CDK), AWS Serverless Application Model (SAM) ja OSS-Serverless. Käymme läpi niiden ominaisuuksia, vahvuuksia ja heikkouksia sekä pohdimme, mitä yritysten tulisi ottaa huomioon tehdessään päätöstä tähän liittyen. On myös syytä huomata, että näiden vaihtoehtojen lisäksi on olemassa muita työkaluja, jotka voivat soveltua yritysten tarpeisiin.

AWS Cloud Development Kit (CDK)

AWS CDK on AWS:n tarjoama IaC-työkalu, joka mahdollistaa resurssien hallinnan ohjelmointikielillä, kuten TypeScript, Python, Java, C# ja Go. Toisin kuin deklaratiivinen lähestymistapa, CDK tarjoaa dynaamisen ja joustavan tavan määritellä infrastruktuuri koodina.

Hyödyt:

Ohjelmointikielipohjainen lähestymistapa, joka helpottaa kehittäjien työtä, sillä infrastruktuuria voidaan hallita tutuilla ohjelmointikielillä.
Laajennettavuus – yritykset voivat rakentaa ja jakaa omia konstruktioita, mikä helpottaa standardien luomista ja hyväksi todettujen ratkaisujen uudelleen käyttöä.
AWS:n virallinen tuki, mikä takaa pitkäaikaisen tuen ja kehityksen sekä saumattomat integraatiot AWS-ekosysteemiin.

Huomioitavaa:

Oppimiskynnys voi olla korkea, erityisesti tiimeille, jotka ovat tottuneet deklaratiiviseen infrastruktuurin määrittelyyn.
Monimutkaisuus kasvaa suurissa projekteissa, mikä vaatii tarkempaa suunnittelua ja ylläpitoa.

AWS Serverless Application Model (SAM)

AWS SAM on AWS:n tarjoama työkalu, joka laajentaa CloudFormationia ja mahdollistaa serverless-sovellusten määrittelyn YAML- tai JSON-muotoisilla templateilla. Se on suunniteltu yksinkertaistamaan AWS Lambda -pohjaisten sovellusten hallintaa.

Hyödyt:

Helppokäyttöinen, erityisesti kehittäjille, jotka ovat jo tottuneet CloudFormationiin.
Integroitu AWS-ekosysteemi, mikä takaa yhteensopivuuden ja jatkuvan tuen uusille ominaisuuksille
Lokaali testausmahdollisuus, jonka avulla kehittäjät voivat testata Lambda-funktioita omalla koneellaan ennen AWS-pilveen vientiä.

Huomioitavaa:

Rajoitettu laajennettavuus verrattuna CDK:hon, mikä rajoittaa monimutkaisempien sovellusten toteutusta.
Vähemmän joustava, sillä deklaratiivinen konfigurointi on rajoitetumpaa kuin ohjelmointikielipohjainen lähestymistapa.

OSS-Serverless

OSS-Serverless (https://github.com/oss-serverless/serverless) on avoimen lähdekoodin projekti. Yhteisön ylläpitämä fork Serverless Frameworkin versiosta 3, joka pyrkii tarjoamaan saman käyttökokemuksen ja toiminnallisuuden ilman kaupallisia lisenssirajoituksia.

Hyödyt:

Ilmainen ja avointa lähdekoodia, mikä tekee siitä kustannustehokkaan vaihtoehdon erityisesti pienille yrityksille.
Tutut työkalut ja toimintamallit, mikä helpottaa siirtymää Serverless Framework v3:sta.

Huomioitavaa:

Epävarmuus kehityksen jatkuvuudesta, sillä yhteisöpohjaisilla projekteilla ei ole AWS:n tai muiden kaupallisten toimijoiden tarjoamaa pitkäaikaista virallista tukea.
Rajoitettu tuki, koska asiakastukea ei ole saatavilla.

Yhteenveto

Serverless Framework v3:n tuen päättyminen pakottaa yritykset arvioimaan uusia ratkaisuja serverless-sovellustensa hallintaan. Valinta riippuu pitkälti organisaation tarpeista ja resursseista. AWS CDK tarjoaa laajennettavan ja ohjelmointikielipohjaisen lähestymistavan, mutta sen käyttöönotto voi vaatia lisäresursseja ja oppimista. AWS SAM on selkeä ja helppokäyttöinen vaihtoehto, joka integroituu syvälle AWS-ekosysteemiin, mutta sen laajennettavuus on rajallisempi. OSS-Serverless puolestaan tarjoaa tutun käyttöympäristön ilman lisenssikustannuksia, mutta sen ylläpidon jatkuvuus on epävarmaa, koska se perustuu vapaaehtoiseen yhteisöön.

Lopullinen päätös tulisi tehdä yrityksen nykyisten työkalujen, osaamisen ja tulevaisuuden tarpeiden perusteella. Perusteellinen arviointi ja pitkän aikavälin strateginen suunnittelu auttavat valitsemaan ratkaisun, joka tukee organisaation kasvua ja kehitystä parhaalla mahdollisella tavalla.

Heikki Ma

Cloud Consultant, CloudOps Lead

Neljä syytä laatia pilvistrategia

Fri, 21 Feb 2025 06:52:58 GMT

Pilvipalveluiden tehokas hyödyntäminen on noussut kriittiseksi menestystekijäksi kilpailluissa

markkinoissa. Pilvipalvelut mahdollistavat niin nopeamman innovoinnin, resurssien tehokkaamman hallinnan kuin joustavammat liiketoimintamallitkin. Jotta pilven tarjoamat liiketoimintaedut pystytään hyödyntämään, tarvitaan pilven käyttöön kuitenkin suunnitelmallisuutta ja järjestelmällisyyttä. Toisin sanoen strateginen lähestymistapa pilvipalveluiden hyödyntämiseen mahdollistaa myös liiketoiminnallisten tavoitteiden täyttymisen.

Mitä pilvistrategia on?

Pilvistrategia ei ole pelkkä teknologinen valinta, vaan se toimii suuntaviivana pilvipalveluiden

käytölle suhteessa liiketoiminnan tavoitteisiin. Se on kokonaisvaltainen suunnitelma

pilviteknologian hyödyntämiseksi kattaen niin IT-infrastruktuurin, liiketoimintaprosessit kuin

henkilöstön osaamisen kehittämisen. Keskeisiä kysymyksiä pilvistrategiaa laatiessa ovat, mitkä sovellukset ja työkuormat siirretään pilveen, miten riskejä hallitaan ja miten pilvipalveluita hyödynnetään kilpailukyvyn parantamiseksi.

Pilvistrategia auttaa pitämään kustannukset kurissa

Ilman strategiaa pilvipalveluiden tarjoamat liiketoiminnalliset hyödyt tuppaavat jäämään laihoiksi. Tavoitellut kustannussäästöt eivät ole löytäneet tietään laskulle saakka tai lift-and-shitft migraation tuloksena palvelut eivät skaalaudukaan odotetusti. Pilvistrategian auttaa varmistamaan, että pilvipalveluiden käyttöönotto tukee liiketoiminnan tavoitteita ja tuo aidosti arvoa. Huolellisesti laaditun pilvistrategian seurauksena saavutetaan esimerkiksi seuraavia liiketoimintaetuja:

1. Kustannustehokkuus – Oikein optimoidut pilvipalvelut vähentävät IT-infrastruktuurin

kustannuksia ja mahdollistavat resurssien tehokkaamman kohdentamisen. Keskiöön

nousevat mm. oikeiden laskutusmallien ja palveluiden valinta.

2. Joustavuus ja skaalautuvuus – Pilviratkaisut mahdollistavat nopean reagoinnin

liiketoimintaympäristön muutoksiin ja tukevat yrityksen kasvua ilman suuria investointeja

laitteistoihin.

3. Innovaatioiden nopeampi kehitys – Pilviympäristö mahdollistaa uusien sovellusten ja

palveluiden kokeilun ja kehittämisen ketterästi. Serverless-ratkaisut ja automaattiset CI/CD putket nopeuttavat kehityssyklejä.

4. Parempi tietoturva ja hallittavuus – Pilvistrategian avulla voidaan varmistaa, että

tietoturva ja regulaatio huomioidaan asianmukaisesti. Keskitetyt hallintatyökalut, automaattiset päivitykset ja kehittyneet uhkatunnistusjärjestelmät parantavat turvallisuutta ja vähentävät manuaalisen ylläpidon tarvetta.

Huomioi nämä pilvistrategiaa laatiessa

Onnistunut pilvistrategia edellyttää selkeää visiota ja suunnitelmallisuutta, jotta pilvipalveluiden käyttöönotto tukee yrityksen pitkäaikaisia tavoitteita ja mahdollistaa liiketoiminnan kestävän kehityksen. Pilvipalveluiden tulee tukea yrityksen strategisia päämääriä, joten pilvistrategian hahmottelukin on hyvä aloittaa liiketoimintatavoitteiden määrittelystä. Kaikkia työkuormia ei välttämättä ole kannattavaa siirtää pilveen, joten on tärkeää tunnistaa mitkä sovellukset ja prosessit hyötyvät eniten pilveen siirtymisestä.

Myös itse pilvimalleissa on eroavaisuuksia. Pilvimallin valinta vaikuttaa suoraan yrityksen operatiiviseen tehokkuuteen ja vaatimustenmukaisuuteen. Julkinen pilvi tarjoaa kustannustehokkuutta ja skaalautuvuutta, kun taas yksityinen pilvi voi olla parempi vaihtoehto silloin, kun tietoturva ja sääntely asettavat tiukempia vaatimuksia. Hybridiratkaisu yhdistää molempien mallien edut ja mahdollistaa joustavan infrastruktuurin rakentamisen.

Pilvipalveluissa toimitaan jaetun vastuun mallilla, jossa palveluntarjoaja vastaa infrastruktuurin suojaamisesta, mutta asiakas huolehtii omien sovellustensa ja datansa turvallisuudesta. Tietoturvan huomioiminen nousee siis keskiöön pilvipalveluiden käytössä.

Onnistunut pilvisiirtymä vaatii vahvaa IT-hallintaa ja osaamista. Pilvipalveluiden hallinta vaatii selkeitä toimintamalleja, koulutusta ja jatkuvaa kehittämistä, jotta palveluiden käyttö on tehokasta ja turvallista. Ilman riittävää asiantuntemusta pilven hyödyt jäävät ulottumattomiin joka näkyy usein myös hintalapussakin.

Pilvistrategia auttaa hahmottamaan omat kyvykkyydet

Parhaimmillaan pilvi tarjoaa joustavan infrastruktuurin, joka mahdollistaa nopeat kehityssyklit sekä ketterän mukautumisen markkinoiden muutoksiin. Pilvellä ei kuitenkaan ole itseisarvoa, eikä sen käyttöönotto yksinään takaa menestystä. Tarvitaankin selkeää strategiaa, joka tukee liiketoiminnan tavoitteita ja varmistaa pilvipalveluiden hallitun hyödyntämisen.

Pilvistrategia helpottaa myös hahmottamaan mihin osa-alueille saatetaan kaivata ulkopuolisen kumppanin apuja. Webscale on kokenut kumppani pilvipalveluiden parissa. Autamme asiakkaitamme joustavin kaupallisin mallein pilvimatkan jokaisessa vaiheessa, ole yhteydessä ja keskustellaan lisää!

Miro Nissilä
Sales Specialist

Kysy konsultilta: Mikä on Amazon Cognito?

Wed, 19 Feb 2025 07:16:01 GMT

Mikä on Amazon Cognito?

Amazon Cognito on AWS:n tarjoama palvelu turvalliseen ja skaalautuvaan asiakasidentiteetin- ja pääsynhallintaan (Customer Identity and Access Management, eli CIAM). Kehittäjät voivat käyttää Cognitoa helpottamaan autentikaation, auktorisoinnin ja käyttäjähallinnan lisäämistä sovelluksiin, jolloin käyttäjät voivat esimerkiksi kirjautua sovelluksiin sekä suorittaa sallittuja toimintoja. Cogniton tärkeimmät komponentit ovat User Pool ja Identity Pool.

User Pool on on käyttäjähakemisto, eli se pitää sisällään käyttäjien tiedot (profiilit, attribuutit ja ryhmät). Käyttäjät voidaan rekisteröidä suoraan User Pooliin, jolloin User Pool toimii itsenäisenä Identity Providerina (IdP) näille käyttäjille, eli tällöin User Pool säilyttää ja verifioi identiteetit. Toinen vaihtoehto on käyttää federointia, jolloin käyttäjät kirjautuvat sisään sovellukseen kolmannen osapuolen IdP:tä, kuten Amazonin, Facebookin, Googlen, Applen tai muun yhteensopivan (SAML tai OpenID Connect) IdP:n avulla. Tällöin User Pool toimii sovelluksen ja kolmannen osapuolen IdP:n välissä. Käyttäjän onnistuneen sisäänkirjautumisen päätteeksi User Pool palauttaa JSON web tokenit, joita käytetään haluttuun toimintoon, kuten esimerkiksi tietojen hakemiseen backend-palvelusta. Kehittäjien ei tarvitse toteuttaa käyttöliittymiä itse, sillä Cognito myös tarjoaa valmiita toteutuksia, kuten esimerkiksi rekisteröityminen ja sisäänkirjautuminen. User Poolin toiminnallisuutta voi myös mukauttaa Lambda-funktioiden avulla (Lambda triggers). User Poolissa on myös useita erilaisia ominaisuuksia, kuten esimerkiksi monivaiheinen tunnistautuminen (MFA), konfiguroitavat salasanan vaatimukset, CAPTCHA-tuki, kirjautuminen ilman salasanaa sekä tuki AWS WAF -palomuurille.

Identity Pool puolestaan mahdollistaa käyttäjille pääsyn AWS-palveluihin, kuten esimerkiksi pääsyn S3-palveluun. Identity Pool antaa käyttäjälle väliaikaiset AWS-tunnukset, joita käytetään pyyntöjen tekemiseen sallittuihin AWS-palveluihin. Käyttäjän autentikaatio voidaan tehdä käyttämällä User Poolia tai muuta IdP:tä, kuten Amazon, Facebook, Google, Apple tai muuta yhteensopivaa (SAML tai OpenID Connect) IdP:tä. Halutessaan Identity Poolin voi konfiguroida palauttamaan väliaikaiset AWS-tunnukset myös anonyymeille käyttäjille, eli käyttäjille, jotka eivät ole kirjautuneet sisään sovellukseen. Identity Pool tarvitsee IAM-roolin väliaikaisia AWS-tunnuksia varten. IAM-roolin avulla määritellään mitä oikeuksia käyttäjällä on. Autentikoituneille ja anonyymeille käyttäjille voidaan määritellä eri IAM-roolit.

Cognitoa voidaan käyttää myös muiden AWS-palveluiden kanssa, kuten esimerkiksi API Gateway ja AppSync. AppSync-palvelun (GraphQL API) kanssa Cognitoa voidaan käyttää esimerkiksi siten, että käyttäjä kirjautuu sisään sovellukseen käyttäen Cognito User Poolia ja saa sieltä JWT-tokenin. Tätä tokenia käytetään AppSync-pyynnössä, ja AppSync voidaan konfiguroida siten, että tietyt operaatiot ovat sallittuja tietylle käyttäjäryhmälle. Tieto käyttäjän mahdollisista ryhmistä tulee User Poolista ja token sisältää kyseisen tiedon. Käyttäjä saa suorittaa operaation mikäli hän kuuluu sallittuun ryhmään, ja käyttäjälle palautetaan virhe mikäli token ei sisällä vaadittua ryhmää/tietoa.

Jukka Ukkonen

Senior Consultant

CloudFormation-palvelun uusi ominaisuus: AWS CloudFormation Hooks

Thu, 13 Feb 2025 11:31:46 GMT

CloudFormation-palvelun uusi ominaisuus: AWS CloudFormation Hooks

AWS CloudFormation Hooks on CloudFormation-palvelun uusi ominaisuus, jolla voidaan tarkistaa, että kaikki infrastruktuuriin tehtävät muutokset noudattavat ennalta määriteltyjä sääntöjä, esimerkiksi, että kaikki resurssit on tägätty oikein.

Hookit ovat siis eräänlaisia portteja, joiden läpi jokaisen halutun muutokset tulee kulkea ennen niiden varsinaista toimeenpanoa. Jos kaikki on kunnossa, muutos pääsee jatkamaan matkaansa ja siitä tulee osa infrastruktuuria. Jos taas jokin ei täytä vaatimuksia, CloudFormation estää muutoksen.

Hookeja on kolmea tyyppiä: Guard Hook , AWS Lambda ja Custom Hook .

Guard Hook hyödyntää CloudFormation Guard -sääntöjä ja varmistaa, että resurssit noudattavat niitä sääntöjä. CloudFormation Guard sääntöjä voi helposti määritellä itse.
AWS Lambda mahdollistaa resurssien ohjelmallisen tarkistamisen ja helpon integroinnin muihin AWS-palveluihin. Lisäksi AWS Lambdan avulla Hookeja voi käyttää muuhunkin kuin vain resurssien tarkistamiseen.
Custom Hookin avulla voidaan luoda omia, räätälöityjä sääntöjä resursseille Java- tai Python-ohjelmointikielillä. AWS Lamdalla voi kuitenkin tehdä saman helpommin, joten Custom Hookit jäänevät hiljalleen pois käytöstä.

Heikki Ma

Senior Consultant

Webscale saavutti AWS DevOps Services Competencyn - mitä tämä tarkoittaa asiakkaillemme?

Tue, 11 Feb 2025 06:51:51 GMT

AWS DevOps Services Competency on merkittävä virstanpylväs yrityksellemme ja osoitus sitoutumisestamme korkealaatuisiin DevOps-palveluihin AWS-ympäristössä. Mutta mitä tämä tarkoittaa asiakkaillemme, ja miksi AWS Competency -ohjelma on tärkeä?

Mistä AWS Competency -ohjelmassa on kyse?

AWS Competency -ohjelman tarkoitus on auttaa asiakkaita löytämään AWS-kumppaniyrityksiä, jotka ovat erikoistuneet tiettyyn teknologiaan tai palvelumalliin. Competencyja on lukuisia erilaisia ja sellaisen saavuttaminen vaatii kumppanilta todistetusti korkeaa asiantuntemusta ja menestyksekkäitä asiakasratkaisuja Competencyn osa-alueilla.

Mikä on AWS DevOps Services Competency?

AWS DevOps Services Competency myönnetään kumppaniyrityksille, jotka ovat osoittaneet syvällistä osaamista DevOps-käytäntöjen ja -työkalujen hyödyntämisessä AWS-alustalla. Tämä sisältää muun muassa:

Infrastruktuurin hallinnan (IaC) parhaiden käytäntöjen mukaisesti.
Pitkälle viedyn automaation ja CI/CD-putkien toteutuksen.
Monitoroinnin ja lokien hallinnan.
Tietoturvan ja standardien varmistamisen kaikissa DevOps-työn vaiheissa.
Työmenetelmät, prosessit ja dokumentaation.
DevOps-kulttuurin ja roolien jalkauttaminen asiakasorganisaatioon.

Kumppaniyritykselle asetetut vaatimukset ovat tiukat ja niiden täyttyminen varmistetaan ulkopuolisen auditoijan toimesta.

Miten tämä hyödyttää asiakkaitamme?

Webscale on tarjonnut jo yli kymmenen vuoden ajan laadukkaita asiantuntijapalveluita AWS-pilveen ja DevOps-käytäntöihin liittyen. AWS DevOps Services Competency on osoitus jatkuvasta panostuksestamme asiakkaidemme menestykseen ja todistaa, että palvelumme ja prosessimme täyttävät AWS:n asettamat korkeat standardit.

Valitsemalla Webscalen kumppanikseen, asiakas voi luottaa saavansa käyttöönsä todistetusti huipputason DevOps-osaamisen sekä vuosikymmenen verran kokemusta vaativista projekteissa, joissa viimeisin teknologia on onnistuneesti tuotu osaksi asiakasorganisaation palvelukehitystä ja kulttuuria.

Henri Meltaus

CTO

Kysy konsultilta: Mikä on Elastic Load Balancing (ELB) ja mihin sitä tarvitaan?

Wed, 29 Jan 2025 08:52:08 GMT

Mikä on Elastic Load Balancing (ELB) ja mihin sitä tarvitaan?

Elastic Load Balancing (ELB) on AWS-palvelu, jonka ensisijainen tarkoitus on nimensä mukaisesti kuormanjako. ELB:n avulla voidaan jakaa verkosta tulevia pyyntöjä pyyntöjen käsittelijöille tasaisesti tai erilaisin painotuksin. Kuormanjaon kohteena voi olla esimerkiksi IP-osoitteet, EC2-instanssit tai konteissa ajettavat palvelut (ECS, Fargate). ELB on AWS:n ylläpitämä automaattisesti skaalautuva palvelu ja se toimii usealla maantieteellisesti hajautetulla Availability Zonella. Yhdistämällä ELB-kuormanjaon AWS Autoscalingin avulla automaattisesti skaalautuviin taustapalveluihin voidaan rakentaa järjestelmä, joka kestää huomattavaa kuormitusta.

AWS tarjoaa kaksi ELB-versiota, joista v2 sisältää kolme eri OSI-mallin kerroksilla toimivaa ja eri käyttötarkoituksiin soveltuvaa palvelua:

V1:

Classic Load Balancer

V2:

Application Load Balancer (ALB)
Network Load Balancer (NLB)
Gateway Load Balancer (GWLB)

Application Load Balancer toimii OSI-mallin application-tasolla ja sopii HTTP- ja HTTPS-liikenteen kuormanjakoon. Application-tasolla toimiminen antaa enemmän mahdollisuuksia kuormanjaon sääntöjen määrittelyyn kuin OSI-mallin alemmilla tasoilla toimittaessa. Kuormanjaossa voidaan hyödyntää esimerkiksi url-polkuja tai pyynnön header-tietoja. Pyyntöjä voidaan myös ohjata monipuolisemmin eri kohteisin kuin muilla ELB-tyypeillä: kuormaa voidaan ohjata eri domaineihin tai esimerkiksi AWS Lambda -funktioille. ALB mahdollistaa myös esimerkiksi liikenteen ohjauksen siten, että saman asiakkaan kutsut ohjautuvat aina samalle pyyntöjen käsittelijälle (sticky sessions). ALB:tä voidaan käyttää myös HTTPS-terminointiin, jolloin pyyntöjen käsittelijöiden ei tarvitse huolehtia liikenteen salauksesta.

Network Load Balancer toimii OSI-mallin transport-tasolla. NLB tarjoaa matalimman latenssin ja se kestää eniten kuormitusta, eli se soveltuu äärimmäistä suorituskykyä vaativiin sovelluksiin. NLB:n avulla saadaan kuormanjako tehtyä läpinäkyvästi application-tason suhteen. Toisin kuin ALB:lle, NLB:lle on mahdollista antaa kiinteä IP-osoite ja alkuperäisen kutsujan IP-osoite välittyy kutsun käsittelijälle.

Gateway Load Balancer toimii OSI-mallin network-tasolla ja on suunniteltu verkkotason valvontaan, suojaukseen ja analysointiin käytettyjen virtuaalilaitteiden, kuten palomuurien, tunkeutumisen tunnistukseen ja estoon sekä verkkopakettien analysointiin käytettyjen palveluiden hallintaan ja skaalaamiseen.

Classic load balancer on AWS:n alkuperäinen OSI-mallin transport-tasolla toimiva kuormanjakaja, joka on olemassa enää lähinnä taaksepäin yhteensopivuus syistä, eikä sitä ole syytä käyttää uusissa sovelluksissa.

Markus Nousiainen

Senior Consultant

Kysy konsultilta: Miten Kubernetesin avulla voidaan orkestroida kontteja?

Tue, 14 Jan 2025 08:22:50 GMT

Miten Kubernetesin avulla voidaan orkestroida kontteja?

Kubernetes on avoimen lähdekoodin alusta, joka mahdollistaa konttien orkestroinnin automatisoidusti ja skaalautuvasti. Se ryhmittelee palvelimet klusteriksi, jossa ohjaustaso (control plane) hallitsee konttien sijoittelua (scheduler) ja kuormituksen tasapainotusta, kun taas solmut (nodes) suorittavat itse kontit. Kubernetes käyttää deklaratiivisia konfiguraatiotiedostoja, joiden avulla määritellään esimerkiksi konttien määrä, resurssivaatimukset ja sijoittelustrategiat. Skaalautuvuus hoidetaan automaattisesti kuormituksen perusteella, ja resurssien käyttö optimoidaan tehokkaasti.

Verkonhallinta mahdollistaa konttien välisen kommunikoinnin ja ulkoisen liikenteen hallinnan palvelu- ja ingress-abstraktioiden avulla. Kubernetes huolehtii myös virheistä käynnistämällä uudelleen kaatuneet kontit ja korvaamalla vialliset solmut. Tallennus hoituu pysyvien tallennusvolyymien (persistent volume, PV) sekä dynaamisten tallennusluokkien kautta esimerkiksi pilvipalvelutarjoajan tallennuspalveluun (esim. EBS AWS:ssä).

Yhteenvetona Kubernetes yksinkertaistaa sovellusympäristöjen hallintaa tarjoamalla automatisoidut ratkaisut konttien käyttöönottoon, skaalaukseen, verkotukseen ja virheiden hallintaan, mikä tekee siitä erityisen hyödyllisen modernien pilvinatiivien sovellusten kehityksessä.

Kalle Soranko

Senior Consultant

Amazon CloudFrontilta suora yhteys sisäverkkoon

Wed, 18 Dec 2024 07:06:50 GMT

Amazon CloudFrontilta suora yhteys sisäverkkoon

Amazon CloudFront on maailmanlaajuinen sisällönjakelupalvelu (CDN), jonka kautta voidaan jaella verkkosisältöä, kuten sovelluksia ja verkkosivustoja, nopeasti ja turvallisesti käyttäjille ympäri maailmaa. Se hyödyntää AWS:n globaalia verkkoa vähentääkseen latenssia ja parantaakseen suorituskykyä, samalla tarjoten kehittyneitä tietoturvaominaisuuksia.

CloudFrontin lähteenä (origin) voidaan hyödyntää AWS:n muita palveluita kuten S3:a, josta voidaan jaella staattisia resursseja, kuten verkkosivustoja, kuvia ja videoita. Aiemmin asiakkaan virtuaalisesta verkosta (VPC) on voinut jakaa sisältöä CloudFrontin kautta vain, jos sisältö on ollut saatavissa internetiin esimerkiksi kuormanjakajan kautta tai suoraan palvelimelta.

AWS julkaisi juuri ennen vuoden 2024 re:Invent-tapahtumaansa merkittävän parannuksen CloudFront-palveluun. Tästä lähtien CloudFrontin lähteenä voidaan käyttää myös sellaisia VPC-virtuaaliverkossa sijaitsevia resursseja, joita ei ole avattu internetiin.

Uusi ominaisuus mahdollistaa yksinkertaisemman arkkitehtuurin, sillä sovellusta ei enää tarvitse tehdä internetiin näkyväksi vain CloudFrontin lähteeksi liittämistä varten. Arkkitehtuurista voidaan poistaa ylimääräiset verkkoresurssit, mikä pienentää myös kustannuksia. Lisäksi tietoturva paranee, koska kaikki liikenne CloudFrontin ja sovelluksen välillä kulkee sisäverkossa, mikä pienentää vihamielisen tahon hyödynnettävissä olevaa hyökkäyspinta-alaa.

Linkki alkuperäiseen julkaisuun

Heikki Ma

Senior Consultant

Webscale Oy esittelee uuden yrityskohtaisen työehtosopimuksen: joustavuus ja työntekijöiden hyvinvointi etusijalla

Tue, 10 Dec 2024 09:33:10 GMT

Työehtosopimukset ovat olennainen osa suomalaista työelämää, ja niiden rooli korostuu erityisesti IT-alan kaltaisella nopeasti kehittyvällä alalla. Olemme Webscalella pitkään pohtineet, miten voisimme kehittää työolojamme niin, että ne eivät vain täyttäisi lakisääteisiä vaatimuksia, vaan myös tukisivat kokonaisvaltaisesti työntekijöidemme hyvinvointia, ammatillista kasvua ja yrityksen menestystä parhaalla mahdollisella tavalla. Tämä johti meidät neuvottelemaan yrityskohtaisen työehtosopimuksen osana laajempaa tavoitettamme rakentaa entistä parempaa työpaikkaa.

Miksi yrityskohtainen TES?

Haluamme erottua markkinassa ja tarjota työntekijöillemme räätälöityjä, kilpailukykyisiä työehtoja. Yrityskohtainen TES mahdollistaa joustavuuden esimerkiksi työaikojen, etätyön ja palkkaneuvotteluiden osalta, mikä tukee työntekijöidemme jaksamista ja motivaatiota. Lisäksi se helpottaa sopimusehtojen tulkintaa ja parantaa sitoutumista tarjoamalla henkilöstöllemme mahdollisuuden vaikuttaa omaan työelämäänsä. Näin voimme varmistaa, että pysymme houkuttelevana työpaikkana alan huippuosaajille myös jatkossa.

”Yrityskohtainen TES tukee sekä työntekijöidemme hyvinvointia että liiketoimintamme kasvua. Sopimus tuo selkeyttä yhteisiin pelisääntöihin, mutta mahdollistaa samalla joustavuuden, joka on erityisen tärkeää nopeasti kehittyvällä IT-alalla. Se takaa, että työehdot pysyvät kilpailukykyisinä ja vastaavat työntekijöidemme tarpeita, samalla kun luomme edellytykset motivoivalle työympäristölle. Haluamme varmistaa, että Webscale on paitsi hyvä työpaikka, myös houkutteleva valinta alan parhaille osaajille.” toteaa Webscalen toimitusjohtaja Tero Kauhanen.

Työn ja vapaa-ajan tasapaino

Uuden yrityskohtaisen TES:in myötä korostamme työntekijöiden hyvinvointia uudistamalla perhevapaat ja ottamalla käyttöön työaikapankin.

Palkalliset vanhempainvapaat kaikille vanhemmille – synnyttäville, ei-synnyttäville, adoptiovanhemmille sekä muulle lapsen hoitoon osallistuvalle henkilölle, jolle on luovutettu vanhempainvapaata – takaavat mahdollisuuden osallistua perhe-elämään tasa-arvoisesti ilman taloudellisia esteitä.

Työaikapankki tuo joustoa työntekijöiden arkeen, mahdollistaen ylimääräisten työtuntien hyödyntämisen vapaina tai erilaisten elämänvaiheiden tasapainottamiseen.

"Työ ja vapaa-aika kulkevat meillä käsi kädessä. Palkalliset vanhempainvapaat ja työaikapankki ovat tapojamme tukea työntekijöidemme arkea ja varmistaa, että jokaisella on mahdollisuus tasapainoiseen elämään." toteaa Varpu Kekkonen, People and Organizational Development Lead.

Tasapuolisuus ja selkeys

Webscale haluaa varmistaa, että työntekijöiden panos ja tarpeet huomioidaan oikeudenmukaisesti. Uusi työehtosopimus tuo selkeyttä mm. hälytys- ja varallaolokorvauksiin, jotta erityistilanteissa tehtävä työ saa asianmukaisen arvostuksen myös jatkossa.

Lisäksi uusille työntekijöille tarjotaan mahdollisuus yhdistää palkalliset ja palkattomat lomat neljän viikon yhtäjaksoiseksi lomaksi, mikä helpottaa työsuhteen alkuvaihetta ja edistää sopeutumista. Nämä uudistukset tukevat työntekijöiden hyvinvointia ja vahvistavat Webscalen sitoutumista reiluun ja työntekijälähtöiseen toimintatapaan.

“Työntekijöille paikallinen sopimus tarjoaa selkeän vuoropuhelualustan yrityksen ja työntekijöiden välille luoden yrityksen henkilöstöasioihin uudella tavalla sitoutumista ja kiinnostavuutta. Nyt neuvoteltu paikallinen sopimus antaa alkusysäyksen jatkuvalle prosessille, jolla TES-asiat ovat huomattavasti lähempänä työntekijää ja vaikuttamismahdollisuudet konkreettisemmat.” linjaa Webscalen luottamushenkilö Ville Välimäki.

Selkeytetty palkkaus

Uuden TES:in myötä Webscalen palkkaus perustuu selkeisiin periaatteisiin, joissa yhdistyvät tehtävän vaativuus, työntekijän pätevyys ja yrityksen määrittelemät muut palkkaperiaatteet. Vuosittaisista palkantarkistuksista neuvotellaan paikallisesti luottamushenkilön kanssa. Näillä tuodaan läpinäkyvyyttä ja joustavuutta korotusten jakamiseen.

On selvää, että taloudelliset tulokset vaikuttavat palkkakehitykseen – mutta yhtä selvää on, että hyvä työ ansaitsee reilun palkitsemisen. Tämä on tasapaino, jonka haluamme säilyttää.

Tervetuloa tutustumaan Webscalen yrityskohtaiseen työehtosopimukseen.

Varpu Kekkonen

People and Organizational Development Lead

AWS Console to Code - Generoi IaC-koodia hallintakonsolia käyttämällä

Wed, 20 Nov 2024 07:08:57 GMT

AWS Console to Code - Generoi IaC-koodia hallintakonsolia käyttämällä

AWS-konsolista löytyy nyt uusi ominaisuus nimeltä AWS Console to Code. Sen avulla käyttäjä voi antaa tekoälyn seurata konsolin kautta suorittamiaan toimintoja ja generoida sitten niiden pohjalta valmista CDK-koodia, CloudFormation-templateja tai komentoja komentorivikäyttöä ja skriptausta varten.

Pilvi-infran luonti konsolin kautta klikkailemalla on tietysti ollut jo pitkään ns. anti-pattern pilviarkkitehtien parissa, joten voisi kysyä onko Console to Code askel eteen- vai taaksepäin? Suunta on kuitenkin ehdottomasti oikea, sillä Console to Code auttaa pilvi-infran parissa työskenteleviä olemaan tehokkaampia työssään generoimalla viimeistelyä vaille valmista koodia. Tämä puolestaan vapauttaa aikaa keskittyä niihin enemmän ajattelua vaativiin tehtäviin, jotka yleisesti koetaan myös mielekkäämmiksi. Periaate on siis hyvin samankaltainen kuin monella muullakin generatiiviseen tekoälyyn perustuvalla työkalulla.

Erilaisten nopeiden kokeilujen ja proof-of-conceptien tekoon Console to Code on varmasti hyödyllinen - varsinkin jos projektia halutaan jatkossa ylläpitää ja kehittää IaC-periaatteiden mukaan. Juuri projektin aloitukseen ja uusien resurssien luontiin tämä työkalu sopiikin parhaiten, sillä jo olemassa olevien resurssien muokkaus ei ole vielä täysin tuettu. Näin alkuun työkalun hyödyllisyyttä vähentää myös se, että tuettujen AWS-palveluiden lista on varsin vaatimaton, sisältäen vain EC2:n, VPC:n ja RDS:n. Niilläkin toki pääsee alkuun ja tuki varmasti laajenee jatkossa.

Lue lisää aiheesta: https://aws.amazon.com/about-aws/whats-new/2024/10/general-availability-console-to-code-generate-code/

Heikki Ma

Senior Consultant

AWS S3 Conditional Writes - Lisää kontrollia S3-tallennukseen

Wed, 23 Oct 2024 06:17:15 GMT

AWS S3 Conditional Writes - Lisää kontrollia S3-tallennukseen

Amazon S3 on AWS:n skaalautuva tallennuspalvelu pilvessä. Se tarjoaa suuren joukon ominaisuuksia, jotka mahdollistavat tiedon turvallisen säilyttämisen ja tehokkaan käsittelyn.

Hetki sitten julkaistun Conditional Writes -ominaisuuden myötä käyttäjät voivat asettaa ehtoja, joiden on täytyttävä, jotta tiedoston kirjoitus S3:een onnistuu. Tämä mahdollistaa tarkemman kontrollin tietojen päivityksille auttaen estämään ei-toivottuja muutoksia kuten olemassa olevien tiedostojen ylikirjoittamista vanhalla datalla. Ehdot voivat perustua muun muassa tiedoston metadataan, versionumeroon tai tageihin.

Conditional Writes on erityisen hyödyllinen, kun hallinnoidaan tietovarastoja, joihin useat järjestelmät tai käyttäjät saattavat tehdä päivityksiä samanaikaisesti. Aikaisemmin tällainen logiikka on pitänyt rakentaa itse sovelluksen puolelle, mutta nyt sen voi jättää S3:n huoleksi.

Lue lisää aiheesta: https://aws.amazon.com/about-aws/whats-new/2024/08/amazon-s3-conditional-writes/

Heikki Ma

Senior Consultant

Kysy konsultilta: Mitkä ovat AWS Lambda-layerit?

Thu, 17 Oct 2024 07:29:58 GMT

Mitkä ovat AWS Lambda-layerit?

AWS Lambda layer on resurssi, jonka avulla Lambda-funktiolle voidaan antaa riippuvuuksia, dataa tai konfiguraatiotiedostoja funktion oman deployment-paketin ulkopuolella. Lambda layer luodaan pakkaamalla tarvittavat tiedostot erilliseen zip-pakettiin ja luomalla siitä Lambda-layer -resurssi.

Lambda layerin selvä hyöty on siinä, että deployment-paketista tulee yksinkertaisempi ja pienempi, kun riippuvuudet on pakattu erilliseen pakettiin. Tällöin myös deployment-paketin luominen yksinkertaistuu kun riippuvuuksia ei tarvitse sisällyttää samaan pakettiin kuin itse funktiokoodia. Yhtä Lambda layer -resurssia voidaan käyttää monen Lambda-funktion kanssa.

Lambda layerit mahdollistavat myös muiden kuin itse funktion toteuttamiseen käytetyn ohjelmointikielen kirjastojen käytön riippuvuuksina. Esimerkiksi komentorivityökalun pakkaaminen binäärimuodossa Lambda layeriin on mahdollista, jolloin kyseistä komentorivityökalua voidaan kutsua Lambda-funkion koodista.

Lambda layer liitetään Lambda-funktioon seuraavalla tavalla:

1. Luo Lambda layer zip-paketti, joka sisältää tarvittavat tiedostot

2. Luo Lambda layer-resurssi

3. Luo Lambda-funktio, johon haluat liittää Lambda layerin

4. Liitä Lambda layer-resurssi Lambda-funktioon

On hyvä tiedostaa, että Lambda layer-paketin maksimikoko on 50MB ja yksi Lambda-funktio voi käyttää maksimissaan viittä Lambda layeria. Lisäksi kun Lambda layeria päivitetään, niin layeristä luodaan uusi versio, joka täytyy liittää Lambda-funktioon erikseen.

Kalle Soranko

Senior Consultant

Webscale nousee uudelle tasolle AWS-kumppanina

Thu, 10 Oct 2024 08:41:07 GMT

Webscale on saavuttanut kaksi uutta AWS-kumppanuutta – AWS Well-Architected Partner ja AWS CloudFormation Delivery Partner . Näiden kumppanuuksien ansiosta voimme auttaa asiakkaitamme entistäkin paremmin rakentamaan, kehittämään ja ylläpitämään AWS-ympäristöjään parhaiden käytäntöjen mukaisesti.

AWS Well-Architected Partner – varmistamme parhaat käytännöt

AWS Well-Architected -kumppanuus mahdollistaa entistä laadukkaampien arviointien ja suositusten tarjoamisen asiakkaillemme heidän AWS-ratkaisujensa kehittämiseen. Well-Architected on malli, joka auttaa organisaatioita rakentamaan turvallisia, tehokkaita ja luotettavia pilviympäristöjä AWS:n parhaiden käytäntöjen mukaisesti. Sen avulla voidaan arvioida nykyisiä arkkitehtuuriratkaisuja, tunnistaa mahdolliset haasteet ja löytää kehityskohteita.

Well-Architected -katselmoinneilla varmistamme yhdessä asiakkaan kanssa, että sovellukset ja työkuormat toimivat pilvessä optimaalisesti ja turvallisesti. Kun tunnistamme kehityskohteita, asiakkaamme voivat myös hyödyntää AWS:n tarjoamaa rahoitusta parannusten toteuttamiseen. Palvelumme tekee arkkitehtuurin optimoinnista jatkuvaa ja joustavaa, pitäen pilviympäristön ajan tasalla ja toimintakykyisenä.

AWS CloudFormation Delivery Partner – pilvi-infra hallintaan

Infrastructure as Code (IaC) eli pilvi-infrastruktuurin määrittely ja hallinta koodilla tekee työstä pilven parissa tehokkaampaa sekä mahdollistaa pitkälle viedyn automaation. IaC onkin aina ollut olennainen osa Webscalen työtä; oli kyse sitten kokonaan uuden palvelun toteuttamisesta tai olemassa olevien järjestelmien ylläpidosta.

IaC-työkaluja on useita, joista valitsemme asiakkaan tarpeisiin sopivimman vaihtoehdon. CloudFormation on AWS:n oma laajasti käytetty työkalu, johon perustuu myös useita muita korkeamman tason IaC-ratkaisuja, kuten AWS CDK ja Serverless Framework.

AWS CloudFormation Delivery -kumppanuuden myötä tarjoamme asiakkaillemme syvällistä asiantuntemusta infrastruktuurin hallintaan CloudFormationin avulla. Olemme valmiita auttamaan parhaiden IaC- ja DevOps-käytäntöjen tuomisessa osaksi jokapäiväistä toimintaa.

Yhdessä kohti parempaa pilveä

Nämä uudet AWS-kumppanuudet vahvistavat kykyämme toimia asiakkaidemme luotettavana pilvikumppanina. Tarjoamme entistä laajemman palveluvalikoiman, jotta asiakkaidemme pilviympäristöt pysyvät suorituskykyisinä, turvallisina ja kustannustehokkaina.

Lue lisää Well-Architected Review -palvelustamme .

Tero Kauhanen

Toimitusjohtaja

Asiakkaidemme kiitokset lämmittävät – NPS-tuloksemme 100!

verkkosivut@webscale.fi (Tero Kauhanen) — Fri, 04 Oct 2024 06:25:32 GMT

Asiakastyytyväisyys on jokaisen yrityksen menestyksen kulmakivi, ja meille Webscalella se on yksi tärkeimmistä toimintamme mittareista. Tänä vuonna toteuttamamme NPS-kysely osoitti jälleen, että panostuksemme osaamisen ja palveluiden kehittämiseen sekä luottamuksellisten asiakassuhteiden rakentamiseen kantavat hedelmää.

Tuloksemme – NPS 100 – ei ole pelkkä luku; se on osoitus siitä, että olemme onnistuneet tuottamaan asiakkaillemme todellista arvoa yhteistyökumppanina. Syksyn viileneviin päiviin tällaiset uutiset tuovat erityistä lämpöä ja iloa.

NPS-tuloksesta tänä ja viime vuonna

NPS, eli Net Promoter Score, mittaa asiakkaiden halukkuutta suositella meitä yhteistyökumppanina. Asteikolla -100 ja +100 välillä 100 on korkein mahdollinen tulos ja upea osoitus asiakkaidemme tyytyväisyydestä.

Viime vuonna NPS-tuloksemme oli jo loistava: 95. Saimme tuolloin arvokkaita näkemyksiä siitä, mikä tekee yhteistyöstämme erinomaista ja missä voisimme vielä kehittyä. Olemme tarttuneet tähän palautteeseen ja tehneet määrätietoista työtä parantaaksemme palveluja ja toimintojamme entisestään.

Mitä NPS 100 meille merkitsee?

Olemme erittäin kiitollisia ja otettuja siitä, että asiakkaamme arvostavat yhteistyötämme ja kokevat sen hyödylliseksi. Vaikka tuloksemme on korkein mahdollinen, emme pysähdy tähän. Palautteiden avulla olemme jo tunnistaneet kehittämiskohteita, ja jatkamme työtämme palveluiden ja prosessiemme kehittämiseksi. Haluamme ansaita asiakkaidemme luottamuksen joka päivä, jokaisessa kohtaamisessa.

NPS 100 on kunnianosoitus koko tiimillemme. Webscalella on sitoutunut ja asiantunteva porukka, joka tekee joka päivä parhaansa asiakkaidemme menestyksen eteen. Haluan kiittää koko henkilöstöämme upeasta työstä ja omistautumisesta tavoitteiden saavuttamiseksi!

Kiitos asiakkaillemme

Suurin kiitos kuuluu asiakkaillemme. Olemme ylpeitä saadessamme tehdä yhteistyötä kanssanne, ja arvostamme suuresti luottamustanne ja palautettanne. Teidän ansiostanne meillä on mahdollisuus kehittyä ja kasvaa.

Syksy on täynnä uusia mahdollisuuksia, ja odotamme innolla tulevia kohtaamisia!

Tero Kauhanen

Toimitusjohtaja

AWS CloudFormation IaC generatorin viimeisin päivitys tuo merkittävän parannuksen

Fri, 27 Sep 2024 09:00:36 GMT

AWS CloudFormation IaC generatorin viimeisin päivitys tuo merkittävän parannuksen

AWS CloudFormation on palvelu, joka helpottaa infrastruktuurin hallintaa AWS-pilvessä. Se mahdollistaa resurssien, kuten virtuaalikoneiden, tietokantojen ja verkkokonfiguraation, hallinnan koodin avulla (Infrastructure-as-Code, IaC). IaC tekee pilviresurssien hallinnasta tehokasta ja toistettavaa sekä mahdollistaa siihen liittyvän työn automatisoinnin.

Viimeisin päivitys tuo merkittävän parannuksen CloudFormation IaC -generaattoriin. Jatkossa käyttäjät saavat AWS-tilin skannauksen jälkeen visuaalisen yhteenvedon skannatuista resursseista ja niiden keskinäisistä riippuvuuksista. Tällainen esikatselu helpottaa valitsemaan oikeat resurssit mukaan generoitavaan CloudFormation-koodiin. Palvelun avulla generoitu koodi voidaan käyttää sellaisenaan tai muuttaa CDK-sovellukseksi.

CloudFormation-koodin generointi olemassa olevista resursseita on erityisen hyödyllinen mikäli infrastruktuurin hallinnointi on aikaisemmin tehty käsin, mutta tahtotila olisi siirtyä käyttämään IaC:tä.

Aiheesta lisää: https://aws.amazon.com/about-aws/whats-new/2024/08/cloudformation-resource-discovery-template-review-iac-generator/

Heikki Ma

Senior Consultant

Kysy konsultilta: Mitä eroa on yksikkö- ja integraatiotestaamisella?

Thu, 19 Sep 2024 06:58:19 GMT

Mitä eroa on yksikkö- ja integraatiotestaamisella?

Yksikkötesteillä testataan jonkin koodin osan toimintaa itsenäisesti. Yhden yksikkötestin tulisi kohdistua laajuudeltaan yksittäisen funktion tai luokan sisäiseen toimintaan. Yksikkötesteissä riippuvuudet sovelluksen muihin osiin, ulkopuolisiin sovelluksiin ja kirjastoihin pyritään minimoimaan. Testattavan yksikön vuorovaikutusta muiden osien kanssa voidaan testata korvaamalla oikea riippuvuuden kohde tynkä- tai sijaistoteutuksella (mock, stub, spy) joiden palauttamia arvoja voidaan kontrolloida ja joihin lähetettyjä kutsuja voidaan tarkastella. Yksikkö testien tulisi testata yksiköiden sisäinen logiikka kattavasti ja niiden tulisi olla helposti muutettavissa, jos logiikkaa joudutaan korjaamaan.

Integraatiotestaus on ohjelmiston osien yhteistoiminnan testaamista. Integraatiotestit voivat rajoittua esimerkiksi yhdellä palvelimella suoritettavan ohjelmiston testaamiseen siten että riippuvuudet palvelimen ulkopuolisiin järjestelmiin korvataan paikallisesti ajettavilla sijaistoteutuksilla tai tuotannossa eri palvelimilla ajettavien järjestelmän osien yhteistoiminnan testaamista siten että osia ajetaan omissa säiliöissään (container) yhdellä koneella. Integraatiotesteillä voidaan tarkoittaa myös usean fyysisesti eri palvelimilla tai jopa eri konesaleissa toimivien järjestelmien yhteistoiminnan testaamista tuotannon kaltaisessa ympäristössä. Perinteisissä konesaleissa ei välttämättä ole käytännöllistä ajaa testejä oikeassa palvelinympäristössä, mutta moderneissa pilviympäristöissä palveluiden käyttöönotto on usein niin nopeaa, että integraatiotestaamiseen voidaan pystyttää puhdas, tuotantoympäristöä vastaava testiympäristö, jossa testejä voidaan ajaa hallitusti siten että testaajalla on täysi hallinta järjestelmän komponenttien versioihin, parametreihin ja tilaan, esimerkiksi tietokantojen ja dokumenttivarastojen sisältöön. Integraatiotesteillä ei välttämättä ole mielekästä testata testattavien komponenttien sisäisen toiminnallisuuden jokaista yksityiskohtaa.

Usein ohjelmistolle kirjoitetaan erilliset yksikkö- ja integraatiotestikokoelmat. Käytännön toteutuksissa yksikkö- ja integraatiotestisettien rajat eivät useinkaan ole yhtä selkeät kuin edellä. Varsinkin yksikkötestien joukossa on usein testejä joilla testataan myös hieman isompia kokonaisuuksia ja esimerkiksi usean eri funktion yhteistoimintaa yhdellä testillä. Integraatiotestit taas saattavat laajimmillaan alkaa muistuttaa end-to-end testejä, joilla nimensä mukaisesti tarkoitetaan koko järjestelmä kokonaisuuden testausta loppukäyttäjältä koko järjestelmän läpi (päästä-päähän).

Markus Nousiainen

Senior Consultant

Webscale TechDays ja AWS Summit - kuin kaksi marjaa?

Tue, 18 Jun 2024 07:15:21 GMT

Toukokuun lopussa, aurinkoisena perjantaina, kokoontui Krapin Pajalle Tuusulaan noin 50 tiedonjanoista IT-alan ammattilaista. Luvassa oli kolmas laatuaan, erinomaista palautetta jo aiemmin saanut, Webscalen järjestämä TechDays. Kovaa ja pragmaattista asiaa pilvestä. Allekirjoittanut sai kunnian toimia tapahtuman juontajana. Juontajan suurin haaste oli houkutella ihmisiä sisätiloihin upeasta auringonpaisteesta useita kertoja päivän aikana.

Kesäkuun alussa, myös aurinkoisessa kelissä, Tukholmaan saapui ympäri Eurooppaa, ja pidemmältäkin, yli satakertainen määrä yhtä tiedonjanoisia pilven kuluttajia, tekijöitä ja muuten sen ympärillä pyöriviä. Kyseessä oli Tukholman AWS Summit. Kaksi webscaleria lensi heti maanantaiaamusta kuuntelemaan Partner Summit osuutta ja tiistaina sitten varsinaiseen päätapahtumaan.

Käytäntöä, hypeä ja GenAI:ta

Vaikka aihepiiri molemmissa olikin ylätasolla sama, niin ero löytyi hypen määrästä. Ja GenAI:sta. Tukholmassa puitteet olivat hulppeat ja äänekkäät, Krapilla kauniit ja rauhalliset. Tukholmassa puhuttiin +80% GenAI:sta, Krapilla enemmänkin siitä mikä mahdollistaa sen, että yrityksen ympäristössä pystytään oikeasti pitkässä juoksussa hyödyntämään GenAI:ta, tai ylipäätään tekemään mitään kehitystä tehokkaasti, oikean suuntaisesti ja tietoturvallisesti. Liikuttiin siis huomattavasti maanläheisemmissä aiheissa hypen sijaan.

Aamupäivän esitykset

TechDaysin agendalla oli kuusi upeaa esitystä. Alkuun AWS:n Antti Kuosmanen kertoi AWS:n avainajatuksista, frugality and innovation , ja miten ne istuvat heidän jokapäiväiseen tekemiseen. Antti on loistava esiintyjä ja huumorilta ei voitu välttyä. Erinomainen ja herättelevä avaus päivään.

Seuraavaksi lauteille astui Webscalen Juho Rautio. Juho on tehnyt pitkään hommia Postilla ja hän kertoikin, miten olemme yhdessä Postin kanssa toteuttaneet niin kutsuttua Standard Infraa. Tällä hetkellä työn alla on jo versio 3.0 ja tavoitteena on saada se syksyllä tuotantoon. Standard infra tukee Postin lukuisia kehittäjätiimejä ja helpottaa tietenkin myös pilven ylläpitoa merkittävästi. Vaikka pakko myöntää, että varsinkin loppuosa esitystä alkoi mennä myyjältä kovaa ja korkealta ohi, niin henkilökohtaisesti pidin tätä mielenkiintoisimpana aiheena. Standardisoinnilla, niin pilven kuin monen muunkin asian, saavutettavat edut ovat todella merkittäviä.

Vielä ennen lounasta kuultiin Webscalen Jukka Ukkosen syväluotaava katsaus aiheesta Data Protection in Sovereign Cloud . Jukka on lähes hypnoottista kuunnella. Ammattitaito ja kiinnostus aiheeseen huokuu koko esityksestä. Vaikka ei ehkä ole se kovin hypetysaihe, niin puhutaan äärimmäisen tärkeistä asioista, jotka jokaisen organisaation pitää ottaa huomioon. Kunkin itselleen sopivalla tasolla tietenkin, mikä olikin yksi esityksen kantavista teemoista. Ratkaisu haasteisiin ei ole automaattisesti kiristää ruuvia äärimmilleen, koska siinä käytännön tekeminen voi häiriintyä pahastikin.

Vauhti kiihtyy iltapäivällä

Iltapäivän avasi Postin Muhammad Hassan. Hänen aiheenaan oli Maximizing AWS Cost Efficiency . Hassan käsitteli aihetta hyvin konkreettisesti ja kertoi käytännönläheisesti Postin tavoista toimia ja toteuttaa FinOpsia. Monet paikalla olleet yritykset kyselivätkin esityksen jälkeen vinkkejä ja ajatuksia omiin ympäristöihinsä.

Seuraavaksi lavalle asteli Thomas Malmberg Mint Securitysta. Aiheena tietoturva. Jos olet pitänyt ko. aihetta tylsänä, pyydä Thomasta puhumaan tapahtumaasi ja muuta käsityksesi. Loistava esitys maustettuna loistavilla visuaaleilla piti yleisön otteeseen alusta loppuun. Esityksessä ei voitu välttää viittauksia Helsingin kaupungin tuoreisiin haasteisiin aiheesta. Samalla myös annettiin työkaluja, miten vastaava voisi välttää omassa yrityksessä.

Päivän virallisen osuuden päätti Webscalen Jussi Lehtiniemi. Jussin aiheena oli pilven maturiteetti ja tyypilliset sudenkuopat, sekä tietenkin miten välttää, tai vähintään mitigoida niitä. Sinänsä aiheessa ei varmasti ole isoa mystiikkaa, mutta me kaikki IT-alalla työtä tekevät tiedämme, että näissä asioissa löytyy isompia ja pienempiä haasteita melkein jokaisesta yrityksestä.

Kiitokset ja yhteenveto

Iso kiitos kaikille esiintyjille! Ja vielä erityiskiitos kaikille osallistujille. Juontajan hommia helpotti huomattavasti erinomaiset kysymykset yleisöstä. Esitysten jälkeen käytiin loistavia keskusteluja aiheista. Nämä keskustelut jatkuivat myös esitysten ulkopuolella, pienemmissä peer to peer ryhmissä. TechDays tarjoaa nimenomaan erinomaisen paikan jutella kollegoiden kanssa, eri yrityksistä, itselle tärkeistä aiheista.

Summa summarum, käytännönläheistä ja konkreettista asiaa pilven käytöstä ja kehittämisestä yrityksessä. Juuri sitä, mitä tarvitaan, jotta prosessit pyörivät, kehitys menee eteenpäin ja asiat toimivat ensi viikollakin. Tervetuloa siis ensi vuonna TechDaysiin kaikki tiedonnälkäiset, jotka haluavat päivittäiseen arkeen vinkkejä! Jos haluat kovaa hypeä ja ison maailman meininkiä, suosittelen AWS Summitteja. Toki mikään ei estä osallistumasta molempiin!

PS. Päivän päätteeksi nautittiin maittava illallinen ja viihteestä vastasi stand up -koomikko Aatu Raitala. Suomen kesäsää säilytti parhaat puolensa ja illallisen jälkeen päästiin nauttimaan kylmiä juomia Krapin kauniissa pihapiirissä. Olipa tänne asti mukaan uskaltautunut muutama asiakaskin webscalereiden lisäksi. Joten varaa ensi vuodeksi kalenteriisi myös iltabileet!

Teemu Kuusisto

Senior Sales Manager

Kysy konsultilta: Terraform vs. CDK

Thu, 23 May 2024 05:44:13 GMT

Terraform vs. CDK

Terraform ja AWS Cloud Development Kit (CDK) ovat molemmat työkaluja, joilla voidaan määrittää infrastruktuuri koodina (Infrastructure as Code, IaC). Molemmilla työkaluilla kuvataan ympäristön haluttu tila ns. deklaratiivisesti ja työkalu pitää huolen, että haluttuun tilaan päästään. Tähän loppuivatkin yhtäläisyydet.

CDK:ssa määritykset kirjoitetaan jollain yleisistä ohjelmointikielistä - esim. TypeScript, Python tai Java - ja käännetään lopulta CloudFormation-koodiksi. Ohjelmointikielen käyttö on usein kehittäjille ennestään tuttua ja se myös mahdollistaa tarvittaessa monimutkaisen logiikan rakentamisen.

Terraformissa puolestaan käytetään HashiCorp Configuration Language:a (HCL), joka ei ole useimmille kehittäjille tuttu ja vaatii pientä opettelua. HCL ei ole varsinainen ohjelmointikieli, mutta se tukee tärkeimpiä rakenteita kuten loopit ja ehtolauseet. Nykyään Terraformin kanssa voi käyttää myös CDK for Terraformia (CDKTF), jossa Terraform-koodi tuotetaan samaan tapaan yleisillä ohjelmointikielillä kuin CDK:ssa CloudFormation-koodi.

Myös ympäristön provisiointi ja tilan hallinta eroavat Terraformin ja CDK:n välillä. Terraformin providerit kutsuvat suoraan rajapintoja (API) ja tallentavat tilan tilatiedostoon, joka yleensä on myös jossain pilvipalvelussa. Terraformiin löytyy providereita lähes kaikkiin pilvipalveluihin sekä monien muidenkin yleisten ohjelmistojen hallintaan.

CDK:ta käytettäessä AWS CloudFormation vastaa resurssien provisioinnista sekä toimii samalla ympäristön tilatietona. Tämän takia CDK sopii käytettäväksi lähinnä vain AWS:n kanssa vaikka CloudFormationin laajennoksilla pystyykin joitain AWS:n ulkopuolisia palveluita hallitsemaan.

Lyhyesti voisi sanoa, että CDK on hyvä valinta, jos käytössä on AWS ja ympäristön - tai koko sovelluksen - rakentaa sovelluskehittäjä. CDK on hyvä valinta myös silloin, jos ympäristö on pääasiassa AWS:ssä tai CloudFormation on ennestään tuttu. Muulloin valitsisin Terraformin tai CDK for Terraformin, koska ne tarjoavat laajemman tuen, nopeammat päivitykset uusille ominaisuuksille sekä suoremman vuorovaikutuksen hallittavan palvelun kanssa.

p.s. HashiCorp muutti Terraformin lisenssiehtoja syksyllä 2023. Tämän seurauksena sen rinnalle on tullut avoimen lähdekoodin lisenssin OpenTofu, joka pyrkii pysymään ominaisuuksiltaan Terraformin tasalla.

Antti Elonheimo

Senior Consultant

Kysy konsultilta: Mitä compiler tarkoittaa?

Fri, 17 May 2024 04:45:17 GMT

Mitä compiler tarkoittaa?

Compiler (suom. kääntäjä) on tietokoneohjelma, jolla käännetään korkeamman tason ohjelmointikielellä (esim. Java / TypeScript) kirjoitettu tietokoneohjelma alemman tason kielelle (assembly, machine code, binääri). Eli sillä muunnetaan ohjelman lähdekoodi ihmisen ymmärtämästä muodosta muotoon, jonka tietokone ymmärtää ja pystyy suorittamaan. Kääntämisprosessiin kuuluu useita vaiheita, kuten sanasyntaksianalyysi, parsinta, semanttinen analyysi, optimointi ja koodin generointi.

Alla lyhyt kuvaus näistä vaiheista:

Sanasyntaksianalyysi: Tässä vaiheessa lähdekoodi jaetaan tokeneihin, kuten avainsanoihin, tunnisteisiin, operaattoreihin ja välimerkkeihin.
Parsinta: Kääntäjä analysoi koodin rakenteen ohjelmointikielen kieliopin sääntöjen mukaisesti. Tämä luo jäsentämispuiden tai abstraktien syntaksipuiden (AST), jotka edustavat koodin rakennetta.
Semanttinen analyysi: Tässä vaiheessa koodi tarkistetaan semanttisesti oikeelliseksi, kuten tyyppivirheet tai määrittelemättömät muuttujat. Se suorittaa myös tyyppipäätelmän ja varmistaa, että koodi noudattaa kielen sääntöjä.
Optimointi: Monet kääntäjät suorittavat erilaisia optimointeja parantaakseen generoidun koodin tehokkuutta, kuten vakioarvot, silmukoiden purkaminen ja kuolleen koodin eliminointi.
Koodin generointi: Viimeiseksi kääntäjä muuntaa koodin konekoodiksi tai tavukoodiksi suoritettavaksi kohdealustalla. Tämä saattaa sisältää korkean tason ohjeiden muuttamisen konekieliseksi tai suoraan konekoodiksi.

Kun käännösvaihe on valmis, tuloksena olevaa suoritettavaa koodia voidaan ajaa kohdealustalla ilman alkuperäistä lähdekoodia tai itse kääntäjää. Tämä tekee kääntäjistä olennaisia työkaluja ohjelmistokehityksessä, koska ne mahdollistavat ohjelmoijille koodin kirjoittamisen helpommin luettavassa ja ylläpidettävässä muodossa saavuttaen silti tehokkaan suorituksen tietokoneella.

Juha Mustajärvi

Full Stack Developer

Kysy konsultilta: Mitkä ovat esitietovaatimukset AWS Cloud Development Kit (CDK) käyttöön?

Mon, 13 May 2024 06:00:00 GMT

Mitkä ovat esitietovaatimukset AWS Cloud Development Kit (CDK) käyttöön?

AWS Cloud Development Kit (CDK) on Infrastructure as Code (IaC) -työkalu, joka mahdollistaa AWS-infrastruktuurin määrittämisen koodina. Koodista syntetisoidaan CloudFormation-template, joka lopulta viedään (deploy) pilviympäristöön. Kaiken voi tehdä CDK CLI -työkalulla ilman, että templatea tarvitsee edes vilkaista, joten vaikka CloudFormation-syntaksin tunteminen voi olla hyödyllistä, se ei ole CDK:n käytössä välttämätöntä.

Jotta CDK:n kanssa pääsee alkuun, tarvitaan siis tietenkin ohjelmointikielen osaamista. CDK tukee useita ohjelmointikieliä: TypeScript, JavaScript, Python, Java, C# ja Go. TypeScript on kuitenkin CDK:n natiivikieli, joten sen käyttö on kaikkein luontevinta. Koska CDK:lla luodaan AWS-infraa, on syytä tuntea vähintään niiden AWS-infraresurssien luonteenpiirteitä, joita ollaan rakentamassa. CDK tarjoaa eri tasoisia rakennuspalikoita (kutsutaan CDK:ssa construct:eiksi) L1, L2 ja L3, joista L3-tasoon kuuluu kaikkein ylemmän tason valmiita AWS-pilviratkaisuja, jotka voivat koostua useista AWS-resursseista toistensa kanssa yhteen konfiguroituina. CDK:lla voi siis luoda L3:n avulla pilviratkaisun tietämättä tarkkaan mitä resursseja pellin alla syntyy ja lopulta päätyy pilveen. Syntyvistä resursseista on kuitenkin hyvä tietää jotakin tietoturvan ja kustannusten hallinnan tähden.

CDK:sta on hyvä tuntea sen keskeisiä käsitteistä ainakin App ja Stack, jotka nekin ovat pohjimmiltaan constructeja. App on sovelluksen ylätason juurielementti, jonka alle kaikki muu rakennetaan. Stack on puolestaan constructi, jota käsitellään aina kokonaisuutena: se viedään pilveen kerralla, se päivitetään ja poistetaan myös kerralla. App voi siis sisältää useita stackeja, mutta koko App:ia ei tarvitse kerralla operoida; yhtä stackia pitää.

Yksi IaC-työkalujen, kuten CDK:n eduista on saada infrastruktuuri versionhallintaan. Näin ollen gitin ja jonkin git-pilviratkaisun, kuten GitHubin tuntemisesta on hyötyä CDK:ta aloittelevalle.

Kokonaisuutena CDK sisältää paljon enemmän konsepteja, kuin mitä tässä ehdimme käsitellä. Kunhan tarkkailet AWS-tilisi kustannuksia ja tietoturvaa, voit lähteä oppimaan CDK:sta lisää kokeilemalla.

Yksi asia vielä - vaikka CloudFormation-syntaksin tunteminen ei ollut CDK:ta käyttääkseen välttämätöntä, tutustuthan silti CloudFormation:iin AWS-konsolissa. Näet sieltä CDK:n pilveen viemät stackit ja infran kunhan olet sillä AWS-regionilla, johon CDK:lla olet infraa vienyt.

Pidä hauskaa CDK:n tutustumisen parissa!

Johan Stenroth

Consultant

Kysy konsultilta: Miten FinOps auttaa pilvikustannuksissa?

Fri, 03 May 2024 04:58:11 GMT

Miten FinOps auttaa pilvikustannuksissa?

FinOps, eli Financial Operations, on toimintamalli ja työskentelykulttuuri, jonka avulla yritykset voivat varmistaa, että ne saavat pilvipalveluista parhaan mahdollisen hyödyn. Keskeisimpiä FinOpsin tavoitteita ovat muun muassa:

Alentaa pilvikustannuksia optimoimalla pilvipalveluiden käyttöä.
Parantaa pilvipalveluiden suorituskykyä ja varmistaa, että ne tukevat liiketoiminnan tarpeita.
Lisätä läpinäkyvyyttä pilvikustannuksiin ja tehdä dataan perustuvia päätöksiä.

FinOpsin onnistuminen edellyttää avointa kommunikaatiota ja yhteistyötä IT-osaston, taloushallinnon ja liiketoiminnan välillä.

FinOps on jatkuva prosessi, joka koostuu kolmesta päävaiheesta:

Inform (Tiedosta)
Kerää tietoa pilvikulutukseesi ja -kustannuksiin liittyvistä tekijöistä.
Analysoi tietoa ja tunnista mahdolliset parannuskohteet.
Optimize (Optimoi)
Määrittele tavoitteet pilvikustannusten hallinnalle ja luo periaatteet pilvipalveluiden käyttöön.
Toteuta muutoksia pilvipalveluiden käyttöön ja resurssien allokointiin.
Operate (Suorita / Hallinnoi)
Seuraa pilvikulutustasi ja varmista, että tavoitteet saavutetaan.
Tee tarvittaessa muutoksia pilvipalveluiden käyttöön ja resurssien allokointiin.

Ps. Olemme käsitelleet FinOpsia myös meidän Pilvipilotit -podcastin tuoreella toisella tuotantokaudella. Vieraana AWS:n Data Champion Nordics, Sr. Solutions Architect Veli-Matti Ojala. Voit ottaa kyseisen jakson kuunteluun tästä.

Heikki Ma

Senior Consultant

Kysy konsultilta: Mikä on AWS Landing Zone? (Miten AWS Control Tower liittyy Landing Zoneen?)

Fri, 26 Apr 2024 05:38:53 GMT

Mikä on AWS Landing Zone? (Miten AWS Control Tower liittyy Landing Zoneen?)

AWS Landing Zone on käsite, joka tarkoittaa hyvin suunniteltua, skaalautuvaa ja turvallista monitiliympäristöä isoille ja myös pienemmille organisaatioille, jotka operoivat useita AWS-tilejä. Landing Zonen rakentamiseen ei ole yhtä oikeaa tapaa vaan yleensä ratkaisu suunnitellaan organisaation tarpeiden mukaan. Yleensä Landing Zoneen kuuluvat vähintään seuraavat osa-alueet:

- Sovellusten ja työkuormien hallinnollinen eriyttäminen (ajoympäristöt)

Yksi AWS-tili / sovellus / ympäristö.
Least privilege -periaatteen noudattaminen tiimeille. Tiimillä on pääsyt vain niille AWS-tileille, joiden kanssa he työskentelevät.

- Tietoturvakontrollien eriyttäminen

Eri tileillä tai tiliryhmillä voi olla erilaiset tietoturvakontrollit, esimerkiksi tuotantotileille voi olla rajatummat oikeudet kun kehitysympäristön tileille.
Tietoturvariskien rajaaminen onnistuu helpoiten tilikohtaisella eriyttämisellä.
AWS-tili on vahvasti eristetty muista AWS-tileistä automaattisesti.

- Tietovarantojen eristäminen

Sensitiivisten tietovarantojen eristäminen omalle AWS-tilille mahdollistaa vahvan kontrollin siihen kuka tietoihin pääsee käsiksi.

- Laskutuksen kohdentaminen

Isossa organisaatiossa AWS-laskutuksen kohdentaminen sovellus- tai ympäristökohtaisesti on tärkeää. Jos sovellus on omalla AWS-tilillään tämä on helpompaa.

AWS Control Tower on AWS:n tarjoama managed service -ratkaisu Landing Zonen rakentamiseen. Control Tower luo AWS:n parhaiden käytäntöjen mukaisen Landing Zone -ympäristön, jossa perusasiat kuten tietoturvakontrollit ovat oletusarvoisesti kunnossa. Control Tower rakentaa monitiliympäristön AWS Organizations -palvelun päälle, joka mahdollistaa tilien jakamisen organisaatioyksikköihin tarpeen mukaan. Tämä mahdollistaa erilaisten policyjen ja AWS-resurssien automaattisen luonnin automaattisesti joko organisaation kaikille tileille tai valinnaisesti organisaatioyksiköille. Control Tower ottaa myös haluttaessa automaattisesti käyttöön muita AWS-organisaatioiden hallintaan käytettäviä tuotteita kuten Single Sign On -kirjautumisen IAM Identity Center -palvelun kautta. Tärkeät tietoturvaan liittyvät lokit ja hälytykset kerätään keskitetysti mm. CloudTrail, Config ja Guard Duty palveluista. Uusien AWS-tilien luonti ja perustason konfigurointi tapahtuu Control Tower Account Factory -toiminnallisuuden kautta. Tämä helpottaa tilien luontia, ja tilien luonti on myös automatisoitavissa Account Factoryn kautta.

Control Towerin käyttöönotto on suositeltavaa heti kun organisaatiolla on käytössään useampi AWS-tili, joita halutaan hallita keskitetysti.

Jussi Lehtiniemi

Senior Cloud Architect

Kysy konsultilta: Mitä on DevSecOps?

Fri, 19 Apr 2024 05:10:50 GMT

Mitä on DevSecOps?

Tietoturvan tulisi olla suuressa roolissa organisaatioissa, koska onnistuneella hyökkäyksellä voi olla tuntuvia vaikutuksia organisaation maineeseen ja toimintaan. On myös hyvä tiedostaa, ettei järjestelmä voi olla kovin laadukas, mikäli tietoturvaa ei ole huomioitu. Tällöin myös tuotantoympäristöön päätyy helposti vakaviakin tietoturvaongelmia. Tästä syystä tietoturvaan tulisi kiinnittää huomiota myös ohjelmistokehitysprosessissa, ja mieluiten mahdollisimman aikaisessa vaiheessa ohjelmistokehitysprosessia, sillä myöhään havaitut tietoturvaongelmat ovat monesti kalliimpia ja työläämpiä korjata sekä ne myös estävät/viivästyttävät julkaisuja.

Termi “DevSecOps” (Development, Security, Operations) tarkoittaa sitä, kun tietoturva tuodaan kokonaisvaltaisesti mukaan DevOps:ia noudattavaan ohjelmistokehitysprosessiin. Ideana on, että tietoturva on yhteinen vastuualue kaikkien ohjelmistokehitysprosessiin liittyvien tahojen kesken. Tämä edellyttää erillisen “security” tiimin siilon rikkomista, sillä erillinen “security” tiimi ei ole enää yksinomaan vastuussa tietoturvasta. DevSecOps ei itsessään tarkoita mitään nimenomaista prosessia, vaan tietoturvan huomioimista prosessin jokaisessa vaiheessa erilaisilla tarkoituksenmukaisilla tavoilla. Se siis on menetelmä ohjelmistokehitysprosessin parantamiseksi tietoturvan näkökulmasta. Käytännössä tämä tarkoittaa erilaisia toimintamalleja, työkaluja ja teknologioita joiden avulla tietoturvaa saadaan parannettua, kuten esimerkiksi estämään tehokkaammin erilaisten tietoturvaongelmien päätymistä tuotantojärjestelmään. Näin päästään tilanteeseen, jossa tietoturvaa aletaan toteuttaa aiemmassa vaiheessa ohjelmistokehitysprosessia verrattuna perinteiseen malliin, jossa tietoturvaan keskittyvä testaus tehdään vasta kehityksen jälkeen.

DevOps:in käytäntöjen mukaisesti tietoturvaan liittyviä tehtäviä pyritään myös automatisoimaan. Esimerkiksi, kun turvallisuustestaus on automatisoitu ja osana CI/CD-putkea, niin erilaisia tietoturvaongelmia, kuten haavoittuvuuksia voidaan huomata aikaisessa vaiheessa prosessia. Lisäksi automatisointi myös estää tehokkaasti ettei tietoturvasta tule pullonkaulaa ja siten aiheuta viivästyksiä julkaisuille.

Yleisiä menetelmiä DevSecOps:in yhteydessä ovat esimerkiksi uhkamallinnus, tietoturvaan liittyvien käytäntöjen ja periaatteiden noudattaminen suunnittelun ja kehityksen yhteydessä, tietoturvaongelmien tunnistaminen ohjelmakoodista automaattisesti staattisen analyysin avulla (SAST), haavoittuvuuksien tunnistaminen järjestelmän riippuvuuksista (SCA), järjestelmän automaattinen turvallisuustestaus (DAST/IAST), arkaluontoisen tiedon skannaus, penetraatiotestaus ja informatiivinen lokitus. DevSecOps:iin liittyy myös jatkuva monitorointi hälytyksineen tietoturvan näkökulmasta, ja lisäksi toimintamalleja liittyen miten erilaisiin tietoturvatapahtumiin reagoidaan.

Eli DevSecOps ohjaa tiimejä suunnittelemaan ja kehittämään järjestelmää tietoturvallisella tavalla. Tietoturvan ei tulisi olla päälleliimattu osa ohjelmistokehitysprosessia, koska siten ei saavuteta kaikkia hyötyjä DevSecOps:ista. Tähän auttaa, että koko organisaatiossa toteutetaan tietoturvaa suunnitelmallisesti, jatkuvasti ja kokonaisvaltaisesti luoden ja parantaen organisaation sisäistä kulttuuria tietoturvaan liittyen. Tämä käsittää myös sen, että itse DevSecOps:ia noudattavaa ohelmistokehitysprosessia sekä käytettäviä menetelmiä parannetaan jatkuvasti. Näin päästään tilanteeseen, jossa kaikki ohjelmistokehitysprosessin osalliset tahot ovat paremmin tietoisia erilaisista tietoturvaan liittyvistä asioista. Ja ennen kaikkea he pystyvät toteuttamaan tietoturvaa entistäkin paremmin ottaen myös huomioon organisaation ja eri järjestelmien tarpeet ja vaatimukset.

Jukka Ukkonen

Senior Consultant

Kysy konsultilta: Mikä on Serverless Framework?

Fri, 12 Apr 2024 07:17:24 GMT

Mikä on Serverless Framework?

Serverless Framework on nimensä mukaisesti ohjelmistokehys palvelittomien sovellusten kehittämiseen, joka kehitettiin alunperin AWS Lambdaa varten sen mullistaessa palvelittoman arkkitehtuurin suosion. Nykyään ohjelmistokehyksellä voidaan kehittää palvelittomia sovelluksia AWS:n lisäksin myös usealla muulla pilvialustalla tunnetuimpina esimerkiksi Google Cloud Platform ja Microsoft Azure.

Serverless Framework helpottaa ohjelmistokehittäjän työtä tarjoamalla helposti lähestyttävän konfiguraatiotiedoston YAML-syntaksilla minkä avulla voidaan määrittää lukuisia infraresursseja kuten AWS Lambda -funktiot ja niiden tarvitsemat tapahtumalähteet. Konfiguraatiotiedosto tukee myös CloudFormation-syntaksia, mikä mahdollistaa käytännössä melkein minkä tahansa AWS-resurssin luomisen. Helposti määriteltävien resurssien avulla kehittäjä pystyy keskittymään paremmin sovelluslogiikkaan ja koodiin.

Serverless Framework mahdollistaa siis sovelluksen kokonaisvaltaisen kehityksen sisältäen sovelluskoodin ja infran. Lisäksi se tarjoaa työkalut molempien samanaikaiseen julkaisuun. Serverless Framework soveltuu erinomaisesti mikropalveluarkkitehtuuriin, mutta sitä voidaan käyttää myös isommissa projekteissa. Huonona puolena mainittakoon mahdolliset haasteet lokaalissa kehittämisessä ja testauksessa, mitkä saattavat olla haastavia pilviresurssien riippuvuuksien takia. Nykyään siihenkin ongelmaan löytyy kuitenkin usein valmiita liitännäisiä.

Mika Catani

Cloud Solutions Consultant

Kysy konsultilta: Mitä tarkoittaa kuluoptimointi pilviympäristössä?

Fri, 05 Apr 2024 04:41:17 GMT

Mitä tarkoittaa kuluoptimointi pilviympäristössä?

Tarpeettoman korkeat ja hallitsemattomasti kasvavat pilvikulut ovat toistuva ongelma eri ympäristöissä. Eri palveluntarjoajat (Amazon Web Services, Azure, Google Cloud Platform) tarjoavat pääsääntöisesti tietoja läpinäkyvästi siitä, mitä asiat maksavat. Hankalaksi kulujen seuraamisesta tekee niiden jyvittyminen lukuisiin pienempiin menoeriin, ja mahdolliset palveluiden liitännäiskulut jotka eivät näy yksittäisen palvelun hintalapulla.

Pääsääntöisesti pilviresurssien pystyttäjä ei ole sama henkilö, joka maksaa ympäristön kulut. Yksittäisen tekijän insentiivinä valitettavan harvoin on miettiä perustettavista resursseista syntyviä välittömiä ja välillisiä kuluja, silloin kun tavaraa on tarkoitus saada kovaan ajoon. Eikä tekijällä välttämättä ole kokemusta ympäristön kulutuksen arvioinnista.

Muutamia yleisiä ongelmia:

- Pilviresursseja pystytetään, mutta tarpeettomia resursseja ei poisteta. Vanhaa tavaraa jää olemaan, ja ilmaan jää leijumaan epävarmuus siitä mitkä niistä ovat enää välttämättömiä.

- Pilvialustan palveluita ei käytetä tavalla joka on kustannustehokasta ja keskitettyä. Joitakin resursseja provisioidaan tarpeettoman monta kertaa, vaikka vähemmälläkin pärjäisi oikein hyvin.

- Ongelmien lyhytnäköinen ratkominen. Ongelmat korjataan liian usein nopeasti, ei kunnolla.

Pilviympäristöä tulisi aina miettiä kokonaisuutena, jossa on hyödynnetty mahdollisuudet keskitettyjen palveluiden (esimerkiksi verkkoarkitehtuuri, sovelluksien yhteiset palvelut) käytössä turhien resurssien perustamisen estämiseksi. Hyvin mietitty ja suunniteltu alustakokonaisuus torjuu useimpia yllättäviin kuluihin liittyviä ongelmia. Suunnittelun huomiointi mahdollisimman aikaisessa vaiheessa vähentää kitkaa muutoksiin myöhemmin ja johtaa edullisempiin pilvikuluihin koko elinkaaren aikana. Orgaanisesti ilman riittävää koordinointia ja suunnitelmallisuutta syntyvä ympäristö taas ei.

Mitä keinoja meillä on kulujen pitämiseen kurissa?

- Pilvialustan budjettirajojen käyttö. Tyypillistä on, että käyttö ja kustannukset lisääntyvät käsi kädessä, mutta rajojen ylittämisen tulee herättää hieman pohdintaa siitä, onko kasvu ollut tarkoituksenmukaista.

- Kulutuspoikkeaminen tunnustaminen automaattisilla työkaluilla ja silmämääräisesti. Säännöllinen seuranta ja pelkästään jo silmämääräisellä arvioinnilla on mahdollista tunnistaa tarpeettomia menoeriä.

- Hyvien tag -käytäntöjen luominen. Tagien käyttäminen ympäristön resurssien luokitteluun ja seurantaan mahdollistaa tehokkaampaa kuluerottelua ja auttaa hallinnassa.

- Ympäristöjen hallittu ja suunniteltu perustaminen. Tarkoituksenmukainen ympäristöjen käyttö ja perustaminen säästää kustannuksia pitkällä aikavälillä ja auttaa karsimaan tarpeettomien resurssien syntymistä.

- Vanhentuneiden resurssien ottaminen pois käytöstä ja siivoaminen aktiivisesti. Tontti on helpompi pitää siistissä hallinnassa, kun siellä on vähemmän tavaraa.

- Säästöohjelmien käyttö missä mahdollista.

- Jatkuva kulujen muutoksen seuranta mahdollistaa ongelmien tunnistamisen aikaisessa vaiheessa.

Osaavan silmäparin ja kumppanin hyödyntäminen ympäristön pitkäjänteisessä suunnittelussa vähentää tarpeettomia kuluja kaikkien vuosien aikana, joina ympäristö on käytössä. Vähänkään isommissa ympäristöissä pienikin määrä työtä voi säästää jopa tuhansia euroja kuukaudessa.

Teemu Ala-Järvenpää

Cloud Specialist

Kysy konsultilta: Miten AWS Step Functions liittyy AWS Lambdaan?

Fri, 22 Mar 2024 05:56:41 GMT

Miten AWS Step Functions liittyy AWS Lambdaan?

AWS Step Functions tarjoaa visuaalisen työkalun hajautettujen järjestelmien integrointiin ja työnkulun orkestrointiin. Step Functions helpottaa löyhästi kytkettyjen järjestelmien toteuttamista tarjoamalla havainnollisen tavan sovittaa järjestelmät luotettavasti toisiinsa. Esimerkiksi viestin tuottajan ja kuluttajan ei tarvitse tuntea toisiansa eikä toistensa rajapintoja. Step Functions voi muokata viestin rakennetta ja huolehtia viestin luotettavasta perillemenosta suorittamalla virhetilanteissa mahdolliset uudelleenyritykset ja vaihtoehtoiset toiminnot.

Step Functions perustuu tilakonemalliin, jossa tiloihin voi liittyä tehtävien suorittamista, syötteen prosessointia sekä tilasiirtymälogiikkaa. Nämä kuvataan sisäisesti Amazon States Language -kuvauskielellä, joka on voidaan esittää JSON- tai YAML-formaatissa. AWS-konsolissa tilakone esitetään interaktiivisesti muokattavana tilakaaviona. Tilakoneen suorituksen etenemistä voi myös seurata suoraan tilakaaviosta ja historiasta voi hakea aiempia suorituksia tarkasteltavaksi.

Tilakonemalli tukee tehtävien peräkkäistä ja rinnakkaista suoritusta sekä ehdollista haarautumista ja tehtävien ajastusta. Virhetilanteiden toimintalogiikka voidaan määrittää jokaiseen tilaan yksilöllisesti.

AWS Lambda -funktio on hyvin yleisesti käytetty tilakoneen tehtävätyyppi. Lambda-funktiolla voidaan toteuttaa kevyesti pieniä operaatioita, jotka käsittelevät tehtävän syötettä ja esimerkiksi kutsuvat integraatioon liittyviä rajapintoja. Lambda-funktiota kannattaa kuitenkin käyttää vain silloin kun tilakoneen kuvauskielen ilmaisuvoima ei riitä tarvittavan käyttäytymisen toteuttamiseen.

Lauri Siponen

Cloud Architect

Kysy konsultilta: Mitä tarkoittaa uudelleenkäytettävät CI/CD pipelinet/jobit?

Fri, 15 Mar 2024 06:12:11 GMT

Mitä tarkoittaa uudelleenkäytettävät CI/CD pipelinet/jobit?

CI/CD (continous integration/continous deployment) on menetelmä, jossa järjestelmän muutokset integroidaan ja julkaistaan automaattisesti. Tyypillisesti julkaisuprosessi koostuu muutosten testaamisesta ja katselmoinnista, sekä uuden version julkaisemisesta. CI/CD menetelmässä nämä vaiheet pyritään automatisoimaan mahdollisimman pitkälle, ja järjestelmästä riippuen tämä voidaan saavuttaa esimerkiksi uudelleenkäytettävillä julkaisuputkilla (pipeline) tai tehtävillä (job).

CI/CD menetelmän voi toteuttaa mm. tarkoitukseen rakennetulla järjestelmällä, kuten Jenkinsillä tai se voi olla osa versionhallintajärjestelmää, kuten GitHubissa. Yksinkertaisimmillaan julkaisuputki toteutetaan projektikohtaisesti, jolloin se toimii vain kyseisen projektin julkaisua varten. Tämä lähestymistapa voi olla riittävä, mutta projektikohtaisen lähestymistavan sijaan uudelleenkäytettävät julkaisuputket ja tehtävät tarjoavat tehokkaamman tavan automatisoida julkaisuprosessi.

Uudelleenkäytettävien julkaisuputkien/tehtävien hyötyjä ovat mm. testattavuus, yhdenmukaisuus ja ylläpidon helppous. Testien avulla huolehditaan julkaisuputken odotetunlaisesta toiminnasta ja ne toimivat osaltaan julkaisuputken dokumentaationa. Yhdenmukaisuuden avulla voidaan soveltaa yhdessä sovittuja parhaita käytäntöjä kaikkiin organisaation projekteihin. Julkaisuputken ylläpito helpottuu, kun päivitykset ja korjaukset voidaan toteuttaa keskitetysti. Parhaimmillaan CI/CD järjestelmä tarjoaa valmiita julkaisuputkia/tehtäviä, joiden myötä ylläpitovastuuta ja testausta voidaan ulkoistaa. Esimerkiksi GitHub tarjoaa markkinapaikan , jossa kehittäjät voivat julkaista omia uudelleenkäytettäviä tehtäviä. Hyvä esimerkki uudelleenkäytettävästä tehtävästä on GitHub:n Checkout-action , jonka avulla kehittäjä pystyy lataamaan projektinsa lähdekoodin git-varastosta.

Järjestelmästä ja projektista riippumatta uudelleenkäytettävien julkaisuputkien ja tehtävien merkitystä on vaikea ylikorostaa. Niitä hyödyntämällä voidaan vapauttaa kehittäjien aikaa julkaisuprosessin ylläpitämisestä ja kohdistaa se projektin kehittämiseen. Kannattaa tutustua omassa projektissa tapahtuviin prosesseihin ja pohtia, voisiko niistä tehdä automaattisia tai jopa uudelleenkäytettäviä julkaisuputkia ja tehtäviä.

Janne Lavila

Fullstack Developer

Kysy konsultilta: Mitä tarkoittaa NoSQL?

Fri, 08 Mar 2024 06:06:09 GMT

Mitä tarkoittaa NoSQL?

NoSQL

SQL (Structured Query Language) on deklaratiivinen, standardoitu kyselykieli tietokantadatan käsittelyyn. NoSQL-termin merkitys on epämääräisempi. Se voi tarkoittaa ettei tietokanta tue SQL:ää ollenkaan (No SQL) - tai se voi tarkoittaa, ettei SQL-tuki ole ainoa tietokannan käytettävissä oleva kyselykieli (Not only SQL). NoSQL-kannat yleistyivät 2000-luvun ensimmäisen vuosikymmenen lopulla, jolloin tiedon varastoinnin hinnat laskivat voimakkaasti.

NoSQL-kantojen ominaisuudet vaihtelevat, mutta yleisominaisuutena SQL-kannoista poiketen, NoSQL-kannat varastoivat dataa tyypillisesti kuitenkin muuten kuin taulukkomaisessa muodossa.

NoSQL-kannat ovat nopeita, joustavaskeemaisia, horisontaalisesti hyvin skaalautuvia, ja ne voivat parhaimmillaan olla kehittäjille paljon helpompia käyttää kuin tauluihin perustuvat SQL-kannat. Esimerkiksi key-value -kannat (yksi NoSQL-kantojen päätyypeistä) tarjoavat helposti lähestyttävän kantaratkaisun.

CAP-teoreeman (Consistency, Availability, Partition tolerance) näkökulmasta useat NoSQL-kannat joustavat eheydessä (engl. consistency) samalla saatavutta (engl. availability) priorisoiden.

Sopivia käyttötapauksia NoSQL-kannoille ovat esimerkiksi:

Sovellukset, joissa käsitellään valtavia datamääriä
Mikropalveluarkkitehtuuria noudattavat sovellukset ja datastriimaus
Prototyyppien ja Proof of Concept (POC) -sovellusten nopea rakentaminen

DB-engines -sivuston mittausten mukaan (tarkistettu tammikuussa 2024) maailman suosituimpia NoSQL-tietokantoja olivat MongoDB, Redis ja Elasticsearch. Kaikista tietokannoista suosituin NoSQL-kanta oli MongoDB viidennellä sijalla neljän perinteisen SQL-relaatiokanna jälkeen.

Väärinkäsityksiä

Yleinen väärinkäsitys on, että relaatiodata sopii aina parhaimmin juuri relaatiokantaan. Sopivimman tietokannan valintaperusteisiin vaikuttaa useampi tekijä. Monet NoSQL-kannat tukevat relaatioita; ne vain tekevät sen eri tavoin, eikä dataa tarvitse hajauttaa eri tauluihin. Esimerkiksi JSON-muotoiseen dokumenttidatamalliin perustuvissa NoSQL-tietokannoissa relaatioita voidaan sisällyttää dataan sisäkkäisyyksien avulla.

Moni NoSQL-tietokanta tukee myös ACID-transaktioita, vaikka helposti ajatellaan ettei ominaisuus ole NoSQL-kannoissa saatavilla. ACID-transaktiotuki on saatavilla esimerkiksi AWS DynamoDB- ja MongoDB -kannoissa.

NoSQL-taulujen päätyyppejä

NoSQL-tietokantojen voidaan sanoa vakiintuneen neljäksi päätyypiksi.

1) Dokumenttikantoihin, joihin talletetaan dokumenttityyppisiä tietueita, kuten JSON-rakenne. Esimerkiksi AWS DynamoDB ja MongoDB tukevat dokumenttidatamallia.

2) Key-value -kantoihin, joissa tietueet nimensä mukaisesti ovat avain-arvo -pareja. Esimerkiksi Redis ja AWS DynamoDB ovat avain-arvo -kantoja.

3) Wide-Column -kantoihin, joissa dataa varastoidaan taulukoihin, riveihin ja dynaamisiin sarakkeisiin. Apache Cassandra ja sen kanssa yhteensopiva AWS Keyspaces ovat Wide-Column -tietokantoja.

4) sekä Graafikantoihin, jotka sopivat vahvasti verkottuneelle datalle, jossa varastoidaan sekä yhtymäkohtia (engl. node), että niiden välisiä kaaria (engl. edge). Kaaret voivat sisältää tietoa yhtymäkohtien välisistä suhteista, kuten ihmisten välisistä sukulaissuhteista tai kaupunkien välisistä kulkuyhteyksistä. Neo4j ja Amazon Neptune ovat esimerkkejä graafikannoista.

Johan Stenroth

Consultant

Kysy konsultilta: Kannattaako AWS:ssä käyttää "encryption at rest" -asetusta ja miksi?

Mon, 26 Feb 2024 09:10:49 GMT

Kannattaako AWS:ssä käyttää "encryption at rest" -asetusta ja miksi?

"Encryption at rest" -asetus liittyy datan salaamiseen levossa. Levossa oleva data tarkoittaa esimerkiksi tietokantaan tai kiintolevylle tallennettua dataa, jota ei käytetä aktiivisesti. Datan salaaminen itsessään tarkoittaa selkokielisen datan muuttamista salattuun muotoon (salatekstiksi) salausavainta ja -algoritmia käyttäen. Datan pystyy muuttamaan tästä salatusta muodosta takaisin selkokieliseen muotoon (eli purkamaan salauksen) vain salausavaimella.

Datan salaaminen levossa on yleinen tietoturvaan liittyvä vaatimus etenkin arkaluonteiselle datalle, koska levossa(kaan) oleva data ei ole turvassa. Hyökkääjä voi päästä käsiksi levossa olevaan dataan esimerkiksi pääsemällä käsiksi palvelimen kiintolevyyn ja sitä kautta sen sisältämään dataan. Hyökkääjän on paljon vaikeampi saada selkokielistä dataa, kun data on salattu kiintolevyllä. Myös eri vaatimukset esimerkiksi GDPR ja PCI DSS edellyttävät arkaluonteisen datan salaamista levossa. Tietoturvan kokonaisuuden kannalta käytössä tulisi olla myös muita suojausmenetelmiä kuin pelkästään datan salaaminen.

Monet AWS-palvelut salaavat dataa levossa joko oletusarvoisesti tai erillisten konfiguraatioiden avulla. Tällaisia palveluja ovat esimerkiksi RDS, DynamoDB, S3, EBS, EFS ja CloudWatch.

Salausavainten hallinta on myös suuressa roolissa datan salauksen kanssa. Salausavainten hallinnassa tulee ottaa huomioon esimerkiksi avainten säilytys, elinkaari/rotatointi ja salausavaimiin liittyvä käyttöoikeuksien hallinta. Tähän myös liittyy vahvasti identiteetin- ja pääsynhallinta (IAM), sillä käyttöoikeuksia esimerkiksi dataan ja salausavaimiin liittyen on hyvä hallita roolien avulla ja käyttöoikeuksien tulisi olla tarkasti rajattuja. Käyttöoikeuksiin liittyen on hyvä käytäntö, että roolilla olisi niin vähän käyttöoikeuksia kuin mahdollista ja niiden tulisi olla voimassa mahdollisimman lyhyt aika. AWS tarjoaa KMS (Key Management Service) ja CloudHSM -palvelut, joita voidaan käyttää avainten hallintaan. Lisäksi AWS IAM-palvelua käytetään identiteetin- ja pääsynhallintaan.

Näihin syihin perustuen suosittelen käyttämään "encryption at rest" -asetusta.

Jukka Ukkonen

Senior Consultant

Kysy konsultilta: Miten ja missä Terraformia voidaan hyödyntää?

Fri, 09 Feb 2024 07:42:22 GMT

Miten ja missä Terraformia voidaan hyödyntää?

HashiCorpin Terraform on työkalu pilvi-infrastruktuurin määrittelemiseen. Terraform tukee useamman pilvialustan konfigurointia, valmiit työkalut tukevat laajalti ainakin AWS-, Azure ja GCP-resursseja ja periaatteessa näitä voi myös laajentaa omiin tarpeisiinsa, koska Terraform on julkaistu avoimena lähdekoodina rajatummalla Business Source Lisenssillä.

Terraformin resurssit kuvataan yksinkertaisena koodina deklaratiivisesti, eli määritellään mikä on haluttu tavoitetila resursseille. Ajettaessa Terraform luo ja päivittää olemassa olevat resurssit vastaamaan tätä annettua tavoitetilaa.

Terraform ja pilvialustaspesifiset vastaavat työkalut kuten AWS:n CloudFormation ovat kriittisiä työkaluja siihen, että pilvi-infrastruktuuri voidaan määritellä versioituina dokumentteina, joiden perusteella infrastruktuurista tulee hyvin määriteltyä, monistettavaa ja automatisoitavaa. Lähtökohtaisesti ajattelen, että mitään tuotannossa ajettavaa pilvi-infraa ei pitäisi tehdä ilman näitä Infra as Code (IaC) -työkaluja.

Terraform mahdollistaa myös organisaation käyttämien omien moduulien rakentamisen, jolloin organisaation kaikki tiimit voivat käyttää samalla tavalla rakennettua pilvi-infraa eikä kehitystiimien tarvitse jokaisen tehdä omaa ympäristöään. Moduulien myötä voidaan myös viedä keskitetysti uusia päivityksiä infraan ilman, että tiimien tarvitsee erikseen muuttaa mitään omassa konfiguraatiossaan.

Terraform puolustaa paikkaansa tilanteissa, joissa halutaan hallita useammassa pilvessä ajattavia palvelinympäristöjä. Se on aiemmin myös osoittautunut saavan hieman nopeammin uusia ominaisuuksia tiettyjen uusien palveluiden osalta kuin vaikka CloudFormation. Kääntöpuolena CloudFormationin kanssa AWS tarjoaa paljon palveluita, jotka tukevat CloudFormationin käyttöä ja sen tilan ylläpitoa. Terraformilla olevilla resursseilla ei ole AWS-pilvessä myöskään samanlaista stack-ryhmittelyä kuin CloudFormationilla luoduilla resursseilla.

Kaikissa näissä työkaluissa tulee vielä organisaatiotasolla käytettäessä vastaan se, että niiden lisäksi on tarpeen käyttää vielä uusia työkaluja, jotka mahdollistavat lukuisten tilien hallinnan ja kaikille tileille näiden resurssien luomisen keskitetysti. Nämä työkalut tuntuu olevan rakennettu tukemaan vain yhtä IAAS-työkalua kukin. Terraformille on ainakin TerraGrunt, CloudFormationille Sceptre ja vaikkapa Takomo.

Kaikkiaan nykyisessä pilvi-infran kehitysvaiheessa organisaatioiden pitäisi lähtökohtaisesti rakentaa kaikki infransa jollakin IaC-työkalulla, ja vain pääkäyttäjätunnusten luomisen ja 2FA-avainten hallinnan pitäisi olla manuaalinen prosessi. On hyödyllistä tarjota kehittäjille hiekkalaatikkoympäristöt, joissa pääsee kokeilemaan uusia palveluita ja tapoja käyttää resursseja, mutta kaikki hiekkalaatikkotilien ulkopuolella pitäisi rakentaa versionhallinnassa tallennettuina resurssitemplateina Terraformin kaltaisilla työkaluilla.

Ilman näitä työkaluja on nimittäin ylläpitäjillä edessä lukuisia päiviä hiusten repimistä, kun yritetään jäljittää jonkun aikaisemmin tekemiä manuaalisia muutoksia, ja ymmärtää miten ne liittyvät yhteen. Alkuun pääsy voi tuntua työläältä, mutta siinä jää voitolle työajan käytössä kun alun alkaen hyödyntää asiantuntijoiden osaamista.

Jukka Dahlbom

Head Of Data Engineering

Kysy konsultilta: Mihin tarvitaan VPC:tä?

Fri, 02 Feb 2024 06:47:13 GMT

Mihin tarvitaan VPC:tä?

VPC tulee sanoista Virtual Private Cloud. Se on virtuaalinen, loogisesti eristetty pilviympäristön verkko. Amazonilla komponenttia sanotaan Amazon VPC:ksi - Microsoftin Azure-pilviympäristön vastaavaa verkkoresurssi on puolestaan Azure Virtual Network (VNet).

AWS VPC:t luodaan aina tietylle regionille, esimerkiksi Tukholman eu-north-1:lle. Samalla VPC:lle valitaan IP-osoiteavaruus, jota edelleen allokoidaan VPC:n sisäisille aliverkoille (engl. subnet). Aliverkon reititysasetukset määrittävät aliverkon tyypin. Esimerkiksi aliverkon sanotaan olevan julkinen, mikäli sillä on suora reititys Internet Gateway -verkkokomponentille.

VPC:n aliverkkoihin voidaan asentaa verkkoliikennettä käyttäviä pilviresursseja, kuten Amazon Elastic Compute Cloud (EC2), Amazon Relational Database Service (RDS) tai AWS Lambda -funktio. Resurssien verkkoliikennöintimahdollisuudet on näin ollen tarkoituksella rajoitettu aliverkon ja siihen kytkettyjen verkkokomponenttien ominaisuuksiin.

Tyypillinen VPC:n käyttöesimerkkitapaus on web-palvelin (esim. EC2), jonka halutaan pystyvän olemaan yhteydessä julkiseen internetiin sekä tietokantapalvelimeen (esim. RDS). Samaan aikaan kun tietokantapalvelimen tulee pystyä keskustelemaan web-palvelimelle, tietokantapalvelin ei tietoturvasyistä saa näkyä julkisessa internetissä. Tämä voidaan ratkaista VPC:n sisäisten julkisen ja yksityisen aliverkon ja niiden välisten reititysten avulla. Web-palvelin on julkisessa aliverkossa ja tietokantapalvelin yksityisessä aliverkossa. Molempien aliverkkojen reititystaulut rajoittavat ja sallivat niiden sisäistä verkkoliikennettä ja mahdollistavat tietoturvallisen verkkoratkaisun.

VPC:n ja sen aliverkkojen yhteyksiä ja ominaisuuksia voidaan muokata myös useilla muilla verkkokomponenteilla käyttötarpeen mukaan. Komponenttien hinnoittelut ja kapasiteetit vaihtelevat, joten sopivimman ratkaisun saamiseksi Amazon VPC:n tunteminen on suureksi hyödyksi.

Johan Stenroth

Consultant

Tyytyväiset työntekijät avaintekijänä menestyksessä - Webscalen työtyytyväisyyskyselyn tulokset

Mon, 29 Jan 2024 08:52:58 GMT

Vuoden 2023 loppupuolella teetimme henkilöstölle vuosittaisen työtyytyväisyyskyselyn. Kyselyn lopussa pyysimme vastaajia arvioimaan asteikolla 0-10 (0 = erittäin epätodennäköisesti ja 10 = erittäin todennäköisesti) kuinka todennäköisesti he suosittelisivat Webscalea työpaikkana. Tämän kysymyksen pohjalta Webscalen suositteluindeksiksi eli eNPS-luvuksi omilta työntekijöiltämme tuli todella komea 88. Vuonna 2022 vastaava eNPS luku oli 76, joten vuoden aikana on tapahtunut hieno nousu jo ennestään hyvästä luvusta.

Tämä on vahva osoitus siitä, että Webscalessa tehdään oikeita asioita työhyvinvoinnin eteen. Samalla se heijastaa hyvin työyhteisömme vahvaa yhteenkuuluvuuden tunnetta ja henkilöstön tyytyväisyyttä.

Webscalereiden kommentteja

Käydään seuraavaksi Webscalen työntekijöiden, eli tuttavallisemmin webscalereiden, antamia anonyymejä kommentteja läpi, miksi he vahvasti suosittelevat Webscalea työnantajana sekä erityisesti ajatuksia erinomaisen tuloksen taustalla.

“Pidän siitä miten Webscalessa tehdään töitä, työkaverit on todella hyviä.”

“Webscale on hyvä työpaikka. Työkaverit on kovia ammattilaisia ja projektit pääsääntöisesti mielekkäitä.”

“Webscale on työpaikkana hyvin johdettu ja erittäin läpinäkyvä. Työtehtävät ovat haastavia ja mielenkiintoisia.”

“Työntekijöille annetaan tarpeeksi vapautta käyttää haluttuja teknologioita ja vastuuta projekteissa.”

“Työntekijöiden hyvinvoinnista huolehditaan ja yhteistä tekemistä järjestetään myös työn ulkopuolella.”

Yhteensä saimme kyselyyn 25 vastausta 30:stä. Edellä mainitut kommentit ovat tietenkin Webcalelle ylpeyden aihe, jotka eivät varmasti ole sattumaa, vaan pitkäjänteisen työn tulos. Pyrin avaamaan seuraavassa osiossa asioita, jotka ovat erinomaisen työtyytyväisyyden taustalla.

Työtyytyväisyyden ylläpitäminen on jatkuvaa työtä

Webscalen historia on tätä kirjoitettaessa reilun 10 vuoden mittainen. Kolmen devaajan perustamasta yrityksestä on tullut yli 30 henkeä työllistävä konsultointiyritys. Kantavana teemana koko historian ajan on ollut tehdä kannattavaa kasvua samalla huolehtien henkilöstön työtyytyväisyydestä. Yrityksen toiminta on aina perustunut tulorahoitukseen. Esimerkiksi rekrytointien osalta ollaan oltu hyvin tarkkoja sen suhteen, että uusille työntekijöille varmasti riittää töitä myös pidemmällä aikavälillä. Tämä on mahdollistanut sen, että muun muassa konsulttimme ovat hyvin työllistettyjä ja mahdollinen “penkkiaika”, eli projektien välinen aika, on ollut mahdollisimman pieni. Myös projektien laatuun kiinnitetään huomiota. Pyrimme huomioimaan työntekijöidemme toiveet työnkuvan osalta ja ennen kaikkea sen, että ne mahdollisimman hyvin vastaavat heidän vahvinta ydinosaamistaan. Useammissa vastauksissa nouseekin esiin esimerkiksi projektien mielekkyys, unohtamatta ympäristöä, jossa pääsee haastamaan itseään ja kehittymään.

Yrityksen kasvaessa on myös hallinnollista puolta vahvistettu merkittävästi, erityisesti parin viime vuoden aikana. Tämä tuo lisää “muskeleita” kasvun mahdollistamiseen jatkossakin ja myös siihen, että haastavassa markkinatilanteessa olemme pystyneet takamaan töiden riittävyyden jo olemassa olevalle henkilöstölle. Vaikka vuosien aikana hallintoa on vahvistettu ja henkilöstömäärä on kasvanut vauhdilla, on matala organisaatiohierarkia säilynyt. Työtyyväisyyskyselyssä webscalerit mainitsevat useasti rennon työilmapiirin ilman turhaa “pönötystä” sekä läpinäkyvän ja avoimen kulttuurin yhtenä suurimpana positiivisena asiana Webscalessa työskentelyssä.

Varmasti kaikki tiedostavat sen, että oman työnkuvan mielekkyys ja palkkaus ovat tärkeiden asioiden joukossa, jotta työssä viihdytään. Ei kuitenkaan tule vähätellä esimerkiksi työkavereiden ja työsuhde-etujen merkitystä tässä kokonaisuudessa. Mukavat kollegat ovatkin edellä mainitun avoimen ja rennon ilmapiirin ohella kenties se kaikkein eniten esiin nouseva asia, kun kysytään webscalereilta, miksi he viihtyvät niin hyvin. Tämä ei ole vain sanahelinää, vaan näkyy konkreettisesti siinä, että vietämme töiden ulkopuolella aikaa yhdessä muun muassa erilaisten afterwork -tapahtumien tai kerhotoiminnan muodossa. Vastauksissa myös tämä mahdollisuus nousi usein esiin positiivisena asiana. Tämän osalta suuri kiitos kuuluu toimistopäälliköllemme Sara Peltolalle, joka on pääosin vastuussa eri afterwork -tapahtumien ja vastaavien järjestämisestä, huomioiden toki mahdolliset toiveet. Sara kirjoittikin hyvän blogin yhteisöllisyydestämme, jonka voit lukea tästä.

Kaiken kaikkiaan tästä on hyvä jatkaa työtyytyväisyyden kehittämistä edelleen. Henkilöstö on Webscalen tärkein voimavara ja käymme aktiivista vuoropuhelua henkilöstömme kanssa siitä, mitä voisimme tehdä paremmin ja kuuntelemme heidän toiveitaan tarkalla korvalla.

Töihin Webscaleen?

Me Webscalella uskomme, että työ on palkitsevaa silloin, kun sen tekijällä on sopivasti vastuuta ja vapautta. Mottomme on “parhaat keskittyvät olennaiseen” ja meille se tarkoittaa sitä, että asiantuntijamme ovat parhaimmillaan, kun saavat käyttää aikaansa heille merkityksellisiin tehtäviin. Asiakkaat saavat meiltä laadukasta palvelua ja, mikä tärkeintä, koemme tiiminä onnistumisia ja opimme yhdessä.

Kiinnostaisiko sinua liittyä tiimiimme? Lue lisää rekrysivuiltamme . Kuulemme mielellämme tarinasi ja otamme selvää, olisimmeko me sinulle oikea työnantaja.

Juho Sopanen

Talent Acquisition Specialist

Kysy konsultilta: Mikä MFA on ja miksi sitä pitäisi käyttää?

Fri, 26 Jan 2024 05:59:25 GMT

Mikä MFA on ja miksi sitä pitäisi käyttää?

Multi-factor authentication (MFA) eli monivaiheinen tunnistautuminen parantaa merkittävästi verkkopalveluiden käyttäjien identiteettisuojaa verrattuna perinteiseen pelkällä käyttäjätunnuksella ja salasanalla tunnistautumiseen. Identiteettivarkaudessa verkkorikolliset voivat saada uhrin käyttäjätunnuksen ja salasanan haltuunsa esimerkiksi arvaamalla (sähköpostiosoite käyttäjätunnuksena), tietojenkalastelulla, sanakirjahyökkäyksellä tai kryptografisella murtamisella. Murtoyrityksen onnistumista edesauttaa lyhyt tai yksinkertainen salasana. Haitan laajuutta voi lisätä saman salasanan käyttäminen monessa palvelussa. Kun monivaiheinen tunnistautumista on käytössä, pelkällä käyttäjätunnuksella ja salasanalla ei vielä pääse kirjautumaan kohdejärjestelmään sisään. Lisätunnistautumismenetelmänä kirjautumisen yhteydessä voi olla esimerkiksi:

kertakäyttöisen koodin välitys tekstiviestinä tai sähköpostitse
kertakäyttöisen koodin poiminta todennussovelluksesta tai todennuslaitteesta (suojausavain)
biometrinen tunnistautuminen sormenjäljellä tai kasvontunnistuksella

Monivaiheiselle tunnistautumiselle rinnakkaisena todentamistekniikkana on yleistymässä avainkoodit (passkey), jossa matkapuhelimen tai työaseman käyttäjätili rekisteröidään verkkopalveluun julkisen avaimen salaustekniikkaa hyödyntäen. Tämä edellyttää tukea käyttöjärjestelmältä, selaimelta ja verkkosovellukselta. Kirjautumisen yhteydessä käyttäjä tyypillisesti todennetaan biometrisesti sormenjäljellä tai kasvontunnistuksella. Myös PIN-koodin käyttö voi joissain tapauksissa olla mahdollinen. Käyttöjärjestelmä suojaa Passkey-avaimen turvallisesti. Identiteettivarkaus ei onnistu tietojenkalastelulla koska mitään salasanoja ei ole.

Lisätietoa monivaiheisesta tunnistautumisesta löytyy esimerkiksi Traficomin sivulta.

Lauri Siponen

Cloud Architect

Kysy konsultilta: Milloin tarvitaan Edge Lambdaa?

Mon, 15 Jan 2024 08:50:30 GMT

Milloin tarvitaan Edge Lambdaa?

Edge Lambda on AWS CloudFront ominaisuus, joka mahdollistaa serverless-laskennan reunapalveluissa (edge locations). Se rakentuu AWS Lambdan päälle, joka on jo suosittu AWS palvelu serverless-laskennan tarjoamiseen. Edge Lambda tuo tämän laskentatehon lähemmäksi loppukäyttäjiä ja -laitteita käyttämällä AWS:n reunapalvelun infrastruktuuria. Edge Lambda pystyy muokkaamaan käyttäjän lähettämää kutsua tai kohdejärjestelmän takaisin lähettämää vastausta riippuen missä kohtaa Edge Lambdan suorittaa. Tämä itsessään mahdollistaa monenlaisia ratkaisuja, joilla parantaa esimerkiksi käyttäjäkokemusta ja tietoturvaa. Edge Lambdassa on joitakin rajoituksia, jotka tulisi ottaa huomioon kun uutta ratkaisua suunnittelee. Nämä rajoitukset on listattu AWSn omalla sivulla.

Edge Lambdan voi suorittaa neljässä eri vaiheessa:

Ennen kuin kutsu saapuu CloudFront distribuutiolle* (Viewer Request)
Ennen kuin kutsu lähetetään kohdejärjestelmään (Origin Request)
Ennen kuin kohdejärjestelmän vastaus tallennetaan välimuistiin* (Origin Response)
Ennen kuin CloudFront palauttaa vastauksen loppukäyttäjälle (Viewer Response)

*Edge Lambdan suorituksen tulos tallennetaan CloudFrontin välimuistiin.

Milloin tarvitset Edge Lambdaa?

Alhainen latenssi:

Edge Lambdaa tarvitaan tilanteissa, joissa alhainen latenssi on kriittinen tekijä. Edge Lambdassa laskenta tapahtuu lähempänä käyttäjiä, mikä vähentää merkittävästi viivettä ja parantaa palveluiden suorituskykyä.

Reunalaskennan (edge computing) hyödyntäminen:

Esimerkiksi IoT-sovellukset, jotka vaativat reaaliaikaista päätöksentekoa ja nopeaa vuorovaikutusta laitteiden kanssa, voivat käyttää Edge Lambdaa suorittamaan tehtäviä lähellä laitteita.

Palveluiden hajauttaminen maantieteellisesti:

Kun palvelut on hajautettu maantieteellisesti, Edge Lambda auttaa varmistamaan, että jokainen käyttäjä saa parhaan mahdollisen käyttökokemuksen. Tämä on erityisen tärkeää organisaatioille, jotka toimivat globaalisti.

AWS on koonnut Edge Lambdan yleisimpiä käyttötarkoituksia heidän omaan blogiinsa.

Heikki Ma

Senior Consultant

Vakaata kasvua ja katse vuoteen 2024

tero.kauhanen@webscale.fi (Tero Kauhanen) — Mon, 08 Jan 2024 05:30:00 GMT

Tammikuun alussa on hyvä hetki hetkeksi pysähtyä ja arvioida viime vuoden saavutuksia ja oppeja. Tämän pohjalta voi innolla suunnitella ja rakentaa tätä vuotta.

10 vuoden merkkipaalu

Vuosi 2023 oli Webscalelle merkittävä, kun juhlistimme 10-vuotista taivalta. Tämä merkkipaalu on osoitus kasvusta, joka alkoi kolmen perustajan pienestä tiimistä. On ollut hienoa nähdä, kuinka monet alkuvuosina solmitut asiakas-, yhteistyö- ja työsuhteet ovat vahvistuneet samalla, kun yhtiö on vuosi vuodelta kasvattanut toimintaansa kaikilla osa-alueilla. Kasvu on mahdollistanut tutustumisen sekä uusiin asiakkaisiin että työkavereihin. Ala on myös kehittynyt valtavasti viimeisen kymmenen vuoden aikana; pilviteknologiat, tekoäly ja koneoppiminen vaikuttavat lähes kaikkien yritysten toimintaan, tuoden mukanaan uusia innovaatioita ja tehokkuutta liiketoimintaprosesseihin. Samaan aikaan teknisiä ratkaisuja toteutetaan yhä paremmilla työkaluilla ja prosesseilla, joissa mm. automaatio ja datan hyödyntäminen korostuvat.

Vuoden aikana monet yritykset, myös it-alan yritykset, kertoivat kohdanneensa muutoksia ja haasteita liiketoiminnassaan. Tämä huomioiden olen ylpeä ja kiitollinen siitä, että olemme Webscalessa onnistuneet säilyttämään vakaan kasvun ja kehittämään toimintaamme. Positiiviseen kasvuun ovat merkittävästi vaikuttaneet vahvat ja pitkäaikaiset asiakassuhteemme sekä jatkuva halumme kehittyä. Uskomme, että asiakaslähtöisellä palveluiden kehittämisellä, teknologian hyödyntämisen sekä innovatiivisiin ratkaisuihin keskittymisen kautta, Webscale ja koko ala kykenee menestymään tänäkin vuonna.

Kannattavaa ja vakaata kasvua laadusta tinkimättä

Saavutimme viime vuonna 20%:n kannattavan kasvun liikevaihdossa ja henkilöstömäärämme kasvoi yli 10%:a.

Asiakastyytyväisyytemme on säilynyt erittäin korkealla tasolla. Vuoden 2023 AWS Partner Networkin (APN) kumppanikyselyssä saavutimme vaikuttavan NPS (Net Promoter Score) -tuloksen 85, ja aiemmin samana keväänä toteutetussa laajemmassa kaikkia palveluitamme koskevassa asiakastyytyväisyyskyselyssä NPS-tulos oli vieläkin korkeampi, 92.

Yhteisöllisyys ja henkilöstön hyvinvointi

Vuoden aikana henkilöstötyytyväisyytemme nousi NPS-lukemalla 76:sta 88:aan, mikä heijastaa työyhteisömme vahvaa yhteenkuuluvuuden tunnetta ja henkilöstön tyytyväisyyttä. Olemme sitoutuneet edistämään yhteisöllisyyttä ja työntekijöidemme hyvinvointia, ja tästä näet esimerkkejä blogissamme ja some-kanavillamme.

Vuonna 2023 otimme käyttöön NPS-kyselyn myös rekrytointiprosessimme onnistumisen arvioimiseksi. Rekrytoinnin NPS-lukumme on 64, mikä osoittaa, että suuri osa meille hakeneista tai muuta kautta rekrytointiprosessiimme osallistuneista ovat olleet erittäin tyytyväisiä toimintaamme. Saadut tulokset ovat vahvistaneet, että olemme oikealla tiellä rakentamassa positiivista ja palkitsevaa kokemusta sekä työnhakijoille että työntekijöillemme.

Palveluiden kehittämistä ja osaamisen syventämistä

Vuoden 2023 aikana jatkuvien palveluidemme kehittäminen oli keskeisessä roolissa, mukaan lukien pilven hallinta- ja neuvonantajapalvelut. AWS:n virallisena konsultointi- ja jälleenmyyntikumppanina syvensimme asiantuntemustamme merkittävästi. Laajensimme teknologiatarjontaamme kattamaan myös muita pilvialustoja. Vuoden 2024 suunnitelmissamme on jatkaa tätä kasvua ja kehitystä, keskittyen laadukkaisiin ratkaisuihin ja asiakaskokemuksen parantamiseen entisestään.

Vaalipalvelut: Työkaluja demokratiaan

Yrityksemme palvelutarjontaan kuuluu konsultointi- ja projektipalveluiden sekä jatkuvien palveluiden lisäksi vaalijärjestelmäpalvelut, jotka kattavat paitsi vaalikoneen – palvelumme näkyvimmän osan – myös vaalitulospalvelun ja ääntenlaskujärjestelmän. Vuonna 2023 eduskuntavaalit ja niihin liittyvät vaalikoneet olivat vaalitiimimme keskiössä. Lisäksi aloitimme uuden vaalikoneversion kehittämisen, joka on suunnattu yhdistyksille ja pienemmille mediataloille, ja jonka julkaisemme alkuvuodesta.

Vuonna 2024 vaalipalvelumme, erityisesti presidentinvaalin ja EU-vaalien yhteydessä, keskittyvät tarjoamaan laadukkaita vaalikoneita, jotka tukevat avoimuutta ja osallistumista vaaliprosesseissa. Tavoitteenamme on osaltamme edistää demokratiaa luomalla ratkaisuja, jotka kannustavat kaikenikäisiä äänestäjiä osallistumaan aktiivisesti vaaleihin. Tämä sisältää yhdistysten edustajistovaaleista valtakunnallisiin suuriin vaaleihin ulottuvat prosessit.

Asiantuntijuuden ja oppimisen kehittäminen

Vuonna 2023 panostimme asiantuntemuksemme jakamiseen ja kehittämiseen sekä tarjosimme myös mahdollisuuden tutustua paremmin työntekijöihimme. Näkyvimpiä kokonaisuuksia tähän liittyen olivat Webscale Tech Days, Pilvipilotit-podcast, Kysy konsultilta -blogisarja sekä Webscalen kaverikirja, joista kerron lyhyesti ohessa.

Webscale Tech Days: Tulevaisuuden teknologiat ja verkostoituminen

Viime vuoden toukokuussa järjestimme Webscale Tech Days -kutsuvierastapahtuman Tuusulassa, johon osallistui noin 50 alan ammattilaista. Tapahtuma tarjosi hienon mahdollisuuden perehtyä alan uusimpiin innovaatioihin ja verkostoitumiseen. Positiivisen palautteen innoittamana päätimme, että tänä vuonna avaamme ovet kaikille kiinnostuneille. Laita siis some-kanavamme seurantaan, sillä tiedotamme lähiaikoina tarkemmin tämän vuoden tapahtumasta!

Pilvipilotit

Lanseerasimme viime vuonna Pilvipilotit-podcastin, jossa keskustelemme pilviteknologian trendeistä ja haasteista erikokoisten yritysten näkökulmasta. Tämä on ollut arvokas kanava jakaa tietämystä ja kokemuksia laajemmalle yleisölle. Podcastin uudet jaksot ovat jo työn alla.

Kysy konsultilta -blogisarja

Kysy konsultilta -blogisarjamme tarjoaa hyödyllistä tietoa pilvi-, ohjelmistokehitys- ja data-analytiikan saralla, auttaen ymmärtämään alan monimutkaisia ilmiöitä ja termejä paremmin. Sarjassa konsulttimme tekevät selkoa alan termeistä ja ilmiöistä niin, että kiireisempikin ehtii ne lukea työpäivän aikana.

Kaverikirja

Yrityksemme koostuu moninaisista persoonista, joilla on erilaiset taustat, mutta yhteinen intohimo teknologiaa kohtaan ja kyky tehdä sujuvaa yhteistyötä. Somessa julkaistava Kaverikirja-sarjamme tuo esille tämän monimuotoisuuden ja korostaa yhteisöllisyyttämme. Siinä webscalelaiset, tutummin webscalerit, kertovat itsestään ja toisistaan sekä jakavat harrastuksiaan ja kokemuksiaan.

AWS re:Invent 2023 ja alan tapahtumat

Marras-joulukuun vaihteessa kolme konsulttiamme osallistui AWS re:Invent -konferenssiin Las Vegasissa. AWS re:Invent -tapahtuma on alan johtava konferenssi, joka tarjoaa kattavan katsauksen pilviteknologian uusimpiin suuntauksiin ja innovaatioihin. Tämän lisäksi olemme aktiivisesti osallistuneet meetupeihin, seminaareihin sekä AWS:n ja muiden teknologiakumppaneiden paikallisiin tapahtumiin Suomessa ja Pohjoismaissa. Panostuksemme sertifiointeihin ja jatkuvaan kouluttautumiseen ovat osa sitoutumistamme pysyä teknologian aallonharjalla, mikä näkyy suoraan asiakastyössämme ja palveluidemme laadussa.

Kohti tulevaa

Iso kiitos koko henkilöstöllemme, asiakkaillemme ja yhteistyökumppaneillemme menneestä vuodesta. Yhteistyössä kanssanne olemme voineet kasvaa ja kehittyä. Odotamme innolla, mitä vuosi 2024 tuo tullessaan, ja jatkamme matkaamme yhdessä luoden kestäviä digitaalisia palveluita.

Kysy konsultilta: Miksi CDK-projekti tarvitsee yleensä bootstrapata?

Wed, 03 Jan 2024 08:38:02 GMT

Miksi CDK-projekti tarvitsee yleensä bootstrapata?

AWS Cloud Development Kit eli tuttavallisemmin CDK on AWS:n tarjoama framework resurssien ja infrastruktuurin provisiointiin useilla ohjelmointikielillä. Pellin alla CDK ajaa CloudFormationia ja toimii abstraktiokerroksena, jonka tarkoituksena on auttaa tekemään asioita hyvien käytäntöjen mukaisesti. Vaikka CDK abstraktoi joitakin kompastuskiviä piiloon, on syytä muistaa mahdollisuus kurkata mustan laatikon sisälle. CDK:lla provisioitavat resurssit syntyvät CloudFormation stackeina, joista näkee koodista generoidun CloudFormation templaten.

Matka koodista resurssiksi sisältää muitakin askelia, ja käytännössä kaikki ei-triviaalit CDK-projektit on tarpeen 'bootstrapata' mikä tarkoittaa CDK:n käyttämien riippuvuuksien ja resurssien luomista ympäristöön ennen itse sovelluksen resurssien pystyttämistä. Yksinkertaisimmillaan tämä tarkoittaa 'cdk bootstrap' komennon ajamista, joka perustaa ympäristöön 'CDKToolkit' nimisen CloudFormation-stackin näillä resursseilla.

Oletusasetuksillakin tehty bootstrap toimii testatessa, mutta templatea voi muokata haluamallaan tavalla ja ympäristön vaatimusten mukaan. Asioita ei tarvitse jättää maagisiksi, sillä käytössä olevan templaten näkee stackista, ja ennen luomista templatea voidaan tarkastella komentamalla 'cdk bootstrap --show-template'. Oletuksena esimerkiksi CloudFormationia ajetaan varsin laajoilla oikeuksilla, ja bootstrap-resursseille syntyvä tunniste ei ole erityisen kuvaava. Muita mahdollisesti mielenkiintoisia arvoja on useampi säädettäväksi.

CDK on myös jatkuvasti kehittyvä työkalu, ja bootstrap-template kehittyy sen mukana. Aiemmin bootstrapattu ympäristö voi siis erota joiltakin osin myöhemmin bootstrapatusta ympäristöstä. Bootstrap-templaten sisällyttäminen versionhallintaan auttaa näiden eroavaisuuksien löytämisessä ja helpottaa päivittämistä eteenpäin. CDK-projektien kanssa työskennellessä on hyvä muistaa tarkastaa mahdolliset erot CDK v1 ja CDK v2 välillä. Esimerkiksi CDK v2 tukee ainoastaan modernia bootstrap-templatea, kun CDK v1 tukee sekä modernia että vanhempaa mallia.

Hyvin suunniteltu ja tarpeen mukainen bootstrappaus osana CDK-projektia mahdollistaa asioiden tekemisen hyvien infrastructure-as-code -käytäntöjen mukaisesti sekä toistettavien ja ennakoitavissa olevien ympäristöjen pystyttämisen uudelleen helposti nyt, tulevaisuudessa ja tekijästä riippumatta.

Teemu Ala-Järvenpää

Cloud Specialist

AWS re:Invent 2023 - Webscalerit Las Vegasissa

Thu, 28 Dec 2023 07:00:00 GMT

Marras-joulukuun vaihteessa kolme Webscalen konsulttia, Heikki, Jussi ja Ville, suuntasivat kohti Las Vegasia ja AWS re:Invent tapahtumaa. Odotukset ennen matkaa olivat korkealla, sillä koronavuodet olivat siirtäneet osallistumista tapahtumaan. Tämä oli kolmikkomme ensimmäinen matka AWS re:Inventiin.

Matkaan lähdettiin lumisena lauantaina 25.11. ja edessä oli pitkä lentomatka Dallasin kautta Vegasiin. Matkasta tuli kirjaimellisesti pitkä ja erilaisten kommellusten jälkeen matka-aikaa kertyi lopulta 20 tuntia. Vaikka matka painoi pohkeissa, tunnelma perillä oli korkealla.

Tunnelmat Las Vegasissa ennen konferenssin alkua

AWS re:Invent tapahtuma alkoi vasta maanantaina 27.11., joten meillä oli sunnuntaina aikaa valmistautua tulevaan viikkoon. Majoituspaikkana toimi Palazzo resort, The Venetian, joka sijaitsi lähes tapahtumapaikan ytimessä. Huoneen ikkunasta aukesi näkymät Vegasin uusimman vetonaulan, The Spheren, suuntaan. Sunnuntain aikana kävimme hakemassa tapahtumapassit konferenssipaikalta. Tällöin viimeistään ymmärsimme, kuinka isosta tapahtumasta oli kyse.

Pääsimme tutustumaan Certified Loungeen, joka oli vain AWS-sertifioiduille henkilöille tarkoitettu oleskelutila. Kävimme myös kuuntelemassa “How to re:invent” -session, jossa jaettiin vinkkejä miten konferenssista saa eniten irti - tätä suosittelemme kaikille ensikertalaisille! Kävimme myös hakemassa reissun ensimmäiset AWS-swagit itsellemme.

Iltapäivällä vierailimme Mandalay Bay kasinolla sijaitsevassa Rec Centerissa. Tämä oli re:Inventin uusi viihdealue, joka oli järjestetty partnereiden voimin. Tarjolla oli pientä syötävää, jenkkifudista amerikkalaiseen tailgating -henkeen sekä lisäksi mm. erilaista urheiluun liittyvää aktiviteettia, pelejä, golf-simulaattoreita, F1-simulaattoria ja jalkapalloa.

AWS re:Invent -konferenssi

Maanantaina alkoi itse konferenssi ja olimme varanneet etukäteen osaan sessioista paikat, joissa halusimme käydä. Tarjontaa oli runsaasti, joten jätimme tilaa myös extempore sessioille. Aiheina meitä kiinnostivat mm. FinOps ja tekoäly. Olimme onnistuneet varaamaan paikat hyvin näitä aiheita käsitteleviin sessioihin. Tämän vuoden ehdottomasti suurin painopiste konferenssissa tuntui olevan tekoälyssä ja uusissa mahdollisuuksissa mitä tämä teknologia tarjoaa. Luento Falcon-kielimallin kehityksestä oli mielenkiintoinen. Lisäksi kävimme kuuntelemassa pari sessiota generatiivisesta AI:sta ja sen tuomista mahdollisuuksista.

Jokaisen aihepiirin ympärillä oli erityyppisiä istuntoja, joista osa oli vähemmän vuorovaikutteisempia kuin toiset ja myöskin niiden teknisyys vaihteli. Tarjolla oli muun muassa chalk talk- ja workshop-tyyppisiä sessioita. Chalk talk -sessiot olivat Q&A-tyyppisiä, joissa oli mahdollisuus kysellä haastavia kysymyksiä AWS-asiantuntijoilta. Asiantuntijat saattoivat hyödyntää piirtotaulua apuna vastauksissa. Workshop-tyyppisissä sessioissa ratkottiin oikeita AWS-aiheisia ongelmia asiantuntijoiden avustuksella.

Välittömästi tiistaiaamuna havaitsimme miten suosittuja re:Inventin keynote-sessiot ovat. Vajaa tunti ennen keynoten alkua (n. klo 7:45) jonotusaula oli jo täynnä. Jos siis aikoo keynotea katsomaan, on oltava ajoissa. Onneksi keynotet myös live-striimataan Content Hub tiloihin ja löytyvät myös netistä. AWS:n CTO:n Werner Vogelsin keynote torstaiaamuna oli päästävä näkemään, tiedossa oli siis aikainen herätys. Herääminen myös kannatti, sillä Vogels ei pettänyt ja veti kovan shown hänelle ominaisella huumorilla höystettynä. Keynoten aiheena tänä vuonna olivat modernit, kustannustietoiset ja kestävät arkkitehtuurit. Keynoteen liittyvä sivusto thefrugalarchitect.com kannattaa käydä tsekkaamassa.

Uudet julkaisut tapahtumassa

Konferenssin aikana AWS julkaisi monia uusia tuotteita sekä ominaisuuksia jo olemassa oleville tuotteille. Esimerkeiksi nostaisimme tähän AWS Graviton4 (uusi ARM64 sukupolvi) ja Amazon Q (generatiivinen AI avustaja). AI-avustaja oli yksi mielenkiintoisimmista julkaisuista , mutta toki julkistuksen jälkeisen wow-efektin mentyä ohi tuntui kyllä aika loogiselta, että myös AWS julkaisee oman generative-AI avustajansa, sillä muilla kilpailijoilla sellainen alkaa jo ollakin. Joka tapauksessa Q:n mahdollisuuksia AWS-kehityksessä, operoinnissa yms. on pakko päästä testaamaan! Näiden lisäksi AWS julkaisi monta uutta ominaisuutta heidän AWS bedrock ja SageMaker palveluihin.

Aurora Unlimited serverless-tietokanta oli yksi uusista julkaisuista. Tämä helpottaa massiivisten multi-region tietokantaclustereiden rakentamista serverless-filosofian mukaisesti. Hyvä ja odotettukin julkistus oli myös Elasticache välivarastopalvelun serverless-versio, joka poistaa serverless-mallia noudattavista sovellusarkkitehtuureista yhden viimeisistä "perinteisistä" VPC:tä vaativista komponenteista.

Opit konferenssista

Koska olimme kaikki ensimmäistä kertaa re:Invent tapahtumassa, kaikki oli uutta ja ihmeellistä. Mukaan tarttui paljon oppia, miten tapahtumaan voisi valmistautua paremmin jatkossa, jos kyseiseen tapahtumaan tulee mentyä uudemman kerran.

Suosittelemme ilmoittautumaan etukäteen jo Suomessa sinua kiinnostaviin luentoihin. Emme kuitenkaan suosittele varaamaan kalenteria ihan täyteen, sillä tapahtumapaikalla on varsin pitkät siirtymät. Lisäksi uusia sessioita julkaistaan vielä re:Inventin jo alettua.

Konferenssissa on lisäksi Partner -tapahtumia. Näihin suosittelemme myöskin ilmoittautumaan etukäteen. Ne ovat oiva tapa verkostoitua ja tarjolla on ilmaista ruokaa sekä juomaa. Viimeisenä vinkkinä klassinen pukeutumisopas. Kannattaa varata riittävästi lämpimiä vaatteita. Vaikka konferenssipäivät kuluivat pääosin sisätiloissa, on siellä todella tehokas ilmastointi. Myös itse ulkoilma Nevadassa kyseiseen vuodenaikaan ei ole kovinkaan lämmin, lämpötilan ollessa noin 5-15 astetta. Vaatetuksen lisäksi kannattaa ottaa mukaan hyvät kengät, sillä kävelyä tulee todella paljon tapahtuma-alueen ollessa laajalla alueella. Meilläkin tuli jokaiselle kävelyä keskimäärin noin 15km/päivä, ilman, että kävimme juurikaan ulkona.

Las Vegas - Kaupunki täynnä huveja

Meidän re:Invent reissu ei ollut kuitenkaan onneksi vain pelkkää konferenssia ja luentosessioita. Ehdimme myös vähän tutustua Vegasiin, kierrellä kasinoita ja testata yhden Gordon Ramsayn viidestä Vegasin ravintolasta. Tiistaina kävimme uudessa The Sphere teatterissa. Maailman suurin näyttö oli kyllä todella vaikuttava kokemus.

Tapahtumassa oli oiva mahdollisuus verkostoitua alan osaajien kanssa. Keskiviikkoiltana kävimme verkostoitumassa AWS EMEA-alueen beach partyissä, ja tietenkin koko konferenssin loppubilefestari re:Play käytiin tsekkaamassa torstai-iltana. Pääesiintyjä Major Lazer oli mahtava. Lisäksi oli mahdollista esimerkiksi osallistua peertalk-istuntoihin, joissa ideana oli tavata muita henkilöitä, joita kiinnosti sama aihe. Tutustuimme muihin ihmisiin myös AWS Certified -oleskelutilassa ja istunnoissa, joissa tehtiin tiimityötä.

Lopputunnelmat

Perjantaiaamuna tunnelmat olivat väsyneen lisäksi hieman haikeat. Mahtava re:Invent viikko oli nyt ohi. Aamulla olisi vielä ollut tarjolla muutamia sessiota, mutta aamupalaa lukuunottamatta, aikataulut eivät antaneet mahdollisuutta niihin osallistua. Aamupalan jälkeen suuntasimme lentokentälle, jossa heitimme hyvästit Heikille, joka oli palaamassa jo Suomeen. Jussin ja Villen matka jatkui kuitenkin autovuokraamolle ja kimppakyydillä kohti tulevaa lomaviikkoa Kalifornian rannikolla.

AWS re:Invent oli kokonaisuudessaan erittäin hieno ja onnistunut kokemus. Opimme paljon uutta, vahvistimme omaa osaamistani ja inspiroiduimme uusista aiheista. Voimme ehdottomasti suositella kyseistä konferenssia kaikille aiheesta kiinnostuneille.

Reissuterveisin,

Heikki Ma

Jussi Lehtiniemi

Ville Välimäki

Yhteisöllisyys - ei vain logo hupparissa

sara.peltola@webscale.fi (Sara Peltola) — Thu, 21 Dec 2023 10:52:50 GMT

Yhteisöllisyyden merkitys työpaikoilla on korostunut erityisesti koronavuosien jälkeen. Työterveyslaitoksen tuoreessa tutkimuksessakin todetaan, että työuupumuksen riski on kasvanut ja yksinäisyyden kokemukset ovat yleistyneet, erityisesti nuorilla työntekijöillä ja etätöissä olevilla miehillä.

Yhteisöllisyyden kehittäminen ja ylläpitäminen on tärkeä osa omia työtehtäviäni toimistopäällikkönä. Pysähdyn usein miettimään, miten yhteisöllisyys meillä Webscalella näkyy ja mitkä asiat tekevät meistä yhteisöllisen työpaikan.

Webscalen työntekijät eli webscalerit tunnistaa helposti brändivaatteisiin ja -tuotteisiin painetutusta kruununmuotoisesta logosta. Rahalla hankitut tuotteet ovat tietysti mukava lisä, mutta nämä eivät itsessään ole avain sujuvaan yhtenäiseen tekemiseen ja toimimiseen.

Webscalerit - keitä me olemme?

Työyhteisömme on insinööripainotteinen, mutta joukkoomme mahtuu monenlaisia persoonia ja jokaisella on tilaa olla oma itsensä. Ei ole väliä oletko sosiaalinen hassuttelija, hiljainen pohdiskelija, tai jotain tältä väliltä.

Suurimpina yhteisinä tekijöinä Webscalella koen työntekijöidemme korkean ammattitaidon, halun kehittää omaa osaamista sekä arvostuksen ja kunnioituksen toisiamme kohtaan. Yhteiset toimintatavat ja pelisäännöt asettavat meillä raamit työskentelylle ja tekemiselle.

Teemme töitä korkealla ammattiylpeydellä ja -taidoilla, ei sieltä missä rima on matalin. Erään kollegani sanat kuvaavat mielestäni erinomaisesti tekemistämme: “jos asiaa ei halua tehdä kunnolla, tulee miettiä kannattaako sitä tehdä lainkaan” .

Etänä - kotona - toimistolla - aftereilla

Yrjönkadun toimistosta tuli webscalereiden “kotipesä” muuton myötä syksyllä 2022. Halusimme säilyttää toimistomme sijainnin Helsingin ydinkeskustassa, jotta sinne olisi edelleen hyvät kulkuyhteydet kaikista ilmansuunnista.

Kuluneen vuoden aikana olemme mielestäni onnistuneet herättämään toimistoelämän ja yhteisen tekemisen jälleen henkiin, hiljaisempien koronavuosien jälkeen. Kannustamme työntekijöitämme osallistumaan yhteisiin tapahtumiin, elämäntilanteet huomioiden - pakko toimistolle tai tapahtumiin ei ole tulla, mutta mielellämme aina tapaamme toisiamme.

Toimistolla on ilahduttava kuunnella kollegoideni kuulumisia, osallistua ja seurata keskusteluita sisäisissä Slack -kanavissamme. Usein konsulttien väliset keskustelut ajautuvat itselleni niin sanottuun syvään päätyyn eli kovin tekniseen osaamiseen - olen kuitenkin oppinut sujuvaksi kuuntelijaksi. Tapaa, jolla he keskustelevat teknisistä ratkaisuista on mielenkiintoista seurata ja on mahtava huomata, kuinka he yhdessä löytävät ratkaisun käsissä olevaan haasteeseen.

Vuonna 2023 olemme päässeet järjestämään toimistolla kuukausittaiset Monthly -palaverit aamiaisen ja lounaan kera, jossa käymme läpi ajankohtaisia asioita talousluvuista projektikuulumisiin. Monthlyn yhteydessä järjestetään myös Tech Day -iltapäivä, jossa konsulttimme pääsevät kertomaan minkälaisia teknisiä ratkaisuita ovat tehneet eri asiakasprojekteissa ja jakamaan omaa osaamistaan. Toki etäyhteydet toimivat edelleen, joten työskentelypaikka ei määritä osallistumismahdollisuutta.

Myös Tuusulan Krapilla järjestetty Tech Days -konferenssi ja Webscalen 10 - vuotissyntymäpäivät ovat olleet mukavia hetkiä niin kollegoiden kuin asiakkaiden kanssa. Näiden lisäksi olemme käyneet ahkerasti pelaamassa yhdessä padelia, juhlineet pikkujouluja sekä viettäneet aikaa erilaisissa afterwork -tapahtumissa aina oopperanäytöksestä jääkiekkopeliin - mahtuihan tähän mukaan myös maaliskuinen viikonloppu Himoksella.

Innolla kohti vuotta 2024

Tuoreimman työtyväisyyskyselyn tulokset osoittavat, että Webscalella voidaan hyvin. Pyrimme kuitenkin jatkuvasti parantamaan toimintaamme ja jatkamme yhteisöllisyyden kehittämistä myös tulevana vuonna. Pääsemme varmasti järjestämään jälleen mielenkiintoisia tapahtumia sekä yhteistä tekemistä.

Etulyöntiasemana tehtävässä onnistumiselle, pidän avointa keskustelukulttuuriamme ja matalaa hierarkiaa, jolloin pystymme myös pienillä teoilla parantamaan viihtyvyyttä työyhteisössämme.

Haluan omasta puolestani kiittää jokaista työntekijää ja asiakasta - te teette minulle Webscalesta juuri sen oikean työpaikan, jossa minun on mukava työskennellä. Odotan innolla tulevaa vuotta 2024 kanssanne.

Hyvää ja rentouttavaa joulua kaikille! ♥

Sara Peltola

Toimistopäällikkö

Mahdollisuus kasvaa ja kehittyä joustavassa työympäristössä - esittelyssä uusi webscaler Miro

Mon, 18 Dec 2023 07:22:46 GMT

Marraskuussa Webscalen myyntitiimi jatkoi vahvistumistaan, kun Miro Nissilä aloitti työt Junior Sales Specialistina. Ensimmäisten viikkojen aikana Miro on päässyt perehdytyksen lisäksi jo konkreettiseen asiakastyöhön kiinni ja kertoo alun sujuneen kaikin puolin mukavissa merkeissä. Ensi vuoden osalta tavoitteet ovat selkeät.

Miron tie Webscalelle

“Koko ajan tuli tunne, että tietää missä mennään ilman epäselvyyksiä. Tuntui, että hakijaprofiiliini ja henkilökohtaiseen tilanteeseeni oltiin perehdytty hyvin. Avoimuus nousi myös hyvin esiin”, Miro totesi rekrytointiprosessista.

Keskustelujen jälkeen Miro päättikin tarttua haasteeseen ja hän on ehtinyt työskennellä nyt muutaman viikon ajan Webscalella. Miron työnkuvaan kuuluu myyntitehtävät erityisesti prosessin alkuvaiheen osalta eli potentiaalisten asiakkaiden prospektointi, kontaktointi ja yhteydenpito muun muassa puhelimen välityksellä.

Perehdytys on sujunut Miron mukaan hyvin. Hän kokee sen edenneen sopivassa tahdissa ilman turhaa kiirehtimistä, mutta myös käytännön työtä on tuotu hyvässä suhteessa mukaan pikkuhiljaa. Perehdytyksessä toimitusjohtaja Tero Kauhaselle on ollut suuri rooli ja myöskin myyntitiimistä Teemu Kuusisto ja Iiro Nousiainen ovat sparrailleet asioita. Ylipäätään ensiajatukset myyntitiimistä ovat positiiviset. Miro kokee pienen tiimin kommunikoinnin sujuvan hyvin ja esimerkiksi eri prosesseista pystytään sopimaan joustavasti. Parasta Webscalella työskentelyssä tähän asti Miro sanoo olleen muut webscalerit eli työporukka, johon hän koki pääsevänsä sisään heti ensimmäisestä päivästä lähtien. Myös pikkujouluja vietettiin heti ensimmäisen työviikon päätteeksi, jolloin Miro pääsi tutustumaan suurimpaan osaan porukkaa työajan ulkopuolellakin.

Töiden lisäksi Mirolla ei ole hankaluuksia vapaa-ajalla keksiä tekemistä, sillä hän opiskelee parhaillaan samaan aikaan Turun Kauppakorkeakoulussa kolmatta vuotta tietojärjestelmätieteitä. Miro työskentelee Webscalella osa-aikaisesti opintojen ohessa ja pystyy joustavasti vaikuttamaan työskentelyaikoihin, -päiviin ja -paikkaan sen mukaan miten opinnot aikatauluttavat kalenteria. Alku on tämänkin osalta sujunut hyvin, sillä opintojen osalta syksy on ollut myös hieman rauhallisempaa. Töiden ja opintojen jälkeen jäävän ajan Miro tykkää viettää urheillen, muun muassa käymällä kuntosalilla ja pelaamalla padelia.

Mahdollisuus kasvaa ja kehittyä

Kasvuyrityksenä Webscale haluaa tarjota kehittymismahdollisuuksia uran eri vaiheilla esim. kannustamalla alan sertifiointeihin. Yhtiö on keskittynyt rekrytoinnissaan kokeneempiin it-asiantuntijoihin, mutta mahdollisuuksien mukaan Webscale haluaa tarjota myös uran alkuvaiheessa oleville tilaisuuksia kasvaa ja kehittyä osana osaavaa tiimiä. Yhtenä tekijänä, joka houkutti Miroa jättämään hakemuksen, oli nimenomaan optio kasvaa ajan saatossa kenties ihan kokoaikaiseksi myyntitiimin jäseneksi ja kasvattaa vastuualuetta osaamisen karttuessa sekä opintotilanteen sen salliessa.

Mahdollisuus kasvaa ja kehittyä tuli ilmi jo työpaikkailmoituksesta ja Miron mukaan haastattelujen aikana käytyjen keskustelujen jälkeen tämä näkemys vain vahvistui. Hän kokee nykyisen position sopivan loistavasti hänen tämän hetkiseen elämäntilanteeseen opintojen oheen.

Ensi vuoden osalta Miro odottaa, että saa opeteltua perinpohjaisesti Webscalen palvelutarjonnan sekä myynnin prosessit. Lisäksi luonnollisesti myös AWS:n syövereihin ja sen tarjoamiin myynnin mahdollisuuksiin on tarkoitus keskittyä. Opintojen osalta puolestaan Miro suunnittelee aloittavansa kandidaatin tutkielman kirjoittamisen ensi vuoden puolella.

Töihin Webscaleen?

Kiinnostaisiko sinua liittyä tiimiimme? Lue lisää rekrysivuiltamme. Kuulemme mielellämme tarinasi ja otamme selvää, olisimmeko me sinulle oikea työnantaja.

Kysy konsultilta: Mitkä ovat AWS:n ja asiakkaan vastuut pilven tietoturvassa?

Wed, 13 Dec 2023 06:15:33 GMT

Mitkä ovat AWS:n ja asiakkaan vastuut pilven tietoturvassa?

AWS noudattaa tietoturvan yhteydessä jaetun vastuun mallia , joka määrittelee AWS:n ja asiakkaan vastuut tietoturvaan liittyen.

AWS:n vastuulla on huolehtia, että kaikkien AWS-palveluiden käyttämä infrastruktuuri sekä AWS:n tarjoamat palvelut ovat turvallisia. Tämä pitää sisällään AWS-palveluiden käyttämien ohjelmistojen, laitteistojen, verkkojen ja konesalien turvallisuuden.

Asiakkaan vastuulla on puolestaan huolehtia oman pilviympäristön turvallisuudesta. Tämä pitää sisällään montakin eri asiaa ja kokonaisuutta, kuten esimerkiksi AWS-tilin suojauksen, identiteetin ja pääsynhallinnan, käytettävien AWS-palveluiden ja verkkojen suojaamisen ja turvallisuuden, uhkien ja haavoittuvuuksien tunnistamisen, tietojen salauksen niin levyllä kuin verkkoliikenteessäkin, pilvi-infrastruktuurin määrittelemisen ohjelmallisesti (IaC) ja tietoturvaan liittyvien parhaiden käytänteiden noudattamisen.

AWS-palveluiden välillä on suuriakin eroja liittyen tietoturvan vastuuseen ja laajuuteen. Esimerkiksi EC2-palvelun kanssa asiakas vastaa laaja-alaisesti ylläpidosta ja turvallisesta konfiguroinnista, kuten esimerkiksi käyttöjärjestelmän ylläpidosta, instanssille asennetuista sovelluksista, datan salaamisesta sekä instanssin turvallisesta konfiguroinnista. Lambda-palvelun yhteydessä asiakkaan vastuut tietoturvaan liittyen ovat suppeammat. Asiakas varmistaa, että Lambdassa suoritettava koodi ja käytetyt kirjastot ovat turvallisia sekä huolehtii identiteetin ja pääsynhallinnasta. AWS puolestaan vastaa Lambda-palvelun taustalla olevan infrastruktuurin turvallisuudesta.

AWS tarjoaa erilaisia palveluita tietoturvaan liittyen. Näitä palveluita käytetään esimerkiksi tietoturvaan liittyvien ongelmien tunnistamiseen, uhkilta suojautumiseen, hyökkäysten havaitsemiseen ja reagointiin sekä palautumiseen hyökkäyksen jäljiltä. Tällaisia palveluita ovat esimerkiksi Inspector, Security Hub, IAM, Security group, Network Firewall, Shield, WAF, Macie, KMS, GuardDuty, Detective sekä Backup. Tietoturvaan liittyvistä AWS-palveluista voi käydä lukemassa lisää myös AWS:n omasta listauksesta .

Näiden palveluiden käyttämisen lisäksi on myös suositeltavaa, että turvallisuus huomioidaan ohjelmistokehityksen kaikissa vaiheissa. DevOpsin yhteydessä tästä käytetään nimitystä DevSecOps, jota käyttämällä tietoturva on läsnä kaikissa vaiheissa suunnittelusta tuotantoympäristön monitorointiin, ja lisäksi tietoturvaan liittyvät operaatiot, kuten esimerkiksi tietoturvaongelmien tunnistaminen ja havaittuun uhkaan reagointi automatisoidaan.

Tietoturva on laaja aihepiiri, mutta AWS:n Well-Architected Framework sisältää erillisen tietoturvaan keskittyvän "Security Pillar" -osion , josta asiakkaat saavat paljon arvokasta tietoa tietoturvaan liittyen, kuten esimerkiksi parhaita käytänteitä ja suosituksia toteutuksiin liittyen.

Jukka Ukkonen

Senior Consultant

Kysy konsultilta: Mihin chaos engineering -työkaluja käytetään?

Thu, 07 Dec 2023 07:17:25 GMT

Mihin chaos engineering -työkaluja käytetään?

Chaos engineering on Netflixin alunperin kehittämä filosofia, jolla pyritään parantamaan isojen hajautettujen järjestelmien vikasietoisuutta ajamalla erilaisia "kaaoskokeita" (chaos experiment) suoraan tuotantoympäristössä. Netflix aloitti tämän kehittämällä Chaos Monkey nimisen työkalun, joka toimii tuotantoympäristössä ja sammuttaa virtuaalikoneita sattumanvaraisesti. Tämä käytännössä pakottaa tiimit kehittämään palveluista sellaisia, että ne toipuvat tällaisista vikatilanteista. Myöhemmin vastaavia työkaluja on kehitetty lisää ja ne pystyvät injektoimaan ympäristöihin paljon erilaisia vikatilanteita, esimerkiksi verkkotason latenssia tai katkoksia, pakettihävikkiä ym, ja virtuaalikonetasolla kasvanutta CPU-kuormaa, muistin kulutusta tai muita suorituskykyyn vaikuttavia ongelmatilanteita. Hallitusti injektoitujen vikatilanteiden kautta järjestelmien vikasietoisuutta voidaan testata ja sitä kautta pyrkiä korjaamaan havaitut ongelmat. Chaos engineerig -filosofian ydin on ajaa testejä nimenomaan tuotantoympäristössä, jolloin voidaan varmistua siitä, että testit mahdollisimman tarkasti toistavat tosielämän vikatilanteita.

Chaos engineering -kokeiden suorittaminen tuotantoympäristössä vaatii pitkäjänteistä kehitystä ja kokeiden tarkkaa suunnittelua ja valmistelua. Tätä ennen pitää tietenkin olla suhteellisen hyvä käsitys siitä miten järjestelmä tulee käyttäytymään vikatilanteissa, ja yleensä kokeilla halutaankin testata jotain tiettyä järjestelmän osa-aluetta. Järjestelmien vikasietoisuuden parantumisen lisäksi toinen tärkeä hyöty on siinä että sovellustiimit oppivat toimimaan paremmin myös todelllisissa vikatilanteissa kun vikatilanteiden selvittelyä harjoitellaan hallitusti chaos engineering kokeiden kautta.

Vaikka chaos engineering -filosofian tavoitteena onkin pyrkiä tilanteeseen, jossa luottamus järjestelmän toimintaan on sillä tasolla, että kokeita voidaan ajaa tuotantoympäristössä riittävällä varmuudella siitä, että kokeet itsessään eivät aiheuteta isompaa hallitsematonta vikatilannetta, tähän ei ole tietenkään välttämätöntä pyrkiä heti alkuvaiheessa. Chaos engineering -työkaluista voi olla paljonkin hyötyä osana normaalia järjestelmien testausprosessia, jolloin mahdolliset ongelmat havaitaan mahdollisesti jo testausvaiheessa ja voidaan korjata ennen kuin tuotannossa vastaavia ongelmia edes ilmenee.

Chaos engineering -kokeiden hallintaan ja suorittamiseen löytyy useita avoimen lähdekoodin sovelluksia ja myös maksullisia apuvälineitä, esimerkiksi ChaosMesh, LitmusChaos ja Gremlin. Toimittaessa AWS-ympäristössä voidaan käyttää AWS:n omaa Fault Injection Simulator (FIS) -työkalua joka integroituu suoraan AWS-resursseihin ja pystyy simuloimaan useita erilaisia vikatilanteita.

Jussi Lehtiniemi

Senior Cloud Architect

Perusasiat keskiössä - Rekrytoinnin NPS-kyselyn tulokset

Mon, 04 Dec 2023 12:46:55 GMT

Rekrytointi on tärkeä osa menestyvää kasvuyritystä ja sen avulla voidaan vaikuttaa merkittävästi työnantajamielikuvaan. Siksi on oleellista mitata myös sen onnistumista, jotta tiedetään mikä prosessissa toimii ja missä voisi mahdollisesti olla parannettavaa. Kilpailu osaavista työntekijöistä on edelleen kovaa ja panostamalla rekrytointiprosessin eri vaiheisiin, voidaan erottautua kilpailijoista ja sitä kautta taata paremmat mahdollisuudet pärjätä osaajakilpailussa jatkossakin.

Vuoden 2023 alusta lähtien olemme käyttäneet NPS-sähköpostikyselyä rekrytointiprosessimme onnistumisen mittaamiseen. NPS, eli Net Promoter Score, on tyytyväisyyden mittari, joka rekrytointiprosessin kontekstissa kertoo, kuinka todennäköisesti prosessissa mukana olleet henkilöt suosittelisivat kohdeyritystä työnantajana muille. Se lasketaan asiakkaiden antamien suosituspisteiden perusteella.

Tätä blogia julkaistaessa Webscalen NPS-luku rekrytoinnin osalta on komea 67. Tämä on vahva osoitus siitä, että olemme onnistuneet rekrytointiprosessin aikana tuottamaan suurimmalle osalle kandidaateista positiivisen kokemuksen ja he näkevät Webscalen potentiaalisena työnantajana itselleen tai muille sen perusteella.

Kandidaattien palautteita

Numeroarvosanan lisäksi kandidaateilla on NPS-kyselyyn vastatessa mahdollista antaa avointa palautetta kokemastaan rekrytointiprosessista. Näitä avoimia palautteita olemmekin saaneet mukavan määrän, joista muutama mainittuna alla:

“Erityisesti henkilökohtainen vastaus hakemukseen liittyen on todella hyvä ja ammattimaista. Todella monet firmat laittavat automaattisia viestejä sekä valituksi tulleille ja niille jotka eivät ole tulleet valituksi. Mukava nähdä, kun on ihmisiä rekrytoinnin puolella vastaamassa.”

“Erityisesti arvostin selkeää aikataulutusta ja siitä informointia. Koko ajan tiesi missä mennään, mikä on mielestäni äärimmäisen tärkeää rekryprosessissa.”

“Webscalen rekrytointiprosessi oli itselleni mielekäs kokemus. Keskusteluajat sai sovittua omaan aikatauluun sopivasti ja haastatteluissa oli hyvä tunnelma. Myös haastattelun monipuolisuus oli kattava sekä hyvällä tavalla yllättäväkin.”

“Haastattelut menivät oikein rennosti ja myös haastavasti teknisissä kysymyksissä. Yhteydenotot ja kommunikointi hyvää.”

Perusasiat rekrytointiprosessin kulmakivinä

Rekrytoinnin ammattilaisena yllä olevat palautteet, joita saimme useita vastaavia, lämmittävät tietysti mieltä. NPS-luvussa ovat mukana kaikki rekrytointiprosessimme. Tämä tarkoittaa sitä, että prosessien välillä on pieniä eroja keskenään ja osittain eri henkilöt ovat niissä mukana yrityksen sisältä. Tehtävästä ja prosessista huolimatta, olemme pyrkineet pitämään huolen, että perusasiat ovat kunnossa. Näitä ovat mielestäni hakemuksen jättämisen helppous, selkeä ja avoin hakijaviestintä sekä haastatteluiden rento ilmapiiri. Näiden varaan toimintaa on hyvä rakentaa.

Jo itse työpaikkailmoituksissa pyrimme tuomaan esiin muun muassa palkkahaitarin. Haluamme olla avoimia sen suhteen, mitä kandidaatti voi odottaa tehtävän palkkauksen olevan, toki riippuen myös omasta osaamisesta. Lisäksi kandidaatin ei tarvitse täyttää kankeita useita kohtaa sisältäviä tekstikenttiä jättääkseen hakemuksen, vaan esimerkiksi pelkän LinkedIn -profiilin tiedot riittävät tähän.

Osa-alue, josta olemme kenties eniten saaneet positiviista palautteita, on selkeä ja avoin viestintä prosessin aikana. Kun kandidaatit pysyvät kartalla siitä miten prosessi etenee eri vaiheissa ilman tuskastuttavaa hiljaiseloa ja epätietoisuutta, voidaan tällä huomattavasti vaikuttaa kandidaattien kokemuksiin, kuten yllä olevat vastaukset osoittavat. Tavoitteenamme on myös edetä prosesseissa ripeällä aikataululla, joka on saanut kiitosta. Sisäisissä keskusteluissa meille on jäänyt lisäksi kuva, että rekrytointitapaamisissa on ollut mukavan rento tunnelma. Useissa palautteissa tämä nousi esiin myös kandidaattien puolelta, joka on ollut mukava huomata. Vaikka tapaamisissa esitetään puolin ja toisin välillä kiperiäkin kysymyksiä, ei itse tapaamisen tunnelman tarvitse silti olla jäykkä tai jännittynyt.

Katseet kohti tulevaa

Vuosi 2023 alkaa olemaan kohta jo loppusuoralla ja rekrytoinninkin osalta katseet alkavat olla jo vahvasti ensi vuodessa. Tarkoituksena on kehittää prosessiamme entisestään. Olemmekin palautteissa saaneet hyviä kehitysehdotuksia, missä voisimme parantaa tai mihin kenties kiinnittää jatkossa enemmän huomiota. Näitä asioita ovat olleet muun muassa vielä tarkempi kuvaus mahdollisesta tulevasta roolista yrityksessä sekä mahdollisuus oman osaamisen tuomiseen esiin vielä vahvemmin prosessin aikana, esimerkiksi erilaisten case-esimerkkien avulla.

Kaikki kehitysehdotukset ovat meille äärimmäisen tärkeitä. Rekrytointiprosessiin osallistuvat kandidaatit katsovat prosessia tuorein silmin, jolloin he voivat tuoda omia näkökulmiaan ja ideoitaan esiin, jotka saattavat jäädä rekrytointia tekeviltä henkilöiltä helpommin huomaamatta, jos he “sokaistuvat” tekemisilleen. NPS-kyselyn perusteella kuitenkin kokonaisuus rekrytointiprosessimme osalta on kunnossa ja tästä on hyvä jatkaa kohti ensi vuotta 2024.

Juho Sopanen

Talent Acquisition Specialist

Kysy konsultilta: Mikä on AWS Lambda ja FaaS?

Wed, 29 Nov 2023 06:56:30 GMT

Mikä on AWS Lambda ja FaaS?

AWS Lambda on Amazon Web Servicesin (AWS) tarjoama palvelu, joka mahdollistaa koodin suorittamisen palvelittomassa (Serverless) ympäristössä. Tämä tarkoittaa, että voit suorittaa koodiasi pilvessä ilman, että joutuisit ylläpitämään ja hallitsemaan palvelimia tai muita infrastruktuuriin liittyviä resursseja. AWS Lambdan keskeisimpiä ominaisuuksia ovat automaattinen skaalautuvuus, kustannustehokkuus ja laaja tuki AWS:n muiden palveluiden kanssa. AWS Lambda sopii muun muassa eräajoille ja tapahtumalähtöiseen arkkitehtuuriin (event-driven architecture). Palvelun laskutus perustuu suoritettujen pyyntöjen määrään ja koodin suoritusajan kokonaiskestoon.

FaaS

Function as a Service (FaaS) on pilvipalvelumalli, joka tarjoaa käyttäjilleen valmiin ympäristön koodin ajamiseen. Toisin sanoen, sen sijaan, että pyörittäisit jatkuvasti olevia sovelluksia tai palveluita, voit suorittaa koodinpätkiä vain silloin, kun niitä tarvitaan.

AWS Lambda on eräänlainen FaaS-palvelu. Se tarjoaa alustan, jossa koodi suoritetaan vastauksena erilaisiin tapahtumiin, kuten tietokantamuutoksiin, HTTP-pyyntöihin tai jopa pilvitallennustilassa olevien tiedostojen muutoksiin.

Heikki Ma

Senior Consultant

Asiakastyytyväisyys etusijalla - Uusimmat AWS-kumppanikyselyn tulokset

tero.kauhanen@webscale.fi (Tero Kauhanen) — Tue, 21 Nov 2023 20:08:31 GMT

Vahvalla asiantuntemuksella pilvi- ja ohjelmistokehityksen saralla, Webscale on jälleen saanut tunnustusta asiakastyytyväisyydessä. Vuoden 2023 AWS Partner Networkin (APN) kumppanikyselyssä saavutimme merkittävän NPS-luvun 85 , mikä on osoitus asiakkaidemme vahvasta luottamuksesta ja tyytyväisyydestä palveluihimme.

NPS, eli Net Promoter Score, on asiakastyytyväisyyden mittari, joka kertoo, kuinka todennäköisesti asiakkaamme suosittelisivat palvelujamme muille. Se lasketaan asiakkaiden antamien suosituspisteiden perusteella. Korkea NPS-luku, kuten meidän 85, on merkki siitä, että suurin osa asiakkaistamme ovat vahvoja suosittelijoita.

AWS Partner Network Customer Satisfaction

AWS Partner Network Customer Satisfaction (APN CSAT) on ohjelma, joka tarjoaa kumppaneille tietoa asiakkaiden tyytyväisyydestä ja palautteesta. Tämän ohjelman kautta saamme arvokasta palautetta asiakkailtamme, mikä auttaa meitä ymmärtämään heidän tarpeitaan ja parantamaan palvelujamme.

Tässä muutamia asiakkaidemme antamia palautteita:

"Excellent team working for us. These guys know AWS and their skills are beyond other providers we have used."
"Fast reacting, excellent competence, deep knowledge of AWS products and managed services and especially how to utilize them in creating business services, doing frameworks and processes to support a wide range of use cases in coherent manners."
"The service has always been excellent, and they respond quickly, take issues seriously and go out of their way to find solutions."
"Good knowledge of technologies. Listens to their clients needs and finds the best solution."

Oikealla tiellä - sitoutumistamme ja kykyämme reagoida nopeasti arvostetaan

Nämä palautteet ovat meille yhtiönä erittäin arvokkaita. Ne vahvistavat, että olemme oikealla tiellä ja että asiakkaamme arvostavat sitoutumistamme, ammattitaitoamme ja kykyämme reagoida nopeasti heidän tarpeisiinsa.

Palautteet auttavat meitä myös tunnistamaan alueita, joissa voimme vielä kehittyä. Vaikka NPS-lukumme on korkea, emme tyydy pelkästään nykyiseen tilanteeseen. Pyrimme jatkuvasti kehittymään, pysymään teknologian aallonharjalla ja palvelemaan asiakkaitamme entistä paremmin.

Kiitämme asiakkaitamme luottamuksesta, jonka olette meille osoittaneet. Haluamme myös kiittää koko Webscalen henkilöstöä erinomaisesta työstä ja sitoutumisesta, mikä on olennainen osa menestystämme. Olemme ylpeitä siitä, että saamme olla mukana luomassa kestäviä ja skaalautuvia digitaalisia palveluita yhdessä asiakkaidemme kanssa.

Kysy konsultilta: Mitä kaikkia Serverless-palveluita AWS:ssä on?

Mon, 20 Nov 2023 07:50:28 GMT

Mitä kaikkia Serverless-palveluita AWS:ssä on?

Aivan alkuun on hyvä kerrata, mitä Serverlessillä oikein tarkoitetaankaan. Serverless-palvelut ovat tapa rakentaa sovelluksia ja palveluita ilman että tarvitsee itse ylläpitää infraa, jossa näitä sovelluksia ja palveluita suoritetaan. Esimerkiksi backend-kehittäjä voi tällöin keskittyä huolehtimaan koodin toiminnasta ja turvallisuudesta, ja jättää käyttöjärjestelmäpäivitykset ja vastaavat palveluntarjoajan, esimerkiksi AWS:n, vastuulle.

AWS:ssä on tarjolla kattava valikoima Serverless-palveluita niin laskenta-, sovellusintegraatio-, kuin tietovarastotarkoituksiinkin. Niiden kattava läpikäynti ei ole mielekästä tämän vastauksen puitteissa, mutta esitän tässä muutamia esimerkkejä yleisimmistä AWS:n Serverless-palveluista.

Serverless-laskentaa varten AWS:ssa on Lambda-funktiot, jotka on tarkoitettu pääasiassa suhteellisten lyhyiden yksittäisten operaatioiden suorittamiseen, ja AWS Fargate konteissa suoritettavia palveluita varten. Molemmissa käyttäjän tarvitsee määrittää lähinnä koodin tarvitseman muistin ja/tai laskentatehon määrä, ja varsinaisten palvelimien hallinnointi tapahtuu taustalla automaattisesti.

Sovelluksen eri osien välistä viestintää varten AWS tarjoaa lukuisia erilaisia Serverless-ratkaisuja eri käyttötarkoituksiin. Esimerkkeinä mainittakoon EventBridge, SQS ja SNS viestien välitykseen eri tavoin ja API Gateway ohjelmointirajapintojen toteutukseen.

Myös tiedon pidempiaikainen varastointi onnistuu AWS:ssä Serverless-palveluiden varassa: tiedostojen varastointi onnistuu esimerkiksi S3:ssa tai EFS:ssä, joista jälkimmäinen on täysiveroinen tiedostojärjestelmä, jota voi helposti skaalata omien tarpeiden mukaan niin koon kuin suorituskyvynkin osalta. Tietokantapuolella Serverless-vaihtoehto on olemassa NoSQL-kannalle (DynamoDB), relaatiokannalle (Aurora Serverless), datavarastolle (Redshift Serverless) ja graafitietokannalle (Neptune Serverless).

Tämä on luonnollisestikin vain pintaraapaisu Serverless-maailmaan ja AWS tarjoaa useita muitakin Serverless-käsitteen alle kuuluvia palveluita.

Jari Avikainen

Data Engineer

Kysy konsultilta: Miten infra-komponentit kannattaa jakaa stack:eihin CDK:ssa?

Mon, 13 Nov 2023 08:13:15 GMT

Miten infra-komponentit kannattaa jakaa stack:eihin CDK:ssa?

Kuten moni muukin asia, riippuu se pitkälti siitä, miten toteutus halutaan tehdä.

Moni voisi ajatella, että samaan stackiin olisi hyvä määritellä toisistaan suoraan riippuvaiset komponentit, jotka eivät voi toimia ilman toisiaan. Tällä tavalla omasta mielestäni stackin ja stagen merkitys kuitenkin sekoittuu ja lopulta kaikki komponentit voivat päätyä samaan stackiin. Pienemmissä kokonaisuuksissa tämä ei ole välttämättä ongelma, mutta yhtään isomman järjestelmän kanssa koodi voi puuroutua ja deployment muuttua hankalammaksi.

Itse suosimani tapa määritellä komponentit on eritellä infra häilyvään ja pysyvään infraan. Pysyvä infra on tyypillisesti sellaista, jota ei missään tapauksessa saa poistaa ja joka säilöö dataa kuten Dynamo ja S3. Häilyvä infra voidaan poistaa ja deployata uudelleen ilman ongelmia, kuten Lambda ja API Gateway. Tämän erottelun jälkeen jokaiselle pysyvälle infralle voidaan tehdä oma stack. Häilyvää infraa voi määritellä samassakin stackissa, jos komponentit ovat suoraan toisistaan riippuvaisia. Esimerkiksi API Gateway ja sen taustalla pyörivät Lambdat voivat hyvin olla samassa stackissa.

Infran määrittely on kuitenkin aina tapauskohtaista ja on hyvä muistaa myös tiimissä yhteisesti sovitut konventiot.

Timo Laakso

Senior Consultant

Kysy konsultilta: Mitä ovat generaattorit JavaScriptissä?

Wed, 25 Oct 2023 11:52:17 GMT

Mitä ovat generaattorit JavaScriptissä?

Generaattorit yleisesti

Generaattorit ovat yleinen ohjelmointikielten ominaisuus. Esimerkiksi JavaScript, Python, Java, C++ ja PHP tukevat generaattoreita. Generaattorit tarjoavat yleisen ja suhteellisen helpon tavan toteuttaa iteraattorirajapinta, joka kykenee käymään läpi, siis iteroimaan datasarjan alkiot. Sarja voi olla rajallinen, mutta myös virtuaalisesti loputon.

Generaattoreita voidaan käyttää esimerkiksi listan läpikäyntiin yksi alkio kerrallaan, suorittaa välissä muuta koodia ja palata sitten tarpeen mukaan alkioiden käsittelyyn siitä kohdasta, johon viimeksi jäätiin. Tämä on hyödyllistä esimerkiksi silloin, kun alkioiden käsittely kerralla kuluttaisi liikaa muistia, tai silloin, kun vasta alkiota käsiteltäessä ratkeaa halutaanko listan iterointia ylipäätään jatkaa.

Generaattorit JavaScriptissä

JavaScriptissä generaattorifunktio tarjoaa mahdollisuuden kirjoittaa iteratiivinen algoritmi helposti funktion muodossa. Generaattorifunktion iteratiivisen osan suoritusta ei kuitenkaan aloiteta vielä generaattorin luontivaiheessa. Iterointikierroksia suoritetaan erikseen kutsumalla generaattorifunktion palauttaman generaattorin next()-metodia.

Generaattorifunktio määritetään merkitsemällä tähti function-sanan ja funktion nimen väliin. Tähden on oltava heti function-sanan perässä mikäli kyseessä on anonyymi generaattorifunktio.

Generaattorifunktio palauttaa iteroitavan iteraattoriobjektin (engl. iterable iterator), joka täyttää kaikki iteroitavan objektin vaatimukset. Huomaa, että “iterable” on eri asia kuin “iterator”, ja että molemmat ominaisuudet tarvitaan oikeaoppisen iteraattorin toteuttamiseen.

Generaattorifunktion sisään kirjoitetaan tyypillisesti yksi tai useampia yield-ilmauksia, jotka toimivat kuin return-ilmaukset sillä erotuksella, että yield-palautuksen jälkeen iteraattori muistaa sen tilan, eli funktion sisäisessä skoopissa määriteltyjen muuttujien arvot, johon se viime suorituskerralla jäi. Vaikka yield-ilmauksia olisi vain yksi, se voi palauttaa arvoja useita kertoja esimerkiksi toistorakenteen sisällä.

Merkitsemällä yield-ilmauksen perään tähtimerkintä (yield*) voidaan iteraattorin palauttama arvo halutessa delegoida toiselle iteroitavalle objektille.

Iteraattorit JavaScriptissä

Alla on esimerkki JavaScript-iteraattorin toteutuksesta. For..of-rakenne osaa käyttää mitä tahansa iteroitavaa objektia. JavaScriptissä on useita natiiveja iteroitavia objekteja kuten Array-, String- tai Map-rakenteiden instanssit.

Myös Generaattorifunktion palauttama generaattori on iteroitava objekti, jota for..of-rakenne osaa iteroida. Alla olevassa esimerkissä ei ole genraattoria eikä generaattorifunktiota, vaan iteroitava iteraattoriobjekti manuaalisesti luotuna. Generaattorifunktiot ovat apuvälineitä, joiden ansiosta meidän ei tarvitse luoda iteroitavia iteraattoreita alusta asti, koska generaattorifunktio palauttaa meille sellaisen.

Mistä tahansa objektista saadaan iteroitava (engl. iterable), kun objektilla on oikeaoppisesti toteutettu next()-metodi. Objektista tulee kuitenkin iteraattori, kun sillä on myös @@iterator-metodi.

Huom: @@-etuliite on tapa merkitä JavaScript -symboleita. Esimerkiksi Symbol.iterator voidaan merkitä @@iterator.

Yhteenveto

JavaScriptissä generaattorifunktioita käytetään luomaan generaattoreita, jotka ovat iteroitavia iteraattoreita samoin kuin monet muut JavaScript-rakenteet (esim. String- tai Array-rakenteiden instanssit). Generaattorifunktion sisällä yield-ilmaus palauttaa iteraatiokierroksen arvon, mutta yield*-ilmauksella palautus voidaan delegoida myös muulle iteroitavalle objektille. Objekti on iteraattori mikäli se toteuttaa oikeaoppisen next()-metodin. Objekti on lisäksi iteroituva, mikäli se toteuttaa oikeaoppisesti myös @@iterator-metodin.

Johan Stenroth

Consultant

Kysy konsultilta: Miten tietoturva tuodaan pilveen?

Fri, 20 Oct 2023 06:41:21 GMT

Miten tietoturva tuodaan pilveen?

Julkipilven palveluissa ja järjestelmissä toteutetaan jaettua tietoturvamallia pilvipalveluntarjoajan ja käyttäjän välillä. Tässä mallissa pilvipalvelutarjoajan vastuulla on tarjottujen palvelujen alla olevan infrastruktuurin tietoturva kuten varsinaisten konesalien, verkkojen ja virtualisointialustojen turvallisuus. Käyttäjä puolestaan on vastuussa käytettävien palveluiden konfiguraatiotasosta, jolla vaikutetaan esimerkiksi datan luokitteluun ja suojaukseen, verkkokonfiguraatioiden toteuttamiseen ja identiteetti- ja pääsyhallintaan.

Palveluiden käyttäjän on ymmärrettävä ja huolehdittava seuraavista osa-alueista osana kokonaisvaltaista pilven tietoturvaa:

Identiteetti ja pääsynhallinta (Identity and Access Management, IAM)
Tunnistautuminen, pääsynhallinta ja oikeustasomääritykset ovat oltava kyllin tarkasti ja vahvasti toteutettu pilvipalvelutarjoajan työkaluja hyödyntäen, jotta pääsy on mahdollinen vain oikeilla käyttäjillä ja riittävällä oikeustasolla. MFA- ja muut vahvan tunnistautumisen palvelut ovat arkipäivää julkipilvessä ja näitä palveluita on syytä hyödyntää.

Datan suojaus
Datan vahva suojaaminen voidaan toteuttaa niin verkko- kuin tallennuspäässä hyödyntäen vahvaa salausta esimerkiksi pilvipalvelutarjoajan KMS (Key Management System) palveluita käyttämällä.

Tiedon luokittelu ja hallinta
Tiedon (datan) luokittelulla tarkoitetaan tiedon erottamista arkaluonteisen tiedon osalta tämän perusteella tehtävien määritysten suhteen liittyen tiedon tallennukseen ja säilyvyyteen.

Haavoittuvuuksien hallinta
Pilvipalvelutarjoajat pitävät huolta palveluidensa päivityksien saatavuudesta ja esilletuonnista. Loppukäyttäjän on huolehdittava päivitysten asentamisesta ja toteutuksesta varsinaisiin pilviresursseihin.

Valvonta ja seuranta
Pilvipalvelutarjoajilla yleensä on tarjolla omia työkaluja haavoittuvuuksien ja uhkien seurantaan, jotka kannattaa ottaa käyttöön ensimmäisestä askeleesta lähtien. Erilaiset logitus- ja valvontatyökalut tarjoavat mahdollisuuksia pitää huolta turvallisuudesta ja toiminnallisuuksista pilviympäristössä.

Verkon tietoturva
Käyttäjä pitää huolta reitityksien, palomuurisääntöjen ja pääsyhallintalistojen toteutuksesta niin että tieto liikkuu pilviympäristössä ja muiden verkkojen välillä turvallisesti. Huomiota on myös syytä kiinnittää verkon hallintaan ja jakoon hyödyntäen virtuaaliverkkojen ja aliverkkojen tuomia erottelumahdollisuuksia.

Datan varmistus ja palautus
Loppukäyttäjän on huolehdittava uhkien toteutuessa siitä että tieto on varmistettu ja palautuminen on mahdollisimman tehokasta minimoidakseen vahingot. Pilvipalvelutarjoajan omat varmistus- ja palautuspalvelut näyttelevät tässä merkittävää roolia, mutta myös muita 3. osapuolen ratkaisuja on paljon saatavilla. Huomiota on kiinnitettävä myös käytäntöihin, jotta mahdollisten vahinkojen sattuessa palautuminen on mahdollista: Testauksen kuuluu olla osa kokonaisvaltaista varmistusprosessia, jossa pidetään huolta niin tekniikan kuin käytännön osalta varmistusten toimivuudesta.

Kouluttautuminen
Koulutuksen kuuluu olla osa kokonaisvaltaista tietoturvatoimintaa myös pilviympäristöissä niin että henkilöstö pystyy tunnistamaan tietoturvauhkat ja noudattamaan parhaita käytäntöjä tietoturvan suhteen.

Suuret pilvipalvelutarjoajat kuten Amazon, Microsoft ja Google ovat panostaneet valtavasti järjestelmiensä tietototurvaan ja vaatimustenmukaisuuteen. Loppukäyttäjän, joka näitä alustoja hyödyntää omien palveluiden ja ratkaisujen toteuttamiseen, on hoidettava oma osuutensa, jotta tietoturva on asianmukaisella tasolla pilviympäristössä. Tämä kaikki kiteytyy puolikuuluisaan toteamukseen “Tietoturvasta huolehtiminen on meidän jokaisen tehtävä.”

Ville Välimäki

Cloud Architect

NEVER - mistä on kyse TypeScriptin oudoimmassa tyypissä? Osa 2/2

Tue, 17 Oct 2023 06:00:53 GMT

NEVER - mistä on kyse TypeScriptin oudoimmassa tyypissä?

Blogin toisessa osassa (osa 2/2) keskitymme neverin rooliin tyyppisupistimissa (engl. type guard), unioneissa ja leikkauksissa. Lisäksi katsomme, mikä merkitys neverillä on funktioiden paluuarvon tyyppinä. Blogin ensimmäisen osan pääset lukemaan täältä .

Yleensä tulkki päättelee never-tyypin

Jotta voisimme ymmärtää never-tyypin merkityksen muuttujan tyyppinä, palataan vielä hetkeksi joukko-opillisiin käsitteisiin, kuten unioni, leikkaus (engl. intersection) ja tyhjä joukko.

Never osana unionia

Unionit määrittävät joukon tyyppejä, jotka kelpaavat muuttujan arvoksi.

New ParagraphVoiko union-tyyppien vaihtoehdoksi antaa siis myös never-tyypin? Teknisesti, kyllä voi, mutta siinä ei ole mitään mieltä, sillä kuten blogin ensimmäisessä osassa totesimme, never laajentaa jokaista muuta TypeScript-tyyppiä ja sisältyy näin ollen jo jokaiseen muuhun unionissa olevaan tyyppiin. Neverin merkitseminen unioniin on tarpeetonta ja TypeScript-tulkki pudottaa never-tyypin unionista erillisenä tyyppinä.

Alla oleva esimerkki on kuten yllä, mutta olemme lisänneet unioniin never-tyypin (rivi 1).

New Never ei esiinny TypeScript-tulkin virheilmoituksessa (rivi3), vaikka never on merkitty yhdeksi unionin tyypeistä (rivi1). Tulkki on päätellyt never-tyypin ulos unionista, koska never sisältyy jo kaikkiin muihin tyyppeihin.

Unioni voi supistua type guardeilla neveriksi

Never siis sisältyy kaikkiin unioneihin. Joissain tilanteissa unionin tyyppivaihtoehdot voivat supistua TypeScript tulkissa pelkäksi never-tyypiksi.

Tällainen tilanne on type guardilla toteutettu type narrowing -koodi, jossa ehtolausekkeet poissulkevat muuttujan mahdollisia tyyppejä siten, ettei jäljellä ole yhtäkään mahdollista tyyppiä, ja näin siitä tulee never.

Tässä esimerkissä union-tyyppiä supistetaan (engl. type narrowing) tyyppivahteina (engl. type guard) toimivilla if-ehtolauseilla.

New ParagraphEnsin “string | number”-union -tyypistä (rivi 1) supistuu ensimmäisessä if-lauseessa pois string, sitten else if -osassa number, jolloin viimeisen else-blokin sisällä muuttuja ei voi enää olla yhtäkään unionissa suoraan ilmaistua tyyppiä. Tyyppi on supistunut never-tyypiksi.

Leikkaus ja never

Leikkaus (engl. intersection) tarkoittaa joukko-opissa kahden tai useamman joukon yhteisiä alkioita, eli niitä alkioita, jotka esiintyvät kaikissa keskenään leikattavissa joukoissa. Vastaavasti TypeScript-maailmassa leikkaus tarkoittaa kahden tai useamman unionin yhteisiä tyyppejä.

Tässä “ type c” (rivi 3) on unioneiden a ja b leikkaus

Mitä jos leikkauksesta ei jääkään mitään jäljelle, eli jos keskenään leikattavilla unioneilla ei ole yhtäkään yhteistä tyyppiä? Kun leikkauksen lopputulos on tyhjä unioni, sen tyyppi on never.

Conditional type ja never

Tässä osiossa puhumme ensimmäistä kertaa tyyppitason muuttujasta, jota kutsuttakoon tässä geneeriseksi tyypiksi (engl. generics). Geneerinen tyyppi on siis tyyppimaailman muuttuja, joka kantaa mukanaan tietoa muuttujan tyypistä. Geneerisen tyypin varsinainen tyyppi määrittyy geneeristä tyyppiä alustettaessa, jonka jälkeen tyyppi säilyy geneerisen tyypin mukana missä tahansa sitä käytetäänkin. Tämä blogi ei käsittele geneerisiä tyyppejä tämän syvemmin, mutta geneerisen tyypin ajatus pähkinän kuoressa on hyvä tietää ehdollisten tyyppien esimerkkiä ymmärtääksemme.

JavaScriptissä on ehtolauseita kuten if-lauseet, jotka käsittelevät vain arvoja, eivät tyyppejä. TypeScript tuo ohjelmointiin myös tyyppejä käsittelevät ehtolauseet, jotka käsittelevät vain tyyppejä.

TypeScript-maailmassa on siis mahdollista operoida tyyppien ehtolauseilla (engl. Conditional Type).

Conditional Type -määrittelyssä käytetään geneeristä tyyppiä, sekä tyypin laajennettua versiota tarkoittavaa extends-merkintää. Katso alla olevaa esimerkkiä.

Yläpuolen esimerkki määrittää Conditional Typen avulla tyypin HasFourLegs. Tyypille annetaan geneerisenä tyyppinä Animal. Tyypin ehto-osassa tehdään päätelmä: jos geneerisenä tyyppinä annetulla tyypillä on property “legs: 4”, eli toisin sanoen, jos Animal on laajennus { legs: 4 } -tyypistä, Animal-tyyppi täyttää tyypin HasFourLegs ehdollisen tyypityksen kriteerit.

Huomaathan, ettei tyyppiehtolause tarkasta, onko Animal oikeasti tyyppiä Animal. Vaikka ehtolause päätyisi never-osaan, Animal-tyyppi on edelleen Animal-tyyppiä. Animal-tyyppi ei vain silloin ole tyypin { legs:4 } laajennus. Huomaathan myös, ettei numero 4 ole tässä tapauksessa arvo, vaan TypeScriptin literaalityyppi. Arvot ovat JavaScriptiä, tyypit puolestaan ovat TypeScriptiä mukaan lukien literaalityypit. Tämä olisi kenties helpompi huomata, jos laajennetestissä tarkistettaisiinkin laajennusta esimerkiksi tyypille { legs: number }. Sekä number, että literaalityyppi 4 kuuluvat tyyppimaailmaan.

Esimerkissä määritellään union tyyppi Animals. Tämän jälkeen määritellään tyyppi FourLegs, johon kohdistetaan tyyppisupistus (Type Narrowing) Conditional Typen avulla. FourLegs-tyypin unioniin päätyvät ainoastaan HasFourLegs Conditional Typen ehdon täyttävät Animals-uniontyypin unionialkiot, eli kaikki ne alkiot, jotka olivat laajennuksia objektille { legs: 4 }.

FourLegs-tyypiksi tulisi never, mikäli Animals-unionissa ei olisi yhtään Conditional Type -ehdossa määritettyä alkiota.

Sekavaa? Ei huolta, ehdolliset tyypit eivät ole TypeScriptin joka päiväisiä rakennuspalikoita. Oikeastaan kaikkein hyödyllisintä lienee tunnistaa Conditional Typet geneeristen tyyppien ja extends-ilmaisujen avulla jonkun toisen kirjoittamasta koodista ja ymmärtää siitä mitä koodissa tapahtuu.

Never funktion paluuarvon tyyppinä

Funktion paluuarvon tyyppinä never tarkoittaa funktiota, joka ei koskaan suoriudu loppuun asti.

Tällaisia tapauksia on kaksi:

funktio jää ikuiseen kiertoon
funktio päätyy aina virheeseen

Void on eri tyyppi ja eri asia kuin never

Kun funktio ei palauta mitään, sen tyypiksi voidaan asettaa void.

Kun funktio ei palauta mitään joko tyhjän tai puuttuvan return-ilmauksen vuoksi, sen paluuarvon tyyppi on void. Palauttamattomuus on kumminkin eri asia kuin se, ettei funktio koskaan pääse loppuun asti. Jos funktio jää jokaisella suorituskerralla ikuiseen kiertoon tai jos funktio jokaisella suorituskerralla päätyy virheeseen, on funktion paluutyyppi aina never.

Alla oleva funktio jää aina ikuiseen kiertoon, joten sen paluutyyppi on never.

Alla oleva funktio päätyy jokaisella suorituskerralla virheeseen, joten sen paluutyyppi on never.

Entä jos funktio pääsee joskus loppuun ja joskus taas ei? Voiko paluutyyppi olla esimerkiksi number | never ? Teknisesti näin voisi kirjoittaa, eikä TypeScript-kääntäjä huomauttaisi virheestä. number | never funktion paluutyyppinä ei kuitenkaan olisi mielekästä, sillä kuten olemme todenneet, kaikki tyypit ovat jo valmiiksi never-tyypin laajennuksia. TypeScript-tulkki supistaa tyypin automaattisesti number-tyypiksi.

Joten mikäli funktio kykenee joissain tapauksissa palauttamaan jonkin arvon, sen tulkittu paluuarvo ei koskaan ole never. Sillä ei ole merkitystä, voiko funktio joskus jäädä myös ikuiseen kiertoon tai jos se voi joskus päätyä virheeseen. Mikäli loppuun pääsy ei ole estynyt jokaisella suorituskerralla, funktion paluutyyppi ei voi olla never.

isHeads()-funktion paluutyyppi on boolean siitä huolimatta, että funktio voi joskus jäädä ikuiseen kiertoon. Paluutyypin merkitseminen boolean | never -tyypiksi olisi mahdollista, mutta tarpeetonta.

Kiitos kun luit blogini NEVER - TypeScriptin oudoin tyyppi osat 1 & 2! Tässä oli paljon asiaa ja käsittelimme useita TypeScript-konsepteja, jotka tavalla tai toisella, etäisestikin, liittyivät never-tyyppiin. TypeScript sisältää paljon enemmän ominaisuuksia ja konsepteja, kuin mitä on välttämätöntä osata ja tunnistaa, jotta voisi kirjoittaa hyvää TypeScript-koodia.

Johan Stenroth

Consultant

Kysy konsultilta: Miksi AWS:lla on eri regioonia?

Fri, 13 Oct 2023 09:40:42 GMT

Miksi AWS:lla on eri regioonia?

AWS:ssä Region koostuu yhdelle maantieteelliselle alueelle ryhmitetyistä erillisistä datakeskuksista. Regionin datakeskukset muodostavat yhden erittäin vikasietoisen kokonaisuuden.

Regionin ajatus on tuoda data ja laskentakapasiteetti lähelle asiakasta. Jos asiakkaita on ympäri maailmaa, voi heitä parhaiten palvella tuottamalla palveluita lähimmissä Regionissa. Eri Regioonia koskee myös kansalliset ja alueelliset lait ja vaatimukset, esimerkiksi EU GDPR (General Data Protection Regulation) rajoittaa EU-kansalaisten datan siirtoa EU:n alueen ulkopuolelle jääviin Regiooniin.

Region vaikuttaa myös AWS-palveluiden hinnoitteluun ja saatavuuteen. Kaikki palvelut on hinnoiteltu erikseen Region-kohtaisesti. Kaikissa Regioonissa ei myöskään ole aina saatavilla kaikkia AWS:n palveluita.

Juho Rautio

Principal Consultant

NEVER - mistä on kyse TypeScriptin oudoimmassa tyypissä? Osa 1/2

Thu, 12 Oct 2023 05:53:59 GMT

NEVER - mistä on kyse TypeScriptin oudoimmassa tyypissä?

TypeScript tuo tyypitykset JavaScriptiin

TypeScript on Microsoftin kehittämä JavaScript-laajennus, jonka keskeisin hyöty on tarjota vahva tyypitys koodin kehitys- ja käännösvaiheeseen, jotta ajonaikaiset tyypityksiin liittyvät ongelmat tulisivat etukäteen minimoiduiksi.

TypeScriptillä on tyyppi jokaiselle kahdeksalle JavaScriptissä määritellylle primitiivityypille , jotka ovat string, number, bigint, boolean, object, null, undefined ja symbol. TypeScript-tyypit tukevat myös tuttuja JavaScript-rakenteita, kuten listoja, objekteja ja Map-rakennetta. Lisäksi TypeScript tukee erikoisempia tyyppitapauksia kuten any, unknown ja never .

TypeScript on ennen kaikkea apuväline paremman JavaScript-koodin tuottamiseen ja vain hyvin rajatuissa käyttötapauksissa TypeScript-koodista jää mitään jäljelle käännettyyn JavaScript -koodiin.

Never on outo tyyppi

Never on puolestaan TypeScriptin oma primitiivityyppi, joka tuotiin kieleen version 2.0 mukana. Tätä kirjoitettaessa TypeScript on saavuttanut version 5.2.

Never -tyypillä on oma merkityksensä muuttujien ja funktioiden paluuarvojen tyyppinä. Muuttujien yhteydessä never edustaa sellaista koodin osaa, jota ei voida koskaan saavuttaa. Funktioiden paluuarvojen yhteydessä puolestaan never edustaa funktiota, jota ei voida koskaan suorittaa loppuun saakka. Perehdymme never -tyyppisten muuttujien ja funktion paluuarvojen ominaisuuksiin tarkemmin myöhemmin blogissa.

Never on TypeScript-maailman outo tyyppi, joka edustaa jokaisen muun tyypin alityyppiä, mutta ainoastaan never itse voi olla never -tyypin alityyppi. Tästä pian lisää tyyppien laajenteita käsittelevän otsikon alla.

Kehittäjän tarvitsee vain harvoin kirjoittaa never -tyyppi itse koodiin. Sen sijaan, useimmiten never -tyyppi on vain TypeScript-tulkin tekemä lopputoteamus siitä, ettei muuttujaa käsittelevä koodilohko ole TypeScript-kääntäjän ymmärryksen mukaan saavutettavissa. Tämä voi esimerkiksi auttaa kehittäjää huomaamaan koodissa osia, johon suorittavan koodin on loogisesti mahdotonta päästä.

Kaikki TypeScript-tyypit ovat neverin laajenteita

Joukko {‘A’} on joukon {‘A’, ‘B’, ‘C’} osajoukko. Näin ollen joukon {‘A’, ‘B’, ‘C’} voidaan sanoa laajentavan (engl. extend) joukkoa {‘A’}, koska joukon {‘A’} kaikki alkiot sisältyvät joukkoon {‘A’, ‘B’, ‘C’}. Identtiset joukot ovat osajoukkoja itselleen, joten esimerkiksi joukko {‘A’} on joukon {‘A’} osajoukko.

Samalla tavalla tyyppien maailmassa voidaan esimerkiksi sanoa tyypin string laajentavan literaalityyppiä “foo” , koska tyyppi string sisältää kaikki mahdolliset merkkijonovariaatiot.

Never puolestaan sisältyy vaivihkaa kaikkiin muihin tyyppeihin, koska kaikki tyypit ovat never -tyypin laajennuksia. Toisin sanoen, TypeScript-maailmassa kaikki tyypit laajentavat never -tyyppiä. Myös never itse laajentaa itseään. Never on vähän kuin tyhjä joukko joukko-opissa, sillä tyhjä joukko on kaikkien muiden joukkojen osajoukko.

TypeScript-maailmassa operoidaan joukko-opillisilla konsepteilla. Esimerkiksi, jos haluamme kirjoittaa rajapinnan (engl. interface), joka laajentaa jo olemassa olevaa rajapintaa, voimme kirjoittaa sen käyttäen TypeScriptin extends-ilmaisua.

Muutama hyödyllinen TypeScript-konsepti

Type Narrowing & Type Guard

Sen lisäksi, että TypeScript-tulkki osaa tulkita JavaScripin ajonaikaisia staattisia tyyppejä, se osaa tulkita myös koodin suoritusta ohjaavia rakenteita, kuten if/else, ternary-operaattori, toistorakenteita ja totuustarkistusoperaattoreita.

Näissä koodin ohjausrakenteissa mahdollisten tyyppien kirjo saattaa supistua (engl. type narrowing). Tyyppien kirjon supistuminen tapahtuu ns. tyyppiä vartioivassa osassa (engl. type guard).

TypeScript ymmärtää useita Type Narrowing -rakenteita. Yksi yleinen rakenne on JavaScriptin typeof-operaattori.

Esimerkkikoodin padding-muuttuja voi olla tyyppiä number tai string . Repeat-metodi on olemassa ainoastaan number -tyyppisille muuttujille, mutta se on TS-tulkille okei, sillä if-lauseen type guard varmistaa, että if-blokin sisällä padding-muuttuja on aina number-tyyppiä.

Type predicate function

Joskus type guardin logiikaksi tarvitaan monimutkaisempaa koodia, jota TypeScript ei kykene automaattisesti päättelemään. Tällaisessa tapauksessa voimme luoda oman funktion tekemään päätelmä ja kertoa TypeScriptille, minkä type guard -päättelyn funktio toteuttaa. Tällainen funktio on nimeltään Type Predicate Function.

Kehittäjän on oltava tarkkana, jotta funktio todella tekee juuri oikean tyyppitarkistuksen, sillä kuten todettua, TypeScript ei funktion sisäistä logiikkaa kykene tarkastamaan, vaan uskoo täysin sen, minkä tyyppitarkastuksen kehittäjä väittää TypeScriptille funktion toteuttavan.

Type Predicate Function palauttaa aina boolean -arvon ja tyypin tarkistuksen tiedot välitetään TypeScriptille funktion palautustyypin merkinnän yhteydessä, johon ei tällä kertaa merkitäkään boolean , vaan muoto “[funktion parametrin nimi] is [tyypin nimi]”. Katso esimerkki alta.

Funktion logiikassa tarkastetaan, onko pet-muuttujalla property swim. Jos swim-property on olemassa, tiedämme pet-muuttujan olevan tyyppiä Fish ja funktio palauttaa boolean -arvon true. Nyt käyttämällä funktiota koodissa, TypeScript osaa suhtautua funktioon Type Guardina.

Exhaustiveness checking & never

Switch-case-rakenteessa on mahdollista toteuttaa never -tyypin avulla union -tyypin perinpohjainen alityyppien läpikäynnin tarkastus (engl. exhaustiveness checking).

Tiedämme jo useita tapoja miten union-tyyppisten muuttujien jäljellä olevia tyyppivaihtoehtoja voidaan supistaa (engl. narrow) type guardien avulla esimerkiksi typeof-operaattorilla tai Type Predicate Functionin avulla.

Kun haluamme kuitenkin erikseen varmistaa TypeScriptin avulla, että onhan kaikki tyyppivaihtoehdot nyt läpi koluttu, voimme tehdä tämän tarkistuksen merkitsemällä muuttujan never -tyypiksi. Jos TypeScript hyväksyy never -tyypin, unionilla ei ole enää yhtäkään tyyppivaihtoehtoa jäljellä ja muuttujan tyypit on käsitelty Type Guardeille läpikotaisin, eli sille on toteutettu “exhaustive type checking”. Katso esimerkki alta.

Koska TypeScript hyväksyy never-tyypin, tyypin exhaustiveness (tai ts. tyypin läpikotaisuustarkistus) on onnistunut, sillä myös TypeScript on sitä mieltä, ettei Shape-tyypin unionilla ole default-blokin sisällä enää yhtäkään mahdollista tyyppiä jäljellä, jota aiemmat type guardit (rivit 5 ja 7) eivät olisi jo poissulkeneet.

Never-tyyppistä arvoa ei ole olemassa

Muuttujan tyypiksi on sallittua asettaa never, mutta never-tyyppiselle muuttujalle emme voi asettaa mitään arvoa.

Mikään arvo, kuten esimerkiksi undefined , ei ole sallittu arvo never -tyyppiselle muuttujalle. Never on puhdas TypeScript-maailman tyyppi ja konsepti, eikä JavaScript-maailmassa ole never -tyyppisiä arvoja.

Kiitos kun tutustuit never -blogin ensimmäiseen osaan. Seuraavassa osassa (osa 2/2) keskitymme neverin rooliin tyyppisupistimissa (engl. type guard), unioneissa ja leikkauksissa. Lisäksi katsomme, mikä merkitys never illä on funktioiden paluuarvon tyyppinä.

Nähdään toisessa osassa!

Kysy konsultilta: Mitä eroa on AWS:n EKS ja ECS -palveluilla?

Tue, 03 Oct 2023 10:12:06 GMT

Mitä eroa on AWS:n EKS ja ECS -palveluilla?

EKS (Elastic Kubernetes Service) ja ECS (Elastic Container Service) ovat molemmat AWS:n tarjoamia palveluita kontitettujen sovellusten ajoa ja hallintaa varten. ECS tarjoaa yksinkertaisemman ja helppokäyttöisemmän alustan sovelluksille, kun taas EKS tarjoaa täysikasvuisen Kubernetes ympäristön, jossa on AWS:n hallinnoima Control Plane (CP) helpottamaan klusterin käyttöönottoa ja hallintaa.

Niin EKS:n kuin ECS:n päällä suoritettavia työkuormia voi ajaa itsehallinnoitavissa (self-managed) EC2 instansseissa, jolloin instanssityypit ja muut infrastruktuurin määritykset pitää hoitaa itse. Molemmille palveluille on myös tarjolla “serverless” Fargate versiot, jolloin käyttäjä määrittää vain resurssit (cpu ja muisti) konteille ja AWS pitää huolen alla olevan infrastruktuurin provisoinnista sekä hallinnasta. EKS työkuormia on mahdollista suorittaa myös omassa on-prem datakeskuksessa EKS Anywhere palvelun myötä.

Yleisesti ottaen ECS soveltuu hyvin tilanteisiin, joissa halutaan suhteellisen yksinkertainen palvelu pystyyn pienellä vaivalla eikä tarvita Kuberneteksen ominaisuuksia. EKS on mainio vaihtoehto monimutkaisemmille sovelluksille ja klustereille, joissa halutaan hyödyntää Kuberneteksen monia ominaisuuksia, kuten esimerkiksi joustavuutta resurssien provisointiin (scheduler). Lisäksi Kubernetes tarjoaa monipuolisen ekosysteemin ja suuren valikoiman sen ympärille rakennettuja työkaluja, joista suuri osa on vapaasti saatavilla open sourcena.

K alle Soranko

Senior Consultant

Kysy konsultilta: CDK ja CloudFormation ovat molemmat IaC-työkaluja, miten ne eroavat toisistaan?

Thu, 28 Sep 2023 05:25:26 GMT

CDK ja CloudFormation ovat molemmat IaC-työkaluja, miten ne eroavat toisistaan?

Molemmat ovat AWS:n tarjoamia IaC (Infrastructure as Code) työkaluja, joista CDK (Cloud Development Kit) on uudempi. CloudFormation on alemman tason työkalu, millä voi kirjoittaa infraresursseja deklaratiivisesti JSON- tai YAML-formaatissa. CDK taas on korkeamman tason työkalu, millä infraa voi kirjoittaa samoilla tutuilla ohjelmointikielillä kuin sovelluskoodia, kuten TypeScript, Python, Java ja .NET.

CloudFormationissa jokainen luotava infraresurssi täytyy määritellä erikseen, mikä on aikaa vievää, mutta selkeää. CDK tarjoaa avuksi valmiita komponentteja, joiden avulla pystyy luomaan yksittäisiä resursseja tai isompiakin kokonaisuuksia nopeasti pienemmällä määrällä koodia. Omia uudelleenkäytettäviä komponentteja voidaan myös toteuttaa ja jakaa eri tiimien käyttöön. Myös CDK käännetään (tai syntetisoidaan) lopulta CloudFormation-muotoon käyttöönottovaiheessa, minkä takia CloudFormationin tunteminen auttaa ymmärtämään myös mitä CDK tekee.

Mika Catani

Senior Consultant

Kysy konsultilta: Mikä on GitOps malli?

Thu, 21 Sep 2023 07:17:27 GMT

Mikä on GitOps malli?

GitOps-mallissa Git-versionhallintajärjestelmä toimii infrastruktuurin tai sovelluskonfiguraation ainoana totuuden lähteenä (engl. Single Source of Truth). Muutokset viedään käyttöön automaattisesti joko CI/CD-pipelinen tai tähän synkronointiin tarkoitetun ohjelmiston avulla. GitOps-malli on yleistynyt erityisesti IaC-työkalujen (infrastruktuuri koodina) yleistymisen myötä. Suurimpia hyötyjä tästä mallista ovat automaattinen versiointi, muutosten jäljitettävyys sekä tavoitetilan ja todellisen tilan välisen muutoksen (engl. drift) havainnointi.

Antti Elonheimo

Senior Consultant

Nordic Software Summit 2023

Tue, 19 Sep 2023 09:20:01 GMT

Esitys tekoälystä - Googlen kanta

Tekoäly muuttaa IT-alaa merkittävästi, mutta kehittäjää se ei korvaa, sillä tekoäly ei kykene ymmärtämään ohjelmistokehitystä kokonaisuutena.

Large Language Model (LLM) tarkoittaa luonnollista kieltä prosessoivaa (engl. Natural language Processing, NLP) tekoälyalgoritmia, jota on koulutettu mittavalla datamäärällä, ja joka kykenee tunnistamaan, muuntamaan, ennustamaan ja tuottamaan tekstiä sekä muuta sisältöä.

Kuluttajien ja yritysten käyttötarpeet tekoälylle eroavat toisistaan. Yritysmaailmassa LLM mahdollistaa yrityksen tuottamiin omiin suuriin datamääriin kohdistuvien kysymysten esittämisen ihmisten ymmärtämällä luonnollisella kielellä. Siinä missä aikaisemmin dataa on seulottu esimerkiksi SQL:llä, nyt yrityksessä voidaan esimerkiksi kysyä LLM:ltä “montako vähintään 100€ tuotetta on myyty tammikuussa 2023, jossa maksutapana on ollut luottokortti?”

Generative AI, eli sisältöä luova tekoäly on oma tekoälykonseptinsa, jolla voidaan tuottaa tekstiä, kuvaa, videota ja jopa musiikkia. Google esimerkiksi on tuonut tekoälyn luoman sisällön tukea useisiin palveluihinsa kuten gmailiin, docsiin ja presentaatioihin.

Esitys koodaamisesta tekoälyn avulla

New ParagrOsallistuin esityksen seuraamiseen, jossa opastettiin tekoälyn hyödyntämistä koodauksessa. Demossa tavoitteena oli luoda ChatGPT:llä (versio gpt-3.5-turbo) python koodi, joka tuottaa ihmisvalokuvasta passiin sopivan kuvan. Valokuvasta täytyi siis tunnistaa ihmiskasvot, rajata sopiva alue ja poistaa tausta kasvojen ympäriltä.

Yleisohjeena, tekoälyltä ei kannata pyytää koko projektia yhtenä koodirimpsuna, vaan jakaa ohjelmalliset operaatiot itse ensin osiin ja pyytää tekoälyltä sitten eri toimintoja suorittavat moduulit, sekä pääohjelma, joka käyttää moduuleja tuottamaan halutun lopputuloksen.

Tekoälylle esitetty pyyntö ei välttämättä tuota haluttua lopputulosta ensimmäisellä yrittämällä ja omaa tavoitettaan voi joutua täsmentämään tekoälylle pariin otteeseen. Kuten tavanomainenkin ohjelmointiprosessi, ohjelmointi tekoälynkin kanssa on iteratiivinen.

Hyvään lopputulokseen pääsee, kun ymmärtää AI:n kieltä eli promptausta, käyttää sopivaa AI-mallia, tietää mitä on oikeastaan luomassa ja pitää laajuuden kohtuudessa.

Esityksen demo onnistui hyvin ja ajettaessa python-koodi toteutti tekoälylle esitetyt tavoitteet.

Oma tekoälykokeilu esitysten välissä

Edellä mainitun tekoälykoodausesityksen innoittamana vetäydyin väliajalla hotelliaulaan kokeilemaan omaa tekoälykoodidemoa. Esityksen tapaan käytin ChatGPT:tä, mutta tällä kertaa luodakseni node.js -koodin, joka tuottaa kuvasta käänteisväriversion.

Pyysin ChatGPT:ltä suomeksi sanatarkasti seuraavaa:

“ Kehitä minulle node.js koodi, jota voi kutsua komentoriviltä ja antaa komentoriviparametrinä png-kuvatiedoston nimen. Koodi tallettaa samaan sijaintiin alkuperäisen kuvan kanssa uuden kuvan, jossa on käänteiset värit. Uuden kuvan nimeksi tulee vanhan kuvan nimi, johon on lisätty osa "-inverted-colours". Esimerkiksi jos alkuperäinen kuva on image.png, uuden kuvan nimi olisi "image-inverted-colours.png ”

Näin ChatGPT aloitti vastauksensa (pitkää vastausta on leikattu tarkoituksella):

ChatGPT loi sharp -kuvamuokkauskirjastoa hyödyntävän koodin ja antoi sille komentorivitason suoritusohjeet. Tallensin koodin tiedostoon, asensin samaan kansioon npm:llä sharp-kirjaston. Samaan kansioon talletin myös logo.png -tiedoston. Koodi loi logosta käänteisväriversion juuri kuten pitikin.

Esitys RoadMap:in laatimisesta yrityksille

Olin valinnut RoadMap -esityksen omaan seurantaohjelmistooni. Sitä seurattiin kuulokkeet päässä, jotta samassa tilassa oleva yleisö saattoi seurata yhtäaikaisesti itselle sopivaa esitystä.

Monissa yrityksissä katsotaan ensiksi uutta teknologiaa ja mitä sillä voisi tehdä. Lähestymistapa on yleensä kehno, sillä teknologian uutuus ei ole tae kannattavasta liiketoiminnasta. Laadukas RoadMap keskittyy arvonluontiin ja lopputuloksiin. Lisäksi RoadMap on erilainen eri yleisöille, kuten asiakkaalle ja muille sidosryhmille.

New ParRoadMap on myös iteratiivinen ja “oppiva”, eikä sen kuulukaan olla kiveen hakattu. Yleisiä sudenkuoppia RoadMapin laadinnassa ovat epäselvä priorisointi, prosessia ei ole määritelty, ei linjassa sidosryhmien tarpeiden kanssa ja ns. kiiltävän objektin syndrooma (engl. Shiny Object Syndrome, SOS) jossa fokus siirtyy jatkuvasti uusiin asioihin ilman että nykyinen tekeminen saadaan saatettua loppuun.

Esitys tietoturva-asioista

Tässä esityksessä kerrottiin kuuluisista ja vähemmänkin tunnetuista tietomurroista sekä kuuluisuuksien kohua herättäneistä salasanavalinnoista.

Esitys alkoi tapaus SolarWindillä, jossa yhtiön github -repository oli jäänyt avoimeksi. Lisäksi repossa oli ollut kovakoodattuja salasanoja. Eräs salasana oli ollut “ solarwinds123 ”. Hakkeri onnistui laittamaan omaa koodiaan SolarWindin repositoryyn, josta koodi provisioitui SolarWindin asiakkaiden järjestelmiin asti.

Esityksessä kerrottiin esimerkkejä julkisuuden henkilöiden tietoturvahaasteista. Venäläisen cozybear -hakkeriryhmän oli onnistunut huijata pääsyn Hillary Clintonin email -tilille Googlen lähettämäksi tekaistulla “joku on saanut salasanasi” -emaililla. Donald Trumpin salasana Twitteriin oli ollut joskus “yourefired”, jonka paljastumisen jälkeen salasanaksi oli vaihdettu “maga2020!”. Mark Zuckerbergin salasana Twitteriin, Instagramiin ja Pinterestiin oli ollut yhtä aikaa “dadada”.

Esityksessä kerrottiin myös deepfake -puhelinsoitosta, jossa valeääni esiintyi yrityksen johtajana ja yritykseltä onnistuttiin viemään 200 000€.

Esityksen kolme opetusta tietoturvaan:

Ethän käytä yrityksen nimeä salasanoissa
Käytä Multi Factor Authenticationia (MFA)
Muista että partnereidesi heikko tietoturva voi olla sinun tietoturvasi heikoin lenkki

Loppusanat

Vietin mukavan ja opettavaisen reissun Nordic Software Summit -tapahtumassa. Matkani sponsoroi Webscale ja webscalereille kuuluva koulutusbudjetti, johon sisältyy kahdeksan kouluttautumiseen käytettävää päivää vuodessa.

Töihin Webscaleen?

Kiinnostaisiko sinua liittyä tiimiimme? Lue lisää rekrysivuiltamme . Kuulemme mielellämme tarinasi ja otamme selvää, olisimmeko me sinulle oikea työnantaja.

Kysy konsultilta: Mitä hyötyä on pariohjelmoinnista?

Wed, 13 Sep 2023 06:41:55 GMT

Mitä hyötyä on pariohjelmoinnista?

Pariohjelmointi (eng. “pair programming”) on työskentelytapa, jossa kaksi ohjelmoijaa istuvat yhdessä saman tietokoneen ääressä tehden yhteistyötä siten, että toinen kirjoittaa koodia toisen katsellessa. Tällä pyritään parantamaan kehitettävän ohjelmiston laatua, sillä mahdollisissa ongelmatilanteissa kaksi ohjelmoijaa voivat ratkoa ongelmaa yhdessä välittömästi.

Toinen yleinen peruste pariohjelmoinnin käyttämiselle on tietouden (niin kehitettävän ohjelmiston kuin yleisimpien käytäntöjen ym. suhteen) ja osaamisen tehokkaampi jakaminen tiimien ja työyhteisöjen sisällä, kun kehittäjät näkevät toistensa tapoja ratkoa eteentulevia ongelmia.

Juha Mustajärvi

Full Stack Developer

Kysy konsultilta: Miten valita oikea tietokanta?

Wed, 06 Sep 2023 10:37:21 GMT

Miten valita oikea tietokanta?

Tietokannat ovat datan ja informaation varastointiratkaisuja. Kannat palvelevat lukuisia eri käyttötarpeita ja niitä voidaan pystyttää itse tai ostaa valmiina pilvipalveluna.

Kun kaikkia ominaisuuksia ei voi saada samassa paketissa, kehitystiimin haasteeksi jää valita sopivin kompromissi datan sijoituspaikaksi. Valintaa tehdessä tulee ottaa huomioon lukuisia seikkoja, kuten datan formaatti, datan luku- ja kirjoitusintensiivisyys sekä ratkaisun budjetti. Yhden vaihtuvan numeron - esimerkiksi viimeisin lämpötila ilman historiatietoja - tallennukseen voi riittää yksinkertainen kirjoitus tiedostoon. Taulukkomaiseen dataan, jossa on relaatioita muihin taulukoihin, voi toimia perinteinen SQL-kyselykieltä tukeva relaatiokanta, kuten PostgreSQL. Entäpä jos data sisältää runsaasti mielivaltaisia relaatioita? Tällöin datasi muodostaa graafin ja oikea ratkaisukin voi löytyä graafikannoista, kuten neo4j tai Amazon Neptune.

Tarvitsetko datatallennuksillesi ACID -periaatteet toteuttavan transaktiotuen, eli mahdollisuuden toteuttaa useampi tietokantaoperaatio atomisena ja mahdollisuutena peruuttaa kaikki transaktion sisäiset operaatiot yhdenkin operaation epäonnistuessa? Hyvinkin eri tyyppiset kannat voivat tukea transaktioita. Mikropalveluarkkitehtuurissa saatat joutua simuloimaan epätäydellistä transaktiotukea arkkitehtuuritasolla, sillä arkkitehtuurin mukaisesti mikropalvelut sisältävät yleensä omat tietokantansa, eikä niiden välinen aito transaktiotuki ole mahdollista.

Erityisempiin datatarpeisiin saatat tarvita juuri tiettyyn tarkoitukseen suunnitellun tietokannan. Niin kutsuttuja “purpose built” -tietokantoja saatat tarvita esimerkiksi IoT-laitteen tuottamalle datalle, jollainen on esimerkiksi AWS Timestream. Lohkoketjumaiseen dataan saattaisi sopia puolestaan Amazon Quantum Ledger Database.

Omia datatarpeita voi kartoittaa laatimalla käyttöskenaarioita esimerkiksi käyttäjätarinoiden (engl. user story) avulla ja kartoittaa, miten skenaariot dataasi käsittelevät. Joihinkin tietokantoihin joudut suunnittelemaan myös erillisiä indeksejä hakujen optimoimiseksi. Haku, jonka tulokset saa aluksi jouhevasti, voi hidastua merkittävästi datamäärän kasvaessa ilman sopivaa indeksointia. Mitkä datan varastointi-, kirjoitus- ja hakutarpeesi ikinä ovatkaan, ratkaisua ei kannata toteuttaa hutaisten, sillä järjestelmään jo integroidun, vääräksi havaitun kannan vaihtaminen toiseksi voi olla työlästä ja siten kallista.

Johan Stenroth

AWS Consultant

Kysy konsultilta: Mitä IaC tarkoittaa ja mitä hyötyä siitä on?

Wed, 30 Aug 2023 08:31:48 GMT

Mitä IaC tarkoittaa ja mitä hyötyä siitä on?

IaC, Infrastructure As Code, tarkoittaa pilvi-infrastruktuurin määrittelemistä koodina. Koodissa määritellään tarvittavat resurssit kuten virtuaalipalvelimet ja niiden konfiguraatio, kuormanjako, verkkoyhteydet sekä niiden suojaukset, pääsyoikeudet yms. Yleensä IaC-koodi tallennetaan johonkin versiohallintaan kuten GitLab, GitHub tai Bitbucket.

Infrastruktuurin määrittely koodina auttaa dokumentoimaan mitä kaikkea ympäristöön sisältyy ja helpottaa muutosten testaamista sekä jäljittämistä. Versiohallinnassa voidaan tehdä muutoksille hyväksyntäprosessi ja nähdä esimerkiksi kuka muutokset on tehnyt. Koodissa voi helposti myös dokumentoida miksi jotain on tehty. IaC-työkalut voivat myös helpottaa ympäristön rakentamisen rutiinitoimenpiteissä, esimerkiksi AWS:n CDK osaa yleensä rakentaa tarvittavat pääsyoikeudet automaattisesti. Koodina voi myös olla valmiita kirjastoja tyypillisiin käyttötarkoituksiin kuten vaikkapa AWS CDK:n ApplicationLoadBalancedFargateService, jolla pystyy rakentamaan kuormanjaolla varustetun www-container -palvelun hyvin vähäisellä määrittelyllä ilman, että se rajoittaa mahdollisuuksia laajentaa ympäristöä. Vastaavantyyppisiä kirjastoja pystyy myös tekemään itse oman yrityksen käytäntöjen ja vaatimusten mukaan. Näillä saadaan myös yhtenäistettyä koko yrityksen käytäntöjä.

Versiohallintaan yhdistettynä IaC mahdollistaa ympäristön muutosten viemisen tuotantoon automaattisesti sekä toistettavasti samanlaisena kehitys-, testaus- ja tuontantoversioon. IaC:llä on myös helposti tehtävissä vaikka joka kehittäjälle tai tiketille oma rajattu testausympäristönsä. Kehitysympäristöjä voidaan ajaa ainoastaan työpäivän ajan tai jos projekti ei ole aktiivisessa kehityksessä voidaan kehitys- ja testausympäristöt ajaa kokonaan alas ja saada ne tarvittaessa pitkänkin ajan jälkeen helposti uudelleen käyttöön.

IaC voi myös helpottaa ympäristön siirtoa pilvipalveluntarjoajalta toiselle. Kun tuotantoympäristön elinkaari päättyy, IaC auttaa jäljittämään resurssit ja oikein tehtynä kaiken pystyy poistamaan kerralla eikä ympäristöihin jää häntiä aiheuttamaan myöhempää ihmetystä tai kustannuksia. Tunnetuimpia IaC-työkaluja ovat useissa ympäristöissä toimivat Terraform ja uudempana tulokkaana Pulumi, ja pilvikohtaisena AWS:n CloudFormation ja CDK, Azuren Bicep ja ARM sekä Googlen Cloud Deployment Manager. Myös Kubernetes Helm chartit voidaan laskea IaC:ksi.

Tuomas Eerola

Senior Cloud Architect

Saavutettavuus ei ole salatiedettä: CPACC-sertifikaatin hankkiminen muutti näkemykseni suunnittelusta

Mon, 28 Aug 2023 06:57:24 GMT

Web-kehittäjänä saavutettavuuteen ei voi olla törmäämättä. Selaimen kehitystyökalu ilmoittaa heikosta kontrastista ja lintteri valittaa puuttuvasta alt-attribuuttista. MDN:stä ja W3.org:sta löytyy ohjeita saavutettavan sovelluksen toteuttamiseen, mutta aiheeseen ei yleensä syvennytä vaatimusten läpäisyä pidemmälle. Miksi kontrastilla on väliä ja mihin kaikkeen alt-attribuuttia käytetään? Halusin ymmärtää, mistä saavutettavuusohjeet ovat lähtöisin ja miksi ne ovat tärkeitä. IAAP-järjestön CPACC-sertifiointi tarjosi kattavan kokonaisuuden vammaisuudesta, toimintarajoitteista ja ihmisten arjessaan kohtaamista esteistä. Esittelen tässä blogitekstissä sekä järjestöä että sertifikaattia ja avaan hieman omaa opintopolkuani.

Mutta mitä se saavutettavuus edes on? Termi ei välttämättä ole kaikille tuttu, joten tässä nopea määritelmä sovelluskehityksen näkökulmasta: saavutettava sovellus on sellainen, jota pystyy käyttämään mahdollisimman kirjava joukko eri kykyisiä ihmisiä. Jokaisella tulisi olla yhtäläiset mahdollisuudet käyttää palveluita riippumatta siitä, mitä aisteja tai vuorovaikutuskeinoja hänellä on käytössään.

CPACC eli Certified Professional in Accessibility Core Competencies

Ja sitten itse asiaan. IAAP eli International Association of Accessibility Professionals on kansainvälinen järjestö, joka kerää yhteen saavutettavuusasiantuntijoita ja he tarjoavat sertifiointeja useilta eri saavutettavuuden osa-alueilta. CPACC eli Certified Professional in Accessibility Core Competencies on yksi niistä ja se mittaa saavutettavuuden taustalla olevien perusasioiden hallintaa.

CPACC-sertifiointi osoittaa osaamista kolmelta osa-alueelta: 1. vammaisuudet, haasteet ja avustavat teknologiat, 2. saavutettavuus ja kaikille sopiva suunnittelu (universal design) ja 3. standardit, lait ja hallintastrategiat. IAAP tarjoaa sertifikaatin tueksi materiaalipaketin, jossa on tiivistettynä sertifikaatin aihealueet ja lähdeviitteet lisämateriaaleihin.

Ensimmäinen osa-alue muodostaa kokonaisvaltaisen kuvan vammaisuudesta, sen historiasta, ja esiintyvyydestä. Lukijalle esitellään yleisimpiä vammaisuuden kategorioita, mitä esteitä ihmiset voivat kokea ja millä tavoilla esteistä aiheutuvia haittoja voidaan lieventää. Minulle vaikuttavinta oli oppia, miten vammaisuuden ymmärtäminen on kehittynyt vuosien varrella. Vammaisuus nähtiin pitkään yksilön lääketieteellisenä ongelmana. Nykyään ymmärretään myös yhteisön normien ja yksilön kykyjen vuorovaikutus vammaisuudessa. Tämä ymmärrys on tuonut paremmin esiin yhteiskunnan roolin vammaisuuksien muodostumisessa ja havahduttaa pohtimaan omaa roolia vammaisuuksien kohtaamisessa.

Toinen osa-alue käy läpi suunnittelustrategioita, joiden avulla voidaan suunnitella saavutettavia rakenteita ja järjestelmiä. Materiaali ei rajoitu laajuudessaan vain sovelluskehitykseen, vaan esittelee myös strategioita saavutettavan opetuksen ja fyysisen ympäristön suunnittelemiseen. Tämän osion mielenkiintoisin aihe oli saavutettavan opetuksen suunnittelu. Kaikki eivät opi samalla tavalla ja opetuksen tulisi mukautua oppijoiden tarpeiden mukaisesti. Kaikille sopivan opetuksen tulisi tarjota useita tapoja herättää oppijoiden kiinnostus, esittää tietoa erilaisilla tavoilla ja mahdollistaa monia tapoja vuorovaikuttaa oppimateriaalien kanssa.

Kolmannessa osassa muodostetaan kuva vammaisten oikeuksista kansallisten ja kansainvälisten sopimusten, julistusten, lakien ja standardien kautta. Näiden pohjalta käydään läpi strategioita saavutettavuuslakien ja -standardien soveltamisesta TVT-organisaatioissa. Tämän osion vaikuttavin oppi oli vammaisten oikeuksien kehitys 1900-luvulla. YK:n ihmisoikeusjulistuksessa vuodelta 1948 taataan yhtäläisiä oikeuksia kaikille ihmisille, mutta siinä ei erikseen mainita vammaisia erityisenä ryhmänä. YK:n yleiskokouksen julistus vammaisten oikeuksista 1975 mainitsi ensimmäistä kertaa vammaiset, mutta julistus ei ollut sitova. Yhtäläiset oikeudet taattiin vasta vuonna 2006 vammaisten henkilöiden oikeuksia koskevassa yleissopimuksessa.

Kokemukseni CPACC-kokeesta

Käytin materiaalin opiskeluun reilun kahden kuukauden aikana noin 5-10 tuntia viikossa. Sadat muistiinpanot ja muistiharjoitukset kulminoituivat kolmetuntiseen kokeeseen Kryterionin Espoon toimipisteessä. Koe koostui samoista osa-alueista, kuin valmennusmateriaalit ja siinä oli yhteensä 100 monivalintakysymystä. Se suoritettiin tietokoneella, mutta tulokset sai tietää vasta myöhemmin. Tulosten valmistumista saikin jännittää useamman viikon, kunnes sähköpostiin tipahti onnitteluviesti hyväksytystä suorituksesta.

Työskentelen Webscalella vaalipalvelutiimissä, joka kehittää mm. vaalikoneita. Vaalikoneissa saavutettavuudella on erityisen suuri merkitys. Saavutettavuus ei voi muodostua esteeksi vaalikoneen käytölle, jonka vuoksi kiinnitän erityistä huomiota ratkaisuihin, jotka vaikuttavat vaalikoneen saavutettavuuteen. Käytän työssäni useita menetelmiä saavutettavuuden parantamiseksi ja testaamiseksi. Saavutettavuusvaatimuksia ja hyviä ohjelmointikäytäntöjä seuraamalla pääsee pitkälle. Näiden lisäksi olen kokenut ruudunlukijatestaamisen erityisen hyödylliseksi.

Opiskellessani CPACC-koetta varten, opin ymmärtämään vammaisuutta paremmin ja miksi saavutettavuuteen panostaminen on arvokasta. Saavutettavuus ei ole salatiedettä. Se vaatii empatiaa ihmisiä kohtaan sekä innostusta uusien asioiden oppimiseen. Voin suositella sertifikaattia kaikille, jotka haluavat oppia ymmärtämään vammaisuutta ja sen tuomia haasteita ja vahvuuksia.

Hyödyllisiä resursseja:

Janne Lavila

Full Stack Developer

Asiakkaamme vastasivat - kyselyn tulokset ovat valmiit

sara.peltola@webscale.fi (Sara Peltola) — Wed, 07 Jun 2023 06:55:17 GMT

Asiakkaamme suosittelevat meitä yrityksenä sekä AWS kumppanina

Toteutimme toukokuussa 2023 asiakastyytyväisyyskyselyn, joka lähetettiin asiakkaillemme sähköpostitse. Kyselyyn vastanneet asiakkaat ovat hankkineet Webscalelta viimeisen vuoden aikana pilvikonsultointi-, ohjelmistokehitys- ja/tai ylläpitopalveluita.

Pyysimme asiakkaitamme antamaan lyhyen arvion saamastaan palvelusta sekä arvioimaan, olisivatko he valmiita suosittelemaan Webscalea yrityksenä. Suosittelumittarina käytimme Net Promoter Scorea (nettosuositteluarvoa) eli NPS:ää. Saavutimme kyselyssä huikean suositteluindeksin, jonka luku on 92 - olemme tästä erityisen ylpeitä.

Suositteluindeksin lisäksi kaikki kyselyyn vastanneet asiakkaat olivat sitä mieltä, että Webscale tarjosi heidän yrityksensä kannalta oikean ratkaisun sen hetkiseen tarpeeseen. Kyselyn avoimissa palautteissa korostui, että asiakkaamme arvostavat erityisesti Webscalen työntekijöiden ammattitaitoa, asiantuntemusta ja yleisesti hyvää yhteistyötä.

Kevään tulokset ovat samansuuntaiset kuin viime vuoden loppupuolella toteutussa Amazon Web Services (AWS) kumppanikyselyssä, jossa pyysimme asiakkaitamme antamaan lyhyen arvion saamastaan palvelusta. Tässä saavutimme uskomattoman NPS tuloksen, joka oli täysi 100! Asiakkaamme ovat valmiita suosittelemaan meitä myös AWS kumppanina.

Kiitämme kaikkia kyselyyn vastanneita asiakkaita - palautteenne on meille ensiarvoisen merkittävää. Haluamme myös jatkossa palvella asiakkaitamme mahdollisimman laadukkaasti. Näiden palautteiden ja tulosten siivittämänä on helppo hymyillä ja pian paketoida vuoden 2023 ensimmäinen vuosipuolisko - olemme äärimmäisen otettuja ja kiitollisia!

Business Continuity - Webscale Tech Days 2023

sara.peltola@webscale.fi (Sara Peltola) — Tue, 06 Jun 2023 07:31:19 GMT

Webscale Tech Days konferenssi on saanut alkunsa Webscalen Principal Consultantin Juho Raution ideasta. Kaipasimme korona-ajan jälkeen jälleen yhteisiä kohtaamisia ja tapahtumaa, jossa on mahdollista syventyä teknisiin ratkaisuihin yhdessä muiden ammattilaisten kanssa. Tämän johdosta syntyi Tech Days konferenssi, joka järjestettiin ensimmäistä kertaa viime vuonna. Tänä vuonna tapahtuma sai jatkoa ja pääteemana oli liiketoiminnan jatkuvuuden tekninen varmistaminen.

Päivä piti sisällään useamman mielenkiintoisen puheenvuoron niin meidän Webscalen konsulttien kuin AWS:n edustajien osalta. Asioiden havainnollistamiseksi esityksissä tuotiin esiin muun muassa jo toteutettuja asiakascaseja eri teemojen ympäriltä. Lisäksi päivä huipentui osallistavaan workshopiin. AWS:n osalta puhumassa olivat Markku Kaskenmaa (Security Solutions Architect, Public Sector) ja Panu Koskela (Partner Solutions Architect). Kaskenmaa puhui esityksessään minkälaisia tuotteita AWS:lta löytyy palvelunestohyökkäyksen ennaltaehkäisemiseksi ja torjumiseksi. Panu Koskela jatkoi iltapäivällä puhumalla AWS:n resilienssistä.

Alle olemme koonneet tiivistelmät niin AWS:n edustajien kuin konsulttiemme esityksistä sekä workshopista.

Architecting for DDoS protection

Markku Kaskenmaa, Security Solutions Architect, Public Sector, AWS

Markku Kaskenmaa (AWS) piti hyvän esityksen hajautettujen palvelunestohyökkäysten (Distributed Denial of Service, DDoS) torjunnasta AWS:ssä. Esityksessä luonnollisesti kerrottiin AWS:n ja asiakkaiden välisestä vastuunjaosta tietoturva-asioissa. DDoS-hyökkäysten torjunta nojaa vahvasti siihen, että asiakas käyttää AWS:n palveluita ja AWS:n omaa, maailmanlaajuista, verkkoinfrastruktuuria mahdollisimman laajasti, koska ne on rakennettu kestämään ja torjumaan erittäin suuria hyökkäyksiä. Esityksessä annettiin myös tietoa minkälaisilla keinoilla asiakkaat voivat itse vähentää DDoS-hyökkäysten vaikutuksia eri AWS-palveluiden asetuksilla sekä tehdä sovelluksistaan sopeutuvia vaihtelevaan kuormaan. DDoS-hyökkäysten torjunta vaatii siis toimenpiteitä monella tasolla ja AWS tekee sitä myös asiakkaiden huomaamatta taustalla.

Multi Region Availability

Juho Rautio, Principal Consultant, Webscale

Multi region availability esityksessä kerrottiin miten Route53 Latency-Based Routing (LBR) ja Route53 health check ominaisuuksien avulla voi rakentaa erittäin vikasietoisen ja vasteaika-optimoidun palvelun. Esityksessä käytiin yksityiskohtaisesti, oikean maailman esimerkin avulla läpi, mitä ratkaisun toteuttaminen vaatii monimutkaisessa yrityksen sisäverkossa. Automaattista vikatilanteen korjautumista ja vasteaikaan perustuvaa reititystä demonstroitiin reaaliajassa.

Chaos Engineering with AWS Fault Injection Simulator

Jussi Lehtiniemi, Senior Consultant / Cloud Architect, Webscale

Reaalimaailman sovelluksissa ja palveluissa tulee aina olemaan ongelmia. Tämä yksinkertainen toteamus on se, johon Netflix törmäsi 2010-luvun alussa ollessaan skaalaamassa palveluitaan globaalille tasolle. Kun palvelut skaalautuvat riittävän suuriksi, pelkästään ongelmiin reagoiminen alkaa käydä mahdottomaksi. Ratkaisuksi tähän ongelmaan Netflix kehitti konseptin, jolle se antoi nimen Chaos Engineering .

Chaos Engineering on pohjimmiltaan filosofia, jossa hyväksytään, että palveluissa tulee aina olemaan odottamattomia ongelmia. Sen sijaan, että näihin vastattaisiin reaktiivisesti ongelman jo ilmettyä, Chaos Engineering pyrkii varautumaan ongelmiin jo ennalta. Varautumisessa tärkeimmät työkalut ovat tarkkaan suunnitellut ja kontrolloidut testit, joilla simuloidaan reaalimaailman ongelmia, esimerkiksi CPU-kuormaa, palvelinten levyjen täyttymistä, verkkokatkoksia tai latenssin kasvua. Chaos Engineering -kokeista saadaan paras mahdollinen hyöty, jos niitä ajetaan suoraan tuotantoympäristössä. Tämä kuitenkin vaatii, että järjestelmät ovat jo sillä tasolla, että kokeiden aiheuttamat mahdolliset ongelmat eivät vaaranna liiaksi itse palveluita.

Omia Chaos Engineering -kokeita varten Netflix kehitti Chaos Monkey -työkalun, joka on yksinkertaisesti erillinen prosessi, mikä satunnaisesti sammuttaa virtuaalikone-instansseja tuotantoympäristössä. Se että tuotantoympäristössä ajetaan Chaos Monkeyn kaltaista työkalua tai suoritetaan muita kokeita, jotka aiheuttavat “hallittua kaaosta”, johtaa siihen, että jo suunnittelu- ja kehitysvaiheessa on panostettava palveluiden vikasietoisuuteen, ja myös testattava palveluita mahdollisten ongelmien varalta. Lopputuloksena syntyy pikkuhiljaa parempia ja vikasietoisempia palveluita. Samalla myös tiimit oppivat toimimaan simuloiduissa vikatilanteissa, ja osaavat näin myös toimia paremmin oikean vikatilanteen sattuessa.

Chaos Engineering filosofian käyttöönotossa organisaatioissa ei tarvitse välittömästi hypätä tuntemattomaan ja alkaa aiheuttaa ongelmia omassa tuotantoympäristössä, vaan tämä on vasta tavoitetila, johon pyritään. Alkuun pääsee helposti ottamalla Chaos Engineering -kokeet ja käytännöt osaksi sovellusten ja palveluiden normaalia kehityskaarta. Aluksi tehdään pieniä ja hallittuja kokeita esim. testiympäristöissä, joissa mahdollisista havaituista ongelmista ei ole haittaa tuotantojärjestelmille. Kokeiden tekemiseen on nykyään paljon valmiita tuotteita ja palveluita, joilla pääsee alkuun, esim. AWS Fault Injection Simulator (FIS). Havaitut ongelmat korjataan ja iteraatiokierroksia jatketaan, kunnes oma luottamus palveluiden laatuun ja vikasietoisuuteen on riittävällä tasolla. Tärkeintä on hyväksyä, että reaalimaailmassa kaaos on normaalia, ja mitä vain voi sattua. Näin voidaan ennalta varautua tuleviin ongelmiin.

Resilience at AWS

Panu Koskela, Partner Solution Architect, AWS

Panu Koskelan (AWS) esitys keskittyi vikasietoisten järjestelmien luomiseen AWS:n pilviympäristössä. Tässäkin esityksessä käytiin läpi mikä osuus vikasietoisuudesta on AWS:n vastuulla ja mikä jää asiakkaan vastuulle. Esityksen mielenkiintoisinta antia oli kun Panu esitteli AWS:n käyttämiä jatkuvan kehityksen malleja, joissa tiimit sekä kehittävät että ylläpitävät palvelua tai sen osaa. Mahdollisten ongelmien jälkikatselmoinnissa etsitään juurisyitä ja ratkaisuja syyllistämättä ketään. Jatkuva kehitys mahdollistaa AWS:n oman vikasietoisuuden. Esityksessä käytiin myös laajasti läpi minkälaisia arkkitehtuureja, kehitysmalleja ja AWS-palveluita asiakkaat voivat käyttää parantaakseen sovellustensa vikasietoisuutta. Yksi mielenkiintoinen nosto on AWS Fault Injection Simulator (AWS FIS), jolla asiakkaat voivat testata erilaisten häiriöiden vaikutusta omaan ympäristöönsä.

Application Security in AWS

Jukka Ukkonen, Senior Consultant / Cloud Architect, Webscale

Kyberturvallisuus on tärkeässä roolissa yrityksen koosta riippumatta, sillä kyberhyökkäyksen aiheuttamat vahingot voivat olla suuria, ja ne vaikuttavat myös yrityksen maineeseen ja asiakkaiden luottamukseen. Sovellusten turvallisuuteen liittyvät oleellisesti erilaiset työkalut, käytännöt ja prosessit, joiden avulla pyritään estämään sovelluksen turvallisuusongelmia. Kehittäjät ovat myös nykyään enenevissä määrin vastuussa pilvi-infrasta ja -resursseista, joita sovellukset tarvitsevat toimiakseen.

Tästä syystä sovellusten turvallisuuden kannalta on tärkeää, että yksittäisen sovelluksen koodin sijaan käsitellään kokonaisuutta, johon kuuluvat esimerkiksi sovellus- ja IaC-koodi, pilvi-infra ja -resurssit ja data. Onkin suositeltavaa, että turvallisuus on läsnä ohjelmistokehityksen elinkaaren kaikissa vaiheissa. DevOpsin yhteydessä tästä käytetään termiä DevSecOps, joka tarkoittaa turvallisuuden lisäämistä DevOps-malliin. DevSecOps pitää myös sisällään turvallisuuteen liittyvien operaatioiden automatisoinnin, kuten esimerkiksi erilaisten skannaussovellusten käytön (SAST, DAST, IAST), riippuvuuksien ja kontti-imagejen tarkistamisen sekä reagoimisen havaittuun uhkaan. Lisäksi turvallisuuteen liittyvä monitorointi on osa DevSecOps:ia.

Turvallisuuteen liittyvät tärkeimmät toiminnot ovat ongelmien tunnistaminen, suojautuminen erilaisilta uhkilta, hyökkäyksen tai muun tietoturvaongelman havaitseminen, havaittuun ongelmaan reagointi sekä palautuminen ongelman jäljiltä. AWS tarjoaa erilaisia turvallisuuteen liittyviä palveluita sekä tuotteita, joissa on erilaisia mekanismeja tähän liittyen ja joiden käyttö on suositeltavaa turvallisuuteen liittyvien tärkeimpien toimintojen mahdollistamiseksi.

Workshop

Kalle Soranko, Senior Consultant / Cloud Architect, Webscale

Henri Meltaus, CTO, Webscale

Konferenssipäivän päätteeksi järjestimme “Business Continuity”-aiheisen workshopin.

Workshopissa osallistujat pääsivät pienryhmissä suunnittelemaan lippu-lappu.fi lipunmyyntiverkkokaupan AWS-arkkitehtuurin uudelleen päivän teeman mukaisesti. Workshopin lopussa jokainen ryhmä esitteli vielä tuotoksensa yhteisesti.

Yhteenveto päivästä

Tech Days -konferenssi oli oikein onnistunut tapahtuma, joka kokosi yhteen lähes kaikki webscalerit sekä myös asiakkaitamme. Päivän aikana pääsimme verkostoitumaan ja oppimaan uutta. Mielenkiintoisten esitysten ja workshopin lisäksi meitä hemmoteltiin hyvällä ruoalla ja hienolla iltajuhlalla. Iltajuhlassa saimme nauttia tarjoiluiden sekä hyvän musiikin lisäksi TV:stä tutun näyttelijän ja stand-up koomikon Jaakko Saariluoman esityksestä. Paikkana Tuusulan Krapi loi loistavat puitteet tapahtumalle.

Jäämme innolla odottamaan tapahtuman palautekyselyn tuloksia ja kehitysideoita, jotta pystymme ensi vuonna tekemään Tech Daysistä vieläkin onnistuneemman. Toivottavasti tapaamme mahdollisesti myös sinut ensi vuonna!

AWS Summit Stockholm 2023 - tunnelmia ja parhaita paloja

Fri, 12 May 2023 12:21:04 GMT

Eri puolilla maailmaa järjestettävissä AWS Summit -tapahtumissa on tilaisuus oppia lisää AWS:stä ja verkostoitua alan muiden osaajien kanssa. Tapahtumissa perehdytään muun muassa AWS-tuotteisiin ja -palveluihin, ja autetaan kehittämään AWS-taitoja, joita tarvitaan infrastruktuurin ja sovellusten rakentamiseen, käyttöönottoon ja käyttöön.

Tänä vuonna AWS Summit Stockholm järjestettiin Stockholmsmässanissa 11. toukokuuta 2023. Tapahtumassa päästiin tutustumaan AWS-teknologioiden edistysaskeliin, pilvi-innovaatioihin sekä menestystarinoihin. Keynote-puheenvuoroja ja erilaisia istuntoja pitivät AWS-aiheasiantuntijat, kumppanit ja asiakkaat, jotka kertoivat heidän omasta pilvimatkastaan ja kuinka he ovat onnistuneesti rakentaneet ratkaisuja AWS:llä.

Suuntasimme torstaina aamulennolla kohti Tukholmaa yhdeksän webscalerin voimin. Aikaisesta herätyksestä huolimatta fiilis oli hyvä ja innostunut. Kokeneina konkareina mukaan lähtivät Ville ja Mika, meille muille tämä oli ensimmäinen AWS Summit. Perillä meitä odotti aurinkoinen Tukholma. Kiiruhdimme junalla kohti Stockholmsmässania ja päivän avaavaa keynotea.

Keynote

Marielle Lindgren ( Managing Director - Benelux & Nordics ) avasi tapahtuman kertomalla yleisesti pilven tuomista mahdollisuuksista taloudellisesti sekä AWS:n kestävän kehityksen tavoitteista. AWS jatkaa mittavia investointejaan Pohjoismaihin sekä pyrkii muun muassa olemaan hiilineutraali vuoteen 2040 mennessä ja käyttämään 100% uusiutuvia energianlähteitä vuoteen 2025 mennessä.

Keynote jatkui Holly Mesrobian (VP Serverless Compute - AWS) puheenvuorolla. Hän kertoi AWS:n innovaatioista ja dataratkaisuista. Puheessaan Holly nosti esiin kolme tärkeintä elementtiä vahvaan datastrategiaan: kattavuus, integraatio ja hallinnointi.

Pääsimme kuulemaan myös AWS:n innostavia asiakastarinoita terveydenhuoltoalalta. Amrik Mahal ( Global IT Head for Research ) Astra Zenegasta ja Thomas B. B. Larsen ( Global Head of Business Intelligence, Data Management & Analytics ) Novo Nordiskilta kertoivat, kuinka he pyrkivät omilla tahoillaan saavuttamaan yrityksien missiot AWS:n eri työkaluja hyödyntämällä. Viimeisenä asiakastarina kuultiin Nothvoltin kunnianhimoinen tavoite olla maailman vihrein patterien tuotantotehdas. Mikael Söderberg ( Chief Digitalization Officer ) Northvoltilta viittasi puheessaan esimerkiksi heidän omaan “Cloud Factory -malliin”, jolla pyritään saavuttamaan mahdollisimman kehittäjä- ja loppukäyttäjäystävällinen kokonaisuus.

Keynote oli kaiken kaikkiaan mahtava startti päivälle. Tämän jälkeen haajannuimme kukin seuraamaan esityksiä ja puheenvuoroja oman mielenkiinnon mukaan, joista tiivistelmät alla. Jokainen oli aikatauluttanut omaa päiväänsä AWS Events sovelluksen avulla.

Webscalereiden parhaat palat tapahtumasta

How XXL Sports transformed their customer experience through Amazon Personalize

Asiakaskokemuksen tärkeys korostuu palveluita tuotettaessa. Noin 60% kuluttajista kertoo palaavansa asiakkaaksi personoidun ostokokemuksen myötä. Yritykset, jotka panostavat palveluiden personointiin ovat kasvattaneet tuottoa 10-15%. Uuden asiakkaan hankkiminen voi olla jopa viisi kertaa kalliimpaa, kuin olemassa olevan asiakkaan säilyttäminen. Palveluiden personointi edesauttaa asiakaskokemusta ja asiakkaat palaavat käyttämään hyväksi toteamiaan palveluita.

Amazon Personalize tarjoaa asiakkaille mahdollisuuden hyödyntää omaa dataa ja tekoälyä personoidun asiakaskokemuksen rakentamiseen. XXL on hyödyntänyt Amazon Personalize palvelua tuottamaan asiakkailleen personoidun käyttäjäkokemuksen. Amazon Personalizen avulla XXL pystyy suosittelemaan asiakkaiden käyttökokemuksen mukaisesti heille oikeita tuotteita ja lisäpalveluita. Samanaikaisesti palvelu tuottaa myös reaaliaikaista personointia asiakkaan ostokäyttäytymisen perusteella. Tällöin asiakkaalle pystytään osoittamaan oikeita tuotteita, kun he vierailevat verkkokaupan sivustolla.

Amazon Personalize vähentää manuaalista työtä ja luo palvelun loppukäyttäjälle personoitua palvelua. Palvelu on kustannustehokas ratkaisukokonaisuus esimerkiksi verkkokaupoille, jotka haluavat parantaa palvelunsa personoitua käyttökokemusta automaatioita hyödyntäen.

Delivering sustainable and performant solutions at scale

Tutkimuksissa on selvitetty, että suomalaiset suosivat ympäristöllisesti kestäviä ratkaisuja, mikäli ne ovat edullisempi kuin tavanomaiset. AWS:n palveluissa hinta kertoo yleensä myös niiden ympäristökuormituksesta. Parhaiten kuormitusta pystyy vähentämään samalla tavalla kuin kustannuksia eli optimoimalla palvelut mahdollisimman tehokkaaksi.

Tässä on keinoina muun muassa käyttää uudempia instanssityyppejä ja hyödyntää AWS Graviton -prosessoreita, jos mahdollista. Nykyisin tämä on valittavissa myös monissa palveluissa kuten Aurora RDS ja OpenSearch. Graviton -prosessorit ovat jopa 60% energiatehokkaampia vastaaviin x86-prosessoreihin verrattuna.

Samoin tallennustilassa ensisijainen vaihtoehto on, että tarpeetonta tietoa ei säilytetä. Lokitiedolle määritellään säilytysaika (retentio) ja tekstitietoa tiivistetään esimerkiksi JSON-> Parquet sekä pakataan (gzip, xz). Jos tieto on pitkäaikaissäilytettävä, se siirretäään mahdollisuuksien mukaan esimerkiksi Glacieriin.

Sustainability Hackathon

Sustainability Hackathonissa ohjelmoitiin IoT-pohjaista vesiviljelyjärjestelmää. IoT-laitteen avulla voitiin mitata veden lämpötilaa, ravinteiden määrää ja hallita veden virtausta. Tehtävänämme oli tallentaa IoT-laitteen mittausdata AWS:n pilveen ja tehdä sen pohjalta reaaliaikaista visualisointia.

Ohjelmointi suoritettiin Hackathonissa kolmen hengen tiimeissä. Tapahtuman järjestäjät tarjosivat AWS-tilin, jossa oli valmiina resursseja tehtävänantoa varten. Laite yhdistyi vähäisellä säätämisellä AWS:n IoT-palveluun ja dataa alkoi kertymään hyvää vauhtia. Kun dataa oli saatavilla, pääsimme rakentamaan visualisointia. AWS-tilille oli tapahtuman järjestäjien puolesta asennettu Grafana, jonka avulla pääsimme nopeasti rakentamaan visualisointia datallemme. Rakensimme näkymät veden lämpötilalle, ravinteiden määrälle, pariston jännitetasolle ja pumpun toimintastatukselle.

How to develop an Observability strategy

Observability tarkoittaa digitaalisen tuotteen monitorointia ja mittausta useista liiketoiminnalle, asiakkaille ja sisäisille sidosryhmille merkityksellisistä näkökulmista. Esitys sisälsi demon kuvitteellisesta lemmikkien adoptointisovelluksesta, jonka toimintaa seurataan AWS-työkalujen, etupäässä CloudWatchin avulla. Esimerkiksi poikkeuksellisen alhainen koirien myyntimäärä tunnissa voi kertoa viasta tai käyttäjäkokemus häiriöstä sovelluksessa. Metriikka siitä, mistä kaupungeista tilaukset tulevat, voi kertoa jotain hyödyllistä, esimerkiksi miten markkinointi toimii tai miten sitä tulisi kohdentaa.

Koirien myyntimääriä tarkkailtiin CloudWatch -lokeihin talletetuista tilaus-URL:eista, joista koiramyynnit saatiin tilauksen osoiteriviparametrin perusteella. Mietimme hetken, miksei hakua kohdistettu esimerkiksi tilaustietokantaan, sillä lokien parsinta avainsanoilla tuntuu äkkiseltään hieman keinotekoiselta ja epävarmalta. Jokuhan voisi periaatteessa häiritä järjestelmää valeparametrisoiduilla URL-kyselyillä. CloudWatch -palvelun lokit ja hälytyssysteemi ovat kuitenkin niin keskeisesti valmiiksi toisiinsa integroituja, ja mahdollisen haitantekijän hyöty niin olematonta, että tälläkin toteutuksella on nähtävissä vahvat perusteet. Esitys suositti toteuttamaan sovellustarkastelua useina osittaisstrategioina, kuten seurantapaneeli-, hälytys- ja datan keruustrategiana sekä hälyttimien ilmaisemiin poikkeustilanteisiin reagoimalla.

Yhteenveto päivästä

Mielenkiintoisissa esityksissä asiaa tulee paljon lyhyessä ajassa. Helpoiten asiat jäivät mieleen muistiinpanoja tekemällä, joihin voi sitten palata myöhemmin. Parhaimmillaan esitykset tarjoavat suoran ratkaisun olemassa olevaan teknologiseen haasteeseen.

Tapahtuman päätyttyä suuntasimme vielä Tukholman keskustaan illalliselle. Kertasimme ja kävimme yhdessä läpi päivän kohokohtia. Kaikille oli jäänyt tapahtumasta positiivisen innostunut fiilis. Pitkä, mutta antoisa päivä oli tullut päätökseen ja oli aika palata takaisin koti-Suomeen. Ensi vuonna taas uudestaan!

Kysy konsultilta: Mitä hyötyjä konttiteknologialla tavoitellaan?

Thu, 20 Apr 2023 09:32:38 GMT

Mitä hyötyjä konttiteknologialla tavoitellaan?

Kontilla tarkoitetaan ohjelmistopakettia, joka sisältää itse ohjelman lisäksi tarvittavan riippuvuuden ohjelman ajamiseksi. Tästä seuraa suoraan konttiteknologian ensimmäinen hyöty. Kontit ovat kätevä tapa jakaa staattisia ohjelmistopaketteja, jotka sisältävät kaiken ohjelman suorittamiseksi minkä tahansa infrastruktuurin päällä. Konttiin voidaan pakata omien binääri- tai lähdekooditiedostojen lisäksi myös muita ohjelmistopaketteja. Esimerkiksi ohjelmistotyökaluja voidaan esiasentaa konttiin. Tällöin kontti voidaan vain käynnistää ja ohjelmisto sekä riippuvuudet ovat saatavilla.

Ohjelmistokehittäjän näkökulmasta kontit tarjoavat oivallisen alustan ohjelmiston kehittämiselle sekä testaamiselle. Kehittäjä voi suorittaa koodinsa kontissa, jolloin hän tietää ympäristön olevan staattinen sekä ennaltamääritelty ja, että se sisältää valmiiksi tarvittavat riippuvuudet. Testauksessa tarvittava tietokanta on esimerkiksi kätevä käynnistää konttina, jolloin sen tila on tiedossa.

Ohjelmien suorittaminen konteissa sekä konttien orkestrointityökaluissa (mm. Kubernetes ja ECS) mahdollistavat ns. mikropalveluarkkitehtuurien käytön. Mikropalvelulla tarkoitetaan ohjelmaa, joka suorittaa yhden tietyn tehtävän ja on osana suurempaa joukkoa muita mikropalveluja. Mikropalveluiden käyttö tarjoaa joustavan tavan kehittää ja testata ohjelmistoja. Jokainen mikropalvelu on oma itsenäinen ohjelmansa, jota kehitetään ja testataan omana kokonaisuutenaan.

Kalle Soranko

Senior Consultant

Kysy konsultilta: Mitä jokaisen kannattaa ymmärtää DevOps:sta?

sara.peltola@webscale.fi (Sara Peltola) — Thu, 06 Apr 2023 10:21:48 GMT

Mitä jokaisen kannattaa ymmärtää DevOps:sta?

DevOps on yleistermi työskentelymallille, jossa kehittäjien ja ylläpitäjien yhteistyö on tiiviimpää tai erot tiimien välillä poistuvat jopa kokonaan. Yleensä siinä mahdollistetaan kehittäjille itsenäisempi tapa toimia omien vastuusovellustensa ylläpitoon liittyvissä asioissa kuten automaatio, testaus ja valvonta. Nämä kyvykkyydet tarvitsevat erilaisia työkaluja, joiden ylläpito voi olla kuitenkin kootusti operoinnin tai DevOps-tiimin vastuulla.

Itsenäisempi työskentelytapa tarvitsee tuekseen näkyvyyttä tavoitteisiin sekä raamit, joiden sisällä toimitaan. Näin vältytään siltä, että organisaation sisälle syntyy useita eri kulttuureja. Monesti DevOps liitetään myös ketterään kehitykseen, koska se mahdollistaa nopean kehityssyklin, kun julkaisuputket ovat automaattisia ja kehittäjät näkevät muutoksen vaikutuksen itse eikä tarvitse odottaa virheraportteja. Sovelluksien kehityssyklin lisäksi DevOpsissa usein halutaan kehittää itse kehitystä. Tällöin mietitään, miten sovelluskehityksestä voisi saada vielä turvallisempaa, laadukkaampaa ja organisaation tavoitteita vastaavampaa .

Antti Elonheimo

Senior Consultant

6 asiaa, jotka on hyvä tietää vaalikoneista

Tue, 28 Mar 2023 07:17:50 GMT

Vaalikoneilla on Suomessa lähes 30 vuoden historia ja niitä käytetään kotimaassamme erityisen paljon. Vaalikoneilla on suuri merkitys etenkin nuorten äänestyskäyttäytymiseen ja tulevaisuudessa niiden merkityksen arvioidaan kasvavan entisestään.

Webscalella on pitkä kokemus vaalikoneiden suunnittelusta ja toteutuksesta. Kokemus on tuonut myös näkemystä siitä, millainen on hyvä vaalikone ja millaisia asioita esimerkiksi vaalikysymysten laatimisessa kannattaa ottaa huomioon. Ota selvää, mitä asioita jokaisen olisi hyvä tietää vaalikoneista!

1. Vaalikoneilla on pitkä historia

Vaalikoneilla on maailmalla pitkät perinteet. Yleisradio julkaisi vaalikoneen Suomessa EU-vaalien yhteydessä vuonna 1996 eli 27 vuotta sitten. Maailman ensimmäisen verkkosivun julkaisusta oli tällöin kulunut vain 5 vuotta. Ylen pitkäaikaista toimittajaa Erkki Vihtosta pidetään vaalikoneen isänä, sillä hän keksi idean vaalikoneesta yrittäessään kehittää A-studion tuoreille nettisivuille uutta sisältöä. [Varho, 2016]

Inspiraatio syntyi vuoden 1996 Yhdysvaltain presidentinvaaleista ja CNN:n nettisivuilla olleesta interaktiivisesta kyselystä, jossa oli koostettu ehdokkaiden puheista ja mielipiteistä lyhyt kysymyspatteri. Kyselyyn vastaamalla äänestäjä sai tietää, kumpi ehdokkaista oli lähempänä omia vastauksia. Tästä poiketen A-studion vaalikoneessa pyydettiin ehdokkaita vastaamaan vaalikoneen kysymyksiin suoraan itse ja sitten verrattiin kansalaisten vastauksia ehdokkaiden vastauksiin. Tämä Vihtosen keksimä vaalikoneen perusidea on vielä tänäkin päivänä sama. Yleisradion ensimmäinen vaalikone saattoikin olla paitsi Suomen, mahdollisesti myös koko maailman ensimmäinen verkossa toimiva vaalikone. [Varho, 2016]

Ylen pilotin jälkeen muut mediat ja toimijat seurasivat ideaa nopeasti perässä. Maailman ensimmäisiin vaalikoneisiin lukeutuu myös Suomen nuorisoalan kattojärjestö Allianssin koordinoima Nuorten vaalikone. Se julkaistiin ensimmäistä kertaa myös vuonna 1996 Harava-nimellä. Nuorten vaalikone on perinteisesti koonnut yhteen nuoria koskettavia kysymyksiä ja teemoja. [Allianssi, 2023] Kiintoisa fakta on, että molemmat jo vuosikymmenten ajan vaalikoneita toteuttaneet toimijat ovat tällä hetkellä Webscalen asiakkaita. Eduskuntavaaleihin 2023 toteutetut vaalikoneet löydät Allianssin osalta täältä ja Ylen osalta täältä .

Vaalikoneiden kansainvälinen historia ulottuu vain hieman suomalaisia vaalikoneita pidemmälle. Ensimmäisenä vaalikoneena alan tutkimuksessa on nostettu Alankomaiden StemWijzer-sovellus. Se toteutettiin valtakunnallisena verkkoversiona vasta vuonna 1998, mutta printtiversio alkoi ilmestyä lehdissä jo 1980-luvun loppupuolella. [Borg & Koljonen, 2020]

2. Vaalikoneissa on hiottu prosessi

Vaalikoneiden taustalla on yleensä monien kuukausien suunnittelu- ja toteutustyö. Ennen kuin vaalikone aukeaa suurelle yleisölle, vaalikoneen tarjoaja miettii ja päättää kysymykset ja ominaisuudet, joita vaalikoneessa on. Tämän jälkeen kutsutaan ehdokkaat vastaamaan vaalikoneen kysymyksiin. Ehdokkaille on suunniteltu vaalikoneeseen oma käyttöliittymä; ehdokaskone, jossa ehdokkaat pääsevät täyttämään oman profiilin vaalikoneeseen. Webscalella ehdokkaiden apuna toimii oma ammattitaitoinen ehdokastuki, joka varmistaa vaalikoneen toimivuuden ehdokkaille. Ehdokastuen toiminnasta voit lukea lisää täällä .

Ehdokkaiden vastausajan jälkeen vaalikoneet avataan yleisölle yleensä 1-2 kuukautta ennen vaaleja. Varsinainen äänestäjille suunnattu vaalikone on kaikille näkyvä palvelu, jossa äänestäjät voivat vastata samoihin vaalikysymyksiin, mihin ehdokkaat ovat vastanneet ja löytää siten itselleen sopivan ehdokkaan.

3. Vaalikoneissa kysymyksenasettelut ovat tärkeitä

Vaalikoneen kysymyksiä laadittaessa on tärkeää huomioida kysymysten selkeä muotoilu ja kysymysten määrä. Tyypillisin virhe vaalikoneissa on liian suuri kysymysmäärä, mikä ei houkuttele ehdokkaita eikä sen enempää äänestäjiä vastaamaan vaalikoneen kysymyksiä loppuun asti. Webscalella on kokemuksen kautta opittu, että yleensä hyvä kysymysmäärä vaalikoneissa on n. 10-30 kysymystä. Webscalen seniorikonsultin Hannu-Pekka Hakamäen mukaan: “ Hyvä kysymysmäärä on ehkä liian subjektiivinen, sillä esimerkiksi pikavaalikoneessa noin 10 kysymystä on hyvä määrä, mutta 20-30 on määrä, jolla saadaan esiin tarpeeksi eroja ehdokkaiden välille, kuitenkin niin että vaalikoneen täyttäminen ei ole liian työlästä tai aikaaa vievää loppukäyttäjille. ”

Kysymysten lisäksi kannattaa miettiä tarkkaan myös vastausvaihtoehtojen määrää. Esimerkiksi monivalintakysymyksissä vastausvaihtoehtoja kannattaa olla maksimissaan 6-7 kappaletta.

Vaalikoneet mahdollistavat erilaisten kysymystyyppien käytön ja tällä hetkellä vakiintuneimpia kysymystyyppejä ovat kyllä/ei, monivalinta, prioriteettilista sekä Likert -asteikko. Käytetyin kysymystyyppi “Likert-asteikko” on vastausasteikko, jolla selvitetään mielipide-eroja. Vastaajat arvioivat asenneväittämiä viisiportaisella asteikolla, jonka vastausvaihtoehdot ovat esimerkiksi:

täysin eri mieltä
jokseenkin eri mieltä
ei samaa eikä eri mieltä
jokseenkin samaa mieltä
täysin samaa mieltä

Useat vaalikoneet laskevat käyttäjän ja ehdokkaan valintojen etäisyyttä toisistaan viisiportaisella asteikolla. Aluksi jokainen ehdokas on käyttäjälle yhtä sopiva, mutta etääntyy tästä sen mukaan, montako pykälää vastaukset eroavat toisistaan.

Hakamäen mukaan: “ Kysymystyypeistä likert-asteikolla toteutetut väittämä -kysymykset ovat helpoin ja tutuin käyttäjille ja siksi niitä kannattaa suosia. Myös muita kysymystyyppejä voi lisätä tuomaan mielenkiintoa koneeseen (esim. monivalinta), mutta näitä ei kannata olla liikaa, sillä niihin vastaaminen on työläämpää ja vie enemmän aikaa loppukäyttäjiltä. ”

Toimiva vaalikonekysymys pitää lisäksi olla helposti ymmärrettävä, jolloin se kannattaa muotoilla mahdollisimman selkeästi, ettei sitä voi tulkita usealla eri tavalla. Vaikeaselkoisuus aiheuttaa haittaa sekä ehdokkaille että konetta käyttäville äänestäjille ja molempien pitäisi pystyä ymmärtämään kysymys samalla tavalla. [Laakso, 2023] Yleensä kysymys kannattaa tiivistää mahdollisimman lyhyeksi ja ytimekkääksi. Tämän lisäksi vaalikoneissa voi usein lisätä kysymyksen yhteyteen selitteen, jossa voi avata kysymyksen taustoja vielä enemmän.

4. Vaalikoneissa suomalaiset ovat kärkikäyttäjiä

Vaalikoneita käytetään Suomessa erityisen paljon ja Suomi onkin yksi vaalikoneiden kärkimaista, kun käyttäjämäärät suhteutetaan äänioikeutettujen määrään. Vuonna 2019 pidetyissä eduskuntavaaleissa oli tarjolla 22 erilaista vaalikonetta [Borg & Koljonen, 2020] ja tämän kevään 2023 eduskuntavaaleissa on avattu myös jo lähemmäs 20 vaalikonetta.

Tampereen yliopiston politiikan tutkijat Sami Borg ja Kari Koljonen pitävät yhtenä suosion syynä suomalaista ehdokaskeskeistä vaalijärjestelmää. Suomessa on käytössä vaalijärjestelmä, jossa ehdokkaan äänestäminen on pakollista. Äänestäjä äänestää suoraan sitä henkilöä, jonka hän tahtoo saada valituksi. Tämän takia vaalikoneet ovat yleensä ehdokasvaalikoneita, jotka jäsentävät ehdokkaiden mielipiteitä ja niiden eroja. Monissa muissa maissa vaaleissa äänestetään vain puoluetta, jonka takia vaalikoneet jäsentävät puolueiden välisiä eroja. [Borg & Koljonen, 2020]

Valtakunnallisten vaalien lisäksi vaalikoneita käytetään paljon myös esimerkiksi edustajisto- tai valtuustovaaleissa. Yhdistykset, liitot ja erilaiset järjestöt kaipaavat yhä enemmän omiin vaaleihinsa avuksi vaalikoneen, joka helpottaa ehdokkaiden esittelyä äänestäjille. Webscale tarjoaakin myös pienemmille toimijoille vaalikoneen kustannustehokkaasti helppokäyttöisenä vaalikonepalveluna.

5. Vaalikoneilla on suuri merkitys nuorille

Vaalikoneilla on tutkitusti suuri merkitys erityisesti nuorten äänestyskäyttäytymiseen. Vaalikoneet aktivoivat nuoria äänestämään ja vaikuttavat nuorten ehdokasvalintoihin. Tampereen yliopiston politiikan tutkijoiden Sami Borgin ja Kari Koljosen tekemän tutkimuksen mukaan vaalikoneet ovat suomalaisnuorten tärkein äänestyspäätösten tietolähde. [Borg & Koljonen, 2020]

Borgin ja Koljosen Käyttöliittymä vaaleihin -tutkimuksessa selvitetään vaalikoneiden käyttöä vuoden 2019 eduskuntavaaleissa sekä vuoden 2018 presidentinvaaleissa. Tutkimuksen mukaan “ alle 30-vuotiaista vastaajista joka toinen katsoi, että vaalikoneet olivat lisänneet heidän kiinnostustaan äänestämiseen ja yli puolet heistä sanoi, että vaalikoneiden ehdokassuositukset olivat vaikuttaneet omaan äänestyspäätökseen. ” Lähes puolet (47 %) nuorista äänestäneistä kertoi vaalikoneiden vaikuttaneen ratkaisevasti tai melko paljon omaan puoluevalintaan ja jopa 69 prosenttia oli sitä mieltä, että vaalikoneilta saaduilla tiedoilla oli ollut hyvin tai melko tärkeä merkitys siihen, ketä äänesti vuoden 2019 eduskuntavaaleissa. [Borg & Koljonen, 2020]

Ylen teettämästä vaalisisältöjen vaikuttavuutta vuoden 2021 kuntavaaleissa tutkivasta tutkimuksesta käy ilmi, että 61 prosenttia 18–29-vuotiaista suomalaisista kertoo etsineensä Ylen sisällöistä tietoa vaaleista ja 44 % sai Ylen vaalikoneesta apua ehdokkaan valinnassa. [Ylen tiedote, 2021]

Vuoden 2021 kuntavaaleissa Ylen vaalikonetta käytti 77 % nuorista. [Ylen tiedote, 2021] Nuoret käyttävät siis tutkitusti vaalikoneita eniten. Nuorten ja opiskelijoiden lisäksi vaalikoneista ovat eniten hyötyneet väestöryhmät, joiden into osallistua yhteiskunnalliseen toimintaan on keskimääräistä vähäisempää. Tällaisia ryhmiä ovat tutkijoiden Borg ja Koljonen mukaan matalammin koulutetut ja työttömät. [Borg & Koljonen, 2020]

6. Vaalikoneet kehittyvät tulevaisuudessa

Tulevaisuudessa yhä useampi, nuori tai vanha, hakee itselleen sopivia ehdokkaita vaalikoneiden avulla. Näin ollen vaalikoneiden merkitys ja vaikutus äänestyskäyttäytymiseen tulee kasvamaan entisestään. Todennäköisesti vaalikoneet ovat tulevaisuudessa myös entistä monipuolisempia. Ehdokkaat tulevat epäilemättä käyttämään enemmän aikaa vaalikoneiden huolelliseen täyttämiseen sekä oman monipuolisen ehdokasprofiilin luomiseen.

Vaalikoneiden tulevaisuus riippuu Tampereen yliopiston tutkijoiden mukaan paljolti median elinvoimaisuudesta. Mikäli median resurssit kutistuvat, vaalikoneidenkin kehitys voi pysähtyä ja journalismi voi taantua tulosten referoinniksi. Vaalikonekysymykset ovat olleet tähän mennessä pääosin relevantteja ja tarjonneet äänestäjille apua äänestämistä koskeviin valintoihin, mutta tulevaisuutta saattaa myös uhata kysymyksenasettelujen motiivien hämärtyminen. Tutkijat eivät poissulje sitä, että tulevaisuuden vaalikoneissa painottuisivat politiikkakysymysten sijaan esimerkiksi viihdyttävät kysymykset ja oheissisällöt, joiden avulla saataisiin nostettua vaalikoneiden kävijämääriä. [Borg & Koljonen, 2020]

Lähteet:

[Allianssi, 2023]

https://nuorisoala.fi/palvelut/demokratiakasvatus-ja-osallisuus/nuorten-vaalikone/ , Luettu 17.2.2023.

[Borg & Koljonen, 2020]

Sami Borg & Kari Koljonen, Käyttöliittymä vaaleihin, https://trepo.tuni.fi/bitstream/handle/10024/123860/978-952-359-026-7.pdf?sequence=2 , Luettu 8.3.2023.

[Laakso, 2023]

Ville Laakso, Yle, https://yle.fi/a/74-20020699 , Luettu 10.3.2023.

[Varho, 2016]
Esko Varho, Yle, https://yle.fi/a/3-9115786 , Luettu 17.2.2023.

[Ylen tiedote, 2021]

https://yle.fi/aihe/a/20-10001299 , Luettu 17.2.2023.

Kysy konsultilta: Mikä on AWS Local Zone ja miten sitä voidaan hyödyntää?

sara.peltola@webscale.fi (Sara Peltola) — Mon, 27 Mar 2023 11:33:13 GMT

Mikä on AWS Local Zone ja miten sitä voidaan hyödyntää?

AWS Local Zone on AWS:n palvelu, joka tarjoaa AWS:n infrastruktuuripalveluita lähellä käyttäjän fyysistä sijaintia. AWS Local Zone on käytännössä konesali, joka on sijoitettu fyysisesti lähelle loppukäyttäjää. Tämä auttaa parantamaan suorituskykyä sovelluksissa, jotka vaativat erittäin alhaista viivettä tai nopeaa reagointikykyä.

AWS Local Zone sisältää valikoiman AWS:n infrastruktuuripalveluita. Palveluiden valikoima vaihtelee eri sijaintien välillä. Suomen osalta lähin AWS Local Zone palvelee Helsingissä, jonka palveluvalikoima rajoittuu lähinnä laskenta- ja verkkopalveluihin, kuten Amazon Elastic Compute Cloud (EC2), Amazon Elastic Container Services (ECS) ja Amazon Virtual Private Cloud (VPC).

AWS Local Zonen operointi tapahtuu aina lähinnä olevan varsinainen AWS-regionin kautta, täten esimerkiksi Helsingin Local Zonea hallinnoidaan AWS:n Tukholman regionilta. Yhteensä Local Zoneja on tällä hetkellä maailmanlaajuisesti 32 kpl ja uusia lanseerataan jatkuvasti lisää.

Ville Välimäki

Cloud Architect

Eväät vuodelle 2023 - ja lyhyt katsaus viime vuoteen

tero.kauhanen@webscale.fi (Tero Kauhanen) — Mon, 20 Mar 2023 18:08:10 GMT

Vuosi 2023 on lähtenyt Webscalessa vauhdikkaasti käyntiin. Tammikuussa olemme päässeet tutustumaan uusiin työkavereihin ja maaliskuussa meillä jälleen aloittaa kaksi uutta henkilöä. Tällä hetkellä haemme myös lisää vahvistuksia joukkoomme mm. pilviarkkitehdin ja DevOps-asiantuntijan tehtäviin. Helmikuussa laajensimme yhteistyötä Amazon Web Servicesin (AWS) kanssa liittymällä julkisen sektorin kumppaniohjelmaan (AWS Public Sector Partner). Maaliskuun alussa käynnistimme Pilvipilotit podcastin , johon olemme saaneet mukavasti vieraita erikokoisista yrityksistä kertomaan heidän pilvimatkasta.

Tänä vuonna panostamme yhtiössämme erityisesti jatkuvien palveluidemme kehittämiseen sekä teknisen osaamisen ja tarjonnan kasvattamiseen. Kerromme näistä tarkemmin vuoden edetessä. Edellisten vuosien tapaan haluamme ylläpitää ja kehittää erinomaisia asiakassuhteita. Lukujen valossa haemme yli 20%:n kannattavaa kasvua niin liikevaihdossa kuin henkilömäärässä.

Haluamme olla asiakkaillemme paikallinen ja ammattitaitoinen kumppani vaativissa pilvi- ja ohjelmistokehityshankkeissa. Työntekijöillemme olemme yritys, jossa standardit ovat korkeat ilman turhaa pönötystä.

Katsaus vuoteen 2022

Henkilöstö

Henkilöstömäärämme kasvoi viime vuonna kymmenellä henkilöllä. Tässä yhteydessä on myös mukava kertoa, että viimeisen 12 kuukauden aikana meiltä ei ole lähtenyt yhtään henkilöä!

Myös henkilöstötyytyväisyyskyselymme mukaan Webscalessa on hyvä olla. Maailman mullistusten keskellä koemme tärkeäksi, että voimme osaltamme tarjota mielekkäät puitteet työnteolle. Uskomme, että työ on palkitsevaa silloin, kun sen tekijällä on sopivasti vastuuta ja vapautta.

Liikevaihto ja tulos

Viime vuonna Webscalen liikevaihto kasvoi yli 3,6 miljoonaan euroon ja teimme 630 000 euron tuloksen (EBIT).

Asiakkuudet ja yhteistyökumppanuudet

Saimme ilahduttavan monta uutta asiakasta viime vuonna, jonka lisäksi yhteistyö useiden olemassa olevien asiakkuuksien kanssa on tiivistynyt. Vuoden aikana olemme päässeet kertomaan mm. tuoreesta yhteistyöstä Kempin kanssa sekä pitkäjänteisestä kumppanuudesta Postin kanssa. Syvensimme myös yhteistyötä AWS:n kanssa sekä valikoitujen muiden kumppaneiden kanssa.

Ensimmäinen Webscale Tech Days

Järjestimme viime keväänä yhtiön ensimmäisen Webscale Tech Daysin, joka on sisäinen teknologiakonferenssi ja virkistystapahtuma. Tapahtumapaikkana toimi monipuolinen liikunta- ja luontomatkailukeskus Eerikkälä, joka tarjosi loistavat puitteet yhteisille keskusteluille, harrasteille ja oppimiskokemuksille. Tapahtuma tulee jatkossa olemaan jokavuotinen perinne.

Henkilöstörahasto

Alkuvuodesta perustimme henkilöstörahaston, joka on nyt oleellinen osa kannustinjärjestelmäämme. Rahasto on koettu erittäin positiiviseksi henkilöstöeduksi.

Vaalipalvelut

Vaalipalvelutiimimme kasvoi vuoden aikana ja panostimme tuotekehitykseen. Vuoden 2022 merkittäviä saavutuksia olivat seurakuntavaalien tietojärjestelmähanke sekä aluevaalit, jolloin toimimme usean mediatalon yhteistyökumppanina vaalikoneiden ja tulospalveluiden osalta. Lisäksi toimitimme vaalikoneita lukuisille yhdistyksille, järjestöille ja liitoille.

Uusi toimisto

Kasvu vei meidät uuteen upeaan toimistoon Yrjönkadulle, josta onkin tullut nopeasti merkittävä kohtaamispaikka hybridityössä.

Yhteisellä matkalla

Vielä kerran iso kiitos koko henkilöstöllemme, kaikille asiakkaillemme sekä yhteistyökumppaneille luottamuksesta ja hyvästä yhteistyöstä. Kanssanne on mahtava tehdä töitä!

Pääset seuraamaan Webscalen kuulumisia ja tekemisiä somessa

Webscale on nyt myös AWS Public Sector Partner

Fri, 17 Mar 2023 08:11:12 GMT

Webscale on nyt myös Amazon Web Servicesin julkisen sektorin kumppani ( AWS Public Sector Partner ).

"Olemme pitkäjänteisesti kehittäneet toimintaamme ja kumppaniohjelma vahvistaa entisestään kykyämme palvella myös julkisen sektorin asiakkuuksia. Haluamme olla aktiivisesti suunnittelemassa ja rakentamassa toimivia sähköisiä palveluita sekä niihin liittyviä pilviympäristöjä niin nykyisille kuin uusille julkisen sektorin asiakkaille." kertoo Webscalen toimitusjohtaja Tero Kauhanen.

Pilvipalveluista on muodostunut keskeinen palvelumuoto julkisella sektorilla. Niiden kiistattomia hyötyjä ovat mm. skaalautuvuus, ketteryys ja jatkuvasti kehittyvät palvelut. Julkinen pilvi tukee lisäksi hyvin tuotekehitystä tekeviä organisaatioita, joissa DevOps-menetelmän avulla saadaan palvelut nopeasti ideasta tuotantoon.

Webscale on jo vuodesta 2014 lähtien toiminut AWS:n konsultointikumppanina ja on nykyään julkisen sektorin kumppanuuden lisäksi AWS Advanced Consulting Partner ja AWS-pilvipalveluiden jälleenmyyjä . Webscale on sopimustoimittajana useissa julkisen sektorin dynaamisissa hankintajärjestelmissä ja pienhankintapalveluissa.

Kysy konsultilta: Miksi devaajan kannattaa oppia käyttämään TypeScriptiä?

sara.peltola@webscale.fi (Sara Peltola) — Wed, 08 Mar 2023 08:25:11 GMT

Miksi devaajan kannattaa oppia käyttämään TypeScriptiä?

TypeScript on JavaScriptin laajempi versio. Se tarjoaa samat ominaisuudet kuin JavaScript, mutta lisäksi myös muita ominaisuuksia. Tärkeimpänä näistä on tyypitys eli mahdollisuus määrittää tyyppi esimerkiksi muuttujille. Tyypityksen ansiosta voidaan välttää monia virheitä, koska kehittäjän IDE ja TypeScript-kääntäjä osaavat tunnistaa, jos koodia yritetään käyttää vastoin määritettyä tyypitystä. Myös koodin kehittäminen on miellyttävää, sillä refaktorointi on helpompaa tyypityksen toimiessa eräänlaisena turvaverkkona. Tyypitetty koodi myös dokumentoi itseään paremmin.

TypeScript on laajasti käytössä ja sillä on suuri yhteisö eli sitä pääsee käyttämään monissa projekteissa sekä apua ongelmatilanteissa saa hyvin.

Jukka Ukkonen

Senior Consultant

Joustavuutta ja vapautta tarjoava työympäristö ei ole ollut pelkkää mainospuhetta - esittelyssä uudet webscalerit Timo ja Juho

Mon, 06 Feb 2023 10:15:43 GMT

Webscaleen saatiin vuodenvaihteen molemmin puolin lisää vahvistuksia niin rekrytointitiimiin kuin asiakasprojektienkin pariin. Tiimiin liittyneet Talent Acquisition Specialist Juho Sopanen ja Senior Consultant Timo Laakso kertovat ensikokemuksistaan uudessa työssään. Erilaisissa rooleissa työskentelevien tuoreiden webscalereiden ensitunnelmat ovat olleet positiiviset, vaikka myös uuden oppimista on alkutaival sisältänyt riittämiin. Mutta miten he kokevat vapaa-ajan ja työn yhteensovittamisen onnistuneen uudessa työssään Webscalella?

Timo

Timo aloitti tammikuun alussa Webscalella Senior Consultantina. Hän suunnittelee ja toteuttaa asiakkaan keskitettyä log & data-platformia AWS:n päälle hyödyntäen tässä kolmannen osapuolen analyysialustoja. Timolla on pitkä tausta IT-alalta pilvipalvelujen ja ohjelmistokehityksen parista eri kokoisista yrityksistä niin julkiselta kuin yksityiseltä sektorilta. Taustansa puolesta Timo vahvistaakin vielä lisää jo entuudestaan raudanlujaa AWS-osaamistamme. Timo on viihtynyt Webscalella ensimmäiset viikot todella hyvin.

”Ensimmäiset viikot Webscalella ovat sujuneet hyvin ja kaikki on toiminut moitteettomasti. Tunsin entuudestaan Webscalelta jo kollega Mikan, jolta pystyin kyselemään kaikenlaista ennakkoon. Nyt aloitettuani työt ovat kaikki muutkin olleet avuliaita ja erityisesti olen tykännyt kollega Jussin avusta projektin onboardauksessa. Häneltä olen voinut rohkeasti kysellä kaikenlaista mitä mielen päällä on ollut. Tämä on auttanut todella paljon pääsemään sisään työhön”, Timo kehuu samassa projektissa työskentelevää tiimikaveriaan.

Webscalella työskentelyssä Timo on tykännyt itse asiakastyön lisäksi siitä, että erilaisten palaverien ja muiden tapaamisten aikataulut ovat pääasiassa hyvin tiedossa etukäteen. Tämä helpottaa työpäivien rytmityksen suunnittelua. Hän kokee lisäksi, että kaikki asiat mitä ennen töiden aloittamista on puhuttu, ovat toteutuneet, eivätkä mainospuheet esimerkiksi joustavista työajoista ole jääneet vain pelkiksi mainospuheiksi. Vapaa-ajalla Timo tykkää viettää aikaa puolisonsa ja urheilun parissa. Timo harrastaa kamppailu-urheilua sekä käy aktiivisesti kuntosalilla ja lenkillä hikoilemassa.

Työaikoina Timon tavoittaa sähköpostitse - tai mahdollisesti myös luonnosta metsän keskeltä, sillä Timo mainitsee vaelluksen olevan hänelle muun liikkumisen ohella lähellä sydäntä.

Juho

Juho aloitti joulukuussa Talent Acquisition Specialistina vahvistaen rekrytointitiimiämme. Hänen työnkuvaansa kuuluu erityisesti rekrytointi sekä työnantajamielikuvan kehittäminen. Lisäksi Juho on osa markkinointitiimiämme. Juholta löytyy aikaisempaa työkokemusta rekrytoinneista eri yrityksistä, mutta suorahaun maailmaan hän on ottanut ensiaskeleensa Webscalella. Myös IT-alan kiemurat olivat hänelle uutta, joten uutta opittavaa on riittänyt.

”Alku Webscalella on ollut todella antoisa ja olen tykännyt saadessani rekrytoinnin ohella osallistua muun muassa somepäivitysten tekemiseen. Samaan aikaan on ollut paljon uutta opittavaa, joka on tottakai vaatinut myös kärsivällisyyttä. Apua on kuitenkin aina saanut kaikilta tarvittaessa ja erityisen kiitollinen olen kollega Varpulle, jonka kanssa varsinkin ensimmäisen kuukauden aikana kävimmekin paljon Slack-puheluja aiheesta kuin aiheesta. Molemmat olivat varmaan niiden puheluiden jälkeen mielellään hetken aivan hiljaa, jotta ääni kantaisi vielä seuraavanakin päivänä”, Juho kertoo naurahtaen välillä pitkiksi venyneistä perehdytyssessioista.

Positiivisena yllätyksenä Juholle on tullut työsuhde-etujen laajuus sekä me-henki, joka Webscalella vallitsee. Joustava hybridityö mahdollistaa työn tekemisen käytännössä mistä ja milloin vain, mutta Juhon mukaan myös toimistolle on positiivisen ilmapiirin vuoksi mukava mennä ja tilat ovat viihtyisät. Lisäksi näin uutena työntekijänä hän on kokenut, että kuukausittaiset afterit ja monthly-päivä aamiaisineen ovat mahdollistaneet hyvin tutustumisen porukkaan myös työajan ulkopuolella.

Juhoon kannattaa olla yhteydessä, jos ura Webscalella kiinnostaa. Tavoitat hänet osoitteesta juho.sopanen@webscale.fi - tai todennäköisesti myös kesällä futispeleistä Bolt Areenalta, sillä hän tunnustautuu intohimoiseksi urheilumieheksi ja HJK:n kausikortin omistajaksi.

Työn ja vapaa-ajan tasapaino

Webscale on perheystävällinen työpaikka, jossa mahdollistetaan työ- ja vapaa-ajan mahdollisimman sujuva yhteensovittaminen. Molemmat uudet webscalerit allekirjoittavat tämän viitaten esimerkiksi hybridityömalliin sekä siihen, että työt pystyy lähes aina hoitamaan kahdeksan tunnin aikaraamissa, jonka senkin liukuvasti päivän aikana. Timo työskentelee Porista käsin täysin etänä ja pääsee pitkän välimatkan vuoksi vain satunnaisesti käymään toimistollamme Helsingissä. Juholle puolestaan tämä tarkoittaa mahdollisuutta työskennellä kotitoimiston lisäksi myös Lahdessa, jossa hänen puolisonsa asuu. Meillä jokainen saakin määritellä perhe-sanan itse. Osalle perhe muodostuu puolisosta ja lapsista, osalle sukulaisista ja läheisistä esim. harrastusten ja yhteisten mielenkiintojen mukaan.

Töihin Webscaleen?

Kiinnostaisiko sinua liittyä tiimiimme? Lue lisää rekrysivuiltamme. Kuulemme mielellämme tarinasi ja otamme selvää, olisimmeko me sinulle oikea työnantaja.

Tutkimme suomalaisten keskisuurten yritysten pilvisiirtymää

Mon, 19 Dec 2022 09:59:23 GMT

Selvitimme kotimaisten suurten ja keskisuurten yritysten julkipilven käyttöä sekä mahdollisia hyötyjä ja haasteita pilveen siirtymisessä. Haastattelimme tutkimusta varten eri toimialojen yrityksiä saadaksemme tietää mahdollisimman laajasti, millaista suhtautuminen pilveä kohtaan on.

Kyselytutkimuksen kohderyhmäksi valikoitui 20-100 miljoonan euron liikevaihtoa tekevät suomalaiset osakeyhtiöt mukaan lukien pörssiyritykset.

74% yrityksistä hyödyntää pilveä

Suomalaiset yritykset hyödyntävät laajasti pilveä, sillä kyselyn mukaan 74% yrityksistä käyttää julkipilveä liiketoiminnassaan . Neljäsosa tutkimukseen osallistuneista kuitenkin kertoi, etteivät hyödynnä pilveä. Merkittävimmäksi syyksi koettiin se, ettei pilvi tuota riittävää hyötyä. Toinen merkittävä haaste on olemassa olevien järjestelmien elinkaari, joka sitoo yrityksen nykyiseen ympäristöön sopimuksen ollessa pitkä nykyisen järjestelmätoimittajan kanssa.

Erilaisia pilvialustoja

Tutkimuksen mukaan monessa suomalaisessa yrityksessä Microsoftilla ja sen julkipilvellä Azurella on vankka asema. Tämä poikkeaa kansainvälisistä tutkimuksista , joiden perusteella Amazon Web Services (AWS) on useiden vuosien ajan ollut selkeä markkinajohtaja. Tutkimuksen otosjoukko on myös pieni, joka osaltaan voi selittää eroa muihin vastaaviin tutkimuksiin.

Osalla yrityksistä oli useampia teknologioita käytössä esim. hybridipilvi tai monipilviratkaisu (multi-cloud). Jotkut yrityksistä olivat valinneet harvinaisemman pilviympäristön kuten Oracle tai kotimaisen pienemmän pilvipalvelun. Toiset taas luottivat virtuaaliseen konesaliin tai liiketoiminnan luonne vaati yksityisen pilven (private cloud) hyödyntämistä.

Mitkä asiat ovat ohjanneet yrityksiä pilven käyttöön?

Tavoitteena oli selvittää, mitkä asiat ovat ohjanneet yrityksiä siirtymään pilven käyttöön. Vastauksisssa korostuivat hyödyt, jotka moni kansainvälinenkin tutkimus on tuonut esiin: liiketoiminnan skaalautuvuus, ketteryys ja saavutettavuus koettiin pilven käyttöön ohjanneiksi tärkeimmiksi asioiksi.

Oma osaaminen koettiin merkittävimmäksi haasteeksi. Tämä selittää sen, että kustannusten ymmärtäminen tai optimointi tuottaa yrityksille haasteita.

Yritykset arvioivat heidän pilven käytön valmiutta ja pilvimaturiteettia neljän vaihtoehdon avulla.

Päätös pilveen siirtymisestä on tehty.
Matka on vasta alussa, kokeiluasteella.
Jokseenkin järjestelmällistä ja jatkuvaa kehittämistä.
Pitkälle automatisoitu ja hallittu pilvi.

Suurin osa vastaajista piti tekemistä pääsääntöisesti järjestelmällisenä jatkuvana kehittämisenä. Neljäsosa yrityksistä olivat vasta kokeiluasteella pilven käytössä. Voidaan todeta, että pilviympäristöillä ja -ratkaisuilla halutaan digitalisoida tai tukea liiketoimintaa, mutta vain osalla ne ovat aidosti liiketoiminnan edellytys.

Ne yritykset, joiden käytössä on AWS kokivat, että skaalautuvuus ja kustannussäästöt ovat ohjannut heitä pilven käyttöön. Azuren käyttäjien siirtymää on edistänyt ketteryys ja skaalautuvuus.

Taustatiedot

Tutkimus toteutettiin puhelinhaastatteluina 10-11/2022 aikana ja sen tilaajana oli Webscale Oy. Tutkimukseen osallistui yli 50 päättäjätason henkilöä suomalaisista keskisuurista yrityksistä.

Kiitos kaikille tutkimukseen osallistuneille.

Ehdokastuki takaa vaalikoneen toimivuuden

Thu, 01 Dec 2022 10:22:51 GMT

Webscalen palveluvalikoimasta löytyvä Vaalikone-palvelu ja ehdokastuki auttavat yrityksiä ja muita toimijoita tuottamaan laadukkaita vaalikoneita, jotka vastaavat sekä ehdokkaiden että äänestäjien tarpeisiin.

Tänä syksynä Vaalikone-palvelu on ollut aktiivisessa käytössä seurakuntavaalien alla. Seuraavan kerran koneet hyrähtävät käyntiin vielä suuremmalla mittakaavalla kevään 2023 eduskuntavaaleja varten. Usein hieman näkymättömämpään rooliin jäävällä ehdokastuella on keskeinen rooli vaalikoneen toimivuuden takaamisessa. Tukipalvelumme neuvoo ja auttaa ehdokkaita kaikissa vaalikoneen täyttämiseen ja profiilin luontiin liittyvissä kysymyksissä.

Vaalikoneet ovat merkittävä työkalu ehdokkaille ja äänestäjille

Vaalikoneiden merkitys jatkaa kasvuaan Suomessa. Me suomalaiset harjoitamme demokratiaa monilla yhteiskunnan osa-alueilla ja hallinnon tasoilla, minkä johdosta vaaleja on lukumäärällisesti paljon. Samalla ihmisillä on kuitenkin nyky-yhteiskunnissa entistä vähemmän mahdollisuuksia ja intoa tehdä työlästä taustatutkimusta valistuneen äänestyspäätöksen eteen. Puolueiden ja ehdokkaiden kirjo on Suomessa moninainen, mutta samalla ne ovat tulleet lähemmäksi toisiaan. Pitkät listat ehdokkaita ja puolueiden välisten suurten eroavaisuuksien hälveneminen tekevät ehdokkaan valinnasta äänestäjälle entistä haastavampaa.

Näitä taustoja vasten vaalikoneiden suosio on kasvanut viimeisen 20 vuoden aikana: ne tarjoavat ehdokkaille tasavertaisen mahdollisuuden kantojensa esittelyyn sekä auttavat äänestäjiä rajaamaan sopivia ehdokkaita suuristakin pooleista. Vaalikoneessa täytettävä profiili mahdollistaa ehdokkaan oman persoonallisuuden ja näkemysten kattavan esittelyn - profiiliin voi kirjallisesti perustella vastauksiaan, lisätä linkkejä sosiaalisen median profiileihin sekä ladata valokuvan lisäksi jopa videoklippejä.

Tampereen yliopiston vuonna 2020 julkaiseman tutkimuksen mukaan yksi vaalikoneiden suurimmista anneista on se, että ne mahdollistavat kaikille ehdokkaille tasavertaisesti näkyvyyttä ja alustan, jolla tuoda kantojaan esille. Esimerkiksi myös pienemmillä kampanjabudjeteilla operoivat tai vaikkapa ensimmäistä kertaa ehdolle asettuvat ehdokkaat pystyvät vaalikoneiden ansiosta näyttäytymään äänestäjille äärimmäisen matalalla kynnyksellä. Myös me Webscalella näemme tämän yhtenä Vaalikone-palvelun keskeisenä vahvuutena. On kuitenkin olennaista pitää mielessä, että vajavaisesti täytetyt profiilit heikentävät näkyvyyttä ja vaalikoneen optimaalista toimintaa. “Vaalikone on yhtä hyvä kuin siellä olevien ehdokkaiden määrä”, toteaa Webscalen toimitusjohtaja Tero Kauhanen. On siis tärkeää, että käyttökokemuksesta jää myönteinen mielikuva, jotta ehdokkaat täyttävät vaalikoneita mielellään jatkossakin.

Webscalen ehdokastuki työskentelee positiivisen käyttökokemuksen ja tasavertaisuuden varmistamiseksi

Vaalikoneen saavutettavuus takaa monenlaisista lähtökohdista tuleville ehdokkaille yhtäläiset mahdollisuudet tuoda näkemyksensä äänestäjien tietoisuuteen. Meidän tulee kuitenkin varmistaa, että kaikki halukkaat ehdokkaat pystyvät täyttämään profiilinsa onnistuneesti vaalikoneeseen. Jotkut tarvitsevat tässä enemmän tukea kuin toiset. Seurakuntavaalien ehdokastuessa tuli kuitenkin hyvin esille, kuinka tässä prosessissa kaikenlaisilta ehdokkailta nousee laaja skaala kysymyksiä ja tukitarpeita profiilin täyttämisen eri vaiheissa. Tasavertaisuuden toteutumisessa keskeistä on esimerkiksi se, etteivät kenenkään tietotekniset valmiudet estä vaalikoneeseen osallistumista. Me ehdokastuessa pyrimme kuromaan tätä kuilua umpeen.

Epäilemättä yleisin saamamme tukipyyntö liittyy valokuvan lataukseen. Pintapuolisesti yksinkertaiselta vaikuttava tehtävä on itse asiassa varsin ongelmallinen tänä päivänä, sillä kuvien tiedostomuotoja ja -kokoja löytyy laidasta laitaan ja vielä pellollekin. Valokuva on vaalikoneessa äärimmäisen keskeisessä roolissa, sillä luonnollisesti ehdokas jää äänestäjille paremmin mieleen mikäli nimeen on saanut yhdistettyä myös kasvot. Niinpä me ehdokastuessa ratkomme päivittäin ison pinkan kuvien lataamiseen liittyviä ongelmia. Tämän tapausluokan lisäksi yleisiä ovat esimerkiksi vaikeudet kirjautua palveluun ja jatkaa aikaisempien vastausten täydentämistä.

Vaalikoneen merkitys ehdokkaille tulee hyvin esille siinä vaiheessa, kun ehdokasprofiilien muokkausperiodi on tulossa päätökseensä. Tukipalvelun postilaatikko tulvii yhteydenottoja samalla otsikolla tai jollain sen variantilla: “ovatko vastaukseni varmasti teillä tallessa?”. Vaalikone on ehdokkaille tärkeä työkalu ja niiden huolelliseen täyttämiseen käytetään paljon aikaa. Vaalikoneita on usein myös paljon tarjolla - erityisesti valtakunnallisten vaalien aikaan - mikä tekee niihin vastaamisesta ehdokkaille varsin työlästä. Näin ollen on tärkeää, että mikäli tarve tuelle tai ihan vain vastausten tallentumisen tuplachekkaukselle nousee, siihen on nopeasti apua tarjolla. Ehdokastuessamme pyritään varmistamaan, että juuri kyseisen vaalikoneen käytöstä jää positiivinen mielikuva, ja että jokaisella ehdokkaalla on ollut mahdollisuus osallistua tähän suomalaisen demokratian keskeiseen työvälineeseen. Toisaalta tukipalveluun kilahtelevat yhteydenotot ovat myös meille erittäin tärkeä palanen laadunvarmistuksessa ja palvelujen kehittämisessä.

Näillä mietteillä suuntaamme innolla kohti ensi kevään eduskuntavaaleja ja vaalikoneita.

- Anni

Kirjoittaja työskentelee Webscalella ehdokastuessa ja opiskelee valtiotieteitä Helsingin yliopistossa.

Kannustava me-henki löytyi Webscalesta - Esittelyssä uudet webscalerit Otto, Janne ja Esa

Mon, 21 Nov 2022 12:37:33 GMT

Syksyllä Webscalessa aloittaneet Junior Cloud Engineer Otto, Software Developer Janne sekä Cloud Engineer Esa kertovat tunnelmistaan ensimmäisten työviikkojen jälkeen. Positiivisilla fiiliksillä oleva kolmikko listaa uuden työn parhaimpia puolia; avoimuus, vapaus, loistavat työsuhde-edut sekä pienemmän yrityksen mahtava me-henki!

Otto

Otto (kuvassa vasemmalla) aloitti Webscalella Junior Cloud Engineerinä. Hänen työtehtäviinsä kuuluu luoda ja ylläpitää AWS-pilvipalveluita. Työn aloitus on Oton mukaan sujunut leppoisasti. Hän pitää erityisen hyvänä puolena sitä, että perehdytykseen on varattu hyvin aikaa ja hän on saanut tutustua työtehtäviinsä rauhassa. Työpäivät ovat kuluneet opiskellen itsenäisesti sekä perehdyttäjän kanssa. AWS palveluihin Otto on perehtynyt pikkuhiljaa ja vähitellen hän on alkanut myös hoitaa pienempiä tehtäviä eri asiakkuuksille.

Ensitunnelmistaan työssä Otto kertoo; “Olen ollut yllättynyt siitä, kuinka hyvät työsuhde-edut Webscalella ovat. Sain esimerkiksi aika vapaasti valita laitteet, mitä työssäni käytän. Lisäksi toimistolla on aina limua ja muita virvokkeita saatavilla”. Vapaa-ajallaan Otto tykkää nukkua, pelata, viihdyttää kissaansa sekä viettää aikaa ystäviensä kanssa.

Janne

Janne (kuvassa keskellä) työskentelee Webscalella Vaalikonepalvelu -tiimissä, jossa hän keskittyy palvelun käyttöliittymän kehittämiseen. Janne on ollut innoissaan siitä, että pääsee tekemään vihdoin sellaista työtä, minkä lopputulosta muutkin ihmiset käyttävät. “Tein aikaisemmin lähinnä sisäisiä työkaluja maksimissaan 10 henkilölle, joten kovin moni ei ole nähnyt oman käden jälkeä”, Janne kertoo.

Aloittaessaan työt Jannea on kiinnostanut mahdollisuus päästä nimenomaan konsulttiyritykseen tekemään erilaisia projekteja ja näkemään, millaisia eri asioita ihmiset tekevät, miksi he tekevät niin ja miten itse pystyy omilla taidoillaan helpottamaan tekemistä. “Toistaiseksi ainakin kaikki vaikuttaa hyvältä ja vaalikone on niin valtava projekti, että pääsee tekemään paljon erilaisia asioita ja asiakkaat vaihtuvat eri vaaleissa”, Janne tuumii.

Webscalen työskentelytavoista Jannella on vain positiivista sanottavaa. “Kun aloitin Webscalella, avoimuus ja vapaus yllättivät. Täällä kannustetaan ottamaan kantaa ja annetaan myös rehellistä palautetta”, Janne kehuu. Työajan ulkopuolella Jannen voi löytää mm. juoksemasta, salilta treenaamasta tai pelaamasta pöytäroolipelejä.

Esa

Esa (kuvassa oikealla) tekee Webscalella AWS/pilvi-konsultointia. AWS:stä kiinnostunut Esa löysi tiensä Webscaleen tehdessään aiemmin samassa asiakasprojektissa yhteistyötä Webscalen omien konsulttien kanssa. “Juteltiin, miten asioita pitäisi tehdä oikein ja siitä tuli sellainen olo, että tuosta olen kiinnostunut ja haluaisin päästä tutustumaan Webscalen tapaan tehdä töitä” , Esa kertoo.

Esa kuvailee omaa työn aloitustaan suoraan syvään päähän heittona. Kokeneelle koodarille varoitettiin, että työssä voi olla kova oppimiskäyrä, ja Esa onkin perehtynyt kaikkeen parhaansa mukaan. Työprojektissa on ollut paikoitellen melkoinen kiire, mutta Esa haluaa pitää huolen siitä, että työt tulee kunnolla tehdyksi ja että koodin laatu ei kärsi. Esan odotukset työstä Webscalella ovat toteutuneet hyvin. “Niihin asioihin olen juuri päässyt perehtymään, mitä toivoinkin töihin tullessani” , Esa vakuuttaa. Vapaa-ajallaan Esa harrastaa pyöräilemistä, uimista sekä luonnossa liikkumista.

Me-henki

Uudet webscalerit pitävät etätyöskentelyä erittäin näppäränä etuna, mutta kaikki tekevät myös toisinaan mielellään töitä toimistolta käsin. “On mukava päästä tapaamaan työkavereita toimistolla ja tutustua heihin paremmin” , Otto pohtii.

Esalle yksi syy työpaikan vaihtamiseen oli itse asiassa se, että: “pienemmässä firmassa muodostuu helpommin me-henki”. Hyvä me -henki vaikuttaakin olevan kaikille tärkeää, ja toiveena on, että uusien työkavereiden kanssa muodostuu yhteinen tekemisen meininki. “Olisi mukavaa, että ihmisten, kenen seurassa tekee töitä 8 tuntia päivässä yhdessä, voisi viettää aikaa myös vapaa-ajalla” , Otto summailee.

Uusien webscalereiden onneksi Webscalella heittäydytäänkin usein myös yhdessä vapaalle. Erityisesti Webscalen kuukausittaiset afterworkit keräävät kiitosta. ”Tosi kiva, että niitä järkätään ja mielellään niihin osallistun. Päästään näkemään työkavereita ja kehittämään hyvää tiimihenkeä entisestään” , Janne hehkuttaa.

Töihin Webscaleen?

Kiinnostaisiko sinua liittyä tiimiimme? Lue lisää rekrysivuiltamme. Kuulemme mielellämme tarinasi ja otamme selvää, olisimmeko me sinulle oikea työnantaja.

Avoimuutta ja yksilöä tukeva yhteisö

varpu.kekkonen@webscale.fi (Varpu Kekkonen) — Mon, 07 Nov 2022 13:59:46 GMT

"Avoimuutta ja yksilöä tukeva yhteisö - tätä Webscale on minulle!" Lue lisää, mitä Talent Acquisition and Employer Branding Manager Varpu Kekkonen ajattelee Webscalesta.

Miten päädyit Webscalelle?

Päädyin Webscalelle alkuvuonna 2022. Laitoin rennon sähköpostiviestin toimitusjohtaja Tero Kauhaselle nähtyäni Talent Acquisition Specialistin työpaikkailmoituksen. Tehtävänkuvassa oli paljon mitä etsin, mutta toivoin tämän päälle myös muuta. Nopean rekrytointiprosessin jälkeen minulle oli pedattu unelmieni pesti mielenkiintoisessa kasvuyrityksessä. Se tuntui hyvältä. Täällä ihmisiä ei pakoteta muottiin, vaan muotoillaan tehtävät henkilön näköiseksi.

Mitä teet Webscalella?

Työtehtäviini Webscalella kuuluu rekrytointi meidän CTO Henri Meltauksen kanssa, HR-tehtävät, työnantajamielikuvan kehittäminen ja olenpa päässyt osaksi markkinointitiimiäkin. Tämän kaiken lisäksi olen mukana meidän strategiatyössä sekä istun johtoryhmässä.

Mainitse kolme parasta asiaa Webscalesta?

1. Avoimuus

Avoimuus on varmasti kiistatta yksi yleisimpiä yrityksen arvoja. Vaikka arvotyö on meillä vielä kesken, olen usein pohtinut sitä, onko avoimuus se arvo, jonka haluamme nostaa jalustalle vai pitäisikö tämän olla itsestäänselvyys meidän yhteisössä. Luomme avoimuuden kulttuuria ympärillemme viikoittain, osin määrätietoisesti ja osin jopa huomaamatta. Mutta mitä se avoimuus sitten on Webscalella?

Johtoryhmä ei ole salaseura. Johtoryhmässä käsitellyt asiat kerrotaan viikkoviestissä koko työyhteisölle.
Kuukausittain järjestettävä monthly ei ole vain kiva hotelliaamiainen porukalla. Siellä käsitellään yrityksen taloustilanne kuukausittain, myynnin ja HR.n status sekä jaetaan henkilötasolla projektin kuulumiset koko yhteisön kesken.
Jaamme oppimamme.
Palkkatasot ovat kaikkien nähtävillä.
Lupa ottaa puheeksi myös vaikeita asioita.

2. Itseohjautuvuus

Liian usein itseohjautuvuus sotketaan siihen, että kaikesta pitäisi selviytyä yksin. Itseohjautuvuus on taito, jota kukin henkilö voi kehittää. Itseohjautuvuudella tarkoitetaan henkilön kykyä toimia omaehtoisesti ilman ulkopuolisen ohjauksen ja kontrollin tarvetta. Sen suurimmat hyödyt ovatkin oma-aloitteisuus, päätöksenteon nopeutuminen, innovoiva ja motivoitunut työyhteisö. Webscalella hoidetaan työtehtävät itseohjautuvasti, mutta ei yksin! Tiimin tuki on ihan jokaisessa tehtävässä valtavan tärkeää, mutta kukaan ei halua kytätä tuleeko hommat tehdyksi, vaan yhteisö luottaa toisiinsa.

3. Perheystävällisyys

Se on ennenkaikkea asenne työpaikalla, joka haluaa toimia perheystävällisesti ja tukea ihmisten yhdenvertaisuutta, työyhteisön monimuotoisuutta ja tasa-arvoa. Liian usein tämän ajatellaan olevan vain lapsiperheiden juttu, vaikka kyseessä on laajempi käsite. Meillä jokainen saa määritellä perhe-sanan itse, eikä siihen tarvitse välttämättä kuulua puolisoa tai lapsia.

Minulla se kuitenkin on näin. Perheeseeni kuuluu aviomies sekä kaksi ja puoli vuotias tytär. Webscalella koen mahdolliseksi olla uraäiti. Työni onnistun hoitamaan lähes poikkeuksetta kahdeksan tunnin aika raamissa ja sekin liukuvasti. Kollegoiltani löytyy aina ymmärrystä, kun olen aamulla klo 8 siirtämässä jälleen palaveria lapseni sairastuttua. En ole kokenut elämäntilanteeni olevan este urapolullani Webscalella.

Jos saisit olla kuka tahansa webscaler yhden työpäivän ajan, kenen saappaisiin hyppäisit?

Ehdottomasti AWS pilvi-arkkitehdin! Minua kiehtoo tehtävän monipuolisuus. Olisihan se nyt siistiä päästä suunnittelemaan asiakkaan pilviarkkitehtuuria, tekemään pilvipalvelun käyttöönottoprojektia tai kehittämään asiakkaan pilviympäristöä entistä paremmiksi. Pääsisin myös työskentelemään useilla eri teknologioilla sekä hyödyntämään liiketoiminnan ymmärrystäni.

Tai noh, olenhan minä sinänsä yhden koulutuksen verran sinne puolelle hypännytkin - hassun sattuman kautta tietenkin! Eräs kollega innoissaan esitteli erästä AWS Innovation Workshopia minulle taannoin ja en enempää koulutuksesta alkanut lukemaan, vaan kirjauduin mukaan. Olin ainoa ei-tekninen henkilö koulutuksessa. Ympärilläni istui vain teknologiajohtajia ja CTO:ita. Suoritin päivän koulutuksen kuitenkin parhaani mukaan ja kyllähän sieltä käteen jäi muutakin kuin yksi epämukavuusalueen ylitys. Koulutuksesta vinkanneelle kollegalleni lupaan kuitenkin kuittailla tästä vielä pitkään!

Kiinnostaisiko sinua kuulla lisää Webscalen tarjoamista uramahdollisuuksista? Käy kurkkaamassa meidän avoimet tehtävät tai laita meille viestiä niin jutellaan lisää!

Tuhoamisen ihanuus

Fri, 30 Sep 2022 11:36:02 GMT

Parhaita työpäiviä ovat sellaiset, jossa päivän lopuksi voi todeta tuhonneensa pari tuhatta riviä ohjelmakoodia.
– H-P, Webscale

Monelle IT-järjestelmien kanssa tekemisissä oleville ei-kehittäjille saattaa tulla yllätyksenä se, että kypsän järjestelmän kehittämisessä vaikein asia on monesti vanhentuneiden osien tuhoaminen. Johtuen juuri siitä vaikeudesta se on itselleni monesti suurinta työn iloa tuottava hetki, kun vihdoin saa teilattua lopullisesti pois vanhentuneita komponentteja.

Laadukasta ylläpitoa vai toteutuksen täysi uusiminen?

Tyhjästä rakennettavien järjestelmien alkukuukausina tuotetaan merkittävä määrä koodirivejä päivittäin, mutta saavutettaessa kypsä vaihe vuoden-kahden vaiheilla olennaisesti enemmän työtä vaatii järjestelmän laadukkaana ylläpitäminen ja olemassa olevien käyttötapausten tukeminen. Tästä pari vuotta eteenpäin ja väistämättömät muutostarpeet ovat jo lisänneet koodikannan kokoa, mutta vanhasta ei ole voitu vielä luopua, koska vuosien aikana niiden järjestelmien ympärille on ehditty jo rakentaa uusia integraatiopisteitä ja käyttötarpeita.

Kehitystiimien työ ei ole aivan halpa resurssi, jolloin kehitysjohtajilta tarvitaan valistuneisuutta sijoittaa riittävä osuus tästä resurssista vanhojen järjestelmien tarkasteluun, perkaukseen ja hyvälaatuisena pitämiseen. Ohjelmistokehityksessä työkalujen, ohjelmointikielien ja kirjastojen luonteeseen liittyy se, että näitä kehitetään jatkuvasti ja vanhoista kirjastoista löydetään toinen toistaan luovempia tapoja väärinkäyttää niiden tietoturvahaavoittuvuuksia. Mikäli komponentteja ei kehitetä, loppuu niiltä usein myös tuki ja se tarkoittaa samalla haavoittuvuuksien jäämistä pysyväksi. Tällöin ainoat vaihtoehdot ovat lähteä tukemaan komponenttia itse tai luopua komponentin käytöstä ja kirjoittaa oma toteutus uusiksi.

Monesti tällaisessa tilanteessa, jossa on pakko uusia oma toteutus on paras tilaisuus arvioida kyseisen toteutuksen tarpeellisuutta nykyhetkessä ennen työn käyttämistä sen päivittämiseen.

Tarpeeksi aikaa vanhojen koodirivien läpikäyntiin

Usein huomaan itse, että jo muutenkin vanhentuneet komponentit ylläpitävät vanhentunutta toimintatapaa, josta haluttaisiin eroon ylläpidettävyyden vuoksi: Jos sama toiminnallisuus voidaan muuttaa noudattamaan nykyistä toteutustapaa, voi hyvinkin olla kannattavaa tuhota vanha toteutus kokonaan ja päivittää riippuvuudet uudelle mallille.

Tämä voi näyttäytyä uuden kehityksen kannalta tyhjäkäyntinä, josta ei saada uusia ominaisuuksia esiteltäväksi. Se on kuitenkin mielekkäämpää tyhjäkäyntiä kehitystiimin kannalta kuin vanhojen ongelmakomponenttien ylläpitämiseen kuluva aika. Varsinkin kun tiimeissä on väistämättä vaihtuvuutta tekijöissä, niin vanhentuneiden komponenttien ylläpitoon voi olla yllättävänkin vaikea löytää kunnon osaamista ja ymmärrystä niiden sielunelämästä. Kehittäjänä arvostan sitä, että on säännöllisesti käytettävissä aikaa vanhojen palikoiden perkaamiseen, päivittämiseen ja erityisesti sen liputtamiseen, että järjestelmä pitää tuhota ja päivittää uuteen.

Suurelle suomalaiselle laitevalmistajalle tehdyssä muutaman vuoden pituisessa projektissa laskimme loppuvaiheessa keskimääräisen päivittäisten koodirivien määrän muutoksen per kehittäjä. Lopputulema oli noin +5 riviä koodia per päivä. Vanhat toteutukset oli hyvissä ajoin ajettu alas ja sillä saatu pidettyä kehitystyö mielekkäänä.

AWS Summit Stockholm 2022 – Pohjoismaiden AWS-osaajat ja asiakkaat kokoontuivat

Fri, 13 May 2022 11:36:00 GMT

Toukokuun aurinkoisena päivänä reilut 6000 AWS:n käyttäjää, asiakasta ja kumppania olivat saapuneet Tukholmaan pitkästä aikaa tapaamaan kasvokkain ja kuulemaa alan uusimmista suuntauksista. Päivän avasi AWS:n Compute Services-yksikön johtaja Deepak Singh, jonka pääviesti oli innovatiiviset yritykset tarvitsevat innovatiivisen pilvikumppanin. Nopeasti muuttuvassa maailmassa pilviratkaisut auttavat yrityksiä muuttumaan sen mukana. Teknologiavalinnoilla on merkitystä Alustan valinnalla voi olla pitkäkestoisia vaikutuksia, […]

Vastuuta, vapautta ja unohtuneita salasanoja – esittelyssä Webscalen uudet tiimiläiset Varpu, Sara ja Lauri

Wed, 27 Apr 2022 10:32:00 GMT

Webscalen tiimiin hiljattain liittyneet Talent Acquisition and Employer Branding Manager Varpu Kekkonen, toimistoassistentti Sara Peltola ja Cloud Architect Lauri Siponen kertovat ensikokemuksistaan uudessa työssä. Erilaisissa rooleissa työskentelevien tuoreiden webscalelaisten tunnelmat ovat yllättävän samankaltaiset: positiivisia yllätyksiä, uuden oppimista ja ilmapiiri, jossa voi olla oma itsensä. Mutta kuka – tai ketkä – ovat useampaan otteeseen nykineet toimitusjohtajaa […]

Senioritason myyntiosaamista Webscaleen

Mon, 27 Dec 2021 07:00:00 GMT

Pitkän linjan myynnin ja markkinoinnin ammattilainen Mika Jokinen vahvistaa Webscalen myyntiä tammikuun 2022 alusta. Mikalla on lähes 30 vuoden kokemus asiakastyöstä sekä ratkaisumyynnistä. Päätös Webscaleen siirtymisestä syntyi yhteistyön kautta. Mika on viimeksi toiminut yrittäjänä, auttanut asiakkaita myynnissä ja liiketoiminnan kehittämisessä.

Identity and access management (IAM) in AWS cloud

Fri, 28 May 2021 05:00:00 GMT

Introduction to Identity and Access Management

Identity and access management (IAM) is a combination of tools and processes to identify, authenticate and authorise access to resources to keep systems and data secured. With IAM we can ensure that the source entity (users, groups, applications, devices, etc.) accessing a resource is who they say they are before access control determines their level of access and grants or denies their access. Access control allows system administrators to add and edit source entities, but also determine their access level. Best practice for determining level of access is to grant only the minimum required access. IAM acts in a crucial role of systems security, and it’s extremely important to do it correctly.

AWS Identity and Access Management

Amazon Web Services (AWS) has a service called AWS Identity and Access Management (or IAM in short) and it enables AWS users to control access and permissions to AWS services and resources, for free! IAM is one of the core services in AWS, and it is integrated into most of the AWS services ^[1] . In this blog post I am going to showcase some basic functions of IAM.

“IAM lets you manage permissions for your users and applications, use identity federation to manage access to an AWS account, and analyze access to resources and services.”

https://aws.amazon.com/iam/features/

IAM roles & IAM users

In the AWS world the source entities are AWS IAM users and AWS IAM roles. There are few key differences between these two. IAM users have long-term credentials and are used to directly access AWS services. IAM roles are meant to be assumed by authorised entities before accessing AWS services, when an authorised entity assumes an IAM role a new session is created. The maximum duration for a session is 12 hours ^[2] . IAM users are usually created for a person or an application to interact with AWS. IAM roles on the other hand are intended to be shared by anyone who has access to it. Examples of authorised entities that can assume IAM roles are IAM users, applications or AWS services like AWS lambda.

An IAM user can be assigned to one or multiple IAM groups. An IAM group is a collection of IAM users. All users within a user group will get permissions that are defined for the group. This way system administrators can specify permissions for all users in the group. This makes it easier to manage permissions of multiple similar IAM users.

https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html

Policies and Permissions

In the AWS environment policies and permissions are managed with IAM policies. There are several different policy types but in this blog post we are focusing on identity-based policies.

Access management in AWS is done by creating, editing and attaching an IAM policy to a user, role or a group. A policy is a JSON document in AWS which determines permissions of an entity when attached to one. With IAM policies we can define what the entity can and can not do. Policies support different kinds of conditions which allows even more complex setups. They are re-usable which means that the same IAM policy can be attached to multiple different entities. All the identity-based IAM policies have one or more statements which will either allow or deny specified actions. If an entity has both allow and deny statements on the same action — the deny statement overrides the allow statements ^[3] .

Real world use-cases

Now that we have understood the basic building blocks of AWS IAM, it’s time to have a look at some real world use-cases. We will cover some common scenarios and different setups that I would build with AWS IAM to overcome the obstacle. Keep in mind these setups are not the only way to solve these example scenarios.

AWS Management Console Login

A very common use-case: a new AWS account is created, and we need a way for users to login to the AWS management console. There are a few solutions that I think should be considered for this depending on what systems are already available for the team. If the team has a SAML 2.0-compliant identity provider (IdP) available, you can configure AWS Single Sign-On (AWS SSO) to allow federated users to assume an IAM role to access the management console ^[4] . We already have great blog posts about this topic and I highly suggest taking a look at them ^[5][6] . If the team does not have a SAML 2.0-compliant IdP available and maybe a fast and easy setup is required. Then I recommend creating individual IAM users and adding these users to IAM groups.

Let’s imagine a scenario where we have a small company that just created their first AWS account. This company has four employees: 1x admin, 2x developers and 1x security. It’s required that each and every employee has their own sign-in credentials and each role should have their own permissions.

IAM users for every employee is an easy solution for this scenario. Users can then be added to IAM groups that have the required permissions attached. This solution provides easy management for administrators. If a new person joins the team, it will only require a new IAM user for that person. The user can then be added to correct user groups to get the required permissions. A user can be part of multiple IAM groups, which provides flexibility and easier management.

Machine Users

In some use-cases a machine user is required. Machine users can be used to perform automated tasks like application deployment with CI/CD pipeline. AWS does offer a CI/CD solution called AWS CodeDeploy ^[7] . CodeDeploy uses an IAM role to get permissions to access AWS resources and to perform tasks for you. But what if you want to use 3rd party CI/CD solutions or even build one for yourself? No problemo, with an IAM user you can provide access to your AWS resources for automated tasks that are running outside of AWS. Since these automated tasks usually only require programmatic access to AWS, you can disable IAM users access to the management console. Access keys are long-term credentials for an IAM user, and you can use them to sign requests to the AWS CLI or AWS API. An access key consists of two different keys; an access key ID and a secret access key. These keys act as a username and password, so it’s extremely important not to share them. It is also highly recommended to rotate these keys from time to time.

Cross Account Access

Cross account access is usually required when we have an environment where resources are shared between different AWS accounts. For example, a scenario where we need to read some objects from a private S3 bucket located in a different AWS account.

To enable cross-account access a trust relationship between these accounts needs to be established. We don’t need to create a new user for everyone that needs this cross-account access. We can simply create a new IAM role with required permissions and configure this IAM role to be assumed from another AWS account with an assume role policy document ^[8][9] . When a trusted entity sends an assume request to AWS, it will get temporary credentials as a response. This means that AWS has already created a new session with these given temporary credentials, and they can be used to access AWS resources from the other AWS account.

References

[1] AWS services that work with IAM
https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html

[2] AWS IAM FAQs
https://aws.amazon.com/iam/faqs/

[3] Policy evaluation logic
https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic.html

[4] Enabling SAML 2.0 federated users to access the AWS Management Console
https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_enable-console-saml.html

[5] FEDERATED AUTHENTICATION AND SINGLE SIGN-ON IN AWS PART 1 – SSO SOLUTIONS FOR SMALLER COMPANIES
https://webscale.fi/blogi/federated-authentication-and-single-sign-on-in-aws-part-1-sso-solutions-for-smaller-companies/

[6] FEDERATED AUTHENTICATION AND SINGLE SIGN-ON IN AWS PART 2 – AWS SSO
https://webscale.fi/blogi/federated-authentication-and-single-sign-on-in-aws-part-2-aws-sso/

[7] AWS CodeDeploy features
https://aws.amazon.com/codedeploy/features/

[8] IAM tutorial: Delegate access across AWS accounts using IAM roles
https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_cross-account-with-roles.html

[9] Delegating API Access to AWS Services Using IAM Roles
https://aws.amazon.com/blogs/security/delegating-api-access-to-aws-services-using-iam-roles/

Viikon konsulttikysymys: Mitä hyötyä on DevOps -toimintamallista?

Wed, 03 Mar 2021 13:53:00 GMT

Mitä hyötyä on DevOps -toimintamallista?

Helppo kysymys, mutta laaja ja monitahoinen aihe – kysymys, johon ei ole yksiselitteistä vastausta. DevOps käsitteenä nimittäin ei tarkoita mitään tiettyä työkalua, tiimiä, toimintatapaa tai muuta sellaista. DevOps on ennemminkin ajattelutapa – ideologia, joka lähtee liikkeelle ohjelmistokehityksen ja koko organisaation kulttuurista, eli tavasta tehdä asioita, ja vaikuttaa kaikkeen tekemiseen mikä ohjelmistokehitykseen liittyy, myös bisnespuolella.

DevOps-toimintamallin perusideana on siirtyä laajoista, harvoin (esimerkiksi kerran tai kaksi vuodessa) tehtävistä tuotantoonvienneistä pieniin hallittuihin asennuksiin joita tehdään parhaimmillaan useita kertoja päivässä, tarpeen mukaan. Jotta tämä onnistuisi, pitää viimekädessä koko organisaation bisneksestä ja vaatimusmäärittelystä prosesseihin, järjestelmäarkkitehtuuriin, infrastruktuuriin ja varsinaiseen ohjelmistokehitykseen ja testaukseen tukea ketterää DevOps-pohjaista toimintamallia.

Monesti DevOpsin ajatellaan liittyvän pelkästään asennusten ja vastaavien prosessien automatisointiin jollain tähän sopivalla työkalulla. Tämä on kuitenkin vain yksi vähimmäisvaatimuksista DevOps-toimintamallin mukaiselle ohjelmistokehitykselle. Onnistunut DevOps-hanke vaatii koko organisaation tuen. Parhaimmillaan näin voidaan saavuttaa merkittävää tehokkuutta koko ohjelmistokehitysprosessissa:

Yllä on listattu vain muutamia ajatuksia DevOps-mallin hyödyistä. Käytännössä DevOps-mallin noudattaminen on vähimmäisvaatimus modernille, skaalautuvalle pilvipohjaiselle ohjelmistokehitykselle. DevOps-käytäntöjen noudattaminen myös ohjaa kokonaisuutena laadukkaampaan lopputulokseen ohjelmistokehityksessä, ja sitä kautta myös paremman lisäarvon tuottamiseen loppukäyttäjille.

Jussi Lehtiniemi
Cloud Architect, Full stack developer, konsultti.

Viikon konsulttikysymys: Mitä tekee Back end -kehittäjä?

Wed, 24 Feb 2021 07:27:00 GMT

Mitä tekee Back end -kehittäjä?

Back end -kehittäjä suunnittelee ja toteuttaa pääasiassa palvelinpuolen sovelluksia tai järjestelmiä, jotka ovat käyttöjärjestelmän alla eivätkä näy loppukäyttäjälle. Tyypillisimpiä teknologioita kehityksen kannalta ovat Node ja JVM -kielet (Java, Scala).

Esimerkiksi tyypillisessä web-sovelluksessa back end -kehitys on tiedon vastaanottamista, käsittelyä sekä siirtämistä käyttöliittymä- ja tietovarastototeutusten välillä.

Katso myös, mitä tekee Front end -kehittäjä.

Juha Mustajärvi
Full Stack Developer, konsultti.

Viikon konsulttikysymys: Mikä on Data Lake?

Wed, 17 Feb 2021 06:51:00 GMT

Mikä on Data Lake?

Data Lake on yksinkertaisesti tapa kerätä ja säilyttää suuria määriä dataa esimerkiksi analytiikkaa tai koneoppimista varten. Data Lake:ssa tallennettavan datan formaattia ei ole etukäteen määritelty, vaan samaan varastoon voidaan tallettaa esimerkiksi raakadataa erilaisista sensoreista ja rakenteellista dataa tietokantasovelluksista.

Koska dataa ei tallennusvaiheessa tarvitse käsitellä, on datan tallentaminen Data Lakeen nopeaa ja halpaa, ja dataa voidaankin kerätä suuria määriä siltä varalta, että sitä tarvitaan myöhemmin johonkin. Jos datan tallentaminen ei ole riittävän suunnitelmallista, eikä tallennettua dataa dokumentoida riittävästi, on vaarana Data Laken muuttuminen Data Swampiksi. Tällöin dataa olisi kyllä olemassa, mutta sen löytäminen ja hyödyntäminen on hankalaa tai mahdotonta.

Jari Avikainen
Data Engineer, Cloud Architect, konsultti

Viikon konsulttikysymys: Missä analytiikkaa voi hyödyntää?

Wed, 10 Feb 2021 07:41:00 GMT

Viikon konsulttikysymys-blogisarjassa konsulttimme tekevät selkoa alan termeistä ja ilmiöistä. Vastaukset on mitoitettu sopimaan pieneenkin tiedonnälkään. Tällä kertaa pureudumme ytimekkäästi siihen, kuinka analytiikkaa voi hyödyntää.

Viikon konsulttikysymys: Mikä on JavaScript?

Wed, 03 Feb 2021 06:07:00 GMT

Mikä on JavaScript?

JavaScript on joustava ja kevyt scriptauskieli, jolla voi nykyään kirjoittaa myös monimutkaisia ja tehokkaita sovelluksia. Vaikkakin alkuun JavaScript oli enemmänkin vain kiva lisä verkkosivuihin, eli esimerkiksi käytettiin animointiin, on se nykyään erittäin tehokas työkalu monille verkkokehityksen ammattilaisille.

Todella moni nykyaikainen sovellus tehdään alusta loppuun JavaScriptillä, ja suuri osa nykyaikaisista verkkosivuista tehdään tavalla tai toisella JavaScriptillä. Tätä muutosta on suurelta osin avittanut mm. Facebookin sponsoroima ja kehittämä ReactJS ohjelmointikehys , eli framework. Verkkosivujen lisäksi JavaScriptillä voi luoda myös palvelimia ja monimutkaisia pelejä. Katso myös; mitä tekee React-kehittäjä.

Jarmo Hakkarainen
Full Stack Developer, konsultti.

Viikon konsulttikysymys: Mitä AWS-sertifiointi on ja mitä hyötyä siitä on?

Wed, 27 Jan 2021 07:00:00 GMT

Mitä AWS-sertifiointi on ja mitä hyötyä siitä on?

AWS-sertifiointi on tapa osoittaa kollegoille ja asiakkaille, että AWS:n sertifikaatioon valitsemat perusasiat ovat perustasolla niin hyvin hallussa, että itse työtehtävissä näitä asioita ei tarvitse enää opiskella. Varsinaisten teknisten sertifikaatioiden vaatimustaso on AWS:llä kohtuullisen vaativa, vaikka tuo esittelytason sertifikaatti ( Cloud Practitioner ) lähinnä testaa sitä että olet jaksanut opetella tuotekuvauksen brosyyrit läpi.

Lopputuloksessa teknisen AWS-sertifikaatin suorittaminen näkyy siinä, että tekijä ymmärtää ympäristön toteutuslogiikan perusteellisemmin, ja pystyy siten rakentamaan tietoturvallisempia ja robustimpia ratkaisuja. Työntekijöitä palkatessa arkkitehtisertifikaation suorittaminen on selkeä etu valintatilanteessa.

Pitää kuitenkin muistaa, että AWS-sertifikaatti osoittaa vasta teoreettisen ymmärryksen ympäristöstä, ja vasta käytännön tekemisellä tuon opiskelun jälkeen hankitaan se todellinen kyky tuottaa hyötyä asiakkaille ja loppukäyttäjille.

Jukka Dahlbom
Head of Data Engineerin g, konsultti.

Viikon konsulttikysymys: Mitä ovat modernit pilvialustat ja kuinka ne soveltuvat eri toimialoille?

Wed, 20 Jan 2021 07:00:00 GMT

Mitä ovat modernit pilvialustat ja kuinka ne soveltuvat eri toimialoille?

Modernilla pilvialustalla tarkoitetaan internetin kautta tarjoiltavaa infrastruktuuria sovellusten kehittämiseen ja ylläpitämiseen. Pilvi toimii tarpeen mukaan sekä moottorina että rakennuspalikoina ohjelmistoille. Moottorin tehoa voidaan mitoittaa joustavasti, jopa automaattisesti, ohjelmistojen tarpeeseen ja rakennuspalikoiden osalta pilvialustat antavat useita valmiiksi määriteltyjä työkaluja erilaisten sovellusten toteuttamista varten.

Monipuolisuus, joustavuus ja tehokkuus ovat pilven ominaisuuksia joista on hyötyä toimialasta riippumatta – toimialaa tärkeämpää onkin usein miettiä kulloistakin konkreettista käyttökohdetta ja (liike)toiminnan vaatimuksia sovellukselle. Näin voidaan tunnistaa millaisten palikoiden avulla tavoitteeseen päästään parhaiten.

Mona Moilanen
Account Executive.

Viikon konsulttikysymys: Mitä tarkoittaa CloudFormation?

Wed, 13 Jan 2021 07:00:00 GMT

Mitä tarkoittaa CloudFormation?

CloudFormation on Amazon Web Services (AWS) palvelu, jota käytetään käytetään pilvipalveluiden resurssien kuvaamiseen ja hallinnointiin koodimuodossa (Infrastructure as Code, IaC). CloudFormationin kautta voidaan hallinnoida suurinta osaa AWS:n omista palveluista sekä myös kolmansien osapuolien tuottamia palveluita.

CloudFormation Template on JSON tai YAML dokumentti, joka kuvaa nipun AWS:n perusresursseja (Stack) joista sitten koostetaan toimivia kokonaisuuksia sovellusarkkitehtuurin osaksi. Templateiden avulla voidaan kuvata suurin osa sovelluksen tarvitsemista resursseista verkkoresursseista ja tietokannoista itse palveluihin. Resurssien luonti ja muokkaus voidaan automatisoida DevOps ja CI/CD käytäntöjen mukaisesti.

Jussi Lehtiniemi
Cloud Architect, Full stack developer, konsultti.

Viikon konsulttikysymys: Mitä tarkoittaa Github Actions?

Wed, 06 Jan 2021 07:00:00 GMT

Mitä tarkoittaa Github Actions?

GitHub Actions on GitHubin luoma CI/CD (“ CI/CD” on lyhenne englanninkielisistä sanoista Continuous Integration (CI) ja Continuous Delivery (CD). Näillä tarkoitetaan ohjelmistokehityksen työtapoja ja niitä palvelevia ohjelmia) työkalu, jota käyttämällä voidaan muun muassa helpottaa sovelluksien testien ajo ja sovelluksen päivittäminen automaattisesti eri ympäristöihin. GitHub Actions on erittäin muokattava, mikä mahdollistaa erilaisten tehtävien automatisoinnin.

Heikki Ma
DevOps engineer, developer, konsultti.

Viikon konsulttikysymys: Mitä tekee Node-kehittäjä?

Wed, 30 Dec 2020 07:00:00 GMT

Mitä tekee Node-kehittäjä?

Node-kehittäjä suunnittelee ja toteuttaa pääasiassa web-sovellusten palvelinpuolen (backend) sovelluksia joita suoritetaan Node.js suoritinympäristössä. Sovellukset toteutetaan JavaScript tai TypeScript ohjelmointikielellä.

Tavanomainen Node-sovellus tarjoaa rajapinnan jonka avulla se pystyy kommunikoimaan käyttöliittymän ( frontend ) tai muun osapuolen kanssa esimerkiksi HTTP-pyyntöjen välityksellä. Esimerkiksi Node-sovellus voi olla yhteydessä tietokantaan ja palauttaa dataa tietokannasta HTTP-pyynnön perusteella.

Jukka Ukkonen
Full Stack Developer, konsultti.

Viikon konsulttikysymys: Miten DevOps ja ohjelmistokehitys liittyvät toisiinsa?

Wed, 23 Dec 2020 07:00:00 GMT

Viisi tärkeää asiaa, jotka tänä vuonna korostuivat HR:n näkökulmasta

Thu, 17 Dec 2020 09:15:00 GMT

Korona vaati valmistautumista pahimpaan ja olimme kaikkien muiden tapaan aluksi hyvin epävarmoja siitä, mitä kaikkea vielä seuraisikaan. Minä ja toimitusjohtajamme Tero seurasimme aktiivisesti viranomaisten tiedotteita ja ohjeistuksia. Ensimmäinen varautumisohje koronaan annettiin maaliskuun 2. päivä. Siirryimme koko henkilöstön voimin maaliskuun alussa etätöihin, siirsimme suunniteltuja tapahtumia myöhemmäksi ja olimme onnellisia, että yksi toimintaamme jo pitkään ohjanneista arvoista on ollut etäyhteisöllisyys . Nopeasti huomasimme, että sekä henkilöstön että asiakkaiden osalta työt jatkuivat normaalisti. Olin myös ilahtunut, että kuulimme Pahimman yli -kampanjasta ja päätimme osallistua lahjoittamalla 20 euroa per Webscalen työntekijä. Haastoimme kampanjaan mukaan myös yhteystyöverkostomme tahot Qvikin , Bitfactorin , Eminen , Veren ja Modern Marketingin.

Nyt kun vuotta katsoo taaksepäin, niin viisi tärkeää asiaa korostuvat HR:n näkökulmasta:

1. Työergonomia

Työergonomian tärkeys on tullut entistäkin konkreettisemmaksi kotitoimistoilla. Meillä on mahdollista lainata kaikkea toimistolta löytyvää tarpeistoa kotiin, ja kannustamme siihen aktiivisesti.

2. Viestintä

Viestinnän tärkeys korostui entisestään. Olemme seuranneet koronaohjeistusta tarkasti ja päivittäneet sisäistä ohjeistusta niiden mukaisesti. Otimme myös alkuvuodesta käyttöön sisäisen ajankohtaisia asioita sisältävän Webscalessa tapahtuu -viestin, joka lähtee kerran viikossa jokaiselle webscalelaiselle. Slackissa on matala kynnys puhua niitä näitä työasioiden lisäksi ja usein keskustelut ovat silkkaa giphytulittelua.

3. Suunnitelmallisuus

Pyrimme huomioimaan sen, että etätyösuosituksenkin ollessa voimassa kaikki eivät pysty mielekkäästi tekemään töitä kotoa käsin. Siksi olemme koko ajan pitäneet toimiston avoinna halukkaille, mutta reunaehdoin: vain hyvin rajoitetulla ihmismäärällä, etukäteisilmoittautumisella, turvavälein, kasvomaskein.

4. Etätyö – uhka vai mahdollisuus?

Olemme yksilöitä, ja se näkyi ennenkaikkea vuoden lopulla tehdyssä henkilöstötyytyväisyyskyselyssä. Osalle etäily on sopinut niin hyvin, että toivoisi jatkossakin voivansa työskennellä pääosin kotona. Kolikon toinen puoli on etäilyn yksitoikkoisuus, jota osa on kokenut sosiaalisen puolen kadottua tapahtumienkin siirryttyä etäilyksi. Ei ole siltä kulmalta yllättävää, että moni kaipaa työkavereiden tapaamista kasvokkain.

5. Luovuus

Kun ei ole mahdollista viettää aikaa yhdessä, on pakko miettiä vaihtoehtoisia tapoja niin työn tekemiseen, kuin hauskanpitoonkin. Olemme sitkeästi pitäneet kiinni yhteisöllisyyttä lisäävistä rutiineista ja tehneet parhaamme sen eteen, että etänäkin päästään pitämään hauskaa yhdessä. Viimeisimpänä #etäyhteisöllisyys-harjoituksena reissasimme viime viikolla pikkujouluteemaisen virtuaalimatkan maailman ympäri.

Otimme myös käyttöön uuden viikkohaasteen. Joka viikko heitän tehtävän ja toivon, että mahdollisimman moni tarttuisi osallistumaan. Olemme haasteiden merkeissä esimerkiksi jakaneet kuvia luontoretkiltä ja kotikokkailuista. Olen luvannut, että näitä haasteasioita ei levitellä Slackin ulkopuolelle – mutta rikon nyt tuon lupauksen julkeasti näyttämällä pari kuvaa, joilla haasteisiin on vastattu.

Joulu on pian täällä ja on ilo huomata, että kaikki on lopulta sujunut hyvin: olemme kasvupolulla ja rekrytoinnit käynnissä. Hyvillä mielin ensi vuoteen!

Viikon konsulttikysymys: mitä tekee React-kehittäjä?

Wed, 16 Dec 2020 10:13:00 GMT

MITÄ TEKEE REACT-KEHITTÄJÄ?

React-kehittäjä suunnittelee ja toteuttaa web-sovellusten käyttöliittymiä (frontend) React-kirjaston avulla käyttäen JavaScript tai TypeScript ohjelmointikieltä. Käyttöliittymät toteutetaan erillisistä osista joita kutsutaan komponenteiksi. Kehittäjä päättää kuinka komponentti toimii ja miltä se näyttää. Komponenttien toteutus vaihtelee hyvinkin paljon eri komponenttien välillä. Toiset komponentit voivat olla hyvinkin yksinkertaisia ja pieniä, kun taas toiset voivat olla suurempia, sisältää enemmän logiikkaa ja koostua toisista komponenteista.

Jukka Ukkonen
Full Stack Developer, konsultti.

Viikon konsulttikysymys: Mitä tekee front end -kehittäjä?

Wed, 09 Dec 2020 07:00:00 GMT

Käytämme ohjelmisto- ja it-alalla termejä, jotka voivat olla vieraita varsinkin alaa tuntemattomille. Vuosien aikana olemme Webscalella huomanneet, että asiantuntijoilta myös hieman pelätään kysyä "tyhmiä" ja toivotaan, että joku kysyisi toisten puolesta jotain. Tästä ajatuksesta lähti blogimme uusi "viikon konsulttikysymys" -juttusarja, jossa asiantuntijamme vastaavat kysymyksiin, joita alallamme tulee vastaan.

Viikon konsulttikysymys: mitä tarkoitetaan ketterällä ohjelmistokehityksellä?

Wed, 02 Dec 2020 07:00:00 GMT

Viikon konsulttikysymys on uusi viikoittain julkaistava kysymyssarja, jossa asiantuntijamme vastaavat kysymyksiin, joita juuri sinä saatat pohtia.

Suuria ja pieniä vaalikoneita – aina luotettavasti

Wed, 18 Nov 2020 10:04:00 GMT

Jos olet joskus käyttänyt vaalikonetta, olet todennäköisesti ollut tekemisissä Webscalen rakentaman palvelun kanssa. Suomen suurista mediataloista Helsingin Sanomat, YLE, Alma Media ja Keskisuomalainen ovat eri vaaleissa luottaneet ammattitaitoomme, mutta yhtä hyvin samalla pohjalla toimivaan koneeseen voi törmätä vaikkapa liittojen tai yhdistysten vaaleissa.

Digimatkalla kohti kriisinsietokykyä

Tue, 17 Nov 2020 09:55:00 GMT

“Tuttu ja turvallinen” on jotain, mitä moni on varmasti kuluvan vuoden aikana kaivannut arkeensa. Organisaatiot ovat joutuneet sopeuttamaan toimintaansa tavoilla, joiden kirjo on yhtä laaja kuin näiden yhteisöjen joukko itsessäänkin. Muutokseen pakottaminen on tuonut esiin osin vahvan vastarinnan, mutta myös toisen, optimistisemman tavan suhtautua uuteen ja vieraaseen.

Olen antanut itseni havaita ilmiön, joka on verrattavissa siihen, kun jossain hulluuden ja parempaan huomiseen tähtäämisen risteyksessä ihmiskunta pyrkii Marsiin. Tuntemattomalle, haastavalle maaperälle, joka kuitenkin tarjoaa meille aivan käänteentekeviä mahdollisuuksia. Pienemmässä mittakaavassa digiloikat aina uusien liiketoimintamallien omaksumisesta tiedolla johtamiseen ja pilvimigraatioihin ovat nimittäin voineet tuntua samalta. Hypyltä vieraaseen maailmaan, epävarmuudelta siitä, kantavatko kestävyyteen ja digitaalisen liiketoiminnan parantamiseen tehdyt investoinnit lopulta hedelmää. Onkin ilahduttavaa nähdä, että epävarmuus uuden ympäriltä on hälvenemässä ja luotto hyötyjen toteutumiseen aina vain korkeampi.

Digitaaliset palvelut ja kriisinsietokyky

Lokakuun loppupuolella minulla oli ilo osallistua virtuaalitilaisuuteen, jossa Teknologiateollisuuden kasvun ja osaamisen johtaja Laura Juvonen käsitteli skenaariotyön merkitystä tämänhetkisen maailmantilanteen aiheuttamasta kuopasta nousemiseksi. Juvonen esitti puheenvuoronsa päätteeksi kysymyksen siitä kuinka meidän on mahdollista päästä kiinni muutoksen best-case skenaarioon – digivihreään kiihdytykseen. Kysymyksen ytimessä oli haaste siitä, kuinka digitaalisten palveluiden avulla voidaan saavuttaa uutta liiketoimintaetua kestävästi, samalla päivittäisen toiminnan jatkuvuudesta huolehtien. Näihin liittyen haudoimme ajatuksia pienryhmäkeskustelussa suomalaisten liiketoiminta- ja teknologiapäättäjien kanssa.

Huomattavaa itse keskustelussa ja sen aihepiirissa oli mielestäni se kuinka olennaisesti digitaalisten palveluiden toimivuus, uuden luominen ja jatkuva kehittäminen ovat sidoksissa yritysten ja yhteisöjen kriisinsietokykyyn. Oli kyseessä sitten taloudellinen, kansanterveydellinen tai ekologinen kriisi. Uskallan väittää, että tässä onnistuminen on lopputulos kahdesta tekijästä, jotka luovat positiivisen kierteen ne käyttöönsä valjastaneissa yrityksissä:

Jatkuvan kehittämisen kulttuuri ja modernien teknologioiden hyödyntäminen läpi organisaation.

Kyseessä on nimittäin kaksi toisiaan ruokkivaa voimaa. Mikäli yritykseltä tai yhteisöltä löytyy vain toista, jää kierre todennäköisemmin saavuttamatta ja näin ollen hyödyt napsimatta. Ne organisaatiot, joilla kolikon molemmat puolet ovat kunnossa, pääsevät useammin nauttimaan jatkuvasta momentumista ja paremmasta kriisinsietokyvystä uusien palveluiden rakentaessa liikevaihtoa, sekä tietopääoman pysyessä ajantasaisena ja osaajien innostuneina tekemisestään. Lisäksi organisaatiot, joissa modernien, liiketoimintaa kehittävien tietojärjestelmien hyödyt nähdään keskeisenä osana koko organisaatiokudosta, näyttävät vetävän puoleensa kovaa osaamista ja eteenpäin katsovalle kulttuurille olennaista näkemyksellisyyttä. Tämä mahdollistaa sen, että aina ei tarvitse rakentaa pyörää uudelleen, vaan jo olemassaolevaa voidaan kehittää tietoon – markkina- ja asiakasymmärrykseen – pohjautuen sekä sitä vahvistaen.

Nämä kaikki ovat tärkeitä ainesosia elinvoimaisen liiketoiminnan reseptissä, nyt ja tulevaisuudessa. Olemme jo nähneet lukuisia osoituksia siitä, kuinka jatkuvalla kehittämisellä ja digitaalisten palveluiden sekä datan hyödyntämisellä saadaan aikaan menestystarinoita toimialasta riippumatta. Tuntemattoman, uuden ja vieraan näkeminen mahdollisuutena on jo itsessään merkittävä askel ja sen kaulimiseen omaksi ja yhteisöjen hyödyksi on olemassa toimivia malleja ja asiantuntevia kumppaneita. Monesti syväosaamisen lisäksi poikkitieteellinen näkemys ja yhdessä tekeminen onkin se viimeinen silaus, kirsikka kakun päällä onnistuneessa digimatkassa.

Sillä Marsiinkaan ei kukaan lennä yksin.

Managing Organizations with Takomo

Tue, 16 Jun 2020 09:19:00 GMT

I have had my own personal AWS account for over half a decade now. Back in 2015 I didn’t have any need for multiple accounts. All my workloads were running fine within a single account. Nevertheless, my appetite grew and in 2017 I migrated to AWS Organizations. I was able to separate different functions from one another. After a while I had separate accounts for backups, shared services etc. Creating accounts is fast. However, management of all these different accounts was rather cumbersome and time consuming. Luckily Takomo can change this.

Steps taken on this post assume you are already running AWS Organizations. If not the case, you enable Organizations either via console/cli or using command tkm org create .

Please keep in mind that the default limit for accounts in Organizations is 4. If you are planning to test the features, make sure you raise the limit via support beforehand!

Creating a new account

I have been working for a while migrating my personal website from Lightsail into VPC. Things are already running smoothly on my development account and I am now ready to create a separate production account.

Before I can create a new account I need to tell Takomo I want the application to support AWS Organizations. This is done by creating a new directory (organization) and configuration file (organization.yml). Below is a bare minimum of what the configuration file should look like.

masterAccountId is used to define the organization master. It is used to ensure that organization management operations target the correct AWS organization.

organizationalUnits define the OU structure. In this example we simply define just our Master account to appear on the root OU. We’ll take a closer look at organizational units later in the post.

Now I am ready to create a fresh account.

Output of creating a new account with Takomo

My new account is now ready to be taken into use. I could access it with OrganizationAccountAccessRole . However, I want to add some core functionality to the account first.

Managing Organization

Creating new accounts is easy. I could do the same from within the console, CLI or various 3rd party tools. However, not many tools give me capability to manage the entire organization and store the entire organization structure into a configuration file.

First thing I want to do is to organize accounts into organizational units (OU). OU can be used to administer accounts as a single unit. For example, I might want to attach service control policies (SCP) to an OU. Once enabled, these policy files would affect all accounts within the OU.

organization.yml

This is the first step of configuring my organization. Next we’ll walk thru the new parameters on the configuration file:

trustedAwsServices defines trusted access for various AWS services. Takomo will enable all services by default when organization is deployed. Since I don’t want to enable everything I can list only the ones applicable for my use case.

serviceControlPolicies defines SCPs used in the organization. I have defined two policies: FullAWSAccess and AllowedRegions . First is awsManaged, meaning we use policy defined by AWS (FullAWSAccess is the default SCP. It is attached to all accounts in your Organization by default). The latter is a custom policy. The actual policyfile, called AllowedRegions.json, is located in the service-control-policies directory. In this example I limit my accounts to only use European regions and us-east-1.

AllowedRegions.json

Last changes are made on organizationalUnits . I need to define all my accounts on the configuration file in order for Takomo to work correctly. I don’t want to create a difficult structure for my existing accounts (master, shared, bc). I will keep my old accounts on Root OU. I will add a new OU (“WebProject”) where I add my development and production accounts. I will also enable additional AllowedRegions SCP to limit which regions can be used on workload accounts.

Now I can start deploying my organization with tkm org deploy command. Tool will display changes about to be done: few new OUs will be created, accounts are about to be moved to new OUs and some SCPs will be attached to accounts. Few seconds later I have my new organization structure ready!

Deployment summary after running takomo org deploy

Entire Takomo Organizations guide can be found at Takomo documentation [2].

Adding beef on top of the bones

Being able to define organization units and service control policies for accounts within AWS organization is great but let’s be honest, it only gets you so far. The real struggle is to create your base infrastructure. Perhaps you want to deploy IAM users or cross-account roles for your administrators. Or maybe you want to create a VPC and network resources into your workload accounts to limit the burden of your development team. This can be accomplished with config sets.

In the next example I will utilize Takomo to deploy a VPC stack to my development and production accounts. Once my base infrastructure is in place I could hand over these accounts to the actual development team. By default, Takomo will use OrganizationAccountAccessRole to perform this. However, I can define any role available if needed.

organization.yml with modified account information

Looking at the existing WebProject OU, we can see first changes in the configuration. I have changed the formatting of my dev and prd accounts. I have also added new sections, “vars” with CidrBlock and EnvironmentName definitions. These variables are passed to my configuration set when I want to deploy my accounts. This way I can define different CIDR blocks for my development and production VPCs.

Let’s continue to the bottom of the file. I have added a new block, “configSets”, where I define my base configuration (baseConfiguration). Naming isn’t important here, I could call it whatever I want. What is important is that I also have something on my commandPaths. In this case “/base” reflects a directory in my stacks folder. configSet is also added to my organizationalUnits configuration for my development and production accounts.

The last thing is to define the actual VPC stack. If you read my previous blog post [1] or have tried Takomo you should already be familiar with how standard Takomo stack configuration looks like. We defined baseConfiguration commandPath to be /base. After this we just need to create a new directory inside the stack configuration directory. I will create a new stacks/base/vpc.yml file and define the required parameters as below.

stacks/base/vpc.yml

If you find the text above confusing here is the whole directory tree:

Now we are ready to deploy the new VPC stacks with tkm org accounts deploy -command. The tool will present me a list of stacks about to be deployed. I am able to review my changes and proceed with the deployment. Once done, I will get a nice deployment summary telling me how my deployment went.

Now I am ready to start working with my new accounts!

If you are looking for more guidance how to manage Organizations with Takomo, take a look at official Takomo example [3].

In the next part of the series we will take a look at the advanced features of Takomo, including custom stack resolvers. Stay tuned!

[1] https://webscale.fi/blogi/introducing-takomo-a-new-cloudformation-deployment-tool/

[2] https://takomo.io/config-reference/organization.html

[3] https://takomo.io/examples/managing-organization.html

Introducing Takomo – a new CloudFormation deployment tool

Wed, 20 May 2020 10:57:00 GMT

I have been using AWS CloudFormation as my main IaC tool for handling AWS resources for a better half of a decade. CloudFormation is an excellent tool to manage resources. However, it is rather low-level. Most of the time I have ended up using a wrapper tool to generate and deploy CloudFormation templates. While good, usually these tools have lacked some functionality. This in mind, my colleague Henri has created Takomo (engl. forge). Takomo is inspired by Cloudreach’s excellent Sceptre, a CloudFormation wrapper tool built with Python, and Terraform built by Hashicorp.

Built with large-scale deployments in mind, Takomo brings some cool extra features on top of your standard CloudFormation tooling, including:

Full list of features can be found at [1].

First Run

Installing Takomo is easy, thanks to the NPM package. Following quick-start guide [2] I am up to speed in no time. Stack deployment is launched with a simple tkm stacks deploy -command. Below is an example output of command.

When I deploy my basic VPC stack for the first time I see something I haven’t seen with other tools before: I am prompted twice whether I want to proceed. First prompt confirms whether the role and account I am using are correct. Next prompt is from the CloudFormation Change Set. Once approved, I am able to deploy the stack. After a while I have my freshly created VPC up and running.

I personally use Change Sets quite frequently. Whenever I am changing production resources I want to verify that I am doing the right thing. Attaching the Change Set feature into the tool is a rather useful feature, at least for me.

Modifying my existing stack is easy. After making changes to the configuration and the template I simply relaunch the tool. Change Set will prompt me for changes and I can proceed with the deployment. Cleaning up stacks is just as easy. However, this time I use tkm stacks undeploy to remove my environment.

Advanced Configuration

After my initial test I want to proceed deploying something a bit more useful. I am currently running a few Lightsail instances hosting my personal website. I want to migrate the website inside VPC. My aim is to containerize the CMS and refactor some of the resources into Lambda functions. First step in the progress is to migrate the existing environment into VPC. To accomplish this I need to create the environment for EC2 instances, including VPC, subnets and other mandatory resources.

In quick start I simply created a stack configuration file, a stack template and launched the CloudFormation stack. This time I want to be able to have multiple environments. I need at least separate development and production environments. In each environment, I will have stacks related to infrastructure and applications. To achieve this, I can use Stack Groups to organize infrastructure into logical groups.

The idea of stack groups is rather simple. I can create subdirectories beneath the main stack configuration folder. Each subdirectory will be treated as a separate stack group. For example, I can create a stack group for the development environment by creating a subdirectory with name dev . Inside the dev directory I can create separate subdirectories e.g. for infrastructure and application stacks. Once done, I can also provide a base configuration for the whole stack group. For example, I can provide a list of tags or define a project name (which will be used as a prefix for all the stacks). These properties would be used by all the stacks inside the stack group. Configuration file is cascading and if needed, you can override parts or all of it in the nested directories.

Passing parameters via config.yml

When your environment is getting larger you want to be able to centralize your configuration into as few files as possible. While providing parameters for some resources can be done in the stack configuration files sometimes it can be rather cumbersome.

Takomo has extensive support for passing variables [3]. For example, I can pass variables via command line, environment variables or config.yml.

In my example, I want to define a name for my environment. I will create a new entry to my dev/config.yml and call it “Environment”. After this I can refer to the variable on my stack configuration file.

Example: stacks/config.yml

Example: stacks/dev/config.yml

Example: stacks/dev/infra/vpc.yml

Now I can pass the parameter into CloudFormation and use it e.g. when naming resources. This makes creating new environments easy. I can just duplicate my dev -folder (let’s call it prod) and modify Environment parameter on my prod/config.yml. Now I am ready to launch a separate production environment.

Fetching parameters from stack outputs with a resolver

One of the most important features of CloudFormation is the ability to refer to the outputs of other stacks. I want to split my stacks into small logical groups instead of monolithic stacks. This way I can make small, controlled changes more easily and efficiently.

One of many features of Takomo is the ability to use your own resolvers . The idea of resolvers is simple: they allow you to fetch stack input parameters from various sources. For example, you might want to create an API key to your proprietary monitoring system before launching an EC2 instance and pass the key to your instance upon launch. All you need to do is to create a custom resolver that connects to your monitoring system and creates the API key you then push into CloudFormation as a parameter.

On top custom resolvers , Takomo includes a few resolvers, including stack output resolver .

Using the resolver I don’t need to manually copy and paste parameters of resources that might change. Let me give you an example. Above I created a VPC stack. Stack consists of only VPC and nothing else. Stack outputs the ID of the VPC. I create subnets in a separate subnet stack and I need to provide the VPC ID as a parameter into the subnet stack. I can provide this information manually. All I need to do is to copy the output value and paste it into the configuration file. However, if I recreate the VPC the new VPC will have a new ID I need to manually copy and paste again. Stack output resolver automates this process for you.

Example: stacks/dev/infra/subnets.yml

With the example above I can launch my subnet stack and create required resources without manual steps.

Now I can re-launch my VPC stack and add outputs. Using these new output parameters and parameters I added into my main configuration.yml I can also launch my subnet stack and have a base environment ready to be used.

Conclusion

Takomo is something we have been using internally at Webscale for a while now. With the release of Takomo 1.0.0 we feel like the tool is now mature enough to be launched externally.

This post is just a brief introduction to the core features of the tool. I will write another post where we will take a look at more advanced features of the tool.

If you have any questions or requests regarding the tool feel free to comment or participate in the development in Github [4].

[1] https://takomo.io/guide/#features

[2] https://takomo.io/guide/quick-start.html

[3] https://takomo.io/guide/stacks/variables-and-templating.html#variables-in-stack-group-configuration-files

[4] https://github.com/takomo-io/takomo

Lähdimme mukaan Pahimman yli -kampanjaan

Tue, 12 May 2020 11:45:00 GMT

Me Webscalessa haluamme ottaa huomioon erilaiset elämäntilanteet osana työntekoa. Kannamme vastuuta työntekijöistämme ja haluamme olla myös aktiivinen toimija yhteiskunnassa . Tiedostamme sen ikävän totuuden, että kaikilla ei ole asiat tällä hetkellä hyvin – monet perheet ovat joutuneet taloudelliseen ahdinkoon koronaviruksen aiheuttaman tilanteen myötä.

Halusimme osaltamme auttaa osallistumalla Pahimman yli -kampanjaan lahjoittamalla siihen 20 euroa per Webscalen työntekijä. Samalla haastamme mukaan seuraavat yhteistyöverkostomme tahot: Qvik , Bitfactor , Emine , Vere ja Modern Marketing . Otatteko haasteen vastaan ja haastatte edelleen 5 yritystä tai organisaatiota mukaan?

Pahimman yli on haastekampanja, joka perustettiin keräämään ruoka-apua niille vähävaraisille lapsiperheille, joiden elämää ja toimeentuloa koronakriisin vaikutukset kolhaisevat kovimmin. Lahjoitukset menevät Hope ry:lle, joka jakaa lahjoitukset perheille 300 euron arvoisina ruoka-apulahjakortteina. Lahjakortilla apua tarvitset perheet voivat hankkia välttämättömiä elintarvikkeita ja hygieniatuotteita, tarpeidensa mukaan. Hope – Yhdessä ja Yhteisesti ry on valtakunnallinen hyväntekeväisyysjärjestö, joka on auttanut vähävaraisia ja äkillisen kriisin kohdanneita lapsiperheitä ja huostaanotettuja lapsia Suomessa jo vuodesta 2009. Lue kampanjasta lisää ja osallistu: https://pahimmanyli.fi/

Miten koulutuksen hyödyt näkyvät?

Tue, 28 Apr 2020 13:14:00 GMT

Yrityksen teknisiin tai taloudellisiin mittareihin vaikuttamattomia tavoitteitakin on syytä tarkastella: Moni kiinnostava asia ei millään tavalla liity yrityksen tavoitteisiin, mutta parantaa asiantuntijan tyytyväisyyttä ja monipuolisemman osaamisen myötä tuo uusia ajattelutapoja yhteisöön.

Webscalen 2019 liikevaihdosta 3% käytettiin koulutuksen välittömiin kuluihin. Tämän lisäksi hihasta ravistamalla arvelisin että toiset 3-5 % liikevaihtoa menetettiin koulutukseen käytetyn ajan vaihtoehtoiskustannuksena. Kun vaihtuvat kustannukset edustavat vain 20% liikevaihdosta, tuo 6% on merkittävä osuus vuoden tuloksesta. Silti olen yhä vain sitä mieltä että joka vuotisena sijoituksena tuo on hyvin käytettyä panostusta: Vahvempi ammatillinen osaaminen näkyy tyytyväisissä asiakkaissa, tehtyjen virheiden puuttumisena ja näkemyksellisyytenä siitä, miten tekniset toteutukset vaikuttavat asiakkaidemme liiketoimintaan pitkälle tulevaisuuteen.

Koulutusohjelmamme sisältö liikkuu ydinosaamisemme ympärillä: Verkkopalveluiden kehitystyössä, datan käsittelyssä, AWS:n arkkitehtuuriosaamisessa, ketterien kehitysmenetelmien hallinnassa ja tietoturvasssa. Suuremmat konferenssit ovat näkyvintä toimintaa – kuluneen vuoden aikana käytiin taas AWS re:Invent issä, uudessa turvallisuusalan AWS re:Inforce ssa ja toki ScanAgile sekä Disobey kotimaisina. AWS-sertifioinnit ovat olleet koulutusvalikoimassamme alusta saakka, ja näitäkin on viime vuoden aikana tehty 13 kappaletta. IT-alalla perinteisesti sertifiointeja on pidetty yhdentekevinä, koska monet sertit ovat triviaaleja osaamisvaatimuksiltaan. AWS:n arkkitehtuurisertit ovat nähdäksemme vaikeimmasta päästä. Asiakkaamme kysyvät toisinaan näemmekö noilla sertifikaattien tuovan jotain arvoa: Meidän näkökulmastamme sertifiointi kertoo, että konsultillamme on tietty vähimmäiskäsitys tuosta kokonaisuudesta, jota ei usein pelkästään itse tekemällä saisi. Se helpottaa kommunikaatiota, ja mahdollistaa korkeammalla abstraktiotasolla suunnittelun, kun tiimin kesken ei tarvitse työn ohessa opettaa peruskäsitteitä. Varsinainen osaaminen on saavutettu toki vasta silloin, kun teoreettista osaamista on riittävän monipuolisesti käytetty ratkaisemaan todellisia ongelmia.

Sertifikaatiota 21 hengen yrityksessämme tehtiin viimeisen vuoden aikana:
2 Big Data Specialty Certification
1 AWS DevOps Professional Cert
1 AWS Professional Architect Certification
3 AWS Associate Solutions Architect Certification
6 AWS Cloud Practitioner Cert.

Nämä liitettynä aiempien vuosien serteihin, olemme tilanteessa jossa 90% henkilöstöllä on jokin AWS-sertifikaatio ja kokeneilla useampi.
Ensimmäisen sertifikaatiosuorituksen jälkeen samantasoiset Associate-sertit vaativat aina vain vähemmän vaivaa, mutta Professional-serteissä työn määrä on taas moninkertainen.

Viime kädessä koulutuksen arvo näkyy siinä, että meillä on alati kasvava tyytyväinen asiakaskunta, jotka tulevat asiakkaiksemme eivätkä lähde pois.

Linkit:
[1] Webscale, Lauri Sten: AWS Re:Inforce 2019
[2] Webscale, Kim Martesuo: Ensikertalaisen matka re:Inventiin
[3] Webscale, Jari Avikainen: Disobey 2020 through the eyes of a cloud architect
[4] Webscale, Mona Moilanen: Cloud Practitioner -sertifikaatti bisneslähtökohdista

Webscale on voittanut useita julkisia hankintakilpailutuksia

Thu, 02 Apr 2020 04:46:00 GMT

Lisäksi Webscale valittiin muun muassa Helsingin kaupungin ohjelmistokehityksen asiantuntija- ja ylläpitopalveluiden dynaamisen hankintajärjestelmään (DPS) toimittajaksi. Muita tänä vuonna voitettuja kilpailutuksia ovat Fingrid Oyj:n ICT-johdon konsultointipalvelut sekä Istekki Oy:n ICT-asiantuntija- ja konsultointipalvelut, joissa Webscale valittiin ohjelmoinnin ja sovelluskehityksen sekä IoT-palveluiden toimittajaksi.

”Digitaalisten palveluiden kehitys vaatii organisaatioilta ja yrityksiltä entistä enemmän ketteryyttä ja kykyä tehdä ratkaisuja nopeasti muuttuvassa markkinassa. Digitalisaation edistämisessä haasteita tuovat erityisesti vanhat ja monimutkaiset tietojärjestelmät, organisaatiosiilot sekä osaaja- ja osaamispula. Me tarjoamme ratkaisuja, joilla asiakkaamme pystyvät rakentamaan ja kehittämään digitaalisia palveluita nopeammin ja entistä tehokkaammin”, toteaa Webscalen toimitusjohtaja Tero Kauhanen .

Webscalen asiakkaina myös Yle sekä Hanselin kautta ministeriöitä ja yliopistoja

Vuonna 2019 Webscale teki yhteistyösopimuksen Ylen kanssa. Yle kilpailutti Tekoälyn ja koneoppimisen sekä tiedonkäsittelyn asiantuntijapalvelut. Sopimus on voimassa toistaiseksi ja Webscale tarjoaa palvelun yhdessä oululaisen BitFactor Oy:n kanssa.

Webscale on valittu myös julkisen sektorin kilpailutuksista vastaavan Hanselin sopimustoimittajaksi IT-konsultoinnissa sekä IT-konsultoinnin pienhankinnoissa. Hanselin sopimus tuo Webscalen asiakkaaksi valtionhallinnon hankintayksiköitä, kuten esimerkiksi ministeriöitä, valtion liikelaitoksia sekä yliopistoja ja ammattikorkeakouluja.

Building durable VPNs with AWS Managed VPN

Thu, 19 Mar 2020 08:00:00 GMT

Unfortunately a lot of companies don’t have a secure remote work environment. Some companies have intranet software and websites that are only accessible from the internal network. To grant remote workers access to the intranet would basically mean opening the whole intranet to the world. This is of course not what companies want to do. Having a secure virtual private network (VPN) would allow remote workers to access intranet by just whitelisting the VPN’s public IP-address in intranet’s firewall. Building a secure and scalable on-premise VPN from scratch can be really slow and expensive. That is why we show in this post how to build one using AWS Client VPN .

Introduction to AWS Client VPN

AWS Client VPN is a fully managed VPN solution from AWS, based on OpenVPN that was introduced in late 2018 [1]. It supports client authentication using Active Directory (AD) and certificate-based authentication. AD support is integrated to AWS Directory Service. The service scales automatically up and down with the number of connections. The maximum number of concurrent client connections is 2000 per Client VPN endpoint [2]. You are charged for the number of active VPN client connections per hour and the number of subnets that are associated with Client VPN per hour.

Architecture

Client VPN uses subnets as target networks. These subnets will host the AWS Elastic Network Interfaces (ENIs) for the VPN connections. These connections will be routed to the VPC NAT gateway within the same Availability Zone (AZ) for internet connection. NAT Gateways have a static IP attached to them, which can be whitelisted for intranet access. You can associate a minimum of one subnet with VPN, but for higher availability it is recommended to have multiple subnets associated.

Client VPN has a pool of IP-addresses for clients. The CIDR block of the client pool must be /22 or greater and the private subnet associated with AWS Client VPN must be /27 or greater. The CIDR block of the VPN’s IP-address pool can not overlap either one [3].

Let’s build!

We’ve created a public GitHub repository for all of the templates. See the README.md in the repository for instructions on building a scalable and durable VPN with certificate-based authentication in the AWS cloud easily and crazy fast .

[1] Introducing AWS Client VPN to Securely Access AWS and On-Premises Resources. https://aws.amazon.com/blogs/networking-and-content-delivery/introducing-aws-client-vpn-to-securely-access-aws-and-on-premises-resources/

[2] AWS Client VPN Quotas
https://docs.aws.amazon.com/vpn/latest/clientvpn-admin/limits.html

[3] Getting Started with Client VPN
https://docs.aws.amazon.com/vpn/latest/clientvpn-admin/cvpn-getting-started.html

Webscale palvelee myös korona-aikana

Tue, 17 Mar 2020 12:43:00 GMT

Webscalessa aloitimme 2.3. toimenpiteet antamalla ensimmäisen ohjeistuksen koronavirukseen varautumisesta, joka sisälsi mm. ohjeet etätyöskentelystä ja hyvästä käsihygieniasta. Seuraamme viranomaisohjeita ja olemme korottaneet valmistautumista asteittain. Olemme myös aktiivisesti tiedottaneet henkilöstölle tilanteen kehittymisestä ja neuvoneet toimimaan varotoimien mukaisesti.

Koko henkilöstömme työskentelee tällä hetkellä etänä. Tähän meillä on jo valmiina toimivat käytännöt ja työvälineet. Yksi toimintaamme jo pitkään ohjanneista arvoista on etäyhteisöllisyys. Vältämme myös matkustamista sekä olemme siirtäneet kaikki tapahtumamme myöhempään ajankohtaan tai etäyhteyksien kautta pidettäväksi.

Palvelemme kaikkia asiakkaita normaalisti ja olemme tavoitettavissa puhelimitse, sähköpostitse sekä etäyhteyksin.

Haluamme omalta osalta toimia aktiivisesti ja turvata asiakkaidemme liiketoiminnan jatkuvuutta. Poikkeuksellisina aikoina on pystyttävä myös katsomaan tulevaisuuteen, jossa digitaalisten palveluiden merkitys todennäköisesti entisestään korostuu. Voitte olla meihin yhteydessä matalalla kynnyksellä. Tarjoamme palveluitamme ja apua esimerkiksi liiketoimintakriittisten palveluiden suunnittelussa, kehittämisessä sekä ylläpidossa.

Disobey 2020 through the eyes of a cloud architect

Wed, 19 Feb 2020 10:35:00 GMT

What is Disobey?

Disobey is a security/hacker culture event that has been organised since 2015. The main event consists of talks, workshops covering a variety of security-related topics and parties. In addition, during the event the participants have a chance to try their skills in solving various security-related puzzles, such as hacking target servers that have been configured to contain some common vulnerabilities.

Learning to break into things

The 2020 event had three main program venues: the main stage for the talks, and two rooms for the various workshops. The talks covered a wide variety of topics from bypassing building access control and improving cybersecurity during business trips to escaping sandboxes and performing live memory attacks. The full event program description is available on the event website at Disobey 2020 for those interested.

I watched multiple talks on various topics. Perhaps the most immediately useful (in the sense of actionable information) for myself was the “Cyber security for business trips: Tips and tricks from a paranoid traveller”. The talk covered a wide variety of ways to make yourself a more difficult target during business travel ranging from simple “use 6-digit PIN codes for SIM cards and proper screen lock passwords instead of facial recognition or short PIN codes” to things like “cover screws in your laptop with glitter nail polish and take photos of the result in order to prevent someone from opening your laptop and installing spy chips on the motherboard undetected”. I did already add some minor new security measures to my standard practices, and will definitely consider others as well in the future.

Workshops provided a chance for hand-on learning on a variety of traditional topics such as log analysis and penetration testing, but also included things like body language, surface mount electronics assembly, and quantum computing. Both of the workshops I participated in, the log analytics and the penetration testing, required participants to use their own computers, with data or target servers being provided by the instructors. Using work laptops containing sensitive data was discouraged, and I prepared an old personal laptop of mine to be used in the event.

In the log analysis workshop the aim was to analyse log data from an imaginary company in order to find signs of shady activities using a certain log analysis tool. In the end it became apparent that an attacker had managed to install a backdoor to the company’s server and later used the backdoor to steal some customer data. The workshop was pretty useful in both making me aware of this type of attacks and the importance of taking these sorts of shenanigans into account when writing log parsers of my own.

The penetration testing workshop on the other hand gave me at least some idea of the types of tools that exist for attacking various types of servers. It was eye-opening to see how easy it is to perform e.g. SQL injection attacks on vulnerable servers when using tools designed exactly for that.

In addition to the official workshops, one area of the event venue was dedicated to lockpicking and related activities. Spread on a fair amount of tables there were both transparent training locks as well as some ordinary locks of various types, and an assortment of tensioners and lockpicks for anyone willing to test their skills. There were also people answering questions and giving tutorials on the basics of lockpicking. In addition to locks that open using keys, there were also some combination locks and even a couple of the kind of combination locks that are used in safes.

I did manage to pick a couple of the easier training locks, and also learned the basics of how one goes about figuring out the combination of a safe, but unfortunately didn’t have enough time (and patience) to actually go through the process of opening one of the training safes. I also got an answer to a question that I have been wondering from time to time: yes, the stethoscope is an actually useful tool when opening a safe and not just something they use in the movies.

The Disobey badge and other challenges

Another part of the Disobey event are the various challenges and puzzles, and the electronic badge that plays an integral part in one of the puzzles. The first of the puzzles can actually be solved before the event in order to obtain a special hacker badge and a cheaper ticket to the event itself. The badge itself is a circuit board filled with all kinds of functionality, such as wifi, an audio port and a microphone, a small display and multiple RGB leds, a memory card reader, and a micro USB port for charging and shell access, plus various buttons and switches.

The start of the badge challenge involved realising that the badge has a hidden connector that could be used to connect the badge to certain suspicious-looking terminals. Connecting different combinations of badges to the terminals produced new hints that could then be used to progress further in solving the puzzle. I didn’t work on the puzzle further than that, but it seemed like something that would be interesting to check out should I go to the event again in the future.

In addition to the badge challenges there was something called the Capture the Flag competition, that involved solving different scored challenges solo or in small groups and trying to collect as many points as possible. I didn’t participate in that, so I don’t have any information on the contents of those challenges.

Final thoughts

All in all, the event was a positive experience, although I’m sure I missed some things by not going to the parties. The talks I listened to were interesting, as were the workshops and the badge challenge seemed like something that I would like to try my hand at some other time. From a professional point of view, the most useful contents were probably the tips on improving cyber security while travelling and the workshop on log analysis, but I guess it doesn’t really hurt to be more aware of different security risks that can be found in software, hardware, or for example in the access controls used in offices and the like.

Webscale löysi uuden toimitusjohtajan talon sisältä

Fri, 07 Feb 2020 09:09:00 GMT

Kauhanen on ollut osakkaana, liiketoimintajohtajana ja vastannut myynnistä ja markkinoinnista Webscalessa vuodesta 2014 lähtien. Hänellä on yli 20 vuoden kokemus alalta johdon ja myynnin eri tehtävistä.

Kauhanen aloittaa toimitusjohtajana 7. helmikuuta.

Yhtiön perustamisesta lähtien johdossa ollut Jukka Dahlbom jatkaa päätoimisesti vaativien asiakasprojektien parissa ja vastaa data- ja analytiikkapalveluiden liiketoiminnasta. Dahlbom myös toimii jatkossa Webscalen varatoimitusjohtajana.

Toimitusjohtajan tehtävästä siirtyvä Dahlbom kertoo: “Kuuden ja puolen vuoden aikana Webscale on kasvanut kolmen hengen yrityksestä yli 20 henkilöä työllistäväksi ja yli 2M€ liikevaihtoa tekeväksi yhtiöksi. Asiakkaat tuntevat meidät teknisestä huippuosaamisesta ja erinomaisesta palvelusta. Olemme onnistuneet myös luomaan vahvan yrityskulttuurin, jossa henkilökuntamme työtyytyväisyys on tärkeää.”

Yhtiön uusi toimitusjohtaja näkee tulevaisuuden selkeänä: “Edessä on seuraava kasvun vaihe, jossa tavoitteena on kehittää ja kasvattaa Webscalen asemaa ohjelmistokehitys- ja konsultointiyritysten kentässä. Yhtiössä on erittäin ammattitaitoinen porukka, jonka kanssa tiedän, että meillä on erinomaiset edellytykset vastata alan kovaan kilpailuun. Uskon johtajuudessa ihmiskeskeiseen lähestymistapaan, jossa edistetään mm. ketteriä prosesseja, itseohjautuvuutta ja emotionaalista älykkyyttä.”

Quality Software – Cheap and Fast!

Wed, 05 Feb 2020 10:07:00 GMT

Building digital services in an enterprise environment is most of the time depressingly slow and ridiculously expensive. Why? Legacy systems, organizational silos, scattered responsibilities, bad vendor contracts, complex environments, security requirements… it all adds up. A simple web form development project becomes a 1 year, 1 M€ failure.

Solution: a small team of experts to solve all the difficult technical and domain specific issues. The team should include roles like Software architect, Cloud architect, IT-administrator, Network specialist and Developer. Ideally, the team provides the fundamental building blocks for all the development teams as a service. After all, solving all the same issues in every project is irrational and expensive.

Hire the best talent. All the development teams depend on it. Automation is everything. If it can be documented, it can be automated. If it’s automated, it’s definitely documented.

Take for example creating a new DNS record

Assuming no human errors are made during the ticketing process, automation is at least 180,000 times faster.

Power to the edge. Authorize the team and their automated processes to make all the changes they need to on a daily basis. Same goes for the development teams, they should not need anyone’s involvement to do their daily work. Introduce reviews and utilize automation to build trust and consistency.

Don’t make bad contracts. If your IT infrastructure vendor charges you by the number of support tickets and for wasted capacity, is it in their interest to automate and save cost?

High reward. When your developers can focus on building the applications instead of on learning hybrid cloud routing, you can start changing the months into weeks in the release schedule. Less effort, less cost.

What I’ve described here is often referred to as DevOps . We have been building a DevOps function from scratch for a +1 Bn€ enterprise for the past year and the results are great. A team of four per tens of applications. The fastest application went from beginning of development into production in three months. DevOps is one of the things we at Webscale are really talented at.

Federated authentication and single sign-on in AWS part 2 – AWS SSO

Thu, 30 Jan 2020 09:40:00 GMT

Introduction to AWS SSO

Originally launched in 2017, AWS Single Sign-On is “ a cloud SSO service that makes it easy to centrally manage SSO access to multiple AWS accounts and business applications [1].” When launched, AWS SSO was lacking some crucial features. For example, a rather cumbersome command line login integration [2] was added only later. As an infrastructure engineer I need to switch roles and accounts multiple times per day (on support duty I might need to do this over a dozen times). Copy / pasting access keys from the browser into my command line interface just didn’t cut it. Knowing this, I had never really looked into AWS SSO as a tool I’d want to use.

Finally in late 2019 AWS announced the next evolution in Single Sign-On [3] together with AWS CLI Version 2 (still on preview mode). On top of other features (namely Azure AD support) the combination of tools supports integration with AWS CLI Version 2 and AWS SSO [4].

Taking AWS SSO into use

Setting up AWS SSO is straightforward. Once enabled on the organization master account, service will take care of initializing SSO on all the accounts within an organization. After a while, the initial setup is done and the actual service configuration can be performed.

Service configuration is also straightforward as there are only two steps to be done:

Choosing the Identity Source

Previously, AWS SSO supported only Active Directory as an identity source, either via AWS Managed Microsoft Active Directory or AD Connector. After the overhaul, the service now supports two additional identity sources. Local user directory stores users, groups, credentials and MFA assignments locally. Alternatively, external identity provider (Azure AD) can be used as well.

Out of the three options, the local user directory is the fastest to set up. Users and groups can be created with no extra steps. Using Active Directory or external identity provider requires either AWS Managed Microsoft Active Directory, AD Connector or Azure AD to be set up before the identity source can be configured.

AWS SSO supports multi-factor authentication via Google Authenticator. It is the only alternative for local directory. Active Directory can also use a Radius server; however this needs to be set up manually. External identity providers work differently. User authentication, including multi-factor authentication, is done externally before the user is redirected to AWS SSO portal.

Configuring SSO access to the accounts

The next step is to configure SSO to the accounts. This can be split into two parts:

Permission set is a collection of policies that AWS SSO uses to determine the user’s effective permissions to access a given AWS account [5]. Simply put, permission sets are IAM policies stored in AWS SSO. Permission sets are used when the service configures SSO into an AWS account. Ultimately the service creates IAM roles into AWS accounts with a specific AWS SSO SAML provider as a trusted entity.

Permission sets consist of two different kinds of policies:

Existing job function policies [6] are predefined AWS Managed Policies aligned to common job functions in the IT industry (e.g. AdministratorAccess to give full access to the account, DataScientist to give access to data analytics services and SupportUser to troubleshoot and resolve issues in an AWS account). Personally, I want to follow the principle of least privilege as closely as possible. This is also a principle we follow within our company. Instead of handing out generic roles with access to ‘*’ resources I want to be able to limit access to e.g. resources with names matching to application, environment, service type etc. In this case, custom permission sets [7] can be used. Custom permission sets can have two different types of policies: AWS managed policies (the same policies available on standard IAM) and custom policies. Unfortunately, there is no way to use standard customer managed policies. Instead, custom policies need to be typed or pasted into the console when creating permission set. This is cumbersome as the creation of custom policies cannot be scripted. Similarly, there is no way to create permission sets outside the console as there is no externally available API. This is a real handicap in my opinion.

Once created, permission sets can be assigned into accounts. The first step is to select which accounts are being configured, the next step is to select which users and groups the access is given to, and the last step is to select the permission set to be deployed. Once confirmed, AWS SSO will make changes into directory and deploy SAML identity provider and actual federated roles into the account.

AWS SSO is now set up and ready to be used.

AWS SSO user experience

Logging into AWS Management Console via AWS SSO is rather straightforward.

Next, I present a personal experience using the new command line interface with AWS SSO.

With the release of AWS CLI Version 2, AWS tries to provide seamless SSO command line login experience. The tool is still on preview [4] and it might be a good idea not to use it on production environments [8]. I tried the tool with a few different Ubuntu versions on both Vagrant and Virtualbox.

I have experience using multiple different SSO solutions together with AWS CLI. All these have one thing in common: they are all fully integrated with command line. However, this is not how AWS SSO works. It uses operating system default browser for authentication. When configuring / logging in, the tool will try to open the browser and synchronization page. Synchronization page is used to provide a verification code which pairs CLI and browsers session. Once synchronized, AWS SSO login page is presented and the user can login into AWS SSO portal and once successful, CLI can be configured with the flow similar to console login (select account, select role / permission set available). All configurations are stored to .aws/config -file. Additional profiles can be added easily into the configuration file assuming account id and role name are known.

It took me a few tries to realize how the flow is supposed to work on my Vagrant-based Ubuntu.

Upon configuring SSO, my terminal screen suddenly refreshed and opened a web page using w3m (command line browser) asking for the verification code. Unfortunately the code was no longer visible after the refresh. Once I realized that I had to close w3m, open another browser tab on my actual MacOS, paste the device authorization URL, provide authorization code, perform SSO login and finish setting up SSO on the CLI everything went as a breeze.

Strangely, my Ubuntu Bionic running on Virtualbox was not able to automatically open the browser so I had to copy and paste the information manually.

After the initial configuration I was able to use the federated role without any problems. The tool works just like a standard AWS CLI with AWS profiles.

AWS SSO with Azure AD

As I don’t have previous Azure or AzureAD experience I wanted to try AWS SSO with an external IdP.

After quickly learning the ropes and getting hang of Azure portal I proceeded following the AWS -provided setup guide [3].

Following the guide, I was able to create an external identity provider. Within 10 minutes I had my AWS SSO linked with Azure AD and ready to test the federated authentication. Unfortunately my first attempt was greeted with an error message: My application identifier (link pointing to my AWS SSO SAML) was not found in my AzureAD Directory.

After a bit of head scratching I realized my SSO id did not match the one configured on the Azure AD side. The fix was rather simple: re-downloading SAML metadata from AWS SSO and re-uploading metadata file into AzureAD application solved the issue. Knowing this, I would recommend you to set up an external identity provider on AWS SSO first before downloading AWS SSO SAML Metadata xml file and uploading it into AzureAD.

AWS SSO supports two different types of provisioning with external identity providers: automatic [9] and manual. By default, manual provisioning is used and it requires matching users (username needs to be identical) to be created into both AWS SSO and AzureAD. With automatic provisioning, Azure AD manages creation and synchronization of user accounts and groups into AWS SSO, reducing management overhead.

Automated provisioning was the last thing I tested. After a few well documented extra steps I had enabled automatic provisioning. I needed to wait a moment for the initial synchronization to take place. Once synchronized, I was able to see the users and groups created in AzureAD appear into AWS SSO and I was able to use synchronized users and groups when assigning permission sets to my AWS accounts. From here on everything worked as previously described. I had successfully set up AzureAD -based SSO into AWS.

Conclusion

There are many different aspects one needs to keep in mind when selecting single sign-on. As there can’t just be one single solution for all enterprises I have simply listed pros and cons for AWS Single Sign-On below.

Pros:

Cons:

Finally, a few pointers worth keeping in mind when setting up AWS SSO:

[1] Announcing AWS Single Sign-On. AWS 2017.
https://aws.amazon.com/about-aws/whats-new/2017/12/announcing-aws-single-sign-on–sso/

[2] How to retrieve short-term credentials for CLI use with AWS Single Sign-on. AWS 2018.
https://aws.amazon.com/blogs/security/aws-single-sign-on-now-enables-command-line-interface-access-for-aws-accounts-using-corporate-credentials/

[3] The Next Evolution in AWS Single Sign-On. AWS 2019.
https://aws.amazon.com/blogs/aws/the-next-evolution-in-aws-single-sign-on/

[4] AWS CLI v2 Preview Now Supports AWS Single Sign-On. AWS 2019.
https://aws.amazon.com/blogs/developer/aws-cli-v2-now-supports-aws-single-sign-on/

[5] https://docs.aws.amazon.com/singlesignon/latest/userguide/permissionsetsconcept.html

[6] https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html

[7] https://docs.aws.amazon.com/singlesignon/latest/userguide/howtocreatepermissionset.html

[8] https://docs.aws.amazon.com/cli/latest/userguide/install-cliv2.html

[10] https://docs.aws.amazon.com/singlesignon/latest/userguide/provision-automatically.html

Data innovaatioiden lähteenä: Mahdollista kokeilukulttuuri

Fri, 24 Jan 2020 08:16:00 GMT

Innovatiivinen yritys kulkee käytännössä jatkuvan muutoksen tietä ja kokeilukulttuuri on silloin syystäkin korostuneessa asemassa. Tämä on toki ihmisten johtamiseen liittyvä kysymys, mutta mitä tarkoittaakaan, kun mukaan tuodaan data?

Data ja innovaatiot kulkevat ihannetilantessa käsi kädessä, toisiaan tukien ja ruokkien. Enemmän dataa tuo enemmän mahdollisuuksia innovaatioille, enemmän toteutettuja ja tuotannollistettuja innovaatioita tuo enemmän dataa. Jos halutaan kasvattaa tätä positiivista kehää, on tärkeää ymmärtää mitä portteja tulee avata ja millaiset puitteet luoda jotta innovatiivinen kokeilukulttuuri on mahdollista nimenomaa käytännön ja datan tasolla. Yhtäkkiä aihe siirtyy puhtaasti ihmisen johtamisesta myös teknologian johtamiseen. Tutustutaanpa siis hieman tarkemmin siihen kuinka datatyön kulmakivi, tietoarkkitehtuuri, vaikuttaa yhtälöön!

Löysitkö itsesi loukusta?

Jos yrität rakentaa ketterää kokeilukulttuuria jähmeiden, vanhanaikaisten teknisten tietorakenteiden päälle, lopeta. Tässä syy miksi.

Maksimoidaksesi markkinoita sykähdyttävien ideoiden virran on organisaatiosi oltava markkinaa lähellä ja tunnusteltava sitä mahdollisimman monella lonkerolla. Käytännössä tämä tarkoittaa sitä, että datavarallisuutesi on oltava mahdollisimman saavutettavissa ja käytettävissä mahdollisimman monille ja vain perustelluin rajauksin.

Valtaosassa organisaatioita tietovarannot ovat tahallisesti tai tahattomasti rajoitettuja verrattain pienelle käyttäjäjoukolle, hyvin spesifejä käyttötarkoituksia varten ja todellisuudessa hyvin harvoin merkityksellisesti hyödynnettyjä. Siilojen ongelma missä tahansa tietovirroissa näkyy myös datan kohdalla ja ne ovat ensimmäinen fyysinen este joka seisoo innovaatiivisen kokeilukulttuurin rakentamisen tiellä. Datan yhdisteleminen ja kiinnostavien korrelaatioiden tai kuvioiden tunnistaminen ei ole mahdollista jos käytettävissä on vain marginaalinen työkalupakki. Haaste on onneksi selätettävissä puhkomalla siiloihin muutama aukko ja valuttamalla data niistä yhteisesti organisaation eri toimintojen käytössä olevaan muotoon.

Tähtää elastisuuteen

Moderni tietoarkkitehtuuri tarjoaa monta arvokasta etua datan kautta innovoinnille. Se on rakenteeltaan automatisoitua, turvallista ja kustannustehokkaasti skaalautuvaa. Sen avulla vältytään monilta yksittäisiin tarpeisiin rakennetuilta, käyttäjän manuaalista työtä vaativilta ratkaisuilta ja datan säilyttämiseltä useina duplikaatteina, jotka kääntyvät valvomattomina herkästi tietoturvariskeiksi. Sen avulla myös analysointi ja datan jatkotyöstö tuotteistukseen asti onnistuu nopeasti. Kun data on pilven kautta turvallisesti jaettavissa ja työstettävissä, on helppoa tehdä ketteriä kokeiluja ja prototyyppeja, mikä puolestaan rohkaisee yhä useampia tahoja tutkimaan ja hyödyntämään dataa. Tämä on hyvä asia organisaation kannalta, mutta vaatii paljon tekniseltä ratkaisulta joka sen mahdollistaa.

Yhdessä osaavien datainsinöörien kanssa rakennettu arkkitehtuuri voidaan luoda parhaiden käytäntöjen mukaisesti, kuitenkin kulloiseenkin toimintaympäristöön sovittaen. Tässä tärkeää on eri toimijoiden yhteistyö jotta tunnistetaan mikä data on merkityksellistä ja miten datan laatua voidaan parantaa jo sen kulkiessa läpi sille määrättyjen rakenteiden. Kaiken taustatyön tavoitteena tulee olla se, että loppukäyttäjille heidän varsinainen innovaatiotyönsä ja datan analysointi on mahdollisimman mutkatonta. Datan käytön mutkattomuus vapauttaa organisaation innovoijien ja strategien aikaa lisäarvon, anteeksi maalaisuuteni, tuottamiseen datan pohjalta.

Lienee sanomattakin selvää, että ajankäytön painottuessa manuaalisesta työstä luovaan työhön myös innovaatioiden synnyn sykli on nopeampi. Ja mitä tapahtuu kun innovaatioiden sykli on nopeampi? Tunnistat nopeammin mikä toimii ja mikä ei, pääset nopeammin kehittämään arvokkaaksi havaitun tuotoksen arvoa entisestään ja lopettamaan ne ratkaisut, jotka eivät suoriudu toivotulla tasolla. Sanalla sanoen nopea innovaatiosykli tekee organisaatiostasi elastisen.

Kakku kasaan

Kun haluat rakentaa data-avusteista, innovatiivista kokeilukulttuuria, aloita perustuksista. Aloita niistä palapelin reunapaloista, jotta et myöhemmin rönsyile holtittomasti. Aloita arkkitehtuurista. Varmista, että rakenteet ja infra jolla organisaatiosi dataa käsitellään, ovat parhaiden käytäntöjen mukaisia ja moderneja. Varmista, että ne kestävät kasvavan tietovirran yskimättä. Varmista, että mahdollisimman moni saa datan käyttöönsä mahdollisimman helposti ja laadukkaana. Vasta sen jälkeen varmista, että puhut innovoinnista ja ketteryydestä organisaatiossasi. Kun perustukset ovat kunnossa, voidaan vilkaista miltä luova datatyö näyttää.

Ja niin, jos et itse ole varma mitä kaikkea moderni tietoarkkitehtuuri pitää sisällään, kysy kaverilta – esimerkiksi meiltä!

Kuinka monta kiloa konsulttia laitetaan?

Wed, 15 Jan 2020 09:19:00 GMT

AWS, React, Node, Clojure, DevOps.. tarpeet on määritelty ytimekkäiksi listoiksi, joita teknologiaan perehtymätönkin osaa verrata henkilöiden ansioluetteloihin. Tämä tuntuu helposti johtavan siihen, että henkilöitä haetaan resursseina, joiden arvo määrittyy vain teknologiakokemuksen perusteella. Onko oikeasti näin?

IT-alalla, kuten usealla muullakin alalla, keskustellaan osaaja- ja osaamispulasta, joihin haetaan ratkaisua monilla tavoilla. Koulutukseen ja nuoriin osaajiin panostetaan, samoin myös työperäiseen maahanmuuttoon. IT-alan työpaikkailmoituksia ja erilaisia toimeksiantoja katsoessa kuitenkin piirtyy selkeä kuva, että moni asiakas hakee nimenomaan huippuosaajaa, jolla on tietystä teknologiasta kokemusta. Konsulteille tuntuu riittävän kysyntää tämänkin tarpeen kautta.

Mistä te löydätte niitä osaajia? Tuo on kysymys, jonka kuulen usein kertoessani meillä työskentelevän mm. kokeneita full stack -kehittäjiä ja AWS-konsultteja. Konsulttiyrityksessä meidän elinehto on, että pystymme sekä palkkaamaan että kouluttamaan henkilöitä vaativiin projekteihin ja toimeksiantoihin. Meille on myös tärkeää, että ihmiset viihtyvät työssään. Käytämme rekrytointiin ja erilaisiin ihmisten tapaamisiin paljon aikaa. Ymmärrän, ettei jokaisessa yrityksessä ole tähän mahdollisuuksia. Asiakkaidemme it- ja liiketoimintajohdon fokus on heidän omassa ydinliiketoiminnassa.

Akuuttiin osaajapulaan moni iso yritys käyttää mm. IT-agentuureja, joiden tehtävä on löytää osaajia asiakkaidensa toimeksiantoihin. Teknologiahaasteiden äärellä myös erilaiset ulkoistus- ja keskittämispalvelut saattavat vaikuttaa ainakin paperilla hyviltä ratkaisuilta. Kaikilla malleilla on varmasti oma paikkansa. Kun asiakkaan tarvetta on ratkaisemassa useampi taho, myös mahdolliset alihankintaketjut pitenevät.

Olen valitettavan usein kuitenkin nähnyt, että pitkissä alihankintaketjuissa yrityksen osaajapulaa on ratkaisemassa taho, joka ei välttämättä edes tiedä tai ymmärrä alkuperäistä tarvetta. Matkan varrella tarpeesta jää myös paljon sellaista tietoa pois, joka kiinnostaa haettua osaajaa. Fokus on tällöin resursseissa, joilta löytyy vaadittava osaaminen. Henkilön sitoutuneisuus, motivaatio ja muu osaaminen tuntuvat olevan toissijaisia asioita.

Suomessa on paljon pieniä ja keskisuuria it- ja ohjelmistokehitysyhtiöitä, joilla on huippuosaamista valitsemiltaan osaamisalueilta. Välillä on harmillista nähdä, että todellisen asiakastarpeen ja näiden osaajien välille luodaan keinotekoisesti malleja, joissa hankintaosasto pakottaa it- ja liiketoimintapäättäjiä käyttämään vain tiettyjen toimijoiden palveluita. Onneksi on paljon myös toimijoita, jotka suhtautuvat avoimesti uusiin kumppanuuksiin.

Haet sitten huippuosaajia itse tai välikäsien kautta, jaan viisi vinkkiä, jotka auttavat ainakin konsulttiyrityksiä löytämään paremmin tarpeitaan vastaavia osaajia:

Federated authentication and single sign-on in AWS part 1 – SSO solutions for smaller companies

Thu, 19 Dec 2019 10:12:00 GMT

In the first part of the blog series, Lauri will present how smaller companies can easily achieve federated SSO by using SaaS services. In the next part, we will take a look at AzureAD and AWS-provided SSO services.

Introduction

Our company has grown steadily last 24 months. While still small, we have close to 20 professionals working daily with AWS. On top of our base accounts we have a bunch of our own internal service accounts. We have sandbox accounts for each developer. Finally we operate various customer accounts, all with different authorisation requirements.

In the late 2018 we were utilising a standard, centralised IAM account. Everyone had their own, personal IAM user attached to various IAM Groups depending on the tasks-at-hand. Policies attached to Groups defined cross-account access policies and either allowed or denied access to actual workload accounts.

While we were able to have fine-grained access control and follow the principle of least privilege, approach was rather cumbersome. While I was able to switch roles rather easily in the CLI I was forced to have close to 50 different profiles on my configuration file. When using a console I had to use my personal cheat sheet to figure out the account and role I wanted to assume. Our password policy was rather strict, forcing IAM password change rather often. Whenever a consultant returned from a longer gig, password had expired requiring actions from administrators. Personally, after using MFA with push feature previously I felt typing MFA codes were rather clumsy process.

Single Sign-On with SAML

Take a look at any modern enterprise and you notice single sign-on services are everywhere. Employees sign into workstations using domain (Active Directory) username and password after which internal services can be used without providing credentials. Similarly, federation can be used to access external SaaS services.

Single Sign-On has many benefits. Users need to spend less time typing passwords or having means to store various credentials. On the other hand, company needs to spend less on IT costs thanks to unified user administration and reduced number of service desk calls. Similarly, SSO mitigates security risks as credentials are no longer handled externally when using federation.

The most typical example of single sign-on and federation has traditionally been Microsoft Active Directory with ADFS (Active Directory Federation Service). Active Directory stores user and group information. ADFS acts as an identity provider used to establish trust between the organisation and resource (e.g. 3rd party SaaS).

Whenever a user wants to access a resource, ADFS uses identity provider to verify user has sufficient privileges. ADFS issues a token which is passed to the resource using a security protocol (e.g. SAML 2.0). Once verified, access is granted and resources can be used.

Once set up, granting or revoking access to resources is straightforward. Users can be added or removed from groups in Active Directory, instantly allowing or blocking access to respective resources.

The next image illustrates how Active Directory and ADFS can be used to grant federated access to AWS. [1] and [2] provide documentation on how to set up federation.

ADFS Federation explained

Similar approach can be used with AWS command line tools [3] .

Federation with Google G-Suite

Like many companies our size, we use Google -based services instead of enterprise level tools like Exchange or Active Directory. This leads into less management overhead but unfortunately also less integration opportunities.

On early 2019 I had some spare time between customer projects. Finding our AWS login flow being suboptimal I decided to find a way to make our AWS login flow smoother with less management overhead. I had a few criteria for the solution: I wanted to be able to create user into single a directory, add user into respective groups and access into AWS would be granted automatically. Optimally, I wanted to be able to integrate other SaaS platforms into the solution. The Tool had to be able to support our in-house tool, built on top of Cognito using G-Suite user directory as identity pool.

Upon initial investigation it was discovered that Google G-Suite supports SAML 2.0 -based federation [4] . Since we already use the tool we decided to start our investigation with the tool already at hand. Testing the approach was easy. I was able to set up federation in less than 60 minutes. While being fast, setup also revealed some caveats:

While being easy to set up, we felt G-Suite -based federation would require too much development compared to ROI.

Federation with Okta

After tests with our existing tools were unsuccessful, we decided to look into other SSO services [5] . Some options (Shibboleth) were ruled out since we don’t want to maintain any infrastructure ourselves, others for various reasons (e.g. pricing, lack of information available, not satisfied with the product specifications). Finally, we had a few alternatives we thought would suit our needs:

After comparing features and integrations [6] , we decided Okta would be the optimal candidate for our next round.

Taking the tool into use was a rather easy task. After creating a user directory, initial test users and groups, we were able to implement SSO into a single AWS account within minutes. Hooking up multiple accounts was rather easy as well; Okta utilises a cross-account role when scanning accounts for suitable roles. All you need to do is to create a role and provide a list of accounts. Once set up, the application would detect rules suitable for federation after which roles could be assigned to users and roles within Okta. From an end user perspective, the tool is rather straightforward. Users can login to Okta console with credentials and Google Authenticator or push-based Okta Authenticator. Once authenticated, logging into AWS follows a process similar to the one using ADFS above. Similarly, AWS CLI can be used with a separate script [7] .

Taking Okta into use

Within a few days we realised capabilities of Okta would be enough for our company. However, we would need some automation to make life of the administrators a bit easier.

We already utilise automation heavily on all possible maintenance tasks. Creating new accounts is performed with AWS API tools. A dedicated maintenance role is also created upon account creation. What we were missing was an automated way to create Okta -related IDP, user roles and cross-account-role (for scanning accounts for suitable roles).

Lots of coffee was spent while delivering the solution.

We have been avid users of Sceptre [8] , a wrapper for CloudFormation. However, we also have an internal CloudFormation wrapper, Takomo [9] , which is built from the ground up to support multi-account environments and extensions. Therefore, it was an obvious choice to utilise Takomo when creating IAM resources for SSO integration.

Our initial workflow for IAM resource automation formed out to be the following:

We still have few manual steps not yet automated. Newly created AWS account ID has to be added to Okta manually (more about this later) before the tool is able to scan accounts for SSO -compatible roles. Once successful, we configure group and role associations manually in Okta.

Conclusion

Our proof of concept turned out to be a great success. After an initial testing phase we hooked up the tool with our user directory and performed the final migration and roll-out.

8 months later, we are very satisfied with the results. The tool has been running smoothly, however we have done some small tweaks here and there. Our initial automation was done with Sceptre before we migrated to Takomo in late 2019. We could add more features to the automation flow but so far we have tried to keep it simple. Biggest issue we’ve faced so far was related to deprecated AWS accounts. We were unable to sync Okta with newly created roles. Upon investigation we noticed the sync process was trying to fetch information from deprecated accounts not removed from a manually maintained Okta configuration, failing and exiting the whole process without noticeable output. This could be automated. However we delete accounts so rarely this is more related to the process and following the documentation.

There has been talk about hooking up Okta with other tools we use. This way we could utilise Okta more efficiently. Even with just AWS, mail and office services we find the solution worth using. It is reducing management overhead and making day-to-day operations more secure.

I recommend every organisation to have a look into utilising federated SSO with Amazon Web Services. We have done multiple implementations using various different sources (Okta, ADFS, AzureAD among others) and the end result has always been the same: increased security, less management overhead and improved efficiency due to easy access to the resources.

In the next part of the blog series we will take a closer look at AzureAD and AWS’s own SSO tool offering. Stay tuned!

References

[1] Enabling Federation to AWS Using Windows Active Directory, ADFS, and SAML 2.0. AWS 2013.

https://aws.amazon.com/blogs/security/enabling-federation-to-aws-using-windows-active-directory-adfs-and-saml-2-0/

[2] AWS Federated Authentication with Active Directory Federation Services (AD FS). AWS 2018.

https://aws.amazon.com/blogs/security/aws-federated-authentication-with-active-directory-federation-services-ad-fs/

[3] How to Implement Federated API and CLI Access Using SAML 2.0 and AD FS. AWS 2015.

https://aws.amazon.com/blogs/security/how-to-implement-federated-api-and-cli-access-using-saml-2-0-and-ad-fs/

[4] How to Set Up Federated Single Sign-On to AWS Using Google Apps. AWS 2016.

https://aws.amazon.com/blogs/security/how-to-set-up-federated-single-sign-on-to-aws-using-google-apps/

[5] Integrating Third-Party SAML Solution Providers with AWS. AWS.

https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_saml_3rd-party.html

[6] https://www.okta.com/okta-integration-network/#Categories.

https://www.okta.com/okta-integration-network/#Categories

[7] okta-awscli – Retrieve AWS credentials from Okta.

https://github.com/jmhale/okta-awscli

[8] Sceptre, a tool to drive CloudFormation. Cloudreach.

https://sceptre.cloudreach.com/

[9] Takomo, organize, parametrize and deploy your CloudFormation stacks. Webscale Oy.

https://takomo.io/

Ensikertalaisen matka re:Inventiin

Mon, 16 Dec 2019 06:00:00 GMT

Webscalelta lähetetään joka vuosi pieni poppoo AWS:n järjestämään re:Invent -konferenssiin. Tänä vuonna Las Vegasissa järjestettävään konferenssiin lähti H-P ja minä. H-P:lle tämä oli neljäs ja minulle ensimmäinen kerta konferenssissa. En ollut ennen käynyt Amerikassa saatika tämän kokoluokan konferenssissa, joten kieltämättä olin innoissani reissusta. Onnekseni re:Invent-konkari H-P oli mukana matkassa, joten ihan kaikkea minun ei tarvinnut oppia kantapään kautta. Tässä kirjoituksessa kerron ensikertalaisen matkasta re:Inventiin.

Re:Invent on AWS:n jokavuotinen Las Vegasissa järjestettävä noin viikon kestävä konferenssi. Tapahtumassa on tuhansia AWS:n ja AWS:n asiakkaiden pitämiä luentoja, workshoppeja, chalk-talkeja, sekä paljon muuta. Kävijöitä on kymmeniä tuhansia ja re:Invent onkin yksi alan suurimpia konferensseja.

Vegasista varasimme hotellihuoneen The Venetianista, joka oli konferenssin pääasiallinen tapahtumapaikka. Tämän takia meillä oli lyhyt matka sessioiden ja huoneen välillä. Näin ollen ei tarvinnut päivän mittaan matkustaa pitkiä matkoja, ja tarvittaessa pääsi pitkien päivien aikana välillä huoneeseen rauhoittumaan. Sessioita järjestettiin myös muissa lähialueen hotelleissa.

Suurin osa sessioista julkistetaan ennen konferenssia ja onkin syytä varata mieleiset hyvissä ajoin, että varmasti saa paikkoja. Sessiot menevät nopeasti täyteen, mutta kokemus osoitti, että hyvin saattaa päästä mukaan myös ns. Walk-up jonoista. Eli vaikka ei olisi sessioon varannut paikkaa, niin menemällä paikan päälle jonottamaan voi hyvin mahtua vielä mukaan. Itse valitsin sessioita koskien muun muassa koneoppimista, arkkitehtuureja ja serverlessiä.

Aikaisemmista vuosista poiketen tänä vuonna AWS:n johtohahmojen pitämiin pääpuheisiin piti varata istumapaikka etukäteen. Kun paikkojen varaus avattiin yritin saman tien tehdä varauksen, mutta paikat täyttyivät muutamassa minuutissa. Pääpuheissa on tapana julkistaa uusia AWS:n palveluita. Puheet näkee tosin striimattuna netistä ja konferenssissa on myös järjestetty striimien katselupaikkoja. Tänä vuonna merkittävimmät julkistukset koskivat yrityksen koneoppimispalvelua SageMakeria . Uudet ominaisuudet helpottavat koneoppimisen käyttöönottoa ja kokeilua.

Kokemukseni mukaan konferenssin järjestelyt sujuivat hyvin, eikä mihinkään tarvinnut pahemmin jonottaa. Tapahtumapaikkojen välillä pystyi kätevästi matkaamaan hyvin järjestetyllä bussikuljetuksella. Lounaiden tarjoilu sujui myös hyvin, vaikka operaation volyymi oli massiivinen. Ahkerimmille sessioissa käyville tarjottiin myös valmiita “juoksulounaita”.

Las Vegasissa kannattaa kulkea Überilla. Sovellus toimii kaupungissa loistavasti ja autoja on aina tarjolla lyhyellä odotusajalla. Samalla tippaaminen sujuu kätevästi. Yhdysvalloissa kannattaakin varautua paikalliseen tippauskulttuuriin ja Vegasissa yleisesti kalliiseen hintatasoon.

Saavuimme H-P:n kanssa paikalle sunnuntaina ja konferenssi alkoi maanantaina. Ensimmäiset päivät menivätkin aikamoisessa jetlagissa. Mikäli mahdollista, kannattaa lentää Vegasiin muutama päivä ennen konferenssia, jotta ehtii selvitä pahimmasta jetlagista. Kaupungissa on runsaasti nähtävää ja tehtävää, joten on kiva päästä katselemaan paikkoja muutama päivä ennen konferenssia.

Ps. Valmistaudu henkisesti erittäin vahvoihin drinkkeihin ��

Crowdsourced data labeling with AWS SageMaker Ground Truth

Thu, 12 Dec 2019 10:36:00 GMT

What is data labeling needed for?

After the initial idea of what to solve as a machine learning problem, you are going to need high quality training data. Generation of raw data is fairly straightforward, but transforming that raw data into useful, meaningful, and machine-interpretable training data requires human effort. Data labels for images are named areas of image which contain specific objects.

Computer vision can also detect objects in images, and defining a reasonable set of object types to detect can improve the machine labeling accuracy. Computer labeling with improper objects produces low quality results. An extreme form of this has been made into art by DeepDream, which created nightmarish renditions of dogs from images of jellyfish, for example.

For our purpose, we use data labeling by humans to create data labels. These data labels will be used to train the machine learning model to classify similar situations.

How does Ground Truth help

Ground Truth is a crowdsourcing service for running labeling jobs provided as a part of AWS SageMaker, a machine learning service suite. It is a platform for setting up, running and staffing your labeling jobs online. You can either have the labeling jobs be worked on by your own staff, or use Mechanical Turk for finding workers to label for you.

When using Mechanical Turkers as workforce, you set the task pricing. There is a recommended price for a given estimate of time required to complete single task. Ground Truth has a set of image labeling tasks which each has a selection of durations. As with Mechanical Turk, having a higher price relative to task duration will make the task more interesting for Turkers to complete early.

Price for labeling the data set is multiplication of the image set size, the price per task and number of workers per task. Ground Truth runs the same labeling job on several human labelers to improve accuracy and to find outlier results by single labeler.

With a good instruction set, a reasonably sized data set could be labeled in a day with very little organizing required, leaving you free to focus on the ML problem.

How do you set it up technically

As the training data is viewed by unknown parties and stored by AWS, any sensitive content in the training images needs to be anonymized. In my prototype case, I preprocessed training images, removing all metadata EXIF and renaming the images to remove the timestamp in the name.

The training images need to be stored in S3. As usual, the S3 bucket should be limited to as little visibility and permissions as possible. Trial, error and tutorial resources showed that at least the following S3 bucket features need to be allowed.

Cloudformation YAML template for the Ground Truth role policy allows Cognito actions in addition to accessing the files.

A manifest file of all training images is used as input to the labeling task. This is in the simplest form a list of S3 objects.

Labeling job instructions

Hardest part of the task creation is determining the best labeling criteria, and creating clear, non-ambiguous instructions on how to meet those criteria. The image above was a result of multi-class labeling job. The possible labels were “sidewalk”, “bike path”, “car on road” and “car on sidewalk”. As seen by the overlapping green and orange bounding boxes, my instructions were unclear, and led to labeling of the car to being both “on road” and “on sidewalk”.

Instructions should include both description of what is a good object to label as well as how bounding box should be fit around the object. Partially visible objects is another issue for instructions. My task required labelers to label the sidewalk in an image, which is always only partially shown.

In many labeling cases it might be useful to use several tasks to label single class each.

Results for the example task and further development

The output from this labeling work is a JSON list of labels with confidence ratings. Confidence is calculated by how well the labeling results for the image match across several labelers outputs. Labeling confidence for many objects is low, due to street environment being cluttered with lot of objects. I assume this street imagery leads to having too many unclear objects and street areas which have very subjective bounds.

Especially the sidewalks are labeled with low confidence. This could be improved by using semantic segmentation, or pixel areas, for labeling exact areas instead.

Labeling cars is also a common task, and COCO dataset already contains a large number of imagery with cars in them. Having humans label mere existence of cars in the image set is waste of resources.

Once the initial model for detecting interesting features in images is in place, the human processing tasks would become more valuable in validating results of ML classification tasks.

Data innovaatioiden lähteenä

Wed, 13 Nov 2019 08:44:00 GMT

Innovatiivisuus ja uudistumiskyky ovat yrityksen aortta. Niiden kautta mahdollistuu uuden vireyden kuljettaminen organisaation kudokseen, toiminnan pitkäjänteinen ylläpito ja elinvoimaisuus. Innovatiivisuus on yksi yrityksen strategisesti merkittävimpiä kyvykkyyksiä.

Liiketoimintaa perinteisesti tarkastellen strategian perimmäinen tarkoitus on löytää yrityksen tavoitteita tukeva pitkäkestoinen kilpailuetu ja tuoda se käytäntöön. Totuus on, ettei elämällämme aikakaudella voi enää puhua pitkäkestoisesta kilpailuedusta yksikössä, sinä autuuden tuovana graalin maljana jonka löydettyään organisaation strategit voivat huokaista helpotuksesta, heittää ylävitoset ja nostaa jalat pöydälle. Kilpailuedun pitkäkestoisuus mahdollistuu nimenomaan jatkuvan uudistumisen ja innovoinnin kautta. Strategin työ ei pääty koskaan ja se pitää lähes välttämättä sisällään innovointia.

Mitä todennäköisimmin kohtaamme aina vain enemmän liiketoimintapäättäjiä ja strategeja, jotka allekirjoittavat innovatiivisuuden tärkeyden yrityksensä menestyksen tekijänä. Harvalle lienee kuitenkaan aivan selvää kuinka tuoda innovatiivisuus osaksi yrityksen perusolemusta, ja tämän vuoksi se jääkin usein kunnianhimoiselta kuulostavaksi, konkreettista hyötyä tuottamattomaksi jargoniksi.

Haluan nostaa esille yhden työkalun, jonka avulla innovoinnista on mahdollista tehdä jatkuvaa, ketterää ja tuottavaa. Se mahdollistaa oikein valjastettuna organisaation kasvun ja kilpailukyvyn, auttaa ilahduttamaan asiakkaita yhä uudelleen ja uudelleen, sekä ohjaa tunnistamaan mihin suuntaan organisaation kehitystä on tässä kompleksisessa ja muuttuvassa maailmassa kannattavinta viedä. Arvannet jo, mitä työkalua tarkoitan.

Data. Se kuuluisa, kaikkivoipa data.

Mielikuvitus ≠ innovatiivisuus

Aloitetaan ylhäältä. On totta, että ihmisen intuitio ja mielikuvitus synnyttävät jatkuvasti uusia ja erinomaisiakin ideoita liiketoimintaan, mutta niiden vaikuttavuuden validointiin tarvitaan kaikesta huolimatta tietoa. Innovatiivisuus ei tarkoita mielikuvituksellisuutta, eikä mielikuvituksellisuus innovatiivisuutta. Pelkästään mielikuvituksen varassa tehdyt uudistukset ovat lähtökohtaisesti huono sijoitus, sillä niiden ja ympäristön väliset lainalaisuudet jäävät tutkimatta, minkä vuoksi puolestaan on vaikea korjata suuntaa niin tarvittaessa. Viisaasti kerätty ja jalostettu data auttaa meitä ymmärtämään innovaatioiden elinkaarta ja tunnistamaan mikä kulloinkin toimii ja mitä tulee muuttaa. Oli kyse sitten palvelu-, tuote- tai prosessi-innovaatiosta, oikeanlaiset metriikat ja seuranta ovat ensiarvoisen tärkeitä merkityksellisten, innovatiivisten ratkaisujen rakentamiseksi.

Moni on saattanut kuulla konseptista “Fire bullets, then cannonballs”, jonka Jim Collins kuvasi mainiossa kirjassaan Tietoisesti paras. Lyhykäisyydessään konsepti on malli nopealle pilotoinnille, ja sen avulla pystytään tunnistamaan epävarmassakin ympäristössä tehokkaasti ne kaikkein toimivimmat innovaatiot tekemällä matalan riskin, matalan kustannuksen ja matalan sitovuuden kokeiluja. Kokeilujen parhaimmistosta rakennetaan lopulta laajempia kokonaisuuksia, joihin voidaan myös sijoittaa isosti, sillä niiden on jo konkreettisesti havaittu olevan tuloksentekokykyisiä. Tämä on erinomainen esimerkki jatkuvasta innovaatiotyöstä, sillä konseptia voi soveltaa liiketoiminnan joka tasolla ja se vain paranee mitä enemmän sitä käyttää.

Jatkuva tiedolla validointi on siispä kultaa. Dataa voi kuitenkin hyödyntää jo aivan innovaation elinkaaren alkuvaiheessa, ennen validointia ja kehittämistä. Tämän havainnollistamiseksi täytyy jakaa yritysten keräämä ja hyödyntämä data karkeasti kahtia yrityksen sisäiseen ja sen ulkopuoliseen dataan.

Operatiivinen data ja markkinadata

Operatiivinen data löytyy yrityksen sisältä. Se kertoo yrityksen prosesseista, suoriutumisesta ja toimintamekanismeista. Sitä käytetään lähtökohtaisesti parantamaan yrityksen operatiivisen toiminnan tehokkuutta eri osa-alueilla. Operatiivisen datan ja sen avulla johtamisen vaikutukset näkyvät taloudellisesti tyypillisimmillään kustannussäästöinä (tai nousuina) tuloslaskelmassa – toimitusketjun optimointi, pakkausmateriaalin muuttaminen, henkilöstörakenteen uudistaminen ovat kaikki yrityksen sisällä kustannusrakenteeseen vaikuttavia muutoksia ja niistä kertyy organisaation sisäistä operatiivista dataa. Operatiivisesta datasta voidaan löytää vastauksia siihen miten asioita tehdään, mutta harvemmin siihen miksi.

Markkinadata puolestaan käsittää ympäröivän maailman luoman datan, sen kuinka asiakkaat reagoivat yrityksen tuotteisiin ja palveluun, kuinka yritys asettuu kilpailukenttään ja millaiset megatrendit vaikuttavat asiakkaiden (sekä yritys-, että yksityisasiakkaiden) tarpeisiin ja haluihin tai yhteistyökumppaneiden toimintaan. Markkinadataa hyödyntämällä saadaan siirrettyä vaikutuksia suoraan yrityksen liikevaihtoon. Uusien tuotteiden ja palveluiden luominen asiakasdataa ja avointa dataa hyödyntämällä luo uusia kanavia kassavirralle, ja vanhojen syystä tai toisesta epäkiinnostaviksi todettujen palveluiden lopettaminen sulkee niitä.

Yritykset ovat olleet jo pitkään varsin lahjakkaita ja innovatiivisia hakiessaan kustannussäästöjä ja mahdollistaakseen niiden kautta jonkinasteista kilpailukykyä. Operatiivisen datan käyttämisessä ollaan yleisesti siis jo varsin hakoja, mutta markkinadata on vielä verrattain tuntematon ja haastava pelikenttä – puhumattakaan operatiivisen ja markkinadatan yhdistelystä. Haastetta ei ainakaan vähennä se, että markkinadata on usein operatiivista dataa monimuotoisempaa, epäpuhtaampaa ja ylipäätään isompaa. Avatakseni ajatuksia markkinadatan kautta tapahtuvan innovoinnin käytännön mahdollisuuksille, kerron sinulle tarinan.

Olipa kerran korporaatio

Maailma katsoi kalenteristaan vuotta 2019, mutta korporaatio eli vielä vuotta 1970. Korporaatiolla oli hätä: asiakkaat eivät enää olleet lojaaleja korporaation palveluiden kuluttajia, vaan olivat alkaneet hajaantua ja vieneet mukanaan roposensa, joiden korporaatio oli tottunut kuulemaan kilahtelevan omaan kirstuunsa. Korporaatio mietti päänsä puhki kuinka houkutella asiakkaat takaisin, kokeili mitä moninaisempia mainoskampanjoita ja uusia palvelujulkaisuja mutta tulosta ei tuntunut syntyvän. Markkinoille oli tullut muita toimijoita, joiden kanssa asiakkaat mieluummin asioivat. Ketterämpiä, elinvoimaisempia yrityksiä, jotka lisäksi tuntuivat ymmärtävän paremmin mitä asiakas halusi ja pystyivät sen asiakkaalle antamaan.

Korporaatio sisuuntui ja alkoi tutkia tilannetta tarkemmin. Se päätti pyytää apua eräältä tuoreelta toimijalta jonka asiakaskunta oli lähellä korporaation omaa asiakaskuntaa. Tuore toimija näki korporaation kanssa tehtävässä yhteistyössä monta mahdollisuutta tehdä hyvää ja kasvattaa liiketoimintaansa, joten se suostui ilomielin auttamaan korporaatiota. Ei aikaakaan kun tuore toimija ja korporaatio yhdistivät voimansa. Korporaatiolle kertyneet valtavat datamäärät asiakkaista ja toiminnan kehityksestä keskitettiin ja jalostettiin hyötykäyttöön kelpaavaksi varaksi; operatiivinen data saatettiin standardimuotoiseksi ja markkinadataa siistittiin urakalla. Rajapintojen avaamisen ja integroinnin myötä korporaation ja tuoreen toimijan data saatiin yhdistettyä, tuoreen toimijan tuodessa tiimiin hyvinkin eriytynyttä ja reaaliaikaista näkyvyyttä asiakkaidensa mieltymyksiin.

Kävipä pian niinkin onnellisesti, että korporaatio ja tuore toimija tunnistivat yhdistyneestä datatyökalustaan kaksi kiinnostavaa trendiä – korporaation datan keskittämisen myötä laajentunut näkyvyys asiakaskuntaansa mahdollisti selkeästi kasvavan asiakassegmentin löytämisen ja tuoreen toimijan omien palveluiden kautta löydettiin vastaavan asiakassegmentin erityisiä kipukohtia joita korporaation palvelukapasiteetilla pystyttäisiin oikaisemaan. Tuore toimija ja korporaatio toteuttivat nopean pilotoinnin hankkeen uuden kohdennetun tuotteen rakentamiseksi, jota tarjottiin tuoreen toimijan asiakkaille ja jonka tukemiseksi saatiin valjastettua korporaation palveluorganisaatio pitkäaikaisen asiakassuhteen rakentamiseksi ja asiakkaiden sitouttamiseksi. Korporaatio ja tuore toimija jatkoivat datavetoista pilotointia tunnistaessaan aika-ajoin uusia ja muuttuvia trendejä ja kehittäen datavarantoaan jatkuvasti. He onnistuivat rakentamaan jatkuvasti uudistuvan ja ketterän yhteistyömallin ja elivät onnellisina elämänsä loppuun asti.

Sen pituinen se?

Datan hyödyntäminen innovaatioiden lähteenä ei toki reaalimaailmassa ole aivan noin yksioikoista. Käytännössä se vaatii useamman tahon yhteistyötä ja innovoivan osapuolen tai osapuolten henkistä ja operatiivista valmiutta tehdä nopeita siirtoja ja omaksua kokeilukulttuuri osaksi yrityksen arkea. On kuitenkin tosi, että kuvatunlainen skenaario jossa datamassasta voidaan tunnistaa liiketoiminnallisesti tärkeitä ominaisuuksia markkinassa tai asiakkaissa ja rakentaa niiden pohjalta uusia palvelu- tai tuoteinnovaatioita on tämän hetken realiteetti niissä kaikkein innovatiivisimmissa yrityksissä. On tosi, että se kasvattaa heidän liiketoimintansa resilienssiä ja yrityksen tilipussia. Ja on tosi, että siihen pystyy sekä korporaatio että tuore toimija.

Millaisia askeleita tul ee käytännössä ottaa, jotta datan kautta innovointi on mahdollista? Seuraavaa osaa odotellessa virittäydy tunnelmaan lukemalla vaikka tämä:

https://sloanreview.mit.edu/article/creating-digital-offerings-customers-will-buy/

React series part 2: SSR

Wed, 06 Nov 2019 10:38:00 GMT

The goal of this post is to provide a rather comprehensive overview of React server-side rendering (SSR). SSR is not a new but definitely important and interesting concept. You have probably heard of terms like SSR, SSG, pre-render, dynamic render, ReactDOMServer or SEO and social sharing issues with React. This post tries to explain those terms and give you answers for questions like what is SSR and why and how to use it.

Introducing SSR

React renders components/views to HTML on the browser which is called client-side rendering (CSR) but this can be done on the server also. Generating the HTML on the server is called server-side rendering (SSR). SSR means rendering the application to HTML on the server at request time. To be able to use SSR the application needs to be universal (also term ‘isomorphic’ is used) which means that the application can be rendered on the client and on the server. Static site generator (SSG) and pre-rendering techniques are usually mentioned when talking about SSR because these are rather closely related to each other. All these techniques are used for rendering HTML from the content created by JavaScript. SSGs create a completely static site (HTML, CSS, JavaScript, images, etc) which can be hosted on a static site hosting service (AWS S3 for example). Sites generated by SSGs don’t have any server code. Pre-rendering means generating HTML of the application by using a headless browser to crawl the page and execute Javascript. There is also a technique called dynamic rendering, which means switching between client-side rendered and server-side rendered (or pre-rendered) content for specific user agents (search engine crawlers for example). Dynamic rendering is not generally considered as cloaking (https://support.google.com/webmasters/answer/66355) as long as dynamic rendering produces similar content.

SSR, SSG or Pre-rendering can be used for improving SEO, UX and performance. The issue with SEO is that all search engine crawlers still don’t fully support single-page applications (SPAs) because all crawlers won’t execute JavaScript, or if they do, there are some limitations. With CSR the HTML is generated on the client by executing the React application (JavaScript) so the crawlers could end up seeing only a blank page, which might make the site not indexed by the crawler. The same applies for social media sharing. CSR also affects UX and performance because users need to wait until the React application is downloaded and rendered to see the content. This is noticeable especially with large applications and users with slow internet connection. Also users won’t be able to see any content if the JavaScript download fails or the user has disabled JavaScript from the browser.

Using SSR can help with these issues. The idea of SSR is that server (typically a Node.js server) renders the application and returns the HTML to the client. After the client has received the HTML it can be used as a normal SPA. With SSR users will see some content immediately after receiving the HTML from the server. Note that you can also use serverless functions (AWS Lambda for example) for SSR instead of a server (AWS EC2/ECS for example). Let’s compare SSR and CSR flows to understand the benefits of SSR more clearly.

CSR flow

SSR flow

CSR and SSR are both making network requests, executing JavaScript and rendering content. The main difference is when the user will see the content. With CSR it’ll be after downloading and executing the JavaScript and with SSR right after server sends the response. With SSR First Meaningful Paint is usually lower (better) if there aren’t any performance issues with server-side code. Also Time To First Byte (TTFB) will be higher with SSR compared to CSR.

Implementation

React provides ReactDOMServer (react-dom/server) module which enables the server to render React components to HTML. There are also many other libraries and frameworks for React SSR (and SSG) and we’ll go through the most popular ones briefly after this section. With ReactDOMServer React applications can be rendered to an HTML string with the renderToString method or to a readable stream that outputs an HTML string (same string what renderToString would return) with renderToNodeStream method. Both of these methods have static versions (renderToStaticMarkup and renderToStaticNodeStream) that won’t create extra DOM attributes that React uses internally (for example data-reactroot). These static versions are useful when creating static content without using React on the client because stripping the React attributes can reduce the size. It’s important to use ReactDOM.hydrate instead of ReactDOM.render on the client when using renderToString or renderToNodeStream. Calling ReactDOM.hydrate method on the client preserves the server rendered HTML and only attaches event handlers. The hydrate method also calls componentDidMount lifecycle method and useEffect hook. useLayoutEffect hook won’t be called – actually React gives a warning message when using useLayoutEffect with SSR. React-dom gives an error message in case of mismatch between the server and client markup. These errors can be silenced by adding suppressHydrationWarning to the element. This should only be used when element’s attribute or content is unavoidably different between server and client version and it only works one level deep.

Simple example with renderToString:

Simple example with renderToNodeStream:

Usage on the client:

External libraries

React applications usually have one or more of the following technologies: react-router, state management (MobX, Redux, React context, etc), code splitting (React.lazy, @loadable/component), and css-in-js (styled-components, emotion, etc). Each of these technologies requires special attention when it comes to SSR. This section explains how to use these common libraries with SSR starting from react-router.

react-router

First thing to notice when using react-router on the server is to use stateless StaticRouter instead of BrowserRouter. StaticRouter gets usually two props: location and context. The location prop is used to pass the current route to the router. The context prop is an empty object but after the render it contains the result of the render in the router scope. So after rendering there is a context.url property if <Redirect> has been rendered. You can also add custom properties to the context by using staticContext.

Using react-router (StaticRouter):

State management

Application state will most likely change on the client when using the application. It’s a very typical case that some components are rendered based on the application state, so it would be great to initialize application state on the server and pass it to the client. If the view requires some data to be fetched then all data or at least part of the data could be fetched on the server before rendering the application. This way the application can be rendered with all the data or part of the data it needs. A common approach for passing the preloaded data from the server to the client is to do it by using window object. For example window.__MY_PRELOADED_DATA__ could be used and assign preloaded data to its value. Then that data can be used to initialize the application state on the client. Also Redux side effect libraries like redux-saga can be used with SSR. The following simple application requires data fetching (preload data) and is using Redux as a state management solution.

Using Redux with preloaded data:

Alternatively we could make the data fetch as part of the client side initialization process and add the data to the store. But that approach would make two data fetch: one on the server and one on the client.

Code splitting

Code splitting is very useful technique for splitting the application code into various bundles which can then be loaded on demand and in parallel. Code splitting in React applications is usually done with React.lazy. React.lazy is a function which renders a dynamic import as a regular component. However React.lazy doesn’t support SSR yet. Luckily there’s a library called loadable-components (https://github.com/smooth-code/loadable-components) which provides code splitting with SSR support. To get started with loadable-components first you need to install @loadable/babel-plugin and @loadable/webpack-plugin to add support for SSR (automatic chunk names and to create loadable-stats.json file for the ChunkExtractor). The next step is to use ChunkExtractor or ChunkExtractorManager on the server for collecting the chunks and adding link and script-tags to the HTML. Finally on the client you need to use loadable to create loadable components and loadableReady to wait for all loadable components to be loaded (in parallel). Loadable-components provide plenty of other useful features too.

Code splitting with loadable-components:

CSS-in-JS

When using CSS-in-JS solution it’s important to note which libraries support SSR. For example styled-components, which is one of the most popular CSS-in-JS libraries does support SSR (renderToString and renderToNodeStream). Styled-components supports concurrent server side rendering with stylesheet rehydration. It uses ServerStyleSheet and adds a provider to the React application tree. The provider accepts styles via a context API and can be used through collectStyles method (it wraps provided element with the provider) or by using the StyleSheetManager provider directly. ServerStyleSheet instance’s interleaveWithNodeStream method can be used with streaming rendering. This method checks if any styles are ready to be rendered and if so the style block is prepended to the HTML.

Using styled-components with SSR:

So configuring different libraries for SSR clearly adds some complexity to codebase. And these aren’t the only libraries that are requiring configuration for SSR. In fact there are plenty of other popular libraries as well like react-i18next, react-helmet, etc that require configuring for SSR. The point of this section was to show how to configure the most popular libraries for SSR and pointing out that adding new library could potentially mean that it needs to be configured for SSR.

Frameworks

There are plenty of SSR and SSG libraries and frameworks such as: Next.js, Gatsby, After.js, Razzle, react-server, Reframe, Fusion.js, Electrode, Hypernova. For pre-rendering there are SaaS options like prerender.io (https://prerender.io/), prerender.cloud (https://www.prerender.cloud/) and libraries like react-snap (https://github.com/stereobooster/react-snap). Next.js and Gatsby are currently the most popular ones.

Next.js is a React framework that supports SSR, static export and other features. Next.js takes away the “pain” to implement SSR from scratch and basically offers SSR out-of-the-box for you. When working with Next.js or any other framework there are always some conventions so developers need to implement code in the “framework way”. For example with Next.js developers need to use specified directories for pages, configure framework with next.config, use Next.js version of react-router, append elements to <head> with next/head, use getInitialProps just to mention a few. In the client code you add the page specific views to pages directory and Next.js handles for example mounting, hydrating and code splitting for you so you don’t need to import React or setup routes. In the server code you can just require next and create a new instance of it, call getRequestHandler and prepare then use it together with express.js for example. When making a request to a Next.js app the request goes to the Node.js server which renders the application on the server with Next.js and returns the rendered application (HTML) to the client where Next.js handles hydrating, among other things.

Gatsby is a framework based on React and a SSG. This means that before deploying and running the React application, Gatsby needs to generate the static site first with build command. The Gatsby build command produces a directory of static HTML and JavaScript files, which you can deploy to a static site hosting service. Gatsby can also pull data from specified sources. With Gatsby there won’t be any servers required and therefore no server-side code because all is done at build time of the application. So when making a request to a Gatsby app you get pre-rendered HTML file which has script-tag pointing to the React application. One thing to notice with Gatsby is that number of pages affects the build time.

SSR Performance

There are some performance challenges with SSR. If the application needs some data then the data must be fetched before rendering the application. However, the data can be cached for some time if possible to prevent data fetch related performance issues. SSR with or without data fetch is increasing time to first byte (TTFB) compared to CSR. But the HTML could also be cached for some time to reduce the TTFB. TTFB can be reduced also using SSR with streaming. Caching HTML also reduces the server load because each requests won’t trigger SSR because the HTML of the rendered React application can be returned from the cache.

When using renderToString method HTML can be added to the cache after the render and when using renderToNodeStream the HTML can be added to the cache by using transform stream. I recommend to cache as much as possible to make SSR as fast as possible. It’s also possible to add caching to the component level. There are libraries for different React versions but for the current version you can check out react-component-caching (https://github.com/rookLab/react-component-caching) and react-prerendered-component (https://github.com/theKashey/react-prerendered-component).

Developers can also decide if some views should not have SSR. For example, if SSR is used only because of SEO it’s not necessary to SSR content which requires users to log-in because crawlers won’t index these views.

It’s important to know at least basic React performance optimization techniques because unoptimized React application adds more latency to the server response since the render takes longer. SSR can also be optimized by not rendering everything on server. Some components can be rendered only on the client. Placeholder or spinner can be used to indicate that there will be some more content. One technique for this is to use double render so setting boolean variable to true in componentDidMount or in useEffect and render component based on the value of the variable. However, this causes component to rerender and that’s why it shouldn’t be overused because of the performance hit.

Conclusion

SSR is a technique for rendering application on the server and returning HTML to the client. It’s used primarily for SEO, social sharing and to improve performance. You can use ReactDOMServer when implementing SSR or use some framework like Next.js or Gatsby. It’s important to remember that you may need to add some configurations or new code to your server-side code when adding a new libraries to your project. Performance of the application is important since inefficient application uses more time for rendering and thus increasing the latency. Also caching should be used whenever suitable to reduce the latency. Think at least about SEO, social sharing, performance and budget (servers and development isn’t free) if you are wondering whether or not using SSR. I hope this post was able to give you an overview of SSR and maybe you will be using it on your next project.

Syksyn kootut – uusia työkavereita, kaupunkiseikkailua ja instagrammailua

Tue, 29 Oct 2019 14:27:00 GMT

Aurinkoista lokakuuta! Ajattelin taas koota kasaan muutamia kuulumisia meiltä syksyn varrelta. Elokuun tullen jouduimme suruksemme luopumaan toistaiseksi Saarasta , joka palasi koulun penkille, mutta onneksi pääsimme toivottamaan lämpimästi tervetuloa taloon kolmelle uudelle webscalelaiselle – oli ihan huippua saada Jari , Jarno ja Jussi meininkiin mukaan! Jari on jo ehtinyt esitellä osaamistaan bloginkin puolella, pääset lukemaan sen tästä.

Elokuussa osallistuimme jo toistamiseen Runfestiin , jossa Jarmo ja Mona kannustivat Jukkaa , H-Ptä , Lauria , Juhaa ja minua juoksemisessa ja osallistuivat myös jälkipuinteihin. Sen verran kivaa oli taas, että ilmoittauduimme jo seuraavallekin vuodelle mukaan!

Elokuussa myös alkoi kiertävä Instagram -vuoro, jossa seurattiin vuorollaan Monan päiviä asiakkuuksien parissa, Saaran menoa kesätyöntekijän näkökulmasta, Juhon tarinointia niin konsultin elämästä kuin johtoryhmänkin puolesta, Laurin työtä DevOps -hommien parissa, Toffen “peruskonsultin perusviikkoa”, kuten hän itse kuvaili, sekä minun hommiani HR- ja toimistoasioiden parissa.

Syyskuussa kävimme seikkailemassa ketun jäljillä Foxtrail -kaupunkiseikkailussa. Voiton vei Monan, Hekan , Toffen, Jussin, Erikin ja Teemun tiimi toisen tiimin keskittyessä lähinnä fiilistelemään reitti läpi…

Petteri oli bongannut hyvän tarjouksen isosta laatikosta suklaata, ja meinasi ostaa sellaisen tiimilleen. Pettymys oli suuri, kun ko. suklaat oli jo ehditty myydä loppuun! Tarina ei kerro, löysikö Petteri tiimilleen korvaavia herkkuja… Henri korkkasi onneksi hyvin vähälle käytölle jääneen toimiston ensiapukaapin, josta löytyi helpotusta päänsärkyyn. Mona kävi ylittämässä itsensä Cloud Architect -sertikokeessa ja kirjoitti kokemuksestaan blogauksen avuksi muillekin, joka lähtevät suorittamaan sertiä ei-teknisistä lähtökohdista. Teemu on syksyllä ollut töissä opiskelun vuoksi kahtena päivänä viikossa ja harmikseen joutunut jättämään väliin perjantain toimistohengailut, koska silloin yliopistolla on ollut häntä erityisesti kiinnostava tilastotieteisiin liittyvä kurssi aiheesta computational statistics. Syyskuun techdayssa kuultiin esitykset Baublesta, AWS App Meshistä ja React Hookseista, joista muuten voit käydä lukemassa React-aiheisen blogaussarjamme ensimmäisen osan tästä!

Lokakuussa kuukausittainen afterworkimme oli lautapelailua toimistolla ja tietysti myös Webscalen änäriliigan toinen kausi pyörähti käyntiin ja alkusarjan ottelut ovat käynnissä. Jukka rakentaa sitä varten sovelluksen, josta sarjataulukkoa seurataan. Ainakin ensimmäisen kauden voittanutta Heikkiä on jo päästy yllättäviltä tahoilta haastamaan…

Katse alkaa meillä pikkuhiljaa olla jo loppuvuodessa; Kumpulan Potentiaali -rekrytapahtumassa, AWS re:Inventissä Las Vegasissa ja pikkujouluissa. Näistä sekä sarjataulukkosovelluksen kehittämisestä ja änäriliigasta lisää myöhemmin! Ovatko tällaiset henkilöstön normaalia työarkea koskevat jutut sinusta kiinnostavaa luettavaa?

React Series Part 1: Hooks

Thu, 10 Oct 2019 07:36:00 GMT

This post assumes you know the basics of modern JavaScript, React and the concepts around it.

What are hooks and why do they matter?

The short version is that hooks allow you to write function components, while still using functionality and logic previously only available to class components. This includes lifecycle methods and state. Hooks offer a new way to create re-usable, isolated pieces with logic and state. Certain cases that previously needed to be handled with Higher Order Components or Render Props, can now often be solved by reaching for a hook or two.

Common or repetitive pieces of logic can now be extracted from components and made into reusable hooks, and all of them behave and follow the same “rules of hooks” . Complex classes that might be hard to read and test can often be made a lot simpler and shorter, with your hook providing the main logic. However, unlike HOC and render props, they don’t cause nesting in your component trees. We also get rid of a few nuances developers face with JavaScript itself – classes, inheritance and how this works. Hooks are only called from React components, which allows a specific hook’s state to be associated with the actual function that called it.

From Classes To Functions

This is not a migration guide, but rather a quick look at what usually changes when you switch from classes to function components with hooks.

Hooks are very handy and can be fun to write. However, at the end of the day they allow you to do the same thing as before but in a different way. You shouldn’t feel the need to rewrite everything with hooks. Instead, consider trying them out when writing new components, or when making changes to old ones. You might notice that you can get rid of some of the repetitive logic littered around your components.

The actual process of converting a class component is pretty straight forward. Let’s list which parts change when rewriting a class to use hooks;

Function components don’t have a class instance – that means there is no class constructor, no “this”, and no super call. You just pass props to your component and that’s it.

But how does React know which function called which hook and which function uses which state? React keeps track of which component called the hook using an internal list of “memory cells” associated with each component. It’s essentially just a JavaScript object under the hood, you don’t really have to worry about it.

Unless you have a very specific situation, you can just use useEffect , which is called during different lifecycle methods. This depends on how and what dependencies you pass to it. More on that shortly.

Function components return their function body, they don’t need a separate render function.

Rules Of Hooks

While you’re now just writing functions instead of classes, there are still two rules you have to remember to follow;

This one is easy enough. You cannot call hooks from classes or from plain utility functions. There must be a React Function that actually calls the hooks.

Only call hooks at the top level of components. Placing hook calls inside conditionals or loops might result in them being called in a different order when the component renders. By keeping them on the top level we ensure that it doesn’t happen.

The rules are simple but if you’re used to classes you’ll find yourself breaking them every now and then when starting out. There is an eslint plugin to help you enforce these rules. The plugin also verifies the list of dependencies for your hooks.

The Built-In Hooks

React offers ten different hooks by default but as long as you know your way around React you will find them relatively easy to learn and use. While React has all these built-in hooks, you’ll spend most of your time working with only 3-4 of them. You can combine and use them together to create custom hooks. If you need to optimize or handle a specific edge case scenario, there are also specialty hooks which you can use. The built-in hooks are all prefixed with “use” , and you should be following this practice when writing your own hooks as well.

Let’s run through some of the built-in hooks and see which hook to use in what situation. I’ll also mention some pitfalls you can run into when using them.

useState

The most basic hook, comparable to this.setState from class components with a minor difference being how this.setState merges objects, while useState replaces the whole object.

useState takes an argument that it uses to set its initial value. Calling useState returns two items. The first item is the current state value, and the second is a function to update it. You’re free to name them how you want, but the common practice is to prefix the updating function with a “set” .

Note that the first argument, firstName is really just a string, not a magic proxy or a data binding hack – it’s just a normal variable. Calling setFirstName with the same value does not cause a re-render. Note that updating the state with useState will replace the whole state . If you have an object with multiple properties, you need to use something like object spreading to keep the rest of the properties or they will not be part of the next state.

You can also access the previous state with the setter function.

You may also provide the useState with a function. It will be executed only on the initial render , making it useful if setting the initial state is expensive;

If you need to manipulate more complex states or need something more flexible than what useState provides, you should use useReducer which I will present later on.

useEffect

Like the name implies, this hook accepts possibly effectful or imperative code. This is the only place where you should put that logic when using function components. It’s good for side effects like logging, fetching data, subscriptions and so on. Code that needs to run during specific stages of the react lifecycles is put here. You can actually write multiple effect functions in your component, which in certain situations might make things more readable and allow you to separate these effects later on to custom hooks more easily.

The useEffect runs by default on every single render, unless you pass dependencies to it. If an effect has dependencies it only runs when they change. By passing an empty array there are no dependencies that can change, so the effect only runs on componentDidMount .

You can also provide an effect with a function return statement. This return statement is ran when the component using the hook is unmounted. If you have subscriptions or need to remove event listeners etc, this is where you have to do that. Always remember to return a function that cleans up possible subscriptions and removes event listeners to prevent memory leaks!

Here are examples showing the situations when useEffect runs depending on the dependencies passed to it;

A common source of bugs when using useEffect is to use external functions or props from outside of the effect itself. This is not considered safe and could lead to bugs. You should always be passing all of the props that the effect needs in the dependencies. And you should always be calling functions with the props the effect itself has.

Below are some examples. All of them work but especially the first one could cause bugs in certain situations.

useLayoutEffect

The signature for this hook is the same as for useEffect . In practice it means that they behave the same and technically you could replace almost all effects with useLayoutEffect . The key difference is that useLayoutEffect waits for all the DOM mutations before rendering while useEffect doesn’t. Not waiting for DOM mutations is usually the preferred way, so unless you deliberately need to block the browsers paint you should be using useEffect . In the rare cases when you need to do some visual calculations or DOM mutation before the browser paints, you can use useLayoutEffect . This way we prevent the layout from flickering suddenly or changing in some way after the initial render.

useContext

The useContext hook does what the name implies. React offers a thing called the Context API, which is a way to pass down props throughout your application. Contexts are helpful when you run into things like excessive prop drilling, which can cause some problems when a codebase grows in size and changes a lot. The useContext hook makes it easier to consume that context. This becomes especially helpful if you have nested or multiple contexts.

Note that you need to reference the actual context itself , even though you can only read the context when using the useContext hook.

useReducer

If you need to handle more complex states or find yourself having a bunch of different state calls all over a component you should use useReducer . You get a cleaner and more readable way to set your state. All through the same dispatch function rather than separate update functions.

Let’s say we have a large form with lots of states and complexity. It can often start to look like this;

When our component is littered with different setters and variables, it becomes harder to read and see what the actual state is in which situation. This is where useReducer comes in.

We moved our logic out of the component to createUserReducer where we can only focus on the logic. This way, updating the state is always done through the same dispatch function which returns the new state that is then passed to the component state. The reducer-dispatch flow is very similar to Redux, if you’re familiar with that. There are even arguments for that if your state management doesn’t need all the Redux features, you could get away with using just useState , useReducer and useContext in a smaller applications.

useCallback & useMemo

Why am I grouping these two together? Because they are very much alike, with only a minor difference.

These are hooks you should look at when you start optimizing your application. They help you skip expensive operations that occur every render.

That means that these are the same;

If the dependencies haven’t changed these hooks just return the previous value or function.

useRef

Refs are usually used for managing element focus or for example selecting something. You can access the node which the ref is referring to with .current . But since we are now using functions we can’t use the traditional React createRef , since in function components it will be reset on every render.

That is why we have a useRef hook.

But useRef isn’t only useful for DOM refs, you can actually use it like an instance variable. The refs .current is basically an instance variable, which will persist for the whole lifetime of the component where it is used.

Just like createRef , useRef provides a mutable value in its .current property which will persist for the full lifetime of the component using it. Mutating the .current property will not re-render the component using it.

useRef should always be used carefully and you should check if there are alternatives before using it.

An example where useRef could come in handy is when you do not want an effect to run on the initial render (there are other ways to solve this too);

Custom Hook

As a final example let’s write a simple demo hook to use event listeners called useEventListener . The function will accept three parameters: the event name , a handler function , and the element (window by default) to add the listener to.

We start with a useEffect where we add our event listener to your element. Since we don’t want memory leaks, we remember to remove the event listeners in the return function. We also remember that we need to add our dependencies, making the hook run whenever the dependencies change.

Let’s put this hook to use by making a window resize handler which tells us the current window aspect ratio. First, we need a helper function to get the window aspect ratio;

Next, we set the initial state in the component using our custom hook by passing it the function we just created. It will only be ran on the initial render. Now we can create a handler which we’ll pass to the hook. It also uses the setWindowSize function and passes it the helper function we created.

Now we can see the windowSize updating and the height and width properties update whenever we resize the window. They are just regular variables we can use.

We could easily add another event listener in our components now. Let’s add another handler using our hook that tracks the position of our cursor;

Then just render the state like before;

Our hook is not perfect, it’s not tested or covers all the edge cases but I think it serves as a good example.

And that’s a wrap.

People experienced with Hooks API might’ve noticed I left out a few of the built-in hooks. If you find yourself using these hooks, you’re probably already pretty comfortable with hooks or have ran into a pretty specific situation. For anyone else interested in these hooks I didn’t mention, you can see how and when to use them in the documentation for useImperativeHandle and useDebugValue .

Cloud Practitioner -sertifikaatti bisneslähtökohdista

Wed, 02 Oct 2019 10:37:00 GMT

Teknologiakonsulttien kanssa päiviä viettäessäni olen päässyt ujuttamaan itseäni pilven, softan, analytiikan ja datan maailmaan jo tovin. Modernien teknologioiden virta on pikkuhiljaa alkanut toden teolla viedä mennessään ja jokunen viikko sitten tuli sopiva sauma näyttää, että siinä oppii bisnesnainenkin uimaan. Kävin tekemässä ensimmäisen virallisen AWS-sertifikaattikokeeni AWS Cloud Practitioner -nimellä kulkevaa foundational tason sertifiointia varten. AWS:n teknologiat ovat olleet välillisesti osa arkeani nyt reilun puolen vuoden ajan, mutta ensimmäistä kertaa laitoin tietoni niistä testiin. Läpi meni niin, että heilahti.

Muutama hikikarpalo tuli kuitenkin pyyhittyä ohimoilta kokeeseen valmistautuessa siitä yksinkertaisesta syystä, että teknologioita, palveluita, konsepteja ja työkaluja on kokeen scopessa valtavasti ja niiden väliset erot ja kunkin spesifit käyttötarkoitukset on tunnistettava. Kyseisten aihepiirien hallitseminen on toki merkittävästi helpompaa mikäli ne ovat osa omaa päivittäistä työkalupakkia, mutta itselläni näin ei suoranaisesti ollut ja aikaa valmistautumiseen oli hyvin rajallisesti.

Mikä on Cloud Practitioner -sertifikaatti?

Cloud Practitioner on sertifikaatti, joka testaa teknisen syväosaamisen sijaan AWS:n julkipilven kokonaiskuvan hahmottamista ja sen käyttökohteiden ymmärtämistä. Se on myös merkittävästi laajempi kokonaisuus kuin esimerkiksi AWS:n tarjoamat verkossa itsenäisesti tehtävät akkreditoinnit, kuten AWS Business Professional. Cloud Practitioner on suunniteltu kahdelle kohderyhmälle: teknisille asiantuntijoille ensimmäiseksi sertifioinniksi, jonka päälle rakentaa perehtyneempää arkkitehtuuri- ja erikoisosaamista, sekä liiketoiminnan, myynnin ja hallinnon henkilöille tuomaan lisää substanssia heidän työhönsä.

Cloud Practitioner käsittää neljä osa-aluetta: teknologiat, julkipilven peruskonseptit, tietoturva, sekä kustannusoptimointi. Teknologiat ja pilven fundamentit kattavat valtaosan koekysymyksistä, tietoturva-asiat noin viidenneksen ja kustannusten hallinnan kysymyksiä on vähiten. Näin ollen kokeeseen valmistautuessa on järkevää miettiä osa-aluekohtaista jakoa ajankäyttöön etenkin jos aika on kortilla. Pilvipalveluiden peruskonseptit ja kustannusoptimoinnin ratkaisut kaipasivat omalla kohdallani selkeästi vähiten läpikäyntiä, joten oli luontevaa keskittyä opiskelussa lähinnä teknologioihin, tietoturvan kulkiessa siinä jatkuvasti mukana. Kokosin alle muutamia vinkkejä valmistautumiseen riippuen siitä, mihin osa-alueisiin kokee tarvitsevansa eniten tukea.

Teknologiat

Mikäli perustason tekninen terminologia ei ole ennalta tuttua, kannattaa sen parissa viettää jonkin verran aikaa. Ratkaisujen ja työkalujen oppiminen on sujuvampaa, kun whitepapereita pystyy lukemaan nopeasti pienellä vaivannäöllä, ja opetusvideoita ei tarvitse jokaisen termin kohdalla pysäyttää selityksen hakemista varten. Ja niitä whitepapereita todella kannattaa käydä läpi. AWS kategorisoi teknologiansa opetusmateriaaleissa varsin luontevasti eri osakokonaisuuksiin, mikä helpottaa niiden välisten suhteiden ja eroavaisuuksien, sekä erilaisten käyttökohteiden hahmottamisessa ja muistamisessa.

Teknologioiden osalta kokeen kysymysten määrä vaihtelee osakokonaisuuksittain ja esimerkiksi Compute ja Database -kategorioiden palvelut on hyvä osata perinpohjaisesti. Niistä riittää kokeeseen todennäköisesti laajemmin kysyttävää, kuin esimerkiksi koneoppimisen työkaluista.

Pilven peruskonseptit

Jos julkiset pilvipalvelut ja niiden toimintamekanismit ovat yleisesti hallussa, tämä osio on enää lähinnä semantiikkaa. Sanavalintojen ja konseptien kirjaimellisen muotoilun kanssa kannattaa olla tarkka, sillä kokeessa on myös kompakysymyksiä, jotka testaavat konseptien AWS -spesifejä ilmaisuja. Esimerkiksi pilven “elasticity” ja “scalability” -ominaisuudet ovat keskenään hyvin samankaltaisia, mutta niitä käytetään eri yhteyksissä ja kuvaamaan erilaisia toimintoja. Samankaltaisuuteen tuudittautuminen voi maksaa kokeessa pisteitä hyvin äkkiä.

Mikäli julkipilven perusrakenteet eivät vielä ole selkäytimessä, on ne ehdottomasti saatava sinne. Niiden päälle nimittäin rakentuu kaikki muu – teknologioista kustannusoptimointiin. AWS:n Well Architected Framework tukee näiden konseptien oppimista hyvin ja on äärimmäisen hyödyllinen osata Cloud Practitioner -kokeessa. Tämän lisäksi AWS:n globaali infrastruktuuri tulee tuntea, sillä se on erottamaton osa heidän parhaita käytäntöjään.

Tietoturva

AWS kertoo paljon jaetun vastuun mallistaan, joka määrittelee mitkä osat tietoturvasta ovat heidän vastuullaan ja mitkä asiakkaan vastuulla. Lähtökohtaisesti on hyvä ymmärtää, mitä kuuluu pilvialustan itsensä turvallisuuteen, ja mitä puolestaan pilvialustan päällä toteutettavien palveluiden turvallisuuteen. AWS:n vastuulla on pilvialustan turvallisuus – asiakkaan vastuulla puolestaan hänen toteuttamansa ratkaisun turvallisuus. Näissäkin on teknologiakohtaisia erityispiirteitä ja niitä on hyvä ottaa huomioon teknologioita opeteltaessa.

AWS:lla on myös useita tietoturvaan erikoistuneita palveluita ja toimintoja, joita kokeessa nousee mahdollisesti esiin.

Kustannusoptimointi

Monet AWS ratkaisujen taloudelliset hyödyt juontuvat suoraan pilvipalveluiden fundamenteista ja skaalaetujen siirtämisestä asiakkaille, sekä teknologioiden käytettävyydestä todellisen tarpeen mukaan sen sijaan, että kapasiteettia varattaisiin reilusti etukäteen. Kun Cloud Concepts -osiosta on hyvä ymmärrys, on helppo myös nähdä yleisellä tasolla julkipilven tuomat taloudelliset hyödyt. Sertifikaattikoetta varten on tosin hyvä tunnistaa yleisten hyötyjen lisäksi eri skenaarioissa optimaalisimmat kustannusmallit, sillä kokeen tarkoitus on varmistaa henkilöllä olevan kokonaisymmärrys siitä, mitä hyötyjä missäkin yksittäisessä tapauksessa on saavutettavissa.

Tämä vaatii eri palveluiden kustannusrakenteen ymmärtämistä, hyvin tyypillisesti kustannusoptimoinnin kysymykset koskevat EC2 instanssityyppien käyttöä eri skenaarioissa. Näistä löytyy myös kompakysymyksiä ja erikoistapauksia, eli yksityiskohtien kanssa on jälleen kerran oltava tarkkana.

Ja näin pääset alkuun

AWS itse tarjoaa valtavan määrän oppimateriaalia valmistautumisen tueksi ja olennaista onkin tunnistaa sieltä ne hyödyllisimmät juuri tätä koetta varten. Harjoituskokeita on hyvä tehdä jo heti alkuun kokonaiskuvan saamiseksi, ja omalla kohdallani koin ne hyödyllisiksi myös aivan valmistautumisen loppuvaiheessa, juuri ennen koetta. Esimerkiksi Whizlabs tarjoaa harjoituskokeita, joiden sisältö ja toiminnallisuudet ovat riittävän lähellä todellisen kokeen sisältöä, jotta niistä on aitoa hyötyä valmistautumisen kannalta ja ennen koetta vastausrutiinin rakentamiseksi. Oppimateriaalien palveluntarjoajia on kuitenkin useampia ja mikäli tuntee itsensä oppijana hyvin, pystyy jo sen perusteella valitsemaan sopivimmat materiaalit ja menetelmät. Omalla kohdallani selkeästi suurin hyöty oli harjoituskokeista, sekä niiden tarjoamista oikeista vastauksista ja tarkemmista selityksistä kysymyksiin.

Suosittelen kuitenkin käyttämään useampaa kuin yhtä oppimateriaalityyppiä – esimerkiksi hyvin toimiva combo on katsoa ensin ylätason opetusvideoita joista saa helposti kokonaiskuvan asioista ja siirtyä niiden jälkeen whitepapereihin hieman syvällisemmän tiedon hankkimiseksi.

Yhtä kaikki, Cloud Practitioner on varsin toimiva kokonaisuus liiketoiminnallisistakin lähtökohdista ja sen sisällön omaksuminen helpottaa teknologian ja bisneksen välimaastossa kulkemista merkittävästi. Vaikkei pilvipalveluiden kanssa suoraan työskentelisikään, tarjoaa Cloud Practitionerin tuoma oppi vähintäänkin työkaluja vertailla ratkaisuja moninaisten digitaalisten palveluiden toteuttamiseen muuttuvassa liiketoimintaympäristössä. On virkistävää huomata oman ajattelunsa ja tietämyksensä kehittyvän mitä laaja-alaisemmin erilaisia ilmiöitä tulee käsiteltyä. Ja kuka tietää millainen lumipalloefekti tällä onnistuneella sertifioinnilla vielä on allekirjoittaneeseen, maailma on mahdollisuuksia täynnä!

Offline Video Surveillance using AWS DeepLens

Mon, 23 Sep 2019 06:29:00 GMT

I have recently been prototyping with an AWS DeepLens device. We were playing around with an idea of theme songs for people working at the office, and it seemed like a fun idea to have the DeepLens automatically play the theme song for the person who enters the office. With this in mind I was trying to find a smooth development workflow for the DeepLens and the related AWS infrastructure and to create a working prototype of the project. In this blog, I’ll discuss the project itself and some of the things I have learned during the project.

What is DeepLens?

DeepLens is a deep learning enabled video camera from AWS. Its main purpose is to offer developers an easy way to get hands-on experience in deep learning. The first version became available in 2018, and a second version with some hardware and software improvements was published in 2019.

The device is basically a small computer with a built-in 4MP video camera and it has the ability to deploy and run visual deep learning models created using SageMaker, Amazon’s tool for building such models. Amazon offers a wide variety of example projects for the DeepLens, such as bird classification, face detection, and activity recognition, that can be deployed to the device in a matter of minutes.

Behind the scenes, DeepLens uses Amazon IoT Greengrass to deploy and run lambda functions in the device, and the device can also be used as an ordinary Greengrass core instead of deploying projects through the DeepLens console.

The Standard Development Pipeline

When building a DeepLens project from scratch, the first thing that you need is a deep learning model. The models are built using Amazon SageMaker from which they can be transferred to the DeepLens device. It is also possible to select a model from a library of pre-trained models offered by AWS.

I addition to the trained model, a DeepLens project needs a lambda function (written in Python 2.7) that at minimum passes the visual data from the device’s camera to the model for inference and then publishes the results.

The model and the lambda function are then deployed to the DeepLens device using a dedicated DeepLens console in the AWS Management Console. Behind the scenes, the console creates a Greengrass deployment with certain hard coded parameters and deploys that on the device. This is excellent for fast prototyping, but makes certain things a bit more complicated, which I will discuss more later in the blog.

AWS offers a nice selection of example projects which showcase not only the models and lambda functions deployed into the DeepLens, but also how the device can be used in connection with other parts of the AWS infrastructure, especially the Amazon Rekognition Image . Most examples involve dividing the image analysis into different subtasks. Some of these are performed in the DeepLens device, after which the images that require further processing are uploaded to an S3 bucket and analysed using Rekognition.

As mentioned above, DeepLens uses Greengrass to run the projects on the device. When the device is registered to an account, AWS automatically sets it up as a Greengrass core. The project deployments are also basically Greengrass deployments using certain hard coded resources and settings. Being aware of this is useful, since examining the Greengrass deployment parameters makes it easier to understand what can and cannot be done without extra tweaking.

The Project

I wanted to build a quick prototype of a light video surveillance system using DeepLens as an autonomous security camera. This would be done by pointing the camera at the door, and performing face recognition on the people entering the office, logging information about unidentified people. I took a privacy-oriented approach, where I wanted to build the system so that everything is done on the device. In other words, no uploading images of passersby to S3 for classification using Rekognition. In addition to identifying people, I wanted to be able to encrypt images containing unidentified faces locally before storing them to an S3 bucket, or failing that, to store the images locally to be retrieved later using an SSH connection over the local Wi-Fi network.

The first option that came to mind was to build a custom model using SageMaker using employee profile photos as training data. This again required uploading the images to cloud, and seemed like it might prove to be pretty complex, so I did some more research and found a DeepLens project called OneEyeFaceDetection that does manage to perform face recognition on the DeepLens device. The project uses face-recognition , a wonderful python library by Adam Geitgey, and I decided to try the same method. Geitgey’s library performs face recognition using a C++ machine learning toolkit called dlib , which includes excellent face detection and recognition functionality.

The great thing about this library is that there is no need to retrain the underlying model when adding or removing faces to the list of known persons. The system works by first detecting faces in the image, and then calculating feature vectors for each of the detected faces. After obtaining the feature vectors, we simply compare those to feature vectors generated from our reference photos of known persons, and find the closest one in the sense of the Frobenius norm [1].

If none of the reference vectors are similar enough, we label the face as unknown. Adding a new person to the list of known people is as simple as generating a feature vector for that person, and adding it to the feature vector database, together with some id linking the feature vector to the identity of the person.

Using this library makes it easy to perform face detection on the DeepLens device, although at the cost of not being able to take advantage of the GPU processing capabilities of the device. I am aware that this is really not the way that DeepLens is primarily meant to be used, but it is a commercially available device that works well with AWS, and is an interesting hardware alternative for custom devices.

Problems and Solutions

There were a few problems I encountered while working on the project. The first was figuring out how to get the face-recognition library installed on the device. At that point I was completely new to the device, and didn’t really have a clear picture of the environment in which the lambda functions are executed so a certain amount of trial and error over an SSH connection was involved.

Installing the face-recognition library requires connecting to the device over SSH, installing cmake (and possibly other supporting libraries), then installing dlib library from source files, and finally installing the face-recognition python library itself.

After this I was able to use face-recognition inside the SSH connection, but it was still inaccessible to the lambda function, probably due to the Greengrass container in which the lambda is executed. I fixed this simply by copying the necessary libraries to another directory that is visible to the lambda functions ( /usr/lib/python2.7/dist-packages/ ), but there are probably other ways of doing this as well.

Accessing S3 required adding new policies to the AWSDeepLensGreengrassGroupRole defined automatically when the DeepLens device is registered to an AWS account. I disliked the idea of editing an existing role for the purpose, and ended up creating a new role for the project. In order to have the DeepLens use my newly created role, I needed to go to the Group settings in the IoT Greengrass console, where the Group role is defined. The group role is one of the things that are defined automatically when a new DeepLens device is registered to an AWS account.

Even if you do decide to edit the existing role instead of creating a new one, the Group settings are worth checking out. They might give some insight into why something is not working as expected in your DeepLens project. You can for instance set the user ID and group ID that are used to run the lambda functions, and enable or disable containerisation.

If you want to have write access to the filesystem on the DeepLens while keeping the containerisation, you can also add write permissions for the lambda functions in the Resources section in the Greengrass group console. This is a bit more fiddly though, since whenever a new DeepLens project is deployed, the resources available to the lambda function are reset to the default settings and need to be adjusted again.

The End Result

Here’s how the project feed from the DeepLens looks like with the face recognition enabled. The bounding box is produced by the face-recognition library and the initials are stored together with the feature vectors.

The next phase is to detect visually when the door opens. With this addition, the door can be used as a trigger for the face detection, instead of keeping the face detection algorithm running all the time. One way to do this is by using the floodfill algorithm from the OpenCV library. Floodfill basically starts from a specific pixel in the image, and then proceeds to colour all connected pixels that are close enough in colour, similar to the ‘paint bucket’ fill tool in image editing software.

If we limit the examined area to the top part of the door and its surroundings, we can fill the door, measure the filled area, and use the area to decide whether the door is open or not. If the area is too small, the door must be open. The following image shows the idea. I’m limiting the flood filled area to the top part of the door to minimise false positives caused by objects between the camera and the door. How well this works depends on the colouring of the door and its surroundings, and various other factors. Below you can see the system in action.

Conclusions

All in all, I’m quite happy with the results of this experiment. The theme song functionality wasn’t yet implemented, but with working face recognition, it’s only a matter of sending a message to another device. Realising that the DeepLens basically functions as a Greengrass core made it easier to find solutions to the problems I encountered. Of course, the way I built the project means that I’m intentionally ignoring the deep learning capabilities of the device, since I’m not taking advantage of SageMaker models and the GPU computing capabilities that the device offers. Then again, I consider being able to use the device also for this sort of prototyping an added bonus that increases its value for me.

References

[1] https://en.wikipedia.org/wiki/Matrix_norm#Frobenius_norm

Kulissien takana: Suomi24-keskustelualustan järeä uudistus

Mon, 09 Sep 2019 06:00:00 GMT

Pääsimme toteuttamaan Allerille Suomi24-keskustelualustan mittavaa uudistusta. Projektia on ollut toteuttamassa Jukka Ukkonen, ja hän kertoo projektista hieman tarkemmin:

“Suomi24-keskustelualustan uudistusprojekti on ollut erittäin mielenkiintoinen. Ensinnäkin keskustelualustalla on pitkä historia ja sillä on erittäin paljon käyttäjiä. Keskustelualusta oli ollut muutaman vuoden ylläpitovaiheessa, eikä uusia ominaisuuksia oltu kehitetty hetkeen. Teknologia ei ollut ajan tasalla, joten prosessien modernisoinnille ja automatisoinnille oli jo selvä tarve .

Uudistukseen on kuulunut ohjelmistokehitysprosessin ja -työnkulun muutoksia, sovellusten muuttaminen Docker-konteissa suoritettavaksi, sovellusten siirto AWS-palveluihin, CI/CD automatisointi sekä käyttöliittymän modernisointi (frontend- ja backend-muutokset).

Suomi24:n lokaali kehitysympäristö uudistettiin siten, että kaikkia sovelluksia ajetaan lokaalisti Docker-konteissa. Kaikki lokaalin kehitysympäristön pystytykseen vaadittavat toimenpiteet automatisoitiin mahdollisimman pitkälle docker-composen ja bash-skriptien avulla. Aiemmin uusilla kehittäjillä kesti tyypillisesti kahdesta viikosta kuukauteen pystyttää toimiva kehitysympäristö. Automatisoinnin jälkeen kehitysympäristö saadaan toimintaan alle puolessa tunnissa. Asiakkaan tiimille opetettiin myös gitin käyttöä ja mietittiin yhdessä tiimin kanssa sopiva versionhallintamalli.

Suomi24-palvelun node.js:llä toteutetun backend-sovelluksen riippuvuuksien hallinta vaihdettiin bowerista npm:ään ja paketointityökalu Gulpista Webpackiin. Samalla päivitettiin joitain vanhoja kirjastoja ja järkevöitettiin paketointiprosessia.

Suomi24 node.js backend-sovelluksen suoritusalusta vaihdettiin AWS:än dedikoiduilta palvelimilta Docker-kontteihin ECS klusteriin. Serverin päivitys toteutettiin aiemmin manuaalisesti palvelimilla ajettavilla bash-skripteillä. Uudistuksessa päivitysten asennusprosessi automatisoitiin CircleCI:n, CloudFormationin ja AWS CodeDeployn avulla.

Näiden muutosten jälkeen sivustolle haluttiin täysin uusi ilme, jolloin seuraava looginen askel oli modernisoida ja uudistaa käyttöliittymä/frontend-koodi aiemmin käytetystä FlightJS:stä Reactiin. Käyttöliittymän uudistuksessa näkymiä uudistetaan yksi kerrallaan. Uudistus pitää sisällään Reactin lisäksi muitakin osia, kuten esimerkiksi mainosten hallinnan ja SEO:on liittyvien ongelmien ratkaisut. Näkymien uudistamisen yhteydessä on tehty myös muutoksia backend-sovelluksille, kuten esimerkiksi React-sovelluksen renderöinti palvelimella suorituskyvyn ja SEO:n parantamiseksi sekä muutoksia datan hakuun ja käsittelyyn.

Lähitulevaisuudessa tietokannat migratoidaan AWS:n RDS-palveluun sekä nykyiset backend-sovellukset pilkotaan omiksi mikropalveluiksi AWS:n ECS-palveluun ja Lambda-funktioiksi. Myös testauskäytäntöjä uudistetaan syksyn aikana.

Projekti on tällä hetkellä kestänyt noin vuoden. Ensimmäinen osa alkoi syksyllä 2018, ja siinä oli vahvasti mukana Markus Nousiainen. Tämä projektin ensimmäinen osa päättyi tammikuussa 2019, ja heti sen jälkeen alkoi nyt käynnissä oleva toinen osa. Tällä osalla ei ole tarkkaa lopetusaikaa. Kehitystiimimme toimii hyvin, ja yritämme jatkuvasti parantaa tuotteen laatua ja omaa tekemistämme esimerkiksi kehittämällä ohjelmistokehitysprosessia ja hyödyntämällä uusia teknologioita.

Asiakkaan kanssa tehdään erittäin tiivistä yhteistyötä. Olen mukana asiakkaan tiimissä ja työskentelen paljon heidän tiloissaan. Arjessa ei välttämättä edes erota, että olen Webscalen väkeä. Tämä työskentelytapa mahdollistaa parhaan mahdollisen lopputuloksen. Olen itse tykännyt tästä projektista. On ollut palkitsevaa auttaa asiakasta sopivien ratkaisujen löytämisessä.”

Kesän kootut – skumppakilistelyä, masurapsuja ja rentoa yhdessäoloa

Tue, 23 Jul 2019 11:07:00 GMT

Elokuu on ihan nurkan takana ja suurin osa lomalaisista palailee sorvin ääreen. Ei meillä silti ihan toimettomina olla oltu kesällä muutoinkaan, kuten etenkin instagramiamme seuraavat tietävät! Ajattelinkin koota tähän joitakin hetkiä meidän kesän työpäivien varrelta. Suvi toivotettiin tervetulleeksi tietysti kesäjuhlien muodossa. Veneilimme jo toista kertaa Stora Herröön, missä viihdyimme muun muassa ruoan, juoman, saunan ja […]

AWS Re:Inforce 2019

Wed, 03 Jul 2019 06:26:00 GMT

Viime syksyn re:Inventissä julkistettu AWS:n tietoturvaan keskittynyt konferenssi sai konferenssiyleisöltä ansaitut aplodit: viime vuosina vauhdilla kasvanut Las Vegasin tapahtuma houkutteli paikalle yli 50 000 kävijää. Allekirjoittanutta on aina kiinnostanut nimenomaan infrastruktuuritason tietoturva. Vastaavasti hallinta (governance) ja yhteensopivuus (compliance) ovat asioita, joiden kanssa tehdään usein yhteistyötä asiakkaiden kanssa. Tätä silmälläpitäen eurooppalaisesta näkökulmasta lähempänä Bostonissa järjestettävä, pelkästään pilvialustan tietoturvaan keskittynyt konferenssi on loistava keksintö.

Julkisten pilvipalveluiden kasvu näkyy hyvin aiheen tiimoilta järjestetyissä tapahtumissa. Itse vierailin Las Vegasissa vuonna 2015 ja tällöin paikalla oli noin 20 000 vierasta. Siksi tuntuikin käsittämättömältä, että tiistai-aamun avausta, AWS CISO Steve Schmidtin keynotea oli pakkautunut kuuntelemaan noin 10 000 ihmistä yli 50 maasta. “Security is job zero”. Hyvä että tärkeä viesti kiinnostaa muitakin.

IT-alan konferensseissa mielenkiintoisin anti kohdistuu yleensä asiakkaiden esityksiin. Ensiksi kerrotaan ongelmallinen case ja tämän jälkeen esitetään ratkaisu. Näin tälläkin kertaa; erilaiset DevSecOps -prosessiin liittyvät aspektit, julkipilven käyttöönotto tietoturva edellä ja turvallisen ulkokehän (secure perimeter) rakentaminen sovellusten ympärille tarjosivat mielenkiintoisia näkökulmia. Security Jam taas mahdollisti leikkimieliseen kisailuun: joukko haasteita joita ratkaistiin yhdessä pienen ryhmän kanssa samalla muita vastaan kilpaillessa tarjosi mukavaa viihdettä iltapäivän ajaksi.

Vaikka re:Inventistä tutut, massiiviset tuotejulkistukset loistivat poissaoloillaan, nähtiin tapahtumassa silti pienempiä julkistuksia. VPC Mirroring tarjoaa uuden työkalun infrastruktuuritason verkkoseurantaan mahdollistaen esimerkiksi helpomman vianetsinnän ja poikkeamien havaitsemisen liikenteestä. Aiemmin julkistetut Security Hub ja Control Tower ovat nyt myös kaikkien AWS:n asiakkaiden käytössä.

Vaikka konferenssiohjelma pitikin varattuna kellon ympäri, jäi aikaa myös pintapuoliseen kaupunkiin tutustumiseen. Kesäinen päivä kaupungilla kului vauhdikkaasti ennen kotimatkaa.

Ensi vuonna re:Inforce järjestetään kesäkuun puolivälissä Houstonissa, Teksasissa.

Mielenkiintoisia poimintoja sessioista:
DDoS Attack Detection at Scale (SDD408)

How Dow Jones Uses AWS to Create a Secure Perimeter (SDD316)

Encrypting Everything with AWS (SEP402)

Kasvun vuosi, ja valoisat näkymät uudelle vuodelle!

Fri, 22 Feb 2019 09:33:00 GMT

2018 on saatu kunnialla päätökseen ja vuodenvaihteeseen perinteisesti kuuluvat kiireet ovat ohi. Nyt voin ilokseni sanoa varauksitta että kulunut vuosi sujui erinomaisesti.

Lunastimme pitkäjänteisen laadukkaan työn hedelmiä voittaessamme Yleisradion kilpailutuksen laajasta vaalikoneiden toteutuksesta ja aiemmat menestyksemme vaalikoneiden toteutuksessa herätti ansaittua huomiota myös muiden asiakkaiden keskuudessa.

Taloudellisesti liikevaihtomme nousi 81% viime vuodesta 1.5 miljoonaan euroon. Tästä oli liikevoittoa 15%. Asiakkaamme ovat olleet tyytyväisiä työhömme sekä kysyttäessä että yhteistyön jatkuvuudella mitattuna – yli 70% liikevaihdostamme teimme asiakkaillemme, joiden kanssa työskentelimme jo aiempina vuosina.

Pitkäaikainen asiakkuus tarjoaa nopeasti kehittyvällä alalla sekä meille että asiakkaillemme tilaisuuden oppia toisiltamme, ja tuoda hyviksi havaittuja teknologioita käyttöön muualta. Syvällinen ymmärrys asiakkaamme toiminnasta ja ympäristöstä tehostaa tietysti myös uuden kehittämistä.

Webscalessa on nähty monta uutta ja ennestään tuttua kollegaa työntekijämäärämme noustua vuoden alun 11 työntekijästä 18 tekijään. Alkanut vuosikin on jatkunut samoissa merkeissä uuden työkaverimme liityttyä kuun alusta joukkoon.

Koulutuspanostuksemme näkyvät muun muassa sertifikaatioiden määrässä – vuoden aikana tekijämme ovat saavuttaneet viisi AWS-sertifikaatiota ja 15 henkilöä on käynyt alan konferensseissa. Dev Trainee -ohjelmaamme osallistunut Heikki on nykyään konsulttina asiakasprojekteissamme saatuaan vahvan pohjan käytännön tekemiselle kokeneempien konsulttien kanssa työskennellessään.

Meille on tärkeää että rakentaessamme yhteiskunnallisesti merkittäviä palveluita olemme myös aktiivinen ja vastuullinen toimija suomalaisessa yrityskentässä. Tämän vuoksi julkaisemme tiedot verojalanjäljestämme täydentämään jo aiempaa katsausta ympäristövaikutuksiimme.

Jatkamme työtämme uusien teknologioiden ja laadukkaiden asiakasprojektien parissa. Ole yhteydessä kun suunnittelet kehityshanketta tai etsit työpaikkaa jossa ei tarvitse harmitella töihin tuloa.

Kollegoiden apuri ja haasteisiin tarttuja

Wed, 19 Dec 2018 10:52:00 GMT

DevOps Lead Lauri nauttii Webscalen ilmapiiristä ja muiden auttamisesta

DevOps Lead Lauri Stenin päivät täyttyvät työssä AWS- sekä DevOps-asioiden ympärillä. Webscalessa yhdessä tekemisen kulttuuri on syvällä, ja Laurinkin mukaan juuri yhteiset haasteet ja kavereiden jeesaaminen ovat työn parasta antia. Ja onpa hänellä myös nuoremmalle IT-sukupolvelle pari vinkkiä jaettavanaan!

Seitsemän kuukautta Webscalella viihtyneellä Laurilla on tällä hetkellä työn alla useampikin asiakasprojekti. Erilaiset asiakkaat tuovat työhön vaihtelevuutta ja mielekkyyttä.

– Autan asiakkaitamme erinäköisissä asioissa alkaen AWS-ympäristön luonnista POC:ien tekemiseen. Autan myös DevOps-periaatteiden kanssa, Lauri kertoo työtehtävistään.

Täysin uusissa greenfield-projekteissa hän vastaa siitä, että ympäristöt rakennetaan parhaiden käytäntöjen mukaan ja tietoturvallisesti.

– Projekteissa, joissa on menty jo vähän eteenpäin, autan automaatioissa ja oikeanlaisten työkalujen ja -metodien valinnassa. Eli kaikessa, millä vain saadaan asiakkaan tiimistäkin se paras teho irti, Lauri toteaa.

Lauri on siis saanut tarttua monenlaisiin tehtäviin. Firmaan hän päätyi yrityksessä työskentelevien vanhojen tuttujen suosituksesta.

– Olin kuullut firmasta pelkkää hyvää. Sainkin töitä hakiessa Webscalesta sellaisen käsityksen, että täällä on hyvä työilmapiiri. Huomasin myös, että omat ja firman näkemykset vastaavat hyvin toisiaan.

Pienessä yrityksessä Lauri on päässyt työskentelemään hyvin erilaisten asioiden kimpussa.

– Jos on tuntunut siltä, että jokin asia kaipaa viilaamista, on aika usein itse päässyt asiaa työstämään. Samalla on nähnyt hyvin erilaisia ratkaisuja ja myös oppinut hurjasti, Lauri kertoo työn viehätyksestä.

Vanhuudenhöperyys iskee – muiden jeesaaminen tuo hyvän fiiliksen

Lauri on ollut alalla jo pitkään ja häntä voisi kaiketi jo kutsua alan konkariksi. Mikä työssä sitten koukuttaa, miksi sitä jaksaa edelleen?

– Vielä muutama vuosi sitten olisin sanonut, että uusien tekniikoiden oppiminen on se juttu. Viime aikoina on varmaan enemmän alkanut vanhuudenhöperyys iskeä ja itselle on ollut tärkeä nähdä, kun muut oppivat. Siitä tulee tosi hyvä fiilis.

Työssään hän saa välillä puurtaa yksinäisenä sutena. Usein kuitenkin juuri kollegoiden kanssa työskentely on työn suola. Yhdessä jumpataan haastavia asioita. Puolin ja toisin kysellään myös mielipiteitä ja apuja eri työtehtävissä.

– Samalla pääsee pureskelemaan mukavia visaisia pähkinöitä, joihin ei välttämättä muuten törmäisi. Se sopii itselle hyvin, koska olen aina tykännyt haasteista. Ja tietysti on mukava päästä jeesaamaan kavereita.

Nörtit koodaa kellarissa ja muita oletuksia

IT-alalla pitää koko ajan olla valmis opiskelemaan lisää ja tarttumaan haasteisiin. Samalla pitää olla valmis kurottamaan oman mukavuusalueen ulkopuolelle.

– Löydän kyllä itsestäni hyvin vahvasti näitä piirteitä ja siksi työ kiinnostaa ja kehittää jatkuvasti, Lauri hymyilee.

Laurin mukaan ”Nörtit koodaa kellarissa” -ajattelulla ei kuitenkaan enää pärjää.

– Vaikka IT-alasta on näin perinteisesti ajateltu, ei sillä nykyaikana pitkälle pötki. Muistakaa nuoret panostaa myös niin sanottuihin soft skillseihin eli pehmeisiinkin taitoihin ja arvoihin, eikä pelkästään teknisen osaamisen kehittämiseen, hän ohjeistaa pilke silmäkulmassaan.

Lauri on myös innokas valokuvaaja

Työ on vaativaa ja hektistäkin, joten ihan kaikkea ei aina pysty tekemään omalla työajalla. Vapaa-ajalla on pakko, jos ei muuta, niin ainakin välillä seurata alaa. Laurin mukaan omaa aikaa kuitenkin jää ja onhan omaan alaan syventyminen tärkeää myös muilla aloilla.

– Itsellä vapaa-aika kuitenkin kuluu vaimon kanssa matkustellessa, valokuvausta harrastaessa sekä erinäköisten urheiluharrastusten puitteissa. Sen lisäksi kyllä välillä tulee tehtyä jotain omia IT-projekteja siinä sivussa, hän nauraa.

Haluatko jutella mitä voimme tarjota sinulle?

Ole yhteydessä Henriin meilillä tai puhelimitse: rekry@webscale.fi tai +358 50 490 5585.

Pyhiinvaellus Vegasiin

Mon, 10 Dec 2018 07:00:00 GMT

Webscalen jokavuotinen pyhiinvaellus Las Vegasiin ja AWS re:Inventiin on jälleen onnistuneesti suoritettu. Tänä vuonna allekirjoittaneen lisäksi mukana olivat Heikki ja Markus, joille molemmille tämä oli ensimmäinen kerta re:Inventissä. Jo useamman re:Inventin kokeneena oli hienoa saada jälleen uusia webscalelaisia mukaan reissulle.

Jo ennakkoon oli tiedossa, että konffapäivät tulisivat olemaan täynnä virallista ja vähän epävirallisempaakin ohjelmaa aina myöhäiseen iltaan asti. Halusimme kuitenkin nähdä muutakin kuin Stripin ja kasinot, joten yhdistimme matkaan myös muutamia päiviä omaa lomaa ennen ja jälkeen konferenssin. Vegasin tutkiminen kävi helposti ja edullisesti Uberia ja polkupyöriä hyödyntäen. Tarkistimme muun muassa alkuperäisen kasinoalueen Fremont Streetillä, jonka rosoisempi ympäristö oli mukavaa vaihtelua Stripin luksusmiljööseen.

Mieleenpainuvin kokemus reissulla oli tietysti kierros kopterilla Grand Canyonilla, jota voin ehdottomasti suositella kaikille Vegasissa vieraileville. Oma korkeanpaikankammokin unohtui saman tien kun kopterin jalakset irtosivat maan kamaralta.

Itse konferenssi oli tietysti jälleen isompi ja mahtavampi kuin edellisenä vuotena ja oli viimevuotiseen tapaan hajautettu usean hotellin alueelle. Majoituimme Palazzossa, ja koska emme halunneet käyttää aikaa paikasta toiseen siirtymiseen, tuli suurin osa esityksistä katsottua sen vieressä olevassa Venetianissa. Valtavasta osallistujamäärästä huolimatta järjestelyt pelasivat erinomaisesti ja vaikka jonot suosituimpiin sessioihin ja keynoteihin olivat välillä aivan jäätäviä, katosivat ne aina lähes yhtä nopeaa kuin olivat muodostuneetkin.

Mitäpä olisi re:Invent ilman Andyn ja Wernerin julkistuksia uusista AWS-palveluista? Tänä vuonna pääpaino oli koneoppimisessa, analytiikassa ja ylemmän tason palveluissa, jotka helpottavat AWS:n muiden palveluiden käyttöä ja joilla saa nopeasti valmista aikaan ilman, että täytyy ymmärtää taustalla olevia usein hyvinkin monimutkaisia kokonaisuuksia. Tämä on ihan oikea painotus sillä pilven suurimpia etuja ovat juurikin valmiit ratkaisut, joita yhdistelemällä oman palvelun tai tuotteen rakentaminen on nopeaa ja kustannustehokasta.

Meidän mielestä mielenkiintoisimmat julkistukset olivat aikasarjatietokanta Amazon Timestream , Dynamon transaktiot ja On-demand-kapasiteetti , useamman AWS-tilin hallinnointia helpottava AWS Control Tower sekä Lambdan layerit . Näiden lisäksi oli tietysti valtava joukko muitakin julkistuksia, joihin perehtymiseen saa kyllä varata taas reippaasti aikaa. Katso koko lista uusista jutuista täältä .

Kaiken kaikkiaan re:Invent oli jälleen todella hieno kokemus. Päivät täyttyivät mielenkiintoisesta ohjelmasta, joista ainakin omasta mielestäni parhaita olivat nimensä mukaisesti pintaa syvemmälle menevät deep dive -esitykset. Uuden oppimisen vastapainoksi oli mukava tavata vanhoja tuttuja ja tietysti myös tutustua uusiin ihmisiin ja kuulla heidän kokemuksistaan AWS:n palveluista. Kotiin viemisinä saimme roppakaupalla uutta tietoa ja innostusta, joita tuskin maltamme päästä soveltamaan projekteissamme.

Huippudevaajan unelma – Webscalen kokenut kehittäjä paljastaa tarkoin varjellun salaisuuden

Mon, 22 Oct 2018 09:16:00 GMT

Juho Rautio on alkujaan Webscalen ensimmäinen palkattu työntekijä. Hän on ollut talossa 3,5 vuoden ajan ja tässä ajassa paljon on muuttunut: kolmen hengen porukka on kasvanut 18-päiseksi ja Raution ura on hänen omien sanojensa mukaan kehittynyt räjähdysmäisesti.

Se ei ole mikään uutinen, että kaikki haluavat palkata meidän Juhon. ”Hae meille!” -somemainokset pyörivät kuumina 24/7, headhunterit soittelevat ja LinkedInin viestipalvelu täyttyy houkutteluviesteistä.

Juho, mikä se huippudevaajan unelma on?

Mahdollisuudet oman osaamisen kehittämiseen, monipuoliset projektit ja kivat työkaverit. Nämä tekijät toistuvat useissa houkutteluviesteissä ja mainoksissa. Näitä siis tyypillisesti odotetaan kuuluvan ohjelmistokehittäjän toivomuslistaan.

Klikkiotsikoinnin mukaisesti Rautio kertoo tässä blogitekstissä, mikä on huippudevaajan unelma, ja mitä nämä tiheään viljellyt korulauseet hänen työssään ovat konkreettisesti tarkoittaneet. Ei se oikeasti ole tarkoin varjeltu salaisuus.

1. Tekemisen vapaus

Rautio työskentelee Webscalella toimien tällä hetkellä suurta osaa suomalaisia hyödyttävän palvelun web-tiimin Lead Developerina ja vastaa palvelun arkkitehtuurista ja teknologiavalinnoista. Kyseiselle palvelulle tuli vastikään täyteen miljoona käyttäjää.

”Olen talossa ollessani tullut Fullstack-kehittäjästä siihen pisteeseen, että suunnittelen tällaisille massiivisille palveluille arkkitehtuureja, pystyn vetämään tiimejä ja olemaan tästä kaikesta vastuussa”, Rautio kertoo. ”Se on itselleni merkittävä henkilökohtainen kasvu.”

”Olen luonteeltani sellainen, että innostun helposti ja olen kunnianhimoinen. Harvoin tyydyn siihen, että tekisin vain sen mitä pyydetään, vaan haluan tehdä aina vähän enemmän”, hän jatkaa.

Ja Rautio on saanut vapaasti tehdä. Hän kertoo, että urakehityksen on ensisijaisesti mahdollistanut se, että vastuuta saa ottaa ja vapaus sekä mahdollisuudet tällaiseksi osaajaksi kehittymiseen on annettu.

”Urakehityksen on ensisijaisesti mahdollistanut se, että vastuuta saa ottaa ja vapaus sekä mahdollisuudet tällaiseksi osaajaksi kehittymiseen on annettu.”

”Olen päässyt tekemään monia projekteja ihan nollasta. Sehän on jokaisen kehittäjän unelma. Meillä tehdään paljon tällaisia projekteja, joissa teknisten ratkaisujen reunaehtoja ei ole saneltu, vaan niistä saa itse päättää”, Rautio sanoo.

Webcsalella ollaan juuri käynnistämässä merkittävää Ylen Vaalikone -projektia. Sen webscalelaiset saavat tehdä itse alusta asti. Palvelua tulee käyttämään valtava osa Suomen aikuisväestöstä.

”Siinä on hyvä esimerkki kokeneelle tekijälle mielekkäästä projektista, jolla on myös yhteiskunnallista vaikutusta”, Rautio sanoo.

2. Huippuammattilaisuus

Toinen tärkeä tekijä on kouluttautuminen ja huippuammattilaisena kehittyminen. Webscalen työntekijöillä on mahdollisuus kouluttautua ja sertifioitua AWS-osaajaksi nopeasti. Pääasiassa webscalelaiset suorittavat AWS Certified Solutions Architect Associate -sertifioinnin, joka on muun muassa maailman toisiksi parhaiten palkattu.

Rautio itse on suorittanut vaativimman mahdollisen AWS Certified Solutions Architect Professional -sertifioinnin, joka on yksi IT-maailman vaativimmista. Kun Rautio suoritti sen, sellainen oli vain muutamalla tuhannella koko maailmassa. Webscalen porukassa kyseisiä sertifiointeja on yhteensä neljä kappaletta.

”Sertifikaatteihin valmistautuminen ja niiden suorittaminen on auttanut itseäni paljon eteenpäin”, Rautio sanoo. ”Meillä suhtaudutaan vakavasti opiskeluun. Pidämme myös sisäisinä Tech Day -päivinämme toisillemme koulutuksia ja vuosittain matkustamme maailmalle alan tärkeimpiin seminaareihin.”

”Meillä suhtaudutaan vakavasti opiskeluun.”

Webscalen oman porukan toisilleen pitämät Tech Day -esitykset ovat huippuluokkaa, mistä kertoo esimerkiksi se, että Rautio veti äskettäin työkavereilleen pitämänsä Tech Day -luennon Suomen AWS-yhteisölle.

Rautio on osallistunut Las Vegasissa pidettävään AWS re:Invent -tapahtumaan jo kolme kertaa peräkkäin. Vuoden 2018 tapahtumaan lennätetään tosin tänä vuonna vuorollaan uusia Webscale-kasvoja, jotta firman sisäisesti päästään tasaisemmin jakamaan mahdollisuuksia osallistua seminaariin.

3. Massiiviset projektit ja henkilökohtainen kehitys niiden myötä

Sanomattakin selvää, että isoja projekteja on Rautiolla tullut tehtyä. Yhdistelmä on aika mukava: pienen firman hengessä tehdään korkean profiilin projekteja.

Rautio sanoo, että projektien vaihtuminen matkan varrella pitää työn mielekkäänä. Projekteissa pääsee oppimaan uutta ja tekemään erilaisia ratkaisuja.

”Sitä on huomannut, että olen päässyt asiakkaiden projekteissa aina vastuullisempiin rooleihin, kuin joissa olen sinne mennyt.”

”Kokemusta talosta löytyy, miten todella isolla käytöllä olevat palvelut pyörivät ympäri vuorokauden kaikille.”

Viime vuosien aikana Webscalen porukka on toteuttanut muun muassa suurimpien suomalaisten sanomalehtien, kuten Helsingin Sanomien vaalikoneita. Kokemusta talosta siis löytyy, miten todella isolla käytöllä olevat palvelut pyörivät ympäri vuorokauden kaikille.

4. Itseä fiksumpi työporukka

”Meillä on täällä vahva vertaistuki. Se on iso yksittäinen syy, miksi olen tullut tänne alkujaan töihin”, Rautio sanoo. ”Uravalintojani on yhdistänyt punainen lanka, että haluan tehdä aina töitä itseäni fiksumpien kanssa.”

Webscalella haasteisiin saa apua kasvotusten tai vähintään Flowdockin välityksellä jopa minuuteissa, eikä ole väliä kysyykö neuvoa vieressä istuvalta harkkarilta tai firman toimarilta. Matala hierarkia mahdollistaa myös edellä mainitun oma-aloitteisuuden ja vapauden omaa työtä kohtaan.

”Matala hierarkia mahdollistaa oma-aloitteisuuden ja vapauden omaa työtä kohtaan.”

Rautio sanoo olevansa ylpeä siitä, että porukkaan on saatu myös tulevaisuuden tähtiainesta. Uusia kovia tekijöitä on saatu suoraan koulun penkiltä ja he ovat muutamassa vuodessa kasvaneet isompiin rooleihin asiakasprojekteissa.

”Porukassamme on sellaista osaamista, että sillä ei mennä pieleen”, Rautio sanoo.

5. Tulevaisuuden näkymät

Rautio sanoo, että jos saisi lisätä jonkin lisämausteen Webscaleen parantamaan koostumusta, olisi se tulevaisuudessa sujuvampi jakautuminen tiimeihin. Tämä tuleekin toteutumaan entistä paremmin, kun yritys kasvaa vielä muutamalla työntekijällä. Webscalella halutaan tehdä töitä omalla tiimillä, jolla voi mennä sellaisenaan asiakasprojektiin.

”Webscalella halutaan tehdä töitä omalla tiimillä, jolla voi mennä sellaisenaan asiakasprojektiin.”

”Alamme olla jo sen kokoinen firma, että omia tiimejä voidaan muodostaa. Muun muassa tulevaan vaalikoneprojektiimme muodostetaan tiimi kokonaan Webscalen toimesta”, Rautio sanoo. ”Se on korkean profiilin projekti, josta tulemme olemaan ylpeitä.”

…

Meillähän on oma lehmä ojassa. Etsimme nimittäin sinua, kokenut Frontend-devaaja , vahvistamaan rivejämme entisestään ja tekemään isolla osaamisroolilla kanssamme lisää vaativia projekteja. Lue lisää avoimesta tehtävästä!

Tältä näyttää IT-yrityksen ympäristöjalanjälki

Fri, 21 Sep 2018 11:24:00 GMT

Mikä on Webscalen vaikutus ympäristöön?

Maapallon ympäristöasiat ovat olleet viimeiset parikymmentä vuotta hyvästä syystä esillä: Samaan aikaan kun tiedeyhteisössä on todettu ihmisen vaikutuksen ilmastonmuutokseen olevan näillä tiedoilla tosiasia, lähemmässä mittakaavassa on jo pitkään puhuttu diversiteetin katoamisesta. Viime vuosina pinnalle on noussut myös muovijätteen kertyminen luontoon. Vaikka näiden asioiden korjaamiseen oikea paikka olisi valtioiden välisten sopimusten tasolla sekä kansallisessa lainsäädännössä, on yritysten silti syytä tarkastella myös omaa toimintaansa.

Miten sovelluskehitys vaikuttaa ympäristöön?

Sinänsä kaltaiselleni idealistille IT-ala on sikäli palkitseva, että järjestelmiä tehdään usein vähentämään turhaa työtä ja turhaa kulutusta palveluissa tai teollisissa prosesseissa. Siltä osin alan toiminnalla on positiivinen vaikutus. Käytännössä kuitenkin tietotekniikan vastuulle tulee samanaikaisesti valtava sähkönkulutuksen kasvu, ja esimerkiksi Bitcoinit kuluttavat tällä hetkellä arvioiden mukaan jo saman verran sähköä kuin Tanska [1].

Netflix aiheuttaa 37% kaikesta verkkoliikenteestä [2]. Vaikka streamauspalveluiden käyttö keskittyy ensisijaisesti nuoriin tai teknisesti ennakkoluulottomiin käyttäjiin, tuo verkkoliikenne on käytännössä ylimääräistä sähkönkulutusta. Monet palvelut ovat olemassa saattaakseen ihmisiä yhteen, ja samalla somepalvelut haalivat ihmisistä ikuisesti säilytettävää dataa, josta louhitaan suurella säilytys- ja laskentakapasiteetilla markkinoijille ja mielipiteenmuokkaajille tietoa. Kaikki tuo laskentakapasiteetti kuluttaa sähköä, ja ala on jatkuvassa kasvun tilassa.

Laitteiden tuottaminen kuluttaa luonnonvaroja, mutta esimerkiksi kännykät voidaan jättää tällaisessa tarkastelussa ulkopuolelle itse alan arviosta, koska puhelimet voidaan olettaa hankittavan muutenkin. Kannettavat tietokoneet ovat energiankulutukseltaan tehokkain vaihtoehto työvälineeksi, mutta niiden valmistus ja kierrätys ovat ongelmallisia ympäristön näkökulmasta [3]. Tällä hetkellä kannettavat tietokoneet ovat vähiten haitallinen vaihtoehto tarjolla olevista työvälineistä.

Valmistuksen osalta kiinnostavaa on työvälineiden ja muiden hankintojen kestävyys, koska niiden ympäristökuormituksestä on vaikeampi saadta luotettavaa numeerista tietoa. Valtaosa kaikista yrityksen sähkölaitteista tuotetaan ulkomailla ja kuljetetaan Suomeen. Tältä emme nykyisellään pysty välttymään, ja voimme lähinnä tiedostaa asian. Massan puolesta merkittävämpää ovat kalusteet, jotka tietääksemme ovat lähes täysin kotimaista tekoa, eikä esimerkiksi merikuljetuksia ole tarvittu. Käytännössä kuitenkin materiaalien alkuperästä ei ole varmaa tietoa.

Henkilöstön liikkumistapojen suhteen toimisto ydinkeskustassa suosii vahvasti julkisen liikenteen käyttöä – vasta Kehä I:n ulkopuolelle siirryttäessä alkaa autoilu olemaan mielekäs vaihtoehto kulkuvälineenä. Myynti ja kauempana sijaitsevilla asiakkaillamme työskentelevät konsultit kulkevat siellä pääosin autoilla, eikä tuohon ole ajankäytön vuoksi järkevää vaihtoehtoa.

Entä pilvipalveluiden ympäristövaikutus?

Webscale on erikoistunut käyttämään AWS:n pilvi-infrastruktuuria, ja tämä palvelininfra edustaa verkkoliikenteen lisäksi kaikkea yllä mainittujen palveluiden energiankulutusta. Jatkuvasti kehittyvät pilvialustat mahdollistavat innovatiivisten palveluiden ja datavarastojen rakentamisen, jonka vuoksi näitä järjestelmiä kehitetään aina vain enemmän, ja aina vain isommiksi. Tekninen kehitys siis mahdollistaa halvemmalla yhä useammalle yritykselle ja julkiselle toimijalle uusien palveluiden käyttöönoton ja esimerkiksi tekoälyratkaisujen toteuttamisen AWS-pilveen on resurssien puolesta hyvin suosittu käyttötapaus.

Käyttämämme palvelinresurssit ovat konseptuaalisesti irrotettu fyysisestä palvelimesta – käsittelemme virtuaalisia laskentayksikköjä, joista maksamme ennalta määrättyä hintaa. Oman tarkastelumme kannalta voimme todennäköisesti jättää fyysisten laitteiden valmistuskustannukset pois, koska emme voi niihin vaikuttaa. Sen sijaan sähkönkulutus sekä laitteiden käyttöön että jäähdytykseen olisi hyödyllinen mittari. Käytännössä näitä tietoja ei kuitenkaan ole saatavilla, edes suhteellisena arvona per laskentayksikkö. Teknisesti ottaen haluaisin tietää kuinka suuri on kW / vCPU – eli kilowattitunteja per virtuaalinen prosessoriyksikkö. Tätääkän tietoa ei ole saatavilla, ja yritykset kauniista eleistä huolimatta eivät jaa kyseistä tietoa tai edes suurpiirteisiä lukuja joista voisi päätellä asioita. Esimerkiksi tietoliikenneyhteyksien osalta on käytetty kWh / Gb -arvoa kuvaamaan sähkönkulutusta runkoverkon liikenteeseen.

Greenpeace kritisoi AWS:ää 2015 läpinäkyvyyden puutteesta [4] artikkelissa, jossa ennen kaikkea heidän tavoitteenaan oli edistää uusiutuvien energialähteiden käyttämistä. AWS julkaisi silloin heidän AWS & Sustainability-brosyyrisivustonsa [5]. Siellä he ilmoittavat että ovat nykyisin 50% uusiutuvan energian käyttäjiä, ja että nykyiset EU:n data centerit ovat “carbon neutral”. Tätä väittämää ei avata sen enempää perusteiltaan kuin toteutustavaltaankaan. Energiamixin osalta ongelmallista on amerikkalainen ydinvoiman välttely, joka johtaa tilanteeseen jossa 25% sähköstä tuotetaan edelleen hiilellä, ja erityisesti Greenpeace rinnastaa implisiittisesti ydinvoiman ja hiilen yhtä huonoiksi vaihtoehdoiksi vertailutaulukossaan.

Mielenkiintoisempia argumentteja pilvi-infran ympäristövaikutuksista löytyy ennen kaikkea AWS:lle työskentelevien James Hamiltonin vastineesta [6] ja Jeff Barrin blogista [7]. Barrin julkaisemien lukujen perusteella 2015 “On average, AWS customers use 77% fewer servers, 84% less power,and utilize a 28% cleaner power mix, for a total reduction in carbon emissions of 88% from using the AWS Cloud instead of operating their own data centers.”

Parempaan käyttöasteeseen ei ole lainkaan vaikeuksia uskoa, mutta energiamix on sijaintikohtainen asia. Tämän vertailun kannalta voidaan keskittyä pelkästään tuohon 84% virransäästöön. Se tarkoittaa että kulutettujen resurssien pysyessä vakiona pilvi-infrastruktuurin käyttäminen tarkoittaa energian kulutuksen vähentämistä kuudesosaan siitä, mihin omassa konesalissa päästäisiin.

Kuinka paljon yrityksen muu toiminta vaikuttaa?

Käytämme melko vähän energiaa ja fyysisiä tavaroita itse liiketoimintaan – ilman fyysisen tavaran myyntiä kulutuksemme vastaa normaalia palveluliiketoimintaa. Toimitilojen lämmitys muodostaa yhden suurimmista yksittäisistä eristä Suomen ilmastossa. Toimimme lähinnä Suomessa, joten työmatkustustakaan asiakaskäynneistä ei tule ulkomaille. Kotimaassa hyödynnämme vahvasti etätyömahdollisuuksia toisinaan jopa Helsingin seudun sisäisen liikkumisen välttämiseen.

Suurimmat liikennepäästövaikutukset syntyvät varmasti henkilöstön koulutuksesta ja konferenssimatkustuksesta. AWS re:Invent on ollut vuosia vakio-ohjelmistossamme päivittämään henkilöstömme osaamista uusimpien AWS:n muutosten osalta. Olkoonkin että konferenssissa käyvien määrä on pysynyt melko vakiona yrityksen koon kasvaessa moninkertaiseksi.
Valtaosa muusta konferenssimatkustamisesta tapahtuu Euroopan sisällä, ja jää pienemmäksi vaikutukseltaan.

Säännöllisenä tapahtumana Webscalen Levin-reissu tuottaa yksittäisenä tapahtumana isoimmat matkustuksen päästöt, koska tuonne matkustaa koko yritys. Tämä on selkeä kohde jossa voisimme kuluttaa vähemmän, mutta tällä hetkellä matka on tärkeä tilaisuus virkistäytymiseen ja tutustumiseen työn ulkopuolella. Ajan- ja rahankäytön vuoksi tuolle ei ole parempaa vaihtoehtoa kuin lentäminen.

Miksi energiankulutuksesta pitäisi välittää?

Anders S.G. Andrae esitti 2017 [8] että todennäköisessä tilanteessa globaali ICT-teknologian energiankäyttö tulee kasvamaan vuoden 2015 8.2% globaalista kulutuksesta vuoteen 2025 20.7 prosenttiin. “Best case”-skenaariossa merkittävien energiatehokkuuden parannusten kera ennuste on 9.0% globaalista kulutuksesta.

IT-energiankulutuksen jakautuminen kuluttajien välilä myös muuttuu nykyisestä tilanteesta, jossa kuluttajalaitteeet käyttävät 55% ja data centerit 11% IT-kulutuksesta. Samalla kun kulutajalaitteet tulevat energiatehokkaammiksi, data centerien ennustettu kulutus kasvaa merkittävästi [9]. Tämä energiankulutus on jatkossa merkittävin tekijä IT-järjestelmien ympäristökuormassa, ja se välillisesti näkyy datacentereiden sijoituspaikoissa paikallisen sähköntuotannon energiamixin muodossa.

Anders S.G. Andrae (Huawei). (2017). Total Consumer Power Consumption Forecast. researchgate.net .

Viitteet:

[1] Ars Technica : Bitcoin insane energy consumption explained – https://arstechnica.com/tech-policy/2017/12/bitcoins-insane-energy-consumption-explained/

[2] Variety : https://variety.com/2015/digital/news/netflix-bandwidth-usage-internet-traffic-1201507187/

[3] Sciencing : https://sciencing.com/laptops-affect-environment-23252.html

[4] Greenpeace : https://www.greenpeace.org/usa/wp-content/uploads/legacy/Global/usa/planet3/PDFs/2015ClickingClean.pdf

[5] AWS & Sustainability: https://aws.amazon.com/about-aws/sustainability/

[6] James Hamilton. (2015): Greenpeace, Renewable Energy, and Data Centers. https://perspectives.mvdirona.com/2015/05/greenpeace-renewable-energy-and-data-centers/

[7] Jeff Barr. (2015): Cloud Computing Server Utilization & the Environment. https://aws.amazon.com/blogs/aws/cloud-computing-server-utilization-the-environment/

[8] Anders S.G. Andrae (Huawei). (2017). Total Consumer Power Consumption Forecast. researchgate.net .

[9] Anders S.G. Andrae and Peter Edler (2015): On Global Electricity Usage of Communication Technology: Trends to 2030 mdpi.com

Webscale 5 vuotta!

Thu, 16 Aug 2018 06:00:00 GMT

Webscale täytti juuri pyöreät viisi vuotta. Tuntuu uskomattomalta, että tätä on tehty jo niin kauan – tekemisen meininki on pysynyt samanlaisena innostuneena, vaikka meitä on nykyään kolmen sijaan seitsemäntoista. Perusasiat on pidetty ennallaan, vaikka kasvu näkyykin laajemmassa osaamisen ja kiinnostuksen kohteiden kirjossa: Tehdään teknisesti meitä kiinnostavia kehitysprojekteja asiakkaille, joiden kanssa haluamme työskennellä.

Muutimme juuri toiseen toimistoomme Kalevankadulle edellisen käytyä ahtaaksi, mutta firmalle tämä on jo neljäs osoite. Perustettaessa firma sijaitsi virallisesti yhden perustajan kotona. Vain pieni parannus tilanteeseen oli postiosoitteen siirtäminen toimistohotelliin, josta se pian siirtyikin jo Rautatientorin laidalle Mikonkadulle. Viimeisin toimiston etsiminen kesti yli vuoden verran, kunnes löysimme uuden kodin Pyy-korttelista samasta risteyksestä Kolmen sepän kanssa.

Täällä ympäriinsä katsellessa huomaan, että olemme päässeet vuosien varrella mukaan Suomen mittakaavassa suuren luokan projekteihin tekijöiksi – on rakennettu videostreamauspalveluita, useampi vaalikone, massiivisia analytiikkajärjestelmiä, uudistettu sulautettuja järjestelmiä ja oltu mukana tukemassa startupien kasvua. Asiakkaina kaikkea startupeista suuriin konserneihin – esimerkkeinä HS TV, Helsingin Sanomat, Keskisuomalainen, Menumat, Aktia, Liquidblox ja Zervant. Näiden asiakkaiden kanssa on ennen kaikkea ollut mukavaa tehdä kehitysprojekteja siellä toimivien tekijöiden vuoksi.

Yrityksen strategia on karkeasti ottaen ollut tehdä kiinnostavia teknisiä projekteja hyvien asiakkaiden ja mukavien työkavereiden kanssa. Tuolla toiminta-ajatuksella työ on ollut hauskaa jo 5 vuotta ja pidämme siitä kiinni jatkossakin kasvaessamme.

EFAIL ja suositus PGP-salauksesta luopumisesta

Tue, 15 May 2018 08:36:00 GMT

OpenPGP [ 1 ] on pitkäikäinen salausstandardi sähköpostiviestintään. Sitä on pitkään pidetty turvallisena tapana välittää sähköpostia turvattomassa kanavassa, jota nykyinen vaihtelevasti salattu sähköpostin siirtoväylä Internetin yli on. Muun muassa Edward Snowden suositteli PGP:n / GPG:n käyttöä journalisteille ja muille, jotka toimivat vihamielisessä ympäristössä – kuten aktivisteille, sekä yritysten ja hallinnon whistleblowereille.

Äskettäin julkaistu tekninen artikkeli [ 2 ] “Efail: Breaking S/MIME and OpenPGP Email Encryption using Exfiltration Channels” osoittaa, että hyödyntämällä vastaanottajan sähköpostiohjelmistojen haavoittuvuuksia, voidaan PGP-salatun viestin sisältö saada selville mikäli hyökkääjällä on käytettävissään salattu viesti. Haavoittuvuus on julkaistu sivustolla https://efail.de .

Hyökkäys hyödyntää sähköpostiohjelmien taipumusta suosia käyttäjäystävällisyyttä turvallisuuden sijaan. Artikkeli ja efail.de näyttävät miten HTML-viestissä ulkoisen resurssin lataamista käytetätän vuotamaan salattua tietoa – salattu viesti puretaan osaksi ladattavan kuvan osoitetta, joka ladataan viestin purkamisen jälkeen ja samalla lähetetään purettu viesti palvelimelle.

Haavoittuvuuden julkaisun jälkeen verkkoon julkaistiin tulkintoja asiasta, ja toimintaohjeet vaihtelivat epäselvistä varsin teknisiin. Alla selventävää tietoa asiasta.

Keskipitkän aikavälin ratkaisu on sähköpostiohjelmien päivittäminen estämään nyt tunnetut haavoittuvuudet. Pidemmän ajan vaativa todellinen ratkaisukeino edellyttää S/MIME ja PGP-standardien päivitystä vastaamaan muuttuvaa tilannetta ja vastaavasti sähköpostiohjelmien päivityksen uuteen standardiin.

Linkit :

Kokoelma ihmisiä, jotka testaavat ideaansa

Wed, 25 Apr 2018 09:27:00 GMT

Eräästä liiketoiminnan lähtökohtia käsittelevästä esityksestä minulle on jäänyt yksi lause erityisesti mieleen:

Lauseessa viitataan liikeideaan, mutta se herättää itsessäni myös enemmän ajatuksia. Jokaisella ihmisellä on idea omasta tulevaisuudesta ja siitä, mihin haluaa panostaa aikaansa. Asiakkaiden lisäksi työntekijöiden on uskottava yrityksen liikeideaan. Terve yritys tarjoaa työntekijöillensä mahdollisuuden testata ja toteuttaa ideoitansa.

Työntekijälähtöisyys

Toimimme alalla, jossa kilpailemme sekä hyvistä osaajista että mielenkiintoisista projekteista ja kehittyvistä asiakaskumppanuuksista. Olemme haastaneet itsemme miettimään asiakashyötyä ja työn mielekkyyttä monesta eri näkökulmasta.

Kilpailuetu syntyy asiakkaiden ja työntekijöiden kokemasta arvosta ja siitä, että on jossakin heille tärkeässä asiassa kilpailijoita parempi. Tiedämme, että monessa yrityksessä on huippuosaamista, mutta ihmiset eivät välttämättä ole tyytyväisiä työhönsä. Tämä valitettavasti näkyy myös asiakkaille, kun projektien avainhenkilöt vaihtuvat ja hankkeet viivästyvät. Väitän, että asiakkaiden kannalta varsinkin osaajakeskeisillä aloilla on iso merkitys millainen yrityskulttuuri kumppaniyrityksessä on.

Työn mielekkyys muodostuu monesta tekijästä ja haemme mielekkyyttä eri tasoilla. Yksilötasolla on merkitystä esimerkiksi mahdollisuudella hyödyntää omaa osaamistaan ja kehittyä. Monille työn sosiaalinen aspekti on tärkeä. Se muodostuu mm. työkavereista, asiakkaista ja arvostuksesta. Työntekijälähtöisyys on kilpailuetu, kun yrityksen toimintatavat- ja mallit muotoillaan niin, että ne tukevat jokaisen tavoitteita – sekä työntekijän että asiakkaan. Kun ihminen voi hyvin, niin on helpompi toimia ja olla tuottava alati muuttuvassa toimintaympäristössä, jollaisia usein ketterät ohjelmistokehityshankkeet ovat.

Osaamista ja välittämistä

Yrityksemme kasvaa ja olemme kiitollisia, että sekä asiakkaat että työntekijämme uskovat liikeideaamme. Kilpaillulla alalla asetan usein itselleni silti kysymyksen: miksi asiakas ostaa juuri meiltä?

Uskon, että alallamme asiakashyöty rakentuu osaamisesta ja välittämisestä. Tähän oleellisesti liittyy myös lupausten tekeminen. Työntekijöille lupaamme mahdollisuuden toteuttaa ideoita ja asiakkaille lupaamme, että he hyötyvät näistä ideoista ja huippuosaamisesta digitaalisen liiketoiminnan tehokkuuden parantumisena. Välitämme siitä, että työntekijämme pääsevät toteuttamaan itseänsä – ja siitä, että asiakkaamme hyötyvät tästä.

Muista nämä IOT-hanketta ostaessasi

Thu, 29 Mar 2018 09:45:00 GMT

IoT-hankkeissa vanhat sulautetut järjestelmät ja puutteet hankintasopimuksissa tulevat kalliiksi hidasteeksi, kun järjestelmiä lähdetään laajentamaan ja jatkokehittämään. Tämän vuoksi päätin julkaista omat neuvoni yritysten järjestelmähankintoihin. Olennaiseksi nämä asiat tulevat, kun olemassa olevaa järjestelmää lähdetään nostamaan toiminnallisesti seuraavalle tasolle datan yhdistelyn, automaattisen huoltotoiminnan ja älykkään valvonnan osalta – jolloin usein pelkän rautatoimittajan kyvykkyys ja intressit eivät usein riitä muuttuneisiin tarpeisiin.

Kaikkien projektituotosten pitäisi olla hankinnan lopuksi laitteen ostajan omaisuutta tai vähintään vapaasti käytettävissä. Muussa tapauksessa laitteilla liiketoimintaa tekevä ostaja joutuu kantamaan liiketoimintariskin siitä, että laitteen toimittaja lopettaa toimintansa tai ryhtyy kiristämään hinnoittelemalla monopoliasemansa turvin työnsä kalliiksi.

Järjestelmien hankintaan liittyy kolme erilaista kehityshanketta, joilla kullakin on omat huomioitavat piirteensä hankintaa tehtäessä. Sulautetun laitteen suunnittelutyö ottaa kantaa ennen muuta fyysiseen laitteeseen ja sen elektroniikkasuunnitteluun. Vahvasti sidoksissa itse laitteeseen on laitteen ohjelmakoodin kehitys, joka on puhtaasti digitaalisena tuotoksena hyvin eri luonteinen kuin fyysinen tuote. Johtuen kytköksestä itse laitteeseen, laitteen ohjelmistossa on pakostikin juuri tälle laitteelle räätälöityä toteutusta, mutta tämä on syytä abstraktoida hyvin itse toimintalogiikassa. Kolmas osa on verkkopalvelun kehittäminen laitteen tietojen ohjaamiseksi. Sulautettujen järjestelmien kanssa poikkeukset tavanomaisesta verkkopalvelukehityksestä johtuvat mahdollisista laitteen rajoittamista kyvykkyyksistä tietoliikenteen ja salauksen suhteen.

Sulautetun laitteen suunnittelutyö:

Laitteen ohjelmakoodin kehityshuomiot:

Verkkopalveluiden kehitys:

Kun näistä asioista on sovittu jo hankintaa tehdessä pitävästi, voit paljon luottavaisemmin mielin kehittää liiketoimintaasi tietäen, että IOT-järjestelmäsi on teknisesti kehittämiskelpoinen, eikä kehitystyöhön jatkossa tule hintalappua kankean järjestelmän korvaamisesta tai selvittelystä puutteellisin lähtötiedoin. Lupaan myös, että tulevat kehittäjäsi kiittävät hyvästä pohjatyöstä.

Implementing a simple serverless SMS handler with Twilio and AWS Lambda

Wed, 21 Mar 2018 10:47:00 GMT

In some projects you need a way to receive and handle SMS messages. Your project might require you to make custom actions based on content of a received SMS or send SMS from your application. Ideally you would want the integration of SMS functionality to be easy and affordable. Your country probably has some local actors that provide SMS services but these might not be the best options if you want to get up and running fast and affordably.

Amazon’s Simple Notification Service (SNS) would be a natural choice when working with Amazon’s cloud services. With SNS you can send SMS, Mobile Push notifications, Email and more . But with SNS you can’t receive SMS from users and this gap must be filled somehow.

Twilio can be the answer if you need a way to handle incoming and outgoing SMS, voice, or even fax. You can send and receive SMS on a local or global scale. Twilio provides a broad set of easy to use tools, pay-per-use pricing and scalability.

In this post we will talk about my experience using Twilio for a simple serverless SMS handler. We will also discuss things that you should know before deciding to use Twilio for a project.

What is Twilio?

Twilio is a cloud service for phone calls, SMS, video and a lot more . Twilio provides rich APIs, open source libraries and SDKs for different programming languages which make using the service nice and easy. Twilio even provides a visual editor for building Twilio apps and a serverless hosting service for your Twilio code.

Twilio is a fully scalable cloud service with a pay-per-use pricing model. Twilio also deserves praise for their somewhat intuitive and fancy dashboard.

Competitors to Twilio

There are a couple of services similar to Twilio on the market. Two services worth mentioning are Nexmo and Plivo . The availability of services, phone number availability in countries and pricing varies between these providers. The comparison of these services is outside scope of this post but before choosing a service be sure to investigate and compare which one is the best option for you. In this post we are solely focusing on Twilio.

Things to know when considering using Twilio

Firstly you should check from your Twilio dashboard that your country is supported for the service you want to use. For example Twilio doesn’t yet provide finnish SMS compatible numbers but in our case we were fine with using an Estonian number for the simple serverless SMS handler.

Of course pricing is important and something you might have to think about. Pricing varies by country. With Twilio you only pay for what you use. As with any pay-per-use cloud service you really do pay for everything you use so make sure that you are aware of the volume you are going to need to avoid being blown away by massive bills. This should not be a problem unless you operate on a massive scale.

In the case of SMS numbers you pay for sending and receiving SMS. The price of sending and receiving SMS can vary by carrier. You also pay a fixed rate per month for each number you have bought from Twilio. At least this is the case with Estonian SMS numbers. Check the pricing for your country before using the service.

Twilio works in the way that it charges you a fixed amount (20$ – 2000$ in 10$ increments, 14.7.2018) when your funds drop under a specified amount (10$ – 1000$ in 10$ increments, 14.7.2018). You can also manually add funds to your account.

Finally, as with any service you are about to use, make sure you understand the acceptable use policy . Twilio has a minimum usage requirement of two (2) transmissions for each SMS number per month. If your SMS number is deemed inactive it might be released for others to buy. This is understandable since there exists a finite amount of phone numbers.

Case: simple serverless SMS handler

In this example we simply want to receive SMS, handle them and respond with an SMS.

The high level architecture for this handler is seen in figure 1.

The process begins with a user sending an SMS to the number you have bought from Twilio. Twilio receives the SMS and does a HTTP POST request to the URL you have defined in the Twilio dashboard. You can choose if you want the request to be either GET or POST.

In this case the URL is an API Gateway endpoint that triggers a Lambda Node.js function. The function will handle the message however you decide to and in our case it posts a message to one of our company’s chat rooms.

The function uses Twilio’s Node.js SDK to answer the SMS with an SMS.

The lambda function

The function is Node.js and uses Express. Naturally, to use the Twilio SDK we have to add the library to our dependencies. In order for the SDK to work you must define two (2) global variables TWILIO_SID and TWILIO_AUTH_TOKEN. You can get both of these from your Twilio dashboard. If you for some reason don’t have these global variables set, you can also start using the SDK in the way shown in the below code snippet.

Request validation

Twilio is nice enough to provide a webhook that can validate that the request really is from Twilio. In the code snippet below the middleware takes the parameters validate and url. No parameters are required by the middleware.

validate (true/false): If the request should be validated or not. It is configured to be false in local development and true in test and production.

url (string): In our case this parameter must be given because the SSL connection is terminated upstream in our stack and the URL our function receives does not match the URL Twilio calls to reach our application. Therefore to successfully validate the request we must set the url parameter. The url parameter is the same url that you have defined in the Twilio dashboard for the HTTP POST request.

Handling and answering a request

Incoming SMS have a bunch of properties . In this case we are interested in the content of the SMS and the sender’s phone number. They are naturally found from the request body as seen in the code snippet below.

Under the hood Twilio uses Twilio Markup Language (TwiML, basically XML-documents) as the data format between transmissions which you don’t luckily have to code yourself (unless you want to).

Summary

Twilio is a good choice for applications that need to receive and send SMS especially because of its easy signup, fancy dashboard, developer friendly APIs and SDKs, exhaustive documentation, scalability and affordable pricing.

As a service Twilio is interesting and it opens up opportunities for you because it makes powerful SMS and other services accessible to everyone. It is easy to use it in conjunction with other cloud services, like AWS Lambda.

On a final note when using Twilio you might have to pay close attention to your spending. Also be sure to check the availability of services you want to use in your country.

Tekemisen vapaus ohjelmistokehityksessä

Wed, 07 Feb 2018 10:10:00 GMT

Ohjelmistokehitys on luovaa työtä ja siinä kokeillaan usein uusia teknologioita ja ideoita. Työn luonteeseen kuuluu, että ratkaisua työstetään ja parannetaan niin pitkään, kunnes lopputulos on miellyttävä.

Luovaan työhön yhdistetään usein myös tekemisen vapaus. Tekemisen vapaus ohjelmistokehityksessä pitää sisällään esimerkiksi vapautta päättää työajoista ja -tavoista sekä käytettävistä teknologioista. Tehokkaissa tiimeissä kehittäjillä on vapaus toteuttaa haluttu toiminnallisuus heidän parhaaksi näkemällään tavalla. Kehittäjien kannalta vapaus on tärkeää, koska se motivoi heitä, edesauttaa heidän omaa kehittymistä ja parantaa ohjelmiston laatua.

Laadukas ohjelmistoprojekti

Laadukkaan ohjelmistoprojektin kannalta on tärkeää luoda sellaiset olosuhteet, jotka tukevat vapautta. Tällaisia olosuhteita ovat esimerkiksi nykyaikaiset teknologiavalinnat ja hyvä projektinhallinta. Nykyaikaisilla teknologiavalinnoilla varmistetaan, että voidaan noudattaa parhaita käytäntöjä ja käyttää moderneja lähestymistapoja erilaisiin ongelmiin. Lisäksi kehittäjien ammattitaito pysyy ajan tasalla ja myös tekeminen säilyy mielekkäänä. Projektinhallinnassa tämä tulisi ottaa huomioon yrittämällä löytää balanssi kehittäjien vapauden ja toiminnallisuuksien toimittamisen välillä.

Vapaus tuo myös vastuuta

Kehittäjän näkökulmasta vapauteen liittyy myös paljon vastuuta. Tärkeimpänä vastuuna on osata erilaisia teknologioita ja ratkaisumalleja, jolloin tekemisen vapautta voidaan käyttää hyödyksi parhaalla mahdollisella tavalla. Tästä syystä on tärkeää pitää omaa ammattitaitoa yllä, koska ala kehittyy jatkuvasti nopealla tahdilla. Laatuvaatimukset ja projektin scope voivat asettaa rajoitteita tekemisen vapauteen, sillä ne voivat estää tai rajoittaa jonkin tietyn lähestymistavan käyttämistä kyseisessä projektissa. On myös tärkeää ymmärtää projektiin liittyvän asiakkaan liiketoimintamalli, koska tällöin voidaan asettaa selkeämmät tavoitteet kehitystyölle.

Tekemisen vapaus Webscalessa

Webscalella tekemisen vapaus näkyy usealla eri tavalla. Tekijät pääsevät itse vaikuttamaan siihen, että minkälaisissa projekteissa he haluavat työskennellä. Projekteissa on mahdollisuus päästä vaikuttamaan teknologiavalintoihin, jolloin päästään tekemään töitä itselle mielenkiintoisten teknologioiden parissa. Tällöin asiakkaan tekninen ympäristö modernisoituu samalla. Myös omien projektien tekemistä tuetaan, sillä ne ovat erinomainen tapa kehittää omaa osaamista. Omissa projekteissa tekijällä on kaikki valta päätöksistä sekä täysi luovuuden ja tekemisen vapaus. Tästä syystä omien projektien parissa saakin hyvin syvennettyä omaa ammattiosaamista, koska pääsee keskittymään juuri sellaisiin kokonaisuuksiin kuin itse haluaa.

Oma osaaminen vaikuttaa

Oman osaamisen ylläpidolla on vaikutusta tekemisen vapauteen, koska oma ammattitaito määrittelee paljon miten hyvin vapautta pystytään käyttämään hyödyksi. Tästä syystä Webscalella oman ammattitaidon ylläpitämistä arvostetaan ja tuetaan paljon. Webscalella pystyy kehittymään monipuolisten asiakasprojektien ansiosta, koska tällöin saa kokemusta erilaisista teknologioista, ratkaisuista ja domaineista. Työntekijöiden osaamiseen panostetaan aidosti erilaisten konferenssien, koulutusten ja tech-dayiden avulla. Säännöllinen vaihtelu projekteissa tarjoaa tilaisuuden työskennellä erilaisten asioiden parissa. Näin ollen tech-dayt ovatkin loistava tilaisuus jakaa käytännön oppeja muiden työntekijöiden kanssa.

Etäyhteisöllisyyttä ja vapaan tekemisen kulttuuria

Wed, 24 Jan 2018 08:47:00 GMT

Arki sujuu Webscale -tiimissä erityisen itseohjautuvasti. Yhteisöllisyys on korkealla tasolla, vaikka olemme suurimman osan ajasta hajallaan jakautuneena asiakkaiden toimitiloihin, kotitoimistoille ja Mikonkadulla sijaitsevalle Webscale-päämajalle. Se on jotakin, josta voimme olla ylpeitä.

Tässä hieman yhden Webscalen perustajista, seniorikonsulttina työskentelevän Hannu-Pekan, tuttavallisemmin HP:n ajatuksia siitä, mitä tarvitaan hyvän yhteisöllisyyden ylläpitoon sekä porukan tiiviinä pitämiseen etätöiden ja jokaisen itse itselleen suunnittelemien aikataulujen keskellä.

Mitä tarvitaan etäyhteisöllisyyden ylläpitämiseen, HP?

Tiedon välittäminen on jokaisen vastuulla

”Teen itse noin puolet ajasta etätöitä. Asiakasprojekteissa toimimme aina asiakkaan toiveiden mukaan: joskus projektitiimin yhteistyö vaatii jatkuvaa läsnäoloa”, sanoo HP. Työn luonne on kuitenkin suurimmaksi osaksi sitä, että töitä tehdään monitoimittajatiimeissä erillään Webscale -porukasta. Etätöitä meillä tehdään pääasiassa kotitoimistolta, mitä nyt HP itse toimi kerran muutaman kuukauden jakson Saksasta käsin .

HP:n mukaan erityisen tärkeäksi tekijäksi etäyhteisöllisyydessä muodostuu tietenkin yhteydenpito. Pidämme etäpäivinä yhteyttä Flowdockin välityksellä, meilaamme ja soittelemme. Tarkempi asioiden läpikäyminen vaatii jo videochatin. Flowdockissa keskustellaan projekteista ja teknologioista, mutta juttu luistaa tietenkin myös kaikesta vapaa-aikaan liittyvästä. ”Tärkeää on, että apua ja neuvoa työkavereilta kysytään heti, ja tukea saa eikä tarvitse lyödä yksin kotona päätä seinään”, HP kertoo.

Vaikka HP on keskusteluissa aktiivinen, hän ei itse asiassa ole edes porukan puheliaimmasta päästä. Tärkeää yhteisöllisyyden ylläpitämisessä onkin se, että jokainen on itse vastuussa omasta aktiivisuudestaan. Jos itse ei muista tuoda esille ajatuksiaan, ei kukaan muu osaa niistä kysyä saati tarjota apuaan. Etäyhteisöllisyyden ja vapaan tekemisen kulttuuria vaalitaan ja myös tiimin kanssa vietetty aika on tärkeällä sijalla. Sitä varten pidetään yhteinen toimistopäivä joka perjantai. Silloin tehdään porukalla töitä, pidetään viikkokatsaus ja päivitetään kuulumiset firman ja työkavereiden tapahtumista. ”Usein perjantaisin järjestämme myös tech dayn, jolloin jaetaan opittua koko tiimille, esitellään mielenkiintoisia asioita ja ajatuksia sekä opetellaan yhdessä esimerkiksi uusia teknologioita”, HP kuvailee yrityksen käytäntöjä.

Vapaus sekä työn ja muun elämän yhteensovittaminen

Webscalessa on töissä useampia, jotka elävät parhaillaan ns. ruuhkavuosia ja arkeen kuuluu niin ikään lapsiperheen aikataulujen ja työn yhteensovittaminen. Elämää helpottaa huomattavasti se, että työmatkaan kuluvan ajan voi useana päivänä viikosta säästää ja käyttää hyödyksi. Meillä pidetään tärkeänä, että työn ja muun elämän yhteensovittaminen sujuu saumattomasti.

Etätyökulttuurin haasteena HP:n mukaan voidaan pitää sitä, että työtunnit saattavat lipsahtaa turhan pitkiksi. Etätyöskentely siirtää työnohjauksellisen vastuun lähes kokonaisuudessaan yksilölle. Systeemi perustuukin täysin luottamukseen ja silloin on muistettava myös itse piirtää raja työn ja vapaa-ajan välille. HP toteaakin: ”Ongelmia tulee, jos ei muisteta etätyöpäivän jälkeen vaihtaa vapaalle. Se alkaa pitemmän päälle näkyä ihmisestä, kun sitä rupeaa harmittamaan”.

Emme tarkoituksella ole kehittäneet tiukkoja sääntöjä tai ohjeistuksia etätyöarkeen. Meillä toimivaa etätyökulttuuria pidetään arvokkaana, ja tavoitteena on pitää se yhtä vapaana, itseohjautuvana ja yhteisöllisenä myös Webscalen kasvaessa suuremmaksi.

Etäyhteisöllisyyden kolme tärkeintä

Webscale vahvistaa palvelutarjontaansa

Fri, 12 Jan 2018 14:00:00 GMT

Tavoitteemme on tarjota Suomen parasta Amazon Web Services (AWS) -konsultointia asiakkaillemme, joiden tarpeet vaativat pilvialustan perinpohjaista tuntemista ja laaja-alaista osaamista moderneista ohjelmistoteknologioista. Asiakaspalautteen perusteella olemme onnistuneet tässä erinomaisesti.

Nyt syvennämme yhteistyötä Amazonin kanssa AWS:n pilvipalveluiden jälleenmyyntikumppanuudella , jolla vastaamme asiakkaiden kasvaviin tarpeisiin pilvialustan käyttöönotoissa, kehityksessä ja hallintapalveluissa. Helmikuussa 2017 saavutimme myös vaativan AWS Advanced Consulting -kumppanuustason.

AWS Channel Reseller ja AWS Advanced Consulting Partner -kumppanisopimusten avulla tarjoamme entistäkin kattavammin parhaita osaajia ja pilvipalveluita digitalisaatiohankkeisiin. Kokeneet ja AWS-sertifioidut kehittäjämme auttavat sekä suuria että pieniä yrityksiä skaalautuvien digitaalisen palvelun suunnittelussa, toteutuksessa ja ylläpidossa. AWS:n jälleenmyyntikumppanina tarjoamme asiakkaille johtavan globaalin pilvipalveluyhtiön palveluita suomenkielisen ja paikallisen tiimin tukemana. Lue lisää palveluistamme .

Vahvan kasvun tueksi olemme myös rekrytoineet uusia osaajia ja palkkaamme nyt lisää päteviä henkilöitä AWS-konsulteiksi ja kehittäjiksi . Tutustu avoimiin tehtäviimme ja ota yhteyttä!

Serverless in re:Invent 2017

Fri, 22 Dec 2017 13:00:00 GMT

This years re:Invent was a blast! Great announcements, solid sessions, hilarious gameday, fun networking opportunities and what a re:Play after party with DJ Snake! Personally this was third in a row and best one so far! I’ve been working with serverless systems for the past year and that’s what was in my scope!

I was glad to find out AWS announced a bucket full of new services and improvements for serverless applications. Serverless is the direction the world is going, so if you aren’t on the serverless train yet, now is the time to catch up.

What is serverless?

Serverless has many definitions, but it can be considered as next step from IaaS (Infrastructure as a Service), to FaaS (Function as a service) where abstraction of application processing moves up from deploying virtual machines and containers to deploying bare business logic functions to be executed on ephemeral automatically scalable managed execution environment such as AWS Lambda. Serverless functions can be triggered from multiple events, for example https request to API Gateway or S3 event stream event. Currently 20 different AWS services can trigger Lambda functions. [ 1 ]

Serverless architectures and applications greatly differ from traditional server/virtual machine/container based architectures and applications. In serverless environment developer no longer needs to worry about building AMIs, installing OS patches, load balancing, instance types or in some cases even VPC networking since if you only need AWS managed services like DynamoDB or S3, you can access those from public internet. Serverless application can scale virtually to any load. You only pay for the actually consumed resources like processor time, memory, networking and utilized managed services.

Amazon Aurora Serverless

“Amazon Aurora Serverless is an on-demand auto-scaling configuration for Amazon Aurora, where the database will automatically start up, shut down, and scale up or down capacity based on your application’s needs. Aurora Serverless enables you to run your relational database in the cloud without managing any database instances or clusters.” [ 2 ]

Aurora Serverless is the single most important announcement regarding serverless development. If your data has many relations and access patterns are not predictable you need a relational database. So far RDS (Relational Database Service) has been the only AWS managed option to provision relational databases. While RDS does its job well it doesn’t automatically scale in terms of performance or costs.

What is great about serverless is that extra environments cost next to nothing. You could have production like environment for every developer and you only pay for the consumed resources. Aurora serverless enables just this and can automatically scale up and down when you hit that unpredicted traffic spike.

DynamoDB Backup and Restore

DynamoDB is the go-to database in serverless environment when data access patterns are well known and there is no need for relational database features like joining tables or transactions. Previously backing up and restoring DynamoDB tables has been quite painful so this is very welcome feature which makes DynamoDB even more compelling. [ 3 ]

DynamoDB Global Tables

“Global Tables builds upon DynamoDB’s global footprint to provide you with a fully managed, multi-region, and multi-master database that provides fast, local, read and write performance for massively scaled, global applications. Global Tables replicates your Amazon DynamoDB tables automatically across your choice of AWS regions.” [ 4 ]

DynamoDB Global Tables is very welcome feature when high availability and near user global performance matter. Active-active disaster recovery model which can withstand an outage of a whole region just became so much easier to implement. Database multi-master replication is very complex issue and now it has been solved for you.

Traffic Shifting and Phased Deployments with AWS CodeDeploy

You can now shift incoming traffic between two AWS Lambda function versions based on pre-assigned weights. This allows you to gradually shift traffic between two versions, helping you reduce the risk and limit the blast radius of new Lambda deployments. [ 5 ]

Weighted traffic switching takes Lambda to new maturity level. No need to risk destroying whole system when deploying new versions. This obviously adds complexity to CI/CD pipelines and increases monitoring requirements, but CodeDeploy should ease the pain. What is your customer experience worth?

AWS Serverless Application Repository in Preview

“The AWS Serverless Application Repository is a collection of serverless applications published by developers, companies, and partners in the serverless community.” [ 6 ]

AWS announced SAM (Serverless Application Model) at 2016 re:Invent. Serverless Application Repository is a boilerplate and plugins sharing platform for SAM applications. It remains to be seen what kind of traction the repository catches. Competition is tough and currently Serverless.com is dominating serverless space from GitHub with 20,674 stars, 2,159 forks and 343 contributors.

Summary

Serverless is clearly the future of cloud software development in AWS. While this year lacked the 2015 dramatic paradigm change caused by Lambda functions publication, there were many very useful serverless announcements, especially for databases, Serverless Aurora being the most interesting one. With Serverless Aurora and DynamoDB Global Tables it’s easy and very cost efficient to scale globally. Serverless space is currently moving and evolving super fast – several of these services merit more in depth posts. Stay tuned!

[1] AWS Lambda documentation, Supported Event Sources

https://docs.aws.amazon.com/lambda/latest/dg/lambda-services.html

[2] Sign up for preview of Amazon Aurora Serverless

https://aws.amazon.com/about-aws/whats-new/2017/11/sign-up-for-the-preview-of-amazon-aurora-serverless/

[3] AWS Launches Amazon DynamoDB Backup and Restore

https://aws.amazon.com/about-aws/whats-new/2017/11/aws-launches-amazon-dynamodb-backup-and-restore/

[4] AWS Launches Amazon DynamoDB Global Tables

https://aws.amazon.com/about-aws/whats-new/2017/11/aws-launches-amazon-dynamodb-global-tables/

[5] AWS Lambda Supports Traffic Shifting and Phased Deployments with AWS CodeDeploy

https://aws.amazon.com/about-aws/whats-new/2017/11/aws-lambda-supports-traffic-shifting-and-phased-deployments-with-aws-codedeploy/

[6] Announcing the AWS Serverless Application Repository in Preview

https://aws.amazon.com/about-aws/whats-new/2017/11/aws-serverless-application-repository-enables-customers-to-discover-deploy-and-publish-serverless-applications/

Building a durable Jenkins CI setup in AWS

Fri, 24 Nov 2017 11:05:00 GMT

CI pipeline is an essential part of modern software project and one of the most popular CI-servers is Jenkins . Managing and setting up a highly available Jenkins server can be a tedious job. For smaller projects, cost of running a multi-instance setup is often too expensive.

If you are willing to accept minor downtime in case of a sudden server loss, we demonstrate here a simple self-healing single server setup that you can use in your AWS environment.

The setup uses AWS EBS . EBS is highly available and persistent block storage service, that we can use to persist Jenkins state between server terminations.

We use AWS autoscaling group with node count of exactly one that automatically restarts new server if the existing server is suddenly terminated (remember, in reality everything fails, all the time ).

We use AWS Route53 for registering a domain for the newly created Jenkins instance – so that access to the server is not bound to node IP address that changes upon termination.

To glue everything together we use EC2 instances user data and AWS Cloudformation for documented and repeatable setup.

The prerequisite

To use this template you should have basic VPC with at least one public subnet and Route53 hosted zone already set up.

The basic setup

Simple jenkins setup architecture diagram

For the sake of simplicity we install the Jenkins into public subnet, but in production usage you should run it in private subnet and manage the network access depending on your networking configuration.

The permissions

First your EC2 instance needs some permissions to call AWS API. We define IAM role that has policy that grants access to listing and attaching EBS volumes and allows EC2 to update its own DNS record in the given Route53.

The EBS Mounting

The real magic happens in the userdata script that is executed when the EC2 instance is started. When the EC2 instance is first time started a custom user data script is run. This configures the instance with defined software packages and it is also the place to run you EBS mounting and Route53 registration code.

The Route53 registration

When the Jenkins is up and running we need to bind it to some domain name (in this example jenkins.{yourdomain}) , so you don’t have to lookup the IP address every time the server restarts.

Doing the first login

To gain access to Jenkins for the first time you need get the first time login password from Jenkins.

This part of script checks if this is first Jenkins start and prints the first time login password into std-out. You can view the userdata scripts output in AWS Console.

Go to AWS console -> ec2 -> select jenkins instance
In the context menu select Instance settings -> Get system log and you should see in the bottom part of the log a entry Your Jenkins Password ********** . You can copy paste that password into Jenkins ui and login.
Now you have successfully created a simple and durable Jenkins setup =).

You can view/download the whole template jenkins.yaml here

Espoon rauhasta Berliinin vilskeeseen

Thu, 06 Apr 2017 12:00:00 GMT

Hannu-Pekan perheellä oli yhteinen haave: tehdä irtiotto arjesta Suomessa ja kokeilla hetki asumista ulkomailla. Kun H-P:n vaimon töiden puolesta sitten tuli sopiva hetki ja lapsetkin ovat vielä alle kouluikäisiä, syntyi päätös tarttua tuumasta toimeen ja lähteä puoleksi vuodeksi Berliiniin.

Aluksi H-P:n oli saatava työasiat järjestymään. Heti idean saatuaan hän kysyi tukea Berliiniin muutolle muilta webscalelaisilta ja saikin kannustavan vastaanoton. Päätöstä ei tarvinnut harkita kahdesti Webscalenkaan puolesta, koska yritys haluaa tukea työntekijöidensä mahdollisuuksia sovittaa työnteko osaksi muuta elämää ja tiedetään, että kokeneille ohjelmistokehittäjille on kysyntää ympäri maailman. Työkuvioiden järjestymisestä huolimatta jännitystä aiheuttivat muut järjestelyt – löytyisikö Suomen asuntoon vuokralaisia, mitä kautta löytyisi mieluisa vuokra-asunto, pääsisivätkö lapset Saksassa päivähoitoon?

Esivalmisteluja muutolle oli tehty jo hyvissä ajoin. H-P lähti kesällä viettämään pitkää viikonloppua Berliinissä vaimonsa kanssa ja otti kaupunkia haltuun pyöräilemällä ympäri keskusta-alueita. Silloin hahmottui, että mieluisa asuinalue olisi Prenzlauer Berg: paljon puistoja lapsille, mutta kuitenkin tarpeeksi keskustassa eläväisen kaupunkikulttuurin äärellä. Yksi syy irtiottoon oli asua hetki rauhallisen Espoon sijasta ison kaupungin sykkeessä. Lopulta kaikki järjestyikin mainiosti: omaan kotiin löytyi hyvä vuokralainen koko ajalle, asunto löytyi eläväiseltä Kollwitzstraßelta ja mieluisa työprojektikin järjestyi kivenheiton päästä asunnolta.

Nyt kun Hakamäen Berliinissä oloa on muutama kuukausi takana, soitin hänelle ja kyselin, minkälaisissa tunnelmissa elo saksanmaalla on sujunut. H-P kertoi olleensa kiinnostunut kokemaan, kuinka työnteko sekä työkulttuuri poikkeaa suomalaisesta. Näin parin kuukauden jälkeen hän on huomannut, ettei se oikeastaan poikkea. Työnteko itsessään on ihan samanlaista ja vahva pilviteknologiaosaaminen on arvossaan myös ulkomailla. Tiimi asiakkaalla sen sijaan on hyvin kansainvälinen; neljäntoista hengen porukkaan mahtuu saksalaisten ja suomalaisten lisäksi ihmisiä niin Puolasta, Hollannista, Yhdysvalloista kuin Iso-Britanniastakin, joten huvittuneesti H-P on todennut, että ainakaan työn puolesta hän ei tule saksaa tällä reissullaan oppimaan tippaakaan.

Intohimoisen ruoanlaittajan arki koki mullistuksen berliiniläisen ravintolatarjonnan edessä. Kotikatu suljetaan torstaisin ja lauantaisin, jolloin sinne tulee tori. Sen lisäksi ympäristö notkuu ravintoloita ja kahviloita ja hintataso on huokea, joten ravintoloiden illallistarjonnasta tulee nautittua selvästi enemmän kuin kotona.

Webscale AWS Advanced Consulting Partneriksi

Tue, 21 Feb 2017 07:00:00 GMT

Pitkäjänteisen kehitys- ja koulutustoiminnan tuloksena Webscale saavutti Amazon Web Servicesin Advanced Consulting Partner-kumppanuustason. Tätä on tavoiteltu edellisen Standard Partner-tason saavuttamisesta lähtien ja sitä varten kaikki Webscalen kehittäjät on koulutettu AWS:n arkkitehtisertifikaation perustasolle ja kokeneimmat professional-tasoisille sertifikaatioille.

Nyt saavutettu kumppanuustaso edellyttää Webscalelta useita loppuun asti saatettuja projektitoteutuksia, koko henkilöstömme sertifioimista vaativilla AWS-sertifikaatioilla sekä AWS:n palveluiden käyttöä suuressa mittakaavassa mitattuna palveluiden laskutuksena.

Näin saatu tunnustus osaamisestamme on meille kannustava välitavoite, ja jatkamme panostamista AWS-kehitykseen. Kehittäjillemme tämä lisää entisestään nopeutta ja ketteryyttä suurten ympäristöjen kehityksessä. Asiakkaillemme kumppanuutemme takaa sen, että meillä on sekä kokemusta, että osaavia tekijöitä ratkaisemaan heidän ongelmansa.

Innovaatiosetelien haku on käynnissä

Mon, 10 Oct 2016 04:55:00 GMT

Tekesin innovaatioseteli on tarkoitettu pienille ja keskisuurille yrityksille, jotka haluavat kehittää tuotteitaan ja liiketoimintaansa. Setelin arvo on 5000 euroa, jonka avulla yritys voi tehdä esimerkiksi nopeita kokeiluja, protoja ja demoja. Käytännössä innovaatioseteliä voi hyödyntää mm. digitaalisten palveluiden suunnitteluun ja kehittämiseen.

Webscale toimii innovaatiopalveluiden tarjoajana, joka suunnittelee ja toteuttaa skaalautuvia digitaalisia palveluita pilviteknologioita hyödyntäen. Voit käyttää innovaatioseteliä yrityksemme palveluiden hankintaan mm. uuden palvelun suunnittelussa, nykyisen palvelun kehittämisessä tai proton toteutuksessa.

Innovaatiosetelien haku on käynnistynyt lokakuussa 2010. Rahoituksen hakeminen tapahtuu Tekesin sivuilla: https://www.tekes.fi/rahoitus/pk-yritys/innovaatioseteli/

Mikäli yrityksesi harkitsee innovaatiosetelin hyödyntämistä digitaalisen palvelun suunnitteluun tai toteutukseen, niin ota meihin yhteyttä . Kerromme mitä voimme tarjota yrityksesi tarpeisiin ja neuvomme tarvittaessa hakuprosessissa.

Suuri osa asiakkaistamme on startupeja ja nopean kasvuvaiheen yrityksiä, joten tiedämme mitä yhteistyössä meiltä odotetaan ja miten saavutamme yhdessä tuloksia. Yrittäjänä ja liiketoimintapäättäjänä arvostat tehokkaasti toimivaa tiimiä, joka suhtautuu kunnianhimoisesti työhönsä ja jolla on näyttöjä merkittävistä ohjelmistokehityshankkeista.

Avoiding SEO pitholes when building Single Page Apps in AWS

Tue, 20 Sep 2016 09:00:00 GMT

Requirements for satisfying web user experience are growing fast and it is becoming increasingly difficult to fulfill those requirements with traditional server side rendered web pages. Users want immediate feedback and fluid transitions. JavaScript Single Page Applications (SPA) can provide just that, highly responsive user interfaces without freezing page loads.

SPAs are quickly replacing traditional server side rendered web application user interfaces. Chart below demonstrates this trend with currently most popular SPA framework AngularJS against traditional server side rendering technologies. Historically popular PHP is in decline too but is left out to keep the chart readable.

Even though SPAs are great for building responsive app like user experiences and provide many benefits over the server side rendered static html sites, they come with few fundamental drawbacks. Biggest issue is that most crawlers and bots can’t render JavaScript content yet, except for Google and Bing to some level.

It’s absolutely crucial for any public site to be accessible for search crawlers and social media platforms. To achieve this reliably crawlers and bots need to be served pre-rendered static HTML of the requested content instead of the SPA. Some latest SPA frameworks like ReactJS and Angular 2 provide means for server side prerendering, but with most others like AngularJS 1.X prerendering has to be implemented manually.

Prerendering

Prerendering means that the SPA is executed with browser like PhantomJS and the outputted static HTML snapshot of the application state is returned to the requester instead of the actual SPA. This way the requester doesn’t need to execute any JavaScript to get fully rendered HTML.

Easiest way to achieve prerendering is to use open source NodeJS application like prerender . You can run it on your own machines or use SAAS offerings like https://prerender.io/ .

Now all you need to do is to detect when a bot or a crawler is requesting the page and respond with the prerendered static HTML. ‘User-Agent’ HTTP Request header is the easiest way to detect crawlers and bots. There are ready made configurations available for most popular platforms like this one for Nginx . There is one major problem with User-Agent headers and CloudFront which I will describe in detail below.

CloudFront

Amazon Web Services (AWS) has a great Content Delivery Network (CDN) managed service called Amazon CloudFront . In a nutshell CloudFront is network of distributed edge location servers providing fast access to resources by caching them close to user. CloudFront is a must have for almost any public site running on AWS.

When resource is requested from the service URL the request is routed to the CloudFront edge location. CloudFront replies with cached object if present or passes the request to the origin. Origin is the actual service running in AWS datacenter.

In order for CloudFront to work efficiently it doesn’t cache requests based on User-Agent header.

This is problematic since the web server running on the origin needs the User-Agent header to detect bots and crawlers.

Unfortunately there is no perfect solution for the issue. The best solution is to configure CloudFront to pass all page load requests to the origin with User-Agent header. User-Agent header is not passed by default so it needs to be configured. This means CloudFront can’t cache any page load requests and the bootstrap index.html is always returned from the origin. Good news is that you can and should have all other resources cached to the CloudFront to minimize the performance hit.

Conclusion

JavaScript Single Page Applications can provide great user experience and are quickly replacing traditional server side rendered web frameworks. Web fundamentals change slowly and only few crawlers and bots can render JavaScript content. Search engine visibility and compatibility with social media platforms is crucial for any public website.

For SPA to be accessible for all the platforms, prerendering needs to happen. Prerendering sets special requirements for the infrastructure configuration.

Amazon CloudFront is powerful content delivery network and should be leveraged for almost every public web service on AWS to guarantee steady performance globally. To enable prerendering with CloudFront some special configurations are required until AWS comes up with something more elegant.

Ideally AWS would add custom cache key header for crawlers and bots as they have already implemented support for different device types:

Paremman maailman tavoittelijat

Mon, 05 Sep 2016 08:00:00 GMT

Elämäni yrittäjänä alkoi 2013 perustaessani Webscalen kahden kollegani kanssa. Tavoitteenamme oli työ, jossa itse päätämme mitä ongelmia lähdemme ratkaisemaan, ja miten elämme valtaosan hereilläoloajastamme.

Nyt olemme näytöillämme lunastaneet ne perusoletukset, joilla yritystä suunnitellessamme perustelimme päätöksen itsellemme – laaja kokemuspohja ja rakkaus ihmisten kanssa työskentelyyn on tuonut meille pitkäaikaisia asiakkuuksia, kiinnostavia ongelmia ratkaistavaksi ja ennen kaikkea muutamia hyviä ystäviä.

Samalla itselleni on korostunut yrittäjien kanssa toimimisen edut – voin puhelinsoitolla sopia hankkeista, joissa molemmat haluavat nähdä toisen osapuolen menestyvän, enkä sitä varten tarvitse pitkiä neuvotteluja lakiosaston tai budjettineuvostojen kanssa. Yrittäjien kanssa toimiessa näillä yrityksillä on kasvot.

Vaikka päässä pyörii päivästä toiseen sekä pitkän tähtäimen suunnitelmat että yrityksen välittömät tarpeet, on päivän päätteeksi kuitenkin olo, että oma kohtalo on omissa käsissäni, eikä kukaan muu ole esteenä oman ideaalimaailmani rakentamiselle.

Perheeni – ne jotka kanssani näkevät tämän elämän joka päivä – kertoo että yrittäjäksi ryhdyttyäni olen ollut iloisempi iltaisin. Siinä on jo syytä riittävästi.

Hyvää Yrittäjän päivää kaikille nykyisille ja tuleville yrittäjille!

Kilpailukyky syntyy osaamisesta

Tue, 22 Mar 2016 22:37:00 GMT

Nyt voimaan tulevan kilpailukykysopimuksen myötä suomalaisten työaika kasvaa yhteensä 24 tuntia vuodessa. Tämän toteuttaminen on paikallisesti sovittavissa.

Meillä ei ole IT-alalla perinteisesti ongelmana, että työt eivät kiinnostaisi. Pikemminkin rajanvetoa joutuu tekemään sen välillä, että onko kotona iltaisin toteutettu harrasteprojekti käytettävissä asiakastöissä, ja jos on, miten tuo työ kompensoidaan. Perinteisesti yhden devaajan mielenkiintoisesta ideasta lähtenyt open source -projekti on otettu ensin sisäiseen käyttöön, ja monesti vielä lähdetty tuotteistamaan kyseista projektia. Vaikka projekti ei koskaan pöytälaatikosta nousisikaan esiin, sitä työstäessä on opittu tulevissa hankkeissa tarvittavaa osaamista.

Webscalella päätimme, että työajan lisäys käytetään ammattitaidon kehittämiseen itse valittuna ajankohtana. Ainoana edellytyksenä pidämme, että tätä kerättyä taitoa jaetaan myös muille tiimipäivinä. Ensi vuonna työntekijämme saavat käyttää tätä työaikaa open source- tai oman harrasteprojektin kehittämiseen, osallistumiseen vertaisryhmiin kuten meetupeihin, osallistujana normaalin työajan ulkopuolella konferensseihin, tai vaikka lasten koodikoulun järjestämiseen.

Miten välttää epäonnistuminen digitalisaatiohankkeissa?

Fri, 15 Jan 2016 07:30:00 GMT

Tänä päivänä Suomessa on käynnissä useita digitalisaatiohankkeita niin julkisella kuin yksityiselläkin puolella. Sähköisten palvelujen saaminen yhdeltä luukulta nopeasti ja turhaa käsittelyä välttäen tuo säästöjä ja parantaa käyttäjäkokemusta.

Suuret tavoitteet johtavat monesti suuriin hankkeisiin, ja suuret hankkeet ovat tunnetusti olleet aina haastavia. Miten tällä kertaa voitaisiin välttää ne samat ongelmat, joihin kerta toisensa jälkeen törmätään, kun rakennettava kokonaisuus kasvaa isommaksi kuin tekijöidensä kyky ymmärtää sitä?

Miksi aina käy niin?

Miksi järjestelmät sitten kasvavat hallitsemattomiksi monoliiteiksi ja lopulta rämettyvät sellaiseen tilaan, että niiden ylläpito ja kehittäminen käy mahdottomaksi? Harvoin ne syntyessään ovat tässä lohduttomassa jamassa, vaan muutos tapahtuu ajan kanssa ja lähes huomaamatta sitä mukaa kun järjestelmälle keksitään yhä uusia tehtäviä ja vastuita. Jokainen lisätty ominaisuus tekee seuraavasta muutoksesta aina vähän vaikeampaa, kunnes kehitys pysähtyy. Miten tämä jo ennalta nähtävissä oleva kohtalo voidaan välttää?

Suuri kokonaisuus pienistä paloista microservices-arkkitehtuurilla

Microservices-arkkitehtuurissa yhden ison ja kaikesta vastuussa olevan järjestelmän sijaan rakennetaan useita pienempiä palveluja, joilla jokaisella on vain yksi tarkkaan rajattu tehtävä. Nämä palvelut ovat itsenäisiä kokonaisuuksia, joilla on mahdollisimman vähän riippuvuuksia keskenään. Palvelujen välinen viestintä tapahtuu kevyillä protokollilla, joista yleisimpiä ovat REST-rajapinnat sekä viestijonot.

Poistamalla palvelujen väliset tiukat riippuvuudet saavutetaan useita etuja:

Vaikeaan ongelmaan ei ole helppoa ratkaisua

Microservices-periaatteiden noudattaminen ei kuitenkaan ole aina helppoa. Suunnittelun kannalta haastavin tehtävä on päättää missä kulkevat palvelujen välisten vastuiden rajat. Tämä linjanveto voi olla hyvinkin vaikeaa, varsinkin jos toimiala ei ole tuttu tai sen liiketoimintasäännöt ovat tekijöille hepreaa.

Myös arkkitehtuurin hajautettu luonne tuo mukanaan omat haasteensa ja vaatimuksensa. Palveluista on esimerkiksi rakennettava vikasietoisia, jotta lyhyet tietoliikennehäiriöt tai yksittäisten palvelujen hetkellinen hajoaminen ei vie kaikkia muitakin mukanaan.

Microservices-arkkitehtuuri ei tietenkään sovellu kaikkiin projekteihin. Se tuo mukanaan kompleksisuutta ja suuremman määrän liikkuvia osia, joiden hallinta ja orkestrointi voi viedä suhteettoman paljon resursseja projektissa. Pienet ja yksinkertaiset järjestelmät eivät siis todennäköisesti hyödy microservices-arkkitehtuurista, mutta suurille IT-hankkeille se voi olla ainoa järkevä vaihtoehto.

Innovaatioita ja uutta tekemisen meininkiä!

Voitaisiinko microservices-arkkitehtuuria noudattamalla varmistaa digitalisaatiohankkeiden onnistuminen? Pelkästään tekniseltä kannalta tarkasteltuna sen mukanaan tuomat edut kuulostavat jo varsin hyviltä, mutta on vielä jotain muutakin, joka oikein hyödynnettynä voi muuttaa tavan, jolla isoja hankkeita vedetään.

Microservices-arkkitehtuurin yhteydessä puhutaan projektien sijaan tuotteista. Tuotteen rakentanut tiimi vastaa siitä kokonaisuudessaan myös julkaisun jälkeen ylläpitäen sitä ja oppien kuinka se käytännössä toimii tuotantoympäristössä. Pitkäjänteisempi työ tuotteen parissa tuo kehittäjät lähemmäksi loppukäyttäjiä ja auttaa heitä löytämään ratkaisuja, joilla tuote saadaan palvelemaan käyttäjiään vieläkin paremmin.

Erityisesti julkishallinnon hankkeet hyötyisivät tällaisesta kehitysmallista, koska se mahdollistaa myös kotimaisten pienten ja ketterien IT-talojen osallistumisen julkisten palvelujen kehittämiseen. Aito kilpailu varmistaisi myös sen, ettei yhdellekään toimittajalle tulisi edes mieleen tarjota nykyaikaan täysin sopimattomia ratkaisuja, kuten Apotti-hankkeen MUMPS .

Suomessa on jo pitkään kyselty innovaatioiden perään. Koko kansan palveluiden digitalisoinnin yhteydessä on kaikki edellytykset luoda hyvät olosuhteet innovoinnille ja tuoda samalla kaivattua uutta näkemystä ja intoa julkisen puolen IT-hankkeisiin.

Älä omista mitään

Fri, 27 Nov 2015 12:45:00 GMT

Tänään vietetään Älä osta mitään-päivää, tavoitteena herättää kuluttajia ajattelemaan ennen turhan krääsän hankkimista kotinsa täytteeksi. Jokainen meistä pärjäisi vähemmällä viihde-elektroniikalla ja vähemmillä leluilla. Mahdollisesti niihin leluihin kuluvan ajan voisi myös käyttää paremminkin.

Yritykset ovat jatkuvasti tehostamassa toimintaansa, ja useimmat turhat kulut onkin jo pudotettu budjetista vuosia sitten. Jäljelle jääneet kuluerät on jonkin osaston mukaan välttämättömiä kuluja, joista ei millään voi enää leikata.

Tässä vaiheessa on siis syytä kyseenalaistaa välttämättömyyksiä yrityksen ydintoiminnan kautta. Aiemmilla vuosikymmenillä IT-osasto on ollut vastuussa työkoneiden lisäksi palvelimista, niiden tiloista, huollosta, korjaamisista, jäähdytyksestä ja ylläpidosta. Aika on kuitenkin ajanut tästä mallista ohi. Jos yritys edelleen omistaa palvelimia, on sille vain muutama kelvollinen perustelu:

Kaikissa muissa tapauksissa palvelimia omistetaan tavan vuoksi, muutoksen pelossa tai koska oman työpaikan pelätään olevan kiinni niissä laitetorneissa.

Kun yritys luopuu turhasta materiasta palvelinten muodossa, se vapautuu kolmivuotissuunnitelmista päivitysten suhteen, vapauttaa toimitilojaan tuottavaan käyttöön sekä vapauttaa henkilöstönsä ratkomaan ydintoiminnan murheita fyysisten laitteiden kunnossapidon sijaan.

Samalla tavalla kuin yrityksen näkökulmasta sähkö tulee töpselistä, on syytä ymmärtää että nykyään laskentakapasiteetti tulee pilvestä. Jokainen voi yrittää pyörittää omaa sähköntuotantoaan, mutta ellei se ole yrityksen ydinliiketoimintaa, kaikki pääoma joka sidotaan sähköntuotantoon, on poissa asiakkaiden palvelemisesta. Samoin palvelinkapasiteetin kanssa.

Olemme nyt Webscale Oy

Tue, 10 Nov 2015 06:00:00 GMT

Uusi nimi selkeyttää yhtiön identiteettiä skaalautuvien digitaalisten palveluiden suunnittelijana ja toteuttajana sekä mahdollistaa myös paremmin kansainvälisen toiminnan.

Webscale rakentaa digitaalisia menestystarinoita asiakkailleen, joille on tärkeätä liiketoiminnan ketteryys, skaalautuvuus ja innovatiivisuus. Yhtiön asiakaskunta muodostuu laajasti eri toimialoilta ja eri kokoluokista. Uuden nimen yhteydessä Webscale julkaisee myös asiakastarinat Helsingin Sanomien vaalikoneesta ja startup-yritys LiquidBloxista.

Amazon Web Services (AWS) konsultointikumppanina Webscale panostaa henkilöstön koulutukseen ja osaamiseen. Yhtiön kaikki konsultit ovat AWS-sertifioituja ja heillä on keskimäärin 10 vuoden työkokemus kehittäjä- ja arkkitehtirooleissa.

AWS re:Invent suomalaisen kumppaniyrityksen silmin

Fri, 16 Oct 2015 12:00:00 GMT

Viime viikolla Las Vegasissa järjestetty AWS re:Invent tarjosi jälleen kerran valtavasti mielenkiintoisia julkistuksia, erinomaisia esityksiä ja mukavaa iltaohjelmaa. Olimme edellisen vuoden tapaan paikan päällä ottamassa selvää mihin suuntaan pilvipalvelut tulevat seuraavan vuoden aikana kehittymään.

AWS:n palveluiden käyttö on kasvanut valtavasti viimeisen vuoden aikana ja samassa tahdissa on kasvanut myös itse konferenssi, joka myytiin loppuun pari kuukautta ennen sen alkamista. Tapahtumapaikkana toimineen Venetian-hotellin käytävät ja salit tuntuivatkin välillä käyvän jo liian ahtaiksi viime vuodesta reilusti kasvaneelle konferenssille. Perinteiseen tapaan AWS:n uudet palvelut julkistettiin peräkkäisinä päivinä pidetyissä keynoteissa, joista ensimmäisen piti AWS:n VSP Andy Jassy ja jälkimmäisen CTO Werner Vogels.

Internet of Things (IoT) on käsite, jonka potentiaali on valtava ja josta kaikki puhuvat. Tähän asti puhetta onkin riittänyt, mutta konkretian tasolle pääseminen on ollut vaikeampaa. Osasyynä tähän on varmasti se, että riittävän helppoja ja tehokkaita työkaluja ei ole ollut yleisesti saatavilla. AWS IoT on yksi tämän vuoden kiinnostavimmista julkistuksista ja sen myötä IoT-vallankumouksen ei pitäisi jäädä ainakaan työkaluista kiinni. Myös Webscalen porukkaan nousi välittömästi ennennäkemätön IoT-kuume, jota entisestään ruokki konferenssissa jaetut AWS IoT:hen valmiiksi integroidut pikkulaitteet, joille kilvan keksimme käyttöä.

IoT oli ehkä tämän vuoden suurin yksittäinen puheenaihe, mutta AWS:llä oli paljon muutakin uutta tarjolla. Analytiikka ja Business Intelligence oli yksi vahva teema, jonka alle AWS julkisti useita uusia palveluita. Amazon QuickSight on BI-työkalu, jolla ennusteiden ja analyysien teko suurista datamääristä on vaivatonta ja reaaliaikaista. QuickSight integroituu saumattomasti AWS:n muihin palveluihin, joten se voi hyödyntää esimerkiksi AWS Redshiftiin tai DynamoDB:hen kerättyä tietoa. QuickSight tulee olemaan todellinen haastaja perinteisille BI-työkaluille edullisen hintansa ja suorituskykynsä ansiosta.

Amazon Kinesis sai myös lisää ominaisuuksia, jotka tekevät siitä entistäkin hyödyllisemmän ratkaisun jatkuvien datavirtojen käsittelyyn ja tallentamiseen: Amazon Kinesis Firehose suoraviivaistaa datavirtojen tallentamista suoraan S3:een ja Redshiftiin, ja Amazon Kinesis Analytics taas mahdollistaa SQL-kyselyjen ajamisen suoraan datavirtaan.

Odotettu lisäys AWS:n analytiikkatyökalujen valikoimaan oli myös Amazon Elasticsearch Service , joka nimensä mukaisesti mahdollistaa Elasticsearchin, tuon suositun open source haku- ja analytiikkamoottorin ajamisen palveluna AWS:n pilviympäristössä. Elasticsearch on erinomainen työkalu esimerkiksi sovellusten ja niiden logien reaaliaikaiseen monitorointiin ja analysointiin.

Osa julkistuksista oli tarkoitettu helpottamaan pilveen siirtymistä. Näistä merkittävimpiä olivat Amazon RDS:n tuki MariaDB:lle ja uusi mielikuvituksettomasti nimetty AWS Database Migration Service , joka lupaa merkittävästi helpottaa tietokantamigraatioita tarjomalla työkalut datan siirtämiselle ja muokkaukselle eri tietokantatuotteiden välillä. Persoonallisemmin nimetty AWS Snowball puolestaan tarjoaa yrityksille kustannustehokkaan tavan siirtää äärimmäisen suuria, petatavuluokan datamääriä konesaleista pilveen.

Näiden lisäksi re:Inventissä julkaistiin suuri määrä muitakin tuotteita ja palveluita. Esimerkiksi uusi EC2 X1 -instanssi järisyttävällä 2 Teratavun muistilla, AWS Lambdan tuki Python-ohjelmointikielelle ja lukuisia odotettuja parannuksia Dockerien ajoon tarkoitettuun EC2 Container Serviceen. Näistä ja muista uusista julkistuksista voit lukea lisää AWS:n sivuilta .

AWS re:Invent on ennen kaikkea oppimiskonferenssi, joka on suunnattu ensisijaisesti AWS:n palveluiden käyttäjille ja heille, jotka kehittävät omia ratkaisujaan niiden päälle. Päivät olivatkin täynnä asiaa ja hyviä oppeja tarttui roppakaupalla kotiin viemisiksi. Iltaisin virallisen ohjelman vastapainoksi oli hyvin aikaa rentoutua, verkostoitua ja tavata muita asiantuntijoita.

AWS-konsultointikumppanina meille on tärkeää, että asiakkaidemme projekteissa työskentelevillä asiantuntijoilla on tuoreimmat tiedot ja tämän takia meillä AWS re:Invent on aina ensisijaisesti devaajien tapahtuma.

Top 3 wishlist for our public cloud Christmas – the AWS re:Invent

Fri, 02 Oct 2015 11:38:00 GMT

AWS re:Invent is right around the corner, and Webscale engineering squad is flying over to our yearly cloud Christmas event to get the latest tech releases fresh from the source – and to enjoy a week in Vegas as a bonus.

In 2014 we came back home with shiny new toys – Lambda for serverless applications, EC2 Container Service to run Docker clusters and Aurora for massively scaling SQL backend.

This year we come prepared with a wish list of things AWS could do even better.

1. Scheduling service

Creating backups, sending a scheduled newsletter and computing web store predictions are all often required examples of scheduled jobs that need to run on online services.

While AWS offers a brilliant set of services for most other needs, a job scheduler is still something you need to write yourself, from scratch.

Commonly used implementations are using a application server scheduling system – which requires a server – or running them as scripts on a on-schedule autoscaling groups – which requires a server – or lately, scheduling the job on Data Pipeline. Each of these implementations works, but requires extra effort and bunch of boilerplate for a simple job. It is like hammering a nail with a chainsaw – in some cases it works, but it is clear that this is not the right tool for the job.

2. API-driven ELB preheating – or better load balancers instead

When you know your service is about to receive a high traffic surge, you need to prepare your environment. Despite being able to scale up your correctly designed AWS environment in minutes, the load balancer service component ELB is a known potential bottleneck for high sudden loads.

Nowadays you need to manually create a support ticket for preparing, “pre-heating”, the load balancer every time you know the service traffic is about to spike. Imagine sending a monthly discount promotion newsletter and having to each and every time send that ticket – or getting lower performance.

We’ve been telling AWS at every turn that this needs to be automated – or gotten rid of the preheating need entirely. In best AWS tradition they tell us it’s being worked on but they can’t really publicly say anything about release plans.

3. NAT server as a service

Running your servers without any publicly visible endpoints is done with private subnets, and having a NAT instance controlling the traffic to your infrastructure privates.

This is something you literally need at every single distributed web service stack, and instead of managing NAT server health it should be just another resource that AWS manages for you completely.

From what AWS architects tell me, we are not alone with this wish.

What’s your top wish from AWS this year? Come tell us over a pint or two on us in the Nordic get together!

Kankea tietojärjestelmä on taakka kaikille

Tue, 25 Aug 2015 05:30:00 GMT

Sanotaan, että tietotekniikka on tehty palvelemaan ihmistä. Usein tekniikka herättää voimakkaita tunteita, varsinkin jos se ei toimi. Miksi tietotekniikka aiheuttaa ongelmia? Taustalla voi olla inhimillisiä virheitä, huonoa suunnittelua tai vanhentunutta teknologiaa. Uskon, että suurin osa meistä ei ole edes kiinnostunut vian syystä. Tärkeintä on, että tekniikka toimii siinä tarkoituksessa mihin sitä on käyttämässä. Tuoko nopea tekninen kehitys vain uusia haasteita?

Olen aina suhtautunut tietotekniikkaan ja uusiin innovaatioihin positiivisesti. Mahdollisia ongelmia olen pyrkinyt ymmärtämään perehtymällä niiden syihin: tekniset ongelmat ovat yleisiä ja niistä on mahdollista myös oppia. Viimeisen parin vuoden aikana olen kuitenkin huomannut, että suhtautumiseni tekniikkaan on muuttunut. Uusin käyttöjärjestelmäpäivitys ei ollutkaan muutos parempaan. Kaipaan puhelimia, joilla pystyi vain soittamaan ja vastaamaan. Kärsivällisyyteni hitaita tietojärjestelmiä kohtaan alkaa olla lopussa.

Kun mikään kanava ei toimi

Verkkokauppa on tuonut kaupan alalle uusia mahdollisuuksia ja yritykset panostavat monikanavaisiin ratkaisuihin. Mitä tapahtuu, kun mikään kanava ei toimi?

Jokin aika sitten olin ostamassa perheemme esikoiselle puhelinliittymää ja samalla tarkoitus oli hankkia toinen liittymä tablettia varten. Olin netissä jo tutustunut eri vaihtoehtoihin ja päätin perjantain kauppamatkan yhteydessä poiketa erään operaattorin myyntipisteellä. Ajattelin, että tilaus hoituu nopeasti. Myyntipisteellä oli kaksi myyjää, jotka molemmat aloittivat tilausten tekemisen. Tehokasta työskentelyä, joten alku näytti lupaavalta.

Tilaukset oli kirjattu järjestelmään muutamassa minuutissa. Sitten tietotekniikka astui kuvaan. Tilaus ei lähtenytkään eteenpäin. Aluksi myyjät luulivat tehneensä itse virheen, joten tilauksen tekeminen aloitettiin alusta. Homma töksähti samaan pisteeseen. Syyksi selvisi jokin häiriö tietojärjestelmässä. Kiusallinen hiljaisuus. Toinen myyjistä yritti soittaa tukipalvelunumeroon, joka oli myös ruuhkautunut ja palveluun oli yli 20 minuutin jono. Aloin tuolloin jo vilkuilla kelloa. Toinen myyjistä yritti pelastaa tilannetta tiedustelemalla tarvetta edulliselle tabletille. Ei kiitos.

Viimeinen oljenkorsi oli yrittää tilausta verkkokaupan kautta. En tosin tätä kautta olisi saanut liittymäkorttia heti mukaan, mutta tilauksella ei ollut kiire. Myyjä kirjoitti tiedot, mutta homma kaatui jälleen viimeiseen vaiheeseen.

Myyntitapahtuman aikana kysyin miten yleisiä nämä häiriöt ovat. Molemmat myyjät huokaisivat ja totesivat, että viime aikoina ongelmia on ollut usein – varsinkin vilkkaina kauppapäivinä. Ikävä kuulla, että tilausjärjestelmä muodostuu myynnin pullonkaulaksi.

Kiitin myyjiä hyvästä yrityksestä. Muutaman päivän jälkeen kokeilin tilauksen tekemistä verkkokaupan kautta. Tilausprosessin lopuksi sain viestin: “Palvelussa tapahtui tekninen virhe. Yritä hetken kuluttua uudelleen”. Päätin tilata liittymät toiselta operaattorilta.

Mitä tästä opimme?

Joskus tietotekniikkaan liittyvät ongelmat tekevät mahdottomaksi palvella asiakkaita. Mitä yrittäjä tai liiketoimintapäättäjä voi tehdä, ettei vastaavanlaisia ongelmia tapahdu omassa yrityksessä?

Neuvoja on varmasti useita. Kertomassani tapauksessa tilausjärjestelmä kannattaa muuttaa sellaiseksi, että tekninen vika loppuvaiheessa ei estä tilausta. Palvelut on mahdollista rakentaa niin, että ne korjaavat itsensä vikatilanteissa ja pystyvät sen jälkeen jatkamaan keskeytyneiden tilausten käsittelyä. Tämän avulla minä ja todennäköisesti muutama muukin henkilö olisimme kyseisen operaattorin uusia asiakkaita. Olen melko varma, että myös yrityksen työntekijät olisivat tyytyväisempiä käyttämäänsä järjestelmään.

Ohjelmistokehityksen ja pilvipalveluiden asiantuntijayrityksen näkökulmasta suosittelemme panostamaan laadukkaaseen suunnitteluun ja toteutukseen. Liiketoimintavaatimusten muuttuessa myös it-ympäristöjen on kyettävä muuttumaan. Ketteryys ja skaalautuvuus ovat nykyaikaisen it-ympäristön avainsanoja.

Tekniikka kehittyy valtavaa vauhtia ja se luo uusia mahdollisuuksia myös muuttaa toimintatapoja. Työni puolesta olen viimeisen vuoden aikana päässyt tapaamaan useita it- ja liiketoimintapäättäjiä, jotka haluavat vastata muuttuvan maailman tarpeisiin mm. pilven avulla. Pilvi tarjoaa yrityksille joustavuutta ja mahdollisuuden kehittää uusia liiketoimintamalleja sekä päivittää kankeita järjestelmiä paremmin toimiviksi.

Nopea tekninen kehitys tuo muutoksia meidän kaikkien elämään. Välillä ne turhauttavat, kuten minua uudet käyttöjärjestelmät tai epävarmasti toimivat puhelimet. Moni muutos on kuitenkin positiviinen. Webscalella lähestymistapamme tekniikkaan ja sovelluskehitykseen on hyvin käytönnönläheinen. Teknologiat ja prosessit ovat meille ensisijaisesti työkaluja asetettujen maalien saavuttamiseksi. Tämän vuoksi suosimme kypsiä ja luotettavia teknologioita sekä maailmalla hyviksi havaittuja menetelmiä ja käytäntöjä.

Mobile vulnerabilities threaten your cloud infrastructure

Thu, 06 Aug 2015 12:00:00 GMT

What if an attacker gained system level access to your mobile phone? What could they achieve with that data? In light of recent new Android vulnerabilities, this is no longer a purely theoretical exercise.

Stagefright was published widely on 27 July (by Zimperium ), and there are implications (by Trend Micro & comment section) that it has been out in the wild for considerably longer. Among its potential attacks are reading / writing files with same privileges OS mediaserver has.

It is fair to assume that over time a commonly available exploit will be made available that allows either system level read access or screen scraping, both enough to gather critical information for further, more profitable attacks.

Trend Micro claims they know of no publicly available attacks so far.

Why should this concern you?

Root access to your mobile phone means your following identity resources are likely to be compromised:

With these resources, the damage potential is staggering:

Given the damage potential, we recommend immediate action to mitigate the attack potential, and to reduce the damage in case your credentials are already lost.

Mitigate the MMS attack vector.

Reduce damage potential of next stage attacks.

Since the published vulnerability is recent, it is unlikely that you or your administrators have been targeted unless you and your company are in a high impact, high visibility position. Taking the above steps without resetting your phone should be enough. However, it is probably worth considering these issues organization wide and ensuring that nobody is no longer vulnerable to the attack.

While this specific vulnerability will be patched within few weeks or months on all up to date devices, it is certain that similar attacks will be discovered given the current pace of new feature additions to mobile operating systems.

More secure processes to avoid this in the future.

Sources:

Uusi Webscale-päämaja Helsingin keskustaan

Tue, 28 Apr 2015 05:00:00 GMT

Helsingin ydinkeskustassa, rautatieaseman välittömässä läheisyydessä osoitteessa Mikonkatu 15 B sijaitsee uusi Webscale-päämaja.

Hienojen näkymien lisäksi yhdeksännen kerroksen toimistostamme on erinomaiset yhteydet tärkeimmille asiakkaillemme ja myös mukavat puitteet tavata heitä sekä muita Webscalelle tärkeitä henkilöitä.

Asiakkaiden ja yhteistyökumppanien lisäksi tärkeiden ihmisten joukko sisältää tietysti myös työntekijämme. Heille uusi toimistomme tarjoaa lyhyen työmatkan ja toimivat työtilat, jotka työajan ulkopuolella palvelevat olohuoneena keskellä kaupunkia.

Etsimme parhaillaan lisää hyviä tyyppejä joukkoomme. Tarjoamamme työ on siistiä sisätyötä hyvässä seurassa ja parhailla teknologioilla. Helppoa ja turvallisen tasaista se ei sen sijaan ole. Hyvin tehdystä työstä maksamme tietysti reilun korvauksen ja myös osakkuus kasvavassa yrityksessämme on mahdollinen.

Jos siis tunnet tervettä vetoa pilvipalveluihin, nautit haastavista tehtävistä ja viihdyt asiakasrajapinnassa, niin ota Jukkaan yhteyttä (+358 50 301 1297) ja poikkea kahville/teelle keskustelemaan kanssamme.

Are you sure you own your data?

Mon, 30 Mar 2015 09:30:00 GMT

Whoever owns the keys to your data, owns your data. In many cases that is not you.

When you took up AWS for the first time, it felt confounding for all of its options. You picked that single feature you needed and realized how powerful it was. Soon, you built your whole development environment on it, and once your managers and/or founders noticed how far you had gotten by yourself, you ended up having a production system running on it as well.

Consulting our customers, we see more often than not that AWS environment is set up organically. It has been used to solve simple issues, and over time more and more features have been included from the AWS offering. While this is exactly what AWS is good for, and its cost model supports incremental steps perfectly, it is often dangerous from a security point of view.

The most common access-related threats we see are:

Security gone wrong

A cautionary tale of AWS security gone wrong is Codespaces.com, a SaaS cloud storage provider. I should say was , because after their AWS account was breached, they went out of business shortly afterwards, unable to recover their customer data.

What happened to Codespaces was that an attacker gained access to their AWS root account, set up a denial of service and demanded payment to return the assets to Codespaces. Codespaces staff tried taking control of their account, but failed. Seeing this, the attacker proceeded to wipe everything. All the data, all the servers.

Codespaces posted a letter of apology shortly afterwards, informing their customers they could not recover the data, and not being able to pay their customers reparations, the company shut down.

Privilege levels you should identify:

First step in securing your system is to reduce the user authorizations bare minimum that they need to perform their tasks. A good starting point for this is classifying your AWS privileges into different severity levels by purpose and storage method.

managed policies

Convenience over security

Recently I have come across several instances of root keys being managed by external company, most usually your cloud consulting partner or development partner. There is absolutely no reason to do this. Every operation that you can do with root account, you can authorized IAM user account to do as well, including viewing billing information.

The main reason you need to hold on to the root account keys is that only the root user can be absolutely certain that your CloudTrail logs have not been tampered with. It is also the only user that can not be deleted or changed at whim of any Administrator-privileged user.

Auditing

For many companies the effort to educate their admins on the finer points of AWS security may be too much, since everyone is overloaded with work. In this case I recommend buying the expertise from outside – find your local AWS consulting partner and ask for a quote on security audit of your environments. At the very least, require that they check for the issues detailed above.

Conclusions

More widespread the AWS usage is in your organization, more important it is that your operational security is up to task. Strict privilege management prevents unintended side effects and mitigates damage potential in the case of your keys being compromised.

Key management should always be ultimately in your own control. Regardless of who you have running your AWS operations, the account root keys should be locked away behind the top responsible tech officer, with CloudTrail set to follow every action.

With the root access in your own sole control, you can still give your contractors and new employees admin level access without compromising your audit trail and ultimate control over your own operations.

Security requires continuous improvement, tuning and reviewing to stay up to speed in an environment where setting up a massive customer facing service could take less than 15 minutes to create. Well-thought privilege restriction and periodic auditing of your whole system are the practices every production system owner should have in place.

Otatko kaiken hyödyn irti automatisoinnista? – DevOps ja AWS

Mon, 02 Mar 2015 07:00:00 GMT

Ohjelmistokehitykseen kohdistuu kiihtyvällä tahdilla vaatimuksia liittyen aikatauluun, kustannuksiin, laatuun ja toiminnallisuuksiin. Perinteiset menetelmät ja työkalut eivät pysy tässä tahdissa mukana.

DevOps pyrkii vastaamaan näihin vaatimuksiin parantamalla ohjelmistokehityksestä ja järjestelmäylläpidosta vastaavien tiimien välistä yhteistyötä sekä korostamalla automaation merkitystä kaikissa ohjelmistokehitysprosessin vaiheissa.

Automatisoinnin tueksi on syntynyt lukuisia työkaluja, jotka yleensä tarjoavat ratkaisun tietyn prosessin vaiheen tarpeisiin. Yhtä, joka tilanteeseen ja kaikille sopivaa, työkalua on mahdoton luoda, jonka vuoksi vaihtoehtoja ja valinnanvaraa riittää. Pelkästään konfiguraation hallintaan on tarjolla jo paikkansa vakiinnuttaneet Puppet ja Chef, sekä näille alati kasvava joukko tuoreempia haastajia.

Mitä AWS tarjoaa DevOps-kentälle?

Amazon Web Services on muiden pilvipalvelujen tarjoajien ohella ollut jo pitkään mahdollistamassa ja vauhdittamassa DevOpsin yleistymistä. AWS:n DevOpsia tukemaan luotujen palvelujen lista on kattava ja heijastaa hyvin sitä tosiasiaa, että organisaatiot ja niiden ohjelmistokehitysprojektit ovat erilaisia.

CloudFormation, OpsWorks, Elastic BeanStalk ja CodeDeploy tarjoavat kaikki toisiinsa yhdistettävissä olevia ratkaisuja organisaatioiden ohjelmistokehityksen tarpeisiin. Ne eivät yritä pakottaa tiettyyn toimintatapaan tai prosessiin, vaan tukevat organisaatioiden työtä kuten DevOpsissa järjestelmäylläpito tukee kehittäjien työtä parhaan lopputuloksen saavuttamiseksi.

DevOps on liikkuva maali

Menetelmistä ja työkaluista ei ole hyötyä, jos niitä ei osata tai haluta hyödyntää. Hyvä kehittäjä pyrkii koko ajan löytämään uusia tapoja tehdä asioita tehokkaammin. Osaaminen pysyy ajan tasalla sekä tekemällä että kouluttautumalla.

Pilvipalveluiden asiantuntijana ja ohjelmistokehitystalona Webscale on perustamisestaan lähtien ollut vahvasti mukana DevOps-kentässä. Panostamme aidosti ammattilaistemme osaamiseen ja pidämme huolta siitä, että tunnemme syvällisesti myös AWS:n DevOps-työkalut. Erinomainen osoitus tästä on se, että suoritimme ensimmäisten joukossa maailmassa uuden AWS Certified DevOps Engineer Professional -sertifikaatin, joka testaa nimenomaan DevOps-osaamista AWS:n pilviympäristössä.

AWS re:Invent Las Vegasissa

Fri, 21 Nov 2014 12:00:00 GMT

Osallistuimme kolmatta kertaa järjestettyyn AWS re:Invent -konferenssiin Las Vegasissa. Viidelle päivälle jakautunut tapahtuma sisälsi monipuolisen kattauksen esityksiä, koulutuksia ja iltaohjelmaa, joiden välissä oli vielä mahdollisuus käydä suorittamassa sertifikaatteja ja harjoituksia.

re:Invent on perinteisesti ollut AWS:n vuoden tärkein tapahtuma, jossa julkistetaan uudet tuotteet ja palvelut. Odotetusti keskiviikon ja torstain pääpuheenvuorot sisälsivät hengästyttävän määrän uusia julkistuksia. Osa näistä oli erittäin odotettuja, kuten AWS EC2 Container Service , joka helpottaa merkittävästi Docker-klustereiden ajamista Amazonin pilviympäristössä. Tämä varmasti edistää jo nyt hyvin etenevää Dockerin maailman valloitusta.

Hieman yllättävämpi julkistus sen sijaan oli AWS Lambda , jonka tilaton tapahtumiin perustuva ohjelmointimalli mahdollistaa toiminnallisuuksien tarjoamisen ilman yhtäkään omaa palvelinta. Kehittäjän vastuulle jää kirjoittaa sovelluslogiikka, joka reagoi pilviympäristön tuottamiin tapahtumiin samalla kun AWS vastaa sovelluksen ajamisesta aina halutulla suoritusteholla. Sovelluskehitys Lambdan avulla on entistä ketterämpää ja tulee varmasti muuttamaan tapaa, jolla sovelluksia jatkossa pilveen rakennetaan.

Uudeksi Amazon RDS -tietokantamoottoriksi julkistettiin Amazon Aurora . Se on lineaarisesti skaalautuva MySQL-yhteensopiva relaatiotietokanta, joka lupaa parhaimpien kaupallisten tietokantojen suorituskyvyn ja vikasietoisuuden yhdistettynä open source -tietokantojen yksinkertaisuuteen ja kustannustehokkuuten.

Sovelluskehittäjille saapui tänä vuonna joulu etuajassa, sillä heidän työnsä tueksi Amazon julkaisi peräti kolme uutta palvelua. CodeCommit, CodeDeploy, CodePipeline tarjoavat ratkaisuja versionhallintaan, automatisoituun sovellusten julkaisuun sekä sovellusympäristöjen ylläpitoon ja hallintaan.

Muita uusia palveluita olivat kryptausavainten hallintaan tarkoitettu AWS Key Management Service , pilviympäristön konfiguraation hallintaan ja auditointiin keskittyvä AWS Config sekä AWS Service Catalog tuoteportfolioiden ylläpitoon.

Kaiken kaikkiaan uudet palvelut ovat erinomainen lisä Amazonin jo ennestään laajaan valikoimaan.

Löysimme myös hetken ylimääräistä aikaa täyteen pakatun ohjelman keskeltä ja kävimme suorittamassa SysOps Administrator -sertifikaatit jo aiemmin hankittujen Solutions Architect -sertifikaattien seuraksi.

re:Invent oli kaikin puolin mahtava kokemus. Reissusta tarttui mukaan aimo annos uutta AWS-tietoa ja erinomaisia kontakteja. Tulemme ehdottomasti osallistumaan myös ensi vuoden konferenssiin koko yrityksen voimin. Tämän kokemuksen jälkeen on mukava palata takaisin sorvin ääreen ja päästä hyödyntämään uusia oppeja ja ratkaisuja yhdessä asiakkaidemme kanssa.

A full year in cloud business

Fri, 12 Sep 2014 10:00:00 GMT

This autumn Webscale reached an important milestone as it was one year ago we started the company. And what a year it has been! During our first twelve months we went through a crash course in entrepreneurship and IT sales, and of course refined our AWS expertise even further.

Overall, we are very pleased with the choices we made and how we have been able to push towards our goals. Especially our decision to put all in on Amazon Web Services has turned out to be the right one. In the past year, several leading companies put their trust in our new company to help them develop their cloud services. Being able to work closely with our clients and providing solutions that utilize the full potential of the cloud is really the best reward for all the hard work and investment we have put in.

Future looks bright for Webscale as there is growing interest in our services. We are committed to answer to that demand and therefore we are now looking for talented people to join our ranks. If you are experienced in the software business and already have strong AWS knowledge, you might be just the right person for the job. We offer partnership programme and challenging role with real opportunities to influence our growing company. Send your CV to rekry@webscale.fi . For more information about working at Webscale, call Jukka +358 50 301 1297.

Webscale becomes AWS Consulting Partner

Wed, 03 Sep 2014 09:15:00 GMT

Webscale became Amazon Web Services Consulting Partner on August 6 2014.

AWS has been the strategic technology choice from day 1 of our company. During our first year of operations, we have been able to provide our customers with reliable services more rapidly than before, thanks to AWS’s elastic infrastructure. We, as developers, see immense productivity gains working with high quality API-based, on-demand infrastructure as opposed to on-premise data centers.

Every engineer in Webscale has been certified with at least the first AWS Solution Architect certification level. We also guarantee that every developer in the company is trained and certified to have strong understanding of AWS.

Our enterprise customers have already seen major benefits from migrating to AWS-based environments. With this partnership, we are able to provide you with even better service, resulting in cost savings and agility to execute you vision.

Growing the gap: IaaS market three years in a row

Tue, 05 Aug 2014 07:00:00 GMT

Gartner recently released their 2014 IaaS Magic Quadrant [ 1 ] report, covering 20 major players in the Infrastructure-as-a-Service market. Amazon Web Services is leading the IaaS market by a massive margin, as it has been since 2012 when the first such report was published.

What is noteworthy – and not obvious by looking at just 2014 report – is that AWS is outpacing its competitors, growing the gap each year even though the market as a whole has evolved significantly during this time.

Other major changes in the market this year were the entry of Google into the IaaS market with their Google Compute Engine, and the grand leap to Leader quadrant by Microsoft Azure offering.

Gartner only included cloud compute IaaS in their Magic Quadrant, not including storage, cloud brokerage or hardware and software providers intended for building cloud infrastructure. Heavy emphasis was in self-service and automation in a standardized environment – the primary context being enterprises with the desire to have a cloud “data center”. Evaluation focused on the common requirements for these customers.

The report does a good apples to apples comparison, which is rare in this market: Certain providers are explicitly called out as cloudwashing their dedicated managed services into “IaaS”.

Evaluated companies in general could promise monthly compute availability SLAs of 99.95% and higher, which is typically higher than availability SLAs for managed hosting. All the companies are believed to be financially stable, with business plans that are adequately funded. Customers should not need to worry about them going out of business.

The API supported by each provider is also mentioned – the Amazon Web Services (AWS), OpenStack and vCloud being the most common. It is essential to understand that even though the API might be identical between providers, there is likely to be no interoperability of services. OpenStack implementation especially differs from provider to another, rendering the hyped lack of vendor lock-in practically false.

Google entered the IaaS market only recently with their general availability launch in December 2013. Although Google entered the market very late in the game, Gartner considers that their ability productize existing capability instead of building from scratch will enable them to move significantly faster than most competition. Productizing existing capacity also means that their cost of service is very low. The effect of GCE pricing has already pushed Amazon into lowering their entry-tier compute pricing. As of now, AWS T2-tier is the most inexpensive option.

Mirosoft Azure business was previously strictly PaaS, but with the launch of Infrastructure Services, Microsoft entered the IaaS market in April 2013. It is already second in IaaS market share, far ahead of the smaller competitors – even if it is still far from Amazon

As downsides to Azure IaaS offering, Gartner sees the lack of support for complex network topologies and Microsoft centricity, as shown by lack of enterprise Linux options. Azure Infrastructure Services appeals primarily to .NET developers, even though running heterogenous loads is possible.

The growing gap between AWS offerings and other providers, together with the fact that the developer ecosystem for AWS is superb, strengthens our belief that Amazon Web Services should be the standard part of every highly productive developers choice of tools. Whether we are migrating a customers enterprise system off premises, or creating their brand new global flagship service, AWS provides us as developers with a scalable, inexpensive and reliable service without limiting our freedom of building just the right kind of solution.

[1] Gartner 2014 IaaS Magic Quadrant released

Interested in how your organization could be more agile and save in costs with AWS? Contact us at info@webscale.fi

Know your cloud storage: Integrity, privacy and SLAs

Thu, 24 Apr 2014 09:05:00 GMT

The cloud storage services have been around for years, and the offerings have been improving rapidly. There are Google ~~Docs~~ Drive, Microsoft ~~SkyDrive~~ OneDrive, Dropbox, Amazon S3, Azure (Blob) Storage, Google Cloud Storage, iCloud, et cetera.

What I see ever more often is a lack of understanding of what each of the storage services are meant for. This is made more confusing by the tendency of storage service providers to wrap their services with tools closely resembling the operating systems file explorer view, even if internally the storage is nothing like plain disk storage.

Last week myce.com published their findings on how OneDrive alters the stored files , which rightly caused many to reconsider their usage of the service for sensitive data or corporate information. Integrity of the files means that you expect to get out files in identical condition as they were when you put them in. OneDrive fails at this, and what is worse, does so while making it superficially look like nothing has changed. The actual changed content was some sort of metadata about the files.

End user services

From the list above, I would classify OneDrive, Dropbox, Google Drive and iCloud as built for the end users, and therefore intended not to require any prior knowledge of the internal functioning of the service.

OneDrive and iCloud are built in to specific desktop operating systems and mobile platforms, to the degree that it actually takes more user effort to disable them than to use them. Dropbox needs to be separately installed, but similarly ‘just works’ as automatically cloud syncing file system path.

Drive differs from the rest in that it is intended primarily as online office document creation service, and only provides the storage capability as a side effect of that function. Regardless, many use it for lightweight cloud storage, myself included. The tools and the service experience are regardless built for layman use, and should be considered from that viewpoint.

The OneDrive incident only shows that Microsoft keeps true to their vision of making the end user experience as easy as possible, regardless of how a small portion of technically inclined users might feel about their service effectively breaking the integrity of the stored files. Microsoft has a long history of altering user data starting with MediaPlayer & MP3 metadata. And can you blame them for forcing their vision for their ecosystem, when Apple would do the same thing on theirs? Only if you made the assumption that you should use the same service to backup your corporate files that teenagers are using for sharing their selfies.

I came across another breach of implied service level with Dropbox shared directories. I purchased my old work laptop when leaving an employer, so I ended up having a previously shared Dropbox directory with monthly sales summary documents in them. My access rights to those files had been revoked, but they still existed on my local hard drive, and Dropbox still kept trying to sync them with online versions: Actual file contents were not updated, but I still got the metadata updates on when files had been changed. My personal assumption had been that once you revoke someones access to files, they will get nothing related to those files. Turns out I was wrong.

Infrastructure services

Amazon S3, Azure Storage and Google Cloud Storage are entirely different services from the end user services. While at core their function is to act as storage services like previous ones do, they are in a stark contrast with end user services by providing very versatile access controls while providing only crude graphical tools for file operations. Access to and manipulation of the files are intended to be done through APIs, and effective use of the services for heavy users requires somewhat thorough understanding of the storage architecture.

The most significant difference comes from having a service level agreement (or SLA) for these infrastructure services. Amazon S3 SLA promises their users 99,9% Monthly Uptime Percentage, with up to 25% of monthly costs given as service credits for failing to live up to that promise. In addition, their product details describe the service having been designed for 99.999999999% durability and 99.99% availability of objects over a given year, and to sustain the concurrent loss of data in two facilities.

Azure Storage SLA and Google Cloud Storage SLA provide similar promises.

Building blocks

You should also be aware that some of the end user services are actually built on those infrastructure services. Most famous example is Dropbox, which is often used as a good example of how to use Amazon S3 innovatively as the storage backend. Dropbox only stores user information and metadata about the files on their own servers, and does all the heavy lifting with S3. Comparing their billing ($9.99/month for Dropbox Pro, 100 Gb) with S3’s ($0.03/month/Gb * 100 Gb = $3/month) they get a decent cut for providing good user experience on top of other providers infrastructure.