API – JanWiersma.com

Where is the open datacenter facility API ?

For some time the Datacenter Pulse top 10 has featured an item called ‘ Converged Infrastructure Intelligence‘. The 2012 presentation mentioned:

Treat the DC infrastructure as an IT system;
– Converge in the infrastructure instrumentation and control systems
– Connect it into the IT systems for ultimate control
Standardize connections and protocols to connect components

With datacenter infrastructure becoming a more complex system and the need for better efficiency within the whole datacenter stack, the need arises to integrate layers of the stack and make them ‘talk’ to each other.

This is shown in the DCP Stack framework with the need for ‘integrated control systems’; going up from the (facility) real-estate layer to the (IT) platform layer.

So if we have the ‘integrated control systems’, what would we be able to do?

We could:

Influence behavior (can’t control what you don’t know); application developers can be given insight on their power usage when they write code for example. This is one of the needed steps for more energy efficient application programming. It will also provide more insight of the complete energy flow and more detailed measurements.
Design for lower level TIER datacenters; when failure is imminent, IT systems can be triggered to move workloads to other datacenter locations. This can be triggered by signals from the facility equipment to the IT systems.
Design close control cooling systems that trigger on real CPU and memory temperature and not on room level temperature sensors. This could eliminate hot spots and focus the cooling energy consumption on the spots where it is really needed. It could even make the cooling system aware of oncoming throttle up from IT systems.
Optimize datacenters for smart grid. The increase of sustainable power sources like wind and solar energy, increases the need for more flexibility in energy consumption. Some may think this is only the case when you introduce onsite sustainable power generation, but the energy market will be affected by the general availability of sustainable power sources also. In the end the ability to be flexible will lead to lower energy prices. Real supply and demand management in the datacenters requires integrated information and control from the facility layers and IT layers of the stack.
…

Gap between IT and facility does not only exists between IT and facility staff but also between their information systems. Closing the gap between people and systems will make the datacenter more efficient, more reliable and opens up a whole new world of possibilities.

This all leads to something that has been on my wish list for a long, long time: the datacenter facility API (Application programming interface)

I’m aware that we have BMS systems supporting open protocols like BACnet, LonWorks and Modbus, and that is great. But they are not ‘IT ready’. I know some BMS systems support integration using XML and SOAP but that is not based on a generic ‘open standard framework’ for datacenter facilities.

So what does this API need to be ?

First it needs to be an ‘open standard’ framework; publicly available and no rights restrictions for the usage of the API framework.

This will avoid vendor lock-in. History has shown us, especially in the area of SCADA and BMS systems, that our vendors come up with many great new proprietary technologies. While I understand that the development of new technology takes time and a great deal of money, locking me in to your specific system is not acceptable anymore.

A vendor proprietary system in the co-lo and wholesale facility will lead to the lock-in of co-lo customers. This is great for the co-lo datacenter owner, but not for its customer. Datacenter owners, operators and users need to be able to move between facilities and systems.

Every vendor that uses the API framework needs to use the same routines, data structures, object classes. Standardized. And yes, I used the word ‘Standardized’. So it’s a framework we all need to agree up on.

These two sentences are the big difference between what is already available and what we actually need. It should not matter if you place your IT systems in your own datacenter or with co-lo provider X, Y, Z. The API will provide the same information structure and layout anywhere…

(While it would be good to have the BMS market disrupted by open source development, having an open standard does not mean all the surrounding software needs to be open source. Open standard does not equal open source and vice versa.)

It needs to be IT ready. An IT application developer needs to be able to talk to the API just like he would to any other IT application API; so no strange facility protocols. Talk IP. Talk SOAP or better: REST. Talk something that is easy to understand and implement for the modern day application developer.

All this openness and ease of use may be scary for vendors and even end users because many SCADA and BMS systems are famous for relying on ‘security through obscurity’. All the facility specific protocols are notoriously hard to understand and program against. So if you don’t want to lose this false sense of security as a vendor; give us a ‘read only’ API. I would be very happy with only this first step…

So what information should this API be able to feed ?

Most information would be nice to have in near real time :

Temperature at rack level
Temperature outside of the building
kWh, but other energy related would be nice at rack level
warnings / alarms at rack and facility level
kWh price (can be pulled from the energy market, but that doesn’t include the full datacenter kWh price (like a PUE markup))

(all if and where applicable and available)

The information owner would need features like access control for rack level information exchange and be able to tweak the real time features; we don’t want to create unmanageable information streams; in security, volume and amount.

So what do you think the API should look like? What information exchange should it provide? And more importantly; who should lead the effort to create the framework? Or… do you believe the Physical Datacenter API framework is already here?

Good API design by Google : http://www.youtube.com/watch?v=heh4OeB9A-c&feature=gv

PAAS & de toekomst van programmeren (3)

In het laatste deel van het drieluik rond PAAS en de toekomst van programmeren enkele afrondende gedachte;

Platform As A Service (PAAS) gaat in de komende periode een belangrijke doorontwikkeling krijgen en daar door een prominentere rol in het cloud portfolio. Zelfs Amazon ziet de kansen op dit deel van de markt en lanceerde deze week de AWS Elastic Beanstalk. Werner Vogels (CTO Amazon) meld in zijn blog:

…developers who do not need control over the whole software stack often use development platforms that help them manage their application development, deployment and monitoring. There are some excellent platforms running on AWS that do precisely this; Ruby on Rails developers have Heroku and Engine Yard, Springsource users have CloudFoundry Drupal developers can use Acquia, and PHP aficionados can sign up for phpfog, just to name a few. These platforms take away much of the "muck" of software development to the extent that most RoR developers these days will choose to run on a platform instead of managing the whole stack themselves.

Gaat IAAS verdwijnen?

Infrastructure As A Service (IAAS) speelt een hele belangrijke rol; het is cruciaal voor een heleboel innovatie op het gebied van PAAS en SAAS. Veel van de huidige startups rond PAAS en SAAS maken gebruik van IAAS oplossingen zoals die van Amazon. Het feit dat deze bedrijven onbeperkte opslag en rekenkracht tot hun beschikking hebben tegen een pay-per-use model levert een belangrijke bijdrage aan hun succes. SAAS oplossingen zoals Dropbox (gebouwd op Amazon S3 storage) en PAAS oplossingen zoals Heroku (ook op Amazon IAAS), hadden bijvoorbeeld grote moeite moeten doen om het benodigde kapitaal bij elkaar te krijgen om hun groei te faciliteren. Denk hierbij aan de CAPEX die nodig is voor hardware en de OPEX voor de tientallen systeembeheerders om dit alles in de lucht te houden.

IAAS zal hierbij voor de eind gebruiker/enterprise IT naar de achtergrond verdwijnen. PAAS en SAAS zijn nu eenmaal de lucratievere modellen voor de CIO.

En SAAS dan?

Zoals eerder beschreven, zullen commodity IT producten zeer geschikt zijn voor Software As A Service. Daarnaast zullen we zien dat een golf aan nieuwe (internet) applicaties, die geleverd worden als SAAS, zullen ontstaan. Dit komt omdat IAAS en PAAS omgevingen ontwikkelaars gereedschap in handen geeft, die ze nog niet eerder hadden. Dit zal leiden tot vele nieuwe innovaties. De aanwezigheid van App Stores, om een applicatie gemakkelijk in te kunnen aan bieden, versterkt dit.

Helemaal geen programmeurs meer?

In de vorige delen werd aangenomen dat de ‘tech-savy’ eind gebruiker met zijn kennis en de nieuwe technologische mogelijkheden, zelf applicaties gaat bouwen met microfunctionaliteit. Dit betekend echter niet dat we geen programmeurs meer nodig hebben. Het werkveld van de huidige programmeurs zal zich wel verleggen.

De leveranciers van PAAS en SAAS omgevingen hebben grote behoefte aan goede programmeurs. Zeker mensen met kennis van Python, Ruby en/of Java worden veel gevraagd door dit soort bedrijven. Deze markt zal dus uitbreiden.

Voor de organisaties waar IT niet de core business is (zoals enterprise IT), zal er in eerste instantie behoefte zijn aan programmeurs voor data ontsluiting. Denk hierbij aan de bouw en onderhoud van API’s. Zeker in de eerst komende jaren zal slechts niet kritische en commodity ICT (&data) naar de public cloud verdwijnen. De bedrijf kritische data zal intern nog ontsloten moeten worden en mogelijk voorzien van een applicatie set. De organisatie zal echter wel eisen van de IT afdeling dat dit gebeurd op een interne cloud omgeving. Daarnaast wil men de mogelijkheid om de applicatie in de toekomst te transporteren naar de (public) cloud. Dit betekend dat nieuwe applicaties dus wel ‘cloud ready’ gebouwd moeten worden.

Binnen enterprise IT zal er daarnaast altijd behoefte zijn aan het in stand houden van legacy omgevingen. Er zijn nog steeds mensen met COBOL bezig en zo zullen er ook nog mensen bezig blijven met interne (legacy) Java en .NET applicaties.

Naar mate er meer mogelijkheden komen voor eind gebruikers om hun eigen (micro)functionaliteit te bouwen, zal de behoefte voor grote interne applicaties afnemen. Daarmee neemt de behoefte aan interne programmeurs ook af. De behoefte aan goede data ontsluiting, via API’s, zal hierbij toenemen. Ook bij de inzet van crowdsourcing voor applicatie bouw, zien we dat de programmeur geen onderdeel meer behoeft te zijn van de organisatie.

Welke skills worden belangrijk voor programmeurs?

Al eerder is aangegeven dat het ontwikkelen van applicaties op een cloud platform iets anders is dan de traditionele IT applicaties. Bij het ontwerpen van een cloud applicatie dient men er rekening mee te houden dat systemen zullen uitvallen in een cloud omgeving. Het ontwerpen rond ‘applicatie redundantie’ is belangrijk. Hierbij werd al eerder opgemerkt: ‘Cloud applications assume failure.’

Het bouwen van cloud applicaties vereist het ontwerpen van stateless applicaties. Zodra er iets niet meer werkt of reageert binnen een cloud omgeving, is het idee dat je deze instance verwijderd (kill) en een nieuwe start. Dat werkt niet als de state ook opgeslagen is binnen deze instance. Ook het concept van een lokale disk is niet aanwezig; er is bijvoorbeeld geen registry. Veel applicatie bouwers hebben vroeger wel geleerd om netjes met ‘state’ om te gaan, maar zijn dit een beetje verleerd omdat de huidige IT dat niet echt afstrafte. Gemakkelijke applicaties zijn vaak stateless. Pas bij de echte interessante applicaties komt een bepaalde mate van state om de hoek kijken. Hier voor zijn in de cloud wel databases en objectstores beschikbaar. Echter de applicatie onderdelen die snel moeten kunnen schalen zoals de web-front-end, moeten stateless zijn.

Daarnaast zijn veel cloud applicaties versplinterd; de applicatie presentatie laag kan bijvoorbeeld op Facebook zijn, de opslag op Amazon S3 en de applicatie logica bij een andere cloud provider. Dit betekend dat er goed nagedacht moet worden over de architectuur, met de nadruk op de schaalbaarheids mogelijkheden die deze platformen bieden.

Voor het vastleggen van de data en state, zijn diverse mogelijkheden in cloud omgevingen die echt anders zijn dan de traditionele IT. Denk hierbij aan de inzet van niet relationele databases. Zowel het Windows Azure platform als de Google App Engine, geven de ontwikkelaar een andere manier om met data om te gaan;

The uses of abstraction and statelessness also have database implications. For example, Azure presents developers with a different perspective on databases than the standard relational model, said Ben
Day, president of Benjamin Day Consulting. The Azure storage engine does not use a standard relational database, so a lot of the stuff you would do if you were developing a standard app using a standard relational database just doesn’t make a lot of sense anymore. An example: the relational database concept of stored procedures, in which query logic is close to the actual data itself. This is no longer applicable in the Azure cloud.

The problem is with Azure is there’s no guarantee that the data that you’re going for lives in any particular location or datacenter or any particular device. You end up writing basically SQL queries against the store because the stored procedures aren’t relevant anymore. Plus, the Azure storage engine is different than the SQL Data Services cloud-based version of SQL Server. As an example, Azure stores a 1MB file as a blob, unlike SQL Server, which stores it in a table.

Bij de Google App Engine, word voor opslag Google’s Big Table gebruikt. Dit is ook geen SQL database. Daarnaast zien we de opkomst van technieken zoals Hadoop voor de verwerking van grote hoeveelheden data.

Daarnaast hebben we de opkomst van diverse nieuwe/andere talen en frameworks. Hierbij zal zullen Java en .NET voorlopig nog niet uitsterven, maar is het wel verstandig voor programmeurs om zich eens te verdiepen in de leidende cloud talen op dit moment.

Op het persoonlijke ontwikkelingslijstje van de programmeur zou dus moeten staan:

Verdiepen in Ruby en/of Python.
Verdiepen in (nieuwe) frameworks i.r.t. cloud (zoals de recente ontwikkelingen rond Springsource).
Verdiepen in API’s (REST, JSON, XML), want dit word je koppelvlak met data uit diverse bronnen.
Verdiepen in andere manieren van data opslag en omgang zoals Hadoop, etc..

Dit alles zou je kunnen starten door eens mee te doen aan lopende prijsvragen voor crowdsource applicatie bouw. Leer je programmeren voor de cloud en misschien hou je er nog een zakcentje aan over 😉

Als ik dit alles zo zie, breken er gouden tijden aan voor programmeurs…

Boek tip: Cloud Application Architectures: Building Applications and Infrastructure in the Cloud (George Reese, 2009)

PAAS & de toekomst van programmeren (2)

PAAS, programmeren en crowdsourcing

Het eerste deel van PAAS & de toekomst van programmeren sloot ik af met het idee dat in de toekomst eindgebruikers (hun) applicaties zouden kunnen schrijven. Als we dit combineren met de technologische mogelijkheden van internet zoals PAAS en wereldwijd bereik van potentiele ontwikkelaars, komen we bij een interessante optie: crowdsourcing.

Conform Wikipedia verstaan we onder crowdsourcing:

…gebruikt om een recente ontwikkeling aan te duiden, waarin organisaties (overheid, bedrijven, instituten) of personen gebruikmaken van een grote groep niet vooraf gespecificeerde individuen (professionals, vrijwilligers, geïnteresseerden) voor consultancy, innovatie, beleidsvorming en onderzoek.

Hierbij is dus het idee om (groepen) mensen aan het werk te zetten om voor jou organisatie applicaties te gaan bouwen. Dit kunnen eigen personeels leden zijn die applicaties bouwen om hun werk beter te kunnen uitvoeren, maar kunnen ook andere mensen zijn. De verleiding tot het bouwen van een applicatie komt vaak in de vorm van een wedstrijd met een (geld) prijs. Daarnaast is het veel deelnemende ontwikkelaars te doen om de eer en de status.

Een aantal ontwikkelingen in de afgelopen jaren maken het bovenstaande echt mogelijk;

Kennis

In 2007 concludeerde de Yankee Group al dat eind gebruikers steeds meer technische kennis bezitten en steeds meer ‘tech-savvy’ worden. Dit beeld werd versterkt met het feit dat steeds meer thuis elektronica zijn intrede deed binnen bedrijven. Dit begon met het zelf mee brengen van een laptop en telefoon/smartphone en de komst van de iPad heeft dit alleen nog maar versterkt. We kunnen niet ontkennen dat generaties die na ons volgen ook vele malen handiger zijn met bijvoorbeeld de PC dan wij zelf.

Platform As A Service

Zoals in het eerste deel vermeld geeft een PAAS omgeving zoals Force.com of Google App Engine, de ontwikkelaar de mogelijkheid om zijn applicatie te bouwen zonder zich druk te maken over de onderliggende technische infrastructuur. Mocht zijn applicatie een succes worden, dan hoeft hij zich ook niet druk te maken over het opschalen van die infrastructuur. Succesvolle diensten kunnen heel snel groeien, denk bijvoorbeeld aan Playfish; Zij bouwde een aantal succesvolle games voor Facebook en iPhone en schoten binnen enkele maanden naar 50 miljoen gebruikers (en werden gekocht voor $300 miljoen door EA). Zonder een flexibel cloud platform was dat niet mogelijk geweest.

Nieuwe programmeer technieken

De manier van applicatie ontwikkeling is veranderd in de afgelopen jaren. Daarnaast zijn er veel tools en frameworks beschikbaar gekomen die het ‘kloppen van code’ makkelijker hebben gemaakt. Er komen ook steeds meer SDK’s beschikbaar die het schrijven van een applicatie voor bijvoorbeeld de iPad makkelijker maken.

(In het vorige deel van de blog is hier voor een deel ook al naar gekeken.)

API’s

API staat voor Application Programming Interface en is een verzameling definities op basis waarvan een computerprogramma kan communiceren met een ander programma of onderdeel. Het vormt zeg maar het onafhankelijke koppelvlak tussen aanbieder en afnemer.

Applicaties zijn leuk, maar het gaat uiteindelijk om de data en informatie die er mee bewerkt, bekeken en geproduceerd kan worden. Als een applicatie ontwikkelaar een applicatie gaat bouwen, dient deze wel te weten op welke manier hij de data kan benaderen en welke opmaak deze data heeft. Hierbij komen API’s in beeld; een API definieert de toegang tot de functionaliteit die er achter de API schuil gaat. De buitenwereld kent geen details van de functionaliteit of implementatie, maar weet dankzij de API wel hoe deze kan worden aangesproken.

Steeds meer organisaties en bedrijven publiceren hun data via een API op internet. Door middel van het combineren van API’s kunnen applicatie bouwers hun applicaties verrijken met deze informatie bronnen. Denk hierbij aan de combinatie van Google Maps en foto’s op Flicker via hun API’s. (Dit worden ook wel Mashups genoemd).

Er zijn inmiddels diverse producten op de markt voor de bouw, publicatie en beheer van API’s. Voorbeeld: Apigee (waar je ook uitgebreide kennis over API’s kunt vinden.)

(O ja, en als je die API(’s) dan gaat bouwen… dan graag een RESTfull API…)

Opensource

Over opensource kunnen we lang discussiëren, maar in een model waarbij crowdsourcing voor applicatie bouw word toegepast word de meeste winst behaald door de applicatie onder een opensource model te ontwikkelen. Het beschikbaar hebben van de broncode, levert inspiratie voor andere ontwikkelaars, levert snellere ontwikkeling door hergebruik van code en veiligere applicaties door dat 10 ontwikkelaars meer zien dan 1.

Uiteraard bestaan hier hele, bijna religieuze, debatten over… maar uiteindelijk past dit gewoon goed bij elkaar. Luister maar naar Simon Wardley. (opensource na +/-20min)

Versie- en broncodebeheer

Goed versie- en broncodebeheer is noodzakelijk voor het beheer en onderhoud van de gebouwde applicatie. Het zorgt voor betere onderlinge samenwerking tussen ontwikkelaars, goede registratie en opvolging van software fouten en betere documentatie. In combinatie met opensource geeft het deelnemers aan een competitie ook de mogelijkheid om code en applicatie delen te hergebruiken en sneller een applicatie te kunnen leveren.

Men kan een eigen systeem selecteren en opzetten of gebruik maken van de vele systemen die op internet al beschikbaar zijn. (Tip: gebruik GitHub… het is 1 van de betere op dit moment… en ja deze draait ook ‘in de cloud’, maar is ook geschikt voor closed-source)

Wedstrijdplatform

Om de competitie voor de applicatie ontwikkeling te houden, dient men een wedstrijdplatform te creëren. Hier bij gaat het in de basis om een systeem waarbij
alle benodigde informatie rond de competitie te vinden is en men zich kan inschrijven. Het is nog beter om dit systeem te verrijken team omgevingen die samenwerking bevorderen en verbeteren en met ranglijsten die het spel en uitdagingselement versterken. Voorbeeld: http://www.challengepost.com/

Laten we na al deze theorie en benodigdheden enkele voorbeelden bekijken van crowdsourcing en app ontwikkeling:

Continue with reading

Cloud computing in 2010.. en door naar 2011

We hebben inmiddels 2010 afgesloten en een start gemaakt met 2011.

Nu zou ik een blog kunnen schrijven met een terugblik en een voorruitblik… maar dat hebben een hele boel Cloud Guru’s al voor mij gedaan in de afgelopen weken. Een greep uit de uitgebrachte blogs:

Terugblik 2010

Top 10 Cloud Computing Services for 2010 – We (ReadWrite) chose our top 10 services based upon what trends bubbled in 2010 and the companies and organizations that responded or even set the tone for the overall market.

2010 Review: Top 10 cloud computing stories – Here Computer Weekly looks back on the top 10 cloud computing stories of the year.

9 Companies That Drove Cloud Computing in ’10 – When market leaders act, or when emerging vendors step up to challenge the status quo, it’s bound to spur reactions, be they mimicry, public outcry, or just plain awe. here are my nine (GigaOm) most-influential infrastructure companies for 2010, with a few links apiece to provide context.

Glazenbol: 2011

A cloudy look forward at 2011 – A bunch of us in the cloud computing business here at CA Technologies put our heads together to see if we could articulate what we thought some of the big trends were going to be in cloud for 2011. It was a long and interesting list, as you might expect.

Cloud Computing: 2011 Predictions – It’s been an incredibly interesting, exciting, and tumultuous year for cloud computing. But, as the saying goes, “you ain’t seen nothin’ yet.” Next year will be one in which the pedal hits the metal, resulting in enormous acceleration for cloud computing. One way to look at it is that next year will see the coming to fruition of a number of trends and initiatives that were launched this year.

Predictions for 2011 in Cloud: Chips, Lawsuits and Acquisitions – It seems like every year since 2008 has been dubbed the “Year of the Cloud,” but I think 2010 was the real deal. Cloud computing, as a delivery model, has matured to a point where we can really see where it’s headed and how it will shape up. Here are my (GigaOm) five predictions for cloud in 2011, with a few links apiece to provide context.

Virtualization and cloud computing predictions for 2011 from leading analysis firms – At the end of every year, industry analysts and reporters are releasing their predictions for the coming 12 months. Jonny Bentwood, Director, Analyst Relations and Strategy at Edelman running the Technobabble 2.0 blog summarized some of these predictions, giving an overview of the different predictions made by the following firms: Gartner, Ovum, CCS Insight, Nucleus Research, HfS, Infotrends, Quocirca, IHS Screen Digest, Forrester, Disruptive Analysis, Tech Market View.

Cloud 2011: The Year of the Network – The pace of innovation in the cloud in the last few years has been astounding. It’s difficult to recognize today’s cloud computing landscape as having any relationship to where it was a year ago. In spite of all the innovation that’s been going on, one area remains in the dark ages—the network. My 2011 prediction is simple: 2011 will be the year of the network in the cloud.

Cloud Predictions For 2011: Gains From Early Experiences Come Alive – what matters as 2010 edges towards a close is what enterprise Infrastructure & Operations (I&O) professionals should be planning for in the coming year. Not all moves that show promise today will result in a sustainable harvest come 12 months, but a few trends are likely to play out. Here are my (Forrester) top expectations

En als laatste uitsmijter:

5 Predictions for APIs in 2011 – As we head into 2011, here are five predictions for what’s next in APIs.

Bij dee vooruitblik naar 2011 ben ik het uiteraard niet met iedere analyst en guru eens 😉 maar we gaan zien wat het jaar gaat brengen…

En nu samen; de opkomst van DevOps..

Met grote interesse volg ik al enige tijd de beweging die DevOps heet in ICT land. Deze interesse komt vooral voort uit mijn ervaring met virtualisatie en de veranderende dynamiek die dit bracht binnen beheer teams.

De meeste organisaties hebben hun beheer teams netjes op geknipt in diverse teams, zeker als het wat grotere IT organisaties zijn. Dit levert voor managers en teamleiders lekker behapbare stukjes op om sturing op te geven. We treffen hier dan Windows beheer teams, Unix beheer teams, Linux teams, Netwerk teams, Storage teams, etc.. aan. Bij voorkeur kruipen de mensen uit die teams bij elkaar op de kamer. De Linux mannen met een grote Tux op de kamer, de Windows mannen met een foto van Bill, de netwerk mannen met lastige tekeningen aan de muur met veel streepjes, blokjes en Cisco logo’s. En vervolgens allemaal de deur dicht. Zodra er een probleem optreed, kijken de mensen in de teams naar hun eigen monitor schermpje; “alle lampjes op groen? Mooi! Bij mij niets aan de hand dus”. Voor de Windows beheerder betekend dit dat zijn verantwoordelijkheid ophoud bij de netwerk poort van zijn server, en voor de netwerk beheerder start hij op de netwerk switch. Lekkere duidelijke verantwoordelijkheden en afbakening zou je denken..

Ik zet bovenstaande een beetje zwart/wit neer, maar dit is wel gedrag wat je terug ziet in veel organisaties. Dit geheel gaat voorbij aan het feit dat ICT als hoofd doel heeft om de bedrijfsprocessen te ondersteunen en verbeteren. Dit doel uit zich vaak in een applicatie. Veel applicaties bestaan uit meerdere lagen en elementen. Bijvoorbeeld een Windows server (web & applicatie), een unix server (database), storage en netwerk. Dit leid tot de volgende situatie:

De applicatie van de klant werkt niet. Hij belt. De helpdesk zet op basis van hun beste analyse het probleem door naar de 2e lijn. De vraag komt bij het Windows beheerteam. Hun conclusie “mijn lampjes zijn groen, dus niet ons probleem”. Zo gaat het probleem langs alle teams en iedereen roept dat er bij hun niets aan de hand is. De storing word afgesloten, maar de klant zit nog steeds met het probleem.

Conclusie: de silo benadering werkt dus niet altijd.

Nu gooien we virtualisatie in deze mix. Wie gaat de hypervisor en omliggende tools en lagen beheren ? Introduceren we weer een ander (nieuw) team ? Borgen we dit binnen bestaande teams ? Uiteraard is dit een beetje afhankelijk van de gebruikte hypervisor, zo weten Windows beheerders van nature iets meer van HyperV en Linux beheerder iets meer van KVM. Een mooie discussie uit het verleden ging over het beheer van de virtuele netwerk switch die door VMWare geïntroduceerd is in hun omgeving. Tot de introductie van de Cisco Nexus 1000v was dit geen Cisco device, waar door bepaalde netwerk beheer teams geen beheer wilde doen op de virtuele switch.

Als er problemen optreden in een virtuele omgeving merk je ook al snel dat je de diverse disciplines bij elkaar nodig hebt. Dit zonder grote ‘hand-overs’ of het ‘over de muur gooien’ van het probleem.

Virtualisatie in generieke zin heeft daarnaast nog iets geïntroduceerd; systemen zijn op een software matige (programmeerbare) manier te configureren en beheren. We betreden een tijd perk waarbij men steeds minder fysieke systemen hoeft te ‘stekkeren’ maar dit steeds vaker via een script of programmeer interface kan doen. Zeker waar deze beweging leid tot een groei (van 10 servers nu naar 100 virtuele servers), is de beheerder er steeds meer bij gebaat om een scriptje te hebben die standaard zaken voor hem automatisch kan afhandelen. De programmeer skills van beheerders worden derhalve ook steeds belangrijker en hun werk wijzigt op dat vlak.

Hierbij raken scripts rond virtualisatie (zeker als je self-provisioning in de mix gooit) opeens netwerk, storage en besturingssysteem.

Als management heeft men deze silo’s vaak gecreëerd door de organisatie zo in te delen. Het effect is ook duidelijk en hier mee zijn we een belangrijk doel van ICT een beetje uit het oog verloren…

Ontwikkelaars v.s. beheer

De dynamiek tussen ontwikkelaars, bouwers (Dev) en beheerders (Ops) is van een hele andere orde; Daar waar (applicatie of infrastructuur) ontwikkelaars gedreven worden door ‘change’ zijn beheerders daar nu juist helemaal niet bij gebaat omdat zij gedreven worden door stabiliteit en het handhaven van status quo. De ontwikkelaar heeft als taak om nieuwe functionaliteit toe te voegen of bestaande te wijzigen, waar de beheerder enkel bestaande services aanpast of verbeterd.

Dit alles levert een muur op tussen ontwikkelaar en beheerder die nog veel hoger is dan de muur tussen de silo’s;

Development builds an application, the new hotness which promises customers all the whizz-bang features and will make the company millions. It is built using cutting edge technology and a brand new platform and it has got to be delivered right now. Development cuts code like crazy and gets the product ready for market ahead of schedule. They throw their masterpiece over the fence to Operations to implement and dash off to the pub for the wrap party.

Operations catches the deployment and is filled with horror. The Operations team summarises their horror and says one or more of:

The wonder application won’t run on our infrastructure because {it’s too old, it doesn’t have capacity, we don’t support that version}

The architecture of the application doesn’t match our { storage, network, deployment, security } model

We weren’t consulted about the { reporting, security, monitoring, backup, provisioning } and it can’t be “productionised”.

(Credit Dev2Ops)

Om dit gat te slechten hebben we o.a. vanuit ITIL en andere methodieken inmiddels complete ‘productie gelijke’ test omgevingen ingericht, acceptatie omgevingen, beheer acceptatie omgevingen en test procedures. Dit om de hand-over maar te borgen tussen de ontwikkelaars (Dev) en de beheerders (Ops). Voor de beheer silo’s kennen we tools als HP OpenView en IBM Tivoli die als een beheer paraplu over de silo’s heen kijkt en de end-to-end keten van een applicatie in de gaten houden.

Het is dus zeker niet allemaal kommer en kwel in de IT1.0 wereld want met wat tools en procedures hebben we een soort samenwerking gevonden. In de wijzigende IT wereld behoeven we niet eens heel ver te kijken om te zien dat dit alles echter niet lang houdbaar is. De invoering van virtualisatie levert al aardige voorbeelden op. Uiteraard allemaal best op te lossen met de huidige manier van denken, maar de vraag is of dat het meest effectief is…

DevOps.

DevOps draait om het voor komen van de boven genoemde problemen door slimmer samen te werken en efficiënter te zijn. Het is een framewerk van ideeën en principes die lijden tot samenwerking, coördinatie en kennis uit wisseling tussen ontwikkelaars en beheerders. In een DevOps omgeving bouwen ontwikkelaars en systeembeheerders gezamenlijk aan processen en tools die hun in staat stelt om beter samen te werken en uiteindelijk het ICT product beter en sneller de deur uit te krijgen.

DevOps gaat ook verder dan alleen de uitrol van software; het draait om een nieuwe manier van denken rond samenwerking en coördinatie tussen de mensen die de software bouwen en zij die het moeten beheren. Zaken als automation, monitoring, capacity planning & performance, backup & recovery, security, networking en provisioning hebben allemaal baat bij het DevOps model door de manier waar op ontwikkel en beheer teams samen om gaan met deze gebieden.

Er is dus geen eenduidige definitie voor DevOps, maar in de basis draait het om cultuur verandering en het afbreken van muren die kwaliteits verlies en doorlooptijd veroorzaken.

Veel gebruikte referentie frameworks binnen DevOps zijn Agile en Scrum. De invoering van dit soort methodes die uit de software hoek komen vereisen ook wel een bepaalde cultuur wijziging; het veelvuldig uit brengen van kleine releases voor software (zoals gepredikt word door deze technieken) levert automatisch spanning op bij de beheerders, die dit moeten ontvangen. Nu infrastructuur ook steeds meer te ‘programmeren’ is (o.a. dankzij virtualisatie), zijn beheerders ook programmeurs. Het schrijven van scripts om zaken te automatiseren is al lang niet vreemd meer voor deze groep ICT-ers. Denk aan perl, bash, python en de opkomst van Windows Powershell. De ontwikkeling van Cloud neemt dit nog een stap verder met zaken als Puppet en Chef die de automatisering van de te beheren omgeving naar een volgend niveau brengen. Hierbij zijn beheerders dus ook gebaat bij de inzet van Agile en Scrum.

Beheerder zullen roepen; en wat moeten we dan met ITIL? ITIL en DevOps (en overigens ook Agile, Scrum en andere LEAN adepten) lijken elkaar af en toe in de weg te zitten. Dat is echter maar gedeeltelijk waar en draait vooral om de manier waarop er met ITIL word omgegaan in de organisatie. Daar over in een later blog meer… of Google eens op DevOps & ITIL..

En dan ?

Nu is het altijd mooi om te zeggen dat we beter willen samen werken, maar hoe doe je dat nou ? Enkele voor beelden en tips:

1. Bekijk samen de non-functionals, waar beheerders vaak mee worstelen;

Security
High availibility
Configuration mngt
Monitoring
…

2. Deel de infrastructuur; door elkaar in de keuken te laten kijken kun je werken aan een beter product. Dit betekend bijvoorbeeld ontwikkelaars (read-only?) toegang te geven tot de monitoring van de productie omgeving. Door gezamenlijk te kunnen kijken wat er gebeurd in de productie omgeving start je de communicatie en conversatie.

3. Werk met hoog frequente, kleine wijzigingen; door het uitvoeren van kleine afgebakende wijzigingen kun je probleem gebieden gemakkelijk identificeren en verlaag je de kans op uitval. Daar naast is het makkelijker communiceren en evalueren door alle betrokken partijen uit ontwikkel en beheer teams. Dit alles forceert een goede samenwerking tussen deze teams.

4. Deel verantwoordelijkheid; het afsluiten van SLA’s en OLA’s met als doel naar elkaar te kunnen wijzen als er iets fout is gegaan is contra productief voor de eind-gebruiker. Die is niet geholpen met de kloof tussen ontwikkelaar en beheer en de onderlinge beheer silo’s. Alleen als je de verantwoordelijkheid voor de programmeer code van de applicatie en het uiteindelijke beheer deelt met elkaar kom je tot een voor de klant productieve oplossing.

5. Wissel mensen uit; (zoals bij punt 2) laat een ontwikkelaar eens mee lopen met een beheerder en andersom.

Dit zijn slechts enkele handreikingen en voorbeelden. Er zijn diverse blogs die hier uitgebreid op in gaan. Daarnaast zijn er (steeds meer) bijeenkomsten waar in andere vertellen hoe ze hier handjes en voetjes aan hebben gegeven.

Zie ook:

Voor een uitstekende presentatie zie: Rise of DevOps