Micro Services and its Constraints

Before we going to understand the microservices, we need to understand the monolith architecture

Monolith architecture

1. Monolith Components are tightly coupled
2. In Monolith, Components are developed, deployed and managed as one entity
3. In Monolith, Components are run as a single OS process.
4. If we made changes in a single component, it requires the deployment of the whole application
5. If any component requires more Memory, CPU based on the requirement, we need to do vertical scaling for all the replicas
6. we need to do Horizontal Scaling to Scale (To maintain the Multiple Copies)
7. Any component of the Monolith application is not scalable, the whole application is not scalable.

Micro Services architecture

1. Micro Service is an independent process and communicates with other micro-services through well-defined interfaces called Application Programming Interfaces (API)
2. Micro Services communicates through synchronous protocols Such as HTTP. They usually expose REST (Representational State Transfer) or through Asynchronous protocols Such as AMQP(Advanced Message Queuing Protocol)
3. These protocols are very simple and are independent of programming languages. So Micro-services are having the flexibility to write in different programming languages based on their functionality and they communicate with each other.
4. Each Micro-service is a standalone process with a relatively static external API
5. It’s possible to develop and deploy each micro-service Separately and changes to one of its services do not require redeployment of any other services
6. The advantage of microservices is we can scale the components individually. Components that require horizontal scaling can scale horizontally and At the same time, we can scale the components which require only vertical scaling. Monolith does not have the flexibility to scale components individually based on the requirement.
7. Microservices are Elastic, Resilient, Composable, Minimal, and Complete
   Elastic: A microservice must be able to scale, up or down, independently of other services in the same application.
   Resilient: A microservice must fail without impacting other services in the same application.
   Composable: A microservice must offer an interface that is uniform and is designed to support service composition.
   Minimal: A microservice must only contain highly cohesive(where things belong together) entities
   Complete: A microservice must be functionally complete

constraints of Microservices

Deployment of Microservices:

1. one of the constraints in microservice is deployment. when the number of components increases deployment-related decisions are increasingly difficult. Not only do the deployment combinations increase but also the number of interdependencies between the components increases by a greater factor.
2. Microservices will communicate together as a team, So they need to find and talk to each other. when deploying them someone needs to configure all of them properly to enable them to work as a single system. with increasing microservices this becomes difficult, especially what the Ops team need to do when a server fails.
3. Microservices are hard to debug and trace the execution calls because they span multiple processes and machines.

Understand the divergence of environmental requirements

1. microservices are the independent processes that are developed, deployed and updated individually by the individual teams. So there is a chance of maintaining the same library with different versions in different microservices based on their usage and requirement.it will become a nightmare for the ops team who deploys and manages them on production servers.
2. The bigger the number of components you need to deploy on the same host, the harder it will be to manage all their dependencies to satisfy all the requirements

Need to provide a consistent environment to applications

1. one of the biggest problems for the developers and ops team is the difference in environments. Not only the difference between the developer environment and the production environment but also there is a difference even exists between the individual production machines.
2. Another unavoidable fact is that the environment of a single production machine will change over time. Production systems can run applications from multiple development teams, So they must provide the proper environment to all applications it hosts, even though they may require different conflicting versions of libraries.
3. To reduce the number of problems it would be ideal if applications could run the exact same environment during development and in production. So that they have the exact same operating system, libraries, System configuration, network environment and everything else.
4. if possible we want the ability to add applications to the same server without affecting any existing applications to that server.

Need continuous delivery(Need to Adopt Devops And NoOps strategy)

1. In the last few years, we have also seen a shift in the whole application development process and how applications take care in production. In the past, the development team job was to create the application and hand it off to the operations team who then deployed and keep it running.
2. But now organizations realize that it is better to have the same team that develops the application and also take part in deploying it and needs to take care of it whole lifetime.
3. So that Developer, QA and Operations need to collaborate, this practice is called DevOps.
4. Benefit: Developers have a better understanding of the user needs and they understand the issues and also the problems faced by the Operations team while maintaining the app. It helps in the further development of the app.
5. To release new versions of applications more often, you need to streamline the deployment process. Ideally, we want developers to deploy the application themselves without the requirement of the ops people.
6. But for deploying the application. it requires an understanding of the underline infrastructure and the organization hardware data centre.
7. Even though developers, OpsTeam, System administrators working towards achieving the same goal i.e running the software application successfully, Their individual goals are different.
8. Developers: They love creating new features and improving the user experience.
   System Administrators: They make sure the underlying Operating System is up to date with all security patches and like that
   Ops Team: They take care of production deployments and hardware infrastructure they run on. They care about System Security and utilization and other aspects.
9. Developers don’t care about these activities and similarly, the Ops team don't care about the implicit interdependencies of all the application components and They don’t care about How the Operating system and infrastructure affect the application's behaviour.
10. Ideally, we want developers to deploy the application without having knowledge of the hardware and infrastructure without any help from the ops team. This practice is called NoOps. But Someone needs to take care of it.

To Handle all these mentioned constraints we are making deployment of microservices with Kubernetes. it achieves all of this abstracting actual hardware and infrastructure and exposing a single platform for deploying and running the applications. it helps Developers to deploy and configure the applications without any help of the Ops team and system administrators

it helps the system administrators to focus on keeping the underlying infrastructure up and running. while not having to know about what actual application is running