Microservices - The Truth Behind the Hype

What is it all about?

"You know that Service Oriented Architecture you are using?"
"Yeah?"
"Keep on doing it - just make them smaller."
"Smaller?  How small?"
"Well, as small as makes sense to you.  Focus on making it do one thing, and one thing well."
"You mean, like, 'Integer as a service'?"
"Everything can be taken to an extreme - and that would be an extreme view.  Maybe task-focused sub-domains."

What problem is it trying to solve?

The same problem we have being trying to solve all along, with SOA, object-orientation, COM:
Essentially, encapsulation and reuse.

The hope is, with service dependencies rather than assembly dependencies, that there will be less dependency and version conflicts.

Good Practices

ü Focus on cohesion, not size.
ü Use re-writability as your heuristic.
ü Create an API tailored to your developer's use cases.

Practices to Avoid

x Relying on HTTP as the transport mechanism.
x Sharing state between services.
x Distributing the services unnecessarily.
x Using request-response instead of push and events.

Benefits of Microservices

ü Isolation.
ü Independent scaling.
ü Independent failures.
ü Modularisation.
ü Reduced fear of making code changes.

Drawbacks of Microservices

x Debugging becomes hard.
x Networking issues.
x Latency & consequence performance reduction.
x Increased infrastructure requirements.
x Orchestration, monitoring.
x Communication complexity.

Will anything remain once the hype has gone?

A well-informed friend of mine holds the view that this will be how we develop enterprise software applications in the future.  I don't think he is far wrong.  We will learn how to size the services appropriately, and how to monitor and coordinate them.  I'm not convinced the services will be "micro" the way the current hype is referring to them.  But they will be small, modularised, and serving specific use cases.