Skip to content

Understanding the concepts

What we are trying to avoid

Limitations of monolithic architecture

Application Scaling
Softwares need to support high horizontal scalability. Sometimes, only a part of the software which is e.g. CPU intensive or I/O intensive needs to be scaled and handled separately. monolithic software works as a single unit and developed in a single programming language using a single tech stack. To achieve horizontal scaling, the whole application needs to be scaled. Correspondingly as the monolithic software only supports one programming language, it is not possible to implement one single module of it in other programming language or in other tech stack.

Development Velocity
To shorten time to market, every company nowadays wants to have fast feature development. In a large, complex and often multi-million line monolithic application, adding new feature is very slow because such a monolithic application gives huge cognitive load to the developer. Modules of giant monolithic applications are tightly coupled and provide an additional challenge to add new features. As a result, adding new features in a monolithic application is often slow and very expensive.

Development Scaling
Companies often want to parallelize the development by hiring more developers to have a competitive advantage or to catch the low hanging fruits. Developers cannot work autonomously on a giant, monolithic, tightly coupled code base and often needs extra synchronization, guard not to bump into each other’s work. Adding more developers does not produce more feature and sometimes delivers even fewer features. Similarly due to the high cognitive load to understand the whole monolithic code base, new hires or fresh graduates often take a long time to write first lines of productive code.

Interview

In 2008, there was an interview in a Telecom company in Berlin where the Technical Manager told with a proud smile that they have multi-million lines of C++ code base and new developers can only write productive codes after 3–6 months.

Release Cycle
Release cycle of large monolithic applications is often too large and usually 6 months to 2/3 years plus another few months to several years delay due to its size. In modern days, large release cycle often put the company under competitive disadvantages as within this large release gap, a new company can come and take away its market.

Modularization
In monolithic architecture, the boundary between Modules are often internal Interfaces. As soon as the application grows in size, the boundary between modules starts to fall apart. As a result, often the Modules in monolithic architecture are tightly coupled instead of the double dictum “loosely coupled, highly cohesive”.

Modernization
Existing successful applications needed to be modernized due to many factors (e.g. taking advantage of modern Hardware, Browser, Network Bandwidth, Tech Stack or Attract good developers). Modernization of monolithic application is often expensive and time-consuming as it needs a Big Bang modernization of the whole application without disrupting the service.

Operational Complexity

Once the complex monolithic application is decomposed into many Microservices, the complexity often moves from source code to operations.

Simple operations like logging, monitoring became more complex because instead of one systems, many more systems need to be handled. Often, the existing logging or monitoring tool does not fit with microservices and new logging, monitoring tools are needed.

Tracing is also very important in microservices to measure the performance/latency of individual microservices for a service request.

The complete system test is likewise quite complex in microservices compared to monolithic applications. Likewise, new infrastructures are needed for service discovery, resiliency. The initial development velocity of microservice architecture is lower compared to monolithic architecture due to the operational complexities.

Quote

For large Enterprises which normally develop complex softwares, microservice architecture is the only way to tackle complexity and to be competitive in the market.

For small to medium enterprises also, Microservice architecture should be used for sustainable software development which can give long term benefits. It is worth noting that the early adopters of Microservice architecture (Spotify, Netflix, Linkedin, Amazon, Google) achieved significant competitive advantages over rivals thanks to their Microservice architecture. Microservices needs a new set of best practices, patterns and tips to be successful. What are those best practices, patterns and tips which Architects/Developers need to consider to develop successful Microservices?

There is more behind the scenes

The back-end is all of the technology required to process the incoming request and generate and send the response to the client. This typically includes three major parts:

  • The server
    • This is the computer that receives requests.
  • The app
    • This is the application running on the server that listens for requests, retrieves information from the database, and sends a response.
  • The database
    • Databases are used to organize and persist data.

However a typical service needs a lot more to function. Logging, monitoring, scaling, caching, load balancing etc. There is so much more than just the HTTP API.