When in the Course of human events, it becomes necessary for one people to dissolve the political bands which have connected them with another, and to assume among the powers of the earth, the separate and equal station to which the Laws of Nature and of Nature’s God entitle them, a decent respect to the opinions of mankind requires that they should declare the causes which impel them to the separation.

Services have to be independent. They can achieve Independent Scalability and Independent Lifecycle by having Independent Data, Independent Code and Independent Deployments.

My First Law of Distributed Object Design: Don’t distribute your objects

— Martin Fowler

Everything in our life has its price. Services give a lot of benefits, but you are not getting them for free. One should always very carefully consider the price, and readiness to pay it. There are visible and hidden costs of services, including, but not limited to Latency, Complexity and MPOFs

Latency

Services need to talk to each other. It means that each request will have to be transferred over the network. Messages have to go through series of transformations - from client’s “language”, to network one, and to one that service understands (and the same on the way back, if your request needs a reply). If you have (and I hope you have) security policies applied to communication - add expenses for authentication, potentially - for encryption and decryption too. All these elements add precious milliseconds (tens? hundreds?) to each request processing. Multiply this by amount of services involved - and you can get pretty significant delays. Are you ready?

Any organization that designs a system (defined more broadly here than just information systems) will inevitably produce a design whose structure is a copy of the organization’s communication structure.

http://www.melconway.com/Home/Committees_Paper.html

Let look a little closer at what it really means for software organizations, and how communication structure impacts the software system.

Initial design of a software system may have nothing to do with the communication structure. But most (if not all) software systems are evolving in time, and that’s where the Conway’s Law really starts to take its effects. Very similar to the second law of thermodynamics, the evolving software system entropy always increases. And this increase happens in the framework of the communication structure.

I guess it is easier to use a new name (Microservices) rather than say that this is what SOA actually meant

— Arnon Rotem-Gal-Oz (@arnonrgo) March 16, 2014

I guess it may be even easier to say what SOA actually meant. Or, at least - what I believe it had in its heart. In this post I am going to try to see how can we define SOA the way that:

• captures its spirit
• does not have elements that damaged the whole idea (WS-*, ESB, etc.)
• goes even further and does not include anything that overly-limit SOA application

In essence, we are looking for a lean SOA definition (to make sure, it is not “lean SOA”, but “lean definition”).