Microservices is all the hype these days, so in this post, I'll try to highlight its most important aspects. I've split these aspects into four groups based on the different benefits they provide. 

Single Responsibility Principle

• The single responsibility principle states that a software component should do a single job and do it well, and this is the main concept behind microservices - that's where its name come from. The jobs should be small in scope and easily defined. 

Before this term, microservices was simply called web services, REST services, or workers when its bootstrap was a message coming from a broker instead of a web request. Today, microservices comes can be split into these two groups: web services or messaging workers.

• Low Coupling

• Low coupling refers to a low level of dependency between software components, which means that the risk of breaking a component when changing another is reduced.

A microservice usually relies on other services for its inputs. Sometimes they will come as part of the request, or the microservice will call other services to get the inputs it needs. In either case, there will always be a dependency on the contract of the consumed service, but not on how this service produces this contract. Changes in the behavior of a microservice should not require changes in the services that consume it, as long as the contract stays the same.

• Conway’s Law

• Conway's law states that:

"organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations."

• Organizations that develop software in silos, depending on handoffs of development stages, will develop a software that will also be highly interdependent on its parts.

• Microservices will usually have its own database and resources. There will be data duplication, which is alright because eventual consistency will be achieved.

• Microservices will also be developed and maintained by a single team who have complete ownership of the service as a whole - there will be no separate QA or DBA team to work on a set of microservices. Those professionals will be a part of the team even if they eventually work on more than one team. It should also be noted that a single team can own more than one microservice.

• Microservices can be implemented using independent technology stacks. The best technology stack to use when building a microservice is the one that delivers the best value in that case. Today it might be Java, but tomorrow it might be Go, so as long as the team that masters that stack and the integration is performed using standard protocols, there's no need to try to stick to a single stack.

• It's Not SOA

• One of the most common misconceptions regarding microservices is about how it differs from SOA. There are even those who claim that microservices is a special kind of SOA, which I disagree with. Here's why: 

• SOA stands for Service Oriented Architecture, and a Microservices Architecture is indeed an architecture oriented by services, but the term SOA references a different kind of integration. When the concept of SOA was born, this integration meant exposing the whole system to others via Web Services, usually refactoring those systems and using some kind of middleware such as an Enterprise Service Bus (ESB) to mediate this communication.

• On the other hand, a Microservices Architecture refers to systems, or parts of systems, built from scratch as microservices.

• The systems that an SOA integrates live by their own,  so the integration is optional. Microservices cannot live by their own, and will always be dependent upon other services in order to continue the job they started, or to provide completed bits and pieces of the job so that they may continue. You will always need more than one microservice, or at least other software components like a user interface, to get some business value from them.

• Another important differentiating factor is the fact that a Microservice Architecture is fundamentally based on the "smart endpoints and dumb pipes" paradigm. It values choreography over orchestration, and therefore, should have simplified communication channels, which is conceptually the opposite of an ESB integration. Even if MuleSoft were used to translate messages between microservices, that process would be seen as a microservice of its own. 

• And finally, microservices are built for the Cloud so they must be adherent to statements like the Reactive Manifesto, or the 12 factor app, and none of these existed when there was hype around SOA.

• So, what are your thoughts? I'd love to hear your perspective in the comments below. 

• To learn more about microservices, read my whitepaper, Microservices Architecture as a Large Scale Refactoring Tool, and check out the amazing book Building Microservices, by Sam Newman.