Author: Máté Hidvégi, Head of Development at ApPello
When your IT colleague starts playing with building bricks.
These days one can hear ever more about microservice architecture – indeed, since Netflix, Amazon and Spotify have switched from their traditional monolithic architecture to this more fashionable solution, the expression is not only raised in IT circles. But what exactly is microservice and what sort of advantages does it offer? Why exactly is it worth using such an architecture when monolithic systems have worked perfectly well up till now? How can an online banking credit platform profit from this? When is it worth switching, and who should do it?
Before seeking answers to these questions, let’s first go over the basic definitions and compare a classic monolithic IT system with the characteristics of a microservice architecture.
A traditional monolithic IT system, such as, for example, a core banking system, forms an independent entity, it builds on software all written in the same language and all the different layers are closely interconnected. Therefore, its advantage is at the same time its Achilles heel: the entire system can be tested and updated at one time but this may be accompanied by glitches and outages, while a version upgrade halts operations for a time.
Contrary to this, microservice architecture is a software design pattern that consists of separate services that can be easily integrated into the core system, the resolution occurs based on the business processes, that is, a microservice satisfies a specific given business demand. Thus, it is not surprising that they can even be written in a different language and communication with the core system is managed through completely separate channels. Developments and updating happen independently and as such they do not hamper the operation of the overall system.
Tuning your car is the easiest way to get more power…but what about warranty?
In order to better understand the difference, let’s look at a more everyday situation: if we were to purchase a car today, the same technology would serve our comfort and safety throughout the entire period of use, the driving experience would not change over the years. However, development in the auto industry, like many other areas, is extremely rapid. What was state-of-the-art in the first year quickly becomes totally standard, or even outdated. In-car monitors are getting larger and higher resolution, there are increasing numbers of built-in intelligent functions, not to mention that the range of clean electric cars is also growing at a faster pace. Imagine a vehicle where every function could be individually replaced: one or two clicks and the monitor could be removed, which could then be switched with a more modern unit offering higher resolution, the body could be retrofitted with various accident-prevention sensors, but let’s go even further and say that a battery with a current range of 200 km could be switched out and replaced with a power unit providing a much greater range. We wouldn’t then have to change cars every 3-4 years if we wanted a better and safer driving experience, it would be sufficient merely to swap the built-in modular elements and straight away we would have more modern technology at hand.
So, what to do?
Whereas for the moment such vehicles built on a modular basis can be considered utopian for technical, or more likely commercial, reasons, we have been able to enjoy the benefits afforded by microservice architecture in numerous other areas for a good few years now. Well-known examples come from tech stars like Netflix, eBay, Twitter or Spotify who went through this transformation years ago. Initially, Netflix built on the monolithic system but today it would be unable to function without microservice. On a daily basis it receives 1 billion streaming requests from approximately 800 different devices – without microservice architecture, the system would simply be incapable of serving this vast demand arriving from such a diverse technical background.
Anyone who plays with building bricks, especially Technic LEGO, will see that today, each sub-unit can be modified in a modular way. By moving one or two studs, the chassis and engine of the LEGO car can be removed, it can be upgraded and motorized with either off-the-shelf sets that can be bought separately or with modifications based on descriptions from the Lego community. The principle is similar: make development and building flexible and convenient.
However, returning to the world of software, let’s take a closer look at what exactly microservices do and what benefits they have to offer.
As we have already shown, microservice architecture was intended to replace the inflexibility of monolithic systems. Thus more compact, independent and separately installable services can be built on to a larger system. Given their decentralized nature, they are independent of the developers of the core system, even a totally different team can design them and in many instances they are written in different languages. A core system, such as a core banking system, communicates with other databases, such as an external credit rating system, via interfaces. This interface can also be realized through a microservice. This means that if there is any change implemented on the external database, it is sufficient merely to make changes on the relevant microservice. This allows the system to run smoothly, and testing and restarting a single function solves the problem.
The next significant advantage of microservice is upgradability. Since it is easily modified and then easily re-integrated into the core system, the IT platform can always be supplemented with the very latest technology. It is not even necessary to commit to a single technology since different microservices can use different solutions in parallel. Returning to the example of the car, such a microservice could guarantee, for example, the retrofitting of cutting-edge smart solutions into our vehicle.
What happens if a fault is introduced into the system? Firstly, with a monolithic architecture the entire system could shut down, and secondly, it is far harder to locate the error. In microservice architecture, the source of the error can be pinpointed much faster and it is easier to isolate, furthermore, it is sufficient to shut down only the given microservice, which does not disable the operation of the entire system.
Sounds good, doesn’t it?
Like any system, microservice architecture also comes with some drawbacks. For example, if too many microservices are built into the system, the added complexity can actually work against efficiency. Too much cross-referencing can slow communication, complicate and extend testing, and overload the system.
To sum up, there are still many arguments in favour of the new approach. The banking environment is exactly the sort of area where the system is not frequently updated, so any solution that incorporates innovations or new functions without totally shutting down the system will come in handy. The core system can be integrated, but microservices can be used effectively in all parts of the system that require flexibility and upgrading.
ApPello Digital Platform integrates many of these microservices and builds onto the core system. These auxiliary elements guarantee flexibility in operations, development is faster and cheaper, testing is easier, and error detection is simplified. Anything that is outdated can be swapped. If only we could do this with cars…