Microservices have been talked about a lot in the last few years. And it’s commonly accepted practice that applications should start as monolithic applications before being broken down into Microservices. In fact that’s exactly how we made Splitoo.
Earlier in 2019 I made a commitment to improve some technical aspects of Splitoo. One of which aspect you could call Microservices. At Splitoo since we’re a small team, we made some fairly intuitive decisions to break down the application into Microservices based on some tell-tale signs that it needed it.
What we realised is that our decisions to break down the app came from getting more intuitive about the tell-tale signs that an application is getting too big, and could benefit from being broken down into microservices. And that’s what we’ll be talking about today.
By the end of this article you should know four tell-tale signs that an application could benefit from being architected with a Microservice approach.
What is a Microservice?
Before we get into the ways that you tell if your application should consider Microservices, let’s look at a definition.
The community is divided on the definition for a Microservice. But let’s define one that we can put to work today.
A Microservice is a single (independently deployed) part of an application typically communicating with other services over a network boundary.
With our definition in the bag, let’s get into the detail of the signs that your application might benefit from being in a Microservice architecture.
1. You Want To Have Separate Deployments
One main way of noticing that an application could benefit from Microservices is you start desiring independent deployment processes.
But, why might independent deployment be desirable?
One reason that we might want separate deployment processes is that different part of our application are more (or less) mission critical. It might benefit us to split our deployment process so we can be more aggressive and experimental in some areas, and more cautious and reserved in others.
To give an example, since Splitoo is a finance application there are inevitably parts of the application which are more critical than others.
The critical services are the ones that cover our core customer journeys and are the ones that would cause a large impact on our user base if they were down or unstable. If you notice that your application has these different areas then it could be time to consider Microservices.
2. Your Automated Testing Is Becoming Complex
In a large monolithic application testing gets complex. More code means it’s harder to spot where application might not be adequately tested. Not only that, but an application coupled in deployment is doomed to deploy as slow as its slowest tests. So that’s spotty test coverage and slow running tests, not great. And at this point you might start considering breaking down the application in order to achieve better test performance.
To give an example, Splitoo has a core web application — which is complicated. The core application has login, state and complex logic. If we compare logic of the core application with some of our basic splash pages, the testing needs are significantly different. Testing splash pages is simple, no login state, no application state. Whereas the core of the application is much more complex. There’s no good reason to wait for the core application tests to run to release our splash pages.
Maybe it’s time to consider Microservices?
3. You Need Separate Tech For Different Parts
Monolithic architectures can get locked into a single technology. But some problems can require custom tech.
Maybe you want to do some data heavy processing, that requires data libraries with Python, or a lot of compute resource? You don’t want to clutter your request serving API’s with resource hungry data processing tasks that can be ran out of hours or on cheaper machines.
Breaking down an application to Microservices gives you the flexibility to choose different application and even infrastructure to architect your solutions. If you find parts of your application have different technology needs, it could be time to consider Microservices.
4. You want to re-use components more easily
Parts of many applications are reusable. But, of course, re-use is a dance with the devil. You may spend so much time abstracting away useful parts of your application only to realise: no-one uses your “re-usable” component. Or, the original component becomes so complex due to the abstractions.
A more pragmatic approach is to build something useful, and then spot the commonalities. These common components could be a good candidate for a Microservice.
To give a final example, in Splitoo we send a lot of emails as part of our on-boarding, for instance. But the process of sending an email isn’t unique. So we’ve broken out our email sending logic into a separate microservice that can be easily re-used.
Can you spot the signs?
And that’s a wrap for today! A quick run through of some tell-tale signs that your application might be busting at the seams. These aren’t all of the signs to break down an application, so I’d love to know what signs and symptoms you’ve come across, too.
With these in mind you can start to build your own intuition for seeing when an application might benefit from being broken down into microservices!
Can you see any of these (or other!) tell-tale signs in an application you’re currently working on?
- 2023 Summary: Data Driven Stories About The Cloud - December 31, 2023
- 2022 Summary: The Open Up The Cloud System - January 1, 2023
- Open Up The Cloud Newsletter #30 (January Recap 2022) - March 1, 2022