“Serverless myths” could also be described as “modern cloud myths.”
We have highlighted myths that we have excerpted from the book The Value Flywheel Effect. They also apply to a containerized, microservice, event-driven solution. The very nature of the cloud means it practically redefines itself every three to four years. The “old stuff” doesn’t go away, but new things come along, and cloud providers fix the problems of yesteryear behind the scenes.
Why do serverless myths exist?
The constantly evolving landscape makes it hard to keep up with good practices as goalposts continuously shift. The myths presented here are either old issues that have since been addressed or were simply the result of a lack of knowledge by an engineer who has yet to keep up. Remember, two of the most challenging situations in software are a very experienced engineer with a legacy skill set and a very inexperienced engineer with a modern skillset. You need both the scars and the curious mind.
Engineering/Technical Myths
Myth: Serverless has a cold-start problem. We can’t afford slow performance in our system.
Engineer or architect
Context:
When you own the server, it runs 24/7. When someone makes an API call, the code is ready to execute. However, the cloud provider only primes the code once serverless technologies call the API. Sometimes, this causes a slight delay for the first call (known as a cold start). But once the “pump is primed,” there’s no delay for subsequent calls (warm start). Public cloud providers are constantly working to reduce the cold-start time. How you write and configure your code also has an impact.
Impact:
Every technology has pros and cons. Cold starts are no longer a concern in the way they were in the early days of Lambda and function as a service. Cold starts are a solved problem, so this myth is incorrect. Serverless may not be the correct architectural choice, but not because of cold starts.
—
Myth: Serverless is impossible to test since you can’t run it locally.
Engineer
Context:
“It worked on my machine!” said every developer, always. Replicating a production environment on a local laptop has always been desirable. The developer can test and push the change straight to production, right? Wrong. You cannot replicate “the cloud” on your laptop.
Impact:
Software verification is complex and requires a different strategy than traditional unit testing. The system under test lives in the cloud and should be tested in the cloud; verification requires an alternate approach designed by experts. “Running everything locally” is a lazy option and problematic. Efforts to run functions locally can help developers, but it’s not the answer.
—
Myth: You can’t see what’s happening with the modern cloud. You don’t know what’s running.
Engineer
Context:
Many traditional monitoring approaches involve installing an agent or specific software in the application. As you cannot access the underlying system, this may only work for some modern cloud solutions. You must trust what’s happening.
Impact:
This inertia point happens when you fail to embrace the cloud as a platform. To use the cloud correctly, you must also use an event-driven monitoring system, not an execution monitoring system. In many cases, the modern cloud platform has more data about the system available—it’s just a matter of approaching observability differently.
—
Architectural Myths
Myth: Serverless/Kubernetes is not the next big thing; it’s technology X. I read a report that backs this up. Besides, our skillset matches technology X.
Architect
Context:
At a time of change, if your architect has not stayed relevant, the architectural advice may be, “Let’s not move to the new technology; we’ll use the next version of our current technology.” Consultants are also likely to give similar advice.
Impact:
Even though it is excellent advice for short-term goals, looking at the long-term picture is more important. It’s worth mapping out the next five years of expected expenditures and deciding how much investment will go to training, development, operations, infrastructure, etc. Today, taking the hit on simplification and upskilling may have a much better return on investment than business as usual.
—
Myth: We don’t want to lock into X cloud provider. If we use their services, we can never change providers.
Everyone
Context:
There are two essential terms to explore here—multi-cloud and cloud agnostic. Multi-cloud should be a typical strategy for a company. For example, many companies have office products running on Azure and workloads running on AWS, which is multi-cloud. The cloud should be treated as a suite of services—from different vendors—and you use your best service. Cloud agnostic means you create a software component that can run on any cloud. Usually, this means building on an open-source platform, which the cloud provider supports.
However, you may be unable to use some of the cloud provider’s features. There is a widely held opinion that engineers should write code in a cloud-agnostic manner to switch to Provider Y if Provider X hikes up their prices. It’s like saying, “I won’t drive a car because fuel prices might increase. I’ll just walk everywhere.” It sounds sensible, but it’s entirely impractical.
Impact:
First, the leading public cloud providers have a record of consistently lowering prices. Second, the goal of your software should be to solve significant problems for your business. Let’s take two scenarios:
Scenario A:
To avoid being locked in, a company spends one million dollars extra. If something ever happens, they can change cloud providers. There’s a very high chance that they will never change cloud providers.
Scenario B:
The company uses the higher-order services in the cloud (including serverless). They ship six months ahead of scenario A and save one million dollars. If something happens, they have a loosely coupled, well-designed system and can move quickly to adapt to new scenarios.
—
Myth: We are different. We’ll create custom standards to keep quality high.
Architect
Context:
Some architect teams believe that a provider still needs to solve their problem. Usually, a provider has solved their problem. The architect just hasn’t researched appropriately.
Impact:
Use industry standards. They are public, hardened, and understood by all. Custom bars must be created and communicated; teams must be trained and maintained. It’s rarely worth the extra effort.
Engineering Management Myths
Myth: “Serverless/autoscaling is more expensive; there’s no control over the costs.”
Architect
Context:
In this case, the architect has likely tried serverless previously or read about a project that generated a large cloud bill. Many cloud implementations, unfortunately, fall victim to poor cost optimization. To avoid this, you’ll need to have the ability to predict traffic and cost. If there is an unexpected lift in traffic, this should mean more users—which is good.
Impact:
Create a coherent cloud management strategy to ensure that your system can handle increased traffic and costs at a proportional rate.
—
Myth: The engineers won’t do what I tell them to.
VP of Engineering
Context:
The serverless paradigm demands teams that move fast. This VP has probably not worked in a technical environment before (unless they come from a big tech company). Making teams move in a pseudo-waterfall manner, with all their work planned out, will frustrate the developers. Give it whatever Agile buzzword works—SAFe, program increments, limit WIP, protect the team—but the impact is the same. We can micromanage the team and force them to make lousy technology choices, even in Agile. But we’re hiring professional engineers; let them own their problem space.
Impact:
If the engineers are skilled in serverless, give them a behavior or outcome to create—resist the temptation to specify every class or function. Great engineers need to be empowered. Don’t slow them down.
—
Myth: Our engineers and our business are not connected.
VP of Engineering
Context:
Engineers must deal with high cognitive load. The connection to the business offers the best insight into the needs. If the engineers don’t seem interested, it may be because it’s hard for them to determine their next move. Do they have the metrics they need? Is there a clear purpose to their work? Are they included in the crucial discussions and decision-making? With some large-scale agile frameworks, the teams are so busy with agile ceremonies that they don’t have the time to connect with the business.
Impact:
If engineers don’t have clarity of purpose, they will likely build the wrong thing.
—
Myth: Technology X worked like a charm for me in my last role. Let’s use that instead.
VP of Engineering
Context:
You should assess every project and problem with context. Unthinkingly using what worked before is only sometimes a good strategy.
Impact:
Architecture is about risk mitigation. Failing to modernize technology is a considerable risk. Support architecture to create and describe the technical strategy—including pros and cons.
—
Myth: We only work on the cool stuff.
VP of Engineering
Context:
A team has explored new technology and doesn’t want to return to the old one. This opinion is often misinterpreted by engineering management. Sound engineers should own the problem and use whatever technology makes sense.
Impact:
The engineering management should not be dictating technology, nor should the technology be dictated to them by engineers. Technical leadership needs to be involved, empowered, and driving the technology decisions.
Organizational Myths
Myth: We are under capacity.
VP of Engineering
Context:
Headcount allocations have been made, and more is needed. The main topic of engineering management discussions is the need for more resources.
—a tell-tale sign of an insufficient focus on the work.
Impact:
Building an empire does not drive business outcomes. If a team is given ownership of the problem and has an adequate number of people, they will find a solution. Good serverless teams should only need a few people if set up correctly.
—
Myth: Security is blocking serverless.
Engineering
Context:
There is a complex security monitoring system, and serverless is not supported. The engineers feel serverless is a good choice, but security will not approve of the new technology.
Impact:
The process implemented is blocking progress. Both engineering and security should revert to the control and reimplement the process with a serverless-friendly approach. Likely, the previous process is not cloud native.
—
Myth: Our financial model does not support OpEx.
CFO
Context:
The financial model was designed with CapEx, assets that depreciate over time. A variable bill every month makes the numbers look bad.
Impact:
It’s not a serverless problem; it’s a blocker for cloud adoption. The focus needs to switch to the additional revenue the cloud will generate.
—
Myth: We spent two years building X. Was that a waste of money?
Stakeholder
Context:
When you decide to build something, what you learn during the build is often more important than the build itself. We need to acknowledge and understand this fact. And we must view Technology as a throwaway.
Impact:
Holding on to previous investments with no additional value is a considerable expense.
—
Myth: Consultancy X will engage for twelve weeks and set direction.
Stakeholder
Context:
A consultancy house starts an open-ended project with limited business outcomes that could last for years. Often, consultants are used to creating internal alignment rather than advising on outcomes.
Impact:
Own your technology and business strategy. Getting an evaluation from external parties is essential, but don’t relinquish control.
Originally published by IT Revolution.