[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [soa-rm] Microservices re-use?
Doing a bit more reading, a consideration could be whether it is easier to move the data to the processing or the processing to the data.In our work on describing SOA, we assumed crossing ownership boundaries was a critical part of the paradigm: the consumer used services where they were offered rather than having a private copy. Part of the rationale was that private copies held by consumers (who were effectively also forcing themselves to be providers) often meant enumerable modified copies that became one-of-a-kind albatrosses to maintain. Under the SOA paradigm, the consumer and provider interacted under agreed upon terms (the execution context) with neither under the other’s control. (What control really existed before is another topic for discussion.)But with VMs and containers, we should be able to manage exact copies, including making sure the copies have a known, controlled configuration. So now if I generate terabytes of data a day, it may be more efficient to bring the processing to the data rather than the data to the processing. My configuration management makes sure the “manifest” for the new VM/container is up to date at all needed locations, and things like applications needing to be deployed are already pre-staged to any place that may need that application.What does this say about deploying on-premise infrastructure vs. cloud vs. what combination? What SOA principles are still useful to guide us? The house of the SOA paradigm may still basically function but it may need to have the kitchen remodeled.KenOn May 25, 2016, at 10:58 AM, Martin Smith <email@example.com> wrote:This is a request for input on how re-use is accomplished in the microservices world. Please provide info or comment via this list or via the public comment list for this TC: firstname.lastname@example.orgPlease also pass this request to others in your network who may have microservices implementation experience.In the April 13, 2016, meeting of the TC there was a discussion of comparison of characteristics of SOA architecture/design principles vs. "microservices" architecture (with specific reference to NIST Special Publication 800-180 (DRAFT) NIST Definition of Microservices, Application Containers and System Virtual Machines of Feb 2016.)One issue discussed was how re-use is accomplished in a microservices-style implementation.It was suggested that the NIST SP seemed to imply that a microservice instance is confined inside a single container. If so, this would be a significant distinction from an “SOA-style” service, in that it would mean that the only way a microservice could be re-used outside the container would be to copy the code and run an entirely separate instance in another container or elsewhere. This “confinement” also implies that microservces are not “multi-user” (or “multi-tennant”) whereas multi-tenant capability might be considered an intrinsic characteristic of SOA-style services. These apparent characteristics of microservices would seem to give away most of the potential efficiencies of a scaleable, easily maintainable shared service.Can anyone with microservices implementation experience explain how re-use is accomplished in this architectural style?Martin