Blogi
Written by
Toni Peltonen
Systems Engineer

Kuinka pilvinatiivit sovellukset ja niiden ajoympäristöt tulisi suunnitella?

Kolmiosaisessa blogisarjassa pilviarkkitehtimme Toni Peltonen sekä Anton Aksola johdattavat lukijansa pilvinatiivien sovellusten ja niiden ajoympäristöjen suunnitteluun. 

 

Nebula sertfikaatti

Käsittelemme alla pilvinatiivien sovellusten ja niiden ajoympäristöjen suunnittelua. Perustamme ajattelua ns. Twelve-Factor App käytäntöihin. (http://12factor.net/). 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 tuoda hyötyjä siirrettävyyteen ja jakeluun, mutta ei 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 suunnitelussa kannattaa pyrkiä active-active -malliin itse sovellustasolla ja välttää siirtämästä vastuuta korkeasta saatavuudesta esimerkiksi tietoliikennetasolle (kuormantasaajat, virtual IP -ratkaisut).

1. Microservices

Korkean saatavuuden ja skaalautuvuuden saavuttamiseksi on tärkeää käsitellä palveluja riittävän pienissä yksiköissä.

Microservices-arkkitehtuurissa (https://en.wikipedia.org/wiki/Microservices) monimutkainen sovellus pilkotaan pieniksi itsenäisiksi palveluiksi ja nämä juttelevat keskenään kieliriippumattomilla rajapinnoilla (usein HTTP API). Jokaisessa palvelussa toteutetaan Twelve-Factorista Port binding -metodia. Esimerkiksi Javalla tehdyn Web-sovelluksen tapauksessa WAR-pakettien sijaan sovelluksesta tehdään itsenäinen esimerkiksi Jetty HTTP serverin avulla.

Datamalleista tulee helposti puhtaampia, kun jokainen palvelu joutuu ottamaan vastaan ja tarjoamaan dataa 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.

https://www.nginx.com/blog/microservices-at-netflix-architectural-best-practices/

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.

 

Microservices

 


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.

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.

 

SSL Flow

 

Seuraavassa osassa kerromme kuinka pilvisovellus tulisi konfiguroida.  

Blogisarjamme sisältää: 

  1. Microservices
  2. Pilvisovelluksen konfiguraatio
  3. Taustapalvelut ja korkea saatavuus
  4. Ajoympäristö ja deployment

Seuraa siis blogiamme ja kerromme lisää! 

 

 

Written by
Toni Peltonen
Systems Engineer