Webscale Oy | Blogi

Miten pitää pilviympäristöt turvallisina ilman, että kehitys hidastuu?

Wed, 13 May 2026 08:51:58 GMT

Pilviympäristöt kasvavat nopeasti, mutta tietoturva ei pysy aina mukana. Kehitystiimit julkaisevat vauhdilla uutta, samalla kun teknologiajohtajat yrittävät hallita kasvavaa riskitasoa, monimutkaisuutta ja kustannuksia.

Monessa yrityksessä tähän vastataan lisäämällä uusia tietoturvatyökaluja vanhojen rinnalle. Lopputuloksena on kuitenkin usein hajanaisia näkymiä, päällekkäistä työtä ja kasvava määrä hälytyksiä, joista on vaikea tunnistaa aidosti kriittiset riskit.

Cloud-Native Application Protection Platform eli CNAPP tarjoaa tähän ratkaisun. Se tuo tietoturvan osaksi pilvinatiivien sovellusten elinkaarta ilman, että nopeus tai ketteryys kärsii.

Mitä CNAPP tarkoittaa

CNAPP yhdistää useita tietoturvatoimintoja yhteen alustaan. Se kattaa sovellusten, infrastruktuurin ja identiteettien turvallisuuden kehityksestä tuotantoon. Tämä tarkoittaa, että riskit voidaan havaita jo varhaisessa vaiheessa ja korjata ennen kuin ne vaikuttavat liiketoimintaan.

Teknologiajohtajalle tämä näkyy parempana riskienhallintana ja ennakoitavuutena. DevOps-tiimeille se tarkoittaa työkaluja, jotka integroituvat suoraan olemassa oleviin työnkulkuihin.

Miksi CNAPP on strategisesti tärkeä

Pilviympäristöjen monimutkaisuus kasvaa jatkuvasti. Mikroarkkitehtuurit, kontit, AI ja monipilviympäristöt lisäävät hyökkäyspintaa. Perinteiset työkalut eivät enää riitä tarjoamaan kokonaiskuvaa.

CNAPP tuo yhtenäisen näkyvyyden koko ympäristöön. Organisaatio näkee nopeammin, mitkä riskit vaativat toimenpiteitä ja mihin turvallisuusinvestoinnit kannattaa kohdistaa. Samalla DevOps-tiimit saavat selkeän näkymän siihen, missä riskit ovat ja miten ne voidaan korjata tehokkaasti.

Tietoturvan huomioiminen kehityksessä varhaisessa vaiheessa on keskeinen osa modernia toimintamallia. CNAPP integroi turvallisuuteen liittyvät tarkistukset osaksi CI/CD-putkea, jolloin ongelmat voidaan havaita ja korjata ennen tuotantoon siirtymistä. Tämä vähentää tuotantoon päätyviä virheitä ja pienentää korjauskustannuksia.

Liiketoimintahyödyt teknologiajohtajalle

CNAPP ei ole pelkkä tietoturvatyökalu, vaan tapa hallita pilviympäristöjen kasvavaa monimutkaisuutta. Kun organisaatio saa keskitetyn näkymän sovelluksiin, infrastruktuuriin ja identiteetteihin, riskit voidaan tunnistaa nopeammin ja niihin voidaan reagoida ennen kuin ne vaikuttavat liiketoimintaan.

Samalla vähenee tarve useille erilaisille työkaluille ja manuaaliselle työlle. Tämä helpottaa ympäristön hallintaa, vähentää operatiivista kuormaa ja auttaa pitämään kustannukset paremmin hallinnassa.

CNAPP tukee myös vaatimustenmukaisuutta automatisoimalla tarkastuksia ja raportointia. Erityisesti säännellyillä toimialoilla tämä voi vähentää merkittävästi auditointeihin käytettävää aikaa.

Hyödyt DevOps-tiimeille

DevOps-tiimeille CNAPP tarkoittaa vähemmän manuaalista työtä ja vähemmän yllätyksiä tuotannossa. Riskit tunnistetaan ajoissa ja korjaukset voidaan automatisoida.

Integraatiot kehitystyökaluihin mahdollistavat sen, että tietoturva ei ole erillinen vaihe vaan osa normaalia työnkulkua. Tämä parantaa kehittäjäkokemusta ja nopeuttaa julkaisusyklejä.

Kontekstuaalinen analyysi auttaa keskittymään olennaiseen. Kaikki haavoittuvuudet eivät ole yhtä kriittisiä, ja CNAPP auttaa priorisoimaan ne, joilla on todellinen vaikutus.

CNAPP käytännössä

Orca Security on CNAPP-ratkaisu, joka auttaa organisaatioita hallitsemaan pilviympäristöjen riskejä keskitetysti. Ratkaisu kokoaa yhteen tiedon infrastruktuurista, identiteeteistä, sovelluksista ja datasta, jolloin kokonaiskuva ympäristön turvallisuudesta on helpompi muodostaa.

Orcan agentiton lähestymistapa mahdollistaa ympäristön kartoittamisen ilman raskaita asennuksia tai erillisiä agentteja. Tämä vähentää ylläpitotyötä ja nopeuttaa käyttöönottoa erityisesti laajoissa pilviympäristöissä. DevOps-tiimeille tämä tarkoittaa vähemmän ylimääräistä ylläpitoa ja helpompaa käyttöönottoa osaksi olemassa olevia ympäristöjä.

Ratkaisu auttaa myös priorisoimaan riskit liiketoimintavaikutuksen perusteella. Sen sijaan, että tiimit joutuisivat käymään läpi suuren määrän yksittäisiä havaintoja, huomio voidaan kohdistaa niihin uhkiin, joilla on todellinen vaikutus ympäristön turvallisuuteen ja liiketoiminnan jatkuvuuteen.

Lisäksi automatisoitu vaatimustenmukaisuuden seuranta helpottaa auditointeja ja raportointia. Tämä vähentää manuaalista työtä ja auttaa pitämään ympäristöt paremmin hallinnassa myös säädellyillä toimialoilla.

Webscale toimii Orca Securityn suomalaisena kumppanina ja auttaa organisaatioita arvioimaan, miten CNAPP-ratkaisut voidaan ottaa käyttöön osana olemassa olevia pilviympäristöjä.

Kun turvallisuus integroidaan osaksi kehitystä ja pilviympäristöjen hallintaa, organisaatiot voivat kehittää ja julkaista palveluita nopeammin ilman, että riskien hallinta jää jälkeen.

Teemu Peräkylä
Sales Executive, Cloud Services

Asiakas edellä – Teemu Peräkylä osaksi Webscalea

Wed, 22 Apr 2026 20:55:04 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:00 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:00 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:00 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:00 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:00 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:00 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

Viisi vinkkiä pilvikulujen hallintaan

Wed, 23 Apr 2025 08:24:00 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.

Ensituntuma SST-työkaluun

Thu, 17 Apr 2025 06:01:00 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:00 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:00 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ää!

Kysy konsultilta: Mikä on Amazon Cognito?

Wed, 19 Feb 2025 07:16:00 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:00 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:00 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:00 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:00 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:00 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:00 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:00 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:00 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:00 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:00 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.

Tero Kauhanen
Toimitusjohtaja

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

Fri, 04 Oct 2024 06:25:00 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:00 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: Terraform vs. CDK

Thu, 23 May 2024 05:44:00 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: 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:00 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:00 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:00 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:00 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:00 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:00 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:00 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:00 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:00 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:00 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:00 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

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

Fri, 26 Jan 2024 05:59:00 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:00 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

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

Wed, 03 Jan 2024 08:38:00 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

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

Wed, 13 Dec 2023 06:15:00 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:00 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:00 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:00 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

Tue, 21 Nov 2023 20:08:00 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:00 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:00 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: Miten tietoturva tuodaan pilveen?

Fri, 20 Oct 2023 06:41:00 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

Kysy konsultilta: Miksi AWS:lla on eri regioonia?

Fri, 13 Oct 2023 09:40:00 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.

Ville Välimäki
Principal Consultant

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

Tue, 03 Oct 2023 10:12:00 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.

Ville Välimäki
Senior Consultant

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

Thu, 28 Sep 2023 05:25:00 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:00 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

Kysy konsultilta: Miten valita oikea tietokanta?

Wed, 06 Sep 2023 10:37:00 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:00 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

Asiakkaamme vastasivat - kyselyn tulokset ovat valmiit

Wed, 07 Jun 2023 06:55:00 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

Tue, 06 Jun 2023 07:31:00 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!

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

Thu, 20 Apr 2023 09:32:00 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?

Thu, 06 Apr 2023 10:21:00 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

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

Mon, 27 Mar 2023 11:33:00 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

Webscale on nyt myös AWS Public Sector Partner

Fri, 17 Mar 2023 08:11:00 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.

Tutkimme suomalaisten keskisuurten yritysten pilvisiirtymää

Mon, 19 Dec 2022 09:59:00 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.

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ä 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: Miten DevOps ja ohjelmistokehitys liittyvät toisiinsa?

Wed, 23 Dec 2020 07:00: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 DevOpsin ja ohjelmistokehityksen maailmaan.

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

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ä.”

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.

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.

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

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)

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.

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.

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.

“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 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.

“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?

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.

“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/

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

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.

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.

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!

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.