Ken -- great, quotable find!
Comment on his logic, from the point of view of the "commercial
Cloud service provider" model of updated SOA:
1. Inevitable customization--AWS and others provide lots of
config options which apparently satisfy the needs of many
customers without getting into customer customization. The 80/20
rule presumably applies: most organizations will choose to work
with 80 of their ideal requirements met if it comes at 20% of the
cost of alternatives.
2. Re-use breakeven--Multi-tenant Cloud service providers have
apparently been able to have thousands-to-millions of re-uses of
their infratructure-type and utility (e.g. Google Maps) services.
3. Communication with other teams-- see 1. above. AWS/Azure don't
respond to individual requests, but on the other hand they do
publish their policies and APIs (in considerable detail) so no
communication is typically needed. (Presumably they do have
processes to respond to widespread customer requirements with
service enhancements rolled out to all customers on the providers'
schedules.)
4. More on communications--Minimizing coordination with other
teams-- internal teams working on the same application, as
oppposed to the external Cloud-service-provider team--seems like
an unhealthy principle that will likely create problems. After
all, there has to be some significant coordination on the
architecture of an app that's being developed by more than one
team.
5. And finally, quality--a service built by a commercial service
provider is likely to be better engineered than one produced by a
small team, especially when it comes to addressing non-functional
requirements like SECURITY. Plus, when a change is made in a
language library on which a micro-service is dependent, perhaps as
a result of a newly discovered security vulnerability or an
algorithm error, users of a commercial service will get the patch
"for free" (and likely quickly since lots of customers will be
complaining otherwise.)
Happy T-Day to all . . .
Martin
On 11/26/2019 4:20 PM, Ken Laskey
wrote:
In looking at the movement from SOA to
microservices, we have often found ourselves in the discussion
of where does reuse come in: SOA wanted reuse but microservices
seems possibly downright hostile to the idea. The discussion
that follows comes from âMonolith to Microservices by Sam Newman (OâReilly). Copyright 2020 Sam
Newman, 978-1-492-07554-7.â I got a full download free from
OâReilly.
--------------
Reuse?
Reuse is one of
the most oft-stated goals for microservice
migration, and in my opinâ
ion is a poor goal in the first place.
Fundamentally, reuse is not a direct outcome peoâ
ple want. Reuse is something people hope will lead
to other benefits. We hope that
through reuse, we may be able to ship features more
quickly, or perhaps reduce costs,
but if those things are your goals, track those
things instead, or you may end up optiâ
mizing the wrong thing.
To explain what I
mean, letâs take a deeper look into one of the usual
reasons reuse is
chosen as an objective. We want to ship features
more quickly. We think that by optiâ
mizing our development process around reusing
existing code, we wonât have to write
as much codeâand with less work to do, we can get
our software out the door more
quickly, right? But letâs take a simple example. The
Customer Services team in Music
Corp needs to format a PDF in order to provide
customer invoices. Another part of
the system already handles PDF generation: we
produce PDFs for printing purposes
in the warehouse, to produce packing slips for
orders shipped to customers and to
send order requests to suppliers.
Following the
goal of reuse, our team may be directed to use the
existing PDF generaâ
tion capability. But that functionality is currently
managed by a different team, in a
different part of the organization. So now we have
to coordinate with them to make
the required changes to support our features. This
may mean we have to ask them to
do the work for us, or perhaps we have to make the
changes ourselves and submit a
pull request (assuming our company works like that).
Either way, we have to coordiâ
nate with another part of the organization to make
the change.
We could spend
the time to coordinate with other people and get the
changes made,
all so we could roll out our change. But we work out
that we could actually just write
our own implementation much faster and ship the
feature to the customer more
quickly than if we spend the time to adapt the
existing code. If your actual goal is
faster time to market, this may be the right choice.
But if you optimize for reuse hopâ
ing you get faster time to market, you may end up
doing things that slow you down.
Measuring reuse
in complex systems is difficult, and as Iâve
outlined, it is typically
something weâre doing to achieve something else.
Spend your time focusing on the
actual objective instead, and recognize that reuse
may not always be the right answer.
-------------
Recall, we always said that one didnât typically see
a reuse savings with services until between the second and third
reuse of a service, so if reuse requires significant changes in
the original, you might always be chasing an illusion.
That said, Docker has public and private registries.
Why have a public registry if there isnât something somebody
has developed that someone else finds as value to reuse? Plus,
containers best practices emphasize trusted sources and scanning
what you reuse, something that didnât get enough attention in
the context of SOA reuse.
So, on considering this further, I say, âHmm!â
Ken
------------------------------------------------------------------------------
Dr. Kenneth
Laskey
MITRE
Corporation, M/S H330
phone: 703-983-7934
7515
Colshire Drive fax: 703-983-7996
McLean VA
22102-7508
--
Martin F Smith
BFC Consulting, LLC
McLean, VA
703 389-3224 mobile