Openheid in software en architecturen is een grote zegen voor gebruikers, beheerders en budgethouders. Deze waarheid is zo erkend dat veel leveranciers `open' als een soort mantra gebruiken, alhoewel ze dat vaak helemaal niet zijn – enkele uitzonderingen daargelaten. Dit gaat nergens meer op dan bij cloud computing.
Het hebben van een open architectuur en een open aanpak is bij het opzetten en het bouwen van een cloudoplossing van groot belang. Alleen met een open cloud kunnen it-organisaties verschillende infrastructuren beheren door ze samen te brengen onder dezelfde cloudarchitectuur. In tegenstelling tot het creëren van cloudsilo's of het weer opnieuw opbouwen van it-structuren, biedt een open cloud voordelen voor de gehele it-infrastructuur, waaronder grotere efficientie, flexibiliteit en controle over de technologie roadmap. Bovendien hebben organisaties zo de toekomst van hun it in eigen hand.
Maar wat betekent `open' in de context van cloud? Het begint en eindigt zeker niet met de onderwerping van een standaard format of met de acceptatie door partners van specifieke technologieplatformen. Als we kijken naar een open cloud bezit hij in ieder geval de volgende kenmerken:
– Is open source. Hierdoor hebben gebruikers controle over hun specifieke implementatie en worden ze niet beperkt tot de technologie en business roadmap van een bepaalde leverancier. Ze kunnen clouds bouwen en beheren waardoor ze zelf controle hebben over hun eigen koers evenals inzicht krijgen in de technologie waarop ze hun business baseren. Het biedt de flexibiliteit om workloads naar keuze, inclusief proprietaire, uit te voeren in hun cloud. Dankzij open source is samenwerking met andere communities en bedrijven eveneens mogelijk om innovatie te stimuleren op juist die vlakken die voor die organisatie belangrijk is.
– Heeft een onafhankelijke community. Open source gaat niet alleen over de softwarecode, licenties, hoe het gebruikt en uitgebreid wordt. Minstens zo belangrijk is de community die verbonden is aan de code en hoe het wordt bestuurd. Als men zich hiervan het enorme samenwerkingspotentieel realiseert en de innovatiekracht, dan impliceert dat wel dat men de structuren en organisatie op orde moet hebben om er volledig van te kunnen profiteren.
– Is gebaseerd op open standaarden, of protocollen en formaten die zich ontwikkelen naar standaarden en onafhankelijk zijn van leveranciers en platformen. Standaardisatie in de zin van officiele cloud standaarden met standaard bodies bevindt zich nog in een vroege levensfase. Benaderingen voor interoperabiliteit die niet onder controle staan van leveranciers en die niet verbonden zijn aan specifieke platformen bieden belangrijke flexibiliteit. Hierdoor kan de API specificatie zich verder ontwikkelen zonder beperkingen en dat biedt mogelijkheden om varianten te ontwikkelen die tegemoetkomen aan individuele technische en commerciele wensen en
eisen.
– Biedt eigenaren van intellectuele eigendomsrechten volledige vrijheid om de technologie te gebruiken. De recente geschiedenis heeft herhaaldelijk aangetoond dat er geen garanties zijn dat intellectual properties (IP) toegankelijk blijven voor iedereen. Om erop te kunnen vertrouwen dat je toegang behoudt tot die IP-assets waarvan je hebt besloten afhankelijk van te zijn, moet er toestemming worden gegeven dat die technologie open en toegankelijk blijft voor gebruikers. Zogenoemde 'de facto standaarden' die vaak uitsluitend 'standaarden' zijn bij de gratie van de grote leveranciers, schieten in deze test tekort.
– Kan worden ingezet op een infrastructuur naar keuze. Hybride cloud management moet een extra abstractielaag bieden bovenop virtualisatie, fysieke servers, storage, netwerken en publieke cloud leveranciers. Dit vereist dat cloudbeheer onafhankelijk is van virtualisatie en andere basistechnologieen. Dit is een fundamentele reden dat cloud verschilt van virtualisatiebeheer. Hierdoor zijn hybride clouds mogelijk die fysieke servers, meerdere virtualisatieplatformen en een breed scala van publieke (top) cloud leveranciers overspant.
– Is plugbaar en uitbreidbaar met een open api. Hierdoor kunnen gebruikers functionaliteiten en technologieen toevoegen van een verscheidenheid aan leveranciers en andere bronnen. De api zelf kan niet onder beheer staan van een specifieke leverancier of gebonden zijn aan een specifieke implementatie maar moet onder toezicht staan van een derde partij die bijdragen en uitbreidingen mogelijk maakt op een open en transparante manier. Deltacloud, een api die de verschillen tussen clouds abstraheert, is een goed voorbeeld. Het staat onder toezicht van de Apache Software Foundation en is niet een project dat door Red Hat wordt gecontroleerd of is gebonden aan een bepaalde implementatie van cloud management.
– Maakt overdraagbaarheid naar andere clouds mogelijk. Een cloud benadering die heterogene infrastructuren ondersteunt, impliceert dat investeringen die gedaan zijn in het ontwikkelen van een open cloud overdraagbaar moeten zijn naar andere clouds. Overdraagbaarheid kan op verschillende manieren waaronder programmeertalen en frameworks, gegevens en de applicaties zelf. Als een applicatie voor een cloud wordt ontwikkeld, zou het niet nodig moeten zijn het in een andere taal te herschrijven of andere API's te gebruiken om het ergens anders naar toe te verplaatsen. Bovendien betekent een consistente runtime omgeving binnen verschillende clouds dat nogmaals testen en kwalificeren niet elke keer nodig is als je wilt redeployen.
Een open cloud vereist een breed scala aan attributen om de omslag te maken van compleet gesloten naar helemaal open. Het hebben van een aantal attributen is beter dan helemaal niets. Maar enkel met het volledige gamma kunnen organisaties maximaal profiteren van cloud computing.
Op zich kan dit in de toekomst best een aardig alternatief zijn/worden. Maar is het nadeel van Open Source niet dat er de standaarden nogal eens veranderen en verschillen? En laat nou juist bij Cloud Computing standarisatie een heet hangijzer zijn.
@Ruud
Dit is absoluut geen eigenschap van open source software, net als dit overigens ook geen eigenschap van closed source software is. Door het open source zijn van gebruikte software zullen (verouderde) standaarden juist langer beschikbaar zijn dan dit met gesloten software het geval is. Al is het maar dat de oorspronkelijk gebruikte source code van de software noge beschikbaar is. Hiermee is het mogelijk om ook bijvoorbeeld 20 jaar later nog software te ontwikkelen welke deze oudere standaard kan begrijpen. Natuurlijk, dit gaat niet vanzelf, maar is een stuk efficienter dan het reverse engineeren van een stuk gesloten software, waarvan de leverancier al lang niet meer bestaat. Zoek maar eens naar open source oplossingen welke verouderde bestandsformaten kunnen openen, t.o.v. commercieele oplossingen. Afgaande op mijn eigen ervaring, bereik je meer succes bij open source ‘leveranciers’ (o.a. enthousiastelingen) dan bij partijen voor wie het al lang niet meer kostenefficient is deze ‘vergeelde’ zaken te ondersteunen.
@mgs
Niet mee eens!
Ik kan nog steeds MS-DOS TXT-bestanden openen, en DBF-bestanden gebruiken, hoewel die standaarden al tenminste 25 jaar oud zijn.
Daarentegen sluit Google geregeld applicaties, ongeacht of mensen dat gebruikten als onderdeel van hun proces.
In mijn mening is veel software wat beschikbaar gesteld wordt door ‘enthousiastelingen’ buggy en slecht/niet ondersteund.