TopDog Bank: Where every client is a good boy.
With a rapidly evolving software development methodology in today’s world of business, “microservices” has become a new industry buzzword. But what is it exactly? What benefits and drawbacks can one expect with this approach? To help illustrate this concept, we will use the TopDog (TD) Bank, “Where every client is a good boy.”
Microservices are exactly as the name denotes: a series of miniature independent services that perform specific business functions. It’s a variation on traditional software architecture that inherits the same needs of deployment and maintenance, but on a more selective and smaller scale.
Let’s run through our use case of the TD web-banking application rollout led by CIO Mr. Lassie. This was a giant single application that was developed using traditional N-layered architecture, which means it was hosted on multiple machines as a single stack. Data would be pulled from databases and files on the back-end, run through a series of application layers that would modify, host, and wrap the data, which was ultimately presented to the user via a web browser interface.
The Problems
Mr. Lassie’s IT team noted a number of issues and headaches with this approach as they maintained the application over a number of years.
- Code maintenance became a series of mazes and as the code base was dedicated to supporting one monolithic application. As developers come and go, sifting through code to update one specific feature is difficult at best.
- Once an update is ready for a specific feature, the entire application would have to be taken down and re-deployed as a net-new application due to it being hosted as a single process.
- Due to it being a single process, this means the entire application is deployed to multiple machines rather than specific services of the application living on their own supported servers.
- As TD reported record customer growth, scaling every bit of the application to handle the influx of users resulted in longer development cycles.
- Longer development cycles and tedious downtimes cost money; something the CFO Scrooge McRuff was not happy with.
Enter Microservices
This is where microservices comes in and addresses the aforementioned pain points. The architecture setup for microservices aims to take one giant application and break it down into multiple services that are hosted independently of one another. Each service now acts like a miniature version of the monolithic application, making it easier to update individually and scale accordingly. The diagram below provides an oversimplified idea to drive the point home.
The services have a connection with each other which allows the user to perceive web banking still as a single application, rather than a sum of parts. On the back-end, code is now contained in silos respective to their microservice, removing the point of single failure, and allowing for individual service testing and updates. This takes advantage of a decentralization property, whereby databases feed into their respective service. It also allows for small services, like your login function, to be shared across multiple areas of the business.
For the developers, this also presents an opportunity to utilize programming languages specific to their service, such as Python and React JS. Deployment becomes more frequent, allowing certain businesses to operate with the SaaS model. Deployment is easy, containerized with tools such as Docker, Kubernetes, and Azure. This comes in particularly handy from a scalability point of view, where only one microservice may need to be scaled up because of an uptick in activity versus the entire application. From a business continuity perspective, this fits well into the Agile framework.
Some real life examples of microservices include features like a payment system or business login; these are re-usable pieces of code that can be utilized in more than one service, if need be. Take Netflix, for example, answering more than one billion API calls a day. Their business continuity is heavily dependent on microservices architecture, as a single point of failure in traditional architecture would be catastrophic.