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