Vuokramallit monivuokralaiselle sovellukselle

Kuulemme usein monivuokralaisen sovelluksen luomisen tärkeydestä, erityisesti ohjelmistona palveluna (SaaS) sovellusta kehitettäessä.

Käsitteessä "monivuokralainen sovellus" ja niissä eri malleissa, joita sen kehittämisessä käytetään, esiintyy jonkin verran epäselvyyttä. Tässä artikkelissa tarkastelimme näitä termejä käytännöllisemmällä tavalla.

Ymmärrä eri vuokrausmalleja teknisestä näkökulmasta#

Yksittäisen vuokralaisen arkkitehtuuri#

Yksittäisen vuokralaisen arkkitehtuuri on ohjelmisto- tai pilvilaskentamalli, jossa jokaisella asiakas- tai vuokralaisella on oma sovelluksen tai palvelun erillinen esiintymä. Jos tarkastelemme B2B-yritysmallin alkuperää, se alkaa siitä, että jokainen ohjelmiston esiintymä palvelee vain yhtä asiakasta tai organisaatiota.

Ominaisuudet#

• Eristäminen: Jokainen asiakas tai vuokralainen toimii eristetyssä ympäristössä, jolla on omat resurssit, tietokannat ja asetukset.
• Mukauttaminen: Yksittäisen vuokralaisen arkkitehtuurit mahdollistavat usein suuremman mukauttamisen ja joustavuuden tiettyjen asiakastarpeiden täyttämiseksi.
• Turvallisuus: Lisätty tietoturva ja tietosuojan vuoksi, sillä asiakastiedot eivät sekoitu muiden vuokralaisten kanssa.
• Skaalautuvuus: Resurssien ja kapasiteetin skaalaaminen voi olla yksinkertaisempaa, koska jokaisen vuokralaisen esiintymää voidaan säätää itsenäisesti.
• Ylläpito: Itsenäinen ylläpito ja päivitykset, sillä yhden vuokralaisen ympäristöön tehdyt muutokset eivät vaikuta muihin.
• Kustannukset: Tyypillisesti korkeammat infrastruktuuri- ja käyttökustannukset, koska jokaisen vuokralaisen tarvitsee ylläpitää erillisiä esiintymiä.

Esimerkit#

• Oma hosting: Perinteiset verkkohosting-palveluntarjoajat tarjoavat yksittäisen vuokralaisen arkkitehtuuria, jossa jokaisella asiakkaalla on omat resurssit, tietokannat tai asetukset.
• Paikallinen ohjelmisto: Jotkut yritystason ohjelmistosovellukset, kuten asiakkuudenhallintajärjestelmät (CRM) tai henkilöstöhallintajärjestelmät (HRMS), tarjoavat yksittäisen vuokralaisen käyttöönotto vaihtoehtoja organisaatioille, joilla on tiukat tietoturva- ja mukauttamisvaatimukset.
• SaaS premium-kategorioilla: Joissakin ohjelmistona palveluna (SaaS) tarjouksissa, premium- tai yritystasot tarjoavat yksittäisen vuokralaisen vaihtoehtoja asiakkaille, jotka vaativat parempaa turvallisuutta, vaatimustenmukaisuutta tai mukauttamista.

Yksittäisen vuokralaisen arkkitehtuuria käytetään yleisesti tilanteissa, joissa vaatimustenmukaisuus on ensisijainen tai tarvitaan räätälöityjä tietoturvavaatimuksia. Esimerkiksi rahoituksen, terveydenhuollon ja hallituksen kaltaiset alat, joilla on tiukkoja sääntelyvaatimuksia, suosivat usein yksittäisen vuokralaisen ratkaisuja varmistaakseen vaatimustenmukaisuuden.

On kuitenkin tärkeää huomata, että yksittäisen vuokralaisen arkkitehtuurit voivat olla enemmän resursseja kuluttavia ja monitahoisimpia hallita verrattuna monivuokralaisten arkkitehtuureihin, sillä jokaisen asiakkaan esiintymä vaatii oman infrastruktuurin ja ylläpidon. Tästä johtuen ne voivat olla paremmin soveltuvia sovelluksille, joilla on vähemmän mutta suurempia asiakkaita tai joissa mukauttamista ja eristämistä pidetään tärkeinä.

Monivuokralainen arkkitehtuuri#

Ohjelmistojen monivuokraaminen on ohjelmistoarkkitehtuuri, jossa yhden ohjelmiston instanssin pyörii palvelimella ja palvelee useita vuokralaisia. Tällaisella tavalla suunnitellut järjestelmät ovat "jaettuja" (eikä "omistettuja" tai "eristettyjä"). Vuokralainen on käyttäjäryhmä, jolla on yhteinen pääsy ohjelmiston instanssissa tietyllä etuoikeustasolla. Monivuokralaisarkkitehtuurissa ohjelmistosovellus on suunniteltu tarjoamaan jokaiselle vuokralaiselle erillinen osa instanssia - mukaan lukien sen tiedot, konfiguraatio, käyttäjähallinta, vuokralaisen yksilölliset toiminnot ja ei-toiminnalliset ominaisuudet. -- Wikipedia

Ominaisuudet#

• Jaetut resurssit: Useat vuokralaiset jakavat saman infrastruktuurin, mukaan lukien palvelimet, tietokannat ja verkkoresurssit, jotta resurssien käyttö saadaan optimoitua.
• Eristäminen: Vuokralaisten tiedot ja kokoonpanot ovat loogisesti eriytettyjä, mikä takaa tietosuojan ja turvallisuuden.
• Mittakaavaedut: Monivuokraaminen voi olla kustannustehokasta, sillä kulut jakautuvat useille käyttäjille, mikä pienentää operatiivisia ja infrastruktuurikustannuksia.
• Skaalautuvuus: Arkkitehtuuri voi skaalautua horisontaalisesti tai vertikaalisesti sopeutuen kasvaviin vuokralaisten ja käyttäjien määriin.
• Ylläpito: Päivitykset ja ylläpito ovat virtaviivaisia, sillä muutokset koskevat tasaisesti kaikkia vuokralaisia, mikä yksinkertaistaa hallintaa.
• Mukauttaminen: Vaikka jonkin verran mukauttamista on mahdollista, se on yleensä rajallisempaa verrattuna yksittäisen vuokralaisen arkkitehtuureihin, jotta järjestelmän laajamittainen yhtenäisyys säilyy.

Esimerkit#

• Pilvipohjainen SaaS: Useimmat ohjelmistona palveluna (SaaS) sovellukset, kuten Google Workspace ja Salesforce, hyödyntävät monivuokraamista palvellakseen useita organisaatioita tai käyttäjiä yhteisellä alustalla.
• Jaettu hosting: Web hosting-palveluissa jaetut hosting-palvelut isännöivät useita verkkosivustoja samalla palvelimella, joista jokainen kuuluu eri asiakkaalle tai organisaatiolle.
• Julkiset pilvipalvelut: Julkiset pilvipalvelutarjoajat, kuten AWS ja Azure, käyttävät monivuokraamista palvellen erilaisia asiakkaita eristetyillä virtualisoiduilla resursseilla jaetuissa datakeskuksissa.
• Yrityksen laajuinen infrastruktuuriratkaisut: Kuten jaettu Kubernetes-klusteri, jota käyttävät useat liiketoimintayksiköt organisaatiossa.

Monivuokralaissovellusten uudelleenmäärittely reaalimaailmassa#

Tarjosimme määritelmiä arkkitehtonisesta näkökulmasta, mikä tekee monivuokralaisen ja yksittäisen vuokralaisen suunnitelmien erottamisesta selkeän. Tämä kuitenkin kallistuu enemmän tekniseen määritelmään. Jos käytämme näitä määritelmiä reaalimaailman kehitys ympäristössämme suunnitellessamme vuokrausmallit, tämä ajattelutapa olettaa, että monivuokralaisen sovelluksen on oltava puhtaasti jaettu, monivuokralainen infrastruktuuri.

Kuitenkin liiketoiminnan ja tuotteiden moninaisuus vaihtelee paljon ja niillä on paljon tapauskohtaisia vaatimuksia, joten yksi ratkaisu ei sovi kaikille.

Kuvittele tilanne, jossa vuokralainen käyttää resursseja jaetusta infrastruktuurista, mutta erityisten liiketoimintatarpeiden vuoksi he tarvitsevat yhden tai kaksi osaa järjestelmästä, jotka ovat yksinomaan omistettu heille. Nämä omistetut osat voivat olla tietokanta, esiintymät tai yhdistelmä muita komponentteja, kuitenkin yhteistä infrastruktuuria jaettaessa. Tämä on paikka, jossa sekavuokralaisarkkitehtuuri tulee kuvaan mukaan.

Käytännön SaaS-tuotteen kehityksessä on yleistä kohdata tilanne, jossa tuote on ensisijaisesti suunniteltu yleisellä monivuokramallilla. Kuitenkin tietyt arkkitehtuurin tai resurssien osat saattavat olla "yksittäisvuokraamisen" suuntaisia.

AWS käytti seuraavaa tapausta esimerkkinä välittääkseen tämän käsitteen: monivuokraus on laaja käsite, ja se on tapauskohtainen yhdistää ja valita oikea strategia määritelläksesi mitä haluat saavuttaa jaetuilla resursseilla ja tietojen eristyksellä.

Toisin sanoen, joskus ihmiset kutsuvat tätä mallia edelleen "Monivuokraamiseksi", joten monivuokraamisen laajemmassa määritelmässä se ei tarkoita, että ratkaisun kaikki komponentit ovat jaettuja. Pikemminkin se tarkoittaa, että vähintään jotkut ratkaisun komponenteista uudelleen käytetään usean vuokralaisen kesken.

Ymmärtämällä tätä termiä laajasti voit paremmin asettua asiakkaasi asemaan ja ymmärtää mistä heidän tarpeensa tulevat.

Keskitysenä yhden arkkitehtonisen mallin sijaan, monivuokraus kuvastaa SaaS-tuotteen arkkitehtuurin käytännöllisyyttä reaalimaailmassa. Kun viittaamme monivuokralaiseen sovellukseen, se ei välttämättä tarkoita, että sovellus noudattaa yhtä arkkitehtonista mallia; se saattaa hyödyntää erilaisia vuokrausstrategioita, mikä tarkoittaa, että ainakin joitain sen komponentteja jaetaan.

Keskeisiä huomioita vuokrausmallistrategian määrittämiseksi#

Tässä tulee kysymys, kuinka ehdotan vuokrausstrategian tuotteelleni? Tässä on joitain tärkeitä kysymyksiä harkittavaksi:

• Mitkä ovat liiketoimintatavoitteesi?
• Voiko yksittäisen vuokralaisen ratkaisu tukea tulevaisuuden kasvusuunnitelmiasi?
• Kuinka suuri on toimintotiimisi, ja kuinka paljon infrastruktuurinhallinnasta voidaan automatisoida? Välitätkö ketteryydestä ja kustannustehokkuudesta?
• Ovatko asiakkaasi tyytyväisiä erilaisiin monivuokraus vaihtoehtoihin?
• Kuinka kukin vaihtoehto vaikuttaa vaatimustenmukaisuuteen, sekä sinun että asiakkaidesi?
• Oletko velvollinen noudattamaan palvelutason sopimuksia (SLA) tai pyritkö tiettyihin palvelutason tavoitteisiin (SLO)?
• Oletko harkinnut turvallisuutta, kustannuksia, suorituskykyä, luotettavuutta ja vastaamista yksilöllisiin vuokralaisen tarpeisiin kokonaisuudessaan?

Muista, että tuotteessasi ei ole jäykkää jakoa, jossa sinun on valittava joko puhtaasti monivuokralainen tai yksinään yksittäinen vuokralaisen malli. Päätöksesi tulisi perustua siihen, kuinka jaat tuotteesi arkkitehtoniset komponentit ja erityiset eristystasot, joita asiakkaasi tai liiketoimintasi vaatii. Voit sitten soveltaa eri lähestymistapoja sen mukaisesti.

Seuraavaksi#

Puhuimme monivuokralaissovelluksen "uudesta" määritelmästä, mutta entä vuokralaisten eristäminen, identiteetit, ja kuinka päättää siitä, tulisiko identiteettien eristää vai ei? Mitä tarkoittaa, että identiteetit ovat "eristettyjä"?

Epäselvyyttä syntyy usein, kun käsitellään tilanteita, joissa yhdellä reaalimaailman käyttäjällä on kaksi eri identiteettiä. Onko tämän tilanteen merkitseminen sopivaa - "identiteetit eristetty"?

Keskitymme näihin kysymyksiin seuraavassa artikkelisarjassamme. Pysy kuulolla!