Sovelluskehitys ja pilvipalvelujen testaus ovat saamassa suosiota, kun yhä useammat yritykset käynnistävät julkisia ja yksityisiä pilvipalvelualoitteita. Pilvikehitys sisältää tyypillisesti integroidut kehitysympäristöt, sovellusten elinkaaren hallintakomponentit (kuten testaus- ja laadunhallinnan, lähdekoodin ja kokoonpanon hallinnan, jatkuvan toimituksen työkalut) ja sovellusten tietoturvatestauksen komponentit.
Vaikka teknologiajohtajat ja kehittäjät, joilla on kokemusta pilvipohjaisesta kehityksestä, sanovat, että näissä ympäristöissä kehitykselle on selviä etuja - kuten kustannussäästöt ja lisääntynyt markkinoinnin nopeus -, he myös varoittavat, että on olemassa haasteita ja yllätyksiä.
[Hanki tarpeettomat selitykset ja neuvot pilvipalvelujen hyödyntämiseksi toimittajien 21-sivuisessa Cloud Computing Deep Dive PDF -erikoisraportissa. | Pysy pilvessä pilvipalveluraportin uutiskirjeen avulla. ]
Ei ole selvää, kuinka yleinen kehitys pilvessä todennäköisesti tulee. Mutta teollisuuden analyysi osoittaa sen olevan nousussa. Helmikuussa 2011 julkaistussa tutkimusilmoituksessa Gartner sanoi, että yrityksen symposiumeihin vuonna 2010 osallistuneet asiakkaat ilmaisivat "voimakkaasti lisääntyneen kiinnostuksensa" pilvipalveluun nykyisten mukautettujen verkkosovellusten kehittämisen ja ylläpidon parantamiseksi.
"Pidän sitä eniten prototyyppien luomisessa ja rinnakkaisessa haarakehityksessä, mutta kuormituksen ja suorituskyvyn testaustilassa on myös valtava kasvu", sanoo Gartnerin johtava tutkimusanalyytikko Eric Knipp.
Jos haluat kokeilla pilvikehitystä ensimmäistä kertaa, tässä on yhdeksän tyyppistä estettä, joita saatat kohdata, ja ehdotuksia niiden ratkaisemiseksi kehittäjiltä, jotka ovat todella tehneet työn.
Pilvikehitys gotcha 1: Pilvi ei aina toimi kuten "todellinen maailma"
Kehittäjät saattavat huomata, että tuotannossa käyttämiään kokoonpanoja on vaikea jäljitellä pilvipalveluissa. Esimerkiksi pilvessä kehittämälläsi sovelluksella, ennen kuin palautat toimimaan paikallisesti, saatat joutua testaamaan vanhaa järjestelmää vastaan, jota et voi yksinkertaisesti kopioida pilvipalveluun, Knipp sanoo: "Tämä tarkoittaa, että siellä voi olla paljon enemmän juttuja, jotka kehittäjien on katkaistava saadakseen testisovelluksen käyttöön. "
Palvelun virtualisointiteknologia voi auttaa, Knipp sanoo, ja kehittäjät voivat hyödyntää markkinoiden tarjouksia, jotka mahdollistavat useita / rinnakkaisia haaroja. Otetaan esimerkiksi iTKO, joka tarjoaa Lisa-nimisen ohjelmistopaketin, joka auttaa yrityksiä siirtämään yrityssovelluksia pilveen.
Kehittäjät, jotka ovat tottuneet ei-pilvipohjaiseen kehitykseen, saattavat myös kohdata yllätyksiä web-sovellusten rakentamisessa pilvessä. Esimerkiksi Greg Taylor, joka rakensi online-rekisteröintisovelluksen Ohio Music Education Associationille, ei odottanut tarvitsevansa niin perusteellista tietämystä tietokannan rakenteesta ja siitä, miten käyttäjät olisivat vuorovaikutuksessa sen kanssa, kun hän loi sovelluksen.
Sovellus, joka hoitaa koulumusiikin esiintyjien rekisteröinnin osavaltion laajuiseen musiikkisisältöön, käyttää MySQL-tietokantaa taustana ja Alpha Five 10.5 Alpha-ohjelmistosta käyttöliittymänä. "Olen kotoisin FileMaker Pro -taustasta [ja], että tuote on erittäin anteeksiantava tietokantarakenteen suhteen", Taylor sanoo. "Huonoa muotoilua voidaan silti käyttää kohtuullisella menestyksellä."
Mutta MySQL: n kanssa kehittäminen pakotti Taylorin olemaan erittäin organisoitu niin, että verkkosovelluksella olisi paras mahdollinen suorituskyky. Paluu taulukkorakenteeseen lisätäksesi lisää kenttiä on aikaa vievää, koska siihen sisältyy vuorottelu eri kehitystyökalujen välillä, Navicat MySQL: lle ja Alpha Five varsinaisen verkkosivun suunnittelun välillä, hän sanoo. Ensimmäinen työkalu luo tietokantarakenteen, kun taas toinen luo sivut, joiden kanssa käyttäjä on tekemisissä syöttääkseen ja muokkaamaan tietoja tietokantaan.
"Tämä ei välttämättä ole ongelma kehittäjille, jotka hyödyntävät jo luotua tietokantaa", Taylor sanoo. "He yksinkertaisesti käyttävät Alpha Five -sovellusta kehittäessään verkkosivuja, joihin käyttäjä pääsee. Minun tapauksessani kehitin samanaikaisesti sekä tietokantaa että verkkosivuja, mikä olisi vaatinut minua vaihtamaan kehitystyökalujen välillä, ellet olisi suunnitellut huolellisesti."
Välttääkseen jatkuvan laukeamisen Taylorin oli muutettava tietokannan kehittämismenetelmäänsä: "Kehittämällä selkeä ERD [entiteettisuhdekaavio] ja kaikki tarvittavat kentät ensin, verkkosovellukseni on tehokas ja kokonaiskehitysaikani lyhenee huomattavasti"
Joissakin tapauksissa pilvikehitystyökalut toimivat todellisen maailman tavoin - ainakin eilisen version todellisesta maailmasta. Munuaisdialyysiin erikoistuneen terveydenhuollon yrityksen DaVitan HRIS-analyytikko Jeff Hensley yllättyi siitä, että pilvessä työskentelevien kehittäjien oli käytettävä komentorivityökaluja, XML: ää ja SQL: ää ", mikä muistutti minua vanhoista DOS-päivistä". Hän odottaa, että vanhan koulun lähestymistapa muuttuu ajan myötä, kun adoptio lisääntyy.
DaVita käyttää sekä pilvipohjaisia sovellusten jakelualustoja että isännöityjä palvelimia henkilöstötietotietovaraston ja liiketiedesovellusten kehittämiseen ja toimittamiseen.
Pilvikehitys gotcha 2: Jotkut sovellukset eivät ole ihanteellisia pilvikehitykseen Esimerkiksi uskonnonopetusministeriöiden IT-johtaja Dan Stueck välttää sellaisten huippuluokan sovellusten kehittämistä pilvessä, joilla on äärimmäiset tietoturva- tai sääntelyrajoitukset tai jotka luottavat vanhoihin koodausprojekteihin, kuten Cobolissa. "Nämä kaksi ovat todennäköisesti parhaiten talossa", hän sanoo, "ensimmäinen johtuu ilmeisistä turvallisuusongelmista ja toinen" kuolleen "kieliongelman vuoksi." Missä Stueck on käyttänyt pilviä, on kehittää palvelinta Amazon.comin julkisessa pilvipalvelussa ja rakentaa opiskelijoiden tietojärjestelmä, opiskelijoiden transkriptioarkisto ja kodin koulukirjojen myyntisovellus pilvessä. Pilvikehitys gotcha 3: Kehittäjät eivät usein pidä tuntemattomasta pilvialueesta "Ehkä kaikkein odottamaton oli se, kuinka hyvin koko [pilvikehitys] projekti otettiin vastaan hallinto- ja myyntitiimien ja kaikkien järjestelmän käyttäjien toimesta, ja kuinka huonosti IT-organisaatio ja erityisesti kehittäjät ottivat sen vastaan, "sanoo Mark Warren, pääarkkitehti 20/20. IT-ihmiset olivat tottuneet työskentelemään Microsoft .Net-, SQL Server-, Java- ja muiden perinteisten kehitysalustojen kanssa, Warren sanoo, ja Force.com oli täysin erilainen malli. "Jos tiedät SQL: n ja Java: n, se on sinun työkalupakki, etkä halua mennä tälle täysin muukalaiselle alustalle, joka on tulossa", Warren sanoo. Tuloksena myyntisovelluksen kehitti ensisijaisesti liike-elämän henkilökunta, ei IT-kehittäjät. Tämä toi omat haasteensa, Warren sanoo, joista suurin oli liikemiehien ymmärtämättömyys muutoksenhallinnasta ja IT-hallinnosta. "Tietotekniikalla on kurinalaisuutta, jota liikemiehet eivät ole tottuneet noudattamaan heitä", Warren sanoo. "Meidän oli saatava heidät vauhtiin muutoksenhallintakysymyksissä." Mitä tulee teknologian ihmisten haluttomuuteen kehittyä pilviympäristössä, on olemassa ohjelmia, joita IT voi toteuttaa auttamaan pilvipalvelujen omaksumisessa sisäisesti, Warren sanoo. "Koulutus on varmasti hyvä tapa helpottaa", hän sanoo. "Ellei tietotekniikan kulttuuri ole avoin uusille menetelmille ja tekniikoille, organisaation muutos [uusien kehittäjien saaminen] voi olla ainoa vaihtoehto." Pilvikehitys gotcha 4: Dokumentaation puute estää pilvikehittäjiä "Odotan ehdottomasti, että se muuttuu kysynnän kasvaessa ja yhä useammat yritykset alkavat mukauttaa pilvikonseptia", Hensley sanoo. "Pystyimme torjumaan sitä yhteistyössä konsulttiyrityksen kanssa." Pilvikehitys gotcha 5: Verkko-ongelmat voivat haitata yksityisiä pilviympäristöjä Embarcadero käyttää virtualisoitua datakeskustaan sovellusten rakentamiseen ja testaamiseen. "Sisäisten yksityisten pilvien suhteen meillä on pari vaihtoehtoa: valita ajoitettu päivämäärä / aika ja määrittää, mitkä palvelimet tehdään tietyssä järjestyksessä", Intersimone sanoo. "On olemassa automatisoituja rakennus- ja automatisoituja savutestausprosesseja, jotka ovat käynnissä koko ajan yksityisessä pääpilvessä ja myös aluekehitystoimistoissa." Saadakseen entistä paremman ympäristön, Intersimone kertoo etsivänsä pilvikontteja ja virtuaalisen yksityisen verkon tarjouksia CohesiveFT: ltä, jotka voidaan asentaa julkisiin ja yksityisiin pilviin tarjotakseen skaalaus, vikasietoisuus, palautus katastrofiin ja katastrofivalmiudet. Muita asioita, jotka voivat vaikuttaa kehitykseen ja testaukseen, ovat verkon viivästykset ja viive sekä verkkoputkien koko, erityisesti tietyissä osissa maailmaa. Embarcaderolla on tutkimus- ja kehityskeskuksia Scotts Valleyssa, Kaliforniassa, Montereyssa, Kaliforniassa, Torontossa, Pietarissa Flaissa ja Iasissa, Romaniassa, sekä sprinklöintiä pienemmistä joukkueista ja yksilöistä ympäri maailmaa. Embarcaderon maantieteellisesti monipuolinen kehitysympäristö "vaikeuttaa sisäänkirjautumisten, koontiversioiden ja automaattisen testauksen synkronointia", Intersimone sanoo. Joidenkin ongelmien ratkaisemiseksi kehittäjät tekevät paikallisia koontiversioita ja alueellisia koontiversioita sekä koodin sisäänkirjautumista kaikkien saatavilla oleville virtuaalipalvelimille. Kehittäjät tekevät myös paikallisia rakenteita omiin koneisiinsa. Embarcadero varmistaa, että nämä eivät pudota synkronoinnista yksityisen pilven pääversioiden kanssa käyttämällä avoimen lähdekoodin Subversion-työkalua lähdekoodin hallintaan. "Kun koontiversio tapahtuu, suoritetaan automaattinen testi rakennuksen vahvistamiseksi", Intersimone sanoo. "Sitten ilmoitukset lähetetään kaikille kehitystiimeille ja koontiversio vedetään automaattisesti kiinalaisen muurin yli suurelle määrälle automaattisia testausvirtuaalikoneita kehityskeskuksissamme." Tuloksena olevalle koontiversiolle tehdään automaattiset ja manuaaliset testit tilan vahvistamiseksi, ja sähköpostit lähetetään muille tiimin jäsenille tämän prosessin päätyttyä. "Kaikki tämä tapahtuu jatkuvasti projektin elinkaaren aikana", hän sanoo. Pilvikehitys gotcha 6: Mittarin on helppo antaa käydä tarpeettomasti pilvessä Toinen mahdollinen ongelma on rahan tuhlaaminen pilvimaksuihin. Kehittäjät voivat helposti unohtaa tai laiminlyödä sammuttamasta virtuaalikoneita, joita he eivät käytä. "Olen kuullut joiltakin asiakkailta, että kehittäjät päästivät villiin virtuaalikoneresursseilla, joita kehittäjät joskus vain jättivät tavarat käyntiin, esimerkiksi viikonloppuna", Gartnerin Knipp kertoo. "Kun se oli yrityksen sisäisellä, isolla isolla palvelimella, tämä ei ollut iso juttu. Mutta kun se on käytössä mitattuja, vuokrattuja resursseja kuten julkisen pilvipalvelun yhteydessä, tämä on rahan tuhlausta." Knipp sanoo odottavansa, että tästä tulee uusi haaste yrityksille, kun ne toteuttavat yksityisiä pilvialoitteita. Vaikka on pieni riski saada iso, odottamaton lasku kehittäjien virtuaalikoneiden käytöstä yksityisessä pilvessä, "itsepalveluprojektissa, IaaS-ympäristössä, kehittäjä voi kehittää virtuaalikoneita eikä koskaan sammuttaa niitä", Knipp sanoo. "Nämä kuluttavat tehokkaasti resursseja koneilta, joita ei käytetä tehokkaasti, ja ne voivat johtaa siihen, että organisaatio ostaa liikaa kapasiteettia suunnittelun vääristyessä." Pilvikehitys gotcha 7: Pilvilisenssit voivat sisältää yllättäviä käyttöönottorajoituksia Pilviin liittyvistä ei-teknisistä kysymyksistä, joilla voi olla vaikutusta kehitykseen, ovat lisenssirajoitukset. Kaksi vuotta sitten Kelly Services, kansallinen temp-virasto, päätti käyttää pilvipohjaista kehitystä monille kotimaisille sovelluksilleen. Salesforce.comin Force.com-alusta toimi toimitusajoneuvona. Pilvikehitys on tuonut etuja, kuten nopeampi läpimenoaika sovelluskehitykseen ja alhaisemmat kustannukset, sanoo Joe Drouin, tietohallintojohtaja Kelly Services -yrityksessä. Mutta yhtiöllä oli myös joitain odottamattomia ongelmia lisensoinnissa, erityisesti siitä, minkä tyyppisiä käyttäjäistuimia sillä oli ja mitä rajoituksia heillä oli. Esimerkiksi istuimella voi olla tietty määrä esineitä, joihin käyttäjä voi päästä. Tämän seurauksena "joissakin kohdissa olimme yllättyneitä siitä, mitä voimme tai eivät voineet tehdä" kehityksen kanssa, Drouin sanoo. Pilvikehitys gotcha 8: Integraation vianmääritys voi olla vaikeampaa
