How microservices are different from isolated, standalone service?

Question

I would like to understand, how microservices is different from creating separate, stand-alone service(like REST or SOAP).

For instance, I have to create a license system for my Webapp. This can be simply a separate REST service, which can be consumed by Webapp. Still it can be tweaked, scaled up/down, isolated from my Webapp,

1. Why it needs to be a microservice ?

2. What are the pros and cons of each approach ?

Answer 1

Microservice is just a buzzword and people have been practicing that architectural style before calling it microservice. Here are the commonly agreed attributes of a microservice. If your service fulfills those points, chances are you can call it a microservice:

1. Independent life cycles (development, testing, deployment, etc) with independent development teams (to utilize Conway's Law to your advantage).
2. Focused scope - Implement exactly one specific domain aspect to keep it as "micro" as possible. (Separation of concerns)
3. Clearly defined interface to the outside world. Typically with changes only versioned and phaseout time frames.
4. Scalable design. Often stateless on purpose to allow for deployment of application clusters.
5. No sharing of databases/persistence. This is important to avoid indirect dependencies.

Additionally some people like to include things like freedom of implementation technologies, infrastructure automation and asynchronous communication.

The cons of not following these practices may not be relevant if you are only a single developer or small team starting out. But if you have a large development organization you would start to suffer under the crippling "monolithis"-disease, which potentially slows down development and release cycles significantly.

For more detailed understanding I recommend reading the Martin Fowler material. Especially the section about trade-offs.