In nature, there are producers and consumers. (There are also decomposers, but that’s food-chain for thought, which we’ll leave for another day.) Producers make their own food, using energy from the sun. Consumers get their energy by eating producers or smaller consumers. In business, we have to be both a producer and a consumer. As Peter Drucker said, we have one goal: to create a customer. Stated another way, we have to choose where we can and should provide value to customers. All our competitors are trying to do the same thing.
To succeed, we must have a bias toward consumption.
What? What’s wrong with being a producer? You can create your own code in exactly the way you want it, to suit your organization’s specific needs. You can handcraft every line so that it meets all of your user and workload needs. You can refine it to the point where there are no bugs or errors.
Oh, wait. This is the real world, where developers are pulled in a dozen (at least) different directions at any one time, with requirements and demands changing constantly. Even if you could make the code perfect, the moment would be fleeting—because the world would change around that perfect code and make it obsolete. Perfect code exists in a perfect world—a world no organization is living in. As a wise programmer once said, “Right after I am finished, I love every piece of code I have ever written. Days or weeks later, I hate it. I hate every piece of code I have ever written.”
More important, that code you seek may already be written, maintained, and packaged by somebody else. A while back, Joe Beda had a really good quote—in a tweet he said, “as engineers, we tend to discount the complexity we build ourselves vs. complexity we need to learn.” This is especially good advice in the age of containers, which are the new baseline piece of infrastructure you need to manage—whether managing your own homegrown code, exposing APIs, or connecting to remote services. Containers are everywhere.
So, you need to fight the want to invent and have a bias toward consumption. I’m not saying that you should never write your own code. In fact, there are lots of good reasons for being a producer, but that’s a column for another day. What I am saying is that you shouldn’t underestimate the value of learning how to use value that has already been created and is maintained by somebody else. In other words, if there’s a service, API, container image, RPM package, or open source library available for consumption, consume it; don’t produce it. I listed those in order from most convenient to least convenient—but don’t confuse convenience with price. Nothing is free.
How do you find that container image and ensure that it is the right fit? Here are some recommendations for being the best kind of consumer:
- First of all, get over yourself. I say that with love, but too many organizations are stuck in the thinking that homemade is better. But, think about it: Even Ina Garten buys bread. She could make it herself, but making bread is a lot of work. Ina knows that there are people out there whose job it is to make really, really good bread. “Consuming” that bread (in this case, literally and figuratively) rather than producing it leaves Garten time to do things like entertain her fabulous friends and write cookbooks. It’s the same with code: If someone is creating quality code for a function you need, why would you develop it yourself?
- Next, analyze all the upstream options. Find the right technical solution first; worry about financial cost second. Some code can be consumed for free, while some will come at a cost. Regardless, it’s critical to evaluate the value proposition of the commodity that’s available. Perhaps you can consume code for relatively low (or no) cost, but at what cost to your time (or to your customer’s time)? Conversely, higher-quality code may come at a higher cost. Is it worth increasing the price of your product to include the higher-quality code? Or can the cost of consuming be negotiated? Striking the cost/value balance is challenging, but it’s key to your success as a consumer and producer in a value supply chain.
- Is the code compatible with existing systems? Linux containers, for example, are designed to be portable, but just because something is portable does not mean it is compatible with everything. Portability and compatibility are two separate design principles. Linux container images include a collection of libraries and binaries specific to the hardware architecture and OS. The binaries inside the image run like they would any Linux OS, so there must be compatibility between the container image and the container host. Incompatibilities can lead to performance and security issues—either of which would totally negate any gains made from consuming in the first place.
- Is the code in line with your organization’s (and industry’s) growing list of regulatory requirements? (GDPR, anyone?)
- Find a trusted source for the code and verify its provenance. There are plenty of examples of people sneaking bad code into trusted places. The xCodeGhost and the latest DockerHub Miner Virus come to mind.
In the end, prebuilt code and images make it easier to faster to deploy applications, freeing up resources for other tasks—but only if the code meets compatibility and security requirements.
This article is published as part of the IDG Contributor Network. Want to Join?
