There's a new kid in the block, every person interested in horizontal scaling is talking about. It is the Microservice design pattern. Long time ago before my rebirth into the technology scene, companies had adopted a monolithic design pattern for their systems. A monolithic pattern is a model where all the application components are tangled up as one artifact that is deployed on the production environment.
This kind of architecture worked for most of the companies for quite a long time, i can attribute this to the slow rate at which technology was adopted by organizations in ‘Yahoo age’. But with time new development methodologies started coming up, adoption of technology was rapidly scaling and companies were now facing a threat. It’s either they scaled or shipped-out. So scaling meant thinking without a box near you, it had to be different and superficial. I believe through this a new pattern called microservices was cooked up. This is the ‘Uber Age’, a generation attributed to so many things. Maybe we can call it the Industrial Revolution 2.0.
Looks like am politicking too much, it’s time to take a deep dive and understand microservices and how they apply to this context. Microservices is a software architecture pattern which adhere to a loosely coupled way of building system components. It involves separation of non-dependent modules from the application core into independent system components which can be run and managed independently.
To explain this concepts in a contextualized manner am going to take a case and scenario of the Mpesa platform. A lot of assumptions are going to be made.
Mpesa as a Monolith
I strongly believe that the first version of Mpesa was a monolithic application. This is derived from mere knowledge i gained from using the services as an end user. From my observations, the Mpesa G2 has been more effective and more available. To point out a few characteristics of a monolithic application i will use cases based on my experience as a user.
Transaction Delays
Most of the time before the system was revamped to the Mpesa G2, clients used to go through a series of frustrations because of transaction delays. They were so unpredictable that you would rather carry cash or depend on your card for emergencies. I remember a time i was out with my boys and i ordered a cocktail for a pal of mine at around 0001hrs, to my surprise the transaction didn’t go through and i had to start hustling my friends for money to settle the bill :-(. It wasn’t an interesting thing to do.
This is mainly attributed to the architecture of the system. Imagine a scenario where all requests are being handled by one application, even if you are to scale within no time you will hit the ceiling provided by your resources. The funny thing might be that 10% of the people are checking there balances, 30% doing B2B transactions and the 60% doing P2P transactions. Imagine if all this were classified as services and ran independently….food for thought.
System Downtime
Whenever Mpesa was undergoing a major upgrade, it meant that you had to wait for almost 72 hours before you could transact on the platform. I cannot imagine the kind of torment a country dependent on mobile money for peer-to-peer transactions went through. This is mainly because a monolith does not provide a smooth way of upgrading specific components of the system. So incase i added a new feature for loans and savings it means i will have to pull down the application to do upgrades and then propagate the same to all redundant servers. This is unacceptable and as a CTO it’s a bit troublesome because everyone will be on your neck.
Those few cases can give you an idea of how a monolithic application can be expensive to maintain.
M-Pesa as a Microservice
Assuming that a microservice architecture was adopted as part of the Mpesa G2 platform , these are the benefits it comes with:
Availability
Since the upgrade my worries have been trashed down to zero, all i know now is that Mpesa is a 24/7 service. I cannot remember the last time i have had to wait for 15 minutes for a transaction to go through. Just over the weekend i was doing a transaction between Mpesa and My KCB account, i noticed that Mpesa was working but KCB seemed to have a problem. This is true definition of Microservice, some components of the system can be developed or suspended without affecting the availability of the system. This would not be possible in a monolithic architecture.
Faster Transaction Processing
Even though some people do not guarantee speed with microservices, i tend to differ. Because if a service is made light it means less execution time and thus guaranteed speeds. Also note that the micro-services could be scaled vertically to accommodate the requests coming. Most people who transact with Mpesa can attest to that, however this is also attributed to the relocation of servers from Germany to Kenya.
Integrations
As a developer it is always my joy to work with platforms with APIs that can allow me to perform any particular operation that pertains to the problem am solving and relevant to the platform features. Before Mpesa G2 the only way you could be able to interact with Safaricom Mpesa system was through an IPN(Instant Payment Notification). This is a single line communication with one ‘dictator’ on the service end, this is disadvantageous particularly because you have no control over it. You cannot even query or verify a customer’s transaction because you couldn’t talk to the system anyway. With the new system in place you have several integrations that can be performed. I believe most of this operations are compartmentalized as microservices. This means if i have integrated with one service, the failure of another service should not render my platform inoperative.
Manageable Code Base
Businesses are scaling too fast and this means that their is exponential growth of personnel and codebase i.e O(n). To utilize the available resource effectively work should be simplified. So instead of giving one developer a whole 1,000,000 lines of codes, they just get to work on a 1,000 lines of code microservice. This improves ultimately on delivery time and also reduces the amount of resources required to get work done.
Polyglot Programming
This is not a new concept at all, it involves the use of multiple programming languages and multiple modularity paradigms in application development. With microservices it means that engineers have the capability of programming a certain service in a way that suits the needs of the problem at hand. For instance Safaricom the mother of Mpesa introduced a new taxi hailing service, for some reason i believe they will integrate their payments and location platform with Little i.e taxi hailing firm. This means we need to program this two platforms differently in order to harness the power of the different platform and thus improve on the system performance. With a microservice architecture polyglot programming works fine because each service is independent and it will only communicate over a standard interface, this means a service does not need to be aware of the architecture or development tools used by another service.
Conclusion
There's a lot more that comes with microservices design pattern, i have only mentioned some of the high level components which comes bundled with microservices. If you need to learn about the internals then you have to study a lot and come up with designs that can work to create a microservice architecture.
Microservices as i say is the talk of town and whoever shall not heed the call and adopt the architecture will be left out. It is one of the patterns that will streamline the IT of a company and makes clients happier than ever.
If you fall in love with this article kindly recommend it to others. :-)
References.
Microservices architecture_This site describes a new, alternative architecture: microservices. Applications with a microservice architecture…_microservices.io
Polyglot Programming