Lesson 170 - Managing Code Reuse in Microservices

Code reuse is a normal and necessary part of software development. Shared functions such as logging, auditing, authorization, string utilities, data utilities, and the like are part of any architectural style-even Microservices. In this lesson I’ll talk about some of the issues surrounding code reuse in microservices, and show three techniques for code reuse and the trade-offs of each.
Reference Links:
Software Architecture Monday: bit.ly/3dadEe3
Fundamentals of Software Architecture: amzn.to/3rgFLjY
Software Architecture: The Hard Parts: amzn.to/3BjMMF2

[@krumbo]

How good are those lessons guys. You can see how he manages such a complex topic with simplicity. Real art IMO.

[@markrichards5014]

Thanks!

[@penaplaster]

The drawbacks of the last approach can be mitigated by running a shared code not as a single standalone service but as a sidecar for each service. This way, the added latency is negligible and the sidecar is scaled together with its main service (since the sidecar is the part of the service). This approach however increases complexity of the solution.

[@markrichards5014]

For infrastructure code (things like logging, authorization, metrics gathering, etc.) this is indeed another approach. However, generally you don't want to use business logic (e.g., common tax calculator) in a sidecar.

[@barrydev]

Thank you for your content Mark, it really is a joy to watch these complex topics covered so simply, I look forward to every new Arch Lesson episode 🙏
I'm just adding another layer here, but, as with most things in software, the sweetspot will generally be a combination of all these techniques, where you use each in a particular subdomain in a way that aims to maximise (never to 100%) their advantages and minimise (never to 0%) their disadvantages. The system's external forces will also change over time, so the weighting of the three approaches would also fluctuate over time, there's no "one right solution forever more", but a continual process of evolution towards the next, most valuable & achievable, outcome.

[@chachucoder8104]

The reuse pattern is generally considered as following from the least desirable to highly desirable in a huge microservices-based architecture. Code duplication -> Shared library -> Shared Service/API -> Side Car -> Platform

[@markrichards5014]

Again, it depends. I wouldn't say that a shared service is any more desirable than a shared library for the reasons I talked about in the video. It depends what's important to you (for example, ease of change vs. better operational characteristics) and what the tradeoffs of each are.

[@chachucoder8104]

@@markrichards5014- Yeah absolutely, I agree - It Depends. With the rise of the platforms, the reuse and the governance can be better enforced with platforms that can provide some standard consistent patterns and enforce governance built into them. Of course, it wouldn't be suitable for every team/organization and depends on the trade-offs that an architect should consider.

[@Kasukke]

@@chachucoder8104 What does Platform mean in this context? It sounds like a Platform is a group of services managed as a separate system.

[@kurito_]

Really easy to understand and put across very well!

[@sw9038]

Then how to choose the approach for code reuse?

[@markrichards5014]

It's all about analyzing your specific needs, and matching those to the pros and cons I outlined in the video.

[@aqilaghamirzayev1070]

What about if we collect all classes in one common library that uses all microservices ?

[@markrichards5014]

Generally when using a shared library you try to make it as fine-grained as possible to ease churn and change control. If you only had one shared library (common.jar for example), every time it changed or deprecated a version ALL microservices would have to be retested and redeployed.

[@aqilaghamirzayev1070]

Thank you @@markrichards5014