An overview about Microservices
Tags: architecture, microservices, soa
Published: 2020-08-27 10:07:07

The microservice's core is performance, is all about performance.

A strategy that born from the experience market, the need of scale, to serve more and more requests.

A point that have to be clear is when we increasing the positive points, what we doing is increasing the negative ones as well. So the success of a microservices' architecture is a well defined strategy to deal with the all complexity that born with that type of approach.

The microservice's strategy is not only about manage the software's life cycle but how to organize your business in order to reflect it in your teams as well.

###__Microservices are small__###

[Two weeks is a good start point when we think about re-built an entire microservice.](https://www.rea-group.com/blog/micro-services-what-even-are-they/)

This is where things start to get interesting...

Let's think about the meaning 'small enough',

Software is about automate routines.

A way that we do the things cheaper, structured, organized, patterned, etc.

Software is located in the middle, not the end of your business.

If we don't have a context to use it, the software there isn't a meaning.

So, we can say here that 'small enough' depending  on your business, your context.

How small can be the smallest routine of your business? 

The response is a routine(service) that do only one thing but do it very well and can be re-built  within around two weeks.

###__Autonomous__###

Microservice is totally separate entity, there is no dependency to deploy it and is a good practice think about deploy every microservice into a new machine(container?).

All that isolation results on more complexity, but nowadays there are many technologies that help us to mitigate it.

All communication is made via network calls to enforce low coupling.

When we are talking about autonomy it means that the service need to be change without concern if the client or another service will be affected. We need to think about what our service will expose and what will be hidden. Because these thing decrease the microservice autonomy.

What we are seeking when creating a new microservice is...

*Can you make a change to a service and deploy it by itself without changing anything else?*

###__Technology Heterogeneity__###

With microservices result in a bunch independent services from which we can take advantages, like using different technologies' stacks that lead us to solve different problems.

If there is a part of our systems that is facing performance problems, for instance, we can select a better one technology's stack to solve this problem. That way we are totally concern about to solve the problem and not about to solve the problem limited to follow a pre-established development standard.

And, of course, everything is a trade-off. All that flexibility comes with overhead.

Different stacks don't reuse the same library, for instance. Once we have different platforms.

Some companies(Netflix and Twitter for example), mostly use Java Virtual Machine as a platform, as they have a very good understanding of the reliability and performance of that system.

Again, If we can rewrite a microservice in two weeks, we may well mitigate the risks of embracing new technology.

###__Resilience__###

####__Monolithic world__####

In a _monolithic architecture_, only one service/system is responsible by many tasks), if it fails, everything the system is responsible stops working(API, UI, Batch routines, etc).

The way to mitigate a general fail is running multiples instances of that system.

####__Microservice world__####

Provides us the ability to deal with a fail, isolate it and allow the rest of system keep working. Every microservice is responsible for only one task.


###__Scaling__###

####__Monolithic world__####

No matter if only one part of the system that is more requested, the entire system has to be scaled(two or more instances). It means much more computational resources to increase system's availability.
![Monolithic scaling](https://dev-to-uploads.s3.amazonaws.com/i/8xc6mcjnkg7p1q6t2e0e.png)

####__Microservice world__####

When a service have to be scaled, the other parts of a system know nothing about that. Only one functionality will have your performance increased and the rest of the system continuous working normally.

![Microservice scaling](https://dev-to-uploads.s3.amazonaws.com/i/x67wbvqtn0dmrs521tb8.png)

###__Deployment__###

If an application is composed of many parts, when we have to deploy, it means that we will deploy just a piece, a limited part of the system. We don't have to deal with the risk of deploy the entire system. In case of problem with that small part, only that part will be unavailable instead of entire system. Once the risk is lower, the incidence of deploys increases.

###__Composability__###

SOA(Service Oriented Architecture) bring us the reuse of functionalities. Next to that, Microservices allow us consuming the functionalities in different ways for different purposes.

As the companies evolves, the architecture has to be flexible in the way to support the business needs, to do that we need to build things in different ways.

###__Optimizing for Replaceability__###

Change the entire microservice is a task that is not involve a big headache at all, because microservices are small by your nature.

Who never worked by a company with a big old system, a legacy one, that is the company's heart, that no one wants touch it?

And if no one wants to touch that system why hasn't that system been changed? We know why, because it is vital to the company and there is a high risk involved.

###__SOA - Service Oriented Architecture__###

Are routines(services) that communicate each other through network calls rather than method calls within only one process.

SOA emerged as an alternative to monolithic systems.

SOA promote the reuse of services. Where the service has a well designed interface based on a concise semantic.

No matter where you are in the company, a service can be used by different areas or even, once outside the company, can be selling as company's resource in order to open new business.

In my opinion, what are doing in practice are simple webservices. Taking the data from one node to another over network. What I means is a Service(note the upper case 'S') is an entity, there is more than transport data one point to another. When we reach the usability characteristic of the Service, it transcending over the company. The Service transform the company's business.

###__Summary__###

In that article, I'm introducing the microservice approach and bringing more information to help when decided to implement it.

All I'm talking here is based from book,
__Building Microservices: Designing Fine-Grained Systems by Sam Newman__

Cover Picture credits: <span>Photo by <a href="https://unsplash.com/@clintadair?utm_source=unsplash&amp;utm_medium=referral&amp;utm_content=creditCopyText">Clint Adair</a> on <a href="https://unsplash.com/s/photos/network?utm_source=unsplash&amp;utm_medium=referral&amp;utm_content=creditCopyText">Unsplash</a></span>