Het is tien jaar geleden dat Amazon met zijn Amazon Web Services op de markt kwam. Daarvoor was Amazon toch vooral bekend als online boekenwinkel. Dé vraag is: leeft AWS in België? Het antwoord is: nog niet echt, maar wacht maar.
Het zou een quizvraag kunnen zijn: wie is wereldwijd de snelste groeier in zakelijke technologie? En hebben we het niet over het kleine grut, maar over de grote jongens: bedrijven met meer dan een miljard dollar omzet.
Wie is de grootste groeier in IT?
Het antwoord is voor sommigen misschien verrassend: Amazon. Het bedrijf voert met Amazon Web Services (AWS) de lijst aan van sterke groeiers (zie figuur rechts), samen met Salesforce.com, VMWare, Red Hat en Microsoft. Al groeit Amazon duidelijk wel veel sneller. Bedrijven die krimpen in enterprise IT zijn er overigens ook, met IBM en CA als grootste verliezers.
De impact van Amazon in de wereld van zakelijke it is behoorlijk groot. Het bedrijf voert de markt aan op het vlak van Infrastructure as a Service (IaaS) (zie figuur links) en staat op eenzame hoogte in het Gartner quadrant over IaaS (zie figuur rechts onder).
Het succes van Amazon met AWS is dus duidelijk, maar in Europa is er nog wel een weg af te leggen. Het bedrijf legde zich toch eerst toe op de thuismarkt in de VS en verschoof de laatste jaren de aandacht naar andere (en Europese) markten. De bouw van het Amazon datacenter in Duitsland is daar niet vreemd aan. First we take Manhattan, then we take Berlin.
Waarom blijft opmars van AWS uit in België?
In België is het een ander verhaal. In ons land hinkt Amazon behoorlijk achterop, zeker in vergelijking met Nederland of andere buurlanden. Dat komt enerzijds omdat in ons land geen prioriteit is voor Amazon als bedrijf. Voor de Benelux komt de ondersteuning door een klein team in Nederland. Marketing wordt dan weer vooral vanuit Luxemburg geregeld.
Meer dan in onze buurlanden krijgt Amazon bij ons meer concurrentie van Microsoft Azure, mede omdat Microsoft in de Belgische markt (wel) vrij goed is vertegenwoordigd. Anderzijds ontbreekt in de Belgische markt ook nog de nodige expertise en kennis rond het Amazon-aanbod. Kortom: In Nederland lijkt Amazon de slag om de public cloud dan wel te winnen, in België vooralsnog niet.
Wie gebruikt AWS?
In principe kan iedereen die clouddienst gebruiken, al blijkt dat in de praktijk niet zo. ‘De echte aantrekkingskracht komt bij ons vandaag van de start-ups’, stelt David Temmerman, sales en marketing manager bij Sentia, dat zich richt op managed hosting. ‘De redenen hiervoor liggen voor de hand. Je kan er snel en vrij goedkoop mee aan de slag, en als startend bedrijf kan je je it vlot doen meegroeien met je business’, stelt Temmerman.
In ons land heeft het ook wel navolging bij kmo’s voor hun websites. En anderzijds bij de grotere bedrijven die AWS in eerste instantie willen inschakelen voor hun testomgevingen, en nadien ook voor het overhevelen van hun legacy-omgeving. Maar bij hen moet de echte adoptie nog starten. ‘De interesse is er, en binnen dit en een jaar of twee zie ik nog wel wat grote Belgische bedrijven, of bijvoorbeeld een aantal grootbanken, de overstap maken’, vertelt Temmerman.
AWS als klant gebruiken?
Eigenlijk zijn hiervoor twee hoofdvormen. Enerzijds is de klassieke aanpak via interface. Dit is traditionele ‘pay as you go’-aanpak waarbij u uw spreekwoordelijke Visa-kaart bovenhaalt, meteen inhaakt op het AWS-netwerk en gebruik maakt van de infrastructuur en standaardtoepassingen die het bedrijf biedt.
De tweede aanpak, die meer en meer opkomt, is dat u gebruik maakt van een tussenpersoon. Er bestaan in ons land intussen een aantal in ‘managed AWS’ gespecialiseerde bedrijven. Kleine bedrijven als Skyscrapers, maar ook Cloudar (deel van de Cronos-groep) en dus ook Sentia (onderdeel van de groep met onder andere Combell), dat onlangs een Managed Public Cloud Services-afdeling oprichtte. Hier ligt de focus niet enkel op het IaaS-luik maar ook op PaaS (Platform as a Service). ‘Als je optimaal van de redundantie van AWS gebruik wil maken, moet je ook de code van je applicatie ernaar aanpassen’, oppert Temmerman. ‘En dan kom je als bedrijf al snel bij een managed cloud partij terecht’, beweert hij.
Grote troeven van AWS?
De grote troef zit in de schaalbaarheid van de oplossing. Via AWS kunt u als bedrijf heel snel uw it uitschalen, en dit zowel qua reikwijdte als regio. Vooral op dit vlak van continous deployment en constante integratie, kan AWS voor bedrijven een echte meerwaarde bieden. Met name voor een cio die agile wil en moet zijn, is zoiets een behoorlijke troef. Je kan een kleine workload snel uitbouwen naar iets groots.
Daarnaast is er ook de maturiteit. Microsoft Azure, de grote concurrent die vooral door ontwikkelaars wordt gedragen, is pas echt begonnen in 2010, dus zowat vier jaar later dan AWS. Die voorsprong lijkt Amazon alvast niet echt meer uit handen te hebben gegeven. Het bedrijf is met zijn cloudaanbod ook altijd behoorlijk innovatief geweest. ‘Als je het vergelijkt met de andere public cloud providers loopt Amazon zowat twee à vier jaar voorop’, meent Temmerman.
Nadelen van AWS?
Omdat het zo snel evolueert is het voor bedrijven en hun it-afdeling niet makkelijk om bij te blijven. Bovendien is in ons land vaak niet voldoende AWS-kennis aanwezig. Ander nadeel is dat Amazon standaard zelf geen echte sla’s (service level agreements) voorziet, iets wat tussenpersonen als Sentia wel kunnen bieden.
Een ander element is de zogenaamde ‘vendor lock-in’ of toch op z’n minst de vaststelling dat je als bedrijf je eieren niet in één mand (of cloud) wil leggen. ‘De meeste bedrijven met grote hoeveelheden gegevens om op te slaan en te beheren willen meer dan één service provider om zich toe te kunnen wenden’, oppert cloudexpert Peter Witsenburg. ‘Want wie wil er afhankelijk zijn van slechts één leverancier voor al zijn bedrijfskritische gegevens?’
Kostprijs van AWS?
Misschien nog het minst bekende aspect van AWS is de kostprijs. Of zoals de boutade luidt: de prijs is zeker geen hinderpaal om bij Amazon te starten, maar wordt na verloop van tijd wel een belemmering zodra de boel volop begint te draaien. ‘De perceptie van Amazon is inderdaad dat het goedkoop zou zijn. Wel, dat is het dus zeker niet’, meent David Temmerman. Witsenburg sluit zich hier bij aan: ‘Goede voorbeelden hiervan zijn Apple en Dropbox’, vertelt hij. Beide bedrijven hadden een behoorlijk deel van hun it-infrastructuur op AWS staan, maar komen daarvan terug omdat de kosten hoog begonnen oplopen, weet Witsenburg.
Ook al zijn jouw it-verwachtingen en –noden van een andere orde dan die van Apple of Dropbox, echte koopjes moet u van Amazon dus niet verwachten. Al heeft hen dat niet tegengehouden om internationaal zo sterk te groeien. Nu België nog.
“de prijs is zeker geen hinderpaal om bij Amazon te starten, maar wordt na verloop van tijd wel een belemmering zodra de boel volop begint te draaien. ‘De perceptie van Amazon is inderdaad dat het goedkoop zou zijn. Wel, dat is het dus zeker niet’,”
Dit is pertinente onzin wat alleen maar verspreid word door mensen die daar belang bij hebben. Sterker nog, AWS is veelal veel goedkoper, juist naarmate je het meer gebruikt en als je van te voren resources inkoopt.
Verder maar een raar stukje dit. Eerste gedeelte was informatief en best okee.
Henri,
Kom nu eens met een eerlijke TCO – 5 jaar – over AWS versus willekeurig welke oplossing waarin naast de CapEx de volledige OpEx zit. Ik kan voorrekenen dat het economische break-even point tussen AWS en welke willekeurige oplossing tussen de 2,8 en 3,5 jaar ligt. Het antwoord waarom de AWS acceptatie minder snel gaat bij zuiderburen kun je vinden in de kosten van het netwerk.
Ewout,
Niet alleen betaal je weinig voor de virtuele servers zelf, als je ook stroom, koeling, de beheer kosten meeneemt en de verborgen kosten van personeel…
Daarnaast doe je bepaalde dingen ook anders dan lokaal. Alleen de capaciteit gebruiken die je nodig hebt.
Maar waar het helemaal scheef loopt is het verschil tussen de oester strategie van veel bedrijven (wat? Gebruikers authenticeren over het Internet? NO WAY!) en gewoon diensten afnemen die waarde toevoegen en koppelen aan een centrale IAM die ook over het internet werkt.
Bam, zo kun je miljoenen besparen.
Eerlijkheidshalve zijn er ook scenario’s mogelijk waarin je met AWS de kosten hoger uitkomen, zeker als je migratie erbij optelt en het menselijk falen om je IT mensen mee te krijgen, of halve slagen maken.
In ieder geval word AWS niet *duurder* als je het meer gaat gebruiken. Er zit geen verborgen model in dat de kosten per gebruik oplopen.
TCO, alleen de term is al verwarrend en een oversimplificatie en op zijn best incompleet.
Niettemin wil ik best wel een keer samen met jouw aan een TCO werken. Maar dan wel in op basis van functie, niet van 1 server lokaal versus 1 server in AWS.
PS: En neem dan ook de tooling mee zoals het monitoren van je netwerk, beheren van je netwerk en automatiseren,
Die zaken kosten on-premises altijd een behoorlijk duit….
Henri,
Ik heb het over de TCO van een business workload, een ecosysteem met een lifecycle van 10+ jaar, IdM (niet IAM) is daarin het zoveelste horizontale laagje over deze verticale silo’s:
http://www.x500standard.com/
Ik geef je deze link om twee redenen, als eerste is het allemaal niet zo nieuw als jij denkt en als tweede gaat het niet om het autorisatiemodel op services maar data. Dit alleen maar juridisch oplossen met een databewerkingsovereenkomst zoals Safe Harbor zorgt ervoor dat de parels door anderen uit je oesters gedoken worden. De cloud realiteit is dat dat deze dus hybride is, zeg maar bipolair als het om het licht aanhouden gaat.
En natuurlijk wil ik best een keer een lichtje laten schijnen op de TCO maar ik denk dat ik eerst nog het licht aan moet doen als het om architectuur denken gaat. Van A naar Beter gaat niet om de kleur van het gras bij de buurman maar de lijken die er onder liggen;-)
@Henri
Je gaat eigenlijk niet in op Ewout zijn vraag/opmerkingen – je beperkt je tot statements & argumenten waarop je *verwacht* dat een invulling met AWS goedkoper uitpakt.
Dus nogmaals, kan je laten zien wat er aan CAPEX-en en OPEX-en nodig is om een gegeven organisatie voor een periode van 5 jaar van een functioneel vergelijkbaar IT landschap te voorzien?
Met aan de ene kant een invulling die zoveel mogelijk vanuit AWS geleverd wordt en aan de andere kant een invulling die zoveel mogelijk in eigen beheer is. In beide gevallen inclusief alle benodigde tooling.
De details rondom “gegeven organisatie” en “functioneel vergelijkbaar” mag je van mij vrij kiezen. Zolang maar duidelijk is wat die keuzes zijn (geweest).
Will, elke berekening zonder uitgangspunt slaat nergens op.
Daarnaast reageerde ik op de bewering dat AWS ogenschijnlijk duurder word naarmate je meer ermee gaat doen.
Als je meer resources van on-premises naar AWS brengt zal de rekening zeker oplopen, maar hoe meer resources je afneemt en vooraf afrekent hoe lager de inkoopsprijs. Data AWS uit kost ook geld terwijl on-premises server data verkeer veel goedkoper is.
Er zijn vier situaties waarin het niet goed is om voor AWS te kiezen:
– Als je organisatie en met name IT afdeling er niet klaar voor is, de weerstand er blijft c.q. niet capabel is of zich bedreigd voelt.
– Als de migratie kosten en risico’s van verandering te hoog zijn
– Als de organisatie zo groot en capabel is dat zelf doen een prima optie is.
– Als compliance je tegen houd.
Wat ik vaak zie is dat een organisatie het internet en dus cloud computing als gevaar ziet en daarom in alle keuzes heel sterk voor on-premises kiest, ook door ogenschijnlijke compliance beperkingen (ogenschijnlijk, want er mag veel meer dan men denkt) . Dit brengt veel extra kosten met zich mee en belemmert een organisatie uberhaupt te profiteren van de mogelijkheden.
Een voorbeeld: Wie bieden een digitale leeromgeving aan. Deze is bedoeld “as a service”. Nu wil een organisatie dit on-premises draaien. De omgeving wordt agile gebouwd en heeft 1 keer per week releases. Deze moeten nu handmatig uitgevoerd worden. Maar ook de uptime en performance monitor moet nu on-premises gedraaid worden. Op en neer schalen is ineens niet meer (zo maar) mogelijk en beheer is duur en omslachtig. Ook het maken back-ups en disaster recovery is ineens een ding geworden.
Maar nogmaals, we kunnen hier epistels delen en dat is prima, en AWS kan duurder zijn, maar ik verzet me tegen suggesties dat je ergens in gezogen word en dat je dan ineens de sjaak bent en allemaal verborgen kost krijgt.
Verdiep je erin, speel ermee, bouw iets hybride zodat je een eigen oordeel kunt vellen. Maar ik blijf erbij dat als je de dingen blijft doen zoals je altijd gedaan hebt concurrenten wellicht manieren vinden om goedkoper te opereren of produceren en dat dat een gevaar kan zijn voor jouw voortbestaan als organisatie. Niet omdat AWS zo goed is, maar omdat je als bedrijf altijd bewust moet zijn van veranderingen en wat voor impact deze kunnen hebben op jouw business of die van de concurrenten. Ik ben dus geen onheilsprofeet die roept dat je zonder cloud computing ten dode bent opgeschreven, maar wel dat je als organisatie niet zomaar vast kunt houden aan het verleden en dat je je moet verdiepen in de veranderingen en mogelijkheden.
Een zeer mooi voorbeeld vind ik Microsoft die Mobiel niet aan zag komen omdat ze er zelf al inzaten en dus dachten te weten wat er gaande was. In het begin hadden ze gelijk. Mobiel was allemaal maar primitief en niet optimaal. Maar daarmee begrepen ze niet de impact van de iPhone en moesten ze lachen om zo’n duur ding waarmee je foto’s kon maken. Nouja, de rest is geschiedenis….
@Henri: de eerste keer dat ik iemand zie zeggen :
“Als de organisatie zo groot en capabel is dat zelf doen een prima optie is. ”
Deze optie wordt bij het vurig verdedigen van cloud based oplossingen nog wel eens vergeten.
Beste Henri – Ik ben niet voor of tegen en waardeer je enthousiasme voor AWS e.d.
Je bent vrij in het kiezen van uitgangspunten zolang die maar consistent toegepast worden.
PaVaKe : Thanks.
Ik sta open voor alle opties. Wie weet komt er in de toekomst een soort doos die je ook on-premises neer kan zetten en is de bandbreedte en redudantie zo goed en groot dat je helemaal geen diensten nodig hebt, vind ik het ook best. En bedrijven “moeten” niets en wat ik vaak zie is weerstand om de verkeerde redenen.
Het is allemaal niet zo bijster ingewikkeld zolang je maar bewust bent van wat je doet en open staat voor niet alleen snellere paarden, maar ook snellere auto’s 🙂 En het gevaar dat relatief kleine bedrijven nog wel eens met dingen kunnen komen die een gevaar betekenen voor de grotere organisatie. Vroeger zou ik zeggen dat de bedrijven die complexe medische apparatuur produceren redelijk veilig zitten maar zelfs daar zie je soms ontwikkelingen komen die hoe dan ook impact gaan hebben.
Interessante tijden 🙂
Will, het is heel moeilijk om vergelijkingen “klein” te houden om zo appels met appels te vergelijken en dat is meteen ook de moeilijkheid. Dat 1 ding heel simpel te realiseren is, betekent niet dat alle dingen er omheen zomaar daar in mee kunnen. Vandaar dat hybride nu zo populair is…
Will,
Henri heeft tot op een zekere hoogte gelijk in zijn statements en argumentatie, als je uitgaat van DevOps met duidelijke silo’s (of containers) dan biedt uitbesteding naar AWS voordelen.
De realiteit is echter weerbarstiger als we kijken naar het maatwerk dat na verloop van tijd altijd weer opduikt. Kijkend naar lifecycle van een business service – middels BCG-matrix – is continuïteit, integriteit en beschikbaarheid geen momentopname. Vandaar ook dat we nu veelal hybride cloud oplossingen hebben want de exoneratieclausules bij publieke versies vrijwaren de providers van gevolgschade, niet de business;-)
Opmerking over gegeven organisatie en functioneel vergelijkbaar is in de discussie over de kosten interessant. Het is een gegeven dat als waarde toeneemt en je kosten verlaagd de kwaliteit altijd afneemt. Continuous Service Improvement (CSI) gaat om waardeketens, je kunt de cloud wel vol druppelen met Continuous Delivery van microservices maar dat levert een steeds grotere uitdaging op met de Continuous Integration.
CapEx is eenvoudig, een lineaire afschrijving van de middelen terwijl de Opex meestal om de arbeidskosten gaat. Henri wint de Turing-prijs als hij het incident management (weinig repeterende taken als gevolg van menselijke interrupties) weet te automatiseren. Het enige dat op dit moment geautomatiseerd is het lekken van data;-)
Henri: Beginnende ondernemers worden wel eens gewaarschuwd dat ze niet alles zelf moeten proberen te doen. Cloud kan een mooie oplossing zijn, zeker in het leeromgeving voorbeeld dat je aanhaalde.
Echter, qua kosten kun je altijd nog even proberen het iets langer uit te zingen met je CAPEX investeringen, terwijl Cloud diensten per definitie vast zit aan je maandelijkse OPEX uitgaven.
De formule van Cloud komt bij mij altijd toch een beetje over als een verhaal dat het mooiste is voor de dienstverlener. Die kan mooi proberen bij te schalen naarmate die maar meer klanten krijgt.
Voorts is het on-premise hebben van een IT-er die iets meer weet dan waar de “any key” zit, ook een pluspunt als er iets aan de hand is en beperkt het knullige shadow IT.
Ook moet je kijken naar wat je core business is, een transportbedrijf zal zijn logistieke programmatuur in eigen beheer houden, maar je leeromgeving voorbeeld toepassen om haar chauffeurs/chauffeuses te onderwijzen over vervoer van gevaarlijke stoffen.
Technicus,
Ik snap je redenering en argumenten alleen zijn ze te grote versimpelingen.
Ja, je kan je servers nog een jaartje na de afschrijving laten werken, maar daar zitten in mijn ogen het zwaartepunt van je IT kosten niet. Ook is een dienst als AWS heel anders dan bijvoorbeeld een auto kopen of een auto leasen. Het gaat namelijk niet om die server, of die harde schijf. AWS is ook een framework waar meteen een hele hoop dingen bij zitten. Van monitoring en logging, tot datawarehousing, disaster recovery, redundantie, beschikbaarheid en last but not least: Security.
“een transportbedrijf zal zijn logistieke programmatuur in eigen beheer houden”
Je kunt je programmatuur ook bij AWS gewoon in eigen beheer houden hoor.
Heb je al ervaring met AWS opgedaan?
Het zou wel interessant zijn om te onderzoeken welke relatie er is tussen kosten IT en grootte van de organisatie in relatie tot Cloud. Zou er, zoals in bovenstaande opmerkingen gesuggereerd wordt, een omslagpunt zijn waar je door IT zelf te organiseren uiteindelijk een lagere TCO bereikt? Zou dat anders zijn voor infrastructuur dan voor software services?
En door welke variabelen wordt dat omslagpunt beïnvloedt?
Henri,
De auteur schrijft – niet geheel onterecht – over de misleidende kosten van ‘achter de deur’ oplossingen en uiteindelijk bevestig jij die conclusie door in je reactie (dd. 4 april 10:04) te bekennen dat je de ‘as-a-service’ oplossing gekozen hebt omdat je software eigenlijk slecht te onderhouden is. Misschien wordt het ook voor jouw tijd om naar een andere oplossing te migreren want het draait dus allemaal om die ‘schijf’ waarop de hele software-defined stack staat. Ik kan me niet voorstellen dat er handmatig releases uitgerold worden als deze goed getest zijn. Of zeg ik nu weer iets raars?
Dag Leen,
dat is zeker een interessant en wel met verschillende parameters. En omslagpunt is ook maar een aanname. Een organisatie met een sterke governance en IAM zal wellicht altijd beter uit zijn bij bijvoorbeeld AWS (om het woord cloud te vermijden, niet alles cloud is zomaar goed). Iets wat ook vaak over het hoofd word gezien is de kracht van de API’s, CLI en console van AWS / Azure / GCP. Nu kun je soort van ook je eigen Azure realiseren voor wellicht geclassificeerde data. Als er een omslagpunt is gaat het denk ik om het aantal virtuele servers wat je gebruikt met relatief traditionele storage. Ofwel IT zoals het momenteel ingezet word. Zelf geloof ik sterk in serverless computing en dan is het al snel niet meer interessant of je het zelf doet of niet.
Ewout, welke kosten vind je misleidend? Iedere maand is er een hele duidelijke specificatie. Bij AWS heb je hooguit een onzekerheids factor als er meer gebruikt word dan je verwacht had. Het is echt betalen naar gebruik. Even voor het beeld. Spotify is niet betalen naar gebruik. En jammer dat je dan ook de verkeerde conclusie trekt over dat mijn software slecht te onderhouden is.
Als mijn as a service software on-premises achter allemaal (virtuele) muren en tunnels verborgen zit is het automatisch uitrollen van nieuwe functionaliteit niet mogelijk. Met een token moet worden ingelogd en feitelijk handmatig een update uitgevoerd worden. Ook de mate van support en direct reageren word een stuk lastiger. Wij krijg een automatisch signaal waarneer een gebruiker een fout ervaart of probelemen heeft met instellen van zijn wachtwoord, vanuit een on-premises kluis komen deze signalen niet direct bij ons als dienstverlener.
Die updates zijn dus geen patches maar onderdeel van continuous delivery. Ontwikkelaar ontwikkeld op de ontwikkelomgeving en deployed naar test. Daar worden deels automatische tests uitgevoerd en de functionaliteit getest. Dan gaat deze naar Acceptance en daarna via Jenkins automatisch in de avond naar productie. Op productie worden ook nog tests uitgevoerd zodat een terugrol mogelijk is.
Onze software is dus prima te onderhouden, maar on-premises is in mijn ogen de veel mindere keus.
Henri,
Stellen dat updates geen patches zijn lijkt me een semantische discussie, uiteindelijk lood om oud ijzer als je beheer(s)last er niet minder om is. En aangaande de kluis van on-premises heb je misschien niet direct inbound remote toegang maar dat wil niet zeggen dat er geen ‘call home’ mogelijkheden zijn. Je voorbeelden vindt ik allemaal nog niet echt overtuigend en doen vermoeden dat er nog heel traditioneel gewerkt wordt, misschien is nested virtualisatie iets dat je interesse heeft.
Nested virtualisatie, je bedoelt containers in een virtual server? 🙂
Met updates bedoel ik voornamelijk nieuwe features en mogelijk patches op bugs. Dat lijkt me nu niet echt een semantische discussie.
Henri,
Containers zijn een vorm van virtualisatie die op basis van gedeelde libraries een run-time omgeving leveren. Nested virtualisatie is de ‘matrousjka’ oplossing die de monolitische kernel in een blik stopt om deze vervolgens in een ander blik te stoppen zodat deze op verschillende cloud omgevingen kan draaien. Uiteraard kun je beide combineren, volledige isolatie middels nested virtualisatie met een variabele run-time omgeving die versioning kent als virtuele appliance.
Een nog mooiere oplossing zou het gebruik van nieuwe unikernels zoals Haskell zijn maar ik denk dat er nog teveel historische kosten zitten in oudere framewerken waardoor ontwikkelaars aan hun servers gehecht zijn. Dat laat echter niet onverlet dat de cloud race nog lang niet gelopen is als we kijken wat er onder de motorkap allemaal gebeurt.
Mooie reactie Ewout 🙂 (no pun intended)
In de laatste zin bedoel je wellicht “cloud provider race” ipv cloud race. Of “cloud technology race”
Er is genoeg aan de hand, leuke ontwikkelingen en steeds uitdagender om bij te blijven.
Geen patches dus, maar juist continouos delivering ervan 🙂 op bugs ..
Zoiets als “we zetten u heel even erg lang in de wacht waarna u geholpen wordt door een
goedkope uitzendkracht die net niet zo irritant genoeg weinig weet dat u uw contract gaat opzeggen”. Zelf wil ik gewoon stabiele en functionele software zodat we gezellig naar de matrix reloaded kunnen kijken in onze dockersized horizon app in een linux mint server die als openstack guest draait op ubuntu als KVM guest met zo’n software defined outband iscsi storage backend naar de KVM host. Straks vast weer iemand die vindt dat die patches gebundeld moeten worden tot servicepacks geschikt voor de hyperconverged appliance, omdat zoiets eigenlijk veel beter schaalt naar klantdemands. Das wel weer zo ingewikkeld dat uitbesteden voor de hand gaat liggen, want ieder bedrijf is eigenlijk ook een IT bedrijf, vraag maar aan je CIO die vanwege de IT integratie tegenwoordig niet meer kan zonder business skills.
Dino, ik zou bijna mauwerd zeggen, of Felix! Episch 🙂
De cloud met zijn gevirtualiseerde 8 jaar oude hardware. Heb gisteren toevallig een brakke RHEL kernel in een vmware omgeving mogen aanschouwen, die tenonder ging aan CPU lockup’s toen er wat load op kwam te staan. “Pay for what you use” maar nu in de betekenis, “goedkoop is duurkoop”.