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!”
Today I received a question if it was possible to do a cross subscription peering… with one big catch; that it was between the subscription of a service provider and their customer(s). So let’s see what is possible?
Public Preview Announcement
When we take a look at the announcement, we see the following statement ;
Note that you can peer virtual networks that exist in two different subscriptions as long as a privileged user of both subscriptions authorizes the peering and the subscriptions are associated with the same Active Directory tenant.
Now the from this we can already see that it is possible to doe cross subscription peering. As a requirement, we need a user that is authorized on both subscriptions AND that the subscriptions are associated with the same AAD tenant.
The latter caused a bit of confusion on the requestor part, where the statement was made if a B2B invite would solve this issue. The answer to this is “no”. The B2B invite lies on the authorized user part, and is not related to the tenant of the subscription!
Let’s try it out?!?
Continue reading “Azure : Is it possible to do a cross subscription network peering?”
In my current role at Microsoft, I often talk about the possibilities in regards to application modernization. A typical ask in this space is to what kind of service they should use as a underlying platform for their own services. Where this commonly results in a (brief) discussion about VMs vs Containers vs Serverless/FaaS. Today’s post is about my personal take on the matter.
Setting the scene
First let’s start with setting the scene a bit… For today I’ll try to focus on the application modernization landscape, where the same goes for the data platform stack. Here you can pretty much interchange “Functions” with “Data Lake Analytics” and “Containers” with “HD Insights”. Though we’ll not go into that detail, in order to reduce the complexity of the post. 😉
When looking towards the spectum, the first thing to acknowledge is the difference in service models. Here we mainly have two service models in play ;
Continue reading “FaaS & Serverless – Vendor lock-in or not? Consider the cost of the full application lifecycle”
In an earlier blog post I discussed the decision criteria in selecting a VM. In that post I also showed a tool called “VMchooser“. Today’s post will be on the architecture I used to build this one. As you might have guessed, it’s built on Azure components. Let’s get to it and check the anatomy of this application.
High Level Architecture
VMchooser has the following high level architecture ;
- Web App : The front-end of the application is hosted on an Azure Web App.
- Azure Functions : The back-end API & batch parser are built with Azure Functions. Which unlocks insane scaling possibilities.
- Storage Account : The storage account serves as decoupled/central storage component for the batch parsing. And it could also be used for hosting the “database” (flat file).
- Application Insights : Application insights is used to have the needed insights into the usage & other metrics.
- Github : All code for this project is open-source and publically hosted. You can run your own VMchooser if you want… 😉 Every change is immediately pushed towards the front-end, back-end & database.
- API Management : As the back-end API is decoupled from the application, I’ve also linked this api with api management. This would provide me with the option to allow 3th party application integrations via an API subscription plan.
Continue reading “The anatomy of “vmchooser”… Adding some serverless into the architecture!”
In my role as a Cloud Solution Architect, I’m often faced with the statement that cloud is expensive. My reply is always that Cloud is not expensive (more expensive than On Premises) if you take into account all the costs involved. As this is an easy statement to make… I made an effort to create a cost comparison for four different scenario’s (in term of deployment size) and stacked “OnPremises” vs “Cloud”.
In this post we’ll discuss this calculation and ensure that we are comparing apples to apples!
Continue reading “Comparing Costs : Is Cloud more expensive than an On Premises setup?”
So what will we be doing today? We are going to leverage the power of the combination between docker containers & the rancher eco system. As a demonstration, we’ll be publishing “Owncloud” with a “mysql” backend. As we tend to like it a bit more secure, we’ll introduce a loadbalancer service as SSL termination. This as we want to keep our “Owncloud” as “vanilla” as possible. We’ll be pointing that service towards the outside world and will make it accessible via the “external dns”.
What can we optimize further about the design? (but is out-of-scope for today)
- Add sidekick containers for backup purposes
- Add data volume containers
- Introduce scalable worker containers (“Owncloud”)
- Introduce convoy for our data containers
Continue reading “Rancher End-to-End Service Example using an Owncloud-plus-mysql Deployment”
As an architect, one always looks towards the supportability of the entire stack during the projected lifecycle of the solution that will be built. So when we are using Azure components, we should also be aware that these cloud services have a given support lifecycle too… Anyhow, let’s dig in!
Azure has four different support categories when looking towards the support lifecycle ;
- Azure Virtual Machines – The Microsoft software supported on Azure Virtual Machines (Infrastructure as a Service) will follow the existing Mainstream and Extended Support phase of the on-premises lifecycle support policy.
- Azure Cloud Services – Microsoft Azure Cloud Services (Web and Worker Roles/Platform as a Service), allows developers to easily deploy and manage application services while delegating the management of underlying Role Instances and Operating System to the Azure Platform. The lifecycle policy details for the Guest OS provided by Azure for Cloud Services.
- Azure Services – All other Azure Services follow the Online Services Support Lifecycle Policy for Business and Developer
- Support for Custom Applications using Open Source on Azure – For all scenarios that are eligible for support through an Azure purchased support plan, Microsoft will provide commercially reasonable efforts to support custom applications and services built using open source software running on Azure
Source : https://support.microsoft.com/en-us/lifecycle#gp/azure-cloud-lifecycle-faq
Is there anything specific you should note?
- Microsoft Azure will provide 12 months of notice to retire the oldest Guest OS family from the list of supported OS families.
- At the end of the 12 month notification period, Microsoft Azure will stop providing the latest/patched version for a retired OS family. The cloud services using the retired OS family will be unsupported and will be stopped.
- Each Guest OS Version is normally disabled 60 days after its release. After this grace period expires, Cloud Services using the retired OS version will be force upgraded to a supported Guest OS version.