The monolith to microservice spectrum

Best-of-breed software part 1

This is the first in a three part series, covering:

Enterprise software buyers have a really hard job. Aside from the specifics of meeting requirements, there’s no escaping the difficulty of the underlying architectural decisions an organization needs to make in order to buy well.

If the technology systems of your company are simple – with few users and minimal integration – you may be able to buy something that just does the job. But, most often, that’s not a strategy that can scale with your business or the changing technology landscape. Usually, there needs to be some consideration of architecture even before shortlisting a vendor.

The decision regularly comes down to buying a monolithic-solution or a point-solution. That is, you can buy a monolith (or suite) that handles the majority of the functional requirements of your business in one solution; or you can buy many solutions that each fulfil one function. Of course there are some solutions that fall between the two, which will be the subject of the next post in this series.

Now, on the face of it, a solution that meets all of your needs in one tool is the obvious winner, versus one that only meets a single need, but – as we all know – it’s not that simple.

Personally, in order to bring clarity to a difficult decision, I like to consider the polar extremes: a solution that literally does everything ones business needs verses a microservice that only handles the slimmest, most atomic function.

Take the example of an online newspaper (as an industry I know well). They need solutions to, at least:

  • Author content
  • Publish content to the web
  • Manage registered user data
  • Authenticate users
  • Hide content behind a paywall
  • Manage recurring subscriptions
  • Curate newsletters
  • Manage email lists
  • Send emails

(In fact, the list is much, much longer than that but they would definitely need to do those things.)

First, let’s consider the monolith. For a green-field publisher this might be an attractive option. One vendor (throat), one set of training for their users, one bill. And, hopefully, the whole business is supported by one integrated solution.

There are three particular drawbacks to the monolithic approach.

One is that the implementation project is likely to be huge, which constitutes a substantial gamble: if the project goes wrong the cost could be existentially damaging, particularly for a new business.

The second problem is vendor lock-in. Assuming the project is a success, what happens a year or two down the line if the publisher wants to change the way they send emails? Maybe they were getting a lot of bounces; maybe the reporting is inaccurate; whatever the reason, the solution is not cutting it and a better one is now desirable. The issue at this point is that the publisher is paying for the email sending functionality of the monolith, whether they are using it or not.

Finally, there is a more insipid problem of the development and maintenance. You should be cognisant to the fact that the vendor of a monolith is competing with several best-of-breed and point solutions, across different functions. If they offer a CMS (authoring & publishing content), an IDM (user data and auth’) and a paywall (access control & subscriptions) then there would be an alternative architecture with 3 separate best-of-breed vendors or 6 point solutions; so the monolith’s development team (and other teams) would need to be in the same order as 3 best-of-breed vendors combined. If they’re not, how can they be investing in their product competitively?

So, what about microservices?

The benefits of microservices are well documented elsewhere but, to summarize, because each service is modular and focused they can be built and maintained more easily and quickly. The service only has to worry about one thing and has a strict interface between it and other services so:

  • you can rebuild or refactor them often, without worrying about the rest of your stack;
  • you can use different technologies and programming languages for each service, picking the most appropriate for each, and;
  • when you release, you are testing an isolated scope.

All of that is predicated upon the architecture being responsible for the interactions between the services. A development team can safely work on just, say, Content Authoring because there is a strict interface (what comes in and out of the service must not change) and there is some kind of transport between them, such as an event bus or HTTP calls.

The real challenge with microservices is that architecture – the glue between the services. Each service is less complicated but the entire system is a whole lot more complex. Some services might be built in house, some bought; in that case you need to abstract the APIs of the bought systems to fit in with your interfaces, which means an API gateway, of some kind. The services you build yourself need to be containerized, load-balanced and auto-scaled. You need to monitor performance at either the interface or the network level to identify bottlenecks… It gets complicated.

In some cases, another down-side to a microservices architecture is performance. This one is arguable and depends a lot on specifics but more network request between the interconnected web of services means more latency. That should be considered too.

So, from this point of view we can see there is a trade-off between simplicity and flexibility. Monoliths are simple solutions, in many senses, but really undermine organizational flexibility; Microservices are flexible but come with an architectural complexity that should not be underestimated.

If these two traits – simplicity and flexibility – are equally valued and dissipate linearly from one extreme to the other then there is no outright advantage for any particular point on the spectrum. You would just chose the solution you liked. That, however, is probably not the case.

The value of each trait is absolutely dependent upon your team and existing systems. If you don’t employ any solutions architects then the value of simplicity is massively inflated. If you have very unique requirements that can only be built bespoke, then flexibility may be more important for you. In part two of this series I will have a look at some example cases and explore a framework for answering the question “how big should your software be”.

In practice, most enterprises will have some blend of solutions from across this spectrum. Extremes are generally risky and solutions that fall somewhere between microservices and monoliths may be the pragmatic choice. In part three of this series I am going to explore which functions should be collected into best-of-breed solutions and why.

Leave a Reply

Your e-mail address will not be published. Required fields are marked *