Cloud lessons learned

Transcriptie

1 Cloud lessons learned Voor providers en consumers, voor een betere rijkscloud VS KIXS J.C. Stroosnijder

2 Agenda 1) Korte herhaling van wat cloud termen 2) Mijn ervaringen als provider 3) Lessons learned voor de consumers 4) Ideeën voor de rijkscloud 5) Cloud Mythes (als de tijd het toelaat) 2

3 1) Korte herhaling van cloud termen 3

4 Cloud varianten De basics: Private cloud in eigendom van de organisatie zelf Community cloud in samenwerking met gelijksoortige organisaties Public cloud alles buiten de deur, voor meerdere klanten Hybrid cloud een mengvorm van private, community en/of public Private cloud varianten Beheerd door klant zelf Op eigen locatie Private cloud Op locatie van derde Hosted private cloud Beheerd door derde Managedprivate cloud Outsourcedprivate cloud 4

5 Wie doet wat? Ik wil diensten! Ik controleer of alles goed gaat! Cloud services Ik lever diensten Cloud computing Service management hoe maak ik diensten van de techniek? Ik bemiddel tussen klant en leverancier en zorg voor integratie Ik verzorg de verbindingen 5

6 Meerdere soorten consumers(nist) 6

7 Inzoomen op consumer en provider Meerdere consumers en meerdere providers Soort dienst provider consumer IaaS PaaS SaaS Levert basic infrastructuur diensten (compute, storage, netwerk, OS) Levert een runtimeomgeving voor software(webserver, database, etc) Levert een werkende services (mail, CRM, opslagdienst, etc..) Veelal een technische beheer afdeling of ontwikkelaar Software ontwikkelaars eindgebruikers 7

8 Verdeling verantwoordelijkheden 8

9 2) Ervaring als provider 9

10 Stukje geschiedenis 2005: begonnen met servervirtualisatie 2008: VMware labmanager 2009: VMware lifecycle manager 2010: eucalyptus (open source, EC2) 2011: V-commander(embotics) 2012: vcloud director (VMware) 2013: Cloudstack (citrix) 2014: openstack en cloudforms(redhat) 2014: vcloud Automation Center (VMware) 2015: openstack & CEPH 10

11 Van virtualisatie naar cloud Virtualisatie is geïntroduceerd om druk op de datacenters te verlichten (rackspace, stroom, koeling). Organisatie en beheerprocessen zijn daarbij nauwelijks veranderd na 10 jaar. Deployment nog grotendeels handwerk. Backup en disaster recovery nog ouderwets. Introductie van cloud verliep daardoor stroef: Technisch lastig Grote impact op de organisatie Past totaal niet in de (oude) processen 11

12 Stand van zaken Virtualisatie gaat nog wel enigszins vooruit (oasap virtueel) Cloud komt echter nog niet uit het lab. Belangrijkste beperkingen: Te weinig mensen bezig met nieuwe ontwikkelingen Organisatie is er totaal niet klaar voor Rollen van consumer en provider verweven 12

13 Waar doet het pijn? Huidige processen zijn ongeschikt voor cloud. Gericht op een desk-to-desk procesgang Self-service is vaak niet mogelijk Techniek is te koop Maar cloudgaat NIET over hardware. Het gaat over diensten. Onder de motorkap gaat het meer over software en de integratie (automation& orchestration) van allerlei componenten. Dit is complex, tijdrovend en de kans bestaat dat de lat te hoog wordt gelegd. Kijk daar mee uit! Waarschijnlijk de belangrijkste factor: Afdelingen moeten samen werken of misschien wel samenvoegen. Andere afdelingen moeten uit elkaar om de rollen van provider en consumer scherp te krijgen. Mensen zijn bang voor hun baan. Mensen kunnen/willen niet veranderen: we doen dit al jaren zo Nieuwe/andere skills nodig: Focus op automatisering-van-deautomatisering 13

14 Tja 14

15 Het probleem binnen de organisatie IT beheer instandhouding oud ontwikkeling nieuw 15

16 Lessons learned als provider Splitsen van de rol van provider en consumeris zeer wenselijk (voorkomen belangenverstrengeling). Voldoende ruimte (tijd, geld, mensen) om cloudte ontwikkelen is essentieel. Realitycheck: wat een bedrijf zoals Google doet met duizenden ontwikkelaars, doen wij als kleine interne IT provider nooit na! Zoek daarom samenwerking waar mogelijk: Binnen de overheid. Met de markt vooral met kleine innovatieve partijen! Maak justenoughcloud en groei door al naar gelang de behoefte van de consumers. 16

17 3) De consumers 17

18 Verschillende type consumers Volgens NIST: IaaS consumers PaaS consumers SaaS consumers Daarbinnen zijn een paar stereotypes te herkennen: De gespleten persoonlijkheid De smart buyers De outsourcers of cloud sourcers 18

19 De gespleten persoonlijkheid De meeste cloudconsumerswaren ooit een providers; Deze providers zijn bezig met automatisering van hun virtualisatie dienst; Dit noemen ze voor het gemak cloud; Dit leveren ze voornamelijk aan zichzelf en soms ook aan anderen 19

20 De smart buyers Kennen hun sterke en zwakke kanten. Ze doen zelf waar ze goed in zijn of waar ze geen geschikte marktpartij voor kunnen vinden. Ze laten de rest door een ander doen. Ze evalueren hun keuzes regelmatig. 20

21 De outsourcers Hebben focus op hun primaire taken. ICT is geen primaire taak, eerder een kostenpost. Besteden daarom zo veel mogelijk uit. Gebruiken cloudals een vorm van outsourcing (cloud sourcing). Veelal op basis van SaaS diensten. Men wil alle IT (kennis en middelen) buiten de deur zetten. 21

22 Voor en nadelen Type consumer voordelen nadelen Gespleten persoonlijkheden Ze kennen hun klant goed (zijn ze zelf!) Smart buyers Heel bewust met cloud bezig cloudsourcers Focus op primaire processen, niet op IT Niet echt cloud Kans op belangenverstren geling,zeker als ze extern leveren Vergt veel inspanning om de leveranciers te selecteren (broker functie!) Risico dat ze met de verkeerde partij in zee gaan 22

23 Vragen aan de gespleten persoonlijkheden Ben je in je eentje wel efficiënt genoeg? Kan je niet beter samenwerken of zaken uit handen geven? Hoe kan je aan jezelf leveren en tegelijkertijd ook diensten aan anderen aanbieden, zonder de belangen van je eigen organisatie of die van je klanten tekort te doen? 23

24 Vragen aan de smart buyers Wat doe je zelf, wat doe je niet zelf? Hoe ga je om met meerdere cloud leveranciers? Op basis van welke criteria kies je ervoor om iets zelf te doen of buiten de deur te zetten? 24

25 Vragen aan de cloudsourcers Hoe selecteer je de juiste provider(s) als je zelf bijna geen IT kennis aan boord hebt? Hoe ga je om met bijvoorbeeld identity management? Zet je dat ook buiten de deur? Wie gaat je helpen om verschillende clouddiensten aan elkaar te koppelen? Hoe ga je om met miskopen, oftewel, want is je exit strategie? 25

26 4) Ideeën 26

27 Idee 1: verdeel en heers Capabilities 27

28 Idee 2 28

29 Idee 1 en idee 2 samen 1. De community cloud moeten we samen ontwikkelen binnen de rijksoverheid: Hierbij kunnen we leren van de markt; Wat we hier leren kunnen we gebruiken voor onze private clouds en omgekeerd Focus van de ontwikkeling moet liggen op de nieuwe werklasten: Iets nieuws maken voor de werklasten van het verleden does notcompute stop bij virtualisatie en (lichte) automatisering! Bouw iets nieuws voor de toekomst! Focus hierbij op open standaarden en gebruik zo veel mogelijk open source!

30 Hoe? We richten een cloudcommunity binnen de overheid op. Alle providers binnen de overheid delen hun kennis en ontwikkelen samen aan de rijkscloud. Daar waar kennis ontbreekt, huren we gezamenlijk een marktpartij in. Liefst een kleine partij, die ons echt wil helpen (en daar belang bij heeft). De consumersbinnen de rijksoverheid investeren in deze community. Ze stellen fundingen personeel beschikbaar voor ontwikkeling van nieuwe services. 30

31 Vragen? 31

32 Cloud Quiz (als de tijd het toelaat) 32

33 Cloud mythes(1/5) Een cloud is super hoog beschikbaar Niet waar. Het is geen eigenschap van cloud (zie NIST). In een cloudkan je net als in een normale datacenterinfrastructuur maatregelen nemen om hoge beschikbaarheid vanuit de infrastructuur te garanderen. Deze maatregelen zijn dus nietspecifiek voor cloudbedoeld. Dit moet je er zelf in (laten) bouwen en is in feite optioneel. Deze aanpak is vaak gericht op lokale hoge beschikbaarheid (clustering) gecombineerd met uitwijk in de vorm van een replicatie techniek, veelal op VM niveau. Er zijn veel applicaties die ongeschikt zijn om op een dergelijke hoog beschikbare (cloud) infrastructuur te draaien. Sommige applicaties laten zich niet eenvoudig veiligstellen of uitwijken op VM niveau (oasap, exchange, sharepointen diverse databases). Het is daarom veel beter om de beschikbaarheid in de applicaties in te bouwen (voorbeeld: exchange 2013) en onafhankelijk van de infrastructuur te blijven. 33

34 Cloud mythes (2/5) In een cloudworden servers en applicaties automatisch aangepast (opgeschaald) om te voldoen aan grotere vraag Niet waar. Niets gaat automatisch. Er zijn initiatieven om applicaties actief te monitoren en middels orchestrationtools uit te breiden wanneer een drempelwaarde wordt overschreden, maar dit is maatwerk en zeer complex. Dergelijk maatwerk maakt de omgeving star en slecht aanpasbaar. Je zit vast aan de orchestrationtool en de scripts die erin zijn toegevoegd.(zie knelpunten titaan) De meeste servers kunnen overigens wel online vergroot worden (scale-up), maar de applicaties kunnen hier niet altijd mee omgaan (voorbeeld: SAP moet herstart worden om extra CPU s of memory te gebruiken). Een beter concept zijn scale-out applicaties, die op piek momenten zelf via standaard API s(bijvamazonec2, openstack API s, VMwareVIM) een instanceerbij kunnen starten en na het piek moment weer af kunnen sluiten. 34

35 Cloud mythes (3/5) Een private cloudmaak je zelf en zet je in je eigen datacenter Niet waar. Het kan ook ergens ander staan. Een private cloudkan je natuurlijk zelfstandig maken en in je eigen datacenters draaien, maar net zo goed kan je een marktpartij betrekken bij de opbouw en het beheer van de private cloud. Verder is het ook een optie om de hardware in een extern datacenterte plaatsen. Dit kan bij commerciële providers, maar levert misschien problemen op ivmde beveiliging. De rijks datacenters zijn dan misschien een optie, omdat deze tot en met STG-confi geschikt zijn. Daarnaast is het ook mogelijk om het beheer van de cloudgeheel of gedeeltelijk uit te besteden. Bij een private cloudblijft je wel altijd in-control. Beheer en housingkan dus optioneel bij een externe partij liggen. 35

36 Cloud mythes (4/4) Een cloud zorgt voor minder beheer Deels waar. Er verplaatst werk. Als externe (community of public) cloudservices worden gebruikt dan klopt het deels. Een deel van het IT beheer valt weg. Daarvoor komt een stuk regie terug. Aanname is dat onder de streep de uitkomst positief is. Voor private cloudligt het anders. De IT verdwijnt namelijk niet, maar wordt anders ingericht (meer automatisering). Dit vereist enerzijds andere leverings-en beheer processen, anderzijds vereist het slimmer personeel. Het personeel is immers niet meer een routinematig en reactief een bouwsteen aan het beheren, maar is pro-actief met het geheel bezig (service gericht). Een DEVOPS aanpak ligt hier voor de hand. Dus niet zo zeer minder beheer, maar wel anders! 36

37 Cloud mythes (5/5) Cloud is een technisch feestje Niet waar. Er komt veel meer bij kijken. Cloud raakt alles: people, processen technology. Het zwaartepunt ligt bij peopleen proces. People: service gericht en pro-actief werken, meer skilled personeel (DEVOPS) Processen: meer agile werken, veel meer self-service, alles automatiseren, dus ook leverings processen, zwaar afhankelijk van inkoop processen (voor groei) Technology: dit komt pas als laatste in beeld. Zonder aanpassingen in de organisatie en de processen komt een cloudniet tot zijn recht! 37