For this post I am assuming you are pretty familiar with the concept of deployment strategies (if not check out this post by Etienne). Now these are typically seen from an application deployment level, where platforms (like for instance Kubernetes) typically have out-of-the box mechanisms in place to do this. Now what if you would want to do this on an “infrastructure level”, like for instance the Kubernetes version of Azure Kubernetes Service. We could do an in-place upgrade, which will carefully cordon and drain the nodes. Though what if things go bad? We could do a Canary, Blue/Green, A/B, Shadow, … on cluster level too? Though how would we tackle the infrastructure point of view of this? That is the base for today’s post!
Architecture at hand
For today’s post we’ll leverage the following high level architecture ;
This project leverages Terraform under the hood. Things like DNS, Traffic Manager, Key Vault, CosmosDB, etc are “statefull’ where its lifecycle is fully managed by Terraform. On the other hand, our kubernetes clusters are “stateless” from an Infrastructure-as-Code point-of-view. We deploy them via Terraform, though do not keep track of them… All the lifecycle management is done on operating on the associated tags afterwards.
The drawing above was not created in Visio for once. The above was made leveraging CloudSkew, which was created by Mithun Shanbhag. Always awesome to see community contributions, which we can only applaud!
Continue reading “Leveraging Azure Tags and Azure Graph for deploying to your Blue/Green environments”
Today a quick post on Zone Aware VPN Gateways… When you currently create a VPN gateway, you’ll see the following screen ;
There are two important options to note here ;
– Availability Zone
– Active / Active
Continue reading “Zone Aware Azure VPN Gateway : Deployment options”
Resiliency patterns in Azure is a very common / return question. Though over the course of time, I’ve noticed there is a lot of confusing around the architectural patterns involved here. This mostly comes down to the basic illusion that HA (High Availability) and DR (Disaster Recovery) are both met when doing a stretched cluster.
Overview of all the patterns
Continue reading “Resiliency Patterns in Azure”
For today’s post, let’s take a look at an architecture example where you want to provide a geographic deployment of your webapp by using a cloudbased WAF (like Cloudflare, or Akamai, …).
High Level Setup
So what will we be setting up & testing today?
The user will receive a url that is powered by “Azure Traffic Manager”. That will have three endpoints ; one in Europe, one in the US and one in Asia. These endpoints will be powered Cloudflare and back by an Azure Webapp. You’re question will probably be ; “Why use that sequence?” Because the Traffic Manager is DNS based and will do a “basic” HTTP check. If you would setup the Traffic Manager behind Cloudflare/Akamai/…, then you would see the source IPs of that service. Thus you would be unable to route the clients to the nearest location.
Continue reading “Combining Azure Traffic Manager, CloudFlare & Azure App Service for Geographic Scale!”
A few weeks ago the “HA Ports” (finally) saw the light (in public preview)! I’m truly excited about this one, as it had become a “unicorn” for me over the last years.
Why am I so excited about this one? This unlocks of advanced networking patterns, starting with a truly HA setup for the Network Virtual Appliances (NVAs). In the past, we needed to rely on “workarounds” that would switch the UDR to point to the surviving node. That was great for the time, but let’s be honest… It shouldn’t have been like that.
Another use case is the scenario where an application needs to connect to a certain dynamic port ranges (like with SQL). I’ve seen several deployments annoyed by this requirement, which then forced people to create a lot of rules. This can now be avoided by allowing the entire port range, and just hardening it with a “Network Security Group” or Firewall rule base.
Continue reading “Azure Star / Any Load Balancer or … like we would like to call it “HA Ports””
When moving to the cloud, one cannot imagine this without some kind of network integration. Taking a look at “Infrastructure-as-a-Service”, there are several common patterns that are utilized by enterprises. Today we’ll discuss these patterns…
Update – June 2018
Despite that this post isn’t even a year old, I’ll be updating it with the new guidance that come from the introduction of the standard LB. Here we advise to use a single legged deployment.
Typical Network Maturity Models
Embarking on a cloud journey? You’ll typically go through the following patterns depending on your “maturity level” in working with the cloud ;
- “Island” : The first approach is typically “the island”. The VMs reside in a VNET that is not connected/integrated with any other networks, except for (maybe) the internet.
- “Hybrid Connection” : The first step towards integration is creating a hybrid connection. Here you want to access “On Premises” resources, though the mass of the resources on Azure do not justify the investment into a “Network Virtual Appliance” (AKA Firewall). Two flavours typically arise here;
- “Forced Tunneling” : Here you set up a “UDR” (User Defined Route, AKA Static Route), where you force all traffic to go back to the “On Premises” network.
- “Azure = Internet Zone” : Here you assume that the Azure zone is does what it needs to do to protect its resources Though you’ll protect your “On Prem” zone by considering the Azure VNET as being “the bad internet”.
- “Single VNET with DMZ” : One step beyond “forced tunneling”, is moving towards the typical DMZ-alike pattern, where you setup a HA-pair of “Network Virtual Appliances” and segregate network zones.
- “Hub & Spoke”-model : Growing even further, you’ll have multiple subscriptions. Setting up “NVAs” on all of those can be quite expensive. In terms of governance, this also a nice model, where you can consolidate all network integration into a segregated subscription/vnet.
The advantage of these patterns is that you can evolve into another pattern without breaking anything in terms of design.
Continue reading “Azure Networking : Blueprint patterns for enterprises”
A topic that’s often discussed in workshops is “Availability Sets“. And during that topic, a question/comment that pops up every time ; “Can I schedule the maintenance for my VMs, because…”. Today we’ll delve into that part.
Why do we need maintenance?
For some this might seem like a very odd question to pose and that is a given fact of life. Though some organisations live by the mantra “if it isn’t broke, why fix it”, and once a systems gets deployed, they’ll (try) never to touch it again…
Continue reading “Azure : How to prepare for maintenance impacting your Virtual Machines”