What I'm Learning: Various Azure Services
Tags: journey, learning, azure
Published: 2019-11-24 02:05:34

---
title: What I'm Learning: Various Azure Services
published: true
date: 2019-11-09 23:56:11 UTC
tags: Journey, learning, azure
canonical_url: https://www.samjarman.co.nz/blog/learning-azure
---

Hi All,  
  
Lately, at my new role, I’ve been doing a lot of work with Azure. Being #Ignite week, I thought I’d share some of my impressions and learnings so far. For context, I’d not used cloud services in my previous role, and before that, I had used a fair amount of AWS.   
  
Of course, no one developer will use all of Azure, they’d probably explode. But I’ve interacted so far with a few components worth talking about.  
  
First up, **Azure Storage**. Azure Storage is an interesting service that combines the storing of files (blobs), records (Table Storage) and other items. I’ve used it so far for storing files temporarily and I’ve used table storage for storing structured data temporarily.

**File storage** works well, and with the [JavaScript SDK](https://github.com/Azure/azure-sdk-for-js/tree/master/sdk/storage), interacting with it from my code is fairly straight forward. The key concepts to know are few: A blob lives in a container which lives in an account. A blob might be ‘hobbiton.jpg’, a container might be “holiday photos”, and the account might be ‘Memorable Photos’. So if you know the latter two at runtime, then basic CRUD operations on files is easy. Nice. 

On top of this is files that can auto-delete themselves and that can be accessed by SAS token as well. These handy features means it was very easy to attach thumbnails securely to our customer’s slack notifications. 

**Table Storage** is something I’ve also found really neat. Coming from S3, where I’ve only used file storage, Table storage was an interesting concept. It allowed me to define reasonably flexible tables (actually no schema at all) and use those without having to modify or reason about the main SQL Server database that our backend uses. However, I could have used the SQL Server database for my use case - and an open question I still have is when is the best time to use table storage vs SQL server. If you have any thoughts I’d love to know. An important thing I’ve learned for Table storage is to pay close attention to your partition key. Partition keys hint to azure as to which rows in the table can be stored together. So, if you put the same partition key on records you’re likely to query or read at once, you’re going to get more performance, as table storage has to go to physically fewer locations to get your data. I’ve used table storage for our email batching system, and the partition key on the insert is the recipient of the email. When it’s time to send out a batch, I query one person at a time, and these are subsequently quite fast. Nice.

The most interesting service I’ve uses is **Azure Service Bus**. Anyone who knows me, knows I have quite a soft spot for queues and streams in backend systems. They scale better, they can auto-scale well, they are easy to debug and easy to monitor. Azure Service Bus is Azure’s queue and stream offering. They have “Queues”, which are, er, queues, and “Topics” which one-to-many queues. With Topics, you can have many subscribers (I think 2000) and each has its own copy of the message to do what it likes with, including dead letter. Annoyingly, while these are definitely queues, the portal doesn’t show a breakdown of these like they do with the first-class queues. I found [this windows application](https://github.com/paolosalvatori/ServiceBusExplorer) handy for that.   
  
I’ve had a few issues with the Service Bus SDK for JavaScript, but it is new. Azure support has been great and released a bugfix when we provided them logs showing an error. We also had some issues with them not receiving messages in our environments after about a week. I’ll talk about how I fixed that in a future post. (Spoiler: Check _isReceivingMessages_ in your liveness probe if using Kubernetes…). 

While topics can’t really be thought of as streams, such as those provided by AWS Kinesis or Apache Kafka, for my uses they’ve been largely the same if even a little better. 

Apart from Service Bus and Storage, I’ve interacted with other services only a little. We use **Azure DevOps** as our CI, and that seems fine? I think like most devs, you only tend to truely experience CI when it breaks, and it hasn’t yet.   
  
On the monitoring front, I have enjoyed **Azure Alerts** , [which I believe is newly centralised](https://channel9.msdn.com/Shows/Azure-Friday/Unified-alerts-in-Azure-Monitor). The concepts are easy to grasp and I was able to quickly get an alert firing. I must call out the super useful usability feature of metric alerts where there is a time-series graph of the metric’s previous values (eg CPU usage) and you can see your metric threshold placed against that and drag it up or down based on how noisy you want the alert to be. Anyone whos ever been woken up at 3 am by an over sensitive alert will appreciate this greatly.   
  
As for getting the metrics in, the **Azure Application Insights** is handy. Again, a [simple JS SDK is provided](https://github.com/microsoft/ApplicationInsights-JS) and its a couple of lines to get values that mean something to you into a graph. You can then alert off these and what-not.   
  
Lastly, I’ve used **Logic Apps** (kinda an IFTTT type tool) to get those alerts into Slack. I’d love to see a first-class Slack Integration in Azure Alerts in action groups (+ ms teams etc).   
  
I’ve used a few other things, such as **Function Apps, Log Analytics, Kubernetes Service, Web Jobs and App Service Plans** , but these have been largely abstracted away from my day to day workflow, so I don’t have anything to say about those.   
  
Overall Azure seems great but I think suffers the same problems as other cloud providers. Some tools seem mature, some seem dated, some seem new and rough around the edges. You know many many teams work on this suite of products, and each has its own roadmap. But I can see promise all throughout the suite. I think comparing to AWS at this point is kinda incredibly hard to do. So far, it seems to be on par to me, without a clear winner. I think the best cloud service is the one that does a lot of what you want with the most minimal problems, and grows with you and has great support. The problem is, that evaluation is usually only possible in hindsight.  
  
This is the start of a long journey, and another step on my personal journey with clouds. We’re all on the same path as clouds computing becomes more and more common, so I urge you all to keep sharing all the cool stuff you find and that has helped your business.   
  
Did I get something wrong? Should I check out something? Tweet me or comment with your thoughts – I’d love to hear them.  
  
Best of luck,  
Sam