November 06, 2018
With today’s many options for abstraction platforms, including VMs, containers and serverless computing (and the dizzying array of buzzwords ending with “as a Service”), it’s not always obvious what is the best way to go when it comes to building and deploying your own application. To that end, let’s get straight to the heart of the advantages and disadvantages.
Containers let you package your application together with all of its dependencies and run it anywhere, regardless of vendor. With containers, you have complete control over your application’s resources, configuration and security. You can migrate any application to container architecture, and this is especially convenient when it comes to legacy applications and “unfashionable” programming languages.
With containers you’re still responsible for all the administration needed to maintain the container’s runtime environment, such as upgrades, ensuring compatibility among packages, and security patches. You also spend time creating and testing deployment packages, and scaling still takes work and careful planning. Finally, you pay for your platform resources continuously, regardless of the time they’re actually used.
In serverless computing (FaaS), you break down your application into small functions. These are activated when specific events trigger them. All you need to deploy is the set of your functions – all other infrastructure is provided by the serverless vendor. The resources devoted to running your functions scale up or down transparently, according to usage at any given time. And you only pay for the runtime you consume – definitely one of the most attractive qualities of serverless.
But because your functions are launched on-demand, their startup time may translate to unsatisfactory response latency. Serverless functions are often restricted in terms of size, memory use and runtime. They’re well-suited to stateless workflows, but it’s harder to implement stateful functionality. And due to their “black box” nature, they’re hard to monitor, debug, and analyze for performance.
When it comes to selecting an abstraction architecture, you’ll need to consider the specific nature of your application. CIMI Corporation President Tom Nolle says to keep in mind that while “developers approach serverless vs. containers as a question of what is best for the application…they also must weigh the deployment concerns for each.”
With containers, you have the flexibility regarding how, when, and on what infrastructure your application runs. However, you will need to pay the operational price in terms of time needed to maintain and deploy containers. Your DevOp’s team will be responsible for implementing security measures and planning for future scaling requirements. On the other hand, your team will have access to a vast ecosystem of debugging and monitoring tools to help do this.
Below are some situations where you may prefer to use containers:
If you need a specific 3rd-party package to run on the server side - for example, MySQL. Serverless platforms such as AWS Lambda don’t enable this.
If you need to run older or more esoteric programming languages, such as PHP, Lua, Elixir or C. Running these languages in serverless environments can be inconvenient or unsupported.
If you have a large or complex application that can’t be broken down efficiently to the bite-sized components that serverless architecture requires.
Conversely, you may prefer to go serverless if your application can easily be implemented as a set of small, event-driven, stateless functions. This will allow your DevOps team to focus solely on added functionality and business value, without having to devote time to deployment, maintenance and scaling considerations – also shortening your time-to-market. The flipside of this is that your architecture may be constrained by specific vendor attributes, effectively locking you in to that vendor’s platform. In addition, you have to trust the vendor to be as rigorous as you would be when it comes to security, which unfortunately is not always the case.
Below are some cases where you may prefer to choose serverless:
Data stream analysis and processing applications, which are ideal for periodically processing new chunks of data using short, stateless functions.
Applications with spiky or unpredictable traffic can see a significant reduction in cost if built using serverless.
Applications using event-based architectures and application that use several cloud services are ideal cases.
Though serverless computing is the newer technology, it’s not necessarily better than containers, and doesn’t constitute a replacement. We know that two architectures may have different characteristics, and the choice between them really depends on your goals and the nature of your application.
A June 2018 Cloud Foundry survey found that 39% of IT decision makers use all three technologies: PaaS, containers and serverless computing. So if making the decision still feels rather muddy, you may very well end up choosing to have both serverless and containers in your enterprise portfolio, joining enterprises who are going with a multi-platform route for the shorter or longer term.