Today the term hosting, in most cases and for most devs, refers to traditional hosting services, the ones that come with storage, database, monitoring, networking, etc., and on which you have to install your components, configure them, etc., before deploying your application. Today term hosting is encompassed in Infrastructure As A Service (IaaS) solutions. Content Delivery Network (CDN) comes optional with IaaS.
Software As A Service (SaaS), on the other hand, encompasses a software licensing and delivery model in which software is licensed on a subscription basis and is centrally hosted, i.e., you don’t deploy anything when you use a service. Salesforce is one of the best examples of modern SaaS solutions. Then you also have a sub-division like Backend As A Service (BaaS), where the backend is the service. Does that ring a bell? This is exactly what Crystallize is.
A Platform As A Service (PaaS) is a bridge between them both. With a PaaS you don’t care about the infrastructure as it allows you to deploy your web application (which can be a static website or a more complex one).
You describe your architecture in a configuration file, and they take care of the underlying chores, installations, updates, patches, security, network, security, backup, etc. The main goal of a PaaS is to reduce DevOps, reducing your ToC (Total Cost of Ownership). In the case of using PaaS, usually, CDN is included. The content delivery network is made up of the origin server, where you upload your static files and widespread edge servers that deliver the files to your visitors.
It also encompasses CI/CD, or continuous integration/continuous delivery, the former of which ensures all changes are pushed to the testing environment as often as possible. In contrast, the latter ensures all those changes are delivered to the right people for testing before production. PaaS often supports cloud functions/node servers and a whole range of different services and functionalities.
A common misconception about PaaS is the concept of a server. To serve static files, you need a (web) server. With Next JS, for example, everything is generated in advance. True, but how about the /api folder? It’s dynamic, right? So you need a server to compute.
Two key concepts to understand with PaaS are the build and the runtime. The build is the initial step that builds your static files (with NextJS or similar). Once built, the build is deployed on the underlying architecture managed for you: that’s the runtime. The application is actually running.
And the PaaS providers have different approaches here to manage the runtime. To serve static files, it’s really easy, but for the dynamic part (the one that requires computations), some use ServerLess functions, and some keep a server running. That’s their magic.
Understanding the approaches of each one(s) will be a huge factor in determining which solution(s) will be the best for your website.
It’s interesting to mention that you don’t have to pick only one. In many situations, you can have your Frontend with Next JS that runs on Vercel and your Service API that runs on Plaform.sh or AWS ECS.
