Artikel

Achter de wolken schijnt een SOA

Cloud computing biedt vele voordelen. In dit artikel leggen we de focus echter op de integratie-uitdagingen die met cloud computing meekomen. Door het ongecoördineerd afnemen van steeds nieuwe cloud diensten in een organisatie, kan het IT landschap snel complex c.q. mistig worden. De daarmee onstane bewolking, kan goed opgelost worden door gebruik te maken van een SOA-zon. Hierbij worden bewezen SOA principes en concepten toegepast op cloud computing.

Cloud wordt voorgesteld als de nieuwe oplossing. Gooi je IT buiten de deur en je hebt er geen last meer van. Wat dat betreft lijkt het wel op outsourcen. Maar hier en daar krabbelen organisaties terug en nemen IT weer in huis of kiezen voor een meer traditionele outsourcing. Ten tweede zien we bij organisaties die hun IT diensten bij verschillende partijen hebben ondergebracht, dat de regierol een taak is die niet onderschat moet worden.

Met de introductie van cloud computing in een organisatie lijkt de IT eenvoudiger te worden. Immers de IT afdeling hoeft minder te doen, “want dat doen we nu toch buiten de deur”. Er zijn vele voordelen bij het gebruik van cloud; de IT complexiteit wordt extern gemanaged, er wordt een schaalbaarheid geïntroduceerd die voorheen niet beschikbaar was en er is de mogelijkheid van kostenmanagement door een utility pricing model. Maar het is niet allemaal zonneschijn. Er wordt ook complexiteit toegevoegd.

Met het afnemen van een dienst in de cloud wordt vaak meer variëteit geïntroduceerd; de organisatie doet iets nieuws en het oude is niet meteen weg. Ook ontstaan er meer afhankelijkheden; niet alleen vanuit het eigen IT landschap, maar ook door de verschillende leveranciers die vaak ook nog een eigen standaard hanteren. Alle voordelen die cloud computing dan biedt, kunnen dan niet voorkomen dat het IT landschap als resultaat van het toepassen van cloud computing, minder gestandaardiseerd wordt.

In dit artikel gaan we in op de achtergronden van deze complexiteit en hoe die door het toepassen van principes en concepten uit SOA valt te beteugelen.

Silo’s en SOA

Binnen cloud computing zijn een aantal mogelijke diensten af te nemen die variëren van het uitbesteden van een infrastructuur (IAAS – Infrastructure as a Service), tot het uitbesteden van een compleet bedrijfsproces (BPAAS – Business Process as a Service).

In figuur 1 staat aan de linkerkant de organisatie zoals we deze nu vaak aantreffen. De business is verdeeld in een aantal functionele afdelingen. Afdelingen hebben elk een eigen deel van het informatiemanagement budget en sturen daarmee een deel van de IT aan. Er zijn twee belangrijke factoren verantwoordelijk voor het ontstaan van silo’s in organisaties:

  1. Het sturen met deelbudgetten. Hierdoor wordt het budget gebruikt voor het realiseren van oplossingen binnen de afdeling. Afdelingsoverschrijdende projecten zijn veel lastiger, omdat daarvoor een aantal afdelingen samen een deel van hun budget moeten inleveren;
  2. Complexiteit van integraal informatiemanagement. Afspraken maken buiten de afdelingsgrenzen is binnen veel bedrijven lastig omdat er niet op gestuurd wordt of omdat het niet in het takenpakket valt.

Figuur 1: Een nieuw paradigma

In de afgelopen 10 jaar draagt de introductie van service gerichte architecturen (SOA) bij aan het leggen van koppelingen tussen de silo’s en het mogelijk maken van een centrale coördinatie van de benodigde IT infrastructuur.Tegelijkertijd onderkent een SOA de behoefte aan flexibiliteit van de business. De SOA ontwikkeling heeft geleid tot een (her)-definiëring van verschillende functionele lagen in het IT landschap, zoals business applicaties, IT services en datamanagement, zonder dat de koppeling tussen de lagen verdwijnt.

Op dit moment worstelen organisaties zonder een dergelijke architectuur nog met het afbreken van de silo’s en het via SOA in lagen organiseren van hun IT. Indien tegelijkertijd cloud computing wordt geïntroduceerd, blijven de silo’s in stand en wordt het gebrek aan connectiviteit mogelijk zelfs versterkt, doordat er ongecoördineerd diensten uit de cloud in het bedrijf gebruikt gaan worden. In figuur 2 zijn als voorbeeld met stippellijnen een drietal organisatie initiatieven aangegeven; een business afdeling die een bedrijfsproces afneemt in de cloud, een IT Silo die een rekenmodule in de cloud aanroept en ten slotte een database beheer laag die zijn data opslaat op het Microsoft Azure platform. In het ergste geval zijn deze initiatieven ongecoördineerd en heeft de organisatie er drie leveranciersafhankelijkheden bij gekregen.

Figuur 2: Potentiële toename van afhankelijkheden

Omdat de bestaande IT systemen de komende jaren nog niet uitgezet kunnen worden, ontstaat er een hybride situatie met zowel ‘oude’ IT diensten als de nieuwe cloud diensten. De werkelijke situatie uit figuur 2 is een stuk complexer dan de verwachte organisatie in het rechterdeel van figuur 1. De uitdaging is om al die nieuwe diensten met elkaar te integreren. Bestaande IT met de cloud, maar ook cloud met cloud. Bij standaardisatie binnen de eigen organisatie kan de organisatie zelf de standaarden bepalen. Maar bij cloud gaat dat anders; een cloud leverancier bepaalt zijn eigen standaarden en organisaties moeten volgen. Een bedrijf met een cloud leverancier heeft dan al snel een cloud standaard, namelijk de standaard van de cloud leverancier. Het wordt een ander verhaal als er meerdere cloud leveranciers zijn. Binnen een organisatie ontstaan er dan meerdere standaarden met een hogere end-to-end beheerscomplexiteit als gevolg.

Verandering door cloud

In dit artikel behandelen we twee belangrijke vormen van cloud integratie. Enerzijds is er cloud integratie die uitgevoerd wordt door één of meerdere mensen, anderzijds is er integratie tussen applicaties. Beide vormen staan geïllustreerd in figuur 3.

Figuur 3: Twee vormen van cloud integratie

I) Bij integratie via een mens gaat het erom dat er één of meer mensen nodig zijn om diensten uit verschillende clouds met elkaar te integreren. Een specifieke vorm hiervan is “Integration at the glass” (de monitor). Hierbij wordt data vanuit twee verschillende bronnen samengebracht bij de gebruiker op het scherm die er vervolgens voor kan kiezen om data te integreren.

II) Bij applicatie integratie communiceren twee verschillende cloud diensten direct met elkaar. Dit betekent dat er afspraken moeten komen over het protocol en de interface. Hier spelen ook aspecten als vertrouwen en veiligheid een rol. Vertrouw ik cloud dienst A als deze mijn data deelt met cloud dienst B? Bijvoorbeeld om mijn LinkedIn status te twitteren moet ik Twitter toegang geven tot mijn data op LinkedIn. Vetrouw ik Twitter dat het alleen dat twittert wat ik wil en is de verbinding tussen Twitter en LinkedIn veilig?

Integratie via een mens

Integration at the Glass, is een integratie aanpak die geïntroduceerd is door SOA portal developers. De portal applicatie levert hierbij een integratielaag die gebruik maakt van een gezamenlijke database of communicatielaag. In de cloud werkt dit op een vergelijkbare manier. Een gebruiker combineert data vanuit de ene (cloud) applicatie met een andere cloud applicatie. Een voorbeeld hiervan is de integratie tussen de CRM applicatie Salesforce.com en de collaboratie omgeving van Google Docs. Gebruikers van Salesforce kunnen de klantgegevens vanuit de CRM omgeving gebruiken in een document template van Google Docs om gepersonaliseerde brieven te maken en te versturen. Integratie gebeurt hierbij op basis van een API van de cloud provider. De gebruiker van Salesforce.com stuurt data vanuit zijn CRM applicatie naar de webservice van Google. Google Docs weet hierbij niet af van het bestaan van een integratie met CRM data. De koppeling wordt door de gebruiker geïnitieerd en gefaciliteerd door Salesforce.com door middel van de Google Docs API1. Het beheren van dit type integraties kan al snel een nachtmerrie worden voor een developer wanneer er geen heldere afspraken zijn over de beschikbaarheid (en wijzigingen) van de API. Indien je een eigen applicatie hebt geïntegreerd met een cloud applicatie, creëer je een externe afhankelijkheid die gemanaged moet worden om ongewenste verassingen te voorkomen. Je wilt immers niet dat je eigen applicatie stopt op het moment dat een cloud dienst besluit zijn API interface te wijzigen.

Applicatie Integratie

Wanneer een organisatie gebruik maakt van de services van een cloud leverancier wordt er effectief een serviceplatform toegevoegd aan het IT landschap. Het toevoegen van een extra platform introduceert extra complexiteit. Door het gebruik van een architectuur gericht op het managen van dergelijke losse serviceplatformen, een SOA, kunnen we het integratievraagstuk onder controle brengen.

 

SOA aanpak van Atos Origin

In de SOA aanpak2 van Atos Origin wordt het begrip complexiteit gedefinieerd als het product van afhankelijkheid en diversiteit. Door afhankelijkheid en diversiteit te reduceren wordt complexiteit verminderd.


                 Figuur 4: Complexiteit = Afhankelijkheid * Diversiteit

 

Voor de reductie van afhankelijkheden kennen we het principe van loose coupling en het contract based interfaces en voor de reductie van diversiteit kennen we het standaardisatieprincipe.
 

I Loose coupling en contract based principe

  • Alleen expliciete afhankelijkheden, gestructureerd in service contracten (interfaces);
  • Componenten kunnen eenvoudig vervangen worden zolang ze dezelfde interface aanbieden (separation of concerns – black box).

II Standaardisatieprincipe

  • Verminder het aantal componenten (‘ontdubbelen’, rationalisatie);
  • Hergebruik van services.

We kunnen de SOA principes toepassen op cloud integratie. Vanuit een standaardisatie-perspectief is het belangrijk om selectief te zijn bij de keuze van cloud serviceplatforms. Iedere cloud leverancier introduceert zijn eigen manier van beheer en zoals gezegd cloud-met-cloud integratie is nog niet gestandaardiseerd.

Met betrekking tot de reductie van afhankelijkheden kunnen we de bestaande SOA standaarden toepassen. Dat betekent dat we webservices gebruiken voor integratie tussen cloud en interne IT. Daarin is nog een keuze tussen “klassieke” web services gebaseerd op WSDL en SOAP-technologie, en de steeds populairder wordende REST-technologie. Voor het managen van de kwaliteit van de afhankelijkheid, vereist cloud ontwikkeling een defensieve programmeerstijl. Omdat service beschikbaarheid niet gegarandeerd is, zullen applicaties die gebruik maken van die services rekening moeten houden met (tijdelijke) non-beschikbaarheid. Een applicatie kan zijn afhankelijkheden beheersen door tijdelijk gegevens te cachen of uit te wijken naar een vergelijkbare service.

Naast deze twee principes, reductie van afhankelijkheid en standaardisatie, is er een concept dat we uit de SOA wereld mee kunnen nemen; het denken in communicatie-bussen. Het begrip enterprise service bus is te vertalen naar de cloud. Voorbeelden zijn de Cloud Orchestration Bus (van Atos Origin) of een internet service bus (zoals geïntroduceerd door Microsoft3).

Figuur 5: Introductie van een cloud bus

Tijdens een recent research project heeft Atos Origin onderzoek gedaan naar de haalbaarheid van een enterprise service bus op mondiale schaal voor het koppelen van cloud services. Tijdens dit onderzoek is vast komen te staan dat de technologie van een SOA in staat is applicaties in verschillende cloud omgevingen aan elkaar te koppelen. Deze koppeling is bovendien geschikt om de continuïteit van het bedrijfsproces te waarborgen. Deze proof of concept heeft verder inzicht gegeven op welke wijze een koppeling geconstrueerd moet worden met in het achterhoofd maximale security, managebility en continuïteit. Hierin is aangetoond dat met REST technologie flexibeler te koppelen valt vergeleken met WSDL/SOAP, maar dat REST nog wel meer belemmeringen kent bij het koppelen met diensten achter een firewall.

In de proof of concept is een private cloud service gekoppeld aan een public cloud service op basis van Google App Engine. Door deze koppeling tot stand te brengen op basis van een service bus die geschikt is voor business transacties en die zelf geïmplementeerd is als een webservice zijn goede resultaten geboekt. Het blijkt mogelijk om transacties te beginnen in een private cloud, de resultaten via de Cloud Orchestration Bus te sturen aan een applicatie op de Google Apps Engine en deze vervolgens opdracht te geven om de transactierapportage terug te sturen aan de private cloud. Tevens is het mogelijk om gedurende het proces een externe webservice aan te spreken.

De Cloud Orchestration Bus is ook ingezet om te bekijken of een bedrijfsproces in zijn geheel over te zetten is van een cloud naar een andere cloud; bijvoorbeeld om continuïteit te garanderen. Ook dit is aangetoond als een werkbaar scenario. Tijdens de proof of concept is ook onderzocht op welke wijze gebruik gemaakt kan worden van closed source middleware. Traditionele middleware veronderstelt veel programmeerwerk en aanpassingen in de verschillende koppelvlakken. Door gebruik te maken van open standaarden zoals REST kunnen we met behulp van de closed source middleware vergelijkbare resultaten boeken. Closed source heeft als nadeel dat je afhankelijk bent van de koppelmogelijkheden die door de leveranciers worden ingebouwd. De Cloud Orchestration Bus kent de mogelijkheid om koppelingen toe te voegen op basis van klant-eigen applicaties.

Door alle cloud diensten te ontsluiten op een centrale plaats, een communicatiebus, wordt de complexiteit verminderd. Hergebruik van cloud diensten door verschillende afdelingen wordt eenvoudiger. Standaardisatie op de afname van diensten is eenvoudiger geworden.

De Cloud verlaten

Het instappen in een cloud omgeving en deze integreren met je eigen omgeving is de ene kant van het verhaal. Een ander aspect, welke niet vergeten mag worden, is het maken van heldere afspraken over het verlaten van de cloud dienst. Indien de stap richting cloud niet bevalt of er ontstaat onenigheid met de cloud leverancier, dan wil je dat er een duidelijke procedure is om data veilig te stellen. Afspraken waaraan je moet denken zijn de mogelijkheden (en tools) die de cloud leverancier biedt om je data (en logs) uit de cloud te verplaatsen naar een andere locatie. Welke kosten en welke tijd spanning is dan nodig. Daarbij wil je vastleggen wanneer de cloud leverancier zelf de data zal verwijderen na het opzeggen van het contract. Dit zijn aspecten waar elke klant aan moet denken voordat er gestart wordt met een cloud dienst. Bij vele cloud providers is hiervoor namelijk nog weinig tot niets geregeld, wat tot problemen kan leiden wanneer bedrijven hun contract met een cloud dienst opzeggen. Een voorbeeld hoe het wel kan is Google. Google heeft voor deze aspecten een apart organisatie onderdeel gestart, het Data Liberation Front4. Zij hebben als doelstelling om zorg te dragen dat klanten net zo eenvoudig data uit Google kunnen halen als data in Google kunnen plaatsen.

Conclusie

Hoewel outsourcing en cloud computing op elkaar lijken zijn er ook verschillen. Denk hierbij aan het bij cloud computing meer dwingend opleggen van standaarden, flexibeler kostenmodel, maar ook aan het defensievere programmeermodel voor applicaties in de cloud.

Hergebruik van principes en concepten uit SOA is in cloud computing goed mogelijk. Om de IT simpel te houden, moet er goed nagedacht worden over welke diensten in huis gehouden moeten worden en welke diensten in de cloud afgenomen gaan worden. Het is daarbij belangrijk je variatie in leveranciers en diensten te beperken. Beperk je verder tot het gebruik van open standaarden bij de integratie van cloud diensten.

Een goede governance op organisatorische en technische aspecten helpt daarbij de complexiteit te beheersen. Een cloud orchestration bus geeft inzicht in de afhankelijkheden van diverse cloud diensten en kan de end-to-end integratie van verschillende cloud diensten managen.

Categorie:   
Auteur(s)
afbeelding van ronaldstreekstra
Ronald Streekstra
Atos Origin - Enterprise Architect

Ronald Streekstra werkt ruim 13 jaar voor Atos Origin. Hij is werkzaam als enterprise architect, doceert aan de Atos Enterprise Architecture Academy en blogged op http://www.atosoriginblog.nl.

afbeelding van paulalbadajelgersma
Paul Albada Jelgersma
Atos Origin - Director Portfolio Management

Paul Albada Jelgersma is Director Portfolio Management bij Atos Origin; Daarnaast is hij is track leader van het onderwerp cloud computing in de Atos Origin Scientific Community.

afbeelding van richardvandelft
Richard van Delft
Atos Origin - ECM Consultant

Richard van Delft is werkzaam als ECM Consultant bij Atos Origin. Het laatste jaar vooral gericht op Collaboration oplossingen in de cloud, met als speerpunt hierbij Google Apps.

Nieuwe reactie inzenden

De inhoud van dit veld is privé en zal niet openbaar worden gemaakt.
Indien het niet lukt om een reactie te plaatsen, stuur dan uw reactie naar redactie@xr-magazine.nl.
Alle inzendingen dienen correct, professioneel en beschaafd te zijn. IP-adressen worden gelogd, maar niet gepubliceerd. De redactie van XR Magazine behoudt zich het recht voor om anonieme reacties (niet op naam) of zonder geldig e-mailadres, te verwijderen zonder kennisgeving. Ook reacties waarin commerciële uitingen worden gedaan en/of commerciële producten en diensten worden aangeboden worden door de redactie verwijderd of ontdaan van commerciële uitingen zonder kennisgeving.