You’re in the early stages of developing a few net-new cloud-based inventory and supply chain management systems. In the first few meetings, you start to feel uneasy: Technology is being discussed way too early in the process. The signs are unmistakable. Your team is not focusing on core requirements or defining the business case. Instead, people are talking about newer technology trends, such as containers and serverless.

I’m picking on these technologies specifically, but it could be any technology for that matter, including generative AI, edge computing, or any new topic spotlighted at the last cloud vendor conference. The concern is not that you’re picking technology—that must happen at some point—you’re doing so too early in the process and you’ll likely make underoptimized decisions, focusing too much on the end-state technology solution rather than on requirements and business value.

So, assuming that the focus is on presolving the problem using these technologies, here are a few issues that teams need to consider.

Limited use cases mean that containers and serverless technologies are well-suited for certain types of applications, such as microservices or event-driven functions. But they do not apply to everything new. Legacy applications or other traditional systems may require significant modifications or restructuring to run effectively in containers or serverless environments.

Of course, you can force-fit any technology to solve any problem, and with enough time and money, it will work. However, those “solutions” will be low-value and underoptimized, driving more spending and less business value.

Complexity is a common downside of most new technology trends. Container and serverless platforms introduce additional complexity that the teams building and operating these cloud-based systems must deal with. Complexity usually means increased development and maintenance costs, less value, and perhaps unexpected security and performance problems. This is on top of the fact that they just cost more to build, deploy, and operate. 

Managing container orchestration frameworks such as Kubernetes or dealing with the intricacies of serverless function deployments is challenging. These innovations may be worth the challenge, especially considering the business value that they can bring, but only in some cases.

Vendor lock-in seems more of an irrational fear nowadays, but it’s still a thing. Each provider has unique features, such as APIs, languages, and deployment methods. You build your application tightly coupled with a particular platform, so migrating to another provider or adopting a different technology stack in the future may require significant rework and investment.

The upsides should be considered with the downsides, always in terms of how any technology fits with the core business requirements. Too often we let business realities take a back seat to chasing new technology, which is a problem. I’m picking on serverless and containers since they are misapplied more than any other technology these days, and the result is much less value that is returned to the business.

These technologies do meet many business requirements, but they don’t solve all business problems. No technology does. Cloud architecture is about configuring technology to return fully optimized value to the business. We must work from the business problem to the solution. Any deviation from that process, such as picking technology too early, ends up with new technology in place but horrible business value.