Reuse

[Ken Laskey <klaskey@mitre.org>]

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