Cloud lessons learned

Cloud lessons learned Voor providers en consumers, voor een betere rijkscloud

VS

KIXS J.C. Stroosnijder

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

Defensie Materieel Organisatie consumers vs providers

1) Korte herhaling van cloud termen

3


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

Op eigen locatie

Op locatie van derde

Beheerd door klant zelf

Private cloud

Hosted private cloud

Beheerd door derde Managed private cloud 4

Outsourced private cloud


Wie doet wat?

Ik wil diensten!

Ik controleer of alles goed gaat!

Cloud services

Service management

hoe maak ik Ik lever diensten

Cloud computing

diensten van de techniek?

Ik bemiddel tussen klant en leverancier en zorg voor integratie

Ik verzorg de verbindingen 5


Meerdere soorten consumers (NIST)

6


Inzoomen op consumer en provider Meerdere consumers en meerdere providers Soort dienst

provider

consumer

IaaS

Levert “basic” infrastructuur diensten (compute, storage, netwerk, OS)

Veelal een technische beheer afdeling of ontwikkelaar

PaaS

Levert een runtime omgeving voor software (webserver, database, etc)

Software ontwikkelaars

SaaS

Levert een werkende services (mail, CRM, opslag dienst, etc..)

eindgebruikers

7


Verdeling verantwoordelijkheden

8


2) Ervaring als provider

9


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


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


Stand van zaken Virtualisatie gaat nog wel enigszins vooruit (oa SAP 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


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… Waarschijnlijk de belangrijkste factor:

• Maar cloud gaat NIET over hardware.

• Afdelingen moeten samen werken of misschien wel samenvoegen.

• Het gaat over diensten. • Onder de motorkap gaat het meer over software en de integratie (automation & orchestration) van allerlei componenten.

• 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…”

• Dit is complex, tijdrovend en de kans bestaat dat de lat te hoog wordt gelegd. Kijk daar mee uit!

13

• Nieuwe/andere skills nodig: Focus op automatisering-van-deautomatisering Defensie Materieel Organisatie consumers vs providers

Tja…

http://en.wikipedia.org/wiki/Grace_Hopper 14


Het probleem binnen de organisatie IT beheer

instandhouding oud ontwikkeling nieuw

15


Lessons learned als provider • Splitsen van de rol van provider en consumer is zeer wenselijk (voorkomen belangenverstrengeling). • Voldoende ruimte (tijd, geld, mensen) om cloud te ontwikkelen is essentieel. • Reality check: 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 “just enough cloud” en groei door al naar gelang de behoefte van de consumers. 16


3) De consumers

17


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


De gespleten persoonlijkheid • De meeste cloud consumers waren 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


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


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

21


Voor en nadelen

22

Type consumer

voordelen

nadelen

Gespleten persoonlijkheden

• Ze kennen hun klant goed (zijn ze zelf!)

• Niet echt cloud • Kans op belangenverstren geling, zeker als ze extern leveren

Smart buyers

• Heel bewust met cloud bezig

• Vergt veel inspanning om de leveranciers te selecteren (broker functie!)

cloudsourcers

• Focus op primaire • Risico dat ze met processen, niet op de verkeerde IT partij in zee gaan Defensie Materieel Organisatie consumers vs providers

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


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


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 cloud diensten aan elkaar te koppelen? • Hoe ga je om met “miskopen”, oftewel, want is je exit strategie?

25


4) Ideeën

26


Capabilities

Idee 1: verdeel en heers

27


Idee 2

28


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.

2. Focus van de ontwikkeling moet liggen op de nieuwe werklasten: •

• • 29

Iets nieuws maken voor de werklasten van het verleden “does not compute” – stop bij virtualisatie en (lichte) automatisering! Bouw iets nieuws voor de toekomst! Focus hierbij op open standaarden en gebruik zo veel mogelijk open source! Defensie Materieel Organisatie consumers vs providers

Hoe? We richten een cloud community 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 consumers binnen de rijksoverheid investeren in deze community. Ze stellen funding en personeel beschikbaar voor ontwikkeling van nieuwe services. 30


Vragen

? 31


Cloud Quiz (als de tijd het toelaat)

32


Cloud mythes (1/5) Een cloud is super hoog beschikbaar Niet waar. Het is geen eigenschap van cloud (zie NIST). In een cloud kan je net als in een normale datacenter infrastructuur maatregelen nemen om hoge beschikbaarheid vanuit de infrastructuur te garanderen. Deze maatregelen zijn dus niet specifiek voor cloud bedoeld. 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 (oa SAP, exchange, sharepoint en 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


Cloud mythes (2/5) In een cloud worden 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 orchestration tools 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 orchestration tool 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 (bijv amazon EC2, openstack API’s, VMware VIM) een instance erbij kunnen starten en na het piek moment weer af kunnen sluiten.

34


Cloud mythes (3/5) Een private cloud maak je zelf en zet je in je eigen datacenter Niet waar. Het kan ook ergens ander staan. Een private cloud kan 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 datacenter te plaatsen. Dit kan bij commerciële providers, maar levert misschien problemen op ivm de 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 cloud geheel of gedeeltelijk uit te besteden. Bij een private cloud blijft je wel altijd in-control. Beheer en housing kan dus optioneel bij een externe partij liggen. 35


Cloud mythes (4/4) Een cloud zorgt voor minder beheer Deels waar. Er verplaatst werk. Als externe (community of public) cloud services 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 cloud ligt 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


Cloud mythes (5/5) Cloud is een technisch feestje Niet waar. Er komt veel meer bij kijken. Cloud raakt alles: people, process en technology. Het zwaartepunt ligt bij people en 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 cloud niet tot zijn recht!

37


Cloud lessons learned

Recommend Documents