Rakenna tiimeillesi täydellinen Internal Developer Platform

Entä jos vain ryhdyt tekemään? Mikä voisi mennä pieleen?

Kuten monissa muissakin projekteissa, vaikeinta on päästä alkuun – ja tehdä se oikein. Se ei kuitenkaan riitä: alusta on saatava valmiiksi ja käyttöön haasteista huolimatta.

Tässä blogikirjoituksessa vastaan seuraaviin kysymyksiin:

1. Miten alustan rakentaminen aloitetaan?

2. Miten sen arkkitehtuuri suunnitellaan?

3. Mitä haasteita kohtaat? Miten ne voidaan ratkaista?

Miten alustan rakentaminen aloitetaan

Miten alustasta sitten tehdään totta? IDP:n rakentaminen koostuu kolmesta päävaiheesta:

1. Määritä arkkitehtuuri ja ohjelmistotyökalut

Alustan luominen edellyttää muutamia keskeisiä arkkitehtuuri- ja teknologiavalintoja. Kehittäjäportaalin lisäksi useimmat alustat rakentuvat Kubernetesin ympärille, joka luo perustan eri ohjelmistokomponenttien käyttämille abstraktioille ja toimintamalleille.

2. Integroi komponentit ja lisää toiminnallisuuksia

Kun alustan ydin on paikallaan, on aika yhdistää eri komponentit kokonaisuudeksi. Integrointi on muutakin kuin lähdekoodin liittämistä build-putkiin. Siihen kuuluu myös käyttöoikeuksien hallinta ja vaatimustenmukaisuuden varmistaminen. IDP:hen on esimerkiksi usein sisällytettävä tietoturvaskannauksia ja automatisoituja laatutarkistuksia.

3. Ota kehittäjät mukaan alustalle

Oppaiden ja tutoriaalien avulla kehittäjät voivat alkaa käyttää alustaa heti, kun se on riittävän kypsä. He voivat antaa varhaista palautetta toiminnallisuuksista ja pyytää työnkulkuaan tukevia ominaisuuksia. Alusta on otettu onnistuneesti käyttöön, kun kehittäjät osallistuvat aktiivisesti sen kehittämiseen esimerkiksi luomalla mallipohjia, kirjoittamalla dokumentaatiota ja lisäämällä mukautettuja näkymiä hallintapaneeliin.

Alustan arkkitehtuurin suunnittelu

Alustan arkkitehtuurin määrittely on monimutkaista, joten olemassa olevien työkalujen ja palveluiden hyödyntäminen voi tuntua hyvältä tavalta päästä alkuun. Monissa tapauksissa se voi kuitenkin olla huono idea. Alustan ajatteleminen sellaisena kuin sen tulisi olla – täysin uutena projektina – auttaa pääsemään eroon perinnöstä ja hyödyntämään moderneja teknologioita. Miten monimutkaisuutta sitten hallitaan? Kannattaa aloittaa vankasta perustasta ja miettiä sen jälkeen, mikä kuuluu alustan ytimeen. Myös referenssitoteutukset helpottavat alkuun pääsemistä.

Cloud Native -periaatteet

Alustan perustan muodostavat sen taustalla olevat tekniset lähestymistavat ja toiminnan mahdollistavat peruskomponentit. Modernit Cloud Native -teknologiat on suunniteltu hyödyntämään pilvimallia. Ne soveltuvat erityisesti skaalautuviin järjestelmiin, joiden komponentit ovat löyhästi kytkettyjä, vikasietoisia ja turvallisia. Cloud Native -lähestymistapa IDP:iden rakentamiseen perustuu muutamaan keskeiseen periaatteeseen.

• Kubernetes. Orkestroinnin lisäksi Kubernetes määrittää, miten modernit sovellukset toimivat käytännössä: ne koostuvat ohjelmistokonteilla toteutetuista tilattomista mikropalveluista. Tämä mahdollistaa myös sovellusten helpon skaalauksen pilviympäristöissä.

• Kaikki koodina. Järjestelmän kaikki komponentit, myös taustalla oleva infrastruktuuri, määritellään koodina. Koodi on ihmisluettavaa ja versioitua, tyypillisesti versionhallintajärjestelmään tallennettuina YAML-konfiguraatiotiedostoina.

• Tietoturva kaikkialla. Alustan käyttöoikeuksia hallitaan roolipohjaisella käyttöoikeuksien hallinnalla. Käytössä on molemminpuolinen tunnistautuminen, ja kaikki data salataan siirron aikana. Tokenit ja sertifikaatit ovat lyhytkestoisia ja luodaan automaattisesti.

Ydinkomponentit

Esitellyt periaatteet ovat alustojen rakentamisen perusabstraktioita, ja niillä kaikilla on samat ydinkomponentit.

• Identiteetti ja käyttöoikeudet. Mahdollistaa käyttäjien tunnistautumisen ja pääsyn alustalle heidän rooliaan vastaavilla oikeuksilla. Ratkaisussa käytetään yleensä identiteettifederaatiota ja keskitettyä käyttöoikeuksien hallintaa.

• Infrastruktuurin provisiointi: Tähän kuuluu alustan palveluita tukevan infrastruktuurin käyttöönotto ja konfigurointi. Tyypilliseen infrastruktuuriin kuuluvat Kubernetes-klusterit, tietokannat ja verkkoresurssit.

• Versionhallintajärjestelmä. Tallentaa koodin ja seuraa muutoksia ajan mittaan säilyttämällä muutoshistorian. Git on nykyään de facto -standardi, ja sitä käytetään koodin, konfiguraatiotiedostojen ja dokumentaation hallintaan.

• Continuous Integration ja Continuous Delivery. Mahdollistaa sovelluksen buildauksen, erilaisten testien suorittamisen ja sovelluksen käyttöönoton kohdeympäristöön.

• Kehittäjäportaali. Kokoaa palvelukatalogin, ohjelmistomallit ja tekniset dokumentit yhtenäiseen näkymään. Se on yleensä dashboard, joka kertoo eri palvelujen tilan ja tarjoaa itsepalvelutoimintoja.

Viitearkkitehtuurit

Nyt kun tunnemme alustan peruskomponentit, voimme valita kuhunkin niistä sopivat ohjelmistot tai palvelut ja lisätä loput tarvittavat osat. Vaihtoehtoja on runsaasti – liikaakin. Cloud Native Computing Foundation (CNCF) ylläpitää avoimen lähdekoodin projektien ja kaupallisten tuotteiden karttaa. Karttaa voi käyttää apuna saatavilla olevien, kätevästi luokkiin järjestettyjen vaihtoehtojen kartoittamisessa. Siinä on silti satoja ratkaisuja. Alustallesi ”oikeiden” ratkaisujen valitseminen voi tuntua haastavalta.

Cloud Native Computing Foundation (CNCF) on aloite, joka edistää skaalautuvien sovellusten pilvessä ajamisen mahdollistavien modernien teknologioiden käyttöönottoa. Näitä ovat esimerkiksi ohjelmistokontit, mikropalvelut ja deklaratiiviset ohjelmointirajapinnat. CNCF tukee myös avoimeen lähdekoodiin ja yhteisöihin perustuvien projektien ekosysteemiä. Se ylläpitää erityisesti näiden projektien karttaa ja määrittelee mittareita niiden kypsyyden arviointiin.

Alustat kannattaa räätälöidä jokaisen organisaation tarpeisiin, mutta onko olemassa ”malleja”, joiden pohjalta niitä voi rakentaa? Cloud Native Operational Excellence (CNOE) pyrkii tarjoamaan viitearkkitehtuurin kokoamalla työkaluketjuja ja parhaita käytäntöjä IDP:n rakentamiseen. CNOE painottaa avoimen lähdekoodin ratkaisuja ja tähtää IDP:ihin, jotka voidaan toteuttaa eri pilvipalveluntarjoajien päälle. CNOE:n teknologiset valinnat ovat seuraavat:

• Keycloak identiteetin- ja pääsynhallintaan.

• External Secrets Operator kolmannen osapuolen vaultien ja secret managerien integrointiin.

• Crossplane ja Terraform infrastruktuuri koodina -toteutukseen.

• Argo Workflows ja Tekton Continuous Integrationiin.

• Argo CD ja Flux Continuous Deliveryyn.

• Backstage kehittäjäportaaliksi.

Cloud Native Operational Excellence (CNOE)

Cloud Native Operational Excellence (CNOE) on avoimen lähdekoodin aloite sisäisten kehittäjäalustojen (IDP) rakentamiseen. Sitä vetävät johtavat yritykset, kuten Adobe, Amazon Web Services, Autodesk, Salesforce ja Twilio. CNOE ei ole valmis alustaratkaisu, vaan pyrkimys jakaa kehittäjätyökaluja ja toimintamalleja, joita organisaatiot voivat hyödyntää IDP:iden luomisessa. Yhteisönä CNOE kehittää myös työkaluja ja viitetoteutuksia, jotka tukevat eri pilvipalveluntarjoajia.

Haasteet, joita kohtaat

Hyödyistä huolimatta tarvitset apua alustan rakentamisessa.

Monimutkaisuuden hallinta

Alustan kehittäminen on haastavaa. Jotta monet komponentit toimivat tarkoitetulla tavalla, ne on integroitava huolellisesti. Integraatio perustuu usein versionhallinnassa oleviin konfiguraatiotiedostoihin. Lähestymistapa on tehokas, mutta myös hieman hankala. Tiedostot eivät ole erityisen helppolukuisia, ja ne voivat vaatia esikäsittelyä erikoistyökaluilla. 

Yksi tapa ratkaista tämä ongelma on laajentaa dashboardin kautta käytettävissä olevia alustan itsepalvelutoimintoja. Tällöin kehittäjät voivat luoda resursseja eivätkä vain tarkastella niitä käyttäjäystävällisessä ja tutussa verkkokäyttöliittymässä.

Vapauden ja hallinnan tasapainottaminen

Kehittäjät voivat kokea alustan uhkana: rakenteena, joka rajoittaa heidän vapauttaan ja häiritsee työnkulkua. Näin käy yleensä silloin, kun alustasta puuttuu odotettuja ominaisuuksia. 

Tällaisissa tilanteissa kehittäjät alkavat etsiä tapoja kiertää alusta ja päätyvät lopulta rakentamaan oman ratkaisunsa. Siksi kehittäjät on otettava mukaan jo alustan rakentamisen alkuvaiheessa. Useilta tiimeiltä saatava laaja palaute on erittäin arvokasta, kun haluat tehdä perusteltuja päätöksiä ja mitoittaa toiminnallisuuksia.

Alustan kestävyyden varmistaminen

Kun alustasi on käytössä, sitä on päivitettävä, laajennettava ja operoitava jatkuvasti. 

Yleinen lähestymistapa on käsitellä sitä tuotteena ja perustaa sitä tukeva alustatiimi. Lähestymistapa vaikuttaa luontevalta, mutta se voi olla DevOps-periaatteiden vastainen. Erotat kehityksen ja operoinnin toisistaan ja saatat luoda alustasiilon.

Yksi tapa vähentää tätä riskiä on antaa kehittäjien osallistua alustan kehittämiseen esimerkiksi innersourcingin avulla. Se on ohjelmistokehitysmenetelmä, jossa organisaation sisällä sovelletaan avoimen lähdekoodin projektien parhaita käytäntöjä.

Loppusanat

Internal Developer Platformin (IDP) luominen on olennaista, kun DevOps-hankkeita halutaan skaalata kuormittamatta kehittäjiä liikaa. Sen käynnistäminen ja ylläpito tuovat kuitenkin haasteita. Tämän blogikirjoituksen tavoitteena oli antaa yleiskuva IDP:n rakentamisesta arkkitehtuurin määrittelystä väistämättömien haasteiden ratkaisemiseen.

Sinulla on tarvittava osaaminen. Nyt on aika aloittaa!