[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [soa-rm] Reuse
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Â
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]