| The discussion began with the topics of service and service interface granularity. Microservices currently fit in that space. I am hoping we get back to divining conclusions.
Ken
P.S. Dial-in for tomorrow will be sent later today.
Folks, I see many observations and suggestions. What is the goal/purpose/target of the entire discusstion?
Regards,
- Michael
Moving this to full list.
Part of the benefit of SOA was to reuse resources built as services rather than copying code and getting a configuration nightmare or rebuilding from scratch and getting all the inefficiencies that produces. Using services in the SOA sense is enabled through interactions using a public interface communicating over network protocols rather than fine-grained coding to RPCs.
Microservices no doubt use the network-enabled interface but the question if the deployment uses containers is what gets packed into a single container. Is it a single service and composition happens across containers? If I have a saved image, is my service reuse in spinning up another instance of the image rather than having a network address somewhere in URI space? With SOA, we use services through the network address that exposes the service and don’t have a private copy. With microservices, what does the network address represent?
Stil wandering around the distinction and need to crisp up the questions.
Ken
Begin forwarded message:
Subject: Re: Microservices observations
Date: May 10, 2016 at 10:54:02 PM EDT
Also read the IRON.io paper and came to some additional observations. Was intrigued to read the Wikipedia article on Docker technology since it appears that microservices are, in a practical sense, dependent on new container technology making a more economical way to package microservices together in an application than a virtual machine unless you're doing Docker in the Azure Linux virtual machine on the Windows platform. The reduction in overhead makes combining microservices very attractive but it looks to me like each instance of a microservice or as many microservices as needed for a given application must live in its own application container with its bins/libs -- leading to some interesting questions for providers whose microservices must deliver the same level of performance across different apps within different containers on different servers/clouds/distributed environments duplicating all bins/libs for each microservice each time. Accessing independent databases makes for interesting complications if transactions in one app add/delete/change values in the databases accessed by other apps such as available credit in credit card accounts. Should make for some interesting discussions.
Cheers, Rex
On 5/10/2016 3:43 PM, Martin Smith wrote:
--
Rex Brooks
Starbourne Communications Design
Email: rexb@starbourne.com
GeoAddress:
1361 Addison St. Apt. A
Berkeley, CA 94702
Phone: 510-898-0670
|