We are all accustomed to building an application where a single code base consists of all the functional components of an application, closely tied together to achieve a certain desired result. These applications follow a rigorous development approach where the functioning and architecture of the application is first thought of during the initial requirement-gathering and design phases, and then the rigorous development of the application starts.

It is only after all the components have been developed and thoroughly tested that an application enters the production stage, where it is deployed on the infrastructure for regular use. This model is shown in the following diagram:

This process is slow, and every step depends upon the successful completion of the previous step. The addition of any new feature to the application once it has been deployed poses a challenge because now the whole development cycle has to be followed again; once the development of the new feature has been completed, the whole application in its entirety needs to be redeployed. This gives rise to a certain number of challenges, as shown in the following list:

• Slow development: Since the whole application is a one large code base, a change to one component may affect the functioning of the other components. A huge amount of care needs to be taken so that the existing functionality does not break and new bugs are not introduced.
• Highly serialized development approach: When an application is developed as a single monolith, the development approach is highly serialized, where the execution of a step heavily depends on the success of the preceding step. This causes an increased serialization of steps.
• Higher risks: When a large code base is modified to add a new feature or to set up a major refactoring, it risks breaking up the previous functionality or introducing new bugs inside the code. This increases the risk of development, and means that there needs to be rigorous testing of the application in its entirety so as to make sure that the functionality still works in the way it was supposed to.
• Higher downtimes during deployments: When an upgraded version of the application needs to be deployed, it means that the whole application has to be taken down. The side effect of this is that the user experiences an increased amount of downtime.
• Difficult to scale the application up: Usually, when an application grows in popularity, the application needs to be scaled up. However, since a monolithic application is a single application, when the load increases, the options to scale up are fairly limited. Generally speaking, these options relate to increasing the resources that are dedicated to running the application or launching more instances of the complete application running behind a load balancer.

These problems needed to be solved, and the solution came in the form of a new development approach that welcomes faster development-to-production release cycles. This solution was to develop the application in such a way that the individual components can be broken down into logical services, where each service does one thing and does it perfectly.

This development model of building an application by modelling its individual components as separate services came to be known as the microservices development model. Let's take a look at some of the features of the microservices development approach, as shown in the following list:

• Modelling as a service: With the microservices approach, the individual functionality of an application is broken down into a set of logical services that are then developed independently of each other. For example, the functionality of allowing a user to authenticate their identity for an application can be segregated into an authentication service.
• Built for the business: The microservices architecture enables modelling as a business requirement. This allows each team to work on a complete component on their own. These teams are not only responsible for the development of the component, but are also responsible for the functioning of that component throughout their lifetime into the production environment.
• Decentralized throughout: The microservices approach provides a highly decentralized way of deployment and management of these services. In the microservices architecture, every service is responsible for the management of its own data. This is in contrast to the monolithic architecture, where a single database is used to store the information that is managed by the different components of the application.
• Simple request handling: Microservices implement a simple RESTful API through which they can take in a request from another entity, process the request, and then provide a suitable response based on the results of the processing of the request. These services do not utilize the highly sophisticated ways of applying business logic to orchestrate the flow of data from one endpoint to another endpoint, and so provide a simple mechanism of routing the requests.
• Polyglot: Microservices do not follow the principle of one size fits all. The team responsible for the development of a microservice is usually free to choose the tools and technologies that will power a particular microservice. This may include the choice of language, the operating system, and the hardware on which the service will be made to run.

These are some features that make using microservices a great option. With microservices in the picture, we can now work to solve some of the problems that we face with monolithic applications while also gaining quite a lot of different advantages. So, let's take a look at the advantages that the microservices architecture has to offer.