The do’s and don’ts when architecting a cloud-native data lake

The do’s and don'ts when architecting a cloud native-data lake

The cloud community still is on the fence about data lakes. On the one hand one could argue it’s a fancy word for something that has existed since humans started using computers. On the other hand, with the advent of Cloud computing, it is finally possible to store, distribute and process (or mine) unstructured data in a safe, governable way that can actually create business value. So when should a Cloud-native data lake be considered, and how can you make it work?

On the fence about data lakes

From a business perspective, cloud-native data lakes can be tricky. In the recent past, large enterprises have attempted to connect and mine (old) datasets with the expectation to gain new insights and ultimately create value. Too often, such projects are guided by a misconception of what ‘Big Data’ is or can do for an organization. Up until this day the internet continues to be littered with promises about AI, machine learning and the secrets that can be unlocked with these technologies in datasets. And while there are many examples of successful cloud-native data lake deployments that add value, the opposite is also true. As was pointed out during the CAA Cloud-native data lake event, senior leadership on occasion becomes enamored by the (real or imagined) possibilities of data, requiring IT to make it happen. Unfortunately, there is a real risk of a waste of time, resources and goodwill.

The challenge for the Cloud Architect

The Cloud Architect thus faces an interesting challenge. He or she needs to be able to make or unmake the case for a Cloud-native data lake, depending on the feasibility of such a project. If there is sufficient ground for architecting a Cloud-native data lake, he or she of course needs to know how to do it. There are numerous variables to take into account that will eventually make a Cloud-native data lake add value for the organization while avoiding the operational and Governance, Risk and Compliance risks that accompany it.

How then should the business case for a cloud-native data lake take shape? We could probably write a book about this (and maybe will someday), but these are the 5 questions a Cloud Architect needs to consider from a business and operational perspective when planning a Cloud-native data lake:

  1. Is there a business oriented problem that can be solved with acquirable data?
  2. Is there sufficient scale in the data sets, is there enough data to justify the required resources?
  3. Does the eventual solution touch the core business?
  4.  Are the right tools available, do business owners and the team understand there needs to be a code base instead of a webportal or GUI?
  5.  Is there a team that knows what to do and can autonomously engineer the data lake, with limited oversight?

Getting these things right will make the difference between a misguided approach and getting the desired results. Those results in turn are highly dependent on the way the data lake is architected.

How a cloud-native data lake can add business value

A useful perspective on architecting a data lake is how the data in the lake should be made available to consumers of this data. Given the fact the data lake holds unstructured data, consumers will have to know which is what, and whether they have access. To see how this would work in practice, it is useful to use an example.

Consider a data lake that holds data sets on mortgages and relevant variables, spanning about two decades. As one can imagine, an institution that is in the business of providing mortgages wants to know how many mortgage holders historically default on them, what the average returns on these mortgages are and will also want to know how mortgage defaults relate to historical interest rates and the historical health of the overall economy in a given country. The data involved has its origin in different data sets, and some of the data is probably privacy sensitive. Also, the data can be sensitive in a competitive sense, justifying tight controls of who has access.

Given the age of the data sets, its highly probable compatibility issues will arise when pushing this data into the data lake. These type of issues can take a lot of time to mitigate, unless an unified data model is issued that is able to assign metadata in a consistent way and making the data available through a publisher-subscriber model. This will also help to control access, and enable teams to discover data without extracting data from the data lake. It is advisable to create an automated workflow which offers a potential subscriber a sample from a data lake, giving him the opportunity to decide whether the data in the lake is useful to him. This workflow will need to automatically provide or deny access based on predefined rules, such as clearances for specific types of data. In this way, the use of this data can be aligned with organizational goals, creating real business value. 

Make a data lake work for you

All in all, the Cloud-native data lake requires a lot of thought, from its conception to its actual use. And even though there is some (contextually justified) skepticism about data lakes, with the right business case and right architecture, innovation can be accelerated with a thoroughly automated data lake.

Cloud Architect of the Year awards 2020

Rob Reus

Cloud Architect of the Year awards 2020

Massive congratulations to Rob Reus, Dennis Vijlbrief and Rene Pingen! They are the well-deserved winners of the respective Cloud Engineer, Cloud Security Architect and Cloud Architect of the year awards. 

Well done and special thanks to our sponsors NetApp, Microsoft, Vamp.io and of course Global Knowledge. 

We will return with a new edition of the Cloud Architect of the Year awards next year!

 

Rob Reus

Cloud Engineer of the Year 2020

Rob Reus

Dennis Vijlbrief

Cloud Security Architect of the Year 2020

Dennis Vijlbrief

René Pingen

Cloud Architect of the Year 2020

René Pingen

How to avoid getting stuck in a data swamp

How to avoid getting stuck in a data swamp

In the run up to the much anticipated Cloud Architect Alliance diner and award show on January 30th, our speakers give a sneak peak into what they have to say that night. Data Solution Architect René Bremer and Senior Cloud Solution Architect Sarath Sasidharan, both currently at Microsoft, share their take on architecting secure data lakes that add business value.

The challenge of scattered data

Many enterprises are considering setting up an enterprise data lake. They want (and often need) to get more business value out of the data that is available within the organization. But even though the potential value of data is recognized, actually using data in this way can be a challenge.

According to René Bremer and Sarath Sasidharan, enterprises need to centralize data first before they can use it to create business value. “Large enterprises face a problem when data needs to be accessible to different teams, departments and offices.” Bremer says. “The last thing you want is teams exchanging data bilaterally, as this data will be ‘marginalized’ and most likely is not accessible to the rest of the organization. It’s difficult to control data that does not have a single source that is used by the whole organization. Centralizing data therefore is the first step to creating a data lake that adds business value.”

Controlling accessible and useful data in a data lake

Centralizing data is a first step, but it certainly should not be the only one. For data in a data lake to become useful, it should be clear who owns it and who is allowed to access it. A pub-sub service should be in place to ensure asynchronous use of data. “Both metadata and a clearly defined pub-sub paradigm are key to creating a functional data lake” Sasidharan explains. “Any data that is put into a data lake needs to be stored according to a proper methodology, with proper metadata and scheming validation for pub-sub to work as it is intended to.”

Adding metadata may seem a fairly straightforward affair, but when terabytes or petabytes of data are involved, a strict policy for assigning metadata fields and labels makes the difference between a functional data lake and a dysfunctional data swamp, Bremer says. “You need to think long and hard about the way metadata is added to data. Business metadata, technical metadata and operational metadata need to be compulsory additions to data that is put in a data lake. Without them, it will be difficult to determine the source and value of data. And even worse, it will be difficult to have tools use the data at all. Ideally, metadata can be interpreted by a variety of tools, for example Bricks or Sequel.” 

And that’s not all, according to Sasidharan. “You will also need to think about the data lake from the consumer’s perspective. You need to adhere to certain standards for API’s, streaming and other ways data in a data lake can be published. It should be easy for a data consumer to access the desired data while at the same time controls should be in place to ensure only authorized users can access certain data for a predefined period of time. A single pane of glass to manage consumption of data in a data lake is indispensable to a secure and efficient enterprise data lake.”

Learnings from real customer cases

To eliminate data siloes between application and business departments, Microsoft has created an open source data model (called Common Data Model) in collaboration with SAP and Adobe. During the upcoming Cloud Architect Alliance event on January 30th, Bremer and Sasidharan will discuss two customer cases and will elaborate on pub-sub flows, metadata and the Common Data Model, and general principles that need to be considered when implementing a data lake. To get guests started, they will even share some generic patterns on metadata and pub-sub. Make sure you don’t miss out and claim your free ticket right now! Don’t wait too long, there’s only a few spots left.

The sense and nonsense of cloud-native data lakes

The sense and nonsense of cloud-native data lakes

In the run up to the much anticipated Cloud Architect Alliance diner and award show on January 30th, our speakers give a sneak peak into what they have to say that night. First up is Maurits van der Drift, mission critical cloud engineer at Schuberg Philis. Van der Drift will talk about the sense and nonsense of cloud-native data lakes and how data can help to enhance business models.

Nothing more than a database?

Gone are the days when tens or hundreds of on premises or colocated servers were clustered with Hadoop to store and process unstructured data. Cloud-native data lakes offer a far more flexible way to create and maintain databases without the need to manage the physical hardware. Another major advantage is that cloud-native data lakes are not bound to a specific location, which makes planning and executing migrations (from data center to data center, for example), a thing of the past. Even though a cloud-native data lake may in its core function like a data warehouse or data base, its cloud-native nature offers far more possibilities.

“One might think the term ‘cloud-native’ is just marketing lingo for what is essentially a database”, Van der Drift says. “And even though that would be a legitimate take on the cloud-native data lake from a purely conceptual point of view, recent technological developments have really changed how data can be leveraged to add business value. The cloud is indispensable in this sense, because it offers an efficient, tailor made solution for data analysis and value extraction.”

Know what to look for before you take a dive

That being said, the promise of data lakes has not yet been fulfilled, Van der Drift observes. “When the idea of data lakes started to become more popular, there seemed to be no limit to the business value unstructured data could generate. Combined with AI and machine learning, many organizations were told they were sitting on massive amounts of useful data and they needed to tap into this new possible revenue stream. The truth is however that in many cases, the unstructured data organizations have is tough to leverage from a business perspective. In addition, even if value can be extracted from unstructured data, it can only be successfully leveraged if you know what you are looking for. In other words: you need to have made the business case for a cloud-native data lake before you actually start creating one.”

Even though Van der Drift has some reservations when it comes to ‘the promises of Big Data’, he notes there are many ways to create business value with data lakes. And it has become easier to do so. ‘A major advantage of cloud-native data lakes is the razor-sharp efficiency they bring. You don’t have to invest in hardware anymore, you don’t have to keep developers on your payroll to maintain your clusters and you only pay for what you use. Infrastructure costs for cloud-native solutions usually are only 10% of the total costs of a project. This means that a small increase in efficiency can rationalize a large increase in infrastructure costs. Needless to say, the threshold to use data analysis is lowered, but it remains important to know why you want to set up a cloud-native data lake and what the desired results are.”

Claim your free ticket for our upcoming event

Do you want to see Maurits explain when and how a cloud-native data lake can add business value? And would you like to enjoy the company of your peers and a free three course dinner while doing so? Join us January 30th 2020 during our next event: ‘How to build a cloud-native data lake & annual Election Night’. During this diner show, you will learn everything there is to know about cloud-native data lakes and can also enjoy the annual Cloud Architect of the Year election. There number of available tickets is limited so make sure to claim yours right now!

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