Microservices governance vs SOA

Question

I was working in SOA goverened projects for the last 10 years and now we switch to a Microservices architecture ones.

The good thing in SOA was that we had a Canonical Data Model where which was built with some effort indeed but at the end all systems ended up speaking the same 'language' and communication was centralized via a Service Bus.

In a Microservice architecture teams are independent and as there is no service bus wonder how all this intergration points will work.

1) Is there a way to enfore some contracts like there is WSDL in SOA (for SOAP) ?

2) If team developing service B is autonoumous and deploys a new service it has to keep the old version as well no ? In SOA this problem was solved that on the service bus we kept v1 and a we did a transformation to v2.It was trasparent for consumers that service B has a new version.

3) What type of govenrnance you would put in place in case the number of microservices is quite high like in the below picture knowing the teams have to be as much as possible autonoumous ('agile')?

I am not looking fot the best answer , I am interested in different opinions as there is no magic solution here.

Thanks.

Answer 1

We are also undergoing a similar change.

The question about whether you enforce contracts is independent of if you connect through the service bus or directly. You could build your microservices to use SOAP and WSDL. The industry as a whole seems to be moving away from this. We are using REST.

The team responsible for deploying the microservice needs to treat all external parties like customers. This means when changes occur, they need to keep backwards compatibility and then undergo a change management process in other teams to have them upgrade before decommissioning the old version. We avoid breaking changes as much as possible, and use semantic versioning otherwise. Automated tests help keep all this possible.

In terms of governance, I would set ground-rules around the following:

• what is (and is not) considered a breaking change, and how this is to be handled in the versioning system
• how/where documentation for services is to be published and updated
• how clients are to authenticate themselves
• security recommendations such as TLS and authentication mechanisms

While you may not have a canonical data model covering all services, it could be wise to introduce some smaller conventions suitable to your domain. In my domain, this means always using 3-character ISO standard currency codes alongside monetary amounts. We never assume the currency or use a different representation.

Answer 2

I participated in a similar transition, with quite a few mistakes along the way. Here are some things I would do as a central governing body:

1. Create architectural independence first

I think the biggest mistake is just letting old SOAP services be their own thing. It won't work. Second mistake is letting Microservices be Data CRUD services (like Product, Customer, etc.). That won't work either.

Those things will just create a lot of synchronous interdependencies and a lot more problems for you!

I would invest in an architecture where interdependencies are minimized. Reduce the need for synchronous communication as much as possible. And I don't mean use MQ, but main functions of a microservice should work with other services down.

That requires a whole new type of decomposition that won't be along the lines of old SOAP services. So this is hard work, but avoids a lot of (exponental) problems later. Check out Self-Contained Systems.

2. Protocol governance

Especially if you are transitioning to RESTful HTTP, I would set rules for:

• Linking format standard (so all applications can be crawled uniformly)
• Linking best practices (all resources have to be reachable through links, urls should not be hard-coded, etc.)
• Documentation standard (how to document Media-Types)
• Versioning Media-Types
• And importantly, an automatic way to mark a version obsolete after a non-backwards compatible change. And a standard grace period after which these are removed (the time they have to be kept alive). Either by calendar interval, or number of releases, etc.

There is no one way of doing either of these, so you have to come up with all of these, then enforce them.

I would stay away of requiring a specific product (like Swagger), and let these decisions with the teams.

If you are just looking for JSON-RPC and not REST, then some of the above points may be irrelevant to you.

3. Infrastructure-like things

Create unified standard for authentication and authorization. Again, I would make those as product-independent as possible, and not require synchronous communication.

For example define to use Json Tokens. Those things can be used "offline", without communication to anybody, and can contain assertions about a user that help with authorization as well.

Define security constraints, like communication encryption of certain messages also. Again, I would just require the "what" not "how".

4. Continuous supervision

I would perhaps create a team for architectural supervision. It is hard to create a proper architecture, it is even harder to change it without falling for quick and dirty solutions projects sometimes demand, creating sneaky dependencies and hidden issues.

These people need to be hands-on domain experts and architects and have to ultimately be responsible for the functioning of the whole landscape.

Well, that's my improvised list of things, HTH..

Answer 3

both architectures have similar pros and cons and some differences. In both architectures, each service - unlike a monolithic architecture - has a certain responsibility. Thus, services can be developed in various technology stacks which bring technology diversity into the development team. The development of services can be organized within multiple teams, however, each team needs to know about the common communication mechanism in SOA.

In microservices, services can operate and be deployed independently of other services, unlike SOA. So, it is easier to deploy new versions of services frequently or scale a service independently.

In SOA, ESB (Enterprise Service Bus) could become a single point of failure which impacts the entire application. Since every service is communicating through ESB, if one of the services slows down, it could cause the ESB to be clogged up with requests for that service. On the other hand, microservices are much better in fault tolerance. For example, if there is a memory leak in one microservice then only that microservice will be affected. The other microservices will continue to handle requests.

In both architectures, developers must deal with the complexity of architecture and a distributed system. Developers must implement the inter-service communication mechanism between microservices (if the message queue is used in Microservice architectures) or within ESB and services.

Unit Testing is more difficult as developers must mock the communication mechanism in tests. Due to many different service types, deployment and operational complexity are a concern in both architectures.

In SOA, services share the data storage (as shown in Figure 1) while each service can have an independent data storage in microservices. Sharing data storage has its pros and cons. for example, the data can be re-used by between all services while it brings dependency and tightly coupling within services.

Last but not least, the main difference between SOA and microservices lies in size and scope. Microservice has to be significantly smaller than what SOA tends to be and mainly is a small(er) independently deployable service. On the other hand, an SOA can be either a monolith or it can be comprised of multiple microservices.

It is also important that SOA has been designed and implemented in various styles which could be different with what it is described here, usually due to a focus on ESBs which is used to integrate monolithic applications.