What is a microservice

Microservices Architectural Style as a specialization of SOA. Don't forget that the generally accepted view is that all SOA really is, is four sentences:
  • Boundaries are explicit
  • Services are autonomous
  • Services share schema and contract, not class
  • Service compatibility is based on policy
These tenets of SOA were given to us by Don Box of Microsoft which is ironic since MS then went on to release WCF and then told us to Go Forth and Service Orientate. Look where that got us.
Then we have this, from Lewis/Fowler:
In short, the microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare mininum of centralized management of these services, which may be written in different programming languages and use different data storage technologies.
From this definition it's clear that microservices fulfill at least the first two tenets (with real emphasis on the second), but it's questionable whether they fulfill the third (I don't really understand tenet 4 so I won't comment).
The reason the third tenet may not hold for microservices is that one of the characteristics of microservices is that they are generally exposed over a RESTful API, which, one could argue, does not expose contract and schema at all (over and above the regular http verbage), as we see from Fowler:
a suite of small services, each... communicating with lightweight mechanisms, often an HTTP resource API
Another way in which a microservices style deviates from SOA is with this prescription:
These services are... independently deployable by fully automated deployment machinery
Following the original tenets of SOA does not prevent me from manually copying my service binaries into my production environment, but with the microservices approach, the service deployment and management should be fully automated.

Comments

Post a Comment

Popular posts from this blog

EJB - Stateful vs Stateless

For  stateless session beans  the server can maintain a variable amount of instances in a pool. Each time a client requests such a stateless bean (e.g. through a method) a random instance is chosen to serve that request. That means if the client does two subsequent requests it is possible that two different instances of the stateless bean serve the requests. In fact there is no conversational state between the two requests. Also if the client disappears, the stateless bean does not get destroyed and can serve the next request from another client. On the other hand a  stateful session bean  is closely connected to the client. Each instance is created and bounded to a single client and serves only requests from that particular client. So happens that if you do two subsequent requests on a stateful bean, your request will be served always from the same instance of the bean. That means you can maintain a conversational state between the requests. At the end of the li...
Read more

Inversion of Control vs Dependency Injection

IoC is a generic term meaning rather than having the application call the methods in a framework, the framework calls implementations provided by the application. DI is a form of IoC, where implementations are passed into an object through constructors/setters/service look-ups, which the object will 'depend' on in order to behave correctly.
Read more