Ken, Martin,
This is turning into an interesting conversation,
and one that needs to be made outside of the app
provider/paas context. Their self-interest tends to
get in the way. I think that's why our ongoing work
on SOA is relevent and, to use Ken's metaphor, the
kitchen may need to be remodeled.
I think the key issues revolve around ownership
boundaries and governance, hence the difficulty with
maintaining data integrity across concurrent
micro-service iterations housed in containers in
differing execution contexts, ie. public v. private
clouds, inter-enterprise infrastructure,
governmental systems. I can foresee data service
providers coming into existence to service these
cross-environment apps/microservices that use common
datasources.
I also look forward to hearing from a
micro-services developer.
Rex
On 5/30/2016 8:50 PM,
Martin Smith wrote:
Ken -- Always good to open the aperture:
referring to your idea of moving the app to the
data, etc.
However. You identified one requirement for
making this work: very robust
config/patch/revision control to keep all the
copies of the code in synch. Not trivial.
Backing further up the development process I
think there's another hard problem: where do the
requirements for the micro-service come from? Is
the motivation for someone to make a
micro-service to meet the needs of a single,
specific containerized application? If so, it
seems a remote possibility that that
specification would closely meet the needs of
other applications. Result: minimal re-use,
unless the whole application is copied. (I admit
I am assuming what provides the motivation for
creation of a micro-service.)
I keep thinking: how does someone creating a
micro-service differ from someone adding a new
function to an open-source project on Github?
The latter seems more valuable both because it's
likely to be written in contemplation of re-use
by others, and also the code is probably more
efficient because it probably uses in-process
communication vs. sockets.
Looking forward to hearing from a
micro-services developer!!
Martin
PS--Also just starting to noodle around with
AWS Lambda ("serverless" framework.)
--
Rex Brooks
Starbourne Communications Design
Email: rexb@starbourne.com
GeoAddress:
1361 Addison St. Apt. A
Berkeley, CA 94702
Phone: 510-898-0670