Satojen vanhoilla virtuaalikoneilla (VM) toimivien sovellusten siirto AWS:ään onnistuu, kun sitä ajetaan tuotantolinjana eikä satoina erillisinä projekteina: inventoi ja luokittele jokainen sovellus, päätä päivitys tai uudelleenrakennus sovelluksittain ja jaa kokonaisuus lohkoihin, joista kukin kuuluu pienelle tiimille. Yhteinen sovellusrunko, testatut tuotantovaihto- ja palautusvaiheet sekä ajo-ohjeet, joita mikä tahansa tiimi voi seurata, pitävät laadun tasaisena volyymin kasvaessa.
Aloita inventaariosta, joka näyttää, mitä kukin sovellus todella tarvitsee
Ennen kuin kukaan koskee AWS:ään, listaa jokainen vanhoilla virtuaalikoneilla toimiva sovellus ja kirjaa tosiasiat, jotka määräävät siirron työmäärän. Aluksi jaettu taulukko riittää. Olennaista on, että jokaisella sovelluksella on rivi, omistaja ja samat sarakkeet.
Luokittele sitten jokainen sovellus muutamaan polkuun, kuten päivitys, uudelleenrakennus ja käytöstä poisto. Tiimit voivat silloin suunnitella polku kerrallaan sen sijaan, että jokaisesta sovelluksesta väiteltäisiin alusta asti.
- Ajoympäristön ja sovelluskehyksen versio sekä merkintä kaikesta, minkä tuki on päättynyt
- Tietokannat, tiedostojaot ja ajastetut työt, joista sovellus riippuu
- Saapuvat ja lähtevät integraatiot, mukaan lukien koodiin kovakoodatut palvelinnimet ja IP-osoitteet
- Tunnistautumistapa ja virtuaalikoneelle tallennetut salaisuudet
- Liiketoiminnan omistaja, käyttöaste ja hyväksyttävä katkoikkuna
Päätä päivitys tai uudelleenrakennus sovelluksittain, ei kerran koko ohjelmalle
Mikään yksittäinen strategia ei sovi satoihin sovelluksiin. Jotkin tarvitsevat vain sovelluskehyksen päivityksen, ulkoistetut asetukset ja uuden käyttöönottokohteen. Toisissa on niin paljon kuollutta koodia tai sotkuista rakennetta, että uudelleenrakentaminen puhtaalle pohjalle on nopeampaa kuin korjaaminen.
Tee päätös kirjallisten kriteerien pohjalta, jotta eri tiimit päätyvät samaan vastaukseen. Hyödyllinen sääntö: jos sovelluksen siirtäminen vakiorunkoon tarkoittaa joka tapauksessa suurimman osan sen kontrollereista ja tietojen käsittelystä uudelleenkirjoittamista, rakenna se uudelleen. Jos liiketoimintalogiikka siirtyy enimmäkseen ehjänä, päivitä se.
Crédit Agricolen ohjelma, jossa siirrettiin 600+ sisäistä sovellusta vanhoilta virtuaalikoneilta AWS:ään, käytti molempia polkuja. Sovellukset rakennettiin pankin sisäiselle CodeIgniter-rungolle; osa päivitettiin ja osa rakennettiin alusta asti uudelleen.
- Päivitä, kun koodi on luettavaa, sen toiminta on selkeää ja ero sovelluskehyksessä on pieni
- Rakenna uudelleen, kun liiketoimintalogiikka on kaikkialla sekoittunut esitystasoon tai sovellus riippuu kielestä poistetuista ominaisuuksista
- Poista käytöstä, kun käyttö on lähes nollassa ja liiketoiminnan omistaja hyväksyy sen, sillä halvin siirto on se, joka jätetään tekemättä
Jaa kokonaisuus lohkoihin ja anna kukin lohko yhdelle tiimille
Tässä mittakaavassa yksittäisestä keskitetystä tiimistä tulee pullonkaula. Lohkomallissa joukko toisiinsa liittyviä sovelluksia annetaan yhdelle pienelle tiimille, joka omistaa ne analyysistä tuotantovaihtoon.
Ryhmittele lohkot yhteisten riippuvuuksien eikä aakkosjärjestyksen mukaan. Sovellusten, jotka jakavat tietokannan tai kutsuvat toisiaan, pitää siirtyä yhdessä, muuten sama integraatiotyö toistuu eri tiimeissä.
Lohkot tekevät myös edistymisestä mitattavaa. Jokainen tiimi raportoi kullekin sovellukselle samat tilat, kuten analysoitu, siirretty, testattu, tuotannossa ja käytöstä poistettu, ja ohjelman tilannetaulu on näiden tilojen summa. Crédit Agricolen ohjelma toimi näin, ja SDK Enterprises toimitti ohjelmatiimin osana 50+ sen sovellussiirroista.
Rakenna yksi vakiorunko ja siirrä jokainen sovellus sen päälle
Vakiomuotoinen sovellusrunko tekee sadoista siirroista toistettavan prosessin. Se lukitsee päätökset, joita ei pidä tehdä uudelleen jokaiselle sovellukselle: hakemistorakenteen, asetukset ympäristömuuttujista, lokimuodon, terveystarkistukset, tunnistautumisen kytkentäpisteet ja käyttöönottoputken.
Jokainen siirretty sovellus eroaa silloin vain liiketoimintalogiikaltaan. Katselmoijat tietävät, mistä katsoa, ylläpitotiimit saavat yhtenäiset lokit ja hälytykset, ja runkoon tehty korjaus ulottuu jokaiseen sen päälle rakennettuun sovellukseen.
Pidä runko pienenä ja versioituna. Jos siitä kasvaa oma sovelluskehyksensä, tiimit alkavat kiertää sitä.
Suunnittele tuotantovaihto ja palautus ennen ensimmäistä siirtoa
Jokainen sovellus tarvitsee tuotantovaihdon suunnitelman, joka kertoo, miten liikenne siirtyy, miten tiedot siirtyvät ja miten palataan takaisin. Päätä nämä ennen kuin ensimmäinen sovellus siirtyy. Palautuksen improvisointi kesken häiriön on tapa, jolla siirto-ohjelmat menettävät liiketoiminnan luottamuksen.
- Jäädytysikkuna: sovi liiketoiminnan omistajan kanssa, milloin muutokset vanhaan virtuaalikoneeseen loppuvat
- Tietojen synkronointi: siirrä tiedot etukäteen ja aja sitten viimeinen muutossynkronointi tuotantovaihdon ikkunassa
- Liikenteen vaihto: muuta DNS:ää tai kuormantasaajan reititystä, ja aseta matalat DNS-TTL-arvot päiviä etukäteen
- Savutestit: lyhyt skriptattu tarkistus kirjautumisesta, keskeisistä näkymistä ja integraatioista heti vaihdon jälkeen
- Palautuksen laukaisin: nimetty henkilö ja kirjalliset ehdot takaisin vaihtamiselle
- Vanha virtuaalikone säilytetään: pysäytä se, mutta älä poista sitä ennen kuin sovellus on toiminut AWS:ssä moitteettomasti sovitun ajan
Kirjoita ajo-ohjeet, joita mikä tahansa tiimi voi seurata heti
Ajo-ohje (runbook) on tarkistuslista yhdelle toistettavalle toimenpiteelle: sovelluksen valmistelu, tuotantovaihto, palautus, virtuaalikoneen käytöstä poisto. Kirjoita kukin kerran, testaa se muutamalla ensimmäisellä sovelluksella ja päivitä se aina, kun jokin yllättää tiimin.
Hyvät ajo-ohjeet nimeävät komennot, vastuuhenkilöt ja odotetut tulokset, eivät aikomuksia. ”Tarkista, että sovellus toimii” ei ole vaihe. ”Kirjaudu testikäyttäjänä ja varmista, että kojelauta lataa tilitiedot” on.
Ajo-ohjeiden avulla myös kesken ohjelman liittyvät kehittäjät pääsevät nopeasti vauhtiin. Kuudennella viikolla saapuvan asiantuntijan pitäisi pystyä tekemään sovelluksen tuotantovaihto dokumentteja seuraamalla yhden parityöskentelykerran jälkeen.
Missä ulkopuolinen tiimi sopii suureen siirtoon
Suuret ohjelmat tarvitsevat usein lisäkapasiteettia määräajaksi luovuttamatta hallintaa. Otamme hoitaaksemme siirtolohkoja suurempien ohjelmien sisällä ja työskentelemme asiakkaan rungon, ajo-ohjeiden ja työkalujen pohjalta omien kehittäjiemme ja tarkistettujen freelance-asiantuntijoiden kanssa yhdellä sopimuksella.
Tärkeimmät havainnot
- Inventoi ja luokittele jokainen sovellus ennen kuin siirrät yhtäkään, jotta työ voidaan suunnitella poluittain.
- Valitse päivitys, uudelleenrakennus tai käytöstä poisto sovelluksittain kirjallisilla kriteereillä, joita jokainen tiimi soveltaa samalla tavalla.
- Jaa kokonaisuus toisiinsa liittyvien sovellusten lohkoihin, joista kukin kuuluu alusta loppuun yhdelle pienelle tiimille.
- Pieni, versioitu sovellusrunko tekee sadoista siirroista yhtenäisiä ja katselmoitavia.
- Älä koskaan vaihda sovellusta tuotantoon ilman testattua palautuspolkua ja edelleen saatavilla olevaa vanhaa virtuaalikonetta.
UKK
Kuinka kauan satojen sovellusten siirto AWS:ään kestää?
Se riippuu sovellusten määrästä, uudelleenrakennusta vaativien osuudesta, rinnakkaisten tiimien määrästä ja tuotantovaihdon ikkunoista, jotka liiketoiminta hyväksyy. Arvioi luokittelun jälkeen: ota aikaa muutamasta sovelluksesta kultakin polulta, kerro kunkin polun koolla ja jaa tiimien kapasiteetilla.
Kannattaako vanhat sovellukset ensin siirtää sellaisenaan ja modernisoida myöhemmin?
Siirto sellaisenaan (lift and shift) on nopein, kun sovellus toimii jo tuetussa ajoympäristössä ja tavoitteena on luopua konesalista. Kun ajoympäristön tuki on päättynyt, sovelluksen siirtäminen muuttamattomana kantaa vanhat riskit uudelle alustalle, joten päivittäminen tai uudelleenrakentaminen siirron yhteydessä tulee usein kokonaisuutena edullisemmaksi.
Mitä lohkoihin jaettu siirto tarkoittaa?
Lohkoihin jaetussa siirrossa (block-split) suuri sovelluskokonaisuus jaetaan toisiinsa liittyvien sovellusten eriin, ja kukin erä annetaan yhdelle tiimille, joka omistaa sen analyysistä tuotantovaihtoon. Se poistaa keskitetyn pullonkaulan ja tekee edistymisen seuraamisesta helppoa monen tiimin kesken.