Pfew, it’s odd to admit that it has been a while since I’ve posted about Rancher. Though today is as good a day as any to pick up that thread… So today we’ll go through give or take the same objective as in the past, where we’ll notice that the integration has improved significantly with the arrival of AKS! Let’s get today’s post underway and deploy AKS from our Rancher control plane.
Before the below started, I already had the following things ready ;
Continue reading “Taking a glance at Rancher’s ability to manage the Azure Kubernetes Service (AKS)”
A while ago I talked about “Faas/Serverless” in relation to vendor lock-in. Today we’ll be continuing in that road, where we’ll be doing a small proof-of-concept (PoC). In this PoC, we’ll be replatforming existing Azure Functions code into an Azure Functions container!
Things to know
Since Azure Functions 2.0 (in preview at the time of writing this post), you are able to leverage containers. Though be aware that there are several known issues. Do check them out first before embarking on your journey!
So first, we’ll start off with testing the Azure Functions Core Tools! If you’re looking to follow this guide, be sure to have the Azure Functions Core Tools installed, which also depends on .NET Core 2.0 and Nodejs. Once you have those installed, do a “func –help”, and you’ll see what capabilities are at hand…
Continue reading “Replatforming Azure Functions into an Azure Functions Container”
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”
Today I took the Xendata Cloud File Gateway out for a spin… Why? This little piece of software allows a windows volume to be extended by an Azure Storage Account. And from a technical level, we are talking about blob storage here. So you can leverage hot & cold storage, and even archive storage in the long-term. Imagine that huge exploding file server? Suddenly we can extend our typical Windows File Server with an seamlessly unlimited cloud tier. Whoppah!
Let’s take a look shall we!
Continue reading “XenData : When a Windows Volume suddenly gets hybrid towards an Azure Storage Account”
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”
Today’s post is conceptually a rather simple one… Let’s see how we can go from this ;
To here ;
By using a CI/CD pipeline.
Flow of the day
What will we be doing today?
- Kick-off a VSTS build once a change has been made to our Github repo
- Build a container via VSTS
- Publish the container to an ACR (Azure Container Registry)
- Kick-off a VSTS release once the build succeeded
- Use an ARM template to deploy an ACI (Azure Container Instance) with our docker container underneath
Sound cool? Let’s get to it!
Continue reading “From Github to ACI – A tale how to use Visual Studio Team Services & Azure Container Registry for Container CI/CD”