Simple Introduction to Microservices Architecture for Beginners

microservices architecture, microservices achitecture for beginners, understanding microservices

Microservices Architecture for Beginners

microservices architecture, microservices achitecture for beginners, understanding microservices

If you are aimlessly wandering here and there to get good knowledge about understanding microservices architecture for beginners than this article will be helpful to you. As a beginner, I am trying to simplify microservices architecture for beginners. If you are someone just like me, who is reading about all these new technologies and have no idea what is going on then you should read this article. It is important to note that I am also very new to these technologies. I do not have enough experience to talk really deep about this subject. I will give the basic information

After reading many resources I have tried to explain microservices architecture for beginners in an easy way. So let us start, shall we?

In The Beginning

microservices architecture, microservices achitecture for beginners, understanding microservices

Let’s start from the beginning to make it easier in understanding microservices architecture. When software production was booming, people started to realize the power and efficiency that came with working on computers. Software engineers were developing massive applications for businesses, government institutions and so much more. These applications were huge in size and were not easy to maintain.

The experts in the field came up with the idea of Divide and Conquer. In order to maintain the readability of the code, developers started to modularize their files and applications. This means that the functionality of the software was distributed in different files and modules. Programmers kept their modules Loosely Coupled and Highly Cohesive. Every module in the program had very little interference with other modules and each of them had unique functionality.

But chaos is unavoidable, as the applications started to grow the boundary between the modules started depleting. This means that a little change to one of the codes in a module would start a chain of change on code in other files and modules. This type of software development architecture was known as Monolithic Architecture. This architecture has been around for quite a while and effective for producing trustable software but with the modernization and development of high-end technology, monolithic architecture is not effective.

Cons in Monolithic Architecture

All of the software is written in a single language and composed of millions of lines of code. With good high-level languages in the market that get the job very well done, the adaption of these languages into the developed software is quite difficult and time-consuming.

New developers consume too much time to fully understand the whole application which decreases productivity. Each new update requires the developers to test every functionality and modules for bugs. As the application becomes tightly coupled instead of loosely coupled there is a high chance that a little addition to one function can cause errors in the other ten function.

  • Hard to Scale
  • Written in a single language hence creating trade-offs
  • Very large codebase, hard for new people
  • Testing has to be done on the whole application
  • A tight coupling as the software starts to scale
  • Hard to make changes fast and correctly


Not a Solution but An Effective Strategy

microservices architecture, microservices achitecture for beginners, understanding microservices

Understanding Microservices Architecture

With modernization taking over the world drastically, the software world was affected too. Experts felt that the monolithic architecture is a hurdle in between the achievement of modern technology. It lacked adaptability, was very memory intensive, difficult to maintain. With all of these problems in mind, Microservices Architecture was developed. The simple definition for understanding microservices architecture would be: “The compartmentalization of functionality so that no functionality affects the other in any way”. Well, this means that one module of software and can run on a different node and the other module can run on another. They all are connected to each other with a physical connection.

This opens up a whole lot of opportunities. The software can run on different languages i.e the memory-intensive part of the software can be developed in C/C++ and the machine learning part can be developed using Python. This still sounds very similar to monolithic architecture, isn’t it? The biggest difference is that all of the stuff that does memory-related work can be physically deployed on a single computer while the other work can be on different computers.

Unlike monolithic architecture, a change in one module of the software will not affect other modules. All of these modules are separated and implemented on different machines. If one part of the application starts to grow in size, then only the machine or server containing this module will be upgraded.

These modules are totally independent of each other and so they are very easy to maintain and upgrade. It said that a new feature can be added and deployed within seconds. If there is an update in the code then you do not have to test the whole application. As the code related to specific functionality is on a single computer than only that code has to be tested. Do you see how easy it is to run many tests without any useless delay?

In this fast-paced business world, this method is proving to be very effective. Traditional software took 2 to 3 years to update and then the time period of the next upgrade would increase too. Microservices can provide upgrades within days proving that they are very flexible and adaptable. The microservices architecture is independent, this makes it easier when an issue arises. As there is a dedicated computer running for that functionality, the problem becomes easier to identify

When Not to Use Microservices Architecture

It is important to remember that the need for creating microservices architecture grew because the monolithic software was getting harder to expand. If you are someone who is making a little project, or just starting a business, or as a developer then there is no need to create microservices architecture. Microservices are really expensive and can only be afforded by giant companies that have very high customer demands.

As someone who is still understanding microservices architecture, you should definitely avoid microservices for now. First, get a good hang of the monolithic architecture first, get your hands dirty in big scaling project, and then you can think about microservices


Although microservices architecture is very flexible and agile, it no way means that it is the silver bullet. First of all, a broken connection between two services can be very drastic, as these services are connected via the physical layer the network latency is very high and the environment and weather conditions too can affect the whole system. They are very costly to be implemented, as one service requires one computer to work on. Database and storage management issues are also a problem that needs to be considered.

In the end, I would say that both of the above-discussed architectures are good in their own way. If you are developing small scale software then you should consider using monolith architecture as it has been battle-tested and very thoroughly studied and if you are a multinational company having trouble in maintaining their software then microservices architecture might just be the solution for you.

This article was written to help in understanding microservices architecture for beginners. If you liked this article you can also check out these too.