Serverless Myths

The term “serverless myths” could also be “modern cloud myths.” The myths highlighted here (which have been excerpted from the book The Value Flywheel Effect) 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 the problems of yesteryear are fixed behind the scenes.

The constantly evolving landscape makes it very hard to keep up with good practices, as the goalposts are constantly shifting. 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 not kept up. Remember, two of the most challenging situations in software are a very experienced engineer with a legacy skillset 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. But when you’re using serverless technologies, the code is only primed once the API call is made. 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 the change and push it 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 involved installing an agent or specific software in the application. This doesn’t work for many modern cloud solutions, as you have no access to the underlying system. 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 properly, 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 is better matched to technology X.”—Architect

Context: At a time of change, if your architect has not stayed relevant, then 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: This is excellent advice for short-term goals, but it’s more important to look at the long-term picture. 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 upskill may have a much better return on investment than business as usual.

—

Myth: “We don’t want to be locked into X cloud provider. If we use their services, we can never change providers.”—Everyone

Context: There are two essential terms to explore here—multicloud and cloud agnostic. Multicloud should be a typical strategy for a company. For example, many companies have office products running on Azure and workload running on AWS. This is multicloud. The cloud should be treated as a suite of services—from different vendors—and you use the best service you can.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. Of course, many of the cloud provider’s features cannot be used. There is a widely held opinion that engineers should write code in a cloud-­agnostic manner so that they can switch to Provider Y if Provider X hikes up their prices. It’s a little like saying, “I won’t drive a car because fuel prices might go up. I’ll just walk everywhere.” 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 important 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 ever 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 the problem they have has never been solved before. Usually, it has been solved—they just haven’t researched appropriately.

Impact: Use industry standards. They are public, hardened, and understood by all. Custom standards need to be created and communicated; teams need to 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 an increase in traffic and increase your 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 are disconnected from the business.” —VP of Engineering

Context: Engineers must deal with high cognitive load. The connection to the business offers the highest insight into what needs to be done next. If the engineers don’t seem interested, it may be because it’s hard for them to find out 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: Every project and problem should be assessed with context. Blindly using what worked before is not always 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 some new technology and doesn’t want to go back to old technology. This opinion is often misinterpreted by engineering management. Good engineers should own the problem and use whatever technology makes sense.

Impact: The engineering management should not be dictating technology, nor have 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 they are not enough. The main topic of engineering management discussions is a lack of 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 not need many people unless they are set up wrong.

—

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 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: This is not a serverless problem; it’s a blocker for cloud adoption. The focus needs to switch to the additional revenue that the cloud will generate.

—

Myth: “We spent two years building X. Was that a waste of money?” —Stakeholder

Context: When a decision is made to build something, what you learn during the build is often more important than the build itself. This is rarely acknowledged or understood. Technology must be viewed 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 that could last for years with limited business outcomes. Often consultants are used to creating internal alignment, not advising on outcomes.

Impact: Own your technology and business strategy. It’s essential to get an evaluation from external parties, but don’t relinquish control.

To read more, check out the new book from David Anderson, Michael O’Reilly, and Mark McCann: The Value Flywheel Effect.

- About The Authors

David Anderson

David Anderson has been at the leading edge of the technology industry for twenty-five years. He formed The Serverless Edge, and continues to work with clients and partners to prove out the thinking in his book, The Value Flywheel Effect. He is also a member of the Wardley Mapping community.

Follow David on Social Media

• 
• 

Michael O’Reilly

Michael O'Reilly is a Software-Architect who specializes in arming organizations with the ability to develop ideas into world-class products by leveraging the capabilities of the modern cloud.

Follow Michael on Social Media

• 
• 

Mark McCann

Mark McCann is a Cloud Architect and leader focused on enabling organizations and their teams to rapidly deliver business value through well-architected, sustainable, serverless-first solutions. He was heavily involved with Liberty Mutual's journey to the cloud, leverages Wardley Mapping, and writes for the The Serverless Edge.

Follow Mark on Social Media

• 
•