Four Red Flags that Indicate You’re Not Ready for Serverless

We've been asked by several clients recently to build systems using serverless technology. In these experiences and in various environments, I’ve seen certain warning signs that indicate that serverless might not be the right solution for all organizations.

Before I get to that, though, I want to take a second and talk about why people want to do serverless and what serverless tech is.

What is Serverless Tech?

Serverless technology, like AWS Lambda and Azure Functions, provides the ability to deploy very small pieces of code — individual functions that start, stop, and scale independently of each other. Serverless technology’s ability to deploy small pieces of code into the cloud gives organizations the ability to granularly manage deployments and scale a system in a more efficient way. People want it because it’s super flexible; testing is a lot easier; and it brings a lot less risk per deployment.

The backbone of serverless tech is made up of small pieces of code called “functions.” Functions are usually very, very small. And the cloud manages access to those functions.

This is an extension of something else you might have heard of: “microservices.” Microservices take your traditional monolith and break it into functional components. With serverless, a function supports only a single operation, whereas a small microservice may support 15 or 20 operations.

An easy way to think of serverless is that it's essentially a nano-service, but when you want to get into this world, here are the red flags warning you of impending problems:

1. You Are New to the Cloud or Microservices

Don’t get overconfident and fall victim to victory disease — like the devastating decision by Napoleon to invade Russia after his victories in Central Europe, which led him to believe that winning would be easy. He made no plans for a sustained campaign or the complicated logistics involved.

The same thing can happen with getting into the cloud, getting microservices, and then immediately trying to step into serverless tech. Occasionally, we see companies overextending themselves driven by hubris.

It takes time for your organization to become accustomed to working in the cloud. There are certain policies and processes that need to be accounted for that are different in the cloud versus on site. One sign of this is if you're depending on static IP addresses to manage your environment and security. The cloud is averse to static IP addresses; serverless is downright hostile to static IP addresses. Make sure you foster some maturity around the cloud before you get ahead of yourself.

Log file management is another area that can cause problems in the on-premise to cloud to serverless migration. Organizations accustomed to monolith applications are accustomed to dealing with one log file per application. A microservice deployment expands that to potentially dozens of log files. Serverless will explode that to hundreds of log files. If you don’t have good infrastructure and practices for aggregating logs, using correlation IDs, and searching log files then the explosion of log files will make your system unmaintainable. Tools like Splunk and Kibana provide the capability to manage the sprawl of log files in a serverless environment.

2. A Lack of CI/CD Automation and DevOps within Your Organization

For serverless to work, DevOps and CI/CD need to be instinctual in your organization because you're deploying tiny little functions — very small pieces of code, sometimes only a couple dozen lines.

For that to work, you need to have a CI/CD pipeline that can manage that level of granularity and control.

Without good CI/CD automation, your developers will spend all their time deploying individual functions rather than actually writing the code. Or developers might lose track of which versions are running across various staging areas.

Additionally, if your corporate processes dictate committee approval of any deployment, then your serverless environment is going to overwhelm the approval process.

3. Your Architecture Team and Information Security Teams are Isolated

If your architecture team or your InfoSec teams are insular and isolated, that doesn’t bode well for either cloud migration or serverless deployment. Both of these teams need to be involved and need to understand at a developer level how these technologies work.

Because they will be setting policies and processes, they need to believe and be fully immersed in that environment. They also need to be aligned with the goal of going serverless and understand the value and the challenges of doing so.

If they don't understand the value and they're reluctant to adopt policies that aren't friendly to that environment, then you won’t succeed.

4. Your Environment has a Heavy Dependency on Legacy Languages

If your culture has a heavy dependency on legacy languages, that’s another red flag. To put it bluntly, Java is the wrong language for serverless technology.

Java is great at long-running processes and is very efficient for that, but one of the battles that you'll have in a serverless environment is the cold start time associated with Java. If you don't use a function for a period of time, the cloud turns that function off. Then, the next call to that function requires it to start up from scratch and load everything into memory; that delay creates a poor user experience. Also, if the cloud is scaling the function to support an additional load, it must cold start new instances.

We find that our developers using Java in a serverless environment spend a lot of time optimizing how much code is actually deployed and trying to minimize the footprint of what's being deployed. Additionally, many of the frameworks, like Spring, add huge overhead to each startup. So, you end up using the legacy language but none of the frameworks that help developers be super productive in those languages.

There are other languages that are better suited for serverless such as Node.js and Python. Both of those have quick start times and have good run times so we have a bias toward them if you’re looking to go serverless.

How to Start with Serverless

If you’re dead set on moving to serverless, prototype something first, something small. Use this test to understand the dynamics of it, the DevOps side of it, the corporate hurdles in security and compliance, and the performance characteristics of it before you attempt a larger deployment. Find out how to log problems and process something small.

Even though you need to start small, make sure you don’t just have one function, but a cluster of functions, because you want to see how they interact together.

Once you get that prototype settled, you’re on your way to a successful serverless set up.