Re: [soa-rm] comments on sp800-180_draft -- further reflection

[Ken Laskey <klaskey@mitre.org>]

Martin,

You are accurate in seeing each (micro)service/application in a separate container, but my reading indicates this is an implementation decision rather than a part of the definition.  If you recall the book Building Microservices that I quoted from several weeks ago in reference to its discussion of how SOA relates to microservices*, that author advocates a similar approach because (as I recall without checking the book) (1) you can spin up (or down) an exact copy of what you need for scalability, (2) you know exactly what new service you are deploying instead of having a package with several services, some of which may not have been updated, and (3) you know exactly what you are monitoring.  The downside is lots of moving parts and that author didn’t (to my satisfaction) address the comms overhead.

* "The microservice approach has emerged from real-world use, taking our better understanding of systems and architecture to do SOA well. So you should instead think of microservices as a specific approach for SOA in the same way that XP or Scrum are specific approaches for Agile software development.”

That said, the NIST document needs to be careful it is not too absolute because, as I noted in one of the comments, there is still a lot that is changing, a lot of tool development is in progress, and things we thought were stupid are becoming best practice (and back to stupid again).

Ken

------------------------------------------------------------------------------
Dr. Kenneth Laskey
MITRE Corporation, M/S F510          phone: 703-983-7934
7515 Colshire Drive                           fax: 703-983-1379
McLean VA 22102-7508

On Mar 19, 2016, at 11:09 AM, Martin Smith <bfc.mclean@gmail.com> wrote:

Ken-- Thanks for putting this together on short notice!

One thing that struck me about NIST's characterization of Microservices (which I will accept as correct as I don't know anything to the contrary) is that they seem to be used as separate dedicated instances for each container or maybe even each app in a container (see diagrams in the draft.) 

So that makes them seem very similar to a function in a function library, which is instantiated separately for each calling application. 

If that's more or less correct, then what's the difference between a function in a library and a microservice? One difference might be that the microservice api is not limited to the syntax of the language of the code library. Another might be that accessing the microservice requires communication outside the application's process space, i.e., a socket call. 

Does any of this make sense? 

Thanks,

Martin

 

On Fri, Mar 18, 2016 at 10:51 PM, Ken Laskey <klaskey@mitre.org> wrote:

Please find attached the comments of the OASIS SOA Reference Model Technical Committee.

We commend NIST for taking the initiative to provide clarity on this important topic.  We appreciate the opportunity to comment on the draft document and would be pleased to clarify or expand on these comments if need be.    

Ken Laskey, chair

------------------------------------------------------------------------------
Dr. Kenneth Laskey
MITRE Corporation, M/S F510          phone: 703-983-7934
7515 Colshire Drive                           fax: 703-983-1379
McLean VA 22102-7508

--

Martin F Smith, Principal

BFC Consulting, LLC

McLean, Va 22102

703 506-0159

703 389-3224 mobile