Around the world, organisations have been building information systems to perform a variety of functions and tasks, as they compete with one another to leverage the ‘latest and greatest’ technologies as they emerge. The assertion that ‘a business is only as strong as its software’ has never been more accurate, and so it is crucial that the correct approach to software development is adopted in any given context.
The rise of microservices
The software monolith has dominated as the traditional approach for architecting a system, particularly among larger enterprises, consisting of various modules that work together to deliver different functionalities. However, as organisations continually strive to increase productivity and become more agile, more of these systems are are being decoupled and split apart into smaller segments.
Microservices have surged in popularity in recent years, thanks to their successful adoption by organisations including Netflix, Google, and Amazon to name a few. An increasing number of businesses are making the decision to split their software monoliths into smaller, more loosely coupled services, with the hope of delivering exceptional digital experiences. In fact, according to a survey by Red Hat, a third of organisations realised benefits following the implementation of microservices within two to six months. However, whilst this style of software architecture can provide significantly improved scalability and performance, it is by no means a silver bullet to every problem.
How are applications built using microservices?
Under the microservice architecture, an application is developed as a suite of small ‘services’ that are independently developed, deployed and maintained. Within this, each service is typically built around a core business capability, running its own independent processes whilst communicating with other services through simple APIs as part of a larger use case. In contrast, a monolithic application is built as a single unit, often comprised of a single client-side, server-side and database layer, with all logic for handling a single request running in a single process.
Software developer and author Martin Fowler exposed the characteristics of this style of architecture further. In addition to the fragmentation and organisation of microservices around business capabilities, applications built using such will typically consist of smart endpoints and dumb pipes. In other words, each service should act as a ‘filter’ containing its own domain logic to apply when necessary, as they aim to be as decoupled and as cohesive as possible. Additionally, microservices support decentralised governance and data management, infrastructure automation through continuous automation and integration, and ultimately evolutionary design for improved business agility.
The implications of microservices on business
The adoption of this new style of software architecture has a number of profound implications. In particular, the independent services comprising an application are more easily managed by individual groups within your software development team, emphasising a separation of responsibilities necessary when it comes to building highly scaled applications. If you haven’t experienced it for yourself, attempting to maintain a single monolithic code base across multiple teams can be a complex process fraught with problems. Changes collide, code quality suffers, and ultimately you’ll be left with a less-reliable application and inefficient development cycles. With microservices, your application can scale as your company and requirements grow.
It’s easy to be immediately drawn to the many benefits that microservices offer, without considering that the approach also introduces its own set of complexities and implementation challenges. Even Martin Fowler himself has stated not to “even consider microservices unless you have a system that’s too complex to manage as a monolith…” With additional overheads in system resources, interoperability of resources and design, it’s quite possible that the cost of the move might simply be too high to warrant it. Further to this, your team could quickly discover a significant increase in time and effort required in managing such a system. Even when it comes down to migrating an old legacy system into a series of microservices in the cloud, lacking the right strategy to do so could be disastrous for you and your business.
So, should I be using microservices or a monolith?
As you might have already guessed, there’s no straight-forward answer to the monolith versus microservices question. The general consensus on the debate is that an application that the traditional monolith should at least be considered at the outset, particularly where it is well-suited to more simple or lightweight solutions. Even where your ultimate goal is developing a microservices architecture to meet the demands of a complex and constantly evolving application, it should always be noted that the implementation of each individual service remains based on monolithic architecture.
Written by Eban Escott
Founder of Codebots
Dr Eban Escott received his Doctorate from UQ (2013) in Model-Driven Engineering and his Masters from QUT (2004) in Artificial Intelligence. He is an advocate of using models as first class artefacts in software engineering and creating not just technologies, but methodologies that enhance the quality of life for software engineers.
