In this article, we will try to understand the Monolithic and Microservices architecture in terms project team, analysis/design, development/construction, continuous integration /deployment and testing.

Before jumping into Microservices, let's see what is Monolithic architecture. Let's say you are building an application that has following basic services for a shopping website having services like Customer Service, Product Service, Inventory Service, Payment Service, Shipping Service

Figure 1

Advantage

The above monolithic architecture has following benefits:

• Developing using specific technologies quiet simple, it is not much complex to develop.
• Deployment is simple
• Consistency can be maintained
• Refactoring is easy

Drawbacks

But as the application becomes large and complex, then things becomes challenging as below

• Application maintenance becomes challenging over the time period in terms code change impact and fixing bugs
• Developer productivity - With large code base, productivity of developers becomes slow
• Continuous integration and deployment -Risk associated with redeployment increases
• Scaling- one can scale with an increasing transaction volume by running multiple copies of the application but this architecture can’t scale with an increasing data volume.
• CPU/memory Consumption- Each application components will have different resource requirement in terms I/O traffic, CPU and memory. Scaling each component independently is not possible
• Monolithic architecture forces one to stick with a particular technology stack. Its not easy to replace component based on some new technology stack

In a nutshell, a monolithic application puts all or most of its functionality in to single process and scales by replication on multiple servers and its hard to keep modular structure. Codebases grow as we write code to add new features. Over time, it can be difficult to know where a change needs to be made because the codebase is so large. The golden rule, can we make a change to a service and deploy it by itself without changing anything else? If the answer is no, then its time to revisit the architecture.

In microservices architecture, each element of functionality is put into seperate service. Then these services are scaled across different servers and replication depending on I/O traffic, CPU and memory requirements. Lets try to understand some of the characteristics of microservice architecture

Here definition of component is "a unit of software that is independently replaceable and upgradeable".

One point to be noted here is when we say :

• Libraries as components then they are called using in-memory function calls

• Services as components then they are out of process components which communicates using web service or remote procedure calls.

Advantage:

Using services as components ,rather than libraries, is that services are independently deploy able. Lets say an application with multiple libraries in a single process, change in in any single library results in to deployment of entire application. But if that application is decomposed into multiple services, you can expect many single service changes to only require that service to be redeployed.

Drawback:

Remote calls are more expensive than in-process calls, and thus remote APIs need to be coarser-grained, which is often more challenging to use. If you need to change the allocation of responsibilities between components, such movements of behaviour are harder to do when you're crossing process boundaries.

Normally in project, team is divided into UI ,Client side ,Server side and database team. The challenge here is that even for simple change impact is on multiple teams which leads approvals etc. The microservice approach is to split the teams based on business capabilities may be like Customer, Payment, Shipping etc.This leads to the teams are cross-functional, including the full range of skills required for the development.

In most application development, we use project model where some functionality of software is delivered and when it is deployed in production after that it is handed over to production support team. Microservice do not recommend this model, instead a team should own a functionality/product over its full life time.This brings development team to work closely with users of the application.This will make development team to understand and assist its end users to enhance the business capability.

Monolithic applications prefer a single logical database for persistent data across a range of applications. Microservices prefer letting each service manage its own database, either different instances of the same database technology, or entirely different database systems.

Challenge

Decentralizing responsibility for data across microservices has implications for managing transactions to guarantee consistency when updating multiple resources.

Microservices add a lot of complexity as we have to deal with lot of moving parts. Automated testing, continuous integration and deployment of individual services ensures our services still works as more complex process than with monolithic systems.

Impact using services as components, is that applications need to be designed so that they can tolerate the failure of services. We need to check for circuit breakers as mentioned below :

• Make sure your timeouts are set appropriately.
• When using network calls  you are prepared for different sorts of failure mode and expect failure will occur anywhere and everywhere
• Understand what the customer-facing impact will be if only one part of the system is misbehaving.
• implications of a network partition might be, and whether sacrificing availability or consistency in a given situation is the right call.

Since services can fail at any time, it's important to be able to detect the failures quickly and, if possible, automatically restore service. Microservice applications put a lot of emphasis on real-time monitoring of the application.

To maximize the ability of one service to evolve independently of any others, it is vital that we hide implementation details.Consider using REST, which formalizes the separation of internal and external implementation details

Good Understanding of Domain:

Less well one understand a domain, the harder it will be for to find proper bounded contexts for the services.Getting service boundaries wrong can result in having to make lots of changes in service-to-service collaboration which makes an expensive operation

Rapid provisioning:

One should be able to fire up a new server in short time.To be able to do such rapid provisioning, one need a lot of automation.

Basic Monitoring:

Sticking with old monitoring practices where you just look at stats like CPU and memory may not be sufficient as more service-to-service collaboration with many loosely-coupled services collaborating in production,Things are bound to go wrong in ways that are difficult to detect in test environments.

Rapid application deployment:

with many services to manage, you need to be able to quickly deploy them, both to test environments and to production.

Good Service design i.e. loose coupling and high cohesion:

When services are loosely coupled, a change to one service should not require a change to another. The whole point of a microservice is being able to make a change to one service and deploy it, without needing to change any other part of the system.On other side , We want related behavior to grouped together so that communication with other boundaries are as loosely as possible and unrelated behavior to be grouped elsewhere.