In April of 2018, I was delegate for Cloud Field Day 3. One of the presenters was NetApp, and they showed off a few different services they had under development in the cloud space. In a previous post I went over the services in some detail, so I won’t regurgitate all that now. One of the services that was still in private preview at the time was NetApp Files for Azure. The idea was relatively simple, NetApp would place their hardware in Azure datacenters and configure the hardware to support multi-tenancy and provisioning through the Azure Resource Manager. That solution is now generally available, and I was curious how it would perform in comparison with the other storage options for the Azure Kubernetes Service (AKS). In this post I will detail out my testing methodology, the performance results, and some thoughts on which storage makes the most sense for different workload types.
Anyone who’s worked with Azure for a bit has encountered the need to create a service principal. If you are an IT Ops person, you probably equate an SP with a service account in local Active Directory. If you’re more of an application developer, then you may have created an SP as part of your application in Azure, because you want to give that application permissions to Azure resources. The purpose of this post is to tease apart what service principals are, how they interact with application objects, and all the myriad ways to create an SP on Azure.
I will be a delegate for Cloud Field Day 5 on April 10-12. During the event we will be attending presentations from several vendors, which will be livestreamed. Before I leave on this grand adventure, I wanted to familiarize myself with each of the presenters and consider how their product/solution integrates with cloud computing. I’m also interested to hear from you about what questions you might have for each vendor, or topics you’d like me to bring up. As a delegate, I am meant to represent the larger IT community, so I want to know what you think! In this post I am going to consider Kemp and what a load balancer company can do in the cloud better than the native tooling.
This is a follow-up to my post about the Kubernetes Cluster running on Azure Stack. In that post, I asked myself how to scale a deployed cluster and how to update the cluster. Since that post went live, I’ve done experimentation on my own, and also learned a few things about the deployment toolset being used for the Kubernetes Cluster Template.
The 100th episode of Buffer Overflow – a weekly tech news podcast I host – is steadily approaching. As I write this, we are getting ready to record episode 98. In preparation for the 100th episode, I thought it might be nice to look over past episodes and find some common themes, running gags, and anything else that caught my eye. At an average of 35 minutes, that’s roughly 57 hours of combined audio. There’s no way I could listen to the entirety of the episodes, and so I started thinking. What if I could transcribe the audio to text, and then search through the text to find all the times we talked about Derrick and Miranda, how we’re all doomed, or smiling poop? The Azure Speech to Text API can be used to convert speech to text of audio files. Why not start there?