Migration to the cloud: roadmap. PART 2: Metodik för att migrera applikationer till molnet

Transkript

1 Migration to the cloud: roadmap PART 2: Metodik för att migrera applikationer till molnet

2 PART 2 ÖVERSIKT 1. Inledning 2. Olika typer av migrering till molnet 3. Metoder för att migrera en applikation 4. Val av migrationsstrategi 5. Verktyg

3 1. INLEDNING

4 INLEDNING Som med alla IT-projekt, kunderna behöver studera om det är tekniskt och ekonomiskt genomförbart att migrera deras IT-tillämpning till molnet. I processen för beslutsfattandet, är det bra att först uttrycka behov och sedan utvärdera molnlösningar som uppfyller dessa krav. Det kommer då att bli nödvändigt att beräkna avkastningen på investeringen (ROI), riskanalys och integrationsfrågor med företagets datasystem.

5 2. TYPER AV MIGRATION

6 OLIKA TYPER AV MIGRERING TILL MOLNET Enligt Gartner, Inc., organisationer som vill migrera sina program till molnet har fem alternativ [15] [16]: Rehost: Värdapplikationer som är på en infrastruktur som en tjänst (IaaS) Refactor: Värdapplikationer till Platform as a Service-nivå (PaaS) Revise: Ändra och anpassa applikationer till en IaaS eller PaaS Rebuild: Bygg ett program på en PaaS Raplace: Byt till Software as a Service (SaaS) "När CIO utfärdar det enkla direktivet" Flytta vissa applikationer till molnet, ställs arkitekter inför det förbryllande val om hur man gör detta, och deras beslut måste överväga en organisations behov, utvärderingskriterier och arkitektur principer, säger Richard Watson, forskningschef på Gartner. Men det erbjuder inte något alternativ en silverkula: Alla kräver att arkitekter ska förstå migrationen från flera perspektiv och kriterier, såsom IT-personalens kompetens, värdet av befintliga investeringar och applikationsarkitektur."

7 OLIKA TYPER AV MIGRERING TILL MOLNET Vi skulle kunna lägga till ett 6: e alternativ till listan över Gartner [15] [16]. - Data Rehost: Flytta data till molnet. Detta gäller överföring av affärsdata till billigare lagringssystem för att säkerställa mer säkerhet, bättre prestanda, mer tillgänglighet. Denna typ av migration kan implicit ingå i de fem tidigare beskrivna alternativ. Detta kallas DAAS (Data as a Service). Denna typ av migration kan användas när företaget behöver lagring i realtid för att fatta beslut snabbt eller för Big Data integrationsproblem i lagering.

8 OLIKA TYPER AV MIGRERING TILL MOLNET Från det lokala till molnet: Rehost (IaaS) Refactor (PaaS) Revise (IaaS/Paas) Rebuild (PaaS) Replace (SaaS) Från ett moln till ett annat (private, public)

9 OLIKA TYPER AV MIGRERING TILL MOLNET Beroende på om man migrerar ett program i SaaS, PaaS eller IaaS, hantering av migration och arbetsbelastning skiljer sig som visas i följande figur anpassas från [1] My application personal management charge S1 My application Data Runtime Middleware Operating System Virtualisation Servers Storage Network

10 OLIKA TYPER AV MIGRERING TILL MOLNET Migrering av en applikation i IaaS: IaaS personal management charge S1 My application Data Runtime Middlew are Operating System Virtualisation Servers Storage Network personal management charge

11 OLIKA TYPER AV MIGRERING TILL MOLNET Migrering av en applikation i PaaS: PaaS personal management charge S1 My application Data Runtime Middlew are Operating System Virtualisation Servers Storage Network personal management charge

12 OLIKA TYPER AV MIGRERING TILL MOLNET Migrering av en applikation i SaaS: SaaS personal management charge S1 My app lication D ata R untime Middlew are Operating System Virtu alisation Servers Storage N etw ork personal management charge

13 OLIKA TYPER AV MIGRERING TILL MOLNET Den idealiska strategi för att migrera till molnet är inte enbart beroende på behoven hos varje kund utan även villkoren för tidigare system Varje strategi har sina egna mål: Med PaaS, måste företagen fastställa de förändringar som krävs för att applikationen är förenlig med plattformen I molnet I de fall där företagen behöver göra fler ändringar för att migrera till en PaaS, kan valet av IaaS vara lämpligare Som en effektiv mekanism för leverans av programvara, kan SaaS vara det idealiskt valet, men utmaningen för SaaS är uppenbar

14 OLIKA TYPER AV MIGRERING TILL MOLNET Jämförelse av tre strategier enligt flera kriterier [2]: Iaas Paas Saas Workload low Moderate Large Migration complexity Easy Moderate Difficult Adaptation Not required Modify applications to adapt Need to make Reverse Engeneering Forward Engineering Impact Save expenses for equipment Resource management freedom Flexible price mechanism, convenient maintenance, reuse and scalability

15 MIGRATIONSTYP REHOST (IAAS) Flytta applikationer till en annan hårdvarumiljö och ändra konfigurationer av applikationsinfrastruktur [15] [16] [17] Fördelar: Flytt utan att ändra dess arkitektur möjliggör en snabbare migrering Nackdelar: Applikationen inte få nytta av molninfrastruktur såsom skalbarhet Hosting eller virtualisering av mycket specifika eller gamla system är inte alltid möjligt Database Application Deployment on the initial platform Virtual Infrastructure Deployment on a Cloud Platform

16 MIGRATIONSTYP REFACTOR (PAAS) Syftet med Refactor är att implementera program som körs på en teknisk miljö med nyare hårdvara och operativsystem som tillhandahålls av molnet [15] [16]. Det kan leda till mindre justeringar, som ofta gör det möjligt att förbättra tillgänglighet och prestanda eller öka resurskapacitet. Fördelar: Förläng livslängden på gamla program Kombinera innovation och kunskap, eftersom PaaS tillåter användning av språk och ramverk som utvecklare känner till och kan. Nackdelar: Mycket gamla utvecklingsverktyg kan utgöra ett kompatibilitetsproblem och kan leda till minskad funktionaliteten i den migrerade applikationen. Inte utnyttjar alla PaaS funktioner Låst inom ramen för PaaS

17 MIGRATIONSTYP REVISE (IAAS/PAAS) Revise syftar till att ändra eller förbättra befintlig kod så att den kan dra nytta av fördelarna med cloud (skalbarhet etc.) och sedan distribuera applikationer efter Rehost och Refactor [15] [16]. Fördelar: Program kan utvecklas och förbättras med ökad exploaterbarhet (till exempel, hög tillgänglighet eller parallell bearbetning) Applikationer kan anpassas till nya funktioner (webbgränssnitt, integration med andra program, etc.). Nackdelar: Kan orsaka större förändringar än en enkel migration. Dessa kan bli långsamma och begränsas av den ursprungliga utformningen av applikationen. Förändringarna innebär kostnader för att mobilisera ett utvecklingsteam Beroende på omfattningen av översynen, är det sannolikt att det åtgår mest tid för denna typ av migration.

18 MIGRATIONSTYP REBUILD (PAAS) Sker vid PaaS nivå [15] [16]. I detta fall ske den befintliga koden upphävas, och vi går till återuppbyggnaden av arkitekturen av applikationen Fördelar: Tillgång till nya funktioner som erbjuds av PaaS, som förbättrar utvecklarnas produktivitet, såsom verktyg för att anpassa mallar för applikation eller datamodeller. Nackdelar: Mindre förtrogenhet med de verktyg som erbjuds av PaaS. Inlåsningseffekter är den viktigaste nackdelen, i själva verket, om leverantören gör tekniska ändringar till ett pris kunden inte kan acceptera, om leverantören bryter mot SLA, eller till och med försvinner, kommer kunden att tvingas att ändra, eller att ge upp vissa av sina gamla program

19 MIGRATIONSTYP REPLACE (SAAS) Slutar använda befintligt program (eller en uppsättning applikationer) och använder en kommersiell lösning som levereras som tjänst på villkor att den täcker befintliga funktioner [15] [16]. Fördelar: Detta alternativ undviker investeringar och mobilisera ett utvecklingsteam när behoven av affärsfunktioner ändras ofta. Användningen av standardprogramvaror ger kunden möjlighet att dra nytta av utvecklingen av programvaran till lägre kostnad (kostnad som delas mellan alla affärskunder). Nackdelar: Inlåsningseffekter Obehörig åtkomst till data Mycket betydande förändringar i arbetsvanor för användare när de byter från gammalt till nytt program. Behovet av utbildningspolitiken. Kundenkan inte utveckla applikationen enligt sin egen takt

20 MIGRATIONSTYP DATA REHOST (DAAS) I detta fall är det endast databaser involverade i migrering. Database Application Deployment on the initial platform Virtual Infrastructure Deployment on a Cloud Platform Fördelar: Dataöverföringar till lagringssystem kan skalas upp. Bättre garantier för skydd och säkerhet. Data kan partitioneras för att förbättra och optimera prestanda. Nackdelar: Dataöverföringen och partitionering kan vara dåligt för de befintliga applikationerna.

21 3. METODER FÖR ATT MIGRERA EN APPLIKATION

22 METODER FÖR ATTMIGRERA EN APPLIKATION Observera att de mesta av detta innehåll är vid migration PaaS, IaaS eller i mindre utsträckning. I själva verket innebär övergången till SaaS bara migreringen av produktanvändning, och migration till en IaaS plattform är oftast enkla kopior av applikationer till virtuella maskiner.

23 METODER FÖR ATTMIGRERA EN APPLIKATION Olika migrationsmetoder vare sig det är akademisk eller industriell, innehåller mer eller mindre samma faser De enda skillnaderna som observerats är fusion av två eller flera faser i en, men totalt sett samma uppgifter finns i varje Faserna för en migrering av en applikation är: A. Beslutsfattande B. Förstudie C. Design och planering D. Pilotprojekt E. Migrering F. Förbättring och förstärkning av molnet G. Opåtimering

24 A. BESLUTSFATTANDE Det första steget, innan man funderar på migration till molnet, är en fas av beslutsfattandet Detta steg syftar till att svara på den övergripande frågan: "Är företaget eller organisationen intresserade av att gå till molnet"? Vi har tidigare presenterat fördelarna och nackdelarna med molnet och nu är det viktigt att bestämma vilka fördelar framför andra i ett särskilt fall av system och applikationer (s)

25 A. BESLUTSFATTANDE Det här steget finns inte i de metoder som erbjuds av molnleverantörer. Vi kan tro att de utgår från att om en organisation är intresserad så accepterar de deras metoder för att anta sin lösning, det innebär att de redan har beslutat att migrera till molnet När det gäller mer akademiska metoder, lär detta steg tvärtom beskrivas varje gång Denna metod i form av en analys och uppsättning kriterier, fördelar sig enligt följande: 1. Definition av beslutskriterier 2. Viktning kriterierna 3. Analys av lösningen 4. Aggregering av resultat

26 A. BESLUTSFATTANDE Definitionen av beslutskriterier bygger på nuläge, användarnas behov och säkerhetspolicyn Viktningen av kriterierna. Målet är att tilldela en poäng till varje kriterium på en skala från 1 till 4 (avgörande betydelse, stor, medium eller låg). Vi kan sedan kvantifiera de viktigaste kriterierna från kundens perspektiv (vi kan tänka på säkerheten eller minskade kostnader till exempel) Analysen av lösningen. Vi måste sedan jämföra lösningen mot kriterierna. Denna fas kan göras via online-dokumentationen, eller genom att besöka molnleverantören och ställa frågor enligt kriterierna. Vi kommer då att ge en poäng för varje kriterium (t.ex., 1 poäng om ett krav är delvis uppfyllt, 2 poäng om en annan är helt fylld) Sammanräkning av resultaten. Detta steg består i att analysera resultaten när det gäller betyg och vikter för att få fram indikatorer. Dessa indikatorer, presenteras grafiskt och kommer att vara användbara för att hjälpa beslutsfattandet

27 A. Olika kriterier [4]: Criteria Cost Analysis Comment Is the cloud platform providing an interesting ROI (considering the subscription and deployment)? For example, does reducing software licensing costs, machinery, and load operations teams lead to substantial benefits? Operator Strategy Is the cloud platform, the business core of the operator or a marginal offer? Sustainability of operator Is the cloud provider sustainable? solvent? mature? Operator flexibility Does the operator impose contracts? Rationalization around the core business A. BESLUTSFATTANDE The cloud platform allows it to outsource tedious tasks except those constituting the business core? For example, the mail is never a business application.

28 A. Olika kriterier: A. BESLUTSFATTANDE Criteria Regulatory Compliance Acceptance by customers and partners Sustainable development Made in France (Europe) Security Comment Is the cloud convenient model in the company's business sector? For example, outsourcing of accounts by a bank is impossible Is it possible that the use of cloud model poses problems for customers or partners? For example, a law business lawyer can easily outsource documents concerning mergers / acquisitions. Is it possible that the use of cloud reduces the company's environmental footprint? The use of cloud located abroad poses some potential problems facing local law Application security and ability to restore data in case of problems.

29 B. Olika kriterier: A. BESLUTSFATTANDE Criteria Agility Ergonomics of applications Applications Scalability Innovation Accelerator Accessibility for deficients Comment Is the cloud platform allowing to shorten the time to market of applications? Is the cloud platform allowing to provide users more ergonomic applications with Customer drive roadmap? The cloud platform allows it to make available more often evolution of applications using the "perpetual beta"? Is the platform a good tool that facilitate the incubation of innovative applications? Is the cloud platform able to make it possible to provide users with easily accessible applications for people who may have disabilities.

30 A. BESLUTSFATTANDE B. Olika kriterier: Criteria Accessibility applications Availability / applications QoS Mashups Acceptability Comment Is the cloud platform allowing it to provide users more easily accessible applications? For example, are the current applications accessible using teleworking, a nomadic situation from a mobile? Does the cloud operator bring to the applications level more advanced availability than that of the business? For example, a small business that outsources mail will benefit from an availability of 99.9%. Does the cloud platform allow simply the creation of new applications by assembling? Does the cloud platform introduce unacceptable constraints for users? For example, it is not possible to work offline.

31 A. BESLUTSFATTANDE C. Olika kriterier för ISD (Information System Department): Criteria Agility for studies Agility for production Change management Platform flexibility Comment Is the cloud platform allowing to save time on development tasks? Does the cloud platform allow production to save time on tasks of putting into production? Are the new cloud-related work methods (data storage in the provider servers, data lock-in, providers management) acceptable? Is the skill improvement simpler than earlier? Does the platform impose a constraining architecture for the SI?

32 A. BESLUTSFATTANDE C. Olika kriterier för ISD: Criteria Sub-Criteria Comment Security Authentification Does the cloud provider offer a sufficiently secure authentication device, especially for administrative tasks? Otherwise, does she/he offer a system of delegation of the authentication? Confidentiality of data stored within the cloud operator Is the Outsourcing data through the use of cloud platform consistent with the company's security policy? For example, data related to project schedules can be outsourced if they are classified as non-critical. Streamlining access security (confidentiality of data exchanged) Does the cloud provider offer a more homogeneous security system than the company?

33 C. Olika kriterier för ISD: Criteria Sub-Criteria Comment Securit y Integrity of the data stored in the cloud operator Traceability Reversibility Recovery Time A. BESLUTSFATTANDE Does the cloud provider offer backup practices or disaster recovery plan more advanced than that of the company? For example, an SME can gain in security by outsourcing its data. Is the cloud operator offering traces on the access / user behavior? Does the cloud operator offer tools to recover data / applications? Otherwise, does he offer at least one API for creating such a tool? Is the cloud operator having an ongoing commitment on the recovery time in case of failure?

34 A. BESLUTSFATTANDE Efter att ha analyserat processen för kriterier, kan vi nu titta på en annan aspekt av denna fas av beslutsfattandet, vilket innebär att tänka på fördelarna och nackdelarna med tanke på de olika delar av verksamheten som är involverade i migreringen Denna reflektion bör genomföras parallellt eller tidigare än analysen som presenteras i föregående avsnitt

35 A. BESLUTSFATTANDE 1. Beslutsfattarnas synpunkt Fördelar: Minskningen av infrastrukturkostnader. Först minskade kostnader för den löpande driften tack vare mutualization. Dessutom molnleverantörerna köper i grossistledet, datorer och elenergi, och kan förhandla ner priset Grön IT: molnet gör det möjligt att minimera miljöpåverkan av datorer till exempel genom att undvika energislöseri från arbetsstationer och datacenter. Aktörerna på cloud computing har oftast optimerade ventilationsanordningar och de börjar att använda mer förnybar energi för sina datacenter

36 A. BESLUTSFATTANDE Fördelar: Minska användar kostnader: Den ekonomiska modellen för molntjänster debiteras efter konsumtion Hyra licenser är nästan alltid billigare än att köpa, det bidrar också till att jämna ut kostnaderna i tid och överföra investeringar (CAPEX: Investeringar) till driftsutgifter (OPEX: driftsutgifter) Molnet erbjuder goda säkerhetsgarantier när det gäller dataintegritet Detta i sin tur bidrar till att fokusera på sin kärnverksamhet, med fokus på insatser i verksamheten affärshjärta" och direkta värdeskapande, samt delegera hela eller delar av en domän av informationssystemet [5]. Molnet ger också olika fördelar såsom mer hållbara informationssystem, nya funktioner, utplacerade snabbare, etc...

37 A. BESLUTSFATTANDE 1. Beslutsfattarnas synpunkt Nackdelar: Tjänster i molnet antar en kommersiell risk: vad kommer att hända om operatören går i konkurs? Om han ändrar sina villkor eller priser? Det är viktigt att värdera denna osäkerhet noggrant och ta dem i beaktande vid val av operatör När ett företag föreslår att migrera till molnet av sina kunders information (epost, adresser...), är den skyldig att ta hänsyn till kundens uppfattning Vi måste kontrollera till exempel om denna migration har rättsliga hinder. Det kan vara så att vissa uppgifter ska anmälas till CNIL eller anställda kan vara medveten om verktyg för att genomdriva sina rättigheter

38 A. BESLUTSFATTANDE 2. Användarnas synpunkter Fördelar: Användningen av molnet accelererar och utvecklingen av nya applikationer likaså SaaS-applikationer erbjuder ofta enkla funktioner, mer användarcentrerade och kan förbättra den totala produktiviteten Molnet ger nya möjligheter och ger en mycket hög tillgänglighet till applikationer (på jobbet, hemma, distansarbete, etc...) Molnet ger också en snabbare migrering av arbetsstation eftersom användaren arbetsmiljön lagras på leverantörens plattform Molnet används för att hantera dataåterställning och användare har inte ansvar för säkerhetskopiering och komplicerade förfaranden för att återställa sina data

39 A. BESLUTSFATTANDE 2. Användarnas synpunkter: Nackdelar: I allmänhet, användare är inte helt säker på vad som gäller runt datasekretess Applikationer missköter offline världen av Internet Molnet kan också orsaka berövande arbetsstationer för användarna. Den sociala risken i samband med omvandlingen är en av de viktigaste punkterna i förändring i omfattningen av IT-verksamheten [5]

40 A. BESLUTSFATTANDE 3. IT-specialist synvinkel: Fördelar: The Cloud leder systematiskt till mer smidighet, för förvaltning samt produktion. Den kan användas för att ge snabbare maskiner, utvecklingsmiljöer / test / recept... Det gör det också möjligt att ställa in lättare overflow scenarier eller behandling av den höga konsumtioner av sådana resurser, tack vare sin egenskaper I molnet kan IT-specialister fokusera på informationsteknik av verksamheten på bekostnad av datorhantering.

41 A. BESLUTSFATTANDE 3. IT-specialist synvinkel: Nackdelar: Datavetare kan ha en rädsla för att förlora makt och resurser pga migration. Detta kan också vara synonymt med en minskning av bemanning och budget. Verksamheten kommer därför att frukta för sina jobb Även om de argument som nämns i föregående avsnitt bör vara tillräckligt för att övertyga dem, förblir de skeptiska om säkerhet Ett annat argument som kan tas upp är beroendet till nätet, som vi har sett tidigare

42 A. BESLUTSFATTANDE Sammanfattning av effekter som orsakas av övergången till molnet på de olika enheter (3) Entity Benefits Impacts Required changes Company Refocusing on the core business. Cost reduction Legal issues Risk of rejection by customer / partner Increasing Competence of the Legal Department Users Time to market Usability and scalability Quality of Service accessibility Purchase division OPEX instead of CAPEX Pay As You Go Difficulties in obtaining contact limited Warranties Increasing Competence of Purchase division OPEX: operational expenditures CAPEX: Capital expenditures

43 A. BESLUTSFATTANDE Sammanfattning av effekter som orsakas av övergången till molnet på de olika enheter Entity Benefits Impacts Required changes Responsible for the safety Putting in question the security policy Security policy development Architectural cell Refocusing on urbanization New architectural issues Cloud operators approval Studies Agility Development constraints on PaaS Production Agility Reduction in the intervention spectrum Creating a cloud competence center Cloud operator certification

44 B. FÖRSTUDIE Om beslutet att migrera till molnet är positivt, så bör man göra en förstudie för att undersöka möjligheten att migrera Denna studie måste vara komplett, och måste handla om många överväganden inom olika områden såsom: 1. Valet av molntyp och leverantör 2. Kostnadstudier 3. Uppskattning av fördelar 4. Riskanalys

45 B. FÖRSTUDIE 1. Val av molntyp och leverantör: Det första steget i denna studie, innan kostnader, risker och fördelar, är att välja en typ av migration och leverantör av molntjänster Migrera till en SaaS-lösning är bara möjlig om det redan finns en liknande produkt till den ursprungliga. Det är bara en migrering av användningen av produkten Valet mellan IaaS och PaaS bör baseras på företagens behov och egenskaper hos de två typerna av moln, som beskrivs i den första delen. Det bör noteras att även om PaaS ökar i popularitet, är IaaS fortfarande den vanligaste lösningen i dag

46 B. FÖRSTUDIE 1. Val av molntyp och leverantör: Sedan är det frågan om att välja ett privat moln, offentligt eller en hybrid Huvudfrågan och vägledande är val av ägande och datasäkerhet När dessa två alternativ är gjorda, återstår det att välja en molnleverantör som erbjuder ett tillräckligt utbud. Kunden bör dock vara noga med vissa kriterier vid val av leverantör

47 B. FÖRSTUDIE 1. Val av molntyp och leverantör: Urvalskriterier: Potential för utveckling (hårdvara, internationell, vision för framtiden), för att säkerställa hållbarheten i applikationen Interoperabilitet av sin plattform, och risken för inlåsning och inte tillhörande kompatibilitet Dess säkerhetscertifieringar av informationssystem till exempel - och fysiska certifiering av sitt datacenter. Certifiering av processer (inklusive incidenthantering och återställning) är ett måste Det måste kunna garanteras att hitta sömlös dataplats samt deras flöden Beroende på kritiska data kan det vara bra att välja en leverantör som kan vara värd för data utanför USA, Patriot Act bemyndiga regeringen för att få tillgång Om dessa kritiska punkter iakttas, är valet naturligt enligt prissättning, anseende och tillförlitligheten hos de tjänster som erbjuds med projektkraven

48 B. FÖRSTUDIE Följande klassificering anpassad från [6] är ett exempel på hjälp för valet av leverantör efter typ av moln, och sedan efter funktion: SaaS Provider Hosted Desktop EnTrustIT Naastar ThinkGrid Finance,HR, PayRoll and ERP Agresso NetSuite Sage Online 50 SAP Business by desugn Workday Online Communications and Collaborations Adobe Acrobat Connect BaseCamp Cisco WebEx Google Apps Huddle IBM Lotus Live Microsoft BPOS Zoho Sales and CRM Oracle Siebel On Demand SalesForce.com SugarCRM Zoho PaaS Provider Business user Platforms Caspio Intuit QuickBase Wolf frameworks Zoho Creator Developper Platforms Bungee Connect Google AppEngine Microsoft Windows Azure Best of Both worlds Force.com LongJump

49 B. FÖRSTUDIE Följande exempel avser IaaS och privata moln: IaaS Provider Storage Amazon S3 GoGrid Microsoft SkyDrive Mozy Rackspace Virtual Machines Amazon EC2 Flexiscale GoGrid Joyent Rackspace Compute Grid Amazon Elastic MapReduce CycleCloud CloudEra Terracotta Data Grid IBM extreme scale GigaSpaces XAP Oracle Cogerence Virtual Private Cloud Amazon VPC BT VDC OpSource Cloud Private Cloud Vendors Eucalyptus IBM Platform Rackspace Unisys Univa UD VMWare vsphere Open source Enomaly Open Nebula Reservoir Nimbus

50 2. Kostnadsstudier: B. FÖRSTUDIE Omedelbart efter valet kommer studiet av kostnaderna för migreringsprojektet Denna viktiga punkt är tyvärr svårt att uppskatta, eftersom det inte finns någon standard beräkningsmetod vid denna tid [3] Detta är lätt förklaras med aktuell erfarenhet av sådana projekt, samt deras specificitet och heterogenitet I själva verket, migrationsprojekt varierar kraftigt beroende på de komponenter som måste migreras, arkitekturer, teknik, målen för migration, osv... Detta gör det svårt att göra empiriska kostnadsberäkningar, baserat på liknande projekt

51 B. FÖRSTUDIE 2. Kostnadsstudier: Kostnaderna kan delas upp i 2 delar [3].Den första, och den i särklass största, handlar om kostnader för migrationen i sig. T ex: Förstudien Konsulter Utbildning av tekniker och dataingenjörer Utbildning av potentiella interna användare av plattformen PoC (proof of concept) Utvecklingen av särskilda bindande komponenter Re-engineering av applikationer eller åtminstone en del av dess komponenter Utveckling av ytterligare funktioner för att dra nytta av molnet Utebliven vinst som genereras av investeringar i migreringsprojektet Alternativkostnad om projektet misslyckas

52 B. PRELIMINARY STUDY 2. Kostnadsstudier: Återkommande utgifter läggs till dessa kostnader när lösningen är installerad, nämligen infrastrukturkostnader, underhåll och support I huvudsak kommer dessa kostnader att vara mycket lägre i molnet än i en lokalt hostad lösning [7] En kvalitativ vetenskaplig studie har visat att applikationer i molnet istället för i ett datacenter innebär en besparing på 37% av infrastrukturkostnader för ett företag [3] En djup föregående analys bör dock göras för att uppskatta den förväntade avkastningen på investeringen av lösningen

53 B. FÖRSTUDIE 3. Uppskattade fördelar: För att beräkna ROI, måste du kunna uppskatta de fördelar som lösningen genererar Flera axlar som hjälper denna beräkning har föreslagits av yrkesverksamma, såsom "10 Laws of Cloudonomics" [8]. De flesta av dessa kriterier har redan behandlats i den här kursen (se "Varför migrera till molnet?") Om vi använder dessa typer av axlar, då blir det lättare att beräkna vilka fördelar molnet skulle ge oss, beroende av den ursprungliga applikation

54 B. FÖRSTUDIE Figuren nedan beskriver konstruktionen av ROI för Cloud Computing med hjälp av nyckeltal (KPI) och mätmetoder [18] Det skulle vara intressant att lägga åtgärder som rör upplevelsen av webbklienten. Dessa åtgärder kan ange om kunderna hade positiva erfarenheter, och om SaaS-baserade applikationer har svarat på deras förväntningar

55 4. Riskanalys: B. FÖRSTUDIE Under denna förstudie är det också nödvändigt att utvärdera ordentligt riskerna i samband med hela projektet, både vad gäller svårighetsgrad och sannolikhet Den här övningen är ibland beskrivs i litteraturen som den svåraste utmaningen i projektet Riskerna kan indelas i två huvudkategorier: allmänna risker och risker relaterade till säkerhet [9] (se kapitel riskerar analys)

56 B. FÖRSTUDIE 4. Riskanalys: De allmänna riskerna inkluderar: Oväntade prestandaproblem Diskontinuitetema inne i tjänsten kommer att påverka verksamheten Effektiviteten i återställning; dålig uppskattning av omfattningen av särskilda händelser och annan omstrukturering av applikation, som kan resultrera i ökade kostnader Problemen med efterlevnad av standarder och styrning Licensfrågor Data belägenhet, ägandeförhållanden och förändringar i lagar som påverkar dem Bristande efterlevnad av SLA klausuler av leverantören Grad av interoperabilitet av plattformen Bristen på förståelse avkomplexiteten i en migreringsprojekttill molnet kan leda till ett misslyckande

57 B. FÖRSTUDIE 4. Riskanalys: Till de allmänna riskerna hör också: Förlust av förtroende för aktieägare eller affärsdivision i bolaget i händelse av projektets misslyckande eller en risk som inte behärskar; övervärderingen av fördelarna med lösningen; bristande på efterlevnad av lösningen med initiala förväntningar som orealistiska förväntningar eller tekniska problem som involverade en minskning av antalet funktioner; motståndet hos medlemmar av organisationen till förändringar som orsakas av clous (t.ex. rädsla för att bli avvisade efter övergången). Denna långa lista är tyvärr inte uttömmande och vi måste också se på de risker som rör säkerhet. Detta diskuteras i del 1 i modul 3.

58 B. FÖRSTUDIE 4. Riskanalys: Risker relaterade till säkerhet har identifierats och beskrivs i en särskild konferens 2009, CSA (Cloud Security Alliance) [10] Organisationer som vill lansera ett migreringsprojekt begränsas av ett antal internationella lagar och standarder, till exempel skyldigheten att upprätthålla loggar liksom rätten att få tillgång till detaljerad dokumentation, vilket inte är fallet nu Dessutom, inte ens om möjligheten för dataförlust redovisas i molnmiljöer, är robusthet av system för att förhindra detta ännu inte helt bevisat Enligt samma papper, vissa viktiga aspekter av sårbarhetshantering och incidenthantering ännu måste stödjas i huvudsak av leverantörer och behöver påvisas

59 C. DESIGN OCH PLANERING Detta steg innebär detaljerad planering och utformning av målmiljö (minne, CPU, diskutrymme) Det ingår att göra arkitektoniska beslut och dimensionera utrustning efter att ha studerat användares användningsmönster av programvara Detta steg beskrivs ofta i industriella metoder, även om de har lite med varandra att göra, förmodligen på grund av den särskilda karaktären hos plattformar. Men inom akademisk forskning, fann vi mycket få arbeten hänförliga till detta

60 C. DESIGN OCH PLANERING Denna del är indelad i fyra faser: 1. Skapa ett beroendeträd och en klassificering 2. Identifiera bra "kandidater" för molnet 3. Kartläggning 4. Skapa en roadmap

61 C. DESIGN OCH PLANERING 1. Skapa ett beroendeträd och en klassificering: De mest informativa metoder i denna fråga, såsom den i Amazon Web Services [7], rekommenderar Till att börja med en grundlig genomgång av logiska konstruktioner av företagsapplikationer, Och rangordna applikationerna enligt deras beroenden, risker och säkerhetskrav och efterlevnad.

62 C. DESIGN OCH PLANERING 1. Skapa ett beroendeträd och en klassificering: Åtgärder som måste genomföras: Identifiera tillämpningar och deras beroende av andra komponenter och tjänster Skapa ett beroende träd som belyser de olika delarna av applikationer och deras beroenden Skapa ett kalkylblad som listar alla program och beroenden eller helt enkelt göra ett beroende träd på en whiteboard som visar de olika samtrafiknivåer av komponenterna. Detta system bör ge en tydlig bild av applikationer. Följande bild visar ett exempel på en beroendeträdet [7]

63 C. DESIGN OCH PLANERING 1. Skapa ett beroendeträd och en klassificering: I detta skede har vi möjlighet att klassificera applikationer i olika kategorier: Applikationer med stark eller svag koppling Känsliga / hemliga applikationer, Offentliga eller privata uppgifter... CRM Customer Relationship Management DB Database OLAP OnLine Analytical Processing LDAP Lightweight Directory Access Protocol ERP Enterprise Resource Planning BIDW Business Intelligence and Data Warehousing Dependancy tree [7]

64 C.DESIGN OCH PLANERING 2. Identifiera lämpliga kandidater för molnet Det är då lämpligt att undersöka stigande och fallande beroenden av varje applikationför att avgöra vilken som kan flyttas till molnet snabbt I de flesta fall, de bästa kandidaterna för molnet är tjänster eller komponenter som har ett minimum av beroenden. Man kan också söka vilka applikationer som är underutnyttjadeoch som har ett omedelbart behov av skalbarhet och har brist på kapacitet, program som har arkitektonisk flexibilitet, etc. Vi får inte prioritera tillämpningar som kräver specialutrustning för att fungera (t.ex. stordator eller specialiserad kryptering hårdvara)

65 C. DESIGN OCH PLANERING 2. Identifiera lämpliga kandidater för molnet Följande figur [7] illustrerar detta steg. Detta exempel visar ett urval av applikationer med minst antal beroenden med andra program.

66 C. DESIGN OCH PLANERING 3. Kartläggning Även om det sällan nämns, verkar kartläggning vara en god praxis. Att inrätta en cloud computing-plattform genom att anpassa befintlig programvara, bör en tidig studie genomföras för att kartlägga IS och identifiera länkar mellan servrar, back-officeprogram, applikationer Front Office, graden av datasekretess, program på datorer och deras användning av användarna.

67 3. Kartläggning C. DESIGN OCH PLANERING Real time can be eligible should be studied bit eligible can be eligible Confidentialit y can be eligible should be studied bit eligible can be eligible Management can be eligible should be studied bit eligible can be eligible Integration to the IS Standard functionalities Physical resources Kartläggning innefattar följande steg [9]: Eligibility to cloud: categorization of applications adapted from [20] Efter att ha definierat vad som ska migreras och vad som kommer att förbli lokalt, är det möjligt att definiera meddelandeformat mellan program, och förutsäga utvecklingen av översättare. Du måste då kartlägga de olika miljöerna och deras interaktioner, och sedan organisera beroenden.

68 C. DESIGN OCH PLANERING 4. Skapa en roadmap De tidigare stegen tillåtet oss att ha en uppfattning om hur vi ska prioritera migrationen, uppskatta den ansträngning som krävs för att migrera, kan förutsäga engångskostnader och bedöma tidsplanen Lösningarna kan anses avgöra hur cloud computing-plattform måste byggas kommer att realiseras av en migreringplan för molnet På industrisidan, en majoritet av företagen och molnleverantörer hoppa över detta steg och går snabbt till nästa fas i byggandet av ett pilotprojekt eftersom det ger en bättre förståelse av de tekniker och verktyg Akademiska metoder rekommenderar att planera i detalj [12]

69 D. PILOTPROJEKT Börjar med en pilotversion innehållande lite data för att generera en proof of concept "Proof of Concept". Att genomföra förändringar som krävs i applikationer för att uppnå målen vid flytt till molnet när det gäller tekniska specifikationer. Det är därför en experimentell fas, och de olika målen är [5]: Utvärdera mervärdet av den nya lösningen, Så småningom bekanta användare med nya lösningar, Identifiera ändringar av användningsområden som kommer att bli följden. Föreställ dig från denna erfarenhet, att den övergångsstrategi, det vill säga, är det bästa sättet att flytta från den nuvarande situationen till målet

70 D. PILOTPROJEKT Detta proof of concept är bara en liten del av migreringsprojektet som möjligen kan testa kritisk funktionalitet av applikationen i molne. Då kan vi kontrollera den tekniska genomförbarheten av migrationen. Det är inte att förbereda hela migrationsprocessen [5]. I allmänhet är det bäst att börja med till exempel en liten databas (eller datamängd) [7], efter att ha tagit säkerhetsföreskrifterna. Då kan vi genomföra migreringen till slutet och lämna systemet till test.

71 D. PILOTPROJEKT The SaaS Pilot: Denna typ av piloten är mycket enkel att implementera, eftersom utbyggnaden är helt klar i molnet operatören. Vi köper bara en nyttjanderätt till en liten tid. Piloten påverkar inte IS i verksamheten: det handlar endast om en pilot programvara och få en uppfattning av de föreslagna funktioner. I fallet med en ny applikation, är påverkan på IS helt noll och det är möjligt att genomföra piloten utan inblandning av ISD. Men när försöket är att ersätta en befintlig applikation, är det nödvändigt att behålla två operativsystem parallellt under den tid piloten pågår. Det måste verkligen hålla reversibilitet, ha möjligheten att gå tillbaka till det gamla systemet för användarna om experimentet går fel [4].

72 D. PILOTPROJEKT The SaaS pilot: I allmänhet, kommer vi att ha tre faser för att slutföra pilotprojektet: Fas 1: motivera valet av en SaaS pilot. Till exempel, om syftet är att minska kostnaderna och öka effektiviteten i kommersiella tillämpningar, krävs valet av en programvara för pilotprojekt som en tjänst (SaaS). Fas 2: Utvärdera prioritetsgraden av mjukvara som tjänst i molnet och bedöm fint och snabbt SaaS-leverantörer att motivera skälen till att välja den typen av piloten. Fas 3: Starta pilotprojekt och analysera resultaten av experimentet i molnet. Dessa resultat kommer att användas för att upprätta en säker omvandling plan.

73 D. PILOTPROJEKT The IaaS pilot: Denna typ av pilot är också enkel att implementera. På samma sätt kan vi bara köper rätten att använda molnleverantör. Detta är en teknisk pilot som endast omfattar anställda i ISD. Det tillåter förfining av [4]: förstå kostnadsmodellen kunskap om plattformen: system för snabb mastering, driftsättning, tiden för en ny applikation, etc. kännedom om särdragen i molnet: Nätverk latency frågor, faktiska tillgänglighet, etc.

74 D. PILOTPROJEKT The PaaS pilot: Detta är den mest komplicerade av de tre. Det behöver verklig design och arkitekturstrategi. Det är lämpligt att fokusera på en liten del av en applikation, för att inte använda allt för många resurser i piloten. Riskerna och målen är i stort sett densamma som för SaaS Pilot.

75 D. PILOTPROJEKT Det finns ingen absolut regel för att definiera den tid pilotprojektet tar; det kan variera från två veckor till två månader eller så. I motsats till mottagna idéer, varaktighet för pilotprojektet beror mycket mer på systemgränsen (applikationens storlek, antal personer som är inblandade i projektet) än storleken på organisationen. Pilotanvändare i sig reduceras till en delmängd som sällan överstiger tjugo personer. Valet av dessa människor är mycket viktig. För att hantera ett framgångsrikt projekt, måste de representerar alla olika roller.

76 D. PILOTPROJEKT Criteria Description Functionality This criterion designates all the criteria and sub-criteria related In order to carry to the out set an assessment of functionalities. of theideally, pilot, we themust minimum definecoverage a set ofin criteria and sub-criteria terms of functional weighted requirements by their importance, is the set thenof tofeatures use them of tothe evaluate the solution based on user feedback. Here is a possible classification [5]. existing solution. All the functionalities that are missing or new elements that appear will be elements used to reduce or enhance the assessment. Each of the elements translated into sub-criteria must be weighted by importance and relevance. Usability This criterion concerns human factors such as ergonomics or quality of the documentation. The majority of user feedback focuses on ergonomics.

77 D. PILOTPROJEKT Criteria Reliability Performance Description This criterion essentially covers the concepts of reliability and availability This criterion includes all criteria and sub-criteria such as response time and resource consumption. The evaluation of the solution with these criteria is rather the responsibility of the directors. It is indeed to assess the size of the network bandwidth constraints, the storage space constraints, the contributions in terms of archiving, etc Sustainability This criteria includes criteria such as adaptability, maintainability, interoperability and portability.

78 D. PILOTPROJEKT Som visas i fas 1 (beslutsfattande), rekommenderas det i allmänhet att konsolidera resultaten i ett diagram (t.ex. radar) för att få en bättre visualisering av resultat och optimera jämförelsen mellan lösningar

79 D. PILOTPROJEKT Olika typer av resultat med enkla kriterier: I det följande ger vi ett exempel på en analys. De klassificeringskriterier är 1 till 4 (1: icke relevant, 2 låg 3: tillräcklig, 4 mer än nog) Global Assessment Sub Criteria The proposed operating system Only windows or only linux At least a windows or a linux, possibly Redhat, or the possibility to use its own image Several operating systems and the possibility to use its own image.

80 D. PILOTPROJEKT Olika typer av resultat med enkla kriterier: I det följande ger vi ett exempel på en analys. De klassificeringskriterier är 1 till 4 (1: icke relevant, 2 låg 3: tillräcklig, 4 mer än nog) Global Assessment Sub Criteria Ease of migration of application and development environment Hard to find information for migration and for environments Documented migration Eclipse installed or possibility to add Compatibilities Java Java, Ruby, Mobile & Web, several tools, but they must be installed Documented migration Many development tools Java, Ruby, Mobile & Web, several tools, but ready to use

81 D. PILOTPROJEKT Resultat av säkerhetskriterier: Global Assessment Sub Criteria Network The presence of firewalls 2 + secure access to network Virtualization some VM Many possibilities for VM. Control of the virtual network environment. Creating sub networks and isolation 3+ corrective measures 3+ Redundant infrastructure components

82 D. PILOTPROJEKT Resultat av säkerhetskriterier: Global Assessment Sub Criteria Location of the servers Offer of Hosting without choice 2+ choice of the server among those proposed. 3+ Hybrid ( with accommodation) and possible Private Data privacy easier Backups and restores ISO Certification good encryption Data access and environment Access via command line Web identity + password and controlling access rights 3+ encrypted password

83 D. PILOTPROJEKT Resultat av säkerhetskriterier: Global Assessment Sub criterion Administration console Difficult to use Accessible via the Internet and quite intuitive Reporting tools Easy access to logs Effective global visualization tools Very easy Warning tools or messaging (real time)

84 D. PILOTPROJEKT Resultat av säkerhetskriterier Global Assessment Sub criterion Documentation Nonexistent online documentation Complete documentation Complete documentation for each product forum Ease to contact the provider Existing support. Active community Online Telephone support with indicative time waiting Many media. Quick Reply

85 D. PILOTPROJEKT Sammanfattande tabell för resultaten: Bland erbjudanden som de undersökta leverantörerna erbjöd, kan vi dra följande sammanfattande tabell. Provider 1 Provider 2 Provider 3 Provider 4 Provider 5 Provider 6 Provider 7 Provider 8 Provider 9 Ease of integration 3,0 2,3 3,0 3,0 3,7 3,7 3,0 3,3 3,0 OS Ease of migration of applications / development environment Compatibilités Security 3,2 2,4 3,2 3,0 3,0 1,2 1,0 3,4 3,0 Réseau (firewall ) Virtualization (isolation ) Server Localization (internal or external cloud, France abroad) Data protection (encryption... ) Data Access and environments Ease of use 2,8 1,5 3,8 2,8 3,5 2,8 2,8 3,3 2,8 Administration console Reporting tools (presence of historical quality of logs, easy access to logs... ) Documentation quality Ease to reach the provider

86 D. PILOTPROJEKT Resultat som radar: Resultaten kan ges i form av radar såsom Amazon Web Services [21], som erbjuder IaaS erbjudande till kunderna genom enkla och begripliga webbgränssnitt (AWS Marketplace). Kunden väljer en infrastruktur och väljer specifikationerna för virtuella maskiner installerade på infrastrukturen (OS, verktyg, programvaror,...). Studien i [21] visar genom den erhållna radar, ett antal egenskaper prestanda för att etablera en fungerande virtuell maskin), servicekvalitet, etc...)

87 D. PILOTPROJEKT Exempel på resultat som tillhandahålls som radar :

88 E. MIGRERING Migreringsfasen i sig är en relativt enkel del om de tidigare stegen har utförts på allvar. Denna uppgift består sig av flera faser [4]: 1. Säkerställa ägande och hantering av plattformen och lägga till nya konton för användare 2. Inledande installation 3. Dataöverföring och migration 4. Migrera applikationer och tester 5. Avsluta den ursprungliga tjänsten 6. Utbildning och användarstöd

89 E. MIGRERING 1. Behärska plattformen och lägga till nya konton för användare Efter avslutade förhandlingar och formalisering av kontrakt med molnlösningsleverantör, får IT-avdelningen de uppgifter som behövs för att komma åt administrationskonsolen på plattformen Nu ska de vara bekanta med de funktioner som erbjuds av denna konsol Då måste vi börja med att lägga till användare och tilldela dem rättigheter på plattformen Observera att detta är egentligen inte nödvändigt när det gäller övergången till SaaS eller PaaS, få administratörskonton är nödvändiga när det gäller IaaS

90 E. MIGRERING 1. Behärska plattformen och lägga till nya konton för användare Det finns två sätt att utföra detta: manuell hantering av konton eller automatisk hantering. 1.1 Manuell hantering Det kan vara enkelt men långtråkig. Det är bättre lämpat för plattformar med ett mindre antal konton (högst 50). I detta sammanhang skapar administratören nya konton med identiska referenser till dem som redan används i verksamheten. Användare kan eller inte kan ändra sina lösenord. Om, på grund av företagets säkerhetspolicy, lösenord skall bytas regelbundet, användare måste manuellt göra denna förändring på sina SaaS / PaaS lösenord.

91 E. MIGRERING 1. Behärska plattformen och lägga till nya konton för användare 1.2 Automatisk hantering För större organisationer, är det rekommenderat att välja automatisk kontohantering, som har skapats från bolagets initiala informationssystem. För att göra detta, ISD kommer att använda APIs som tillhandahålls av molnleverantör som kommer att hantera de olika processerna i ett automatiserat sätt. Vid lanseringen av plattformen eller ankomsten av en ny medarbetare, kommer kontona att skapas och extraheras direkt från företag. Uppdatera lösenord kommer också att ske genom en synkronisering med företagskatalogen utan behov av ingripande av administratören eller användaren. När en anställd slutar och därmed försvinner från katalogen hos företaget, kommer dess molnkonto också att tas bort. Det är då nödvändigt att garantera säkerheten för kanalen och det protokoll som används för överföring av känslig information såsom lösenord. SSL, säkerhet, föredras i allmänhet.

92 E. MIGRERING 1. Behärska plattformen och lägga till nya konton för användare: Komplexiteten och längden på denna fas beror i hög grad på företagets storlek, men även på den valda arkitekturen, i de fall där flera moln är sammankopplade. Av säkerhetsskäl och identitetsfederation, är det starkt rekommenderat att konton lagras lokalt i det som återstår av bolagets IS. Molnoperatören delegera sedan autentisering till identiteten tjänst IS, Identity Provider.

93 2. Inledande installation: E. MIGRERING När du väl skapat användarkonton, är det några steg som behövs innan du kan migrera själva applikationen. Den första och mest uppenbara är att välja från en katalog av virtuella maskiner som ska användas när det gäller IaaS, eller val av tekniska tjänster för användning i PaaS. Dessa val har redan angetts i konstruktionsfasen, och är nu verklighet tack vare administrationskonsolen av plattformen och konfigurationerna som erbjuds.

94 E. MIGRERING 2. Inledande instrallation: Sedan utför vi fastställandet av domännamn och DNSapplikationer. Det är viktigt att använda företagets domännamn för att ge enhetlighet till applikationsportföljen. Till exempel kommer det att komma åt e-post från adressen Slutligen parameter av API: er som är laddade för att samla in spår av användarens åtgärder rekommenderas för övervakningsändamål, även obligatoriska i olika jurisdiktioner.

95 E. MIGRERING 3. Dataöverföring och migration: Vissa program behöver data för att börja. Av detta skäl, och för att testa applikationer så snart de migrerar, är det starkt rekommenderat av olika molnleverantörer liksom vetenskapliga publikationer att börja migrera data först.

96 E. MIGRERING 3. Dataöverföring och migration: Det är nödvändigt att förstå behoven hos applikationen och de olika lagringslösningar som föreslagits av leverantören. Övergången till molnet kan då också vara en möjlighet att förbättra skalbarheten i lagring. Om detta är ett av de argument som stödde beslutet att migrera till molnet, kommer det att vara relevant: att studera skalbara databaser eller att flytta till en NoSQL databasen om inget erbjudande är lämpligt.

97 E. MIGRERING 3. Dataöverföring och migration: Lagret för dataåtkomst bör sedan anpassas och vissa bibliotek måste ersättas. Dessa förändringar är ofta nödvändiga, tjänsteleverantören har inte alltid den använda databasen från början. Men även om dessa förändringar inte är nödvändiga eller är minimala, kan det vara mycket fördelaktigt att omvandla allt data / tillgång till applikationsdata för att göra det mesta av fördelarna med molnet i form av prestanda och skalbarhet.

98 E. MIGRERING 3. Dataöverföring och migration: Det är också möjligt att utveckla en middleware för att översätta sina ursprungliga applikationerom till rätt format för den nya databasen Några av dessa middleware finns redan [13], och i hög grad underlätta databasen förändring, vilket minimerar ändringar i applikation Det kan noteras att om dessa verktyg kan spara tid, finns det ibland mycket tunga testfaserna som blir nödvändiga och upphäver de fördelar som uppnås. Detta kan bero på kvaliteten av översättningen I likhet med förvaltningen av användarkonton, finns det två sätt att hantera överföringen av data i fall där endast en applikation migreras och IT avdelningen fortfarande är central, åtminstone för en tid antingen från fall till fall hanteras användaren manuellt eller automatiskt