Tässä postauksessa käsittelemme lyhyesti pilvinatiivien sovellusten ja niiden ajoympäristöjen suunnittelua. Ajatusketju on rakennettu Twelve-Factor App käytäntöjen pohjalta. Kaikessa yksinkertaisuudessaan tärkeintä suunnittelussa on pyrkiä tilattomiin prosesseihin ja palveluihin, joita voidaan helposti tuoda rinnalle lisää. Perinteiset sovellusympäristöt on usein kasattu kokonaisuuksiksi, joita ajetaan yksittäisellä palvelimella. Konfiguraatio tuodaan erilaisista paikallisista konfiguraatiotiedostoista ja pahimmassa tapauksessa ohjelmisto säilyttää tärkeää dataa paikallisessa tiedostojärjestelmässä.
Tälläisen sovelluksen skaalautuvuutta ja korkeaa saavutettavuutta ei voi parantaa pelkästään paketoimalla sitä uudestaan esimerkiksi Docker-levykuvaksi. Tälläinen uudelleenpaketointi saattaa kyllä tuoda hyötyjä siirrettävyyteen ja jakeluun, mutta se ei kuitenkaan ratko skaalautuvuuden ja käytettävyyden haasteita.
Jos tämän lähestymistavan alle aletaan rakentaa korkean saatavuuden ratkaisuja, tulee niistä helposti aika-, paikka- ja toimittajasidonnaisia. Aika olisi paremmin käytetty koko sovelluksen skaalautuvuuden parantamiseen arkkitehtuurista lähtien. Sovelluksen suunnittelussa kannattaa pyrkiä active-active -malliin itse sovellustasolla ja välttää siirtämästä vastuuta korkeasta saatavuudesta esimerkiksi tietoliikennetasolle (virtual IP -ratkaisut, kuormantasaajat).
Microservices
Korkean saatavuuden ja skaalautuvuuden saavuttamiseksi on tärkeää käsitellä palveluja riittävän pienissä yksiköissä.
Microservices-arkkitehtuurissa monimutkainen sovellus pilkotaan pieniksi itsenäisiksi palveluiksi ja nämä keskustelevat keskenään kieliriippumattomilla rajapinnoilla (esim. HTTP API). Jokaisessa palvelussa toteutetaan Twelve-Factorista tuttua Port binding -metodia. Esimerkiksi Javalla tehdyn Web-sovelluksen tapauksessa WAR-pakettien sijaan sovelluksesta tehdään itsenäinen vaikkapa Jetty HTTP serverin avulla.
Datamalleista tulee puhtaampia, kun jokainen palvelu joutuu ottamaan vastaan dataa ja tarjoamaan sitä järkevässä muodossa. Malli mahdollistaa myös sopivimman tietokantamoottorin valinnan eri palveluille. Voi olla, että metriikkapalvelu haluaa käyttää InfluxDB-tietokantaa asiakasrekisterin edelleen asuessa MySQL-tietokannassa.
Adopting Microservices at Netflix: Lessons for Architectural Design
Usein tälläisten palvelujen eteen, väliin tai taakse tarvitaan erillisiä middleware-palveluja toteuttamaan esimerkiksi SSL-purkua, kuormanrajausta tai kyselyjen reititystä. Tälläiset middleware-palvelut voivat olla itse tehtyjä sovelluksia tai valmiita reverse proxyjä kuten Nginx.
Arkkitehtuurin pilkkoutuessa on samalla hyvä varmistaa, että kyselyt ja sovelluksen sisäiset yhteydet on salattu. Kokemuksemme mukaan ihmiset usein automaattisesti olettavat sisäisten yhteyksien olevan luotettuja, eikä näin välttämättä ole. Sovelluksen eri komponentit voivat olla useassa eri konesalissa jotka voivat olla maantieteellisesti eri paikoissa. Tämän vuoksi on tärkeää muistaa salata kaikki sensitiivinen verkkoliikenne myös sisäverkon puolella.
Joko kokeilit Nebulan pilveä? Testata voit sitoumuksetta nyt 60 päivän ajan! Lue lisää ja rakenna oma pilvesi: nebulacloud.fi
