Azure Playground - JO3-W3B-D3V

My Absence

Firstly, I know I’ve not posted anything here in quite sometime & I am sorry about that, I will follow up as to why & what’s been going on in my personal life that has essentially meant that I’ve not been as present online, etc. Even now, I’m in a mad rush to get this post done, I simply wanted to share some of the fun stuff that I’ve been tinkering with in my own time.

But anyway, let’s dive right into some fun shall we? I wanted to take a moment to talk about how easy it is these days to setup an environment using a platform such as Azure & how easy it is to achieve some nice event driven architecture on a tight budget & with limited resources. I like to often look at implementing such architecture with a very, very limited budget, time & resources. A scenario I know is all too real for a number of small to medium enterprises, not to mention startups & so on.

Getting Started

As I’ve said, I’d like to steam ahead & simply jump straight into things, this isn’t intended to be a simple walk through on how to setup an Azure account or anything like that. This is somewhat a step ahead of that, where we’re going to get our feet wet into more technical subject matters. For instance, I’m going to assume that whoever is reading this is no stranger to the CLI. I personally prefer to work with the Azure CLI purely because I’m lazy & find it easier to work with as opposed to some GUI, especially to handle more specific elements that you may have to dig to get to via some GUI.

So, let’s assume you may have what? A maximum budget of £50 for the month, that’s everything from the application server(s), the database, networking, etc. So yeah, you might be toying with an idea at this point in time. In such a scenario, it can be hard to setup some sort of solution architecture whereby it can scale really nicely, etc. So let’s keep it simple & assume that we’re able to create an application that can do a number of tasks in an asynchronous manner. A fine example being the onboarding process.

For a bit of context, I’ve decided to look at some kinda onboarding process because it can be pretty complex, especially if you’re trying to work with a number of different tasks, such as sending an email notification to the user that’s going through the onboarding process. Another example might be initially setting up & verifying some payment details, another example might involve setting up MFA, the list goes on. Naturally, it’s the kinda thing that’s pretty specific to your product & there’s no one fits all solution here, but the overall journey can in fact be asynchronous. But let’s just work with the idea that we’ve got a very bog standard synchronous implementation for the time being.

So the process might look something like this;

Okay, that’s not terrible, I mean it might do the job, sure, after all, one big thing about the agile mindset is to focus on delivering functioning software, if it does the job, awesome. There’ll always be more time later on to worry about performance optimisation, cleaner code, etc. When you’re in a startup environment, it may be a matter of common sense, but you should simply focus on trying to deliver value to your customers, that’s the number one priority. You need to start generating revenue & even better, profit, so being super pedantic about the fine details, etc, in this context, it’s just silly. Sure, if you’re a big bank or you’re an organisation where you’ve got a lot of money, time & resources, yeah, there’s less of an excuse for writing sloppy code. But a one man band trying to build a business from nothing, it’s a totally different ball game & you have to accept that the code isn’t going to be a work of art, you’ve got much bigger fish to fry at the end of the day.

So with this in mind, you might want to take it a step in the next direction, where you want to be able to evolve this so that you’re not waiting around for the email service implementation to send out an email template, etc. In such a scenario, you might want to mature thing to the next step, for example;

So this might be the next step in the right direction, where we use some dependency that we’ve called an event emitter, on line 65, you can see that we’re simply emitting that something happened & we’re purely looking to create the user & the account in this run. But you could even take things a step further, if you really want to drill into the spirit of single responsibility, you could look to do something a little more like this;

So as you can see, we’ve progressed here where we’re no longer doing a great deal in one run, we’re essentially relying purely on the event driven architecture to take care of things for us. We’re not talking to the database in this bit of code, since that’s a potential dependency that could fail, there could be a network outage, etc, this is an example of some of the wonderful problems we software engineers face on a daily basis. Granted, this solution isn’t 100% bullet proof, I don’t think anything truly is 100% bullet proof, but we can try our best.

The Infrastructure

Now that we’ve seen some code that we’re working with, we’ve briefly stated that we’d like to use some sort of queue or some piece of technology that allows us to process tasks asynchronously. Now, I’ve been playing around with the Azure free trial just to test some ideas out & one pretty cool tool that you could use for this is the Azure service bus, it’s really cheap for a start & it simply put does the job, even if you decide to work with the standard tier as opposed to the basic tier. You can have a look at the difference yourself here.

Anyway, as I’ve said, let’s use the Azure CLI, because it’s a really handy tool. For this instance, let’s just skip a few steps & assume that we want to spin up an all singing, all dancing environment that can handle a number of different tasks.

So with this script, its intention is to simply setup some environment & build some of the following tools & functionality;

A MySQL database
An event handler Azure function application that’ll use a service bus trigger
- Hidden from the world wide web behind a private endpoint
An Azure function that will use a time trigger to handle things like CRON jobs
- Hidden from the world wide web behind a private endpoint
An Azure web app for some admin portal
An Azure web app for some RESTful API
A static website for some brochureware
etc.

Useful Code Snippets

For those of you that might be interested, this is the general implementation that I had in mind when sending messages to the service bus, yes, I called an event emitter in my code, but call it whatever you like, I just thought it was a nice & simple approach.

If you’re also curios, for the likes of the domain events, that is quite literally just a static object where the keys simply point to a string. There’s no black magic going on there.

Then on the other end, where you might want to have some sort of domain events map, you could do a very similar thing, where you might flip it a little, for instance;

But as always, by all means, don’t take my solution or my word for it, by all means I encourage you to experiment, to tinker, find what works for you. A lot of the time, in these kinda projects of mine, I will simply go for simplicity, because why over engineer it?

The Pudding

As they say, the proof is in the pudding. And damn right, it is. I’ve been running something similar against my free trial account & so far, I’ve had this setup for roughly a month & I can confirm that so far, it has cost me a whopping £20.45. You could even cut some more costs from that by skipping the virtual network & private endpoints if you wanted to cut back a little there.

If you don’t believe me, here’s a little break down of the costs against my free trial.

I’m not a wealthy man, but even I could comfortably afford to work with this setup & I do genuinely love the fact that it includes some architecture where it has a nice bit of headroom to scale. Granted, if you’re planning to be the next Google, yeah, it might get a tad bit more complicated than this, but for a typical startup that needs to be able scale in the not so distant future, I think this is a pretty solid starting point.

Conclusion

I hope that you’ve enjoyed this read & I hope that this has been somewhat insightful & even better if it has been useful to you. As I’ve mentioned throughout this article or post, I tried to think about creating some architecture where a startup with a tight budget could create something that has some ability to grow & scale. You could even create more services if you wanted to, you could use a microservice-esque architecture if you so desired.

The nice thing about an approach like this, it allows you to actually take advantage of distributed transactions, sure, I’ve not gone over any choreography in any great detail here. But it’s just nice that the architecture allows you to consider this as a potential avenue, where you can actually rollback transactions if you need to, etc. This is one problem that arises when people create some sort of distributed architecture, but only rely on simple HTTP calls between different services, while it might not be a huge issue for some, it can be a world of pain for others. I hate to repeat myself, but like everything, context is king, even the architecture that I’ve used in this article, you could just call it rubbish. And that’s a fair point, for your use case, that may very well be the case & you may need to consider some more big boy toys, be that K8s, Kafka, DNS load balancers, regional load balancers, etc, the list could go on.

One thing I like about the solution in the third example is that it just means that if you’re doing all of this via some RESTful API or some web based application, you can simply have a response almost instantly. Since all that really happens is that we create some objects & then we simply throw that at the Azure service bus, job done, we don’t make any other networks calls, we don’t run any relational database queries, etc. So, I feel like I can confidently say that the performance of this approach should be awesome.

On another note, I do plan to become more active again, but it’s a case of we’ll see for now, things haven’t been entirely smooth sailing, not that there’s anything wrong or anything dramatic going on in my personal life. But it’s simply the case that I have had to prioritise my time elsewhere. I promise, I will give more insight in my next post as to what’s going on, but for now, it’s a case of trying to find the right balancing act, I’ve not publicly said much around this subject matter, since I’m struggling to find the right words to inform you. It’s nothing horrible, but it’s a subject matter very close to my heart, so I’m trying my best to make sure that when I make it known publicly, it’s done with some sense of elegance, grace & so on.