I realize it’s been a while since you heard from me. What can I say, demands from family and clients tend to keep me from writing. Besides, writing is hard. I prefer going for a ride on my beloved Harley to sitting at my desk trying to organize my thoughts.

This blog post series has been in the making for several years though, I feel that I ought to write it now, almost like a debt owed. In more that one respect this is a monumental event, I need to tell you about event driven serverless architecture.

An event-driven architecture uses events to trigger and communicate between decoupled services and is common in modern applications built with microservices. An event is a change in state, or an update, like an item being placed in a shopping cart on an e-commerce website.

https://aws.amazon.com/event-driven-architecture/

This probably sounds more than a bit abstract, I know it took me a while to get my head around it. Event driven architecture is a really deep down fundamental design choice, a choice to move away from big centralized applications to smaller integrated microservices. It is not just a product, or a tool, that you can start using. It is a different way of thinking about an entire application landscape.

Related reading Slaying the behemoth, Extension Design Principles

Let’s try to make this a bit less abstract. Please consider this usage scenario. Stuff & Co is a company that sells items to customers through several webshops. They have their own webshop but they also use several marketplaces to sell their items. All of a sudden I need to keep track of many events, not just incoming orders, also Item price and availability, customers, shipments, invoices. Even a small event like placing an item in a shopping basket becomes interesting. If 20 customers place an item in their basket while I only have 10 of these items in stock I’m going to need to gear up my replenishment or production processes.

Stuff & Co uses Business Central for their financial administration and warehousing. Unfortunately they find they are drowning in a million different integrations that slow down the primary process of their Business Central server. All these integrations are also impossible to maintain, it takes serious effort to integrate a new webshop, or to keep items up to date across the application landscape.

Stuff & Co are not alone in this. One of the biggest concerns my clients seem to have in the use of Business Central seems to be optimizing Business Central for posting as many documents, usually shipments, as possible without locks. This is nothing new and it is at the heart of my design philosophy; Business Central is used for the reliable tracking of money and goods. And nothing else.

The problem we have here of course is the “nothing else”. How are we going to do the other things we need to have done? How are my items and customers in many different companies, databases, or even applications going to stay in sync? How will I import and export my data? Invoice scanning and recognition? And many more questions. Fortunately my clients also gave me the answer for this, serverless computing. More than once I have helped clients to move non core Business Central processes to a serverless back-end they have already started to implement. Being independent I have used both Amazon Web Services and Microsoft Azure. I must confess to a slight preference for Azure, though that may be caused by years of conditioning. Both are able to provide the services I need but I will use Azure for demonstration purposes.

Using Business Central to handle data imports and exports is like using an 18 wheel truck to pop to the shop for a loaf of bread. Of course it’s possible. It’s also not practical and a waste of resources that can be better used elsewhere.

Why would I pay for a service just to send data to other systems, I hear you think. This, of course, is a very good question that is easy to answer. Scalability. The great joy of using an event driven architecture is that it is insanely easy to scale. Remember Stuff & Co and their multiple webshop integrations? What if I want to integrate a new webshop? Or notify customers that an item is being picked? By using an event driven architecture I can easily build small applications that will subscribe to events. If something changes I can simply change these small applications.

The big challenge is of course to integrate Business Central to the events infrastructure that Azure or AWS (or Google or any number of vendors) offers. I need to push my Business Central events to my serverless back-end and I need to subscribe to events that occur elsewhere in my application landscape. With the added challenge of not interrupting the flow of my Business Central core processes.

I realize I have taken up a lot of your time already. The second blog post in this series will describe sending events from Business Central to the Azure Event Grid, the third will describe subscribing to external events, the fourth and final blog post will describe how to make Business Central data available to your other microservice applications.

Related reading A monumental event, part 2

Photo by Pablo Heimplatz on Unsplash