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.
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.
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.
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: Photo by Clint Adair on Unsplash
Top comments (0)