Selkeyttä ja parempaa hallittavuutta mikropalveluarkkitehtuuriin NGINX Plus:n avulla
Mikropalvelut ovat viime vuosina nousseet yhdeksi tyypillisimmistä tavoista kehittää sovelluksia. Uusia mikropalveluita rakennetaan tyhjästä ja vanhoja monoliitteja puretaan mikropalveluiksi. Mikropalveluarkkitehtuurin rakentamiseen on kuitenkin monenlaisia näkemyksiä, ja varsinkin monoliitteja purkaessa asia on kaikkea muuta kuin yksiselitteistä. Suunnitelmallisella lähestymistavalla ja kokonaisratkaisujen suosimisella (pisteratkaisujen sijaan) homma helpottuu huomattavasti. Mutta mitä se tarkoittaa käytännössä?
Sovelluskehityksessä on suosittu jo pitkään mikropalveluarkkitehtuuria kehitettäessä uusia palveluita tai sovelluksia. Ja miksipä ei, ovathan mikropalveluarkkitehtuurin hyödyt moninkertaisia vanhanaikaisiin monoliittisovelluksiin nähden: Uusia toimintoja kyetään kehittämään, testaamaan ja ottamaan käyttöön helpommin sekä nopeammin. Samalla helpottuu yhteyksien rakentaminen kumppaneiden järjestelmiin ja sovelluksiin mikropalvelujen sisältämien API-rajapintojen avulla.
Silloin kun ei aloitetakaan puhtaalta pöydältä, vaan siirrytään monoliittisesta sovellusarkkitehtuurista mikropalveluihin, on mukana kuitenkin lisättyä vaikeuskerrointa.
Matka monoliitista mikropalveluihin ei ole aina suoraviivainen
Haasteeksi muodostuu esimerkiksi se, miten ja millä ratkaisuilla kyetään tarjoamaan mikropalveluilla toteutetut toiminnallisuudet vakiintuneissa toimintaympäristöissä, jossa samoja toimintoja halutaan käyttää eri kanavissa.
Otetaan esimerkiksi pankkisovellus, jonka on pystyttävä tarjoamaan samat toiminnallisuudet verkko- ja mobiilisovelluksissa sekä puhelinpalveluissa ja konttorilla.
Toinen huomioitava seikka on, että kun näin valtava kokonaisuus muutetaan mikropalveluilla toteutettavaksi, tulee mukana hallinnoitavaksi myös valtava määrä API-rajapintoja. Näiden hallinta onkin tärkeää, jotta myös yhteistyökumppanit ja muut sidosryhmät pääsevät hyötymään mikropalveluista.
Kun olemassa olevaa ratkaisua, kuten nyt esimerkkinä käytettyä pankkisovellusta, ollaan muuttamassa mikropalveluarkkitehtuuriin, tarvitaan aluksi tiekartta siihen, miten uusi arkkitehtuuri tulisi rakentaa ja ottaa käyttöön. Näitä tiekarttoja löytyy NGINX:n sivulta.
Seuraavaksi tulisi päättää, mistä kaikista komponenteista mikropalveluarkkitehtuuri muodostuu.
NGINX Plus on monikäyttöinen kokonaisratkaisu mikropalvelujen kehittämiseen
Nämä komponentit voivat osaltaan tulla valikoiduiksi sovelluskehittäjien toimesta kehitystyön aikana. Tällöin tosin työkaluiksi valikoituu helposti läjä erilaisia pisteratkaisuja, kuten erillisiä API-rajapintojen hallintaratkaisuja, kuormanjakajia jne .
Tuloksena syntyy helposti sekava kokonaisarkkitehtuuri, jonka ylläpito ja hallinta on hankalaa. Pisteratkaisujen sijaan kannattaakin panostaa toimivaan kokonaisratkaisuun, joka vastaa kerralla useampaan tarpeeseen. Kokonaisratkaisun hyödyksi on laskettavissa myös se, ettei pyörää tarvitse ensimmäisen kerran jälkeen keksiä uudelleen. Tällöin kaikki kehitystiimit pääsevät hyötymään jo opituista käytännöistä, joka nopeuttaa ja helpottaa kaikkien elämää.
Tällainen on NGINX Plus. NGINX Plus on ohjelmistojen kuormanjakaja, verkkopalvelin, verkkosovelluspalomuuri, rajapintojen hallintatyökalu ja sisältövarasto. Kyseessä on paremmin varusteltu versio monille tutusta avoimen lähdekoodin NGINX:stä.
NGINX Plus voidaan ottaa käyttöön palvelimilta, virtuaalikoneista tai suoraan Docker-konteissa, minkä vuoksi se soveltuu hyvin erilaisiin tarpeisiin ja taipuu monenlaisiin ympäristöihin.
Käytännön esimerkki NGINX Plus:n hyödyntämisestä pankkisovelluksessa
NGINX Plus:n kaltainen kokonaisratkaisu on äärimmäisen monikäyttöinen ja sen hyödyntämismahdollisuuksia on helpointa avata käytännön esimerkkien kautta:
Tämän kaltaisessa ratkaisussa taustalla on suurella todennäköisyydellä olemassa iso infrastruktuuri. Tässä infrastruktuurissa voi olla jo käytössä erilaisia työkaluja toimituksenhallintaan, kuten verkkoliikenteen hallintaratkaisuja [kuten Global Server Load Balancing (GSLB) tai DNS Based Load Balancing sekä sekä verkkosovelluspalomuureja (Web Application Firewall tai WAF).
Näistä ei suinkaan tarvitse luopua.
Liikennettä voidaan edelleen ohjata alkuperäistä infrastruktuuria hyödyntäen, mutta sitä täydennetään NGINX Plus:lla, joka toimii porttina itse mikropalveluihin. NGINX Plus parantaa tietoturvaa toimimalla käänteisenä proxyna käyttäjäliikenteen ja mikropalvelujen välillä. Samalla se jakaa kuormia eri mikropalveluiden välillä, jolloin varmistetaan kaistan riittävyys myös ruuhkahuippuina.
Lisäksi NGINX Plus käyttöä voidaan syventää hyödyntämällä sen sisältämiä verkkosovelluspalomuuri- (WAF) ja API-rajapintojen hallintaominaisuuksia. Kyseessä on siis varsin voimakas kokonaisratkaisu, jonka käyttö yksinkertaistaa arkkitehtuuria ja konkreettista kehittämistyötä.
Kuvasta nähdään, miten arkkitehtuuri rakentuu pankkisovellusesimerkissä.
GTM = GSLB tai DNS BLB; LTM = Load balancer / Application Delivery Controller
Omaksumalla NGINX Plus:n käyttö saadaan mikropalveluarkkitehtuurin hyödyistä enemmän irti
Mikropalveluarkkitehtuuriin siirrytään usein siksi, että sovelluksia kyettäisiin kehittämään joustavammin, tehokkaammin ja turvallisemmin. Mikropalveluja voidaan kuitenkin toteuttaa monella eri tapaa, ja toiset näistä ovat parempia kuin toiset.
NGINX Plus:n käyttö auttaa sovelluskehittäjiä saamaan mikropalveluiden hyödyistä enemmän irti ja luomaan palveluita, joiden arkkitehtuuri on selkeä ja ylläpito sekä jatkokehittäminen (verrattain) helppoa.
Nopeuta uusien ominaisuuksien toimitusaikoja: Uusien palvelimien ja kuormanjakajien pystyttämiseen ei mene aikaa. Kehittäjät pystyvät itse myös huolehtimaan ominaisuuksien käyttöönotosta.
Paranna palveluiden skaalautuvuutta: Koska NGINX Plus kyetään ottamaan käyttöön suoraan Docker-konteissa, voivat kehittäjät pystyttää valmiiksi uusia palveluita, jotka ovat automaattisesti tarjolla pyyntöjen ilmetessä. Näin mikropalveluita kyetään skaalaamaan helposti kysynnän muuttuessa.
Hallitse mikropalveluiden sisältämiä API-rajapintoja: NGINX Plus:n avulla voidaan myös hallita käytössä olevien API-rajapintojen saatavuutta, autentikointeja, säännöstelyä, turvallisuutta sekä muita osa-alueita ja sitä, missä määrin näitä tarjotaan kumppaneiden ja muiden sidosryhmien käyttöön.
Suunnitelmallisuudella ja kokonaisratkaisuilla tehdään parempia sovelluksia
Tässä blogissa minulla oli oikeastaan kaksi tavoitetta:
1) Halusin avata yhden esimerkin kautta siitä, miten monikäyttöinen ratkaisu NGINX Plus on ja miten sen eri toiminnallisuuksia voidaan käytännössä hyödyntää.
2) Ja tämä on ehkä tavoitteista se tärkeämpi:
Haluan haastaa sovelluskehityksen ja arkkitehtuurin parissa työskenteleviä ajattelemaan sitä, mitä hyötyjä voitaisiin saavuttaa siirtymällä pois harkitsemattomasta pisteratkaisujen käytöstä sovellusarkkitehtuurissa ja kohti suunnitelmallisempaa lähestymistapaa.
Kokonaisratkaisujen laaja hyödyntäminen on osa tuota lähestymistä.
Jos olette kehittämässä sovelluksia oman organisaationne tarpeisiin ja jatkokehityksen sekä ylläpidon tiedetään myös olevan omissa käsissä, on pisteratkaisujen käyttäminen karhunpalvelus teille itsellenne.
Kokonaisratkaisujen, kuten NGINX Plus, suunnitelmallinen käyttö tarjoaa sovelluskehittäjille välineet toimia systemaattisemmin, turvallisemmin ja tehokkaammin kuin käyttämällä useita erillisiä pisteratkaisuja – tinkimättä kuitenkaan kehittäjän vapaudesta.
Lue myös: MIKSI MAKSAA SIITÄ, MINKÄ VOI SAADA ILMAISEKSI? – OPEN SOURCE NGINX VS. NGINX PLUS
Haluatko keskustella kanssani siitä, miten NGINX Plus voisi soveltua teidän organisaationne tarpeisiin? Jätä yhteystietosi tähän, niin olen sinuun pian yhteydessä.
Tai tutustu muihin materiaaleihimme täällä: sovellustietoturva.fi.
Arrow F5 tiimi
Arrow ECS Finland Oy
Mail: f5.ecs.fi@arrow.com