Aside from the variety of technical questions, a very common discussion around Azure Kubernetes Service (AKS) is … “What will it cost me?”. In today’s post we’ll dissect how the pricing dynamics work and how you can optimize the cost for your cluster(s). Where this might not be rocket science, I do have noticed some organizations struggling with this. So with this I hope to help those out… 😉
Continue reading “How to estimate the costs of your Azure Kubernetes Service (AKS) cluster?”
In the beginning of the month I posted about my experience of moving VMchooser from “Serverless” to “Containers”. As in, moving from one way of implementing a CloudNative architecture to another… Since then, I have actually moved back to “Serverless”. Though the cogwheels in my head have been turning 24/7 on how to put everything around this into perspective. Yesterday Yves made a tweet (reply) that really made something click inside of my head…
In today’s post I’m going to try to do a “brain dump” of several thoughts that have been floating around in my mind. Where I hope this will help you in your journey of “finding your perfect rock”. Here I will indicate what I like about the various options and what my typical advice would be to organizations looking to do a given option.
Continue reading “Opinion – Cloud Native, Cloud Native and Cloud Native? What I like about, and my two cents on, running Containers, Kubernetes and/or Serverless”
Over the last months I have migrated VMchooser from a purely serverless implementation towards a container based one. The main reason for me to do this, was (like always) the learning effect that comes with such a refactoring. This post will run you through the various aspects that I encountered and hopefully give you a better understanding between both implementation options of a CloudNative architecture. I will divert a bit from the pure “X vs Y” comparison and also touch topics that typically come with the business discussions when thinking about both in terms of a strategic approach.
First of all… In terms of semantics, there are some definitions floating around. When you look at the CNCF, then it seems to solely revolve around containers. Though when you look at Azure, the definition broadens up a bit… In reality, it depends a lot on the context of the person/organization you are speaking too. So do not be surprised if for some organizations the scope of CloudNative is “limited” to containers. Where for others this might be about leveraging the PaaS cloud services in a “Serverless” manner.
It kinda makes me think about the following “cartoon” (Source ; Simon Wardley) from a few years ago ;
Anyhow, be aware that there are different views on the semantics of “Cloud Native” and be crisp on your own when making conscious decisions.
Strategic Design Principle ; Portability
The design principle of software portability is high on the radar with about every organization I talk to. Here I always highlight two dimensions to take into consideration ;
Continue reading “Cloud Native Options – Personal experience when moving from Serverless to Containers”
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”
Typically you notice that there are two dimensions / viewpoints when it comes to monitoring. On one side there is a team that wants to view everything related to the “infrastructure”, like for instance the kubernetes cluster. On the other hand, there is the typical application performance monitoring that starts from the application side. Sadly enough, in a lot of cases, those two are separated islands… 😦
As you might know, on the Azure front you can do Application Performance Monitoring with Application Insights and there is like a really awesome integration with Azure Monitor (“Log Analytics”) from the container space (kubernetes). Though I see you thinking it… Two separate solutions. Though, what a lot of people forget, is that they are actually using “Log Analytics” under the hood. And… That you can query across workspaces in Log Analytics! Which means that you can join the two and have an aggregated view to span both worlds.
Let’s take a look!
For this test, I’ve created a k8s cluster which is linked to a separate log analytics work-space. Where next to it, there is an application (Azure Function) inside of a docker container that is linked to Application Insights.
Continue reading “Unified monitoring view in Kubernetes : Linking infrastructure monitoring with application monitoring”
Todays post will be the backend tour of “Frietjes-of-Niet” (translated from Dutch : “French-Frites-or-Not?”). A big part of the mission of Azure is about democratizing technology so it becomes accessible to organizations in order for them to achieve more. AI (Artificial Intelligence) is a key part of that vision.
What will be the flow for today?
- We’ll train a model to recognize fries
- Next we’ll be exporting that model to be used as a container
- Afterwards we’ll build that container
- To end with deploying (and testing) it onto AKS
Sound cool? Let’s get to it..
Continue reading “Azure Custom Vision AI : From training to deploying the container export on the Azure Kuberenetes 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”
Today the new “AKS” (Azure Kubernetes Services) was launched in preview. This is a managed container service. So where ACS used to rely on IaaS and used a set of best practices to deploy the cluster. AKS will go a step further, where it’ll managed the master nodes & provide upgrade tracks.
Let’s start with deploying an AKS cluster… Here we can select the k8s (kubernetes) version too.
Continue reading “A first glance at the preview AKS (Azure Kubernetes Service)”
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”
In the past I’ve already done several posts about containers. This by using various orchestrators & workflow management tools. Today’s post will be about deploying a Linux container with Service Fabric… The main goals is to provide you with the look & feel of the initial steps. In a future posts, I’ll delve into the more advanced stuff (like data persistence & inter-container connectivity).
Continue reading “Azure Service Fabric : Deploying your first container…”