Let's talk
Reach out, we'd love to hear from you!
Serverless computing and containers have skyrocketed in popularity over recent years. In fact, according to a recent study by Datadog, over 50% of current AWS, Microsoft Azure, and Google Cloud customers are currently using their CSP’s serverless offering.
However, whilst there are plenty of advantages of containers and serverless – and in their use together as a serverless container infrastructure – it’s important to understand where these up-and-coming technologies will serve your project poorly.
Below, we outline the pros and cons of serverless and containers, and some alternative options to consider.
What are the advantages of serverless and containers?
In short, serverless computing is fast, flexible, and scalable. By outsourcing server management and capacity planning tasks to a leading cloud service provider, developers can build and deploy applications quickly without needing to worry about server infrastructure.
Meanwhile, thanks to its ability to package an application and its dependencies into a cohesive unit, containerization technology offers portability, security, and cost benefits. Applications can run on any OS, regardless of the host OS, whilst isolating applications for enhanced security. Containerization can also reduce overheads by using fewer system resources than traditional or hardware virtual machine environments.
When are serverless and containers a red flag for your project?
Despite these advantages, serverless and containerization technologies will be a poor fit for your project in some cases. These circumstances will nullify any cost, productivity, and security benefits the technologies offer – deploying them may even hinder your progress.
When to avoid containers
If your application has a static user load
Serverless technology is useful for high-performance apps and functions, such as e-commerce. For apps with a non-dynamic workload, serverless adds unnecessary complexity to your infrastructure. Static user loads can lead to several issues in containerized apps. As requests to your application increase, resource contention becomes an issue, leading to unnecessarily higher costs.
If you’re building an app with a constant workload
Containers are designed to be ephemeral, so stateful applications don’t require a containerized environment.
If microservices aren’t needed
Containerization works well with microservices architectures and lightweight applications. Heavy resource-consuming apps can suffer from inefficiency and performance issues when containerized, increasing costs.
If your app needs complex functionality
Containerless technologies work well for simple apps with one or two main functions, making them quick to build, deploy and update.
On the other hand, containerization reduces the amount of direct control you have over your code, security, and authentication. As a result, if your app needs extensive functionality – and a complex algorithm to support it –serverless isn’t the way forward.
If containerization won’t work with your chosen tech stack
Some technologies are significantly more compatible with containerization than others. For example, node.js and Java apps containerize well, whereas for heavy, memory-intensive .NET and PhP frameworks, containerization is a poor choice.
You should also think twice about running proprietary software in a containerized environment, as this can cause licensing issues.
When to avoid serverless
If you don’t have a dynamic workload
Dynamic workloads require sudden, rapid resource changes to address computing demands. Serverless works well for this from a capacity planning point of view.
On the other hand, if your workload remains relatively stable or grows steadily, serverless offers significantly fewer benefits. It may be more cost effective to look for an alternative solution.
If your app needs complex functionality
Like containerization, serverless technologies work best with simple apps, which become easier and faster to deploy with a serverless infrastructure. Extended-functionality apps with a need for complex algorithms suffer, as you have less direct control over your codebase, with limited scope for advanced functionality.
If you want to avoid vendor lock-in
The potential for vendor lock-in is a significant drawback to serverless computing, as it’s easy for your codebase to become tightly coupled with your serverless vendor’s platform. This reduces flexibility long-term – it becomes difficult to move your code to another platform, and leaves you at the mercy of your vendor, expenditure-wise.
If you need robust monitoring and security tools
As traditional security mechanisms don’t apply to serverless applications, developers need to anticipate, monitor, and prevent issues that might not be expected in a traditional network.
Whilst some CSPs offer monitoring tools, these aren’t always fully featured or designed specifically for serverless – many are simply extensions of other services. To benefit from them, you may also need to commit to one CSP for all your needs, an increasingly uncommon strategy for organizations today.
If you want to avoid unforeseen costs
Whilst serverless can look like a smart financial decision on the face of it, it’s important to understand that this can change over time. Instances of high traffic, for example, can increase costs significantly.
What are the alternatives to serverless and containerization technologies?
There are a number of alternatives if serverless or containerization technology is a poor fit for your project. Our team offers expertise in:
Infrastructure as a Service (IaaS)
Under an IaaS model, organizations pay a recurring fee to a CSP for access to storage, network, servers, and virtualization. Developers can use their own software stacks and maintain significantly more control over the entire infrastructure.
Examples: EC2, Instances (AWS), VMs (Microsoft Azure), Compute Engine ( Google Cloud)
Platform as a Service (PaaS)
Under a PaaS model, a CSP provides a platform for developers to develop, run, and manage applications without having to worry about the underlying infrastructure. PaaS offers greater flexibility than serverless in terms of customization and configuration, alongside better portability across cloud providers and environments.
Examples: AWS Elastic Beanstalk, Microsoft Azure, Google App Engine
Caching
Caching can be a simpler way to store data than containerization, particularly for smaller applications. As a more lightweight option, this requires less configuration than container technology.
Examples: Redis is in-memory data store used as a database, cache, that can be used as an alternative to containerization.
A few final thoughts
The key to realizing the benefits of serverless and containerization technology is knowing when to use them. Both offer flexibility, cost savings, and scalability benefits in the right circumstances. If deployed incorrectly, however, they could add unnecessary complexity to your project, encourage unhelpful vendor lock-in, or hinder your ability to monitor threats effectively.
If you’re looking for advice on the best technologies to use for your project, why not get in touch? Kellton’s global team of experts will be happy to advise, using experience from over 200 clients across the world.