[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: RE: [soa-rm] compact blurbs on microservices
Hi Mike, I was formulating a response to Ken’s query _on behalf of_ a hypothetical microservices evangelist … i.e., adopting the mindset of such a person … in that context, I believe
that the definition I offered holds. We can disparage it all we want, but if the hyperscale players continue to optimize for the packaging benefits of the microservices model along the Agile/DevOps movement, we might
have to accept it and make the best of it … which certainly offers new opportunities for SOA and COS principles, designs, etc. IMHO. Avanti, BobN From: Mike Poulin [mailto:mpoulin@usa.com]
Wow, Bob! if I do not use any - no one microservice, I do not have an application do I? The statement "An application is a composition of one or more microservices and other implementation mechanisms that provides a coherent grouping of business functionality.”That’s
quick n’ dirty... "- no, is not dirty, it is shi..y! (Pardon my French) - Michael
Sent: Friday, October 28, 2016 at 3:52 AM Hi Ken, To you original query: “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?” … Taking the perspective of a microservices architecture evangelist, I’d answer “An application is a composition
of one or more microservices and other implementation mechanisms that provides a coherent grouping of business functionality.” That’s quick n’ dirty but conveys the sense as I understand (in the microservices context). Avanti, BobN From:
soa-rm@lists.oasis-open.org [mailto:soa-rm@lists.oasis-open.org]
On Behalf Of Ken Laskey 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 ------------------------------------------------------------------------------ |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]