Microservices vs SOA – Is there any real difference?

Microservice architecture has been the hot topic for 2014, so I suppose it’s appropriate that it be the subject for what I intend to be my last post until 2015. Last week, Kelly Sommers kicked off an active discussion of the nature of microservices vis-a-vis SOA:

This isn’t really a new observation. Before Lewis and Fowler published their final installment of the post that started the everyone talking, Steve Jones had already published “Microservices is SOA, for those who know what SOA is”. Even Adrian Cockcroft, in response to Sommers, noted:

And yet, they’re different. In a post written for Iasa, “Microservices – The Return of SOA?”, I quoted Anne Thomas Manes’ “SOA is Dead; Long Live Services”:

Successful SOA (i.e., application re-architecture) requires disruption to the status quo. SOA is not simply a matter of deploying new technology and building service interfaces to existing applications; it requires redesign of the application portfolio. And it requires a massive shift in the way IT operates. The small select group of organizations that has seen spectacular gains from SOA did so by treating it as an agent of transformation. In each of these success stories, SOA was just one aspect of the transformation effort. And here’s the secret to success: SOA needs to be part of something bigger. If it isn’t, then you need to ask yourself why you’ve been doing it.

As I stated in that post

Part of the problem may be that both SOA and microservices have aspects that transcend boundaries. Manes quote above makes it clear that SOA is concerned with enterprise IT architecture. Microservices are primarily an application architecture pattern.

Microservices can be reused by multiple applications, but need not be. SOA’s emphasis was at a higher level of abstraction. While the two share a great many principles, they apply them at different scales (application and solution architecture versus enterprise IT architecture).

Last weeks Twitter stream did produce some examples of principles that are, if not unique, then at least more heavily emphasized in the microservice style. From Marco Vermeulen:

Eugene Kalenkovich‘s post, “Can I Haz Name?”, captures the essence (in my opinion) of this style: “Independent Scalability, Independent Lifecycle and Independent Data”. It’s not about the lines of code, but about the separation of concerns within the context of the application. These same “independences” are important to SOA, but define a microservice architecture.

Advertisements

13 thoughts on “Microservices vs SOA – Is there any real difference?

    • The one thing that keeps me from saying that is the sub-application nature of services created for microservice architectures. SOA (in my experience) was more about connecting disparate applications & sharing functions of those applications rather than creating very small grained services that were not part of applications in their own right. In my opinion, MSA is scaling down of SOA principles to a lower level of abstraction – a specialization of SOA, if you will.

      Like

  1. Hi Gene,

    I think that three principles (common to SOA and microservices) are important. The first is the most obvious: well-defined interfaces, including methods, objects and exceptions. The second is an effective mechanism for defining contracts. The third is a good mechanism for discovering service implementations *and* their dependencies.

    As an industry, we’ve focused on #1. Betrand Meyer’s Eiffel language is the only thing I’m aware of that promotes contacts as a first-class mechanism. This needs to become language-neutral before child components can comfortably use microservices. Discovery mechanisms have been defined in SOA, but it’s unclear to me whether UDDI or ebXML is widely used.

    Given the above, coarse-grained services appear to be more able to seal off their implementations and dependencies than microservices. Stateless microservices try to avoid dependencies, but stateful microservices have a big challenge: how to be small, encapsulated, and expose their dependencies. Anyone who has used Maven knows what this can be like.

    Regards,
    Charlie

    Like

    • While there has been some focus on #1 (structural contracts), the lack of attention to #2 (behavioral and semantic contracts) makes things harder than they have to be. Unfortunately, the current fascination with RESTful services for system to system scenarios seems to take us backward on this front. The third category is less of a concern, in my opinion, though I’ll admit that may be colored by my background and biases (never needed a formal registry for human use and cringe at the thought of dynamic discovery due to the additional latency).

      Like

    • Nearly forgot – I also cringe at the idea of stateful services (micro or otherwise). Having to deal with downstream dependencies in a distributed application seems to be a case of someone missing the point of distributed applications.

      Like

  2. Gene,

    I concur with your last point, although frequently, it is harder to design stateful services than it is to intend to. Also, stateless services often have code dependencies on other stateless services, which adds complications

    Fortunately, function/oriented languages are teaching people to design this way

    One final response on the idea of a lookup service. When s human user is the consumer of the service, Google is virtually as good as a lookup service. However, when automated processes are the client, solid lookup services become very important. Even if all of the services are hosted in a private cloud, you still have code version and database configuration issues

    Regards,
    Charlie

    Like

  3. Hi Gene,

    You make a good point about network latency, in general. However, as you might also tell me, this is not a one size fits all concern.

    My rule of thumb (very anecdotal, but useful nonetheless) is that CPU’s are about 1000x faster than RAM which is about 1000x faster than LAN which is about 300x faster than WAN.

    If a microservice makes continual requests of other microservices over a WAN or LAN and doesn’t do much computing, then network latency will certainly be the bottleneck. OTOH, if the calling microservice is CPU and RAM bound and does relatively little network access, then not so much.

    The other exception case would be where the microservice doesn’t rely on HTTP as a transport (i.e. uses shared memory or pipes) and runs on the same machine as its microservices, then the impact of latency should be greatly reduced.

    Of course, there are many other factors than the two I mentioned (such as CPU, RAM or network contention from other concurrent processes), so your or my mileage may vary.

    I believe your recommendation to use stateless microservices (where possible), and to stay clear of dependent microservices is a sound one.

    Regards,
    Charlie

    Liked by 1 person

  4. Pingback: Microservice Mistakes – Complexity as a Service | Form Follows Function

  5. Pingback: Form Follows Function on SPaMCast 331 | Form Follows Function

  6. Pingback: Microservice Mistakes – Complexity as a Service | IasaGlobal

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s