All collaborations are transactional, which means that something has to act as the currency. It could be prestige, dollars, or respect. If you want to buy a vacuum cleaner from Target, for example, you can use your Target Red Card, Apple Pay, a bank debit or credit card, check, cash, or several other forms of payment. There are just as many ways for organizations to "buy" software components.
APIs, functions-as-a-service (a.k.a. serverless), containers, and open-source libraries are all forms of currency that you can use to "buy" the building blocks of software. Here's why one of these should be your go-to currency of choice.
The four currencies of software
As in retail, some forms of currency are preferred over others. It goes something like this:
- If you need software for a technology project, go find a function.
- If the function doesn't exist, go find a container.
- If the container doesn't exist, go find an open-source library.
- If there's no library, go write the code yourself.
There's a bias in this progression toward consumption. Functions are easier to consume than open-source libraries, and consuming them is way easier than writing and maintaining code yourself.
With serverless, events trigger application code to run, and a cloud provider dynamically provisions resources for the code to run. When your code finishes executing, the "meter" stops running until you need to execute the code again.
These serverless functions are quite similar to an external API consumed from a service catalog, operating very much like a tool rental store. One of the biggest concerns about serverless is the threat of vendor lock-in, but the technology, as currency for code, is promising, especially when it's strategically integrated into a cloud-native stack.
Which brings us to containers. Containers are in a sweet spot and work well as a unit of consumption. A container can provide all of the code for a function. Or it can provide prepackaged open-source libraries, or even homegrown code that was written in-house. Containers are more of a packaging system than anything else and are used to underlie FaaS, although they can be consumed standalone as well.
But what if nobody has packaged the library you need in a container? You surf GitHub until you find something that meets your needs. Then you can package it in a container yourself and list it in your own internal service catalog so others can build on it and consume it. This requires more work than consuming a prebuilt container, but it also has the advantage of being consumable downstream in the supply chain.
And what if an open-source library doesn't meet your needs? Then you can extend an existing one, or write code from scratch. This is the most expensive option, which is why I've listed it last. In this case, a developer would need to write some code, package it in a container, and list it in a service catalog.
Containers are the new baseline
Are you noticing a pattern yet? You can use containers whether you are consuming a prebuilt function/API, consuming an open-source library, or writing a piece of homegrown code.
This makes them the go-to currency for collaboration in any cloud-native environment. As you work your way down from all prebuilt functions to homegrown code, there is a tradeoff between power and flexibility. Containers stand out as the best compromise between power and flexibility.
Linux containers are the baseline infrastructure element that will help you do everything from improving your own homegrown code to creating serverless functions to connecting remote services.
Containers allow organizations to package and isolate applications with their entire runtime environment—all of the files necessary to run—making it easy to move containerized applications between environments while retaining full functionality.
Also, containers help reduce conflicts between development and operations teams by allowing them to focus on what each does best. Developers can focus on their apps, and operations can focus on the infrastructure.
In this era of having to constantly innovate in order to compete, this is the kind of virtuous cycle organizations can get behind—and one of the things driving the serverless model of consumption.
Stay agile: Use it, don't produce it
Of course, even with all of the ways you can "purchase" code, there are times when it makes sense to build your own. Sometimes the thing you need simply does not exist, and thus you need to create it yourself.
But staying agile depends on staying smart, and one really smart (and pretty easy) thing companies can do is focus all parts of the organization on consumption. When there's a choice for consumption—whether it be a service, API, container image, RPM Package Manager, open-source library, or something else—use it; don't produce it.
Of course, not all code or containers are created equal. Furthermore, some options are free, while others will cost you. When exploring your options, put quality over cost. You may be able to consume code for low to no cost, but it may cost the company time if the code is poorly written. High-quality code can also have cost repercussions if you have to raise the price of a product because it cost you so much to put it together.
It's also important to ensure that any code you consume is compatible with existing systems. Linux container images, for example, include a collection of libraries and binaries specific to the hardware architecture and OS. The container image and the container host must be compatible. If not, you might experience performance and security issues.
In terms of security, you are as secure as what you consume—and the wrong choice can cost your business big time. Make sure your source of code is trusted, and double-check by verifying its provenance.
Software is the ultimate currency
In today's high-pressure, high-stakes business environment, software is the ultimate currency. The faster you can respond to and anticipate customer demand, the better positioned you will be for growth.
And, just as store-bought pie crust will let you focus on the filling as a value-add—and perhaps on also churning out an apple pie and a pumpkin pie to meet the demands of Uncle Joe and Aunt Sue, respectively—so, too, can Linux containers help companies optimize their investment in code and constantly innovate to meet customer demand.
Keep learning
Choose the right ESM tool for your needs. Get up to speed with the our Buyer's Guide to Enterprise Service Management Tools
What will the next generation of enterprise service management tools look like? TechBeacon's Guide to Optimizing Enterprise Service Management offers the insights.
Discover more about IT Operations Monitoring with TechBeacon's Guide.
What's the best way to get your robotic process automation project off the ground? Find out how to choose the right tools—and the right project.
Ready to advance up the IT career ladder? TechBeacon's Careers Topic Center provides expert advice you need to prepare for your next move.
