How to become Cloud Architect of the year

How to become Cloud Architect of the year

With just over two months to go, the Cloud Architect of the Year election is quickly approaching. Cloud Architects in the Netherlands (and beyond) are anticipating the award show on January 30th 2020 with a mix of enthusiasm and anxiousness. Will peers recognize the monumental achievements some have fought so hard to realize? Will the jury notice how the cloud journey of ACME Inc. was secured by an ingenuous and novel take on cloud security? And what about the Cloud Engineers that have to deal with the nitty gritty of everyday cloud implementations?

This year, we’ve chosen to open up nominations for three categories: the Cloud Architect, Cloud Engineer and the Cloud Security Architect. Below, we will briefly discuss which characteristics are important to get nominated and maybe even win.

The Cloud Architect

As we described in our booklet ‘The high performing Cloud Architect’, a truly effective Cloud Architect has a vast array of knowledge on topics ranging from legal requirements to stakeholder management and business needs. He or she combines this knowledge with a thorough familiarity with different cloud technologies. The successful Cloud Architect always aims to realize an well-oiled machine of human interaction and cloud technologies that propels a business forward.

Cloud Engineer

For the first time in this elections’ history, we’ve included the category of Cloud Engineer. Even though the role differs from that of a Cloud Architect and in fact can be broken into multiple roles, the Cloud Engineer is important for the success of any cloud migration. He or she may be acting as cloud software engineer, cloud security engineer, cloud systems engineer or DevOps engineer. For this election, we are looking for the individual who excelled in his or her role as cloud engineer and had a large impact on the Cloud project he or she was involved in.

Cloud Security Architect

Last but not least, the final category is that of the Cloud Security Architect. As anyone who has been involved in Cloud adoption projects will know, business owners, compliancy and others tend to worry about Cloud security a lot. The Cloud security Architect is indispensable in allaying these fears with tried and true technologies and intelligent designs. The Cloud Security Architect of 2020 is the one who is on top of all security concerns related to Cloud and leads and mentors his or her team in applying the appropriate technical controls on cloud.

Nominate your peer!

That’s it! These are the categories in which you can nominate your peers. Hopefully we’ve shed some light on the criteria and characteristics that are important to win. Nominate your peers now and don’t forget to claim your free ticket for the election night (and deep dive on cloud-native data lakes) if you have not done so already. See you there!

On the secrets of stakeholder management

Stakeholder management is really important for any Cloud transition to succeed. Most Cloud adoption trajectories that fail do so because stakeholders have not been engaged properly. Whether its prior, during or after the transition: a lack of commitment from organizational leadership and the business will almost certainly result in failure.

Continue reading

Purpose of a Cloud Business Office – Videos of the presentations

Purpose of a Cloud Business Office - videos of the presentations

On July 4th 2019, the Cloud Architect Alliance organized an event about the purpose of the Cloud Business Office. During the event, no less than 4 speakers shared their viewpoint on stakeholder management and their experiences with a Cloud Business Office or similar horizontal engagement of stakeholders in an organization. The talks that were held during the night were recorded on video for everyone to enjoy.

Jonathan Allen - Cloud Leadership Team, Business Office, Platform Engineering & Stakeholders

In this video, recorded during the event, Jonathan Allen, enterprise strategist at AWS, talks about his vision on how to organize the different stakeholders of a cloud transformation.

Fred Streefland - How to ‘bridge’ the gap between Cloud Architects & the CISO?

In this video, Fred Streefland, CSO NEEUR at Palo Alto Networks, talks about his experiences with stakeholders in cloud transitions.

Bernard Drost -
Cloud Business Office

In this video, recorded during the event, Bernard Drost, VP & MD EMEA at Cloud Technology Partners, talks about the philosophy of the Cloud Business Office.

Arthur van der Wees -
In Cloud we Trust

In this video, recorder during the event, Arthur van der Wees, founder of international tech lawfirm Arthur’s legal, talks about how to build cloud architectures that are functional and trustworthy while keeping an eye on ‘non-functional’ such as GRC at the same time.

The high performing Cloud Architect

The high performing Cloud Architect

A concise guide to becoming a more effective Cloud Architect

As the role of the Cloud Architect in organizations matures, it becomes more widely acknowledged that the Cloud Architect is the linking pin for a successful digital transformation in enterprise settings. We believe it is prudent to elaborate on some essential competencies of the high performing Cloud Architect.

In this booklet, we have chosen to focus on the ‘people’ side of the Cloud Architect. We feel this is an often neglected but very important aspect of the Cloud Architect. The way a Cloud Architect handles organizational culture and behavior is what makes a high performing Cloud Architect stand out.


    The high performing Cloud Architect

    NetApp Kubernetes Service: Accelerated Application Development and Deployment at Scale

    NetApp Kubernetes Service

    Kubernetes has become the de facto platform for container orchestration and dominates the market for container orchestration solutions. All major cloud vendors now provide a managed Kubernetes service, such as Amazon Elastic Kubernetes Service (Amazon EKS) on AWS. In this guide our highly appreciated sponsor NetApp shows how NetApp Kubernetes Service (NKS) and Cloud Volumes Service for AWS can be used to deploy Kubernetes clusters with persistent storage in any of the major cloud environments. 

    NetApp Build@Scale uses these services to create a software development platform that accelerates application development in hybrid environments. The paper describes the benefits of using NKS and the advantages of using Cloud Volumes Service for provisioning storage, and demonstrates how Build@Scale works. It also looks at the RESTful API interface for Cloud Volumes Service for AWS, and shows how it can be used to perform basic operations, such as creating volumes, snapshots, and clones.


      De impact van de cloudstrategie op het bedrijfsnetwerk (Dutch only)

      Hoe zorg je ervoor dat het bedrijfsnetwerk de cloudstrategie ondersteunt en geen knelpunt wordt? Verkeersstromen draaien, knelpunten verplaatsen: sommige applicaties worden sneller, andere onwerkbaar traag. Het bedrijfsnetwerk en internetaansluiting worden na afloop van een cloudmigratie anders belast dan daarvoor. De impact van deze veranderingen goed inschatten blijkt lastig, maar het belang is groot: immers zonder een goed functionerend netwerk presteren de (SaaS)cloudapplicaties niet. In dit artikel leggen we uit waar op te letten bij het geschikt maken van het netwerk voor de cloudmigratie.

      Netwerkverkeervolgt applicatie
      Het netwerkverkeer (tussen client en server) volgt de applicatie; wordt een applicatie vanuit het datacenter gemigreerd naar een cloudproviderdan verdwijnt er een verkeersstroom richting het datacenter en ontstaat er een verkeersstroom op de internetaansluiting. Waar eerder voldoende capaciteit aanwezig was ontstaat nu krapte en andersom. Het inschatten van de benodigde netwerkcapaciteit na eencloudmigratie blijkt bijzonder lastig. Er zijn berekeningen te maken om de toekomstige netwerkbehoefte in te schatten, maar die berekeningen staan zo bol van de aannames en verwachtingen dat ze in de praktijk niet uitkomen. Ook kan de netwerklatency (de vertraging door de toegenomen afstand en het aantal tussenstations) flink toenemen wat de prestaties van de applicaties in de weg zit. Dat beïnvloedt de gebruikerstevredenheid en kan uiteindelijk de sfeer rondom de cloudmigratie gaan beheersen.

      Het netwerk als onderdeel van de cloudstrategie
      De vraag die als onderdeel van de cloudstrategie moet worden beantwoord is:

      Hoe zien de toekomstige verkeersstromen eruit en welke netwerktopologie past hierbij? Zijn de veranderingen zo groot dat het netwerk opnieuw ingericht/gecontracteerd moet worden?

      Er zijn modellen en tools beschikbaar om deze veranderende behoefte vooraf in kaart te brengen. Het probleem van dit soort ‘calculators’ is echter dat ze gevoed moeten worden met gebruiksprofielen zoals: “hoe vaak opent een gebruiker een groot PowerPoint bestand van Sharepoint” en “hoeveel grote e-mails ontvangt en verstuurt een gebruiker”. Deze aannames blijken in de praktijk ver te staan van het werkelijke gebruik waardoor het inkopen van netwerkcapaciteit op basis van deze berekeningen een hachelijke onderneming is. Beter is om tijdens de migratie het netwerkverkeer nauwgezet te monitoren en dan, in overleg met de leverancier, de bottlenecks op te lossen door de capaciteit op-of af te schalen. Deze capaciteit en flexibiliteit moet het contract met de netwerkleverancier dan natuurlijk wel bieden; dat is een aandachtspunt bij de contractering.

      Internetverkeer eerst centraliseren of kiezen voor het lokaal uitbreken vanaf de vestiging?
      Een belangrijke beslissing die bij het opnieuw inrichten van het netwerk moet worden genomen is: kiezen we voor een lokale break-out van internetverkeer op de vestigingen of centraliseren we al het verkeer en gaat het daar via een hoogwaardige internetaansluiting het internet op? In het pre-cloud tijdperk was het gebruikelijk om vestigingen onderling te verbinden met een Wide-Area-Network (WAN). Dergelijke gesloten (MPLS) netwerken bieden veel voordelen als het gaat om beveiliging en beheersing van de netwerkstromen maar als gevolg van de cloudmigratie worden ze minder relevant. De behoefte aan verkeer naar het centrale datacenter neemt af en snelle internettoegang is noodzakelijk. Daarbij geldt dat hoogwaardige internettoegang (Business Internet) inmiddels op bijna iedere locatie in Nederland tegen acceptabele kosten is te krijgen en dat capaciteit op de WAN-verbinding in de regel duurder is. In het geval van SaaS applicaties zoals Office 365 is ons advies te kiezen voor het lokaal uitbreken van het internetverkeer, dit geeft de beste prestaties en is voordeliger in gebruik. Een belangrijk argument daarbij is het verlagen van de netwerklatency, een tussenstop maken op de hoofdvestiging of in het datacenter (van de netwerkleverancier) voegt onnodige extra stappen en netwerklatency toe. Dit geldt ook voor de verplichte VPN-verbindingen die gebruikt moeten worden bij het werken buiten kantoor. Dat kan met name bij het gebruik van applicaties zoal Skype, Teams, Outlook en SharePoint het verschil maken tussen zeer goede prestaties en onwerkbaar.

      Een belangrijk argument om het kostbare WAN te ontdoen van ‘frivool’ internetverkeer zoals Youtube en Internetradio wordt minder relevant; uit recente ervaring met aanbestedingen blijkt namelijk dat de prijsverschillen tussen WAN en Business Internet langzamerhand kleiner worden. Dit maakt dat de businesscase voor de Internetaansluiting op de vestiging niet persé gerealiseerd kan worden door de besparing op de (voorheen flink duurdere) WAN capaciteit; er worden tenslotte extra verbindingen op de vestiging binnengebracht (met de bijbehorende kosten). Ook gaan er kosten gepaard met het organiseren van de beveiliging van die lokale breakout. De belangrijkste business driver voor het lokaal uitbreken van SaaS verkeer is de applicatiesnelheid en dus gebruikerstevredenheid.

      Verkeer naar Office 365 niet filteren of proxy-en
      Een andere belangrijke architectuurbeslissing moet genomen worden rondom het filteren en eventueel proxy-en van verkeer richting de Office 365 cloud en andere SaaS applicaties. Als organisaties gebruik maken van een webfilter en/of proxy dan wordt al het verkeer, zonder uitzondering, daar doorheen geloodst. Dat is in het geval van Microsoft Office 365 en de meeste SaaS applicaties onnodig, bij binnenkomst in de datacenters van Microsoft wordt het verkeer namelijk al uitgebreid gecontroleerd en gefilterd. De extra controle binnen de organisatie zelf voegt daar niets aan toe. Met name applicaties zoals Skype en Teams hebben baat bij zo direct mogelijke toegang. Microsoft publiceert een lijst met adressen die uitgesloten dienen te worden van filtering en proxy-en. Zie de toelichting onderaan dit artikel voor meer informatie.

      Netwerk automatiseren met behulp van SD-WAN
      Mogelijkheden tot automatisering geven gelijk weer nieuwe input voor de herinrichting van het netwerk. Door gebruik te maken van internetverbindingen in combinatie met slimme software op de netwerkapparatuur-laag(een Software-Defined Wide-Area-Netwerk of SD-WAN) ontstaan er mogelijkheden om hetzelfde niveau aan beveiliging en functionaliteit te bereiken als met een traditioneel (MPLS) WAN maar met meer flexibiliteit. Een volledig met software bestuurd netwerk geeft de mogelijkheid om verbindingen te optimaliseren waar de hoogste toegevoegde waarde wordt gerealiseerd, zoals bijvoorbeeld voor Skype en Teams verkeer. Een SD-WAN oplossing voorziet ook in de behoefte om eenvoudig de connectiviteit naar de verschillende cloudomgevingen te realiseren en blijvend te optimaliseren. Deze Software-Defined-WAN’s zijn bijzonder interessant voor organisaties waarbij er veel wijzigingen in de WAN architectuur optreden, bijvoorbeeld om toegang te regelen tot cloudapplicaties. De kosten zijn op dit moment nog wel vrij hoog (>50%+ ten opzichte van reguliere WAN), dus weeg dit af tegen de voordelen zoals vermindering van beheerlast.

      Wel of geen Direct Connect / Express Route verbinding?
      Als laatste punt voor dit artikel; het vraagstuk over de directe verbinding tussen het bedrijfsnetwerk en de cloud. Alle grote cloudproviders bieden de mogelijkheid om, al dan niet via een cloudexchange zoals Equinixof IX-Reach, rechtstreeks te connecteren met de netwerken van de provider. De voor-en nadelen van een dergelijke verbinding zullen we in een separaat artikel behandelen maar de keuze om rechtstreeks te verbinden moet weloverwogen worden genomen. Naast argumenten over beveiliging en controle moet ook hier de prestaties van de applicaties meegenomen worden in de overweging. Regelmatig hebben de applicatieprestaties er baat bij, maar dat is zeker niet altijd het geval. Ook hier geldt weer dat de extra stappen die genomen worden om vanuit de gebruiker bij de Direct Connect / Express Route te komen vertraging toevoegen in plaats van wegnemen. De kortste route is vaak via het publieke Internet, een netwerk dat is ontworpen op basis van het principe om de kortste route van gebruiker naar bestemming te kiezen. De cloudproviders kiezen hun Edge locaties (dit is waar het providernetwerk aansluit op het Internet, dat is niet persé hetzelfde als waar de datacenters staan) op zo’n manier dat ze korte toegang hebben naar de grootst mogelijke groepen gebruikers. Soms bereik je de beste prestaties via het Internet, daar kan dan geen eigen netwerk tegenop.

      Generieke principes voor netwerkarchitectuur bij cloud:

      De volgende principes kunnen toegepast worden bij het nemen van architectuurbeslissingen. Deze principes zijn gebaseerd op onze ervaring met het uitvoeren van cloudstrategie projecten en de diverse ontwerpen die we daarbij als architect gemaakt hebben.

      1. Voorkom onnodige vertraging door haarspeldbochten in het netwerk (lokale break-out vs. centraliseren van Internetverkeer)
      2. Voer geen dubbele inspectie van het netwerkverkeer uit (Office 365 niet filteren of proxy-en)
      3. Behandel verkeersstromen niet gelijk; optimaliseer daar waar mogelijk (real-time verkeer vs. regulier)
      4. Optimaliseer het netwerk voor de hoogste gebruikersprestaties; kies de oplossing met de laagste netwerklatency (RTT)

      De netwerkarchitectuur tijdens de cloudmigratie
      Het oplossen van deze puzzel vereist inzicht in een flink aantal van de schuivende panelen; welke applicaties gaan er naar de public cloud; welk deel daarvan wordt als SaaS afgenomen; welk deel blijft er dan nog in het datacenter staan en vanaf waar wordt dit alles benaderd. Bij het uitvoeren van een cloudstrategie brengen we al deze elementen bij elkaar en zijn we in staat om de contouren van het netwerk te schetsen. Hierbij zouden de prestaties van de (SaaS)applicaties voor de gebruiker centraal moeten staan. Wat ons betreft behoort het bedrijfsnetwerk een onderdeel te zijn van de cloudstrategie en moet hier in elk geval goed over nagedacht worden.

      Voor dit artikel heb ik input gebruikt van-,en gesproken met:

      Verdiepende informatie over filtering enproxy-en
      Microsoft stelt een lijst beschikbaar van die URL’s en IP-ranges die het beste uitgesloten kunnen worden van de filters en proxy’s. Deze lijst is opgedeeld in: beslist niet filteren | beter van niet | maakt weinig verschil; de adressen in de eerste categorie betreffen met name real-time diensten zoals bellen via Skype en conference calls via Teams hebben veel belang bij ongehinderde toegang
      naar het Internet. Hiervoor geldt dus: niet proxy-en, niet decrypten maar zonder onderbrekingen naar het Internet.Waar het voorheen ging om duizenden adressen en honderden URL’s die handmatig ingevoerd moesten worden stelt Microsoft veel in het werk om het aantal gebruikte IP-ranges en URL’s voor Office 365 en Azure te beperken. Dat aantal is inmiddels aanzienlijk teruggebracht en Microsoft heeft een API beschikbaar waarmee de URL’s automatisch opgehaald kunnen worden. Moderne webfilters kunnen al overweg met deze API’s en kunnen het verkeer richting Office 365 ‘met de klik van een button’ uitzonderen van filtering zonder bewerkelijke handmatige administratie.

      Additionele verdiepende informatie vind je hier.

      Het inschatten van de benodigde netwerkcapaciteit blijkt bijzonder lastig. Er zijn berekeningen te maken om de toekomstige netwerkbehoefte in te schatten, maar die berekeningen staan zo bol van de aannames en verwachtingen dat ze in de praktijk niet uitkomen. 

      Meer weten over hoe je het netwerk onderdeel kan maken van je cloudstrategie? Tijdens de meet-up op 28 mei introduceren we een stappenplan om deze ‘eenvoud’ te bereiken en behandelen we nog veel meer onderwerpen. Meld je gratis aan.

      Door: Bart M. Veldhuis

      Meet- up: Reduce complexity and achieve ‘simplicity’

      Quanza

      On the 28th of May we will dive into the complexity of networks. Can you handle your network now hybrid-, multi cloud environments and environments such as IBM Cloud or even Salesforce come into play?

      These days companies no longer rely on on-premise data centers to run their applications and workloads. Hybrid- and (multi)cloud environments such as AWS, Azure and Google Cloud are more common. On top of that, organizations are adding new environments including IBM Cloud or Salesforce to the mix. We call this the ‘scale out-era’.

      Can you handle these changes with your existing network? Isn’t this ‘scale-out’ or step to (multi)cloud environments far too complex? How can you reduce this complexity and achieve ‘simplicity’ in order to better adapt to these diverse cloud environments? And how can you prevent the network becoming a bottleneck for your organization?

      How to make the network part of your cloud strategy?
      During this meet-up we will introduce a 5-step plan to achieve this ‘simplicity’ and cover subjects such as:

      • Cloud creates other traffic flows, how does this affect your network topology?
      • Redundancy and cloud: what do you have to take into account?
      • Advantages and disadvantages of Direct Connect and Express Route connections.
      • How to achieve an open and transparent underlay?
      • Insight as well as end-to-end management by automation and orchestration.
      • Security in all layers (incl.  public cloud environments).
      • The added value of SD-WAN.
      Melchior Aelmans

      Speaker 1
      Melchior Aelmans 
      Senior System Engineer – Juniper Networks

      Melchior will share a 5-step plan to achieve ‘simplicity’ in a complex (multi)cloud environment. He will talk about creating open and transparent underlays, end-to-end management and insight by automation and orchestration and security.

      Melchior Aelmans works as a Senior System Engineer at Juniper Networks and is technically responsible for large enterprise and service provider customers in EMEA. As Lead, he focuses on SDN and NFV solutions, in particular on linking business and technology. His drive is to solve business problems with technology wherever possible.

      Melchior has over ten years of experience in service provider networking. Prior to joining Juniper Networks, he held various post and pre-sales roles at major service providers and data center clients like Liberty Global, eBay and Priority Telecom.

      Frans ter Borg

      Speaker 2
      Frans ter Borg 
      Founder – Quanza Engineering

      For a cloud architect this may sound familiar: you just carried out a perfect migration to the cloud, and suddenly your network turns out to be a bottleneck. Frans ter Borg will share his insights and will also tell you how to use your network optimally and incorporate it in your cloud strategy.

      Frans ter Borg is the founder and CEO of Quanza Engineering, a leading company for Design, Build and Operate of innovative IT- and cloud infrastructures. Frans has over 20 years of deep and broad experience in IT infrastructures of organisations with a 24×7 mission critical IT-environment. His specialties are IP and optical networks, datacenters, network security, application delivery and cloud management and orchestration. In addition to his general management role he is responsible for innovation, strategy and product development. Frans is a boardmember of ISPConnect and of Digital Infrastructure Netherlands (DINL) and the chairman of the Cloud IT Academy.

      Bart M. Veldhuis

      Moderator
      Bart Veldhuis
      Co-founder – Cloud Architect Alliance

      Bart Veldhuis is a seasoned cloud architect with over 15 years of infrastructure architecting experience. He is the co-founder of the Cloud Architect Alliance.

      Bart is a serial entrepreneur and started the first VMware based cloud provider in the BeneLux. Bart founded the vendor independent consultancy firm Weolcan to help organizations bring tangible results from their cloud strategy. Bart will be the moderator during the meet-up on the 28th of May.

      Location

      Quanza Engineering B.V.
      Willem Fenengastraat 7
      1096BL, Amsterdam

      Program
      16:00h – Registration
      16:30h – Melchior Aelmans (Juniper Networks)
      17:00h – Frans ter Borg (Quanza Engineering)
      17:30h – Drinks

      Want to know more? Read the blog about:

      Cloud Architect en Cloud Security Architect awards uitgereikt

      Election

      Amsterdam, 1 februari 2019 – Henk de Ruiter, Cloud Architect bij Ahold-Delhaize en Johannes Vermeulen, Enterprise Security Architect, DXC Technology zijn gisteravond tijdens een award diner uitgeroepen tot respectievelijk Cloud Architect of the Year en Cloud Security Architect of the Year. De uitreiking vond plaats tijdens de jaarlijkse awards show van de Cloud Architect Alliance (CAA). De juryleden roemden beide winnaars om hun hun kennis van cloud(security) en hun vermogen om organisaties te helpen op een veilige en efficiënte manier gebruik te maken van clouddiensten. Beide winnaars hebben aangetoond over de benodigde vaardigheden te beschikken om op verschillende niveaus in de organisatie overtuigend te kunnen zijn en de complexe materie op een eenvoudige manier te kunnen uitleggen. Beide winnaars krijgen een cheque ter waarde van € 2500,- van Global Knowledge.

      De award uitreiking was gekoppeld aan een inhoudelijke avond voor de community van de CAA over high performing cloud architects. De CAA organiseert 4 kwalitatieve inhoudelijke events per jaar, waar iedere keer een thema dat relevant is voor cloud architects centraal staat.

      De meerwaarde van deze avonden voor de community heeft zich ruimschoots bewezen, stelt Melchior Aelmans, Senior Systems Engineer bij Juniper Networks: “Automatisering is de sleutel om multicloud optimaal te laten functioneren als een dynamische, onzichtbare infrastructuur met een overkoepelende en alles-integrerende orkestratielaag. De kennis en vaardigheden van een cloudarchitect zijn vereist om dit proces te vereenvoudigen. Onze partner, Quanza Engineering, heeft de expertise om multicloud echt waardevol te maken voor onze klanten. Deze Awards dienen als waardering en inspiratiebron voor anderen om verder te bouwen op hun cloudstrategie.” Adam van de Putte, Marketing & Sales Manager van managed service provider voor IT-infrastructuren Quanza Engineering, vult aan: “Vooruit komen, ontwikkelen en innoveren, dat kan alleen maar als je kennis deelt met en haalt bij je vakgenoten. Daar geloven wij bij Quanza heilig in. De CAA is bij uitstek een platform waar specialisten bij elkaar komen om precies dat te doen.”

      De concurrentie voor beide titels was groot. Sinds oktober 2018 was het mogelijk voor vakgenoten en anderen om cloud architecten te nomineren. Na een stortvloed van nominaties selecteerde de jury in beide categorieën vijf finalisten. Er werd onder andere beoordeeld op technische kennis, het vermogen om organisaties te overtuigen van de voordelen en mogelijkheden van de cloud en hun bijdrage aan de wereldwijde community van cloud architecten. Na een strenge selectie werd de top drie bekend gemaakt en uiteindelijk op de avond zelf de winnaars.

      Bart M. Veldhuis en Freek Beemster, oprichters van de Cloud Architect Alliance, vertelden tijdens de avond hoe de jury te werk is gegaan. “Op basis van de nominaties hebben we iedere genomineerde uitgenodigd om een schriftelijke pitch in te dienen. Deze zijn beoordeeld, waarna in iedere categorie de 5 overgebleven kandidaten het vuur aan de schenen is gelegd. Daarnaast hebben we ook een referentie geïnterviewd. Uiteindelijk werd per categorie uit de beste 3 de winnaar gekozen. Je zou kunnen zeggen dat je nog makkelijk door de gemiddelde sollicitatieprocedure komt dan dat je cloud architect of the year wordt.”

      De uitreiking van de awards vond voor de tweede keer plaats en zal ook volgend jaar weer plaatsvinden.

      Cloud Architect of the Year 2018

      Winner_2018_Erik_Janssens

      Erik Janssens is the Cloud Architect of the Year winner of last year (2018). Besides the title of best Cloud Architect of the Year he won a Global Knowledge cheque worth 2500 euro for a training of his choice.

      What is, according to you, a good Cloud Architect?

      “A cloud architect should have technical knowledge of different cloud providers but also should have knowledge on security, compliance and different cost models.”

      How was it for you to win the Cloud Architect of the Year title?
      “I really enjoyed the election and I think this is a really good initiative which is also broadly recognized by the community.

      Career history:
      Erik started his career as a software developer .NET and Java in 2003. He worked among other things for Philips in the IT infrastructure domain and as an expert in the Microsoft stack. He joined NXP in October 2014.

      Serverless Architectures: 3 key trends by IBM

      CAA12

      For IBM, supporting the Serverless Architectures event of the Cloud Architect Alliance, was a logical occasion. Not only does it have its own serverless proposition, but, fueled by the legendary mantra Think, ‘Big Blue’ is also keen to learn something new everyday.

      Henk Waanders, Technical Enablement Specialist at IBM: “At IBM, we think ’serverless’ is an important direction to take, as we are on par with the likes of AWS and Azure”, he said in this blog.

      The IBM Cloud Functions platform was developed as a polyglot Function-as-a-Service programming platform within IBM and then donated to the open source community as Apache OpenWhisk.

      Waanders saw three main advantages of serverless architectures really stand out:

      Cost savings
      With being serverless, you only use the compute power when you need it. “We saw savings up to 10 percent from the original sum. So the small overhead to set up a serverless architecture is worth it.”

      Scalability
      “Serverless is easy to realize because every request has its own instance. The old way: servers are created with a certain number of people logging on in mind. That’s how they get sized. Now, you only have to size for one person, and put them next to each other. So a serverless infrastructure is massively scalable.”

      “But”, Waanders continues, “you must always keep in mind how fast you can enable this. For instance: what kind of rate limit does your provider have?”

      Ease of integration
      “Serverless computing also is a great match with microservices”, said Waanders. “You can easily integrate someone else’s function or new functions. Eventually we will move towards ‘infrastructure as a code’.”

      Meetup
      IBM Netherlands is supporting the exploration of the serverless topic even more. It will be organizing a meetup about ‘serverless’ themselves, at the beginning of next year. Contact Henk Waanders to stay up to date!