Microservices are a way of breaking large software projects into loosely coupled modules, which communicate with each other through simple Application Programming Interfaces (APIs).
Resilience : the capacity to recover quickly from difficulties
Improve fault isolation: Larger applications can remain mostly unaffected by the failure of a single module.
Technology Heterogeneity
Eliminate vendor or technology lock-in: You can try new technolgy with different module.
Ease of Understanding: With added simplicity, developers can better understand the functionality of a service.
Scaling
With a large, monolithic service, we have to scale everything together. One small part of our overall system is constrained in performance, but if that behavior is locked up in a giant monolithic application, we have to handle scaling everything as a piece. With smaller services, we can just scale those services that need scaling, allowing us to run other parts of the system on smaller, less powerful hardware.
Ease of Deployment
A one-line change to a million-line-long monolithic application requires the whole application to be deployed in order to release the change. That could be a large-impact, high-risk deployment. In practice, large-impact, high-risk deployments end up happening infrequently due to understandable fear.
With microservices, we can make a change to a single service and deploy it independently of the rest of the system. This allows us to get our code deployed faster. If a problem does occur, it can be isolated quickly to an individual service, making fast rollback easy to achieve.
Composability
One of the key promises of distributed systems and service-oriented architectures is that we open up opportunities for reuse of functionality. With microservices, we allow for our functionality to be consumed in different ways for different purposes. This can be especially important when we think about how our consumers use our software.
Optimizing for Replaceability : Easy to replace it needed.With our individual services being small in size, the cost to replace them with a better implementation, or even delete them altogether, is much easier to manage.
Deployment of Microservices
The best way to deploy microservices-based applications is within containers, which are complete virtual operating system environments that provide processes with isolation and dedicated access to underlying hardware resources. One of the biggest names in container solutions right now is Docker,
Drawback of Microservices
Large numbers of microservices are difficult to orchestrate.
Understanding, managing and testing dependencies is difficult.
Message flow increases with the number of microservices and hampers performance.
Large numbers of microservices are difficult to secure.
Once requirements change, do you want a microservice for one new feature or re-write and add to an existing service. That is a difficult decision in an architecture with many microservices.
Resilience : the capacity to recover quickly from difficulties
Improve fault isolation: Larger applications can remain mostly unaffected by the failure of a single module.
Technology Heterogeneity
Eliminate vendor or technology lock-in: You can try new technolgy with different module.
Ease of Understanding: With added simplicity, developers can better understand the functionality of a service.
Scaling
With a large, monolithic service, we have to scale everything together. One small part of our overall system is constrained in performance, but if that behavior is locked up in a giant monolithic application, we have to handle scaling everything as a piece. With smaller services, we can just scale those services that need scaling, allowing us to run other parts of the system on smaller, less powerful hardware.
Ease of Deployment
A one-line change to a million-line-long monolithic application requires the whole application to be deployed in order to release the change. That could be a large-impact, high-risk deployment. In practice, large-impact, high-risk deployments end up happening infrequently due to understandable fear.
With microservices, we can make a change to a single service and deploy it independently of the rest of the system. This allows us to get our code deployed faster. If a problem does occur, it can be isolated quickly to an individual service, making fast rollback easy to achieve.
Composability
One of the key promises of distributed systems and service-oriented architectures is that we open up opportunities for reuse of functionality. With microservices, we allow for our functionality to be consumed in different ways for different purposes. This can be especially important when we think about how our consumers use our software.
Optimizing for Replaceability : Easy to replace it needed.With our individual services being small in size, the cost to replace them with a better implementation, or even delete them altogether, is much easier to manage.
Deployment of Microservices
The best way to deploy microservices-based applications is within containers, which are complete virtual operating system environments that provide processes with isolation and dedicated access to underlying hardware resources. One of the biggest names in container solutions right now is Docker,
Drawback of Microservices
Large numbers of microservices are difficult to orchestrate.
Understanding, managing and testing dependencies is difficult.
Message flow increases with the number of microservices and hampers performance.
Large numbers of microservices are difficult to secure.
Once requirements change, do you want a microservice for one new feature or re-write and add to an existing service. That is a difficult decision in an architecture with many microservices.
No comments:
Post a Comment