The future in Cloud is event driven! Read along here as Magnus Mårtensson, CPO in Devoteam M Cloud Denmark and Microsoft Regional Director, sets you up for success with events using the Azure Event Grid.
There can be no doubt that reality in the Cloud today, and certainly the future of application communication, is ‘event driven’. Included in the Azure Platform is a slightly undervalued but excellent service called Event Grid that can emit (/send out) events on Azure Service activity. Below you can read how Event Grid works and why you should take care to include it in your service architecture alongside events!
When something happens in your application – a file is uploaded, a user clicks on the red button (never click the big red button), a sale is made – then some other action must most likely follow! Integration platforms such as BizTalk and its Azure Cloud successor Logic Apps are all about the triggering of additional actions after an event has occurred.
Tom Kerkhove is a software engineer at Microsoft and a maintainer of the open-source product Promitor and the Cloud Native Computing Foundation incubation project KEDA. He is a long-time spokesperson for the greatness of the Event Grid. Tom is also a friend of mine. When asked about his preference for the Event Grid, he says:
“Azure Event Grid is the heart of Azure, allowing customers to integrate and extend a growing list of Azure services into their platforms. It is so powerful that you can automate and react to how your infrastructure is doing. Gone are the days of expired certificates, for example.”
What is Event Driven and Event Grid?
I am not sure integration is the final frontier, but it is certainly the case that separate services need to be tied together by events. The event driven programming paradigm has materialized in software patterns, and in concrete frameworks and services that allow developers to build event-based services. Often you hear about event driven programming in graphical user interfaces, but the full scope of the paradigm extends to the Cloud as well. Modern mobile applications are backed by powerful Cloud services and these services are often triggered by events from the user actions in the application.
Whenever you start to think about putting events into your architecture you must always ask the question – why? Events tend to be framed in business language. That is where it starts, “The user uploads a file.” The canonical event often leads to a process that creates a thumbnail and potentially distributes the image file globally in the service. Most of the time events will be business needs that leads to a feature request for the development team. They then need to satisfy the outcome of the event with a technical solution.
A piece of cake for any developer
In the beginning of the Azure Cloud, events for services were not built into the platform services. Today, many Azure resources support emitting events using the Event Grid technology. To continue the example above: when a file is uploaded by the user to an Azure Blob Storage Container, it is a piece of cake for any developer to set up Azure Event Grid for that resource instance, and connect it to for example an Azure Function or a Logic App. These compute services can now act on that new file the moment the file arrived.
Take advantage of Event Grid in your application!
Slightly more technically, there are almost twenty different Azure Services that emit events using the Event Grid, including Azure Blob Storage, Event Hubs, Subscriptions, Cache for Redis, Key vault, and many more are in the works to follow. These services are referred to as event sources. On the receiving end there are event handlers that may be invoked by the Event Grid events. The list of handlers includes the following and more. Azure Automation, Functions, Relay Hybrid Connections, Logic Apps, Power Automate, Service Bus, and WebHooks. If you know how the last one works, you know that if you can call a WebHook from an Event Grid event, you can integrate the downstream action into just about anything. You can in fact write your own Event Grid events to make it even more powerful!
As an architect you can take advantage of this built-in capability to stitch various applications and services together! Of course, you can always draw up a monitoring agent that checks to see if there are new files uploaded, and of course your developers can always write code to trigger an event handler like a Logic App. With Azure Event Grid you no longer need to build and maintain this very standardized functionality. Your architecture is therefore very simplified, and the maintenance of the “glue” between your microservices is no longer required.
An advantage of this kind of service capability is that you pay only for what you use. If your event is not triggered, you do not pay anything, and when it is triggered, you only pay for the number of times it is triggered. The larger cost is likely instead the compute that executes your logic that follows the event. The Event Grid is just a very handy trigger that makes your architecture and development so much easier!
Gluing your picture together…
Today, all of us are likely building ‘Microservice architectures’, where we divide our service into smaller parts to conquer the larger problem. The individual parts of your service need to work independently, scale to your users’ needs, and have optimal cost of ownership, but gluing your picture together and making all parts work in concert can be done using Azure Event Grid events! This really is an extraordinarily convenient way to quickly, effortlessly, and at virtually no cost, get you on the path to event driven solutions to satisfy your business goals and bring you very happy users!
Links for further reading:
Wikipedia: Event-driven programming, Microservices
Azure Event Grid: Azure Event Grid – Event Handler, What is Azure Event Grid?
