Cloud-native apps don’t have to stay DRY

Reuse has been a battle cry of developers since I was a lowly COBOL programmer back in the 1980s. Then we defined functions that could be called many times, and the structural programming age was born.

We then drifted to other languages such as C and the object-oriented C++ as better ways to build on the notion that reuse is good. Next we moved on to distributed objects and SOA (service-oriented architecture) services where reuse grew out of single applications, and then to reusable services that are loosely coupled and reside on different platforms. Now we have the notion of cloud services or APIs and the compelling concept of microservices providing a new granularity of sharing. Whew!

Reuse and/or sharing has taken on a new meaning for cloud and noncloud developers. Many are using the acronym DRY or “don’t repeat yourself,” as their new slogan for building and deploying applications and systems in 2022. However, it’s not as easy as that.

I’ve made two different mistakes when building service-based applications over the years: too much reuse and not enough.

How can you have too much service reuse? It’s when any productivity from using the same services repeatedly diminishes or is even negative. An example would be leveraging services that have to be abstracted and some of their functions changed in order to meet the needs of an application. For example, using a service that accesses customer credit data with all customer information but removing most of the common data back in a response set or a data stream since it’s not needed for this particular purpose within the application.

I’m seeing more of these kinds of hacks that force-fit the reuse. Application development is becoming a mix of services being reused, whether they should be or not. Moreover, these inefficiencies are often overlooked in code reviews and code scanners that don’t yet consider that some reuse could be less than productive. I’m sure some of you who sling code more than me are worried about the reuse baby being tossed out with the unproductivity bathwater, but I’m not saying go back to building services and microservices that are only leveraged once.

It comes down to understanding the trade-offs of leveraging reusable services, including how they should be designed and deployed. The core questions are: Is reusing these services going to make my application better? Should the service I’m reusing be redesigned and deployed? Or should I create a new service that’s purpose built?

You’ll find that it’s often more productive to take different routes, having a bit more of an open mind around what services should be reused. More importantly, learn to recognize when you’re attempting to force-fit a popular philosophy. I’ll take productivity over going along with the crowd any day.