No, I need two for a pizza.
Or a pizza . . .
On 12/19/2016 3:59 PM, Ken Laskey
wrote:
I am not proposing this as a well thought out metric, but if the
optimal team size is 5.4 persons (or something around that) and
Conway’s Law says the software product mirrors the organization
that creates it, and microservices emphasize bounded context (i.e.
the scope), then does this tell us something about service
granularity/size?
Or maybe it’s time for another cup of coffee.
Ken
Hi All,
I havea couple of comments to Ken's
and Bob's notes.
@Ken
<<Microservices and business
talks a lot about the old SOA aligning with
business. I think this makes a lot of sense as
long as you look at business in the broadest
context and realize most deliveries are an
amalgamation of businesses.>>
The exceptional value of our RAF is
that it allowes formulation of Business SOA with
no changes in the specification. When you go this
way as I did, a statement "the old SOA aligning
with business" becomes a tautology: any business
organisation is the old, classic SOA by definition
and construction, and there are no exceptions for
centuries from this rule.
You will be the firts if you can point
to any business organisation in the world, which
would not use orientation on service to its
customers (including the non-profit and Government
organisations). Orientation on serviceis is one of
the fundamental principles of capitalism.
@Bob
<<"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.">> This exact
idea has been described in my book "Ladder to SOE"
in 2009. This is about new service-oriented
organisation of business with no vertical
command/accountability subordination lines. In
essence, such organisation is an "internal market"
(from that book) that has shared source of funding
and should be inthe constant competition with
analogous external services/providers. The
described model was about normal regular services
while internals of those service - what they were
built of - was immaterial (microservice,
miniservices, nanoservices, or anything else).
<<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.”>>
This is only 50% true. If the <<larger team sizes>>
would be used as a basic size they were either
end-up in the decompositions into the smaller size
services _or_ nothing wrong would come from them:
a service/functionality decomposition is the
natural business process and it stops when the
smaller (more granular) functionality does not
make sense for particular business model _or_ the
current (a bit less granular) size is OK because
it serves the needs of the business model of the
organisation already. Moreover, saying that it
<<would
not have given them the same ability to
experiment, adapt, and ultimately keep their
customers happy>> is fundamentally
wrong: there is no universal scale to compare
granularity of servives, i.e. size of the teams,
because each organisation has its optimal smallest
size of 'basic' services (and it depends on the
corporate business model, chosen corporate
strategy and market dynamics).
Also, I believe that the author has
omited the second part of the organisation based
on services: it is impossible to stay in the
market on the basic services only - the services
usually need to be dynamically re-composed into
bigger less granular combinations for solving
current market tasks. These tasks change more and
more dynamically nowadays and this leads to
creation of dynamic mid-size service compositions,
which than composed in the products for internal
and external consumenrs. As a result, the middle
and even top level management appears in a
constant movement where positions/roles exist only
until corresponding coarse-granualr compbination
of basic services is needed to habdle the market
state. [As you, probably, have noticed, this
explanation deviates from IT and filly replicates
SO into Business. This is what I write since 2012
and mean when referring to COS. ]
Cheers,
- Michael
My first thought in seeing
“miniservices" was they’ve found a way to
equivocate to the worst of all worlds.
There may be goodness here but it will take
more than a Gartner broad brush to make that
clear.
The underpinning of Conway’s
Law is people do what is familiar, whether
that’s a go idea or not. Conway’s Law is
a rationale for change throughout an
organization and not just in selective
spots.
Packaging of microservices is
an enabler of a lot of other stuff folks
want to do. There is a packaging
component to structure development and
delivery. Microservices and business
talks a lot about the old SOA aligning
with business. I think this makes a lot
of sense as long as you look at business
in the broadest context and realize most
deliveries are an amalgamation of
businesses. IT infrastructure is a
legitimate business in an organization
delivering software even if it doesn’t
directly reflect the money-making products
the organization produces. Middleware
fails the money-making business when it
becomes a disconnected business itself.
Until tomorrow.
Ken
------------------------------------------------------------------------------
Dr. Kenneth Laskey
MITRE Corporation, M/S F510
phone: 703-983-7934
7515 Colshire Drive
fax: 703-983-1379
McLean VA 22102-7508
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.
“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.
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
|