Three months ago I decided to leave the world of VAR consulting and try my hand at a new venture. That new venture is Ned in the Cloud LLC. I wrote a long post about the events that led up to my decision and I encourage you to go check that out if you have questions. The focus of Ned in the Cloud is to create technical content that is educational in nature. That could be courses on Pluralsight, sponsored blog posts about vendor technology, webinars about a technical topic, podcasts about the cloud, or even a book about the Azure Kubernetes Service. The unifying thread is a desire to learn about technology and share that knowledge with others. Now that I have been doing this for a full quarter, I thought it might be nice to post an update about how things are going so far.
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.
Let me say this upfront. I am going to talk about privilege. I am not an expert on privilege. I am not a poly-sci major with dual minors in social justice and psychology. These are ideas that have been kicking around in my head for a couple weeks, and I thought they might resonate with others or spark conversation. If that’s not the sort of thing you’re interested in, probably best to skip to the next post, where you can read about HashiCorp Vault or Azure or something similar. Okay? Still here? Great. Let’s talk.
On last week’s Buffer Overflow we were talking about this very strange blog post from Microsoft about a “Modern OS” and what it should include. It’s obvious that Microsoft has something big brewing over in Redmond. In the build-up to \build, rumors were flying fast and free that Microsoft was going to unveil their new Lite OS and provide a roadmap for development. That did not happen, and the blog post from Computex seems to indicate that while Microsoft is definitely developing something that is not Windows, they aren’t quite ready to share with the world what that “Modern OS” actually is. The more I think about it, I believe that Microsoft might be poised to come barreling back into the mobile market from a totally unexpected direction.