Re: [soa-rm] compact blurbs on microservices

[Ken Laskey <klaskey@mitre.org>]

Unfortunately, the world in which we live is not always clear or consistent.

Most folks talking MS also talk in terms of REST.  While I have seen articles saying you don’t have to use HTTP, I haven’t seen much where something else was used.  (Several years ago, I got into a discussion of “is FTP Restful?” Google that for the numerous debates.)   I’d be happy to see examples other than HTTP.

MS certainly have a “bounded context”, e.g. a single business function, but that doesn’t mean that same business function cannot be usable as part of multiple, dare I say, applications.  However, the MS becomes a dependency of the application.  Minimizing dependencies is likely good if it doesn’t force you into wasteful duplication or cause synchronization issues.  This has been on our wish list for clarification.

How you would package a MS, e.g. within a container, has also been an open issue if the MS was to be used beyond a single container.

Finally, it is an open question that goes beyond MS to ask how much notice does a consumer want and/or need when something under the hood changes.  We know when Word changes because Microsoft has us install an identifiable upgrade.  We don’t know when Google tweaks their algorithms and you get slightly (significantly?) different search results.  A shipping service upgrades for new postal rates and I likely want accurate shipping cost even if I didn’t know postal rates changed.  I can go on.  Yes, the answer is it depends.

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 Oct 27, 2016, at 5:16 PM, Martin Smith <bfc.mclean@gmail.com> wrote:

Really I find these definitions more and more confusing and apparently inconsistent. 

Surely all "components" (which have been around forever) are not "microservices." 

And I didn't necessarily think all MS only used RESTful protocols. 

And I surely didn't get the idea from NIST and prior work that MS were designed so that "any application can use [them}."  Rather the opposite, in fact: several other sources touted the benefits of an MS having a single business-function customer for which it is optimized. And multiple sources seemed to imply that MS were typically/exclusively used within a single application container. 

And finally I am rather skeptical that all or most MS maintenance can be done safely without coordination and testing with other components of the overall application:  just because an API looks the same doesn't mean that the the algorithm that generates the MS' output has not changed in a way that affects the validity of the data generated or the performance (response-time) of the MS.  (This might be also said of over-enthusiastic advocacy for encapsulation generally.) 

Martin

On Thu, Oct 27, 2016 at 4:55 PM, Ken Laskey <klaskey@mitre.org> wrote:

Rex,

The Wikipedia article says:

an application is a computer program designed to help people perform an activity.

While I’d say that is correct, I’m not sure it’s useful.  BTW, the discussion on slicing and dicing what is application vs. operating system vs. utility … was entertaining.

What I am looking for is a definition of application in the context of “components are defined as independent microservices that any application can use”.  I don’t necessarily need an exhaustive taxonomy but this goes back to old discussions of when is an application offered as a service or when does a service constitute an application.

I’ll take anything that provides some clarity.

Ken

On Oct 27, 2016, at 2:32 PM, rexbroo <rexb@starbourne.com> wrote:

The conventional definition of application software from Wikipedia still works for me. https://en.wikipedia.org/wiki/Application_software

However, I think you may be looking for the definition of something in relation to the conventional definition of application that is like microservivce is to servivce, e.g. micro application, or containerized/componentized application. Correct?

Rex

On 10/27/2016 10:41 AM, Ken Laskey wrote:

Came across this article

http://searchsoa.techtarget.com/tip/Poor-componentization-puts-service-programming-at-risk?utm_content=control&utm_medium=EM&asrc=EM_ERU_66911560&utm_campaign=20161027_ERU%20Transmission%20for%2010/27/2016%20(UserUniverse:%202215767)_myka-reports@techtarget.com&utm_source=ERU&src="">

and while the focus is really on OSGi, its discussion of microservices includes the following:

The first model is the microservices model. With this model, components are defined as independent microservices that any application can use. They also have stateless behavior so they can be replaced and scaled as needed. Additionally, they are independent of each other and of applications that use them, so deployment/redeployment of a microservice doesn't affect applications it serves.

and

But microservices might be the biggest revolution in componentization. A microservice is a logic component deployed in RESTful form, designed to be accessed through a URL. Microservices easily address issues of component dependencies and avalanches of redeployments due to small component changes because microservices are independent as long as the API call formats are maintained. Microservices won't change the modularity of JVM or provide an efficient way of managing remote-versus-local components, but they could significantly reduce the burden of component management for distributed components.

My biggest problem is I have yet to see a good definition of “application”.  Is it just the user interface that calls microservices under the hood?

Any favorite (attributable) definitions of application?

Ken 

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

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

--

Martin F Smith, Principal

BFC Consulting, LLC

McLean, Va 22102

703 506-0159

703 389-3224 mobile