|
Hi All,
My answer to Michael's
question Why we create such a mess? We're not creating
it, the developers are creating it as they look for more
efficient, more profitable, ways to develop and sell business
software. We can get hung up on architectural terminologies and
worry about whether something is an app or service and how many
supposedly independent components there are and how they operate
-- with a container, application server or virtual machine -- and
whether they use an API, but the market is in the process of
shaking out the effective versus the ineffective and it is looking
like the DevOps approach using microservices in containers is
currently in the lead. Who knows? I wish I knew, but I don't.
However, I see a few common denominators in this whirlpool.
First, it seems like everyone wants to break large, monolithic
business/enterprise solutions into smaller, more atomic, units of
functionality. We seem to call this componentization or
modularization, and whether the functional units are called
services, microservices, or willywidgets, they're just smaller,
supposedly independent, supposedly simpler, supposedly less
brittle, faster-computing functional units.
Second, to enable the first we need a supporting infrastructure
of libraries, binaries, and datastores that come in several models
-- application servers, virtual machines, docker-type containers,
and each of these have significant structural limitations, whether
they share the kernel, mimic the entire OS, or serve specific
kinds of applications. These architectures all have pros and cons.
My question is, can we make a start on unraveling this mess?
I am as frustrated as everyone that we seem to be circling around
something that has yet to gell into a comprehensible whole.
Rex
On 11/20/2016 3:49 AM, Mike Poulin
wrote:
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
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
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
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
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC
that generates this mail. Follow this link to all your TCs in
OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
--
Rex Brooks
Starbourne Communications Design
Email: rexb@starbourne.com
GeoAddress:
1361 Addison St. Apt. A
Berkeley, CA 94702
Phone: 510-898-0670
|