Yrityssovellusten modernisointi
Mikäs ihme?
Azure Virtual Desktop (ennen Windows Virtual Desktop). Tuo epämääräinen laitos, jonka nimikin on vaihtunut parin viime vuoden aikana useaan otteeseen. Joo, myös Windows 365 on tarjolla, mutta tälle voi antaa vain hieman painoarvoa tässä vaiheessa.
Mutta Azure Virtual Desktop: Onko tästä mitään hyötyä kenellekään?
Ehkä tämä artikkeli vastaa muutamiin kysymyksiin asian tiimoilta.
Niin, tarkalleen ottaen mikä?
Azure Virtual Desktop on siis Microsoftin tarjoama, Azuressa pyörivä virtualisointialusta. Sen tarkoituksena on mahdollistaa Windows 10 -työasemien virtualisointi. Eli esimerkiksi miltä vain tietokoneelta voidaan käyttää Windows 10 -pohjaista ja yritysympäristössä olevaa virtualisoitua tietokonetta.
Lisätietoja:
Azure Virtual Desktop | Microsoft Azure
What is Azure Virtual Desktop? – Azure | Microsoft Docs
Lähtökohtaisesti tämä kuulostaa usein turhalta ja ei niinkään hyödylliseltä. Poislukien muutamat ns. tietyt nopeat skaalautumisen tarpeet, kuten koulun tarpeet tai kausityöläiset. Miksi tätä siis tarvittaisiin, kun Citrix ja VMwarekin näitä jo tarjoaa?
Tässä on muutamakin etuisuus.
Yrityssovellusten virtualisointi
Azure Virtual Desktop mahdollistaa ns. “ongelmallisten” ja toimistoverkkoa / VPN-yhteyttä vaativien yrityssovellusten virtualisoinnin. Eli niiden sovellusten käytön, jotka vaativat sen standardin Active Directory (AD) -pohjaisen autentikoinnin, tunnukset ja autentikoinnin.
Yksi esimerkki tästä on esimerkiksi kelluvia lisenssejä käyttävä tuotantosovellus (Floating License).
Näissä yritys yleensä varaa tietyn määrän lisenssejä sovelluksen saataville, jota päivän aikana käyttää vaihtuva määrä työntekijöitä. Esimerkiksi vuorotyössä ei tarvita sovellusta koko yrityksen työntekijöille 100% ajasta, vaan vain vuorossa olevalle työntekijämäärälle -> lisenssimäärä on suurissa tarpeissa merkittävästi pienempi kuin dedikoiduille käyttäjille toteutettu lisensointi. Kolmivuorotyössä määrä olisi esimerkiksi 1/3 siitä, mitä tarvittaisiin käyttäjäkohtaiseen lisensointiin.
Toinen vaihtoehto on erittäin raskaaseen prosessointiin tai graafiseen prosessointiin optimoitu sovellus, joka vaatii joko tehokkaan tietokoneen tai palvelimen datan prosessointiin. Tästä yleinen esimerkki on CAD -sovellukset, joissa insinöörit työstävät 3D -mallinnettuja objekteja ja suunnitelmia.
Tässä tilanteessa suunnittelijoille hankitaan joko dedikoidut ja merkittävän kalliit laitteet, joilla suunnittelu suoritetaan, tai suunnittelu suoritetaan vain toimistoverkon kautta (palvelimella / VPN -yhteydellä).
Kolmas vaihtoehto on vain sovellus, joka vaatii AD -autentikointia toimiakseen oikeaoppisesti. Eli kyseessä on vanhemman standardin sovellus, jota ei ole modernisoitu sovelluksen toimittajan toimesta. Se toimii virtualisoidussa maailmassa tai palvelimilla, mutta vaatii vielä tiettyjä asioita ympäristöltään, jotka on helpointa (tai tuettua) toteuttaa vain AD-pohjaisessa ympäristössä.
Näissä jokaisessa tilanteessa Azure Virtual Desktop tarjoaa suoran ratkaisun.
Sen kautta voidaan ajaa juuri vaadituille työntekijöille tai laitepäätteille virtualisoituja toteutuksia yrityssovelluksista skaalautuvasti tarpeen mukaan. Eli käytössä on aina ns. “sopiva” määrä resurssia. Näitä voidaan nimittäin skaalata käytön mukaan sekä ylöspäin että alaspäin ilman erillistä työmäärän lisäystä. Azure Automation hoitaa tämän taustalla, jolloin kapasiteettia ei tarvitse yli-tai alimitoittaa.
Mutta miksen käyttäisi vain AD:tä?
Tässä piileekin se Azure Virtual Desktopin hienous. Azure Active Directory Domain Services (Azure AD DS) sekä AD Connectin ns. Reverse Sync.
Hybriditoteutuksissa normaali AD ja Microsoft AD Connect on lähtökohtaisesti erittäin toimiva palvelukombinaatio. Se yhdistää vanhan AD:n, Azure AD:n ja O365:n palvelut mukavaksi autentikaatiokokonaisuudeksi. Siinä piilee kuitenkin merkittävä vaaratekijä. AD voi yhdellä virheellisellä synkronoinnilla tyhjentää koko Azure AD:n ja O365:n määrityksen.
Kaiken. Sähköpostilaatikot, Teamsit, käyttäjät, laitteet. Poissa.
Toki ne saadaan palautettua, mutta JOKAISELLE tunnukselle pitää alustaa uusi salasana palautuksen jälkeen. Yleensä tämänkaltainen katkos kestää vähintään yhden työpäivän verran palautuksineen. Potentiaalisesti merkittävästi pidempään.
Tämä johtuu siitä yksinkertaisesta syystä, että hybridimallin AD Connectista ns. “ankkuriarvona” käytetään AINA AD:ssä olevaa arvoa. Ja siellä tapahtuvat muutokset replikoidaan Azure AD:n ja O365:n puolelle. Näin onkin mahdollista, että AD Connect tyhjentää Azure AD:ssä olevat määritykset. Tästä hauskuudesta on omakohtaista kokemusta. Voin todeta, että ei ollut mukavaa.
Mitenkö Azure AD DS tätä muuttaa, kun sekin käyttää AD Connectia?
Hyvä kun kysyit!
Siinä on sellainen perustavanlaatuinen ero, että se käyttää Azure AD:tä ankkuriarvona. Tämä yksinkertainen muutos varmistaa sen, että mahdollinen Azure AD DS:n muutos tai virhetilanne ei vaikuta mitenkään sähköpostiin tai muihin käyttäjätileihin. Vain potentiaalisesti tuotantosovelluksen pääsyyn tai tilanteeseen. Muu yrityksen O365:n kautta kulkeva liiketoiminta ei häiriinny mahdollisesta virhetilanteesta. Eli Azure AD DS:n ei ole edes MAHDOLLISTA tehdä muutoksia Azure AD:n puolelle, jolloin se onkin juuri “Reverse AD Connect” tässä tapauksessa.
Toki Azure AD DS myöst poistaa kaiken AD:n ylläpidon overheadin ja huolen, ja poistaa tarpeen toimistoverkolle tai VPN-yhteydelle.
No mut enks mä voi vaan ostaa SaaS -ratkaisun yrityssovelluksesta?
Oh my sweet summer child… Tätä me ollaan yritetty aina ajaa läpi kun vain on suinkin mahdollista!
Usein se ei kuitenkaan valitettavasti tunnu olevan ratkaisu, tai edes mahdollista muutamista hassunhauskoista seikoista johtuen.
- Yrityssovellus ei tue muita autentikaatiotapoja kuin AD -> AD (Connect) tai Azure AD DS
- Sovelluksen SaaS -toteutus on joko täysin KAUHEA tai ylihinnoiteltu
- Sovelluksella ei ole suunnitelmissa toteuttaa SaaS -mallista pilvitoteutusta (kehitys lopetettu tms.)
Tässä vain muutama esimerkki siitä ilosta, millä näitä pirulaisia lähdetään modernisoimaan. Yksi hauska esimerkki oli myös pelkkä RDP-yhteys SaaS -sovelluksen ylläpitämään pilviympäristöön. Tästä ympäristöstä ei kuitenkaan sitten saatu mitään integrointeja esimerkiksi muihin tuotantosovelluksiin tai ympäristöihin. Eli tarjolla oli vain pelkkä sovellus, mutta ei mitään yhdistäviä palveluita. Näin koko sovelluksen pohja putosi pois, kun sitä ei saatu yhdistettyä muihin sen vaatimiin palveluihin.
Siis hä, eikai se noin voi olla?
No mut pakko tän on sit olla ihan pirun kallis?
Joo, ja ei niinkään. Jos täysin tyhjältä pohjalta lähdetään tekemään muutosta, niin kulurakenne on kuukausipohjaisesti varmasti suurempi kuin nyt. Tällainen vertailu on kuitenkin hieman naljua, kun ei se olemassa olevakaan yrityssovellus ole tyhjästä tullut. Paitsi jos kyseessä on piratoitu tai ilman lisenssiä oleva yrityssovellus, jolloin kyseessä onkin jo ihan muu ongelmavyyhti…
Mutta, jokaisessa yrityssovelluksessa on aina pohjakustannus sen alkuperäisessä hankinnassa tai konfiguraatiossa. Azure Virtual Desktop on siinä mielessä hyvin samankaltainen, eli pohja luodaan uudestaan, mutta vain Azure AD DS:n ja Azure Virtual Desktopin pohjalle.
Se hyvä puoli tässä on, että koko kikkare voidaan toteuttaa asiakkaan jo olemassa olevaan O365:n tenanttiin ilman mitään riskejä. Potentiaalisesti tästä syntyy vain kustannuksia, mutta nekin saadaan käytännössä minimiin yllämainitun skaalauksen kautta. Eli jos palvelimet pidetään poissa päältä, kun niillä ei testata, niin ei niistä myöskään synny kustannuksia. Eli ns. “Pay as you go” -malli on voimassa. Testivaiheessa kulurakenne on potentiaalisesti n. 90% pienempi kuin tuotantovaiheessa juuri tämän takia.
Toinen hyvä puoli on lisensoinnissa. Jos asiakasyrityksellä on jo nyt esimerkiksi jonkin sortin virtualisointiratkaisu tulilla (Citrix, VMware), niin poistaa tämä pitkässä juoksussa näiden tarpeen kokonaan. Tiedän kokemuksesta, että Citrixin lisenssit eivät ole sieltä halvimmasta päästä. Azure Virtual Desktopin lisenssi siis sisältyy jo M365 Business Premium -lisenssiin. Toki se ei palvelimen käyttöasteen kuluja korvaa, mutta ei myöskään Citrixin tai VMwaren lisenssi tätä tee.
Muutaman erilaisen ja erikokoisen Azure Virtual Desktopin toteutuksen juoksevat palvelinkustannukset ovat olleet Azuren puolella n. 300 – 1200€ / kk riippuen tarvituista resursseista. Tässä on siis myös mukana SQL -lisenssi sekä Windowsin palvelinlisensoinnin kulut. Tähän vielä erikseen päälle tulevat sitten mahdolliset yrityssovelluksen omat lisenssikulut.
Eli ratkaisu voi olla joko kallis, tai merkittävästi halvempi kuin nykyinen toteutus.
Pyh, evvk tällaiset kikkareet!
Se on ihan OK, ei tämä kaikille toki sovi. Monissa ympäristöissä on merkittäviä rajoituksia esimerkiksi datan tallennuksen suhteen, jolloin vain paikalliset palveluntuottajien ratkaisut ovat sallittuja. Näissä tilanteissa on kuitenkin hyvä arvioida, missä kohtaa laissa vaaditaan, että datan pitää olla juuri Suomessa, eikä esimerkiksi EU:n rajojen sisällä. Voi olla vaikeaa löytää niitä rajoituksia tai tarkkoja kohtia, missä tämä mainitaan.
Suosittelemmekin vahvasti arvioimaan ja kysymään rohkeasti meiltä tällaisesta toteutuksesta tai sen sopivuudesta yrityksenne IT-infrastruktuuriin.
Voitte positiivisesti yllättyä, tai pöyristyä halutessanne. Emme tuomitse kumpaakaan tahoa!