WHAT IS MICROSERVICES AND MONOLITHIC APPLICATIONS (simply explained)?!

Join our BRAND NEW Linkedin Group Click Here: Global Technology Network

Microservices and Monolithic are application and software development architectural styles. The way an application is built in other words.

Most Applications in general are Monolithic (this means data input and output, data processing, error handling, and the user interface code are all interwoven).

Microservices is a application architectural style that breaks down large complex systems into multiple smaller, more manageable systems. This creates a more robust and better quality application.

COMPANIES THAT USE MICROSERVICES

1. Uber
2. Netflix
3. Amazon
4. Ebay
5. Soundcloud
6. Groupon

WHEN TO USE MICROSERVICES: (Microsoft.com)

• Large applications that require a high release velocity.
• Complex applications that need to be highly scalable.
• Applications with rich domains or many subdomains.
• An organization that consists of small development teams.

Think of it like this way. When you buy a camera as a professional photographer you have an option of buying a consumer camera or pro camera.

This consumer camera aka monolithic built application ($150) is something you will see in a major department store. All in one package for quick use. These cameras are mostly used for family or event pictures/videos.

This Pro camera aka microservices built application ($2500) is usually sold as a body and you have to buy lens separately. This allows more flexibility and quality of videos/pictures.

So now instead of just taking family videos, you can now do documentaries, films, music videos, and etc.

This is why a large scale application should be built with Microservices in mind.

Microservice

Monolithic

Monolithic vs. Microservice

MICROSERVICES BENEFITS (Microsoft.com)

• Independent deployments. You can update a service without redeploying the entire application, and roll back or roll forward an update if something goes wrong. Bug fixes and feature releases are more manageable and less risky.
• Independent development. A single development team can build, test, and deploy a service. The result is continuous innovation and a faster release cadence.
• Small, focused teams. Teams can focus on one service. .
• Fault isolation. If a service goes down, it won't take out the entire application.
• Mixed technologies. Teams can pick the technology that best fits their service.
• Scaling. Services can be scaled independently.

MICROSERVICES CHALLENGES (Microsoft.com)

• A microservices application has more moving parts.
• Microservices can become hard to maintain with so many different languages and frameworks.
• The use of many small, granular services can result in network congestion and latency issues.
• You will need to design APIs carefully. Avoid overly chatty APIs, think about serialization formats, and look for places to use asynchronous communication patterns.
• Microservices requires a mature DevOps culture. Correlated logging across services can be challenging. Typically, logging must correlate multiple service calls for a single user operation.

BEST PRACTICES (Microsoft.com)

• Model services around the business domain.
• Decentralize everything. Individual teams are responsible for designing and building services. Avoid sharing code or data schemas.
• Data storage should be private to the service that owns the data. Use the best storage for each service and data type.
• Services communicate through well-designed APIs. Avoid leaking implementation details. APIs should model the domain, not the internal implementation of the service.
• Avoid coupling between services. Causes of coupling include shared database schemas and rigid communication protocols.
• Offload cross-cutting concerns, such as authentication and SSL termination, to the gateway.
• Keep domain knowledge out of the gateway. The gateway should handle and route client requests without any knowledge of the business rules or domain logic. Otherwise, the gateway becomes a dependency and can cause coupling between services.
• Services should have loose coupling and high functional cohesion. Functions that are likely to change together should be packaged and deployed together. If they reside in separate services, those services end up being tightly coupled, because a change in one service will require updating the other service. Overly chatty communication between two services may be a symptom of tight coupling and low cohesion.
• Isolate failures. Use resiliency strategies to prevent failures within a service from cascading. See Resiliency patterns and Designing resilient applications.

Join our BRAND NEW Linkedin Group Click Here: Global Technology Network

That does it!!!