Fwd: Microservices observations

[Ken Laskey <klaskey@mitre.org>]

Moving this to full list.

Part of the benefit of SOA was to reuse resources built as services rather than copying code and getting a configuration nightmare or rebuilding from scratch and getting all the inefficiencies that produces.    Using services in the SOA sense is enabled through interactions using a public interface communicating over network protocols rather than fine-grained coding to RPCs.

Microservices no doubt use the network-enabled interface but the question if the deployment uses containers is what gets packed into a single container.  Is it a single service and composition happens across containers?  If I have a saved image, is my service reuse in spinning up another instance of the image rather than having a network address somewhere in URI space?  With SOA, we use services through the network address that exposes the service and don’t have a private copy.  With microservices, what does the network address represent?

Stil wandering around the distinction and need to crisp up the questions.

Ken

Begin forwarded message:

From: rexbroo <rexb@starbourne.com>

Subject: Re: Microservices observations

Date: May 10, 2016 at 10:54:02 PM EDT

To: Martin Smith <bfc.mclean@gmail.com>

Cc: "Laskey, Ken" <klaskey@mitre.org>, Peter F Brown <peter@peterfbrown.com>, "Sweet Jr., William H" <wsweet@mitre.org>, Mike Poulin <mpoulin@usa.com>, "Gunning, Linda J." <lgunning@mitre.org>, William Cox <wtcox@coxsoftwarearchitects.com>

Reply-To: <rexb@starbourne.com>

Also read the IRON.io paper and came to some additional observations. Was intrigued to read the Wikipedia article on Docker technology since it appears that microservices are, in a practical sense, dependent on new container technology making a more economical way to package microservices together in an application than a virtual machine unless you're doing Docker in the Azure Linux virtual machine on the Windows platform.

The reduction in overhead makes combining microservices very attractive but it looks to me like each instance of a microservice or as many microservices as needed for a given application must live in its own application container with its bins/libs -- leading to some interesting questions for providers whose microservices must deliver the same level of performance across different apps within different containers on different servers/clouds/distributed environments duplicating all bins/libs for each microservice each time. Accessing independent databases makes for interesting complications if transactions in one app add/delete/change values in the databases accessed by other apps such as available credit in credit card accounts.

Should make for some interesting discussions.

Cheers,

Rex

On 5/10/2016 3:43 PM, Martin Smith wrote:

Just making observations/comments as they come. 

Read the MICROSERVICES: PATTERNS FOR BUILDING MODERN APPLICATIONS (Dwyer, IRON.io) paper Ken sent. 

Not the clearest exposition, I must say. And I found it ironic that Dwyer's company produces what I'd say qualifies as one of the despised "enterprise service bus" products. 

Also, the paper implied ignored the whole history of componentization of various types in development of "monolithic" applications, implying that prior to microservices everyone wrote and maintained massive spaghetti-code apps. 

Also read the WikiPedia article on microservices. Several things caught my eye. 

1. "  Adrian Cockcroft at Netflix, describing this [microservices] approach as "fine grained SOA" " 
2. [A microservices based architecture (MSA)] " is distinct from a service-oriented architecture (SOA) in that the latter aims at integrating various (business) applications whereas several microservices belong to one application only." [Martin's emphasis added. This seems important, as it suggest that the motivation for MSA is not to produce "multi-tenant' services but to improve app design, enable scaling and isolate maintenance issues.]
3.  "Granularity" definitely characterized in terms of scope of functionality of the service (vs. the service interface.) 
4. Brief discussion of "nanoservices" as an "anti-pattern": service that is too fine-grained. Metric suggested was balance between out-of-process communications overhead vs. work done by the service. 
   
5. Good caution about the un-avoidability of complexity--you can relocate it to the network but not eliminate it. 
   

After all this, I was left with the feeling that the MSA folks use "SOA" as a straw man to represent the first wave of overweight and functionally limited (and costly) SOA implementations that, not incidentally, was launched before services-friendly Cloud infrastructure and tool suites for managing distributed app life-cycles arrived.  So I kind of like the phrase "SOA done right" that the Dwyer paper mentions. I'm not sure it's MSA that is "SOA done right" but I think we can embrace the idea that the ideal implementation of SOA is not based on ESBs and UDDI. 

Martin

Martin F Smith, Principal

BFC Consulting, LLC

McLean, Va 22102

703 506-0159

703 389-3224 mobile

-- 
Rex Brooks
Starbourne Communications Design
Email: rexb@starbourne.com
GeoAddress:
1361 Addison St. Apt. A
Berkeley, CA 94702
Phone: 510-898-0670