If your looking to run Kubernetes in Azure then the Azure Kubernetes Service is what you’ll generally be looking at, it offers a semi-managed solution with PaaS based management nodes and is by far the simplest and easiest Kubernetes service to use in Azure. If AKS meets all your needs, then no need to read any further, but for some use cases, it may not. AKS is a new service, it’s not gone GA quite yet, and it is still missing some features like the ability to run Windows Containers, support for certain versions of Kubernetes, or maybe you don’t want to run Kubernetes at all and want Swarm or Mesos.
If you’re just getting started with containers and want to run them on Azure the number of options available can be overwhelming, especially with all the not so intuitive acronyms. There are many different options for hosting containers in Azure and all of them fill a specific need. Choosing the appropriate tool will all come down to understanding the benefits and use cases for each. In this post, we are going to take a look at the uses for each of the container hosting options in Azure.
Recently I came across a question on StackOverflow that was asking about how they could backup Azure Blob storage. They finished this question asking I can’t be the only one who needs to do this”. This struck a chord with me, as I recall feeling exactly the same when I had a need to do this. It feels like something that is so obvious, that should be built into the platform.
So far we’ve sent our SmartThings data to event hub, collected this data using Stream Analytics and then stored it in Cosmos DB. In this part were finally going to use that data to create some reports in PowerBI that show SmartThings sensor data over time. We’re going to focus on the example I started with, showing temperature change over time. This will give you the information you need to go on and report on whatever data you want to.
Inpart one of this series, we looked at how we can collect data from SmartThings and send it over to an Azure Event hub. We’re now going to take the next step and work on storing that data so that we can use it in our reports and do historical analysis. For this, we are going to be making use of Azure Cosmos DB for storage, and Azure Stream Analytics to move the data.
I’ve recently added a whole load of home automation functionality using Samsung’s SmartThings platform. Part of this is a number of sensors to trigger automation based on motion, temperature, open/close etc. The SmarTthings platform is able to respond to events from these sensors to undertake tasks, and this works fine. What the platform doesn’t really do however is collect this data to give you historical information. For example, I wanted to collect temperature values from various sensors around the house over time to give me a sense of temperature fluctuations throughout the day and the effectiveness of my heating.
Azure Cloud Shell is the web based cmd line tool provided by Microsoft that allows you to launch either a Bash or PowerShell command line in your browser, that is already authenticated to Azure with your credentials and contains all the command line tools you need to interact with Azure, it even includes other tools like Teraform, Ansible, Git etc.
When Cloud Shell was launched it was only available in the Azure portal, however it is now possible to launch an instance of cloud shell from pretty much any web page by including a clickable link with some Javascript to launch a new window and load Cloud Shell.
The relationship between an Azure Subscription and Azure AD is not always obvious, but each subscription is tied to to an AAD tenant, this allows for authorization of users in that tenant to undertake operations on that subscription. Sometimes it is necessary to change the tenant a subscription sits under, usually this is either to change the scope of users that can be granted roles in that subscription, delegate permissions for that subscription, or for services like Azure AD Domain Services, which require the subscription to sit under the AAD tenant that contians the AAD DS instance.
A web app in Azure actually consists of two things, an App Service Plan and an App Service, what is not always clear is why they are two things and what the purpose of the plan part is. The App Service is fairly easy to understand, it’s the actual instance of your web application, it’s where you deploy your code, set up SSL certificates, connection strings etc. The App Service Plan is a little less clear, when you create your app you select a plan and this determines what you pay, but it’s not entirely obvious what it is for, why it’s a separate things, or what you can do with it.
Monitoring your resources is vital to being able to detect issues or opportunities for performance improvements. When it comes to Azure the monitoring story can be a bit confusing with multiple different services seeming to offer similar or related solutions. In particular there is often confusion between two services, Azure Monitor and Log Analytics (part of the OMS suite). We’re going to take a look at these two services and when you would use them.