At the 2015 AWS re:Invent conference, Rob Brigham made a compelling presentation explaining how in 2000 the engineering group at Amazon, had the undesirable duty of reconciling changes from hundreds of developing teams. Amazon was a monolith, then “It was architected in multiple tiers, and those tiers had many components in them, but they were all very tightly coupled together, where they behaved like one big monolith.” “A lot of startups and projects inside of big companies, start this way, to get moving quickly. But over time, as you add more developers on it, as it grows and the code base gets larger and the architecture gets more complex, that monolith is going to add overhead into your process, and that software development lifecycle begins to slow down.”

Engineers were busy resolving conflicts, merging them, and producing a master version in line to be moved into production. “Even when you have that big, large, new version, it still adds a lot of overhead on this delivery pipeline. That whole, new code base needs to be rebuilt. All of the test cases need to be re-run, to make sure there have been no rushes. And then you need to take that entire application, and deploy it all to your full production fleet.”

full presentation here:

Let’s get in more detail to understand the pros and cons of using a monolithic architecture. This is the traditional style of creating a web service were all different activities like querying the database, munching the business logic and sending the details to front end are carried out by a single code base. The code is easy to maintain and deploy, but as applications grow larger, implementation teams get bigger and divided on the basis of their technical qualification rather based on business tasks.

Any change in any element of the architecture, such as for example the database, would require the DB team to coordinate with most other teams and get them involved. Similarly, making any change to the front end will require the UX team to be engaged in implementing the change requirements along with the DB team and backend teams. Hence it creates more and more dependency b/w teams to achieve a certain business requirement. Such an infrastructure needing a deep integration between teams works well till the time the service is small and manageable. As the teams start growing and applications becomes more complex, there are hurdles which come up at each stage of development. Typically:

  1. Long term commitment to technology: Applications are bounded by the language used for the initial development and any new modificatio will invariably need developers to follow the same technology stack. Hence it becomes difficult to take advantage of new developments.
  2. Continuous development becomes oppressive: deployment of new applications becomes cumbersome with size as even small changes will need the entire unit to be deployed again.
  3. Aggregation of Baseloads increases costs: If one service is memory intensive and another CPU intensive, the server must be provisioned with enough memory and CPU to handle baseline load for each service. Thus increasing the deployment cost.
  4. Slow integration of new team members: As applications grow with time, it becomes more and more difficult to manage hand-overs. People who built it from the ground up from the beginning frequently become indispensable.
  5. Every Instance is a replication of entire application: Providing services to multiple clients will require service instances to be created for the entire application though probably it’s just one part of the service which attracts maximum traffic.

Now we are geared – up to understand how microservice architecture is different from a traditional monolithic architecture and its benefits and any associated disadvantages.

Microservice Architecture:

Microservice architecture divide the application requirement into multiple services were each service can be loosely coupled with one another using communication channels like Rest API  . Services are broken down based on the business requirements rather than on technical basis.

Microservice architecture is about dividing the application requirement into multiple services were each service can be loosely coupled with one another using communication channels like REST API. Services are broken down based on the business requirements rather than on technical basis.

The picture above displays a simple implementation using a microservice architecture where se                rvice 1, 2 & 3 are different services based on business requirements. The Auth Service implements an authorization service (eventually using a JSON token ) to authenticate each request to the application and Search Service instead implements searches which might require interaction with different services.

As displayed, each service can have a single database (but with different tables for each individual service). Search on the other hand can use the same set of tables (in simple applications) or a replica of the tables (which will be updated every time a change is made to any component) and gaining independence and efficiency, to retrieve data faster.

Each service is decoupled from each other and can be developed or modified in isolation. Services have their own database, APIs and logic layer to interact with the user.

Major advantages of adopting a microservice architecture are as follows:

  1. Reduced Complexity of the parts: Each service is relatively small and hence easier to understand and maintain.
  2. Quick implementation of changes: As the services are decoupled from each other, it is possible to intervene just on the intended service instead of affecting the entire code base.
  3. Continuous Development: Deployment requires only the concerned service to be updated and redeployed. The time required for deployment is greatly reduced
  4. Scalability: each team is largely independent of each other and can schedule its development virtually in isolation, thereby increasing efficiency and scaling faster
  5. Possibility to use different stacks: Each service can be developed using the technology which is best suited for that particular task. Therefore the microservice architecture relieves the application of following a generic technology stack.

On the other hand:

  1. At a small scale, it might be unnecessary to deal with the complexity of creating a segregated system and establishing communication routines between each component;
  2. Though deployment becomes more efficient but it comes at the cost of increased complexity of deploying services
  3. Testing of application becomes more difficult

We have developed applications using both monolithic and microservice architecture and complexity of applications, efficiency of code & availability across platforms are few parameters that we consider when we decide which approach to take, together with team size, stage of the project, scope of the startup, target clients, etc. If you would like to have an opinion on which architecture is the best choice for you or for guidance on the implementation requirements send us an email at uk [at]

Further Reading:


Regtech - One of the 3 pillars to cope with increasing regulatory pressure · February 26, 2018 at 10:53 pm

[…] the early 2000s the engineering team at Amazon found out that their monolithic infrastructure, organized by competencies, was progressively becoming slower […]

Five areas of RegTech that any financial services firm should be aware of. · February 27, 2018 at 6:59 am

[…] There are companies in almost all of the aspects of this sector, and players are trying to concentrate on precise value propositions. This helps them to remain focused and produce high standard solutions although it does raise some difficulties at financial institutions that have to deal with many nimble providers and accommodate different tech stacks in their legacy infrastructures. On the other hand, this is the direction where the industry is moving and use of microservices infrastructures and continuous development frameworks can help cope with that, as we highlighted in one of our previous posts. […]

Learning the Amazon way - Principio · April 10, 2018 at 6:58 am

[…] expanded, there was a definite need to move into a microservice architecture (Get more insights here). With time they faced additional problems in terms of adjusting the infrastructure for their […]

Comments are closed.

Related Posts


Why Are Central Banks Flirting With Digital Currencies?

We have been asked this question a few times. Bitcoin, the archetype of all the cryptocurrencies was conceived to remove the need for a trusted third party. Central Banks are trusted third parties themselves. They Read more…

Startup lessons

Learning the Amazon way

Internet brought several new business ideas with it and online commerce was one of it. Undoubtedly, Amazon has been the king of this field. With years of operations it has not just capitalized on its Read more…


A short intro to Blockchain

Maybe this is not the shortest ever, but surely the best we could put together to provide enough details to get a complete understanding of it. Let’s start by breaking a myth: bitcoin is not Read more…