Hi folks,
I attended a Gartner webcast on “12 Core Principles of Application Architecture for Digital Business and IoT” one day last week and the speaker made some interesting remarks about
microservices architecture (and this generally relates to section 3 of the presentation … I can provide a copy of the deck to those who might need/want it). He emphasized the packaging construct with special reference to the hyperscale service provider class
where the pace of innovation requires them to deliver “dozens to hundreds of times per day” … he noted that “microservices are all about agility, autonomy, and discipline” in that context, at least. He argued that not many organizations are in the hyperscale
category and others should focus on “miniservices”, which resemble microservices but with “limited autonomy” support relative to microservices in the hyperscale context. Beyond that, neither the voice track nor the slides provided sufficient detail to distinguish
the two.
At about the same time, I read an interesting article (https://www.thoughtworks.com/insights/blog/demystifying-conways-law)
that included the following addressing the microservices logic for hyperscale service providers:
“Organizations for a few years now have understood this link between organizational structure and software they create, and have been embracing new structures in order to achieve
the outcome they want. Netflix and Amazon for example structure themselves around multiple small teams, each one with responsibility for a small part of the overall system. These independent teams can own the whole lifecycle of the services they create, affording
them a greater degree of autonomy than is possible for larger teams with more monolithic codebases. These services with their independent concerns can change and evolve separately from one another, resulting in the ability to deliver changes to production
faster. If these organizations had adopted larger team sizes, the larger monolithic systems that would have emerged would not have given them the same ability to experiment, adapt, and ultimately keep their customers happy.”
The article goes on to note:
“… the growing popularity of Microservices, which are increasingly being adopted by organizations looking to improve the autonomy of their teams and increase the speed of change
… these architectures allow organizations much more flexibility in aligning the architecture of their systems to the structure of their teams in order to ensure that Conway’s law works for you.”
So, I’ve expanded my view about the drivers behind a shift to microservices architecture to include not only the packaging aspect but its connection with operations and organizational
structure/communication as well.
From: soa-rm@lists.oasis-open.org [mailto:soa-rm@lists.oasis-open.org]
On Behalf Of Ken Laskey
Sent: Friday, November 25, 2016 6:21 PM
To: Natale, Bob <RNATALE@mitre.org>
Cc: Mike Poulin <mpoulin@usa.com>; soa-rm@lists.oasis-open.org
Subject: Re: [soa-rm] compact blurbs on microservices
Still need to get some clarity on reuse. I am concerned that we’ll see benefits in the short term but end up with an unwieldy set of near duplicates when there is no time invested to discover if someone else has already solved your problem,
especially when their solution will be better than yours.
To what extent is MS just packaging and reuse is you spin up a copy of my machine image so you get to use my solution while avoiding the remote networking overhead? The challenge is for me to notify you when I change/update my image and
then you staying in synch with me to the extent that updating is necessary and provides you value.
Ken
------------------------------------------------------------------------------
Dr. Kenneth Laskey
MITRE Corporation, M/S F510 phone: 703-983-7934
7515 Colshire Drive fax: 703-983-1379
McLean VA 22102-7508
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.
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)
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).
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.
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?
------------------------------------------------------------------------------
Dr. Kenneth Laskey
MITRE Corporation, M/S F510 phone: 703-983-7934
7515 Colshire Drive fax: 703-983-1379
McLean VA 22102-7508
|