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:
https://twitter.com/jetpack/status/543688544204898304Eugene 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.
Form Follows Function 
Old wine in a new bottle. Nothing new here. Microservices is an example of SOA.
LikeLike
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.
LikeLike
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
LikeLike
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).
LikeLike
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.
LikeLike
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
LikeLike
Claiming the same caveat as above re: background and biases (the vast majority of which is system to system), but I’ve never had need to do dynamic lookups for services at runtime. The idea of the additional latency that would be involved makes that seem like a route I’d take only at the last resort. Ditto with chains of services calling services. Unless you’re working asynchronously, the extra time spent going over the wire can easily kill any benefit you get from the distribution. Jeppe Cramon’s series on microservices (starting post here: http://www.tigerteam.dk/2014/micro-services-its-not-only-the-size-that-matters-its-also-how-you-use-them-part-1/) talks about the latency issues and coupling inherent in chains of service calls.
LikeLike
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
LikeLiked by 1 person
Thanks for the inspiration – http://improving-bpm-systems.blogspot.ch/2014/12/architecting-application-architecture.html
Thanks,
AS
LikeLiked by 1 person
Fixed the broken link for “Can I Haz Name?”
LikeLike
Pingback: Microservice Mistakes – Complexity as a Service | Form Follows Function
Pingback: Form Follows Function on SPaMCast 331 | Form Follows Function
Pingback: Microservice Mistakes – Complexity as a Service | IasaGlobal