Under construction - currently mostly brainstorming
Microservices are nothing new, modularization is considered a good design practice since the 70s.
Microservices are the next step after SOA in the evolution of software architecture. Without the next level of tooling this architecture would not be possible.
Microservices and modern software development is all about fast feedback cycles (Agile) and quick time to market.
The main benefits and differences to 'just' SOA:
Small teams usually own a service and should be able to test,release and deploy the service as independent as possible. No lock step updates of the whole system should ever be necessary.
If you cannot deploy a new version of a service independently of the rest of your system, you loose most benefits of this architecture. I would even go as far as saying that you should not buy into this architecture if you cannot satisfy this point.
Boundaries should usually not allow sharing of mutable state. Messaging is a very natural way of achieving this separation. HTTP (REST) is also a form of messaging as every other network protocol is. This would also be possible with modularization concepts of modern platforms (.NET, JVM) but it seems that the average developer is not able to use them correctly therefor we now have to cope with distribution :-(
Feature Toggles: 1
Name | Responsibilty | Description |
---|---|---|
Mesos | Cluster Management, Resource Allocation | Datacenter OS |
Kubernetes | Container Orchestration, Deployment, Scheduling, Application Management | |
Marathon | Container Orchestration | |
Docker | Virtualization/Container | THE containerization technology |
ELK | Logging | |
Ansible | Infrastructure managementm, Configuration, Deployment | |
Chef | Infrastructure managementm, Configuration, Deployment | |
Puppet | Infrastructure managementm, Configuration, Deployment | |
SALT | Infrastructure managementm, Configuration, Deployment | |
Zipkin | Distributed Tracing | |
Prometheus | Monitoring | |
Lagom | ||
Spring Boot | ||
Spring Cloud |
My own anti patterns:
- Making every service transactional is an anti pattern
- Making a service just because you can or dont now better, is an anti pattern