AWS Deep Racer, a serious toy to learn Machine Learning

AWS DeepRacer is a 1/18th scaled race car developed by Amazon Web Services (AWS) to bring the complex field of Machine Learning (ML), reserved for Data Scientists in the past, to developers.

DeepRacer service is a platform for developers and enthusiasts alike to get hands-on with reinforcement learning. This is a great starting point for experimenting with different Machine Learning reinforcement models, training them on DeepRacer 3D racing simulator, and deploying these trained models on DeepRacer to get a real world feel.

Many people would think, at first glance, it is a novel toy to play with that after some time will become useless. On the contrary, it is an innovative approach initiated by AWS to fill the gap being left wide due to the lack of Data Scientists. The adoption of Artificial Intelligence technology in a wider commercial domain is suffering, as the cost to hire experts is too high due to the lack of trained human resources. Hence the next best solution is to make the science more accessible by providing tools to the developers. These tools can be used by developers to forecast, improve and effectively integrate with different business models without having an extensive data science background.

Friday Innovation at Oblivion Cloud Control B.V.

Artificial Intelligence, a short introduction

The term Artificial Intelligence (AI) was first coined in 1956 at a Dartmouth College in Hanover, New Hampshire. Artificial Intelligence can be attributed to the branch of computer science focused on enabling digital computers or computer-controlled robots to perform tasks generally associated with intelligent beings. Since its inception in 1956, the field of AI has been progressing over the years. Though it is only in the last 15 years, AI has become popular thanks to the improvements in computers (computing power, GPUs, & storage devices) and its accessibility via cloud-based computing, huge amount of accessible data and the advanced algorithms to train and test these models.

Machine Learning, a subset of AI

Machine Learning (ML) is a subset of much wider field of Artificial Intelligence. Machine Learning at its root is the idea that machines can learn from past data points using analytical models to predict the future behavior of the system for which it is trained. It does this by identifying patterns with minimal human interactions.
Within ML, there is a concept of reinforcement learning which in essence is learning via positive reinforcement. It is the same way you would train your pet, reinforcing good behavior with positive feedback when a certain objective is reached.

Schematic depiction of AI, ML and Deep Learning relationships

Schematic depiction of AI, ML and Deep Learning relationships

The serious objective of the Deepracer

In the case of DeepRacer, the objective is to autonomously drive through the track without deviation and to complete this task in the shortest time possible. The exciting part is that the task of building the model and training it for autonomous driving can be orchestrated from a single AWS service.

The AWS DeepRacer stitches together various AWS services to provide a single point control:

  • ·The reinforcement model is trained in AWS Sagemaker over a simulated race track. The simulated race track has the same dimensions as the track in the real world.

  • This racing simulator is provided by AWS Robomaker.

  • Amazon Kinesis Video stream provides real-time footage of virtual simulation and the effects of positive reinforcement constant.

  • AWS CloudWatch captures the logs with respect to different models being trained and the different metrics a developer want to see.

  • Last but not the least Amazon Simple Storage Service (S3) is where the model is stored, and versioning can be enabled to keep track of various versions of the model.

The DeepRacer can be driven in two configurations:

·      Manual driving mode, where the car can be driven via a computer over local Wifi and can be steered through the AWS DeepRacer control page.

·      And Autonomous driving mode, where a model is trained for a track and then steers DeepRacer around the track. This anticipated service was launched in May 2019 and is available online.

Picture2.png

For the Machine Learning enthusiasts, AWS launched DeepRacer League where the players will race against each other in autonomous driving mode. The team at Oblivion Cloud Control B.V. is very excited to try the trained models against others during the league and learn as we step into the next domain of cloud-based computing with AWS.

Personally, I will be investing my time in making complex reinforcement models and trying to find ways to train and test these models with DeepRacer. On the other hand, it could be very interesting to train a model for obstruction recognition and finding an alternative route around the said obstruction. The possibilities are endless and the future in Machine Learning is exciting.


Mudit Gupta, Cloud System Engineer @ Oblivion Cloud Control B.V.

I am a Machine Learning enthusiast with a background in Aerospace engineering having wide interests in IoT, Data Sciences & Edge computing. Among my hobbies, cooking is at the top followed by gardening. I like to cook Indian, Mediterranean food and share with friends and family.


Automated security en compliance control in de publieke cloud

Het aantal organisaties dat een ‘cloud first’-IT-strategie overweegt of reeds heeft ingezet, stijgt in rap tempo. Het struikelblok dat men over het algemeen als eerste tegenkomt, is het goed neerzetten van security & compliance control in de publieke cloud.

Niet langer een complexe wirwar van meningen omtrent cloud security en monolithische toepassingen, maar door het toepassen van twee zienswijzen kan het onderwerp adequaat en transparant worden toegepast en organisaties naar een hoger niveau van informatiebeveiliging brengen dan gebruikelijk in de traditionele IT.

Het belang van cloud security en voldoen aan compliancy-eisen is evident. De uitdaging ligt in het zorgvuldig en kosteneffectief invullen ervan door organisaties. Hoe ga ik om met kwetsbaarheden binnen mijn applicaties? Hoe houd ik de compliancy status van mijn resources bij? Hoe zorg ik dat al mijn logs veilig zijn opgeslagen en dat ik actie kan ondernemen wanneer dat niet zo is? Hoe verkrijg ik mijn PCI-DSS-certificering binnen de publieke cloud?

Als organisaties net begonnen zijn met het ervaren van alle diensten en mogelijkheden van de publieke cloud kan dit nogal overweldigend overkomen. Hoe zien deze vraagstukken er voor de publieke cloud in zijn geheel uit? Of voor virtuele servers, microservices of zelfs functies? Elke situatie vraagt een andere aanpak en heeft andere eisen. Dus wat is wijsheid?

Security & compliance controls

Een effectieve aanpak is om het gebruik van de mogelijkheden van security & compliance binnen de publieke cloud globaal in twee oplossingsrichtingen te zien.

  • Implementatie en beleid voor het bepalen en inrichten van informatiebeveiligingsbeleid (vooraf)

  • Implementatie en beleid voor de controle en navolging van het toegepaste informatiebeveiligingsbeleid (achteraf)

De concrete implementaties hiervan worden wel ‘preventive’ en ‘detective controls’ genoemd. Preventive controls betreft (het liefst) creëren van geautomatiseerde checks en gestandaardiseerde events (bijvoorbeeld notificaties) om daarmee te voorkomen dat een kwetsbaarheid optreedt. Detective controls zijn eveneens checks en acties. Deze monitoren achteraf of de huidige situatie compliant is aan de eerdere ingerichte checks en acties. Wanneer dat niet het geval is, kan ook hier automatisering aan gekoppeld worden om een actie of event te starten om bijvoorbeeld het opgetreden risico te mitigeren. Een andere vorm van detective controls is het opvragen van compliancy-rapportages van een cloud serviceprovider.

Inrichting en configuratie van deze controls kan op vele manieren. Dus welke diensten en oplossingen zijn er binnen de publieke cloud om de eisen en wensen te realiseren?

De cloud biedt ook de oplossing

De huidige oplossingen rondom security & compliance zijn qua architectuur divers qua aanpak. Als we kijken naar externe oplossingen zijn sommige leveranciers, zoals Trend Micro Deep Security, voorbereid op de karakteristieken van cloud computing (‘pay per use, scalable’). Daarnaast zien we nog veel leveranciers die hun bestaande oplossing(en) in licentievorm en als appliance aanbieden bij cloud serviceproviders. Dezelfde oplossing wordt aangeboden zoals die ook werkzaam was binnen je eigen vertrouwde datacenter. Integratie vindt veelal plaats middels installatie van agents en beperkte toegang tot api’s.

“DE PUBLIEKE CLOUD IS EEN ‘NIET VERTROUWD’ GEHEEL VAN SERVICES GEKOPPELD AAN INTERNET”

De grootste cloud serviceproviders (AWS, Microsoft Azure, Google cloud) bieden eveneens diensten die ondersteunen bij het gewenste niveau van informatiebeveiliging. AWS biedt daarbij een heel portfolio van oplossingen die kunnen helpen bij je doelstellingen. Een service als AWS Config (Rules) bijvoorbeeld checkt de status van je resources binnen AWS en het gebruik. Waar voorheen ‘eyes on screen’ de enige optie was, kan nu het grootste deel van de controles worden overgelaten aan automatisering. Een groot voordeel van het gebruik van cloud-nativediensten is daarbij de toegang tot api’s en documentatie, om integratie van een of meerdere oplossingen mogelijk te maken.

‘Automation, automation, automation’

‘Wat je kunt rationaliseren, kun je automatiseren’ is een adagium dat van toepassing is op de publieke cloud en zeker voor security & compliance. Een IT-landschap is niet een ‘beetje’ compliant of een ‘beetje’ veilig: het resultaat dient binair te worden geïnterpreteerd. Door gebruik te maken van automatisering creëer je een situatie waarbinnen informatiebeveiligingsrisico’s direct kunnen worden opgemerkt en mitigatie zonder tussenkomst van menselijk handelen in gang te zetten is.

Voorbeeld: een preventieve security-maatregel is een complexe password policy op de toegang tot de cloudomgeving. Daarbovenop kan een compliancy control worden ingericht (config rule), die controleert of de password policy conform beleid is. Zodra deze control ‘incompliant’ geeft, kan een geautomatiseerde respons worden gestart die de password policy terugzet naar de oorspronkelijke waarden.

Voordelen security & compliance-automation

Belangrijk is dat organisaties feiten van meningen binnen deze expertise weten te scheiden en als onderdeel opnemen binnen hun nieuwe IT-strategie. Kiezen voor automatisering van security & compliance binnen de publieke cloud kan vervolgens diverse voordelen bieden:

  • Handmatige compliancewerkzaamheden zijn niet langer noodzakelijk. Besparing van arbeidskosten.

  • Een hoger niveau van security & compliancy wordt bereikt, door verregaande automatisering en ‘infra as code’. Voorbeeld is het automatisch benchmarken van door Center of Information Security aangeleverde checks.

  • Het wordt makkelijker, sneller en dus goedkoper om audits te doorlopen en rapportages te verkrijgen over de status van je IT-landschap.

  • Mogelijkheid om versneld en toetsbaar change- en configuratiemanagement uit te voeren (infrastructure as code, versiebeheer).

Afsluitend

Organisaties dienen zich erop in te stellen dat de cloud een ‘niet vertrouwd’ geheel is van services gekoppeld aan internet. De publieke cloud kan anderzijds een stuk veiliger zijn dan je huidige situatie. Beoordeel welke risico’s je wil voorkomen en daarna hoe je zo goed mogelijk op een mogelijk risico kan (techniek) en wil (budget) acteren.

Wanneer het IT-landschap het toelaat, probeer qua inrichting zo dicht mogelijk tegen de cloud serviceprovider aan te zitten. Dit biedt voordelen op het gebied van identity & access management, gedocumenteerde toegang tot api’s en compliancy rapportages. Security & compliance komen zo binnen bereik.

(Dit artikel is eerder verschenen in IT Executive)

Vijf use cases voor VMware Cloud on AWS

VMware Cloud on AWS is alweer een tijdje beschikbaar in de markt en inmiddels zien we interesse ontstaan voor deze propositie. Toch krijgen we regelmatig veel vragen rondom positionering en vooral wanneer VMware Cloud on AWS wel of niet een goede optie is. Daarom, in dit artikel vijf typische usecases wanneer VMware Cloud on AWS het overwegen waard is.

VMware Cloud on AWS is een VMware-propositie waarbij het VMware virtualizatie-platform zoals we dat kennen uit de datacenters draait op fysieke AWS servers. VMware managed het VMware cluster en de interactie met de AWS laag en stuurt uiteindelijk ook de factuur naar de gebruiker. Zoals we weten, is de kernfocus van de dienst het leveren van virtuele servers en dat is nu net iets wat een van de AWS-basisdiensten, AWS EC2, ook is. Bovendien leert een snelle rekensom dat EC2 in veel gevallen goedkoper is dan VMware Cloud on AWS servers. Maar wat is dan de usecase voor VMware Cloud on AWS?

Vijf usecases

#1 Disaster recovery

Een veel toegepaste usecase is disaster recovery. Gezien de VMware Cloud on AWS offering platgezegd een VMware-cluster is in dezelfde virtualisatie technologiestack, is integratie met bestaande VMware-clusters eenvoudig. Typisch voor disaster recovery-scenario’s is dat je minimale en flexibele capaciteit aan de DR-zijde wil en dit is precies wat VMware Cloud on AWS kan bieden. Organisaties die VMware in hun datacenter draaien en de RTO en RPO willen verbeteren of hun DR meer kosteneffectief willen inrichten doen er goed aan eens te kijken naar VMware on AWS.

#2 Cloudtransformatie in stapjes

Als AWS Cloud consultants weten wij als geen ander dat cloudtransformatieprogramma’s voor de meeste organisaties een grote impact hebben. Niet alleen applicaties moeten worden bekeken omtrent hoe deze hoog beschikbaar, secure en effectief op het AWS-cloudplatform gaan landen, maar ook in de organisatie heeft een cloudtransformatie grote impact. Nieuwe competenties moeten worden opgebouwd zoals AWS-platformkennis, DevOps, infra-as-code en deployment pipeline practices. Een cloudtransformatie en bijbehorende competentie opbouw is absoluut de investering waard. Echter heeft de organisatie niet altijd de tijd en ruimte om deze investering op de korte termijn te doen, of soms is er een acuut probleem en moet er snel binnen enkele maanden worden weg gemigreerd uit het bestaande datacenter. In dergelijke situaties is VMware Cloud on AWS potentieel interessant. Gezien de technologiestack dezelfde is als die in het huidige datacenter, is kennisopbouw en applicatietransformatie veel minder een issue. Daarnaast biedt de VMware Cloud on AWS-stack wel de optie tot verdere cloudtransformatie. De VMware omgeving zit immers in een AWS-datacenter en daarmee zijn native AWS-diensten als RDS (Managed Databases), FSx (fileshare storage) en andere quick wins in te passen voor de applicaties die er klaar voor zijn en deze transitie kan geleidelijk aan en in het wenselijke tempo van de organisatie.

#3 Tijdelijke uitbreiding

Enigszins in het verlengde van de vorige usecase is een tijdelijke uitbreiding van VMware-platformcapaciteit. VMware Cloud on AWS integreert met het bestaande VMware cluster en met VMotion technology is zonder downtime te migreren naar dit ‘tijdelijke extra datacenter’. Dit extra datacenter kan dankzij de global footprint van AWS naar praktisch elk continent op de wereld. Wel belangrijk is te weten dat VMware Cloud on AWS een minimale afname kent van drie fysieke hosts gezien het feit dat dit de minimale basis is voor een cluster. Wel biedt VMware Cloud on AWS verder de flexibiliteit om per uur af te nemen.

#4 Capex naar opex

Soms is ver-opexing een drijfveer en zeker wanneer de periodieke datacenter herinvestering voor racks, hardware, software met bijbehorende project kosten weer voor de deur staat. VMware Cloud on AWS is een opex gebaseerd model en werkt ook net als AWS EC2 met de optie van reserved (committed) capaciteit in ruil voor serieuze kortingen.

#5 Parkeren van ‘legacy-apps’

Een laatste usecase die we willen aanhalen is landingzone voor ‘legacy-apps’. Wanneer organisaties in een cloudtransformatie zitten, zijn er vrijwel altijd applicaties waar geen kennis meer van in huis is of waar niet meer in geïnvesteerd mag worden. Toch moeten deze applicaties mee uit het datacenter. Om in dergelijke situaties niet te veel effort te verliezen aan het migreren naar het AWS Native platform zou VMware Cloud on AWS een optie kunnen zijn.

Invalshoeken

Het vaststellen of VMware Cloud on AWS voor uw usecase voldoende interessant is, kent uiteraard meerdere invalshoeken dan boven beschreven en is ook aan verandering onderhevig. Nieuwe features, prijsmodellen en opties worden met regelmaat gelanceerd op zowel AWS als VMware on AWS. Een interessante voor de korte termijn is AWS Outpost waar zowel de AWS Native als VMware Cloud on AWS cloudextensie in uw datacenter kan gaan draaien. Laat u in de afwegingen dan ook zeker goed voorlichten door een AWS- of VMware-partner en benader de stap vanuit een hoger liggende strategie en architectuur.

Anti-patterns in the public cloud

Adopting public cloud isn't always easy and usually a struggle to do it right. In the past years I've gained some experience in my daily life as a Cloud Consultant at Oblivion Cloud Control while helping companies going to public cloud. I think it's time to share some part of this knowledge with you.

Just another datacenter

During the start of "cloud" projects people quite often say: "I can host my application on a virtual machine in public cloud". Yes, obviously you can do that. But most likely doing it will not bring the change your business is looking for. After the migration you will still be busy running, maintaining and debugging your application. It's not worth spending time and money on a lift-and-shift project, since the economical benefits are at most 10% and your on-premises challenges like hardware issues, scaling issues, etc., etc,. will be replaced by cloud related challenges such as storing state, security, dynamic addressing, knowledge etc., etc. Most often we call this "your mess for less".

Do: Look at services provided by the cloud service provider, don't think public cloud is just an extension of your on-premises data center. Cloud-native services will bring you the most value when it comes to focus, maturity, scalability, security and innovation. Use higher level abstracted services such as Function as a Service (FaaS), managed database solutions, queuing services, etc., etc.

Tools over services

The real power of a cloud service provider is the number and variety of service they provide. If you have a brief look at the Periodic table of AWS you will notice around 170 services, from compute to game tech, from mobile to blockchain and from augmented reality & virtual reality to security. There is almost a service for everything and more are coming. According to the big tech giants this is just the beginning.

In my daily life as a cloud consultant I often notice people pushing for their own tools rather than cloud service, driven by reasons such as: not being familiar with cloud services, lack of trust in service, force of habit, job protection or false promises of tool vendors. This mistake is most often made in the area where people tend to solve issues with tools rather than focussing on the objectives. Such as encryption, secrets management, monitoring, vulnerability scanning, etc., etc.

Do: use cloud-services in your architecture, in most cases there is a service which covers almost all your requirements. If you cannot find a suitable service reconsider your requirements, most likely you are doing something terribly wrong. Remember the high burden of selecting, purchasing and running your own tools. You must have very good reason to do so.

Applying generic security controls

The risks identified for running applications in public cloud is somewhat comparable with on-premises workloads, with a few additions. However the risks are similar, the solution used to mitigate the risks shouldn't necessarily be the same between public cloud and on-premises. Preferably not. In most cases we use monolithic and expensive solutions to solve our on-premises challenges, like firewall and proxy, key management and remote access appliances.

Without cloud knowledge your first response would probably be: let's use a virtualised version of this appliance so that we can have a single pane of glass on our security landscape and reuse of specific knowledge. Sorry, you are wrong. You will face challenges implementing this due to the lack of integration, orchestration, scalability, availability, elasticity, high costs, etc., etc.

Do: rewrite your requirements so that they define the output ('what'), let cloud specialists design the 'how' and allow them to come up with new ideas. For example the requirement "Customer data should be protected at-rest and in-transit" will give you are more valuable native solution based on cloud services than when your requirements are specifying which already known tool to use.

Agnostic architectures

This is my favourite topic. I do see this as the biggest marketing slogan currently used. It's no surprise that people think this myth is really true. For years vendors worked on their reputation by increasing license costs year over year, forcing you to switch to newer products by having unpredictable product lifecycles etc., etc. This has led to something we now call "avoid vendor lock-in". Lots of vendors are trying to sell you tools or solutions which fulfil the promise that you actually can avoid the vendor lock-in. "If my cloud vendor increases the prices I can use my workload mobility to run my application on a cheaper vendor within minutes". Sounds good, isn't it? I have a little surprise for you: every technical decision will lead to a vendor lock-in.

Designing your application to be fully agnostic will not bring you anywhere, except from running out of time and budget for sure. The likelihood of applications moving from one platform to another platform because of high costs or sudden price increases is very small. Those risks can be mitigated in most cases. Known exceptions are Dropbox and Netflix, they've (partly) left public cloud due to extremely high volumes. I don't expect your applications, with respect, will ever reach that scale. You can possibly never create a decent business case for workload mobility when comparing the pros and cons of cloud-native vs agnostic (common denominator).

Do: make sure your organisation is prepared. Instead of having discussions around the fear of vendor lock-in, discuss the switching costs of your application. For example: We can build this application on cloud service provider X in four sprints, most likely we can build the same on cloud service provider Y within same amount of time or even faster since the speed innovation is massive and the major cloud service providers are following each other.

Building a new platform

It's very common that people think that public cloud is just a pool of unlimited compute, network and storage resources and that you've to build your own platform on top of that. Yes, public cloud provides basic resources as Infrastructure is a Service, but that is not the type of service you probably want to use. The biggest benefit of public cloud is that cloud service providers are building more and more services for you. Why run your own power plant while you can also get a commodity such as electricity just from a cable running to your building?

I will not make much friends when I say that IT is commodity. The years where scarce skills like putting together a server, mounting it in the datacenter and installing Linux and Oracle database on it are gone. Today everyone with a little bit of technical knowledge, a credit card and a browser can provision a database. IT is commodity.

The real difference is made in the business logic you run on the commodity. The more focus you can have on building logic to enable your business, the better your company can distinguish itself. Don't make the mistake of thinking your company has different IT requirements than all the other companies on this globe. It doesn't make sense to spend time and money on building a platform when your cloud service provider already built and keeps building something for you. Running a platform like OpenShift or Kubernetes on public cloud is most often a bad idea since it will drift away from the core principles of the cloud service provider (e.g. IAM and networking controls).

Do: use the platform capabilities provided by the cloud service provider. Don't think you can do it better. You simply don't have the scale they have. Not when it comes to the budget and especially not the knowledge.

End state architecture

The pace of innovation in public cloud is fast, really fast. The number of new services and features launched annually is massive and increasing each year. If you can maintain status quo for a number of years you are doing something wrong. New features can lead to new insights on performance, scalability, security and costs. The pay-per-use model allow you to switch, without breaking any contracts. Agility.

Due to the economics in public cloud the length of lifecycle for workloads is also very flexible. In more traditional environments it was very common to have long-term agreements (4-8 years contracts). With cloud most pricing models are based on pay-per-use model and often billed per minute, second or sub-second. Billing is stopped immediately after you terminate the resource. Which allow you to have shorter lifespans for marketing campaigns, and also very long lifespans for archive purposes.

Do: Consider your architecture as a rolling release which should continuously improve. Don't be afraid to change your design or opinion, based on the ever changing world of public cloud.

Disclaimer: any resemblance to actual companies is purely coincidental. Do not worry; the challenges described here are generic and more often than not the case.

Single cloud geeft het beste resultaat

Vrijwel elke organisatie heeft inmiddels een cloudstrategie als onderdeel van hun IT strategie gedefinieerd. Bij vrij veel organisaties (met name enterprises) zien wij hierbij een keuze voor multicloudstrategie gemaakt worden waar SaaS providers, middelgrote ondernemingen en start-ups veelal kiezen voor singlecloud. Echter, is een multicloudstrategie wel altijd de beste keuze of gaat de enterprise CIO wellicht te makkelijk mee met deze trend?  

STATE OF THE CLOUD

Voor we ingaan op het vraagstuk single versus multicloud, schetsen we eerst wat trends uit de “multicloud world.” De cloudmarkt wordt momenteel gedomineerd door Amazon Web Services (AWS) en Microsoft Azure met als serieuze derde speler Google Cloud Platform. AWS staat bekend als gericht op developers, hoogste innovatie, grootste ecosysteem en de “founders of the cloud.” Azure kenmerkt zich zeker in Nederlandse markt als de “sort of enterprise standard”. Organisaties met veel Microsoft workloads, die geen expliciete keuzes maken, groeien vanzelf Azure in. Verder is Azure net als AWS een zeer volwassen cloudplatform en voor veel organisaties ook een passende keuze. Google Cloud Platform springt eruit in specifieke situaties. In de gebieden van Artificial intelligence, Machine Learing en Analytics scoren ze goed. Ook drijft Kubernetes nog veel developers richting Google ondanks dat AWS en Azure eveneens Kubernetes services aanbieden. Naast de dominante top drie zijn er nog IBM, Alibaba en Oracle. IBM Cloud (Softlayer en Bluemix gezamenlijk) worstelt wat met haar positionering maar zet ondermeer in op bare metal servers. Alibaba cloud is de equivalent van AWS in China, waarbij het interessant is blijven volgend hoe dit gaat ontwikkelen. Alibaba heeft inmiddels immers ook in Frankfurt een regio gevestigd. Oracle zet in op Oracle workloads en lijkt voornamelijk AWS te wil beconcurreren op Oracle workloads.

Figuur 1 - Multi cloud landschap - a point of view

Figuur 1 - Multi cloud landschap - a point of view

Wanneer we de verschillende clouds vergelijken, kunnen we voor de drie grootste stellen dat het echte verschil niet meer zit in IaaS diensten. Gartner onderzoek toont aan dat alle belangrijke IaaS gerelateerde features in de grootste platformen vergelijkbaar aanwezig zijn. Aanvullend uit eigen calculaties concluderen we dat voor de meeste workloads op IaaS de prijsdiversiteit tussen de platformen in een bandbreedte van + of – 5 procent zit. Het selecteren van een cloudplatform doe je dus beter op basis van hogerliggende diensten en andere factoren. In dit kader zien we al jaren de trend FaaS (Serverless) boven Containers/PaaS boven IaaS. Bedrijven willen hoger in de services stack om meer innovatie, snelheid en efficiencyvoordelen te realiseren. Gelijktijdig worstelt nog menig organisatie met de organisatorische kant van de cloud. Opbouw van de kennis, cloudnative gaan beheren via infra-as-code en het in control houden van de kosten en compliancy is geen sinecure. Binnen deze mulicloud context speelt de vraag single versus multicloud.

MULTICLOUD DRIJFVEREN

Organisaties met multicloudsituaties zien we vanuit twee situaties. Enerzijds organisaties waar een multicloudsituatie is ontstaan zonder expliciete strategie. Bijvoorbeeld door het ontbreken aan strategie  of vanuit overnames en fusies. Anderzijds zien we organisaties met een bewuste multicloudstrategie. Uit een recente inventarisatie langs enterprises met een multicloudstrategie worden er consequent vijf argumenten dominant hiervoor genoemd. Deze drijfveren zijn:

  • Disaster recovery

  • Preventie van vendor Lock-in

  • Cost efficiency

  • Compliancy

  • Innovatie.

Wanneer we kritisch naar deze argumenten kijken zijn dit zeker niet altijd vanzelfsprekend goede redenen om vandaaruit voor een multicloudstrategie te opteren. We ontleden deze argumenten om ons punt helder te maken.

 

1. Disaster Recovery

Om uit te leggen waarom hoge beschikbaarheid en disaster recovery geen vanzelfsprekende drijfveer voor een multicloudstrategie zijn, moeten we kijken naar de principes van beschikbaarheid op Public cloudplatformen als AWS en Azure. Dergelijke cloudplatformen bieden het concept van regions en daarbinnen een of meerdere availabilityzones. Een availabilityzone dient gemakshalve te worden gezien als een datacenter, hoewel ze meerdere datacenters bevatten. Om hoog beschikbare applicaties te realiseren dienen applicaties over meerdere availabilityzones te worden gedeployed. Vergelijk dit concept met een multidatacenter setup. Wanneer dit niet voldoende is kan worden gekozen voor een multiregion deployment. Gezien regions volledig zelfstandig zijn, bereiken we hiermee eigenlijk hetzelfde als met een multicloud deployment. Wanneer we daarnaast naar het verleden kijken, kunnen we stellen dat de grote drie cloudplatformen effectief nog nooit een verstoring hadden die meerdere regios gelijktijdig en volledig platlegt. Disaster recovery drijft dus niet een harde noodzaak om voor multicloud te kiezen.

Figuur 2 - Concept van Availability Zones

Figuur 2 - Concept van Availability Zones

2. Preventie van vendor Lock-in 

Een nog vaker genoemd argument voor multicloud is preventie van vendor lock-in. De grote vraag hierbij is in hoeverre de organisatie ook de SaaS over FaaS over PaaS over IaaS strategie volgt. Wanneer vendor lock-in minimalisatie daadwerkelijk een argument is, zal het aantal services wat in aanmerking komt te gebruiken op het cloudplatform worden beperkt tot primair IaaS en wat database en container services. Hiermee ontstaat dus eigenlijk een vendor lock-out. De voordelen op het vlak van innovatie en TCO worden niet volledig uitgenut. Naar onze visie is toegang tot de innovatieve cloudservices juist één van de primaire redenen om naar public cloud te gaan. Daarbij is het uiteraard nooit verkeerd per applicatieworkload vooraf na te denken over exit en portabiliteit. Voor wegmigreren van IaaS servers en databases zijn tal van migratietools beschikbaar. Het wordt spannender bij cloudplatform specifieke diensten als  Queing, serverless, machinelearning en artificial intellinge. We adviseren exit per cloud service te beoordelen en te benaderen vanuit applicatie bouwstenen die je zou moeten kunnen herplotten.

3. Prijsefficiency

Sommige organisaties stellen kostenvoordeel te halen bij een multicloudstrategie doordat ze een betere onderhandelingspositie hebben tegenover de cloudproviders. Voor de meeste cloudplatformen is dat niet zo. In tegendeel, er wordt juist meer volumediscount gegeven bij hogere workload op één platform. De andere uitleg van deze drijfveer is dat per workload het meest kosteneffectieve platform kan worden geselecteerd. Dat klopt in de basis, maar zoals we eerder zagen zit prijsverschil vooral bij inzet van hogerliggende services. Vergeet daarbij ook niet dat veel diensten in de details lastig vergelijkbaar zijn tussen de providers. Ook is er een keerzijde bij multicloud die juist de kosten opdrijft. Hoe meer platformen, hoe meer complexiteit. Kennis opbouwen en onderhouden over meerdere cloudplatformen kost veel tijd en effort. Ook resulteert meerdere clouds in hogere connectiviteits- en beheerkosten. Kostenvoordeel door inzet van multicloud is daarmee een discutabel argument.

4. Innovatie

Meer cloudplatformen bieden gezamenlijk meer variantie in diensten en features, wat innovatie enabled. In de basis waar, maar alleen wanneer als volledig wordt ingezet op higher level services. Lock-in minimalisatie moet dus niet gelden want dan gaat dit argument niet op. Bovendien moet je het als organisatie ook inhoudelijk op al die diensten kennis technisch kunnen bevatten. Daarnaast is het over het algemeen niet altijd aan te bevelen om applicaties die sterk met elkaar interacteren over meerdere cloudplatformen te verpreiden.

5. Compliancy

Datalocatie en compliancy als argument voor multicloud klopt in specifieke gevallen. Wanneer een organisatie workloads moet kunnen hosten in bijvoorbeeld landen als China, Rusland of Brazilië, dan kom je soms niet onder een lokale cloudprovider uit. In China is bijvoorbeeld Alibaba-cloud of AWS China (wat los staat van de rest van AWS) een optie. Generiek kunnen we stellen dat de grote cloudproviders reeds indrukwekkende compliancy statements/certificeringen afgeven waarmee datalocatie en databeveiliging over het cloudplatform zelf wordt gegarandeerd. Compliancy opzichzelf is dus ook niet een argument tenzij je met specifieke landen te maken hebt. 

VOORDELEN VAN JUIST SINGLE CLOUD

De vijf meest dominante argumenten voor multicloud hebben we dus in perspectief gezet en gaan dus niet altijd op. We zullen andersom nog even kijken naar juist de voordelen van juist single cloud. De crux zit hem in volledige adoptie. Zoals we eerder stellen is het echte voordeel zowel financieel als vanuit innovatie te halen wanneer hogerliggende services worden ingezet. Hiervoor is in-depth kennis nodig van het cloudplatform en die leercurve succesvol doormaken is op één cloud realistischer dan om meerdere alsook het bijhouden van nieuwe ontwikkelingen gaat beter. Met een single cloud is tevens meer succes om compliancy en security beheerst te houden.

Multicloud of Single Cloud

Zoals we stellen geloven wij in een single cloud strategie voor het beste resultaat. We stellen niet dat we tegen multicloud zijn, echter dan wel gebaseerd op de juiste afwegingen en niet omdat veel bedrijven het roepen te doen. En als je dan voor multicloud gaat, zorg dan voor voldoende body in je operations per platform. Bijvoorbeeld en apart AWS en apart Azure ops team die zich kunnen focussen op één van beiden. Forceer beiden platformen ook niet om technisch gelijk te blijven. Werk met generieke architectuurstatements en requirements, maar probeer niet technisch alles gelijk te trekken. Probeer ook de workload logisch te verdelen. Bijvoorbeeld Businessunit A gaat voor AWS en Business unit B voor Azure. Wat we vaker zien is bij multicloud is een dominant platform en een tweede cloud voor specifiek gedefineerde workloads only. Laat prijsstelling bij voorkeur niet het leidende argument zijn voor de afwegingen.

Tot slot, ben ook kritisch op cloudmanagement oplossingen. Bekijk de het probleem op zichzelf en los dat bij voorkeur met de platform native oplossing op tenzij. Gezien we adviseren met aparte opsteams te werken is voor veel cloudmanagement domeinen geen noodzaak en verlaagt abstractie soms alleen maar de waarde. Blijf dus focussen op hoe het cloudplatform(en) optimale value voor de organisatie kunnen realiseren.

Jeroen Jacobs is Cloud Consultant bij Oblivion Cloud Control BV, Edwin van Nuil is Managing Director bij Oblivion Cloud Control BV.

(Dit artikel is eerder verschenen in CIO Magazine in Aprll 2019.)

Het belang van Mensen bij cloud transformatie - KNMI (English)

(Nederlands) Onze klant Jan-Willem Arnold van KNMI sprak in April bij AWS Public Sector Summit in Brussel. Hij presenteerde over "The People Pillar of Cloud Adoption", oftwel het belang van mensen bij de verandering naar cloud computing.

Een succesvolle cloud transformatie kent drie pijlers: Mensen, Processen en Technologie. Te vaak focussen organisaties zich op de laatste twee en vergeten het menselijk aspect ervan. Leidinggevenden beseffen zich goed dat ze processen en technologie relatief makkelijk kunnen aanpassen - maar cultuur is een heel andere zaak.

Deze presentatie behandelt best practices om deze uitdaging goed aan te pakken. De presentatie van Jan Willem begint op 12 minuut 23 en eindigt op 31 minuut 23.

Hij geeft deze presentatie samen met Thomas Blood van AWS, die voor en na zijn presentatie spreekt. Ook zijn verhaal over transformatie kunnen we van harte aanbevelen.

(English) Our client Jan-Willem Arnold of KNMI spoke at the AWS Public Sector Summit in Brussels in April. He presented about "The People Pillar of Cloud Adoption", i.e. people's interest in the change to cloud computing.

A successful cloud transformation has three pillars: People, Processes and Technology. Too often organizations focus on the latter two and forget the human aspect. Managers are well aware that they can adapt processes and technology relatively easily - but culture is a completely different matter.

This presentation discusses best practices for tackling this challenge. Jan Willem's presentation starts at 12 minutes 23 and ends at 31 minutes 23.

He gave this presentation together with Thomas Blood of AWS, who spoke before and after his presentation. We can also warmly recommend his story about transformation.

Digitale overheid op de AWS Public Sector Summit

Op dinsdag 9 april vond in het hart van Brussel, in congresgebouw The Egg, de tweede Amazon Web Services EU Public Sector Summit plaats. Het event heeft een pure focus op de Europese publieke sector gesegmenteerd in overheid, Europese unie en de sectoren educatie en healthcare. De opkomst overtrof de vorige editie. Arjan Timmers en Jeroen Jacobs van Oblivion Cloud Control waren aanwezig en delen hun waarnemingen.


Waren vorig jaar GDPR en cloud-adoptie de rode draden van de summit, dit jaar vormde digital transformatie en digital government het centrale thema. De summit opende met een keynote van Terresa Carlson, hoofd AWS Public Sector Global. Hij vertelde hoe AWS de publieke sector ondersteunt in adoptie van cloudtechnologie om te groeien naar een ‘digital government’. Steeds vaker wordt ook in de publieke sector een cloud first-strategie gehanteerd en dat werd ruimschoots onderbouwd met voorbeelden. Tijdens haar keynote Lanceerde Carlson twee nieuwe Cloud Innovation Centers (CIC).

Cloud Innovation Center (CIC)

De hogeschool van München (MUAS) en de CODE-hogeschool in Berlijn lanceerden tijdens de summit hun innovatie-labs die als doel hebben de digitale transformatie van de publieke sector te versnellen. De centra focussen zich op het stimuleren van innovatie in Duitsland en helpen de overheid, het onderwijs en non-profitorganisaties bij het aanpakken van de meest urgente uitdagingen bij het leveren van een breed scala aan burgerdiensten. Met dit initiatief hebben studenten toegang tot AWS-technologieën, innovatiemethodieken en technische expertise om te experimenteren met 'born-in-the-cloud'-oplossingen.

Digitale overheid

Na de aankondigingen volgden diverse gastsprekers in de keynote onder wie Mario Campolargo, topman bij de Europese Commissie. Zijn verhaal ging over ‘enabling digital government’. Tijdens de Tallinn Digital Summit 2018 in Estonia heeft de Europese Commissie de ambitie uitgesproken om een echte digitale commissie te worden in 2022. ‘Efficiënt, trust, uitwisselbaar, secure, transparant en citizen centric’.

Campolargo benadrukte de fundamentele rol van data. ‘Data is fundamenteel om effectieve innovatie te realiseren.’ Hierbij haalde hij ai, machine learning (ml), blockchain en iot aan. Ook benadrukte Campolargo het belang van aandacht naar skills en culture. Een onderwerp wat verder gedurende de dag regelmatig terugkwam.

De keynote werd verder gevuld met meer cases: onder meer het Vlaamse VDAB, verantwoordelijk voor werkgelegenheid, liet zien hoe ml-diensten van AWS job matching op de website Jobnet aanzienlijk intelligenter maakt. Ook waren er sprekende cases waarin AWS-services worden ingezet om mensenlevens te redden. Zo brengt de Humanitarian OpenStreetMap Team hulpverleningsroutes in kaart in moeilijk bereikbare gebieden bij rampen. Hierbij wordt gebruikgemaakt van AWS Ground Station. Daarnaast een case van de Munich Leukemia Labratory waar AWS-ml-diensten worden ingezet en de dna-analyse van twintig naar drie uur heeft teruggebracht.

Digital technologie en Digital Culture

Vrijwel alle break-out sessies gedurende de rest van de dag gingen over digitale technologieën en veranderfactoren bij cloud- en digital-transformatietrajecten. Een belangrijke take-away uit een sessie over ML en AI is ‘Art of the possible + Art of the Practical’. Hiermee wordt bedoeld dat elk AI/ML-initiatief een duidelijk businessdoel moet hebben en daarna pas naar de technologie en data beschikbaarheid gekeken dient te worden. Hieraan werd toegevoegd de businessvraag goed te scopen, op te passen met slechte implementaties en datacompliancy en security integraal mee te nemen.

Het belang van de menselijke factor

Een voor mij aansprekende afsluitende talk van de dag was die van Thomas Blood, enterprise strategist bij AWS en Jan-Willem Arnold, hoofd Informatie & Ketenmanagement bij KNMI. De cloudtransformatie bij KNMI heb ik van dichtbij mogen ervaren en het was inspirerend om te zien hoe de lessen uit deze journey worden gedeeld met de community.

De kernboodschap van het verhaal was gericht op het belang van de menselijke factor bij digitale transformatie en cloud. ‘Twintig jaar geleden maakte we ons zorgen of die database wel zou performen en technisch zou draaien. Vandaag is de zorg of we het wel kunnen organiseren en hoe we onze mensen aan boord krijgen en houden’, aldus Arnold. Nieuwe manieren van werken, DevOps practices en nieuwe technologie hebben impact op de banen van trouwe medewerkers en ieder gaat daarin mee in zijn eigen tempo. Dit is iets want zich nauwelijks laat plannen. Vervolgens volgden waardevolle tips uit de praktijk. ‘Biedt perspectief, databasebeheerders worden bijvoorbeeld data-architecten. Stimuleer innovatie en experimenten. Investeer in training en certificering en schroom niet om hulp in de schakelen van partners.’

(Dit artikel is eerder verschenen in Computable)

Single Cloud in een Multi Cloud wereld - 5 argumenten

Organisaties kiezen vaak voor een multicloud strategie als ze een keuze overwegen tussen Amazon Web Services, Google en/of Azure. Maar is een multi-cloudstrategie wel altijd de meest voor de hand liggende keuze, of is er sprake van het reageren op de laatste management buzzwords?

Een recente inventarisatie bij bedrijven leert ons vijf belangrijke argumenten voor een multi-cloudstrategie. Helaas is het niet altijd verstandig om van daaruit te kiezen voor een multi-cloudstrategie.

Beschikbaarheid

Het beschikbaarheids-argument is geen vanzelfsprekende drijfveer voor een multi-cloudstrategie. Public cloud-platformen als AWS en Azure bieden het concept van Regions en Availability Zones. Binnen een Region zijn meerdere Availability Zones waarin een applicatie ingezet kan worden voor hoge beschikbaarheid. In feite hebben we hiermee een multi-datacenter-setup. Zijn de eisen nog hoger, dan is voor een multi-region deployment te kiezen, wat hetzelfde is als een multi-cloud deployment. Beschikbaarheid drijft dus de noodzaak voor multi-cloud.

Lock-in

Lock-in moet worden afgezet tegen lock-out. Menig enterprise voert de Paas-over-Iaas-strategie en kiest dus voor hoger liggende services en daarmee meer lock-in. Voor minimalisatie van lock-in is het beperken tot wat Iaas en generieke technologieën als Kubernetes de weg, ook bij multi-cloud. Hierbij blijven innovatie en TCO-voordelen liggen.

Prijsefficiency

Sommige denken dat er beter te onderhandelen valt met cloudproviders bij concurrentie. Voor de meeste cloudplatformen is dat niet zo. Sterker nog, er wordt juist meer volumediscount gegeven bij meer workloads op één platform. Anderen stellen dat per workload het goedkoopste platform is te kiezen. Dat is zo, maar vergeet niet de kosten van extra complexiteit van twee platformen.

Innovatie

Meer platformen is meer variatie in diensten en feature-aanbod en is dus meer innovatie. In de basis is dit waar, maar uitsluitend als er volledig voor higher-levelservices wordt gegaan. Leeft het lock-in-argument, dan gaat dit argument dus zeker niet op.

Compliancy

Compliancy als argument voor multi-cloud snijdt hout in specifieke gevallen. Als uw organisatie veel workloads heeft in bijvoorbeeld China, dan is de Alibaba-cloud wellicht een noodzaak naast bijvoorbeeld AWS voor de rest van de organisatie. Voor vrijwel alle andere regio’s bieden de grote providers reeds indrukwekkende compliancy statements en certificeringen.

Samengevat

Samengevat kunnen we stellen dat multi-cloud vanuit deze argumenten nog niet zo noodzakelijk is. In tegendeel, multi-cloud levert juist complexiteit en dus extra kosten in zowel techniek, connectiviteit, leercurve als beheersbaarheid. Overweeg dus zorgvuldig voor u voor multi-cloud kiest.

(dit artikel is eerder gepubliceerd in Computable)

 
AWS IoT Services in 2019 - presentation (English)

The list of IoT related services and feature launched during AWS re:Invent 2019 is impressive.

Martijn Smit of Oblivion is an IoT-specialized software architect and has successfully completed several IoT projects with AWS services such as AWS IoT, Amazon FreeRTOS and AWS Greengrass.

In this presentation at AWS UGNL (AWS User Group Netherlands) Meetup Amsterdam in January 2019, , Martijn will walk us through the newly launched services such as:

  • AWS IoT Things Graph

  • AWS IoT SiteWise

  • New IoT related features on Greengrass

  • Amazon FreeRTOS support for Bluetooth Low Energy

  • As well as important launches on IoT related services such as Amazon Time Stream, the time series database solution.

Martijn will elaborate on how those new services and features will impact IoT solutions in 2019 and onwards.

IoT-technologie onderbenut in grote ondernemingen

Het internet of things (IoT) is voor veel organisaties en CIO’s nog wat diffuus en wordt vaak afgedaan als toekomstmuziek. Toch wordt IoT meer toegepast dan op het eerste gezicht lijkt, schrijven Martijn Smit, Jeroen Jacobs en Edwin van Nuil van Oblivion Cloud Control.

De essentie van IoT is dat eigenlijk alles, hoe klein ook, verbonden is met internet om gegevens en data te verzamelen of om een apparaat decentraal te besturen. Toepassingen van IoT zijn gericht op twee gebieden. Veruit de meeste toepassingen hebben dataverzameling en analytics tot doel. In mindere mate richten IoT-toepassingen zich op decentrale sturing. Uit deze twee toepassingsgebieden zijn tal van strategisch inzetbare IoT-toepassingen te bedenken voor organisaties.

IoT is een enabler en biedt nieuwe mogelijkheden voor organisaties. Processen, services en data die nooit voorhanden waren, zijn mogelijk dankzij IoT-technologie. Toegepaste IoT draagt dan ook vaak strategisch bij aan innovatie, procesoptimalisatie of financieel voordeel/omzet. Zo realiseren organisaties dankzij IoT bijvoorbeeld nieuwe diensten, businessmodellen en omzetstromen of wordt het engagement met klanten verbeterd, verreikt of verbreed. In de categorie financieel draagt IoT veelal bij door minimalisatie van verspilling of verbetering van uitnuttig van middelen.

Meer richting de interne processen kan gedacht worden aan zaken als verbetering van veiligheid en optimalisatie van bedrijfsprocessen. Een voorbeeld van een strategische toepassing is een kantoorinrichting- en meubilair fabrikant die door sensoren in de bureaustoel een unieke werkplekbeleving aan zijn klanten kan aanbieden, maar daarmee ook gegevens terugstuurt over gebruik. Een ander voorbeeld is een verzekeraar die data verzamelt uit de databus van de auto en met additionele sensoren, en hier een dynamische korting op de verzekeringspremie baseert.

Sensoren zoals temperatuur, licht, beweging, vochtigheid, kleur, stroomsterkte, enzovoorts, zijn op zichzelf niet nieuw. Ze worden al decennialang toegepast in de elektromechanische industrie en zijn er voor de meest bijzondere toepassingen. De hoeveelheid en intensiteit van de toepassing zijn wel nieuw.

IoT-architectuur

Alvorens we verder op praktische IoT-toepassingen ingaan, beschrijven we eerst de basiselementen van een IoT-ketenarchitectuur. Grofweg is een IoT-architectuur opgebouwd uit vier elementen. Het IoT-device zelf, de connectiviteit, een IoT-platform, en de businessapplicatie. De architectuur en zijn functies zijn weergegeven in figuur 1. We verklaren de onderdelen nader.

Figuur 1. IoT-keten en architectuur

Figuur 1. IoT-keten en architectuur

IoT-device

Elk IoT-device bevat drie kernfuncties: één (of meerdere) sensor(en) voor metingen in de fysieke wereld, een lokale simpele processingunit, en de communicatie het netwerk in. Veelal heeft een sensor een lokale aansturing en logica (low-power MCU/SoC) nodig om waarnemingen te verwerken en alleen relevante waarneming te verzenden via de communicatiemodule (WPAN/LPWAN) naar een IoT-Platform.

IoT-connectiviteit

Connectiviteit van de IoT-devices naar het IoT-platform kenmerkt zich als WPAN en LPWAN. WPAN omvat de bekende protocollen als wifi, bluetooth, Thread en/of ZigBee.

LPWAN staat voor low power wide area network en omvat protocollen als LoRa, Sigfox, NB-IoT, LTE-M. LoRa (WAN) is een open standaard die wereldwijd wordt toegepast in zowel publieke als private netwerken. De NB-IoT- en LTE-M-netwerken worden door telecomproviders in gelicenseerd spectrum aangeboden en hebben een aantal voordelen. De grootste voordelen van deze LPWAN-protocollen zijn het lage dataverbruik, geringe batterijverbruik, encryptie en grote reikwijdte. Dit maakt toepassingen mogelijk met kleine devices op locaties zonder elektriciteit of WPAN-connectiviteit.

Connectiviteit wordt geboden door een netwerk als KPN’s LoRaWAN, T-Mobile NB-IoT of door een private-owned LoRaWAN-gateway, die daarna bijvoorbeeld over het internet de communicatie naar achterliggende platformen verzorgt.

IoT-platform

  • Het IoT-Platform heeft grofweg drie functies:

  • Het ontvangen en verwerken van ruwe berichten van de decentrale IoT-devices.

  • Het near-time transformeren van ruwe data naar uitwisselbare informatie voor achterliggende systemen als een datawarehouse of een event-bus.

  • Het managen van de IoT-devices zoals onboarding en provisioning.

Het IoT-platform is IoT-connectivity agnostisch. Dat wil zeggen dat devices langs verschillende WPAN/LPWAN- of zelf WAN/LAN-routes kunnen worden opgenomen.

Businessapplicaties

De businessapplicaties zijn systemen als datawarehouses, analyse/BI-tooling, log-collectors en bijvoorbeeld webbased bedieningsapplicaties om vanuit een vriendelijke interface opdrachten naar apparaten te kunnen sturen. Domotica bijvoorbeeld.

Uitdagingen bij IoT

Anders dan reguliere IT-toepassingen kent het IoT een aantal specifieke uitdagingen. Kenmerkend zijn de hoeveelheid en de aard van de IoT-devices. Devices zijn lang niet altijd eigendom van de aanbieder van een IoT-dienst, worden door diverse vendors op eigen specs in elkaar gezet, en hebben zo hun technische beperkingen.

Zo is stroomverbruik van het device en connectiviteit een schaarste en lang niet altijd vanzelfsprekend. Apparaten moeten dus in sommige toepassingen mogelijk lange tijd op een batterij kunnen functioneren en het IoT-platform moet met downtime en communicatiewindows van apparaten kunnen omgaan. Vanuit de architectuur is zo’n IoT-platform bovendien zwaar asynchroon opgezet.

DEVICES ZIJN LANG NIET ALTIJD EIGENDOM VAN DE AANBIEDER VAN EEN IOT-DIENST

Het is dus belangrijk de embedded software hiermee adequaat te laten omgaan. Ook bieden sommige IoT-platformen (zoals dat van Amazon Web Services) een framework om via shadow/twin designpatterns een IoT-device naar de achterliggende systemen virtueel beschikbaar te houden, én andersom.

Een andere uitdaging is security. Welke data bevat het device? Hoe gevoelig is deze? En hoe is de data lokaal beschermd? Maar ook het transport van deze data via connectiviteit naar de achterliggende platformen, incluis het IoT-Platform. Met de actualiteit van de GDPR is het essentieel om de veiligheid en privacy goed op orde te hebben in de totale keten van de IoT-toepassing.

Beheerbaarheid en kostprijs zijn andere gebieden die aandacht behoeven. In dit kader bieden cloudplatformen als Amazon Web Services en Azure tal van diensten om beheer en dataverwerking in een opex-model beheersbaar en efficiënt te realiseren. Ter illustratie zijn in het kader de belangrijkste IoT-diensten weergeven van Amazon Web Services.

IoT-casus energiemanagement

Nu de architectuur- en IoT-specifieke uitdagingen zijn geschetst, duiken we in enkele cases uit de praktijk. Een woningcoöperatie had de afgelopen jaren veel van haar woningen en flats voorzien van zonnepanelen. Om zicht te houden op de energieopbrengsten waren ze op zoek naar een meetsysteem. Echter, de betrouwbaarheid moest hoog zijn en de daadwerkelijk opgewekte energie meten. Dus geen ‘net feed-in’, maar gerealiseerde opwek zonder afhankelijkheid van het type omvormer. Ook onafhankelijkheid van de lokale internet/wifi-verbinding van de bewoners was geen optie.

Gekozen werd om een extra kWh-meter achter de omvormer te plaatsen met een universele ModBus/RS485-interface. Een collector (MCU) las vervolgens digitaal de meterstand en stuurde een UP-bericht over LPWAN. Eigen LoRaWAN-gateways werden gebruikt op de hogere gebouwen voor omliggende woningen. Deze gateways connecteerden via 4G met het internet en stuurden de data door naar de IoT-Stack in de AWS-public cloud. Daar vond verdere verwerking van de data plaats en landde de data in een datawarehouse waar een webinterface heldere analyses visualiseerde.

Op deze manier had de coöperatie uniform inzicht met een betrouwbaar en kosteneffectief netwerk, los van vendor lock-in en vendordatasilo’s. Inzet van private LoRa bespaarde aanzienlijk in de connectiviteitskosten in vergelijking met de inzet van 4G per locatie. Daarbij bood het netwerk de mogelijkheid om in het gebied andere zaken te meten, zoals temperatuur en fijnstof. (Zie figuur 2 voor de visuele weergave van de architectuur.)

Figuur 2. IoT-architectuur casus 1

Figuur 2. IoT-architectuur casus 1

IoT-casus gladheidbestrijding

Een andere casus betreft een publieke instelling die weerdata (temperatuur en vochtigheid) onder, op en boven de grond wilde verzamelen over een zeer verspreid gebied. Vervolgens is met hulp van analytics tooling voorspeld of er (preventief) gestrooid diende te worden tegen gladheid. De meetpunten werden verspreid over het terrein. Daarbij was echter de uitdaging dat er geen kabels aangebracht konden worden om in connectiviteit en elektriciteit te voorzien. Low power IoT-devices brachten de oplossing. Ook het optuigen van een privaat netwerk met een eigen gateway was niet mogelijk, dus werd besloten om het KPN LoRaWan-netwerk te gebruiken. De data-events kwamen vanaf het KPN-netwerk het AWS IoT-platform in. Daar werd de ruwe data vervolgens getransformeerd en ging deze richting DWH voor verdere verwerking en BI.

Klaar voor IoT?

De mogelijkheden van IoT alsook twee praktische casussen inspireren mogelijk om na te gaan denken over de waarde die IoT binnen de organisatie kan leveren. Het denken vanuit de functionele gebieden data-analytics en decentrale sturing vormt daarbij een goed startpunt. Start na het idee vervolgens klein met een proof of concept. Dankzij de public-cloud-IoT-diensten die vandaag de dag beschikbaar zijn, kun je zonder al te grote startinvesteringen aan de slag. Met slechts enkele IoT-devices ben je al vertrokken.

Denk wel vanaf de start aan de architectuur van de hele IoT-keten en toets aan de hand van de eerder in dit artikel genoemde IoT-uitdagingen. Houd rekening met het ontstaan van vendorsilo’s. Data moet kunnen vloeien. Denk ook een paar stappen vooruit zodat de IoT-keten klaar is voor uitbreiding of nieuwe toepassingen. Dat zorgt voor een haalbare en schaalbare IoT-oplossing bij uiteindelijke realisatie.

Martijn Smit is softwarearchitect en IoT-consultant en realisator van de twee beschreven casussen, Jeroen Jacobs is cloudconsultant, en Edwin van Nuil is managing director bij AWS consultancy-firma Oblivion Cloud Control.

(Dit artikel is eerder verschenen in December 2018 in IT Executive)

AWS RoboMaker gelanceerd op Re:Invent 2018

In Las Vegas vindt jaarlijks in november het AWS Re:Invent plaats. Ook de achtste editie van dit Amazon Web Services-evenement - grootschaliger dan ooit met ruim 52.000 bezoekers en duizenden verschillende workshops, talks en sessies verspreid over zeven hotels - staat in het teken van product- en feature-lanceringen en kennisdeling. Jeroen Jacobs, cloudconsultant bij Oblivion Cloud Control, is ter plaatse en doet als Computable-expert dagelijks verslag.

Aangekomen in Las Vegas opende op zondagmiddag (25/26 november) de aanmeldregistratie en startten de eerste, voornamelijk informele, activiteiten rondom re:Invent, zoals AWS Midnight Madness, waarbij AWS exact om 00:00 uur uitpakt met een eerste indrukwekkende set aankondigingen van nieuwe diensten en features.     

De eerste officiële aankondiging evenwel is de lancering van AWS RoboMaker, een nieuwe dienst die developers van Robotapplicaties enabled in het ontwikkelen, testen en deployen van Robot aansturende toepassingen. Een andere nieuwe technologie die AWS lanceerde is AWS Transfer for SFTP, een volledig managed SFTP-dienst voor S3. Ideaal voor SFTP-gebaseerde integraties waar we direct al vele toepassingen voor zien bij onze klanten.

Ook werd AWS Datasync gelanceerd. Met deze nieuwe dienst zijn datamigraties of back-ups naar S3 en EFS te automatiseren en een hogere performance te halen. Tot slot lanceerde AWS de dienst AWS Amplify Console wat een continuous deployment en hosting dienst is voor serverless applicaties.

Naast nieuwe diensten zijn nieuwe features en verbeteringen in bestaande AWS Services gelanceerd. S3 heeft nu intelligent tiering waarbij AWS automatisch tussen storage classes kan schakelen zonder dat met harde waardes S3 LifeCycle policies hoeven te worden geconfigureerd. Hiermee kan S3 nog meer kosteneffectief worden toegepast.

Andere verbeteringen binnen het AWS-dienstenporfolio zijn CPU-power en GPU-optie op de Snowball Edge, verhoging van het mogelijk aantal max provisioned IOPS bij EBS tot 64.000 en AWS s3 Batch operations.

Cutting edge-sessies

"Duidelijk is dat AWS zwaar inzet op cutting edge-technologie"

Het dagprogramma van re:Invent maandag bestond zoals alle jaren uit de mogelijkheid tot het volgen van tal van worskhops, buildersessions, leadership en techtalks, customer cases en demonstraties. Het aanbod is divers maar duidelijk is dat AWS ook zwaar inzet op cutting edge-technologie en innovatie als virtual en augmented reality (vr/ar), Internet of Things, machine learning en kunstmatige intelligentie.

Zelf nam ik deel aan een AWS Mass Migration-workshop waar we met senior AWS- consultants de diepte ingingen omtrent dit onderwerp. De AWS-consultant gaf ons inzage in de volledige AWS Professional Services Confluence-pagina’s waarin rijke ervaringen waaruit we konden putten.

Ook bezocht ik een sessie omtrent virtual reality en augumented reality gebaseerd op AWS Sumerian. In een korte sessie werd de beoogde vr/ar-standaard WebXR uitgelegd, waarna de mooie case rondom AWS Sumerian en Sony werd uitgelicht. Hierbij realiseerde en lanceerde een klein developersteam in minder dan twee maanden een virtual reality-app voor de nieuwste Spiderman-film die in december uitkomt.

De laatste sessie die ik bezocht, ging over serverless als volgende iteratie van de cloud. Het einde van de dag bezocht ik de expo-vloer met vele AWS gelieerde partners met mooie complementaire solutions.

Nog meer features

Net nog tijdens het diner lanceerde AWS nog een aantal nieuwe diensten en aankondigingen. Binnen AWS EC2 zijn nieuwe IaaSinstance types gelanceerd, de A1 met ARM-processor en een C5n type met 100 gpbs bandbreedte. Op S3 werd de feature object locking bekendgemaakt. Binnen het IoT domain nieuwe features op Free RTOS en AWS Greengrass en twee nieuwe IoT services namelijk Iot Events en AWS IoT Sitewize. Dit sterkt mijn beeld dat AWS stevig inzet op IoT.

Wil je meer weten over de gelanceerde diensten, kijk de officiële AWS whats news blog posts

(Dit artikel is eerder verschenen in Computable in November 2018)

Jeroen Jacobs
AWS-ceo Jassy deelt 5 plannen voor developers

In Las Vegas vindt jaarlijks in november het AWS re:Invent plaats. Ook de achtste editie van dit Amazon Web Services-evenement - grootschaliger dan ooit met ruim 52.000 bezoekers en duizenden verschillende workshops, talks en sessies verspreid over zeven hotels - staat in het teken van product- en feature-lanceringen en kennisdeling. Jeroen Jacobs, cloudconsultant bij Oblivion Cloud Control, is ter plaatse en doet als Computable-expert dagelijks verslag. Dag 3.

De derde re:Invent-dag is een dag met veel grootste aankondigingen. Hoogtepunt op deze dag is dan ook de keynote van AWS-ceo Andy Jassy. Hij startte door te benadrukken hoe belangrijk de ‘builders’ (developers) voor organisaties zijn en hoe serieus Amazon de behoeften en feedback van zijn ontwikkelaars neemt. 

Hij vervolgt zijn verhaal met dat AWS wil uitblinken, niet alleen in de breedte van het dienstenaanbod maar vooral ook diepgang van de diensten. Andere cloudproviders gaan lang niet zo diep, builders weten dat en kiezen daarom consequent voor AWS. Hierbij haalt hij voorbeelden aan waaronder de s3 intelligent tiering die AWS maandag lanceerde, wat nu naar eigen zeggen werelds eerste machine learning gedreven object storage is.

Vervolgens structureert Jassy zijn keynote langs vijf sentimenten van ‘builders’ (developers) van waaruit tientallen bekendmakingen worden gedaan.

I want it all and I want it now

Builders willen diensten direct en breed kunnen inzetten en dat start bij storage. ‘AWS raises the bar for storage’, stelt de ceo. Binnen het storage-portfolio zitten zowel blockstorage, fileshare als object storage-diensten. De eerste aankondiging die de directeur doet is dat begin 2019 een nieuwe storage class, glacier deep archive genaamd, beschikbaar komt. Dit moet een tape-alternatief gezien worden kost 1.01 dollar per Terabyte per maand. Dit is volgens Jassy een gamechanger in voor archivering.

Naast AWS EFS, wat NFS-gebaseerde bestandsdeling aanbiedt, lanceert AWS nu ook AWS FSx for Windows Fileserver. Een volledige managed-dienst die we hadden gehoopt en verwacht, gezien 57,7 procent van IaaS Windows workload op public cloud op AWS is gehost. Binnen de FSx-dienst werd ook AWS FSx for Lustre aangekondigd; een file systeem voor high performance computing en machine learning-workloads waar een hoge throughput is vereist.

The right tools for every builder

Het tweede sentiment is de juiste tools om snel te kunnen starten. AWS lanceert een nieuwe dienst AWS Control Tower. Dit biedt gebruikers de mogelijkheid om multi-account landing zone te implementeren en beheren. Control Tower omvat best practice blueprints rondom accounts, authenticatie, configuratie, cloudtrail, identity & access-manager over meerdere accounts, virtual private cloud (vpc)-setup, een account factory en Guardrailes. De staat van de landing zone wordt weergeven in een dashboard. 

AWS Security Hub is een vijfde aankondiging die Jassy deed. Dit is een centrale plek om alle AWS security en compliancy controls te beheren. Tot slot kondigt AWS Lakeformation aan. Hiermee kunnen builders naar eigen zeggen in korte tijd een datalake optuigen, inclusief bijbehorende security policies.

(Database) Freedom

AWS-ceo Andy Jassy kondigt tijdens AWS re:Invent Timestream

Sentiment drie is database vrijheid (freedom). Jassy stelt dat gesloten database-oplossingen met licentiepraktijken en technische lock ins als Oracle en Microsoft zijn langste tijd hebben gehad. De tendens is naar opensource. AWS zet in op opensource met onder andere Aurora (re:Invent 2017). Ook is de trend het afstappen van relational databases, mede door andere performance-eisen in hedendaagse applicaties. 

DynamoDB is de belangrijke noSQL-oplossing van AWS, maar het is soms lastig om de juiste hoeveelheid read en write-capaciteitsunits te voorspellen. de aangekondigde AWS Read Write capacity on demand-oplossing moet hier antwoord op bieden.

Voor internet of things (IoT)-cases, waar miljoenen apparaten data verzamelen, lanceert Amazon Timestream. Dat is een nieuwe timeseries database. Timestream heeft performance, is naar eigen zeggen tot duizend keer sneller en kost 10 procent van een relationele database.

Specifiek voor blockchain-toepassingen is AWS QLDB aangekondigd; een Quantum Ledger Database. Dit is een managed blockchain ledger database met centrale regie. Immutable, snel en transparent. Als tweede blockchain-dienst wordt nog AWS Managed Blockchain bekend gemaakt. Hiermee kan snel een Hyperlegic fabric of Etherium blockchain worden opgezet en beheerd.

Little less conversation, little more action please

Minder praten, meer doen. En dan zeker op het gebied van machine learning (ml). Machine learning wordt al veel toegepast op AWS met de P3(dn) instance types. In de machine learing-frameworks is TensorFlow de meest gebruikte. AWS heeft nu de tensorflow geoptimaliseerd om hogere efficiency halen. Met AWS elastic inference levert AWS GPU-acceleratie on demand, in combinatie met EC2 om de GPU-capaciteit alleen te betalen wanneer deze daadwerkelijk nodig is. AWS belooft hiermee een kostenbesparing van 75 procent. In 2019 komt AWS nog met AWS Inferentia, een door Amazon ontwikkelde HPC Machine Learning chip. Deze gaat efficiency bieden.

Tijdens re:Invent 2017 lanceerde AWS Sagemaker als kerndienst om machine learning toegankelijk te houden voor een grote groep. Builders zijn enthousiast over de algoritme modellen en vandaag komt daar een AWS Marketplace for machine learning bij. Hier zijn al meer dan 150 algoritmes beschikbaar.

Voor ml is training van het algoritme belangrijk. Maar dat is intensief werk. Hiervoor lanceert AWS SageMaker Ground Truth: een machine learning datalabeling-dienst in twee varianten. Autolabling of uitgevoerd door mensen (Mechanical Turk). Ook werd Sagemaker RL nog gelanceerd voor reinforcement models. Een speelse oplossing rondom reinforcement learning in de vorm van een elektrisch aangedreven speel auto genaamd AWS Deepracer. Doel is om ontwikkelaars op een speelse manier met reinforcement learning te laten kennismaken en experimenteren. Daarmee wordt ook direct een AWS deepracer sports league afgekondigd.

Een andere dienst op het gebied van machine learning is AWS Textract, een hele OCR++ service die de layout van een webpagina, formuliervelden en soorten input herkent. Verder kan Amazon Personalize in webwinkel-apps worden toegepast om persoonlijke aanbevelingen te tonen. Tot slot lanceerde AWS nog Amazon Forecast en Amazon Timeseries forecasting.

Should I stay or should I go now

Should I stay or should I go now wordt gerelateerd aan van on premise naar de cloud. Eerder deze week zijn wederom aankondigingen gedaan als de SFTP gateway welke inzetten op de hybride integratie. En ook al langer zijn diensten als Storage GW, direct connect en vorig jaar het partnership met VMware on AWS onderdeel van deze hybrid oplossingen. 

Tijdens de keynote kwam VMware-ceo Pat Gelsinger op het podium. Hieruit komen de volgende aankondigingen. Op korte termijn heeft elke AWS Region VMware on AWS beschikbaar. Ook kondigt AWS voor 2019 AWS Outputs aan. Outputs is een rack appliance waarmee je AWS uitbreidt naar je datacenter. Eigenlijk vergelijkbaar als Microsoft met Azure Stack doet. Gelsinger vult tijdens de keynote aan dat AWS Outputs ook de optie heeft om VMware cloud on AWS outpost te draaien.

Developers onder de indruk

Tijdens de lunches en breaks verder op de dag sprak ik met diverse mensen waaronder, enkele developers uit de UK, die waren enthousiast over de nieuwe diensten rondom machine learning. En ook ik ben onder de indruk van de golf aan mooie aankondigingen. Morgen maar eens kijken of ik kan deelnemen aan een van de sessies van de vandaag gelanceerde diensten en de komende weken maar eens verder in verdiepen. Vandaag nam ik zelf nog deel aan een IoT leaders-workshop en een talk omtrent de eerder deze week gelanceerde dienst AWS Ground Station.

(Dit artikel verscheen eerder in Computable in November 2018)

AWS innoveert zijn basisdiensten

In Las Vegas vindt jaarlijks in november het AWS Re:Invent plaats. Ook de achtste editie van dit Amazon Web Services-evenement - grootschaliger dan ooit met ruim 52.000 bezoekers en duizenden verschillende workshops, talks en sessies verspreid over zeven hotels - staat in het teken van product- en feature-lanceringen en kennisdeling. Jeroen Jacobs, cloudconsultant bij Oblivion Cloud Control, is ter plaatse en doet als Computable-expert dagelijks verslag. Dag 4.

Na de keynote vol productlanceringen van AWS-ceo Andy Jassy gisteren, is vandaag de keynote van CTO Werner Vogels het hoogtepunt van de dag. Donderdag is tevens de laatste dag van re:Invent. De conferentie wordt vandaag met een groot eindfeest re:Play afgesloten.

Werner Vogels start zijn keynote met terugkijken naar zijn slechtste dag bij Amazon. Dit was 12 december 2004: de dag waarop Amazon garandeerde zijn zendingen voor kerst te leveren. De database van het shopping platform was maximaal opgeschaald en plots klapte het systeem eruit. Een bug in de database logging resulteerde in twaalf uur downtime op een van de meest cruciale dagen in het jaar. Van deze failure heeft Amazon veel geleerd. En die leerpunten zien we terug in het huidige dienstenaanbod van AWS. Vogels vervolgde met een doorkijkje naar de achterliggende technologie en architectuur van de AWS-diensten.

AWS Aurora

"Ondanks de verbeteringen met Aurora is de relationele database niet altijd de beste oplossing"

Everything fails all the time’. Het minimaliseren van de impact is dus van belang, reden voor AWS om met cell based architectures binnen de zogeheten availability zones te werken. De technische doorkijk begon gericht op databases. Relationele databases zijn ontworpen in de jaren tachtig voor andere hoeveelheden data. Deze zijn niet ingericht voor cloud en wereldwijde implementaties. We moeten weg van de jaren tachtig-databaseprincipes en het bedrijf heeft daarom AWS Aurora als relationele database-oplossing met database aware storage. Aurora repliceert zes keer met selfhealing-principes als een cell of zelfs een volledig datacenter faalt. Aurora is de cloud native-database en de basis voor innovatie, stelt Werner.

Ondanks de verbeteringen met Aurora is de relationele database niet altijd de beste oplossing. Kijkend naar de workload van AWS-klanten betreft ongeveer van 70 procent van de queries een single key value request, 20 procent meerdere rows en slechts 10 procent echt relationeel uit meerdere tabellen. Ook binnen een applicatie is het dus belangrijk per usecase de juiste database oplossing te selecteren. In 2012 lanceerde AWS DynamoDB en ook Amazon zelf heeft met AWS Database migratieservice zonder downtime veel workload binnen het retail-platform overgebracht naar DynamoDB. In DynamoDB heeft AWS nu automatic resharding toegevoegd, wat onder water zorgt dat op fysieke storage de performance gelijkmatig blijft schalen.

Amazon S3

De tweede core AWS-dienst waar een kijkje onder de motorkap werd gegeven was S3. Mai Lan Tomsen, verantwoordelijk binnen AWS voor onder meer S3, vertelde de essentie van S3. ‘Exabytes of Storage, Terabytes per second, It just works’. S3 is een van de eerste diensten van AWS in 2006. Het had toen acht  microservices as feature op S3. Momenteel zijn er dat 235+.

Durability op S3 storage is kern voor AWS. ‘Our commitment to your data’. En zo ontwikkelde AWS een echte ‘culture of durability’. Elke dienst krijgt een durability review (static analyses, checksums en spoofs, durability-checks en operational safeguards). Ook S3 kan een volledig datacenter missen.

AWS Redshift

Vogels vervolgde en keek naar zijn beste Amazon dag dit jaar. Dat was 1 november. Op die datum heeft Amazon een van de grootste Oracle datawarehouses uitgezet en vervangen voor AWS Redshift. Bijzonder genoeg merk je dat AWS deze re:Invent enkele keren met impliciete statements uithaalt naar Oracle. Iets wat AWS normaliter nooit doet. Oracle heeft natuurlijk recent zeer open en agressief de aanval op AWS gedaan in media-uitingen, dus AWS zet Oracle tijdens zijn conferentie weer even op zijn plaats.

AWS claimt dat Redshift voor Amazon Retail 17 keer meer performance voor queries biedt en tien keer meer voor bulk delete. En het product is voor alle klanten 3,5 keer sneller dan zes maanden geleden. Dit komt door productverbeteringen aan de achterzijde. Voor 87 procent van de queries op AWS Redshift hoeven klanten niet te wachten op de output van de query, maar Vogels stelt dat AWS niemand wil laten wachten. Daarom introduceert hij Redshift Concurrency Scaling. Voor elke 24 uur Redshift gebruik kan een klant één uur gratis bursten. Builders hoeven dus niet meer te wachten.

Na Redshift kwam de chief product officer van Fender Digital, een dochter van Amerikaanse producent van muziekinstrumenten en muziekapparatuur, op het podium. Hij vertelde hoe AWS het bedrijf helpt te digitaliseren. Fender, ontwikkelaar van apps, websites en ict-tools, koos voor AWS om zicht geen zorgen te hoeven maken over de infrastructuur en om te kunnen schalen. Het bedrijf beweegt naar volledig serverless en wil machine learning inzetten voor betere klantervaringen. Ook een voice interface staat op de roadmap bij de leverancier.

AWS Lambda

Vogels vervolgt met serverless. Sinds de lancering in 2014 zijn veel features toegevoegd aan AWS Lambda, maar ook deze re:Invent worden er zaken aangekondigd. ‘95 procent of AWS feattures and services are built based on direct customer feedback’, zegt hij. En daaruit volgt toevoeging van de AWS ontwikkel-toolkit voor PyCharm, IntelliJ en Visual Studio Code. Ook maakte de cto bekend dat Ruby-ondersteuning is toegevoegd aan AWS Lambda.

Om iedere developer in zijn eigen taal te kunnen laten bouwen, beschikt het product nu ook over ‘Custom Runtimes’. Hiermee kan elke Linux compatible runtime codes worden gebruikt. Denk aan bijvoorbeeld PHP en Cobal. Verder kreeg Lambda nog de toevoeging van Lambda Layers. Dit scheelt duplicatie van code door de mogelijkheid voor refereren.

Voor orkestratie van serverless apps, is er AWS Step Functions. Binnen Step Functions zijn er nu integraties met acht andere veel gebruikte AWS-diensten aangekondigd. Tot slot in het serverless-domein ondersteun de AWS api gateway nu ook Websocket en kan de AWS Application Load Balancer nu ook naar Lambda loadbalancen.

Meer cloud adoptie in Nederland

"Er zijn nog steeds veel bedrijven in Nederland die niet met AWS werken"

Ik ben echt onder indruk hoe groot de AWS-community op wereldschaal is. Ondanks dat ik als AWS-cloudconsultant bij onze klanten dagelijks tot innovatieve oplossingen op AWS zie ontstaan, realiseer ik me dat we in Nederland nog veel meer adoptie zullen gaan maken. Ondanks dat er wel degelijk niveau innovatie met AWS bij aardig wat van onze klanten al plaatsvindt, zijn er ook nog steeds veel organisaties zonder AWS. Natuurlijk ben ik wat bevooroordeeld, maar in mijn ogen zou elke organisatie moeten experimenteren met of zich verdiepen in AWS. Mijn missie voor 2019: Zo veel mogelijk organisatie AWS enabled maken en ze meer leren over deze technologie.

(Dit artikel is eerder verschenen in Computable in November 2018)

Amazon Web Services opent kantoor in Amsterdam

Bij de officiële opening van het kantoor van Amazon in Amsterdam werden er presentaties gegeven door Werner Vogels (Chief Technology Officer en vicepresident van Amazon.com) en Prins Constantijn van Oranje-Nassau.

Het was de aanleiding voor korte Interviews met Kamini Aisola (AWS) over de samenwerking met klanten en partners. Jeroen van der Leer (Product development manager ABN AMRO) en Thomas van de Weerd (CEO Pathe Thuis) vertellen over de reden voor de samenwerking met AWS en Oblivion Cloud Control.
Edwin van Nuil (Managing director Oblivion Cloud Control). licht de samenwerking met AWS kort toe.

Award-regen op de AWS Partner Summit Benelux 2018

De derde editie van de Amazon Web Services (aws) Benelux Partner Summit vond dinsdag 26 juni plaats in Amersfoort. Een jaarlijkse dag voor aws partners met interessante lezingen, break-out sessies, netwerkmomenten en nu voor het eerst de AWS Partner Awards met interessante winnaars.

Uitreiking AWSome Awards

Na een welkomstwoord van Arjen Vriens (Head of Benelux Partners & Alliances) startte de dag met een keynote bestaande uit drie sprekers: Kamini Aisola, Head of AWS Benelux, nam de Partners mee in de cijfers en trends in de globale en Benelux aws markt, die nog steeds verbazingwekkend groeiende is. Vervolgens nam Jeroen van de Leer, product platform owner manager bij ABN AMRO, het woord en deelde zijn visie en ervaring over de internet banking backend services en de Tikkie app op aws en welke aws partners hij specifiek hiervoor heeft ingezet. De keynote sloot af met Sebastian Helin, Head of EMEA partners, over het belang van het aws partner netwerk.

Na de keynote volgden diverse lezingen. Variërende van SAP, Microsoft en VMware workloads op aws tot aan de aws marketplace, de aws well architected framework en het aws partner competency program.

Award regen

Ondanks de zonnige dag, regende het aan het eind van de middag Awards in Amersfoort. De AWS Partner Awards 2018 werden persoonlijk door Arjen Vriens uitgereikt. De meest in het oog springende Award hierbij, genaamd AWSome Award, ging naar Oblivion cloud control voor de prestaties op alle facetten in het partnership. 

Totaal werden negen Awards uitgereikt waarvan vier voor Standard Tier partners en vier voor Advanced+ Tier partners. De AWSome Award werd uitgereikt over het geheel, ongeacht de behaalde partner Tier.

Award winnaars 2018

AWSome Award: Oblivion Cloud Control, voor behalen van de Premier Partner status en resultaten op alle vlakken.

Proficiency Award
Standard Tier: Conclusion, voor de meeste behaalde AWS Accreditaties in het afgelopen jaar.
Advanced+ Tier: Sentia, voor het behouden van de Managed Service Partner status.

Business Award
Standard Tier: McCoy, vanwege de bijdrage in de AWS gerelateerde omzet.
Advanced+ Tier: Cloudar, eveneens door hun geweldige AWS omzet bijdrage.

Innovation Award
Voor deze categorie konden partners innovatieve projecten nomineren.
Standard Tier: Crystalloids
Advanced+ Tier: 4Synergy

Rising Star Award voor hard groeiende en veel belovende partners.
Standard Tier: OlinData
Advanced+ Tier: Xebia

(Dit artikel is eerder gepubliceerd in Channelweb, in Juli 2018)

Jeroen Jacobs
Cloud Strategie Event trekt digitale top

Woensdag 6 juni vond in Zaamdam het Cloud Strategie Event plaats waar de digitale top van het bedrijfsleven ervaringen uitwisselde en sprak met vendoren van cloudoplossingen en -diensten.

De dag ging van start met een keynote van trendwatcher Igor Beukers. Beukers nam het publiek mee in de actuele trends van blockchain, IoT, asteroid mining en artifical intelligence, tot aan de shift in user interface van keyboard tot aan AI-voice. Centraal thema in zijn betoog was de snelheid van innovatie en dat bedrijven hierdoor actief en gedurfd hun oude gewoontes en paradigma’s moeten durven verlaten. Adapt the trends, unlearn, relearn. 'Out of your comfort zone is where it happens. Kodak had de nieuwe Instagram kunnen zijn en Nokia de nieuwe Facebook', aldus Beukers.

Ook moeten we volgens hem stoppen met de discussies over return on investment bij innovatie. De discussie moet gaan over 'risk of inaction'. Innovatie moet onderdeel zijn van de bedrijfscultuur en is geen afdeling. Juiste mindset en willingness zijn hierbij belangrijker dan skills. En helaas zien we vandaag de dag nog steeds de nieuwe Kodak- en Nokia-situaties ontstaan. Terwijl Elon Musk en Richard Branson al successen boeken in de ruimte, worstelt nog menig vliegtuigmaatschappij met het leveren van fatsoenlijke wi-fi aan boord.

Organisaties aan het woord

Na de keynote spraken diverse sprekers uit het bedrijfsleven hun leerpunten in de adoptie van cloud. Perry van der Weyden, cio van Rijkswaterstaat, startte met zijn verhaal hoe cloud en intelligente diensten helpen met het voorspellen van onderhoud aan de Nederlandse infrastructuur. Vervolgens presenteerde Joost van der Vlies, head of architecture, hoe PostNL van brievenbedrijf naar digital company transformeert met inzet van cloud. Hij gaf hierbij toe dat de eerste focus met cloud als een kostenbesparende actie was ingezet, maar dat later echt vanuit een app centric approach het juist SaaS-, PaaS of IaaS-platform werd gekozen.

Inmiddels is PostNL zover dat cloud echt als businessmodel wordt gezien. Zo levert PostNL een platform, Flora@home, aan bloemenwinkels en veilingen om via api's bloembestellingen van veiling tot aan huis te regelen. Een van de laatste sprekers uit het bedrijfsleven was ING’s head of cloud, Wouter Meijs. Zijn boodschap: de bank is een platform. ApiI's are key.

In gesprek over cloudtechnologie

Naast bedrijfsleven kwamen ook leveranciers en technologiepartners aan het woord. Veel talks werden ingezet op security, cloudadoptie en architectuur. Vanuit security is het interessant om te beseffen hoe cloud de risico’s verandert. Enerzijds wordt security ontzorgd en verbeterd, anderzijds ontstaan nieuwe risico's. Hierbij werd de 'risk of misconfiguration' aangehaald als misschien wel een van de grootste nieuwe risico’s. De leveranciers waren ook gesprekspartner voor de cto’s, cio’s en enterprise-architecten die aanwezig waarden.

Ik was aanwezig als een van de leveranciers gericht op public cloud concultancy en sprak ook vele organisaties. Het was inspirerend te horen dat organisaties al echt bezig zijn met hetgeen waar Beukers voor waarschuwde. De meeste grotere bedrijven denken al echt verder met cloud dan pure IaaS. Er wordt echt strategisch nagedacht hoe PaaS-services waarde kunnen toevoegen aan applicaties en bedrijfsmodellen. Gesprekken gingen dan ook als snel meer over digital transformation, dan over cloud. IoT was hierbij een veel besproken thema.

To infinity and beyond

De dag sloot af met een keynote van Astronaut André Kuipers, die zijn ervaringen deelde van zijn twee ruimtereizen. Zowel vanuit technologie, innovatie als mindshift een inspirerende, afsluitende talk. Voor mij een duidelijke strekking uit zijn space-verhaal: 'innovate to infinity and beyond'.

(Dit artikel werd eerder gepubliceerd in Computable in Juni 2018)

Cloud Center of Excellence (CCoE)

Met de groei van enterprise workloads op public-cloudplat- formen als Amazon Web Services (AWS) of Microsoft Azure wordt ook het vraagstuk cloud-operations steeds actueler. Sommige CIO’s brengen het beheer onder in hun bestaande (soms uitbestede) IT- organisatie. Andere CIO’s starten bewust een cloudcenter of excellence (CCoE). Maar wat is nu een CCoE eigenlijk? En hoe zet je dit succesvol neer? Auteurs Edwin van Nuil en Jeroen Jacobs hebben meerdere CCoE-implementaties uitgevoerd en delen in dit artikel hun ervaringen en lessons learned.

Het beheren van een cloudplatform als AWS is niet te vergelijken met het beheer van een private datacenterstack. Dergelijke platformen vereisen andere competenties en kennen een andere dynamiek. Het runnen van cloud-operations als traditionele IT-operations is helaas nog steeds een veel- gemaakte fout. CloudOps wordt dan vaak in de bestaande organisatie ‘erbij gedaan’. Gevolg: traditionele ITIL-processen, meerdere afdelingen en manueel beheer van het cloudplatform. Cloudpractices als beheer via infra-as-code en gebruik van cloud- native diensten worden achterwege gelaten. Hierdoor worden de voordelen die de public cloud biedt gemist en komt de beheersbaarheid sterk onder druk te staan.

Beheer moet anders

Cloudplatformbeheer dient anders te worden georganiseerd dan het beheer van een datacenterstack. Dit komt omdat public cloud vanuit een andere filosofie is neergezet. Een belangrijk voorbeeld hiervan is de focus op de softwareontwikkelaar alsook het feit dat een cloudplatform softwaregebaseerd is.

Softwaredevelopers en infra-engineers werken in de cloud dan ook intens samen. Geen fysieke hardware en integratie-uitdagingen meer tussen netwerk, compute en storage teams, maar één platform waarin alles integraal werkt en via code gemanaged en geautomatiseerd kan worden. Ook worden kant-en-klare applicatiebouwstenen aangereikt als managed databases en message-queues.

Tot slot is het pay-per- use-gedachtegoed een belangrijk aspect. Waar voorheen budgetcycli de financiën in control hielden, drijft nu de engineer direct de kosten. Voordeel daarentegen is dat investeringen in nieuwe technologie tot op de milliseconde kunnen worden verrekend, wat de innovatie drijft. Deze aspecten vereisen een integraal team en een andere aanpak van beheer.

Kenmerken van DevOps-teams

Een CCoE heeft een aantal specifieke kenmerken. Vanuit het DevOps-gedachtegoed is er een sterke business/applicatie- focus en is het team agile georganiseerd. Het team werkt bij voorkeur ook in sprintcycli voor de planbare werkzaamheden en streeft door middel van automation naar zoveel mogelijk stabiliteit, planbaarheid en voorspelbare activiteiten. Een zo goed als lege incident-queue zien we dan ook als een key-succesfactor. Verstoringen zijn immers uitzondering en zijn direct urgent en worden opgepakt, of worden planbaar.

Schermafdruk 2019-08-28 10.02.16.png

De teamsamenstelling van een CCoE is multidisciplinair en niet te groot, vijf tot tien man maximaal – het liefst een mix van business, architectuur, security, infra en applicatieontwikkelaars. Aangezien het cloudplatform via infra-as-code wordt gemanaged, vereist de operationele skillset over het algemeen meer een developers mindset dan een infrabeheer mindset. Belangrijk voor succes is de teamleden hierop te selecteren.

Cloud center of excellence vanuit functioneel perspectief

Ook vanuit functioneel perspectief is het aan te raden om CloudOps anders op te zetten dan het traditionele ITIL- beheermodel. Dit wil niet zeggen dat er bijvoorbeeld geen incidentmanagement plaatsvindt, maar een en ander dient te gebeuren vanuit een DevOps-gedachtegoed. Om de functionele scope van een CCoE weer te geven, kan het CloudOps- framework dienen. Dit model is ontstaan uit inzichten uit het Cloud Adoption Framework van Amazon Web Services, concepten uit het DevOps-gedachtegoed aangevuld met eigen implementatie ervaringen uit de praktijk.

EEN VEELGEMAAKTE FOUT IS HET RUNNEN VAN CLOUD OPERATIONS ALS TRADITIONELE IT

Het CloudOps-framework is opgebouwd vanuit een business/applicatiefocus en een operationele focus. Binnen die gebieden zijn CCoE-functies benoemd die hieronder worden toegelicht. Het is belangrijk om deze functies als kerncompetentie onder te brengen in het CCoE.

Schermafdruk 2019-08-28 10.02.06.png

In de operationele laag beginnen we met service provisioning wat het uitleveren en wijzigen van cloudservices (resources) betreft. Anders dan bij traditionele IT worden diensten niet via een grafische interface (console) bij elkaar geklikt, maar in code gedefinieerd in een template. Deze templates worden via code deployment pipelines en source code repositories gemanaged en geprovisioned.

De tweede functie is daily support wat betreft de operationele ondersteuning aan afnemers van de cloud services. Denk aan het oplossen van incidenten en het verwerken van kleine verzoeken en vragen. Hoewel dit klassieke ITIL-processen lijken, houden we dit lean en mean, met het doel alles binnen één team op te lossen. Continuously monitoring betreft het monitoren op performance en resiliency van de workload op het cloudplatform. Hierbij geen traditionele monitoringschermen met kleurtjes, maar vooral slimme alerts die een self-healingactie starten of de engineer van dienst een bericht sturen om te acteren.

Een ander deel van deze CCoE- functie is het logmanagement. Cloudservices genereren veel logs en metadata. Hier de juiste informatie uit halen en op acteren behoort ook tot de scope. Cost capacity & control is de plannende en bewakende functie gericht op de kosten en servicelimits van een cloudplatform.

De pay-per-usegedachte geeft de engineer direct de macht om de kosten te maken. Inzicht en goede controls hierop zijn essentieel. Automation zit wat ons betreft over de business en operationele functies heen en is in een CCoE een continu proces dat wordt gedreven door de CCoE-leden zelf. Dagelijkse beheertaken automatiseren maar ook zaken die de applicatie/business ondersteunen. Securitymanagement is key en zeker op public cloud. Met zaken als shared responsibility en een grote variëteit aan diensten, is het essentieel te snappen waar het de verantwoordelijkheid van de afnemer van de clouddienst betreft. Daar waar op private stacks de security veelal generiek op bijvoorbeeld de netwerk laag is geregeld, is dit op public cloud iets wat ook zeker per applicatie geregeld wordt.

De activiteiten in de toplaag van het model zijn tactischer van aard. Business demand is actief binnen de organisatie op zoek naar cloud-opportunity’s en het vertalen van business uitdagingen naar oplossingen op het cloudplatform. Architecture patterns richt zich op het verzamelen en definiëren van cloud practices en standaarden binnen de organisatie. Met de bouwstenen op de cloud, kunnen applicatieteams alle kanten op. Uniformiteit en best practices zijn be- langrijk om het beheer consistent en efficiënt te houden.

De laatste functie is projectsupport, dat zich richt op participeren in applicatie en business projecten om cloudkennis effectief in te zetten en een succesvolle overgang naar support in het CCoE te realiseren. Deze functies/competenties omvatten de kern van een CCoE. We blijven het bewust functies noemen en geen processen.

Split tussen applicatieteams en het CCoE

Alhoewel applicatie en infra op een cloud- platform integraal is, richt het CCoE zich veelal op de generieke kennis en platformactiviteiten. Applicatieteams maken vervolgens gebruik van de cloudservices geleverd door het CCoE. Omtrent de demarcatie van CCoE en applicatieteams hanteren we vaak nevenstaand model (zie figuur 3, in dit voorbeeld gevuld met de AWS-servicecategorieën).

Schermafdruk 2019-08-28 10.01.58.png

De donkere vlakken onderin zijn generiek en worden in de meeste gevallen volledig door het CCoE gemanaged. De lichte vlak-ken zijn qua kennis wel gecoverd in het CCoE maar worden in de uitvoering door de applicatieteams zelf ingericht en beheerd. Virtuele servers (compute) en managed databases zijn twee diensten die we eruit willen lichten. In veel CCoE wordt server-OS-management als added value geleverd op de IaaS-computeservices. Dit wordt dan wel conform cloudprincipes geleverd zoals bijvoorbeeld volledig geautomatiseerde patching. Toch is de demarcatie, zelfs binnen één organisatie, niet altijd uniform. Applicatieteams die zelf software ontwikkelen, hebben immers andere behoeften dan standaard commerciële software.

Succesfactoren bij implementatie

Het implementeren van een CCoE is niet eenvoudig maar de volgende factoren dragen positief bij. Het initiëren van het CCoE start idealiter bij het begin van cloudadoptie. Initieel als projectteam, maar zodra de eerste applicaties runnen ook echt met een operations-mindset. Vaak start het projectteam deels met in- terne medewerkers en deels met externe cloudconsultants. Doel is dat de interne medewerkers hands-on een snelle leer- curve doormaken en uiteindelijk de rol van de externe consultants overbodig maken. Een ander belangrijk aspect is de positie in de organisatie. Het team moet zichtbaar en identificeerbaar zijn en afhankelijk van de fase waarin de cloudadoptie zich bevindt, is strategische versus operationele plaatsing in de organisatiestructuur een belangrijke afweging.

Een ander punt is dedication. We raden altijd aan om met een klein team te starten omdat code-based infra managen voor de meeste engineers buiten de comfortzone ligt. Dit vereist veel aandacht en hands-on begeleiding, want met alleen trainingen kom je er niet. Ook is een klein team sneller op elkaar ingespeeld en gaan software en infradisciplines elkaar versterken. Wanneer echter na enige tijd het CCoE een groot en ervaren team begint te worden, is het raadzaam om te herevalueren om de business- en ops-functies apart verder te laten schalen.

Tot slot willen we nog meegeven dat het opzetten van een cloudcenter of excellence gepaard gaat met ‘fail fast, learn fast’. Zoals elk team gaat het door fases van euforie en tegenslag en haalt ook niet ieder teamlid vanzelfsprekend de gewenste eindstreep. Start daarom vroegtijdig voordat de grote workloads op de cloud gaan draaien en zoek en deel zeker ervaringen met andere organisaties binnen of buiten de sector.

Jeroen Jacobs (jeroen@oblcc.com) is cloud- consultant & projectleider en Edwin van Nuil (edwin@oblcc.com) is managing director bij Oblivion Cloud Control B.V.

(Dit artikel is eerder verschenen in Mei 2018 in CIO Magazine - hieronder vind u de embedded versie)

Edwin van Nuil
Cloud adoptie en GDPR zijn van eerste AWS Public Sector Summit

Op donderdag 18 april vond in het hart van de EU in congres gebouw ´The Egg´ te Brussel de eerste Amazon Web Services EU Public Sector Summit plaats. De scope van publieke sector reikte tijdens dit event van overheid en EU tot de sectoren educatie en healthcare en wist een opkomst te realiseren van meer dan vijfhonderd deelnemers. Mark Biesheuvel en ik bezochten dit event en highlighten in dit verslag de belangrijkste punten.

In de ochtend werd de keynote ingeleid door Teresa Carlson, vice-president of Worldwide Public Sector, Amazon Web Services, en zat vol met customer stories uit de publieke sector. Ook deed zij namens Amazon Web Services een aankondiging, namelijk de lancering van AWS Institute. AWS Institute is een kennisdelingsintiatief waar leiders van organisaties binnen een sector met elkaar ervaringen uitwisselen omtrent grote uitdagingen en hoe technologie daarin zaken kan enablen.

GDPR all over the place

"GDPR is geen checklist maar een strategie die continu door de organisatie stroomt. "

Met nog een maand te gaan tot de veel besproken GDPR-datum van 25 mei, was GDPR duidelijk een van de key thema’s, zeker ook in de publieke sector. Belangrijke noot die AWS wil meegeven is dat alle AWS diensten GDPR compliant zijn, echter is ook hier essentieel dat organisaties hun rol in het kader van 'shared responsibility' kennen. Ook volgde nadrukkelijk het advies dat GDPR geen checklist is maar een strategie moet zijn die continu door de organisatie stroomt.

Een andere sessie ging over AWS en de Cispe Code of Conduct for data protection. Deze code of conduct stelt strikte eisen voor infra structuur cloud aanbieders en stemt overeen met de GDPR-eisen. Dit biedt ook een kader om klanten en eindgebruikers te helpen bij het selecteren van cloud providers en het vertrouwen van hun diensten. AWS heeft deze code of conduct ondertekend en geadopteerd.

Hogere cloudadoptie

Een van de verrassende aspecten vonden we toch wel de relatief hoge mate van public cloudadoptie binnen de publieke sector. Zo presenteerde bijvoorbeeld de Europese Commissie dat public cloud enorm heeft geholpen sneller nieuwe digital initiatieven te ontplooien. Met name de global presence van AWS met hun infrastructuur was hierbij een belangrijk aspect. Een vertegenwoordiger van het Belgische agentschap van wegen en verkeer vulde daarbij aan met een case waarbij volgende week een nieuwe website gelanceerd wordt waar de bevolking van België gaten en slechte plekken in het wegdek eenvoudig kunnen melden. De site was zo goed als volledig serverless gebouwd op S3 en Lambda en draait volledig in de cloud.

Toch een van de meest inspirerende talks vonden we die van Skinvision-cto, Breght Boschker, die vertelde over hun missie hoe ze met Amazon Web Services en het daarop gebouwde Skinvision platform het komende jaar 250.000 levens willen redden in het voorkomen van huidkanker in te late fase. Skinvision biedt een laagdrempelige app waarmee je een moedervlek fotografeert en instuurt. Met onderliggende machine learning diensten van AWS wordt de foto geanalyseerd en zijn ze inmiddels in staat een hogere nauwkeurigheid te realiseren dan een ervaren dermatoloog. Kortom, een hele mooie use case van hoe technologie levens kan redden.

Tot slot

Aan het eind van de dag, diverse technische en managementtracks verder, spraken we tijdens een goed verzorgde netwerkborrel nog verder. Belangrijke conclusie die nogmaals onderstreept werd tijdens de gesprekken is dat technologie slechts een deel is van de digitale transformatie formule. Mensen en organisatie daaromheen zijn uiteindelijk de initiatiefnemers van het bedenken van mooie toepassingsmogelijkheden.

(Dit expertverslag werd gemaakt met medewerking van Mark Biesheuvel van Oblivion Cloud Control en werd eerder gepubliceerd in Computable in mei 2018)

Datacenter exit, Enter the Public Cloud

Strategische adoptie van public clouddiensten staat voor geen enkele CIO meer ter discussie. Echter wanneer uw organisatie weer voor het vraagstuk staat, de vijf jaarlijkse grote herinvestering te doen in het corporate datacenter, wat is dan wijsheid? Wanneer is gaan voor 100% cloud en een Datacenter exit haalbaar? En wat zijn nu interessante workloads voor de public cloud? Edwin van Nuil en Jeroen Jacobs brengen in dit artikel hun, vanuit praktijk opgebouwde visie, op dit vraagstuk.

Het periodieke datacenter herinvesteringsvraagstuk, kan vandaag de dag niet meer beantwoord worden zonder zorgvuldig de afweging met public cloud te maken. Recent maakte Barclays Bank in dit kader hun drijfveren achter de all-in public cloud aanpak bekend. Voor hen is public cloud het instrument op in te kunnen spelen op het “ever-changing financial service landscape”. Inmiddels zijn er ook vergelijkbare cases van andere enterprises en hebben wij zelf een aantal organisaties in hun datacenter exit naar Amazon Web Services mogen transformeren. Toch moet datacenter exit niet een doel op zich zijn als daar geen heldere cloud-businessdrivers aan ten grondslag liggen.  

HELDERE CLOUD DRIVERS

Het strategisch stellen van richtinggevende drijfveren voor public cloud adoptie is key. Grofweg zien we enterprises twee primaire argumenten aangrijpen voor adoptie van public cloudplatformen. De eerste reden is kostenbesparing, danwel kostenflexibiliteit. De andere is innovatie en snelheid van innovatie. Security/Compliancy verbetering wordt soms nog als bijkomende driver genoemd en bij SaaS diensten specifiek komt user experience en inventievere way of working ook nog vaak naar boven. Toch kan de afweging soms ook wat minder strategisch zijn en betreft het gewoon een operationeel of acuut probleem wat praktisch door transitie naar public cloud wordt opgelost. Bijvoorbeeld wanneer u op korte termijn gedwongen wordt het huidige datacenter of te verlaten of een IT-ontvlechting te doen omdat een organisatie onderdeel is verkocht.

CLOUD BASED IT LANDSCHAP

Nadat de clouddrijfveren helder zijn, kan een vertaling worden gemaakt naar het beoogde landschap. Centraal hierbij staat welke IT-platformen de applicatiefunctionaliteit en applicatiehosting moeten gaan ondersteunen. In figuur 1 schetsen we ons beeld op het IT-Cloudlandschap voor een gemiddelde Enterprise.  Rechts in de figuur projecteren we de SaaS applicaties als Office365, Gsuite, Salesforce maar ook sector specifieke SaaS oplossingen. Al jaren transformeren softwareleveranciers naar een SaaS model en ook meeste organisaties adopteren SaaS bij vervangingsinvestering indien voorhanden. Deze SaaS applicaties worden, nu al, vaak door de SaaS providers gehost op de grote publieke cloudplatformen als Amazon Web Services of Google, wat in de figuur de onderlaag is.

Figure 1 - Cloud gebaseerd IT Landschap

Figure 1 - Cloud gebaseerd IT Landschap

Links in het plaatje staan de specifieke applicatieworkloads, zowel Custom hosted als Custom developed applications. Hiermee bedoelen we ook standaardapplicaties die specifiek voor uw organisatie worden gehost in een afgeschermde omgeving. Vooral eigen ontwikkelde applicaties zullen meer en meer gebruik maken van PaaS services. Custom hosted zullen in de praktijk vaak nog de legacy applicaties zijn. In het midden hebben we bovenin de userinterface welke bij voorkeur Web & API/APP enabled is. Daaronder Identity-as-a-Service waarbij secure access, single-sign-on en accountprovisioning naar SaaS services gecontroleerd plaatsvindt. Het cloud identityplatform wordt ook de toekomstige primaire identity repository voor de organisatie.

Tot slot voorzien wij nog een dataintegratielaag die we Integration-as-a-service noemen. Tussen SaaS services loopt dit via APIs en met/naar custom hosted applications kan dit nog deels met traditionele protocollen zijn. De integraties zien wij vooral serverless gerealiseerd (AWS Lambda, Google Functions) of met oplossingen die prebuild integraties of integratie hub services aanbieden.

In de weergave figuur 1 is de traditionele datacenter stack niet weergegeven, maar uiteraard zouden we die links ernaast kunnen positioneren in de periode dat we over een hybride cloud spreken. Gebaseerd op deze landschapsplaat kunt u gaan projecteren welke applicatiefunctionaliteit waar onder te gaan brengen op korte en op middellange termijn. Dit noemen we application mapping. 

APPLICATION MAPPING

Een datacentervervangingsinvestering kan een enorme versnelling brengen in de transformatiebeweging naar public cloud, echter adviseren we (ook bij een full datacenter exit) toch per applicatie de afweging te maken. De mapping vanuit de applicatie start ook de discussie over welke cloud(s) wenselijk zijn in het landschap en waar opgeschoond of verSaaSed kan worden. Een door ons veel gehanteerd model hierbij zijn de cloudmigratiestrategieën die Amazon Web Services en Gartner 6R-model noemen. Dit model pakt  de kern met migratieopties die er zijn te weten:

  • Retain: Het behouden van de applicatie in huidige vorm op het huidige platform. Dit zien we vooral voor komen als de applicatie on-premise moet blijven.

  • Retire: Het uitfaseren van de applicatie. Veelal applicaties die eigenlijk nauwelijks nog gebruikt werden en alleen nog voor raadpleging aanstonden. De data archiveren (op de cloud) is vaak voldoende.

  • Rehost: Het letterlijk overbrengen naar een ander public cloud hostingplatform. Dit komt neer op het lift en shift migreren naar IaaS, soms met een managed database of managed fileshares als dienst. Bij snelle datacenter exit is dit de snelste route.

  • Replatform, Is het daadwerkelijk vervangen van componenten. Bijvoorbeeld MySQL vervangen voor AWS-Aurora.

  • Refactor komt alleen voor bij eigen ontwikkelde software. Dit betreft het herontwikkelen met nieuwe software code passend bij de cloud-native uitgangspunten.

  • Repurchase: Opnieuw aanschaffen van de softwarefunctionaliteit. In de cloudtransitie betreft dit vervangen voor SaaS alternatieven.

Zowel vanuit de cloudbusinessdrivers, de applicatieroadmap en architectuur, als financieel perspectief, wordt elke applicatie zorgvuldig tegen de opties aangehouden en de gewenste to-be situatie besloten. Wanneer de totale inventarisatie is gedaan, is de basis voor het cloudtransitie plan gemaakt. 

IDEALE WORKLOAD VOOR CLOUD

Public cloud platformen kunnen praktisch alle hedendaagse applicaties hosten (als lift en shift), echter benut de ene applicatie beter de voordelen van public cloud dan de andere. Onder mogelijke first movers vallen ondermeer vaak sandbox en training of tijdelijke omgevingen. Traditioneel staan die omgevingen dag en nacht aan. Op public cloud kunnen deze systemen snel en eenvoudig met scheduling uitgezet worden buiten kantooruren. In pay-per-use modellen levert dit enorme kostenvoordelen op. Een andere quick-win zijn publieke corporate webapplicaties/websites. Public cloud is uitermate geschikt om websites te hosten en biedt dan ook out of the box allerlei interessante add-ons zoals loadbalancing, anti-DDoS of Content Delivery Network welke uw webapplicatie aanzienlijk kunnen verbeteren. Bovendien zien veel organisaties het ook als een securitywinst niet meer in de eigen DMZ te hosten. Een derde interessante usecase is cloud gebruiken als storage extensie. Zowel voor backup als archiefstorage bieden public cloud platformen zeer scherp geprijsde en highly durable storage waarbij ook nog appliances meegeleverd worden om te integreren in het bestaande datacenter. Tot slot in de quick-wins zijn scriptservers. Met relatief kleine aanpassingen kunnen simpele platform automationscripts vaak serverless gerealiseerd worden.   

Buiten de quick-wins zijn vooral workloads interessant die echt voordeel halen uit de specifieke eigenschappen van de cloud. Dit hoeven niet direct full cloudnative designed apps te zijn, maar kan al simpelweg een databaseomgeving zijn die als PaaS dienst afgenomen wordt of High Available wordt gemaakt door de HA-failover feature aan te zetten. Ook applicaties die voordeel hebben van de global precense van een cloudplatform zijn interessant. De grote publieke providers stellen enterprises in staat om in regios over de gehele wereld applicaties te deployen. Applicaties die primair in Azië gebruikt worden hoeven bijvoorbeeld niet meer in het corporate datacenter in Europa te draaien en daarmee kan latency performance worden verbeterd. Schaalbare piek en batch workloads zijn interessant. Schaalbaar kan al werken voor veel applicaties die achter een load balancer zitten. Cloudplatformen zijn met die gedachten gebouwd. Tot slot hebben we de categorie waar echt native features van het platform kunnen worden ingezet. Denk hierbij niet alleen aan Big Data, Analitycs of IoT workloads, maar ook bijvoorbeeld vervanging van bestaande zelf te beheren oplossingen voor managed VDI of AppStream functionaliteit.

DATACENTER EXIT OF NIET?

De vraag datacenter exit of niet, moet initieel worden beantwoord vanuit de clouddrivers. Als de drijfveer puur innovatie is, wordt datacenter exit een minder relevante afweging. Als de afweging kostenbesparing is, dan is het maken van de rekensom de moeite waard. Wel is het belangrijk in de kostenvergelijk echt naar TCO te kijken. In Figuur 2 geven we een voorzet welke datacenter kostenelementen (Groen) wegvallen in de IaaS prijs. Ook is 20% rightsizing van de bestaande servercapaciteit niet onrealistisch en een besparing die meegenomen kan worden. Lukt een full exit niet, kijk dan of er in ieder geval geclusterd kan worden. Een specifieke Datacenter netwerkzone uitfaseren bespaart naast serverkosten ook netwerkapparatuur en beheer. Of richt op een functioneel gebied zoals bijvoorbeeld een backupoplossing of VDI-omgeving.

Figure 2 - IaaS TCO cost elements (Groene vlakken vallen weg in de IaaS prijs bij public Cloudproviders)

Figure 2 - IaaS TCO cost elements (Groene vlakken vallen weg in de IaaS prijs bij public Cloudproviders)

DATACENTERLESS IN DE PRAKTIJK

Na meerder datacenter exits gerealiseerd te hebben kunnen we stellen dat zelfs met een lift en shift aanpak de businesscase rond te krijgen is. Rightsizing en kleine voor de hand liggende improvements meenemen, wordt hierbij wel geadviseerd. Voor kleinere organisaties is het een datacenter exit een aanzienlijk eenvoudigere en meer voor de hand liggende stap dan voor grote enterprises. Zeker in enterprise context benadrukken we dat er echt van uit applicatieperspectief de afweging gemaakt dient te worden. Het blijft vervolgens een periodiek process om vanuit de applicatie-architectuur naar het cloudplatform te blijven optimaliseren. Tot slot willen we nog benadrukken dat het beheer van een cloudplatform via Infrastructure as Code andere skills vraagt dan beheer van traditionele datacenter stacks. In CIO Magazine #2-18 schreven we reeds onze visie hierop in het artikel omtrent Cloud Center of Excellence.

Edwin van Nuil is Managing Director bij Oblivion Cloud Control, Jeroen Jacobs is Cloud Consultant & Project Manager by Oblivion Cloud Control

(Dit artikel is eerder verschenen in CIO Magazine in Maart 2018)

Edwin van Nuil
Serverless, game changer in cloud computing

 Door: Jeroen Jacobs & Edwin van Nuil  

Cloud computing heeft de afgelopen jaren al menig (IT) organisatie aanzienlijke verbeteringen gebracht als het gaat om wendbaarheid, efficiency, innovatie en daarmee concurrentievoordeel voor de organisatie. Applicatieservers die initieel in gehuurde en gemanagede datacenters draaien, worden massaal verschoven naar public platformen als Amazon Web Services, Google Cloud Platform en Microsoft Azure. Hoewel deze shift vaak nog vooral gericht is op rehosten van servers, zijn de resultaten in zin van efficiency, flexibiliteit en wendbaarheid, alsook innovatie, al enorm. De volgende shift in cloud computing gaat echter niet meer over servers, maar is “Serverless”.

Als we de afgelopen twee decennia terug in de tijd kijken, zien we eigenlijk een continue run om dezelfde applicatiefunctionaliteit op steeds minder fysieke hardware te kunnen laten draaien. Deze trend ontstond begin jaren 2000 met de opkomst van virtualisatietechnologie gedreven door VMware. Door meer servers op één fysieke server te draaien werd enorm veel efficiency behaald en dat evolueerde zo jaren door.

De volgende grote stap was de start van public cloud computing. In 2006 lanceerde Amazon Web Services hun public cloud computing platform, in de begin jaren veelal gericht op Infrastructure as a Service diensten. In plaats van servers gevirtualiseerd op een eigen infrastructuur draaien, al dan niet in eigen of gehuurd datacenter, werd ingezet op grotere schaalvoordelen met hogere efficiency en wendbaarheid tot gevolg. Langzamerhand verschoof de focus breder van Infrastructure as a Service naar Platform as a service. Softwareontwikkelaars en applicatiearchitecten gingen daarop cloud-native denken, designen en implementeren. Ook de CIO binnen de enterprise ging serieus nadenken over een cloudstrategie.

Het cloud-native denken groeide door naar applicatiearchitectuur op basis van microservices waarbij in plaats van één grote monolithische applicatie, de functionaliteit werd opgeknipt in kleinere applicatie services die een samenhang hebben met elkaar. Deze kleinere functies kunnen vervolgens zelfstandig draaien, schalen en ontwikkeld worden. De populariteit van microservices ging hand in hand met containerization (Docker) waarbij deelfunctionaliteiten van een applicatie in containers gingen draaien. De laatste stap in deze evolutie is gezet met de lancering van Amazon Web Services Lambda. AWS Lambda is de grondlegger van de event based serverless computing wat we vandaag de dag “serverless” noemen.

De ontwikkeling van fysieke servers naar serverless

De ontwikkeling van fysieke servers naar serverless

Over Serverless

Serverless lijkt wellicht een vreemde benaming, want een cloudservice provider gebruikt uiteraard nog steeds servers, echter is er voor de afnemer van de serverless dienst geen zorg meer voor het inrichten en managen van de onderliggende servers. Eigenlijk is dit net zo als bij Platform as a Service diensten als bijvoorbeeld managed databases. Waar het bij serverless om draait is het verwerken/draaien van applicatiecode in programeertalen als bijvoorbeeld Ruby, Python of PHP. Bijkomend is, dat het verwerken van de applicatiecode gebeurt op basis van een trigger. Wat een trigger kan zijn is zeer breed variërend van het ontvangen van een upload van een file, het ontvangen van een email, scheduled event tot een API Request of trigger vanaf een andere serverless functie.

Vertaald naar applicatiearchitectuur is het gedachtengoed van serverless om net zoals bij microservices, applicaties op te bouwen uit businesslogic. De businesslogic definieer je in events en functies. Een event triggert een functie en een functie is simpel weg een stukje applicatiecode wat door het onderliggende cloudplatform wordt uitgevoerd.

Serverless georiënteerde applicaties zijn meestal niet uitsluitend gebouwd uit serverless diensten als bijvoorbeeld AWS Lambda. Naast applicatiecode draaien hebben meeste applicaties ook  behoefte aan bijvoorbeeld een stukje storage wat in gevuld kan worden met object storage als AWS S3 of NoSQL database storage met AWS DynomoDB en komen triggers ook vanaf extern waardoor de AWS API Gateway een oplossing kan zijn.  

Serverless is de game changer in cloud computing

Serverless cloud computing is absoluut de game changer in softwareontwikkeling en cloud computing. Doordat er geen servers meer nodig zijn voor het uitvoeren van applicatiecode vervallen veel van de nadelen die nog steeds bij cloud computing gelden. Software developers zijn hierdoor in staat om nog sneller te kunnen ontwikkelen en vooral ook hun tijd te kunnen besteden aan business requested features. Op de gebieden pay per use, beheer en schaalbaarheid worden de grootste voordelen behaald.

Ultime pay per use belofte ingelost

Ondanks dat Infrastructure as a Service diensten worden geleverd met een pay per use belofte,  betalen we in de praktijk eigenlijk nog steeds vaak teveel doordat servers veel idle time hebben. Ondanks dat zelfs tot op seconde kan worden afgenomen, blijft er altijd idle time. De regie om te schalen ligt namelijk bij de applicatie-developer, inframan of in het mooiste geval geautomatiseerd in de applicatie, maar schalen gaat nog steeds in eenheden van steeds een hele server. Daarentegen, wordt bij serversless eigenlijk alleen aangerekend naar de troughput die wordt verwerkt tot op honderden milliseconden nauwkeurig. U kunt zich voorstellen hoe veel efficiënter applicaties kunnen werken dan wanneer dit op een server of meerdere servers zou moeten draaien. 

Beheer(kosten)

Omdat we geen servers hebben, hoeven we geen medewerkers of derde partij meer te betalen om ze te provisionen, te onderhouden en te monitoren. Geen OS patching en hardening meer en ook geen gedoe met OS lifecycle managementprojecten. Buiten de besparing in effort, reduceert dit ook nog eens een aanzienlijk risico die alle changes en upgrades continue met zich meebrengen.  

Schaalbaarheid

Serversless computing wordt als hoog beschikbare dienst aangeboden. Er hoeft dus niet nagedacht te worden hoe de uitvoering van de applicatiecode op infrastructureel niveau hoog beschikbaar wordt gemaakt. Ook voor schaalbaarheid geldt dit mechanisme. De cloudprovider draagt continue zorg voor voldoende resources om de applicatiecode uit te kunnen voeren. Capaciteit is er gewoon en geen zorg meer van de developer.

Voorbeeld van de architectuur van een serverless applicatie

Voorbeeld van de architectuur van een serverless applicatie

Serverless in de praktijk

Sinds de lancering van Serverless met AWS Lambda, en later ook de equivalenten Azure Functions en Google Cloud Functions, groeit de toepassing van serverless enorm hard. Ook bij onze klanten zijn we eigenlijk direct al in 2014 gestart met het toepassen van serverless. We zagen al snel toepassing voor het bouwen van maatwerkfuncties binnen het AWS cloudplatform zelf. Het automatiseren van reguliere beheerscripts, controlefuncties en checks ‘serverless‘ oplossen is inmiddels dan ook een absolute standaard geworden bij onze cloud implementaties. Zo gebruiken we bijvoorbeeld AWS Lambda scripts om op basis van een gescheduled event backups van de Amazon EC2 IaaS dienst te maken en om virtuele EC2 servers buiten kantooruren af te sluiten om kosten te besparen.

Een andere recente case is een integratie tussen een HR systeem en een cloud identity platform. Het doel is om HR data gesynchroniseerd te krijgen naar het cloud identity platform. Dit sync proces loopt enkele keren per dag en leent zich daarom prima om serverless met python scripts op te lossen. De integratie kost de organisatie nauwelijks geld omdat het run proces qua resources zeer efficiënt is. Een laatste voorbeeld is een organisatie waarbij grote delen van de webapplicatie wordt vervangen door AWS Lambda functies. Technisch is het mogelijk de gehele applicatie zonder servers te laten draaien. Dat is ook voor deze applicatie de visie waar we naartoe werken. 

Niet alleen maar rozengeur en maneschijn

Het toepassen van serverless in het applicatielandschap is absoluut interessant, maar kent ook enkele nadelen. Het vereist nieuwe competenties binnen IT en een andere manier van applicaties architectuur. Bestaande applicaties moeten effectief omgebouwd worden om ze geschikt te maken voor serverless. Daarnaast is lock-in een belangrijk punt. Hoe meer gebruik wordt gemaakt van de bouwstenen van de cloudprovider, hoe meer de lock-in op het platform. Ditzelfde geldt voor het security vraagstuk. Door het runnen van code direct op het cloudplatform leggen we een belangrijk deel van de securitymaatregelen bij de cloudprovider. Tot slot performance, monitoring en debugging kan beperkter zijn. Serverless applicaties reageren anders en hebben een vorm van latency tussen functies. Qua monitoring en debugging zitten we met serverless ver boven het OS niveau en hebben we daarmee ook geen toegang tot OS level tooling en metrics. Ook hier zijn we aangewezen op wat de cloudprovider ons out of the box te bieden heeft. 

Toch een serverloze toekomst

Ondanks de nadelen leveren de voordelen veel meer op in termen van efficiency, wendbaarheid en innovatiesnelheid. ‘Serverless’ is naar onze visie eigenlijk geëvolueerd tot de eerste vraag bij het cloudnative migreren of bouwen van nieuwe cloudapplicaties. Vaak wordt serverless ingezet in een deel van de totale applicatieoplossing, aangevuld met diensten als API Gateways en PaaS diensten als databases, storage maar ook Docker en eventueel IaaS. De serverless trend en adoptie ontwikkelt zich naar verwachting de komende jaren hard door. Op zichzelf niet zo vreemd, want serverless is eigenlijk een veel betere en logischere manier om cloudresources te consumeren. Trends als Cloudnative, DevOps, Data analytics, Machinelearning en IoT zullen voor serverless, belangrijke drivers zijn en tot nieuwe innovatieve mogelijkheden en hoge efficiency leiden.

Over de auteurs

Jeroen Jacobs is Cloud Consultant & Projectleider bij Oblivion Cloud Control B.V. jeroen@oblcc.com; Edwin van Nuil is Managing Director bij Oblivion Cloud Control B.V. edwin@oblcc.com  

Oblivion Cloud Control B.V. richt zich op cloudvraagstukken en is één van de Amazon Web Services Nederlandse Consulting partners van het eerste uur. Naast Amazon Web Services tevens implemenatiepartner van complementaire platformen en diensten als onder meer Okta Identity en TrendMicro.

(Dit artikel is eerder gepubliceerd in CIO Magazine, Januari 2018)