The forward march of Microservices
- Author : Dave Howard
- Date : 24 Feb 2020
‘If microservices are so good, why weren’t they invented 30 years ago?’
This was the question posed by my CEO, Bill Vasilieff, during a walkthrough of the 2020 IT plans. We have already deployed a number microservices developed by FinoComp, to resolve some of the constraints and pain points that we were experiencing with our wealth platform, and I was asking for more money to continue to enhance existing microservices and add new ones. Now, Bill is a good Scot when it comes to money and during the justification process his last line of defence really threw me; “if microservices are so good, why weren’t they invented 30 years ago”? At first, I thought this was Bill’s attempt to dodge the bullet and agree to the spend but as I reflected, the more I realised that this was not a dumb question but inspired.
Microservices have really taken off since 2014 driven in part by Netflix, Google and Amazon who were amongst the early pioneers. In layman’s terms you can think of them as small self-contained and independent units of code and data that are responsible to do one thing. They are the latest version of loosely coupled architectures that have their origins way back in client-server architectures. If you are looking for a simple analogy, think of a microservice as a hang glider and a jumbo jet representing monolithic platforms. A hang glider is lightweight, much cheaper to buy and maintain and it does just one thing – transports its occupant from a hill or a mountain to a lower altitude, hopefully with a serious rush of adrenalin and without significant injury.
All the mainstream proprietary wealth platforms are based on a monolithic design with the following layers:
- The presentation layer (the user interface).
- The application layer (which is composed of the business rules and logic).
- The integration layer.
- The database layer.
From a business perspective the problems of supporting a monolithic wealth platform are:
- Complexity, the code is hard to change and costly to maintain. This means that responding to market needs is a challenge when faced with rigid release cycles that limit business agility.
- Performance and scalability are harder to achieve and require a disproportionate investment in the underlying infrastructure.
- Upgrades are infrequent, inefficient and costly to apply, with lots of effort testing features that haven’t changed.
There are several factors that have led to the widespread adoption of microservices in the last five years. The most notable is the confluence of cloud computing, containerisation, DevOps and the emergence of SAFe as the most popular framework for Scaled Agile development. It’s the latter that has had the greatest impact from a business perspective because:
- The development focus is on products (not projects) that result in the maximum sustainable business value delivered in the least possible time.
- The start point is business capabilities such as reconciliation, payments etc, which are easily decomposed into features and user stories that can be readily mapped to enable microservices.
- Agile and DevOps promotes joint teams with representation from the business, development and support communities. This results in more frequent deliveries, higher productivity through the elimination of resource silos and reduced hand-offs
So how do you get started down a microservice route? Based on our experience, start small. We worked with FinoComp to address some of the performance pain points we were experiencing with the non-core platform functionality, e.g. MIFIDII reporting, CGT, Model Portfolio Management, Costs and Charging.
What we found was that adoption has some fundamental implications on the way we thought about and delivered change. Microservices as a technology innovation will not deliver business agility. To get the full value from microservices they must be implemented in conjunction with an Agile/DevOps mindset and all that that entails for development, deployment, release on demand and continuous monitoring.
Finally, in case you were wondering, I did manage to convince Bill to stump-up the required spend and we are now embarking on the next phase of development and enhancement.
We are currently recruiting for a range of roles including developers and BI analysts. We are based in Bath; if you’re interested in being part of this journey and joining a motivated team of likeminded individuals, check our careers opportunities page.
Predicting a Train with Scaled Agile Frameworks (SAFe)
The British Train network is reliable at getting everyone to talk about how unreliable it is. Trains are delayed, they have the wrong number of carriages, that seat you booked…Read more >
From the lang cat: Our guest on HomeGames today was a legend of the platform sector. Bill Vasilieff was there for Selestia in the early days, and then set up…Read more >