Re: [soa-rm] compact blurbs on microservices

Hello from nowhere (deep in Dublin. Ireland)!

In old days an Application differed from a Component only in that the Application could be deployed independently while the Component could not. An appearance of Application Servers and J2EE/JEE destroyed this differentiation because EJB could be independently deployed in the Business Containers. If we put off “JB”, which are technology specific characteristic, EJB constituted an enterprise level components that “that any application can use””.

Then, a concept of Services appeared as a special type of applications with certain characteristics that not every/any application could possess.

Then, we return to ‘EJB’, but in the form of independently deployable components that can act as a special type of applications – Service, but that are not Services yet. Why we create such a mess?

My opinion is this: the movement to microservices is another attempt to shift development methodology back to Objects because developers could overview and comprehend Objects and their combinations, but it was and is the top level of complexity they can work with. Everything else, that gets out of this paradigm required wider and deeper considerations and concerns that are usually a prerogative of people who thing by heads, not by coding (this is not my _expression_). People use new words to hide inconsistencies that would appear if the old and well defined words would be used.

Finally, are microservices really self-consistent and independent providers of the work when they are deployed in the container? My answer is NO. This is because the collection of microservices (in the container) includes so-called libraries also independently deployed (in the same containers) – low-level utilities that enable operations and communications of microservices. Such libraries are supposed to be part of the container, but this would mean that we will need as many containers as we can create combinations of microservices. This is absurd! Thus, we have to admit microservices are not independent and self-sufficient entities though they can be deployed in the container independently from each other (i.e. they are NOT micro or mini Services).

- Michael

Sent: Thursday, October 27, 2016 at 8:55 PM
From: "Ken Laskey" <klaskey@mitre.org>
To: "<rexb@starbourne.com>" <rexb@starbourne.com>
Cc: soa-rm@lists.oasis-open.org
Subject: Re: [soa-rm] compact blurbs on microservices

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 

soa-rm message