Cloud computing is a software engineering paradigm centered around renting rather than purchasing the physical infrastructure required to run your software. Companies hosted their software on prepaid physical servers from the late 1990s to the early 2010s. They set aside a part of their budget to make this purchase before going public with their apps. This model, however, is expensive for companies just starting because they have to set aside a substantial part of their budget to purchase servers. Cloud computing started gaining prominence with the introduction of EC2 to the public in 2006. As the years progressed, more cloud providers entered the market, notably Google in 2008 and Microsoft in 2010. Now, we are at the point where software teams can spin up performant environments for their software applications in seconds rather than months.
When a software team wants to spin up an environment, they must consider the complexity and power it must possess. They can run their app on a virtual machine, a virtualized server created on an even more performant physical machine built for the cloud. They can also run it on a ready-made platform with their desired runtime already installed. If the app is small enough, they can run it as a serverless function. If budget is not a constraint, they can choose to purchase the application from a service provider and only pay subscription fees. Each method has pros and cons, and you must make the right choice that fits your requirements.
In this article, you will learn how to make the right choice when deciding how to build and deploy a web application. You learn this by studying the different models of deploying web applications, popularly known as cloud computing. These cloud computing models include Infrastructure as a Service (IaaS), Platform as a Service, (PaaS), Software as a Service (SaaS), and Functions as a Service (FaaS). You will learn about their features, pros, and cons. And finally, we will learn about Strapi Cloud.
Different cloud computing models exist to address different needs. IaaS, for example, is used by customers who need a high level of customizability at the infrastructure level and don't mind the associated responsibility. SaaS, on the other hand, is restricted to customization only at the application level, with no customization at the infrastructure and platform levels. So you can customize the kind of virtual machine where your app is deployed in the IaaS model, but you can only customize how your app looks in the SaaS model.
All models have the same set of responsibilities, but these are shared differently by the provider and the customer. For IaaS, the provider is responsible for the physical machine's health, security, and uptime of all physical network devices. All other responsibilities such as the Operating System (OS) updates and data security are handled by the customer. As you move from IaaS to PaaS to SaaS, the responsibilities of the customer are reduced, and these responsibilities are transferred to the cloud service provider. The diagram below illustrates how responsibility is shared between the cloud service provider and the customer in the four models (traditional IT is also added for reference).
The following section gives an overview of each model and their use cases.
In the IaaS model, you are provided with a virtualized Infrastructure in the form of virtual machines, disks, and network devices (network interface card, firewalls, routers, etc) that you will configure to meet your requirements to run your software applications. In this model, you as the customer have the most responsibility. You manage your issued OS’ health, security, and updates. You are free to install and run different types of software, from runtimes like Node.js and Python to servers like Nginx and Apache 2. The major IaaS component is the virtual machine. Major cloud providers have different names for this. Azure calls it a "Virtual Machine", AWS calls it “Elastic Compute Cloud (EC2)”, and Google Cloud Platform calls it a "Compute Engine".
When a customer provisions a virtual machine from a cloud provider, they access it using a bastion, an SSH session, or a remote desktop via RDP. They don't necessarily access it directly to install software and this process could be automated using configuration management tools like Ansible and Pulumi.
One specific use case of the IaaS model is for deploying software that would have otherwise been bought as a SaaS. There are many such software from email servers to databases. You can choose to deploy MySQL in your infrastructure rather than buying from a MySQL SaaS provider. Other things you can deploy using the IaaS model include Mattermost for team collaboration, Apache Spark for data analytics, and SAP for Enterprise Resource Planning.
Another popular use case of the IaaS model is deploying web applications. Newer developers would be more familiar with using services like Heroku for this purpose which offers hosting services for popular web frameworks like Node.js, Python, and Ruby. This is a PaaS approach because one can host any type of web application, no matter the framework, on a virtual machine.
The machine simply needs the right configuration to run that particular type of web app. The typical approach is to define a pipeline that runs whenever code is committed to source control and take this code to the target virtual machine for deployment.
Summary of IaaS:
IaaS | Features |
---|---|
Virtualized Resources | Offers customizable virtual machines, storage, and networking. |
Customer Responsibilities | Manages OS maintenance, security, and software installations. |
Access Methods | Accessed via bastion hosts, SSH, or RDP with configuration automation tools. |
SaaS Alternative | Provides infrastructure to host and manage traditional SaaS applications. |
Web Deployment | Enables hosting and control of web applications beyond typical PaaS offerings. |
Automation and Scaling | Supports automated deployments and scalability through CI/CD pipelines. |
In the PaaS model, the cloud provider provides the runtime needed to run apps built with languages such as Python, JavaScript, Java, and Ruby. For a framework like Python with two major versions, the provider makes both versions available so that developers have an easier time getting their app to production. Under the hood, the PaaS environment runs the code in a virtual machine or a container but access to the machine is oftentimes restricted to the customer.
Depending on the provider, one can deploy a container directly to production using the PaaS approach. The general idea is to containerize your application locally, push the resulting container image to a container registry like Dockerhub, and configure the PaaS platform to pull this image and run it as an application.
In both approaches of using virtual machines or containers, you are expected to build your application in a way that doesn’t store the application state on the machine because the environment can be torn down and built back up without notice. If your application writes to disk, you may encounter a data loss problem.
Summary of PaaS:
PaaS | Features |
---|---|
Runtime Provisioning | Provides runtimes for languages like Python, JavaScript, Java, and Ruby. |
Version Support: | Offers multiple versions of frameworks, e.g., both major versions of Python. |
Environment Access | Runs apps in VMs or containers with restricted customer access. |
Container Deployment: | Allows deploying containerized apps directly from registries like Dockerhub. |
Stateless Design | Requires apps to be stateless to avoid data loss during dynamic environment change |
The FaaS model is similar to the PaaS model in that the application is written in one language and deployed to an environment where it gets a Fully Qualified Domain Name (FQDN). It is however different in that only a small portion of an application is deployed. Typically, this is the portion that does a unit of work, abstracted as a function. This is why applications deployed using this model are called Serverless Functions.
The constraints of writing to disk and persisting application state are more apparent in this approach. It forces the developer to take the approach of writing their application to communicate with an external state be it a database, object storage service, or message queue.
Summary of FaaS:
FaaS | Features |
---|---|
Language Consistency | Uses one programming language for application development. |
Deployment | Assigns a Fully Qualified Domain Name (FQDN) to deployed functions. |
Function-based Deployment | Deploys small, function-sized units of an application. |
Serverless Architecture | Functions are managed without dedicated servers by the provider. |
State Management | Necessitates external state management, e.g., databases or message queues. |
In the SaaS model, the customer only pays for the maintenance, support, security, and updates to the software as covered by their license or subscription. The typical deployment approach is a single click through the website of the provider. The SaaS model has most of the responsibility on the provider and the least responsibility on the customer. The customer is in charge of their data security but not in charge of the OS or Infrastructure security.
Examples of SaaS software or SaaS products include Office 365, a document collaboration suite, Dropbox, a file storage service, and Slack, a corporate collaboration software. All these SaaS software require some form of subscription or license to be used. For the most part, the provider tries to optimize costs for the customer. In many cases, the customer only benefits from hosting their software themselves if they can optimize their virtual machine usage. When scale matters, it might make sense to use the IaaS option instead.
Summary of SaaS:
Saas | Features |
---|---|
Cost Structure | Customers pay for maintenance, support, security, and updates via subscriptions. |
Easy Deployment: | Typically offers single-click deployment through the provider's website. |
Provider Responsibility | Most responsibilities, except data security, lie with the provider. |
Customer Responsibility | Customers are mainly responsible for their data security. |
Examples | SaaS products Includes Office 365, Dropbox, and Slack, mostly requiring subscriptions. |
Cost Optimization | Providers aim to optimize costs; self-hosting is beneficial only with efficient VM use. |
Scaling Considerations | IaaS may be preferable when scaling is a critical factor. |
When deciding on a deployment model, consider aspects like the duration of service operation, memory consumption, and scaling requirements. These considerations are vital because each deployment model is tailored for different use cases, prompting you to ask relevant questions about your particular needs and assisting in selecting the best-suited model. It's worth noting that not all software can be deployed using both the IaaS and SaaS approaches. Some software must be obtained using a strict SaaS approach where the customer simply pays the organization and has access to the software. However, with cloud deployment, you typically have the flexibility to choose between IaaS, PaaS, and FaaS options. In this section, you will learn about the different factors that influence the choice of a cloud deployment model.
When your team consists of system administrators who can easily automate, patch, and manage machines in your network, you can easily choose to use an IaaS model. Because people in your team already have the technical know-how to deploy and manage applications on virtual machines, you won't face troubles when you need to troubleshoot. In some instances, your organization already has the physical infrastructure it uses to run applications but wants to connect this physical infrastructure to the cloud. In such cases, you would consider using the IaaS model so you can easily replicate on-prem software to the cloud.
When you have less experienced system administrators or simply run a team with just developers, you should consider using the PaaS model. In this way, developers are responsible for managing their code and releases without worrying about the underlying infrastructure. The same consideration applies to FaaS since it's very similar to the PaaS approach. The purpose of deploying an application is to get value to consumers as fast as possible. So, when you can use a platform configuration to achieve this, you should go for it using your existing manpower. For teams with limited technical expertise, the SaaS approach is a wise choice. This model relieves you of the burden of managing code, deployments, and security updates, among other tasks. Your sole focus is on application data and data security, simplifying your responsibilities and allowing you to concentrate on what matters most.
Each deployment model comes with a scalability option built in. For IaaS, your virtual machine instances can either scale up (vertical scaling) or scale out (horizontal scaling). Scalability is oftentimes handled by scaling rules where the environment scales based on the number of connections, CPU utilization, request rate, response time, etc. For PaaS, scalability is more or less integrated into the environment, and the way the app scales determines the bill at the end of the month/defined billing period. As with other aspects of PaaS, scalability adopts the platform defaults and can more easily be configured to suit a user’s needs. For FaaS, scalability is automatic based on the number of connections and the customer doesn’t have to configure anything. This is similar to SaaS where the customer simply provides the application for the users without worrying about connections, number of instances, CPU utilization, etc.
The cost of a platform is a major consideration factor when deciding the deployment method to adopt. Software teams can save costs if they optimize their virtual machines to run more than one software be it websites or enterprise applications. For example, a single 4 GB RAM virtual machine can be used to run 3 websites for a mid-sized company. When the team does not have the technical know-how to optimize costs for virtual machines, the next reasonable approach is to pay for a PaaS solution or simply pay for a SaaS that addresses their needs. With either approach, they spend less time worrying about optimizing infrastructure costs and more time optimizing application code in the case of PaaS, or optimizing which users are served in the case of SaaS.
To optimize performance you need to consider your chosen deployment method and how performance is generally optimized in it. For an IaaS workload, for example, you should choose an instance that fits your workload based on CPU, memory, and storage. If your deployment spans across multiple virtual machines, you spread your load across multiple instances using an appropriate load-balancing technique. If your load varies based on the time of day you should consider scaling instances automatically by provisioning more instances when the load is higher and deprovisioning extra instances when the load is lower. You should consider implementing firewall protection, encryption, private subnets, and regular updates to ensure your infrastructure is protected at all times. If you are utilizing a PaaS approach you should consider using a managed database service from your cloud provider to reduce latency and ensure zero data loss. You should also cache frequent requests to ensure your instance stays fast.
Strapi Cloud offers a unique Platform as a Service (PaaS) solution distinct from typical Software as a Service (SaaS) Headless CMS. On top of providing a Strapi-optimized stack including database, email provider, and CDN (Content Delivery Network) out of the box, Strapi Cloud gives the flexibility to customize your infrastructure to suit specific project needs, including the ability to integrate custom plugins and APIs. This enables developers to maintain control over their development environment, optimizing for both functionality and performance.
Strapi Cloud simplifies operations by managing infrastructure tasks such as CDN caching, backups, and scalability — features that automatically adjust resources to handle increased loads without user intervention. Click here to try Strapi cloud today.
In this article, you explored the different models of deploying applications to the cloud. These models include Infrastructure as a Service (IaaS), Platform as a Service (PaaS), Functions as a Service (FaaS), and Software as a Service (SaaS). Each model has its quirks and use cases. Your major takeaway is to realize that these models exist and should be used where appropriate to deploy applications to the cloud.
Also, with Strapi Cloud you can get everything you need to run a Strapi in production, deploy a Strapi project to production in just a few clicks, and still remain in complete control.
Osinachi Chukwujama is a software engineer and technical writer. He has deep interest in embedded systems, artificial intelligence, and robotics. He enjoys writing about cloud computing and systems programming.