Category Archives: SOA

Are Microservices Just SOA Done Right?

Having based previous solution designs on SOA what will Architects need to do differently when adopting the Microservices approach? I thought I would look how the definitions of the two approaches match up. The first problem was there are plenty of definitions of each, so I have chosen to the definitions from a couple of the most well regarded publications: SOA Design Patterns (Erl 2008) and Building Microservices (Newman 2015). The following diagram illustrates how they align:

I looked at each of the Microservice principles to see if I could trace them back to a characteristic of SOA

Model Around Business Concepts is a straightforward match to the SOA characteristic of being Business Driven.

Independently Deployable services are a practical requirement for having an Enterprise Centric services architecture. If services were not independently deployable then service consumers would soon become frustrated at the need to co-ordinate changes. This is also true for services which depend on one another, the need to coordinate changes soon brings back the problems of monolithic designs, for example the scope of testing.

Hide Internal Implementation Details is not explicitly stated in Erl’s SOA characteristics but is a very central concept in many other definitions. If implementation details are not hidden consumers may be tempted to go directly to source, which defeats the value of having explicit service interfaces and, at its most extreme, would start coupling consumers to a specific vendor implementation, therefore no longer being Vendor Neutral.

Isolate Failure is a key requirement for a Composition Centric architecture because as more independent services are involved it becomes harder to guarantee they will all be available and operating correctly.

That leaves three Microservices principles that don’t, at least in some way, obviously tie back to Erl’s SOA characteristics.

Decentralise All Things, in its architectural meaning, suggests avoiding ESB and Orchestrations that may place too much business logic centrally. The need for such mechanisms is not a requirement of SOA but they are often discussed in SOA books and have, in my opinion, become associated with SOA architectures.

Adopt A Culture Of Automation although a good objective for an organisation wanting to be agile is, I would argue, not an architectural matter.

Again being Highly Observable is more of a feature related to implementation than it is an architectural design. That being said messages flows are highly observable and, whilst messaging is not required to be Service Oriented, this is how most services are consumed.

In conclusion I do think Microservices are a good extension of SOA but that the extension is more about the ecosystem around building and deploying services, rather than the resulting architecture. The most fundamental takeaway, for me, is the argument, or caution, against over-using ESBs or Orchestrations.

As always a good view from Martin Fowler.

When SOA makes sense

2013.05.25 [IMG_0482]

I’ve always maintained its difficult judge your Enterprise Architect at annual reviews because the success of what we do can only really be judged over longer periods. I’d like to share a SOA success story that goes back to 2005 and has stood the test of time:

The initial business problem was to outsource part of the organisation but reading between the lines it could be seen that this was an area that was likely to undergo more changes. It also involved multiple ‘consumer’ systems wanting to use similar ‘services’ that would be provided from more than one system.

The scenario met the two things I have come to recognise as requirements where a SOA will deliver the maximum impact to the organisation:

1)      There is demand from three, or more, systems for a given service. This satisfies Robert L Glass’s “rule of three” (Fact 18) from his book Facts and Fallacies of Software Engineering which states it is “three times as difficult to build reusable components as single use components” and “a reusable component should be tried in three different applications before it will be sufficiently general….”. I’ve seen SOA approaches used where there is only a single client and yes, these work, but was the extra build cost worth it?

2)      The organisation using the proposed SOA is undergoing a prolonged period of change. How you can judge this is more gut instinct than a known fact but you can look at how the wider industry is changing.

I’d say these two facts alone make SOA a likely candidate but there was a third reason: the service was likely to be provided by more than one implementation (because some of the requests would be answered by another organisation) thus a need to bring in some middleware features like content-based-routing.

Buying a service from another organisation is also a good indicator that SOA principles and designs can be applied because there must be a contract, both in the legal sense and technical sense.  I would expect the purchasing organisation to drive the integration and the supplying organisation to provide the service, technically.

So what happened? Well the SOA went in fairly smoothly and then:

  • The outsourcing was abandoned
  • A significant portion of the original systems were replaced with updated implementations
  • The organisation was sold and merged with another organisation, requiring additional ‘consumers’ and’ providers’ to be added and requests to be routed
  • The newly merged organisation sold a large part of itself, introducing even more complexity during a two-year transition
  • Once the transition was complete the remaining systems could be simplified

Throughout all these changes the SOA proved to be adaptable and flexible. Some changes were necessary but the fundamental design endured.