PaaS, CaaS, or FaaS? How to choose

Imagine walking into a grocery store that specializes in hamburgers—all kinds of hamburgers, but only hamburgers. When it comes to hamburgers, though, the store’s options are endless. 

If you’re a hamburger chef, go to aisle one to find the beef, chicken, and other protein options, along with all the cheeses, types of bread, vegetables, condiments, and other ingredients you might want to build your own hamburger and sides. There is even a selection of plates and containers for packaging the meal.

If you lack the time, skills, or interest to assemble the hamburger yourself, then head over to aisle two where you can buy one of the hamburgers-in-a-kit. Along with the classic options, there’s a kit for an organic burger, a vegan option, and even a keto diet one. Just follow the directions in the kit, and you should have one yummy burger.

Only then, as you’re standing in the checkout line, your boss calls. She says you need to make 300 burgers of different types in the two hours before lunch. Plus, in addition to making the burgers, you have to operationalize a process to serve them and get paid. You’ll have to be careful because some customers want special orders and others will try to cut the line and steal their lunch.

Lastly, there will be a health and safety inspection during lunch, so whatever you do better comply with the regulations. And sorry, but you’ll only have a couple of people working with you, and they also have little experience with this type of operation.

Making the cloud burger

Selecting among cloud architectures is a lot like this makeshift hamburger operation, and in many ways, far more complicated. Developers, engineers, architects, and IT leaders have many platform, performance, regulatory, and other considerations when considering which cloud architectures to operationalize.

Which architecture will offer a better experience for customers and yield a higher quality product? Which will be easier to operationalize and hit your deadline? Which path will handle support, compliance, and security issues better? Finally, which approach can you implement at the lowest cost? 

Engineers can select a container-as-a-service (CaaS) option and containerize applications, which is equivalent to the chef creating and operationalizing her meal through aisle one. If they don’t have that expertise, then platform-as-a-service (PaaS) options are the equivalent to picking a kit in aisle two and following the directions and constraints on using it.

Neither CaaS nor PaaS meets your needs? Well, you could build everything from the ground up (infrastructure as a service, or IaaS) or deploy functions to serverless environments (function as a service, or FaaS).

FaaS is a type of serverless computing designed to respond to a single task. For example, a FaaS might be used to authenticate a user, perform a spell check on a body of text, or perform a mathematical computation.

Clearly, there are many architectural options to host, configure, manage, and deploy code to the cloud. Things get even more complicated when considering the different product offerings. PaaS options include Azure App Service, AWS Elastic Beanstalk, Google App Engine, Red Hat OpenShift, and Salesforce’s Heroku, just to name a few. If you’re exploring CaaS solutions, then Amazon, Google, and Amazon each have their own managed Kubernetes service with their own acronym (EKS, GKE, and AKS, respectively). Plus, there are other options from the likes of VMware, IBM, Oracle, Rackspace, and others.

Of course, there are even more serverless options. Azure Serverless has serverless functions, Kubernetes pods, and application environments. AWS currently has broader serverless options and breaks its serverless into functional categories for computing, storage, data stores, API proxies, and more. Google Cloud takes the most expansive definition of serverless and includes services such as BigQuery and AutoML.

Key CaaS, PaaS, FaaS, and serverless considerations

There are several considerations when reviewing these different cloud architectures. 

• Target audience – PaaS and FaaS options first target the developers by making the solution easy to configure and integrate with CI/CD pipelines for deployment. Containers parameterize the operating environment and the platform configuration, so these tools are generally targeted toward operators and system administrators.
• Configurability versus agility – In general CaaS is the most configurable option, giving operators the most flexibility to select platforms and configurations to containerize. PaaS and FaaS options focus on agility and helping developers deploy and test code faster.
• Some PaaS solutions are opinionated – PaaS and FaaS solutions by design are preselecting, meaning you are already locked into their platform choice and configuration options. These solutions are engineered based on the designer’s opinions of what developers want, best practices, and target performance characteristics. For operators who prefer more flexibility or more controls, an opinionated PaaS or FaaS may be too constraining. 
• Skills and learning curve – A fair generalization is that CaaS solutions have a steeper learning curve and require more skills than PaaS and FaaS solutions.
• Vendor lock-in – CaaS solutions are generally developed on Kubernetes and are portable across different cloud hosting options. Even though PaaS and FaaS solutions can be engineered with Kubernetes as the foundation, they typically don’t expose the Kubernetes layer to end-users and instead present more simplified configurations. These configurations are proprietary to the PaaS and FaaS solution, and often designed to run on only one cloud. Some IT leaders find this problematic and are rightfully concerned about being locked into the cloud vendor. 

Questions to guide your research and prototyping

When facing so many options, some organizations will perform a minimal amount of research and prototyping and select the path that goes farthest fastest. Others will invest significant time, energy, and money to research options, consult experts, and select options for robust implementations.

Both of those approaches are better than your organization becoming paralyzed by the multitude of options, selecting none, and going nowhere. In the fast-paced world where every company is trying to gain a technical advantage, being overly conservative and maintaining the status quo will only inhibit a business’s opportunities. 

So, I consulted with experts to identify some key questions that should help narrow the options and playing field:

1. Are you a small team with only a few applications? In these cases, you should consider the simpler PaaS and serverless options where you can get most of the required platform pre-configured and without investing a lot of time and expertise. DJ Navarrete, director of platform architecture at AvidXchange, suggests, “For small to mid-size companies that may require more change management support to be successful, and those looking to increase maturity, stability, and velocity quickly, PaaS is appealing because it offers a quicker path to implementation and efficiency gains.”
2. Do you have episodic payloads but still need to scale up when required? The scope could be a microservice or function but could also grow to full applications and databases. These use cases are ideally suited for serverless computing, where you’re only paying for the required usage.
3. Do you have a compliance obligation or a regulatory standard that forces you to report on specific underlying options or settings in the execution container, application, database, operating system, or infrastructure? Wayne Anderson, security and compliance architect for Microsoft’s Modern Workplace Center of Excellence, says this is a critical reason that serverless options get ruled out. PCI and other compliance requirements are generally interpreted by legal departments or auditors as requiring proof of computing environment settings.
4. Are you leveraging many specialized platforms or legacy applications? In these cases, it may be difficult to find commercial PaaS options that are compatible. At the same time, developing containers may simplify deployment and dependency management.
5. Are you a large organization or enterprise operating in multiple clouds and with various application and data platforms in production? These organizations may elect to standardize on containers because it provides the most flexibility in supporting multiple platforms and configuration options. Serverless may still be a consideration if compliance isn’t a factor. Enterprises may steer away from PaaS options if they have enough skill and capacity to develop the breadth of options on Kubernetes. Organizations with sufficient scale and technical skills, such as Shopify, might elect to engineer their own PaaS with Kubernetes and containers as the foundation.
6. Are you developing microservices and standardizing on a cloud-based microservices architecture? Mark Heath suggests that containers or FaaS are good options, as is hosting functions in containers. Heath says that serverless functions may be easier to configure and less costly to support, while containers may simplify local development and provide more options to secure endpoints. 
7. Cloud consultant Sarbjeet Johal likes to know if you are building platforms, applications, or services, and whether the audience is internal to the enterprise, external or customer-facing, or machine consumable. Knowing the type of application and the type of end-user helps you anticipate future needs and requirements. For example, Johal says, “For external applications, you want to log a lot more access control, the data volumes may increase unpredictably, and the application may have more extended longevity compared to internal applications. If a service or platform is machine consumable, then you might need some metering.” Forecasting the roadmap and future needs should help promote some options and rule out others.

Once you have the options narrowed, a best practice is to conduct a proof of concept. You don’t cook burgers for 300 without testing the recipe.