Microservice Architecture - A brief overview

During the early days of Software Development, barriers to entry in Programming languages were high and only people with PhD in Science and Mathematics could use those programming languages. In 1964, a general-purpose programming language BASIC was developed. It lowers the barrier so that non-PhD students from all departments can also write programs. As there was a rapid growth of computing applications in the 1960s, software became large and complex

in 1972 which introduced the concepts of Modularity and Information hiding. Also, introduced the concept Separation of Concern, with the principal of decomposing a large, complex software system into “Loosely coupled, highly cohesive” modules which communicated via internal interfaces. In simple terms, “loosely coupled” means the dependency between modules should be very low and “highly cohesive” means that one module should focus on single or similar functionality. With the rise of the Internet and Web in the 1990s, software systems became widespread in business applications and became even more complex and large. Although Modularity is used to reduce the complexities of software application, it often did not help as the soft Modular boundaries of software sub-systems are easy to cross and misuse. Another Software Architecture pattern became very popular during the 1990s to develop business applications: Layered Architecture. Normally, a business Web Application is divided into several layers: Presentation, Business, Database layers.

In 1997, Brian Foote and Joseph Yoder has analyzed many Business applications and published the “Big Ball of Mud” papers. 


It state that most of the Business applications suffer from the following problems:

  • Unregulated growth
  • Too many responsibilities
  • Lacks proper Architecture
  • million lines of Code

In the late 2000s, a Cambrian Explosion happens in the software industries due to the rise of Mobile Internet (Wifi, Smartphone) and faster network. Also, software started to eat the world where along with the traditional Software/Technology companies, almost all types of companies started to develop or use software like Banking, Insurance, Restaurants, Hotels, Music, Driving, etc. Many new companies like Facebook, Twitter, Uber, Netflix, Spotify came with innovative ideas, aggressive strategy, move fast approach which leads to the exponential growth of their applications. Suddenly, Organizations and Software Engineers found that Monolithic Architecture cannot handle the challenges of Modern, Fast-Paced or Web-Scale Software development

Limitations of Monolithic Architecture

  • Application Scaling: As the successful Web Scale companies enjoy exponential growth, their softwares also 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 (implemented with polyglot programming). 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. In 2008, I had an interview in a Telecom company in Berlin where the Technical Manager told me 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”. If we compare the Software development with society, then Monolithic Modularization is like moralistic, religious rules which as we know cannot ensure law and order in the society.
  • 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

Microservice Architecture

In the 2010s, other disruptive technologies arise which impact the Software Development landscape in a significant way: Cloud Computing, Containerization (Docker, Kubernetes), DevOps. Likewise some highly productive, lightweight new programming languages e.g. Golang, Rust, Swift come to the scenario whereas some highly productive, easy to use, lightweight programming language like JavaScript, Python become mainstream. There is a change in Software Development model also. Waterfall software development model is almost discarded and replaced by fast, iterative, incremental Software development methodology: Agile Software development. Computer Hardware also changed massively with cheaper, faster main memory and rise of Multi-Core CPU, GPU. There was a change in the Data Storage landscape as well. New Database technologies like NoSQL, NewSQL emerges and become mainstream

To handle the complexity of modern software applications, to take the advantages of Cloud Computing, Containerization, DevOps, modern Programming languages and to fulfill the need of modern software development (fast development, horizontal scaling), a new Software Architecture Style arose in 2012: Microservice Architecture. So, what is exactly a Microservice Architecture? There are many definitions of Microservice Architecture and here is my definition:

Microservice Architecture is about decomposing a Software System into autonomous Units which are independently deployable and which communicates via lightweight, language agnostic way and together they fulfill the business goal.

image above, Monolithic application is one single unit (tightly coupled) like a single Cube. Modular application is like Rubric Cube which can contain small modules but the modules cannot be separated and can only be deployed together. Microservices are like a lego cube made by lego blocks where the blocks are loosely coupled, easily separable and all the lego blocks together made the cube.

Advantages

  • Application Scaling: Firstly, Microservices are often Stateless and if they are carefully deployed using Docker, Kubernetes or using other Infrastructures, Microservices can offer horizontal Scaling within seconds. In fact, it is the high horizontal Scaling which leads companies like Netflix, Spotify, Uber, Google to move from Monolithic to Microservice Architecture. Secondly, if one microservice is e.g. CPU intensive, it could be implemented in a CPU optimized programming language (C/C++, Rust) where other microservices can be implemented in an interpreted language (Java, PHP).
  • Development Speed: Microservices are often quite small in size (several hundred to several thousand). Due to the size, adding new features in Microservices are usually faster.
  • Development Scaling: Microservices are autonomous and can be developed independently. As a result, Developer Scalability is much better as different developers/teams can work on different microservices autonomously without bumping into each other’s code. So, companies can easily hire more developers and can scale development. Similarly, due to their sizes, Microservices puts small Cognitive load on newly hired Developers or fresh graduates and new Developers can normally write productive codes in a matter of days instead of weeks or months.
  • Release Cycle: In my opinion, the coolest features of Microservice Architecture is that every Microservice is independently deployable. As a result, the Software Release Cycle in Microservice Applications is much smaller and with CI/CD, it is possible to give several releases per day.
  • Modularization: In Microservice Architecture, the boundary between the Microservices are external Interfaces aka Physical (Network) which is hard to cross. As a result, correctly designed Microservices often offers the “Loosely coupled, highly cohesive” Modularization. If we compare Software Development with society, then Microservice Modulation is like strict national, international laws with police/punishments. As we know already, usually strict national, international laws can ensure law and order in society.
  • Modernization: As Microservices are loosely coupled and only communicate via language-agnostic way with each other, a single Microservice can easily be replaced by a new one which can be developed using a new programming language and Tech Stack without affecting the whole system. Modernization in Microservice Architecture is incremental and not Big Bang


Comments

Popular posts from this blog

Email Sending through O365 using OAuth Protocol

IISRESET vs App Pool Recycling ?

Deploy .Net6.0 Web api with docker