Part One : An Introduction To Microservice ? #microservices

Let’s start our discussion with a hypothetical though experiment, Let’s say that I want to build a large application. Now this application has some requirements, there are certain thing the application is expected to do.

• It has to scale to millions of users.
• It has to support multiple platforms i.e. it should not only work on your mobile but also work on your web , embedded devices, desktops.
• Application must handle complicated business rules, which are set by the Business team.
• Competitive in fast moving market i.e.
• You should be able to respond quickly when your competitors make a move.
• You have to be very nimble, responsive. Better than being reactive. Setting yourself being proactive, rather than chasing other and trying to play catchup with your competition.
• You should be able to innovate really quick

Most of the products today in the market need to handle

• Millions of Active user’s monthly/daily.
• Active users can be using you application for few minutes for several times in a day or using it hours together in a day.
• Multiple countries and regions.
• Lot of product/services are added every day/month. Multiple contracts associated with each product probably for each region or country. Which is incredibly complex business rules. The product is expected to handle this.
• Lots of Competition. We have smaller competitors who are nimble, not knocked down by heavy processes. We are also talking about huge businesses competing in the same space. We are seeing few competitors getting knocked out of the space due to lack in agility and innovation.

How do you support these requirements and still keep up the competitive edge by moving fast and keep innovating?

How do we support this complex requirement for the application while still like growing the service in real user numbers pretty significantly month on month with growing number of users subscribing to the services really fast? So we have to support growth, we have to support these complex business rules and we want to keep innovating at the same time. If you see it, all these things are in conflict with each other, all these requirements. How do we do that?

Solution approach :

Let’s go through a typical architecture or this is how we will build kind of connected applications. This is probably how we will build them with a pretty standard way of building connected application.

• You have clients or probably a client team to build Client application for respective platforms.
• You have a core library team that abstracts all that complex business logic probably also handles all Server/Service communications.
• We have Service Layer teams and infrastructure/System of records teams.

This is how we can do it and look pretty obvious way to do that.

So what is the problem here ?

Problem here is, if you want to create a new feature in this kind of an architecture, if you want to build a new client feature. Client team has to ask the Core Library team, please give us an API that lets us do this. In turn the Core Library team asks for a service in the Service layer, so that they can create an API which can be rendered by the Core Library/API team. In order to achieve this on the service layer, Service layer might need to add few data sources or resources to access the Infrastructure/System or records. So bottom line, it is too much of asking form other team, which is already generating a dependency and coordination nightmare. It is lot of people trying to get stuff on to other teams backlogs.

Eventually Client teams get bored waiting for the Core Library team to give them an API to access the service, hence they might opt to call the service layer directly, which is just going to add friction among the teams.

Challenges in working this way ?

Synchronization is the main challenge.

Client UX implementation depends on à Core Library Implementation depends on à Service Layer Implementation depends on à Infrastructure Implementation.

What is the better solution ? 

We introduce a full stack team, Each team has

• Back End Developers
• Front End Developers
• Testers
• UI Designer
•  Product Owner

What this means is each Feature team is equipped to complete a complete end to end implementation of the feature from UI all the way to connecting with the Infrastructure/System of records. Typically all the developers are sitting on the same room, couple of desk away from each other and they are in constant communication and it all goes out together, it is a dialogue not synchronization.

Have we totally eradicated dependencies?

No there are still light dependencies in interfacing with the infrastructure team. What we have done here is minimized the dependencies to least possible.

How does the teams look now with this revamp?

Autonomous Full stack teams. This allows the team to work and act independently. One team should not have dependency on other team. That’s the most import part how we can get this thing done and keep moving forward and keep a competitive edge over other competitors. It is now required that you structure your application in a loosely coupled parts.

Conclusion : In Part II : we will continue our discussion with an Example and explore how we can break the monolith to different designs.

Author : Shankara