To kick off the new year I am trying something new. For the 1st time I will be speaking on a Twitter space. This Twitter space is about Platform Engineering. It was hosted by cloud native and open source champion SAIM SAFDAR (@cloudnativeboy).
On this twitter space we talked about how to prepare your journey of learning and navigating the Platform Engineering (PE) landscape, my latest PE course, the PE guide from Microsoft and emerging best practices, and taking question’s from folks on the space.
We even had special guest Kubernetes and Platform Engineering expert Michael Levan (@TheNJDevOpsGuy) show up on the space! He shared some great insight on PE as well.
If you missed the space you can watch a recording of the space here:
For a while, I have been hearing chatter around “What is Microsoft doing in the Platform Engineering space?” and “What is Microsoft’s stance on Platform Engineering?”. Well, today is the first day of Microsoft Ignite 2024 and I am happy to say Microsoft has officially released a Platform engineering guide. It can be found here: https://aka.ms/plat-eng-learn
It is broken down into the following sections: Overview, Concept, How-To Guide, and Architecture!
Working through this guide will help you discover how platform engineering teams can leverage technologies from Microsoft and other vendors/providers to craft highly personalized, optimized, and secure developer experiences.
This guide essentially gives you the scoop on Microsoft’s perspective when it comes to Platform Engineering. It can be used to help you along your Platform Engineering journey!
Shout out to the core team that built this! DevDiv: Mark Weitzel, Chuck Lantz, Russell Conard and AKS Engineering: Daniel Sol.
Another cool thing launched today is Microsoft’s Platform Engineering Interest Group.
At Microsoft, we want to hear about your challenges with Platform Engineering and provide opportunities to connect with other teams, at Microsoft and at other companies, who are working together to build solutions in the Platform Engineering space. Joining this group will let you get exclusive early access to new tools and services from Microsoft. Sign up here:
The last thing I want to mention in this post is a new open-source product from Microsoft named Radius. Radius is a single tool to describe, deploy, and manage your entire application. Radius is dedicated to addressing the platform engineering challenges associated with facilitating application deployments across on-premises infrastructure and major cloud providers such as Microsoft Azure and Amazon Web Services.
Radius is not an IDP. It’s an optional part of an IDP focused on the applications that provides infrastructure Recipes, simplifying the platform configurations like permissions, connection strings, and more to manage the application and its resources.
Radius empowers developers to comprehend their applications, recognizing that an application extends beyond Kubernetes alone. Radius assists developers in visualizing all the components that form their application. More about Radius here: radapp.io
Hey everyone, today I’m super excited to tell you about a recent episode of Azure Friday that I was lucky enough to be a guest on.
Azure Friday is a weekly video series hosted by the legendary Scott Hanselman, where he interviews experts and developers on various Azure-related topics. In this episode, we talked about Automated Deployments for AKS, a new feature that makes it super easy to deploy your apps to Azure Kubernetes Service.
If you’re not familiar with AKS, it’s a managed Kubernetes service that lets you run containerized applications on Azure without having to worry about the complexity of managing the cluster. It’s a great way to scale your apps and take advantage of the benefits of Kubernetes, such as high availability, load balancing, and service discovery.
But what if you’re not familiar with containers or Kubernetes? What if you just have some code in a GitHub repo and you want to run it on AKS? That’s where Automated Deployments for AKS come in. It’s a feature that simplifies the Kubernetes development process by taking care of the tedious work of containerization for you. It uses a tool called Draft, which automatically detects the language and framework of your app, creates a Dockerfile and a Helm chart for you, builds and pushes the image to Azure Container Registry, and deploys the app to AKS. All with just a few clicks in the Azure Portal.
Sounds amazing, right? Well, that’s what I wanted to show Scott in this episode. I had an app hosted in a GitHub repo that I wanted to run on AKS. The app was a simple web app that displayed some data from a database. I had already created a few resources in Azure, such as a resource group, an Azure Container Registry, and an AKS cluster. All I needed to do was use Automated Deployments for AKS to get this app from code to running on a cluster.
So how did it go? Well, you’ll have to watch the episode to find out. But spoiler alert: it was super easy and fast. In just a few commands, I went from code to an app running on AKS. Scott was impressed and so was I. We had a great time chatting about how Automated Deployments for AKS works under the hood, some of the benefits and limitations of using it, and how it can help developers get started with containers and Kubernetes.
That’s all for today. I hope you enjoy this episode of Azure Friday as much as I did. It was an honor and a pleasure to be a guest on Scott’s show and talk about one of my favorite topics: Azure Kubernetes Service. If you have any questions or feedback, feel free to leave a comment or reach out to me on Twitter at @Buchatech. Thanks for reading and happy coding!
I recently had the honor to film an episode of Spotlight at the Pluralsight headquarters.
It was an awesome experience and fun talking with Adam Gunn.
In the episode, we talked about:
Tech skills you need to master for the future, including hybrid and multi-cloud, Kubernetes, AI, and more. We also touched on how I landed in tech and how to overcome impostor syndrome to become a successful professional.
I was a guest on a very popular cloud podcast. This is one of the longest-running cloud podcasts around starting in 2011. It is the Cloudcast Podcast.
I was on episode #714 titled “Combining Kubernetes Community and Careers”. In this episode, I had a great time chatting with Aaron Delp about my journey in the Kubernetes community, building a personal brand through education and sharing, content creation, and maintaining a healthy work-life balance.
Here are the show notes breaking down the topics:
Topic 1 – Today we are going to be talking about careers and Kubernetes. Steve, welcome to the show! You have a super fascinating career journey, can you give everyone a quick introduction?
Topic 2 – I heard you over on the Kubernetes Unpacked podcast. First off, it’s hard to keep up with everything you are doing in the community these days. What is your current focus and passion? Have you reached 20 courses on Pluralsight yet?!
Topic 3 – How do you balance the day job (Program Manager for AKS) and the nights and weekends (PluralSight courses, blogging, podcasts, etc.)? Besides learning and sharing, what benefits are you seeing with this approach?
Topic 4 – I believe your journey parallels our journey here. We started the podcast to learn and give back to the community. Prior to the podcast, blogging was the big thing (we are completely aging ourselves I know) but I think it is safe to say blogging isn’t a primary source today. How would you recommend folks new to the industry get started sharing their journey? Where is the most “bang for your buck” these days?
Topic 5 – Let’s talk about Kubernetes and specifically AKS, what are customers finding new and interesting? What are the leading solutions and integrations you see combined with AKS? How do you create a “stack” in AKS (GitHub Actions, Azure Container Registry, etc.)
I recently was a guest on StreamingClouds. StreamingClouds is a multicloud live stream by Microsoft CSA Kevin Evans and Microsoft MVP Robin Smorenburg. With topics ranging from cloud native to hybrid, security, architecture, strategy, careers, personal development, and more.
StreamingClouds is more than just a live stream podcast its also a diverse community where the members can all learn from each other.
To highlight what we covered in the episode, we discussed how to effectively use Microsoft’s AKS documentation, reference architectures, scripts, and tools for your AKS project. We also touched on GitOps, Fleet Management, Platform Engineering and more.
Here is a full description of what we covered on the episode: Starting an AKS project soon or in the middle of one and lost? Have you tried to use the Microsoft AKS documentation, reference architectures, scripts, and tools but feel stuck on what to use and when to use it? Let’s talk about it and get you the guidance you need. There is a formula and framework to using these AKS artifacts from Microsoft.
In 2022 I wrote a couple of blog posts that give guidance on how to utilize the Microsoft AKS artifacts and tools. In these blog posts I baked in experience from my days delivering AKS projects to Fortune 500 enterprises. We thought it would be a good idea to dive into the content from these live on the podcast talking through these topics to help listeners who are embarking on an AKS journey. Here aforementioned blog posts for reference:
We dove into:
Architecture Design: Baseline architecture for an Azure Kubernetes Service (AKS) cluster AKS Secure Baseline with Private Cluster AKS baseline for multi-region clusters AKS regulated cluster for PCI Advanced Azure Kubernetes Service (AKS) microservices architecture
Deployment: AKS landing zone accelerator AKS Construction Helper AKS Baseline Automation Azure Draft for AKS
Operation: Operations management considerations for Azure Kubernetes Service Azure Kubernetes Services (AKS) day-2 operations guide
I am kicking off the new year as a guest on the “AzureTalks” podcast by Rolf Schutten. Rolf is a Microsoft MVP based out of the Netherlands. The AzureTalks podcast is a free-form conversation with experts and advocates around the industry discussing various topics on Azure, its services, and integration points with Azure. Some of the topics also get into strategy career, personal development, and more. You can listen to podcast episodes on Google Podcasts, Spotify, and YouTube. You can find the website for this podcast here: www.azuretalks.com
The episode I am a guest on is #004 titled “Containerize apps to AKS with Azure Draft, and Hybrid with Azure Arc“.
In this episode, we discuss how developers can utilize Azure Draft to streamline taking their non-containerized app from code to running on AKS. Azure Draft takes you through the entire process from creating the container, the files needed to run on Kubernetes manifests, Helm charts, or Kustomize, pushing up to an Azure Container Registry, and deploying to AKS.
We also dive into GitHub, GitOps, the differences between push and pull methods with continuous deployment, and even we even touched on hybrid cloud strategies and what role Azure Arc plays in this space. Listen to the audio version of the podcast episode here:
Yesterday a new article titled “Build and deploy apps on AKS using DevOps and GitOps” was published. This is an article I was working on for a while and it is the first item of work that I can share publicly since joining Microsoft. I am working on many other things I can’t share publicly at the moment. :-)!
The article is a part of the Azure Architecture Center. This article is about modernizing end-to-end app build and deploy using containers, continuous integration (CI) via GitHub Actions for build and push to an Azure Container Registry, as well as GitOps via Argo CD for continuous deployment (CD) to an AKS cluster.
The article explores deploying a Python and Flask based app via two CI/CD approaches push-based and pull-based (GitOps). It is complete with a pros and cons comparison of both approaches and architecture diagrams for each that you can download. Here is a screenshot of the pull-based (GitOps) architecture:
The technologies used in this article and scenario include:
After designing and architecting AKS the next step is to deploy your cluster/s. It is ideal to build your AKS deployments out as code.
This means taking your Azure infrastructure & AKS cluster/s design and scripting them as IaC (Infrastructure as Code). Scripting the AKS deployment vs manually deploying gives you documentation as code, standardization, & a templatized deployment for repeatability. You can deploy this code as is, place it in a pipeline for ease of deployment, in inner-source, or in a service catalog for access by multiple teams.
Microsoft has built a tool named the AKS Construction helper to accelerate building out your IaC for AKS. This tool is not as well-known as it should be. I wanted to blog about this tool to share this great resource that will save you tons of time. The AKS Construction helper was originally launched by Keith Howling of Microsoft. The core contributors to this tool have been Gordon Byers and Keith Howling with contributions from others as well.
The tool lets you select Operations Principles or Enterprise-Scale path for configuring the options.
This helps narrow down the overall design requirements of your AKS deployment.
The next section of the AKS Construction helper is to fine-tune your AKS deployment. This gives you the chance to tweak things like the cluster name, K8s version, resource group, region, to be created, IP and Cider, initial RBAC, SLA, autoscaling, upgrade configuration, cluster networking, add ons such as an ingress controller (App Gateway, NGINX, etc), monitoring such as Azure Monitor, Azure policy, service mesh, secret storage, Keda, GitOps with Flux, and even has a few options to deploy some sample apps. This is done across 5 tabs in the Fine tine and Deploy section.
After you have set all of the configurations for your cluster there is code available for you to copy on the Deploy tab. Again you have options for Az CLI, a Github Actions workflow, Terraform scripts or an ARM Template Parameters file. Running the deployment code will deploy your AKS cluster exactly how you have it configured in the AKS Construction helper tool.
Argo CD has something called the Application reconciliation timeout. This is how often your applications will sync from Argo CD to the Git repository. It looks for changes and when it sees changes it will then apply the desired state from the repo to the Kubernetes (K8s) cluster. By default the timeout period is set to 3 minutes. This is set in the General Argo CD configuration.
The General Argo CD configuration is set in the argocd-cm ConfigMap. And the argocd-cm ConfigMap is deployed in the argocd namespace.
You can view what is currently set by running the following kubectl command on your K8s cluster that is running your Argo CD instance:
kubectl describe configmaps argocd-cm -n argocd
The output will look like the following:
You can also see that the argocd-cm Data is empty by running kubectl get configmaps -n argocd or if you are using AKS navigate to ConfigMaps in the Azure portal like in the following screenshot.
Most Argo CD instances are running the default settings for its configurations. The argocd-server component reads and writes to the argocd-cm ConfigMap and other Argo configuration ConfigMaps based on admin user interactions with the Argo CD web UI or the Argo CD CLI. It is normal for it to be empty with Data at 0 if you have not changed any defaults or set anything directly in the ConfigMap yet.
To change the Application reconciliation timeout you need to do the following:
The Application reconciliation timeout can be found on line 283 “timeout.reconciliation: 180s”.
Change “180s” to whatever number you want to change it to i.e. change to “60s” to reduce the sync internal to 1 minute.
Remove all of the other settings in the file except for the Application reconciliation timeout. The file should look like this:
# Application reconciliation timeout is the max amount of time required to discover if a new manifests version got
# published to the repository. Reconciliation by timeout is disabled if timeout is set to 0. Three minutes by default.
# > Note: argocd-repo-server deployment must be manually restarted after changing the setting.
5. Save the file.
6. Connect to the Kubernetes cluster that is running Argo CD and apply the argocd-cm ConfigMap file you just updated by running the following:
kubectl apply -f argocd-cm.yaml -n argocd
7. Run the following to verify the update was applied:
kubectl describe configmaps argocd-cm -n argocd
You should also notice at least 1 is listed under Data for the ConfigMap now.
8. It is a good practice to redeploy the argocd-repo-server after updating the argocd-cm ConfgigMap. You can redeploy the argocd-repo-server by running the following: