Cloud: IaaS vs PaaS vs SaaS vs DaaS vs FaaS vs DBaaS

Introduction

Maybe you heard something about some of the following: IaaS, PaaS, SaaS, DaaS, FaaS, DBaaS. If you are not a DevOps engineer, you’ve probably heard about some of these concepts but not all of them. I guess even if you have used some of them, you most likely don’t know everything you should. You may have even used some parts without knowing the name of the applied concept.

So let’s take a closer look to gain a better understanding of what they really are.

Why move to a cloud-based architecture?

1. Disaster recovery — you can have many data clusters all over the world like the USA, the UK, Japan, Australia and if there’s a hurricane somewhere, a flood or a wildfire, you can clone your data from the survived data stores.
2. Availability — let’s suppose there is a hurricane in Puerto Rico where we have indestructible servers in a bomb shelter, but there the electricity goes out so for two days Puerto Rico is completely cut off from the rest of the world. Fortunately, we have other servers in Germany so the web app is still accessible.
3. Scalability — let’s imagine we have a big server room, so when the number of our app users, data and requests grow, we can put new CPUs and RAM sticks there but eventually, there won’t be space to put more. Fortunately, with the cloud architecture, it’s no longer a problem because you can use resources located anywhere in the world.
4. Cost-saving - Cloud computing often leads to cost savings through reduced hardware, software, and staffing expenses. ‍
5. Simplicity — let’s continue the deployment topic. How do you deploy the app? Manually each time? Or do you create your own continuous deployment system? Or do you just use out-of-the-box services like Heroku or Google App Engine?‍
6. Automatic software updates — e.g., you use mLab and periodically there is an updated MongoDB version with downtime as small as possible for free and if you pay them, the downtime can be practically non-existent.‍
7. Working from anywhere — e.g., you can edit a Google sheet from any device or you can push it to a GitHub repository from any computer.‍
8. Increased collaboration — e.g., a Google sheet can be edited by many users even when providing various levels of permissions for them.‍
9. Version control — you can use a platform like GitHub, BitBucket, GitLab or just have a version control of documents on Google Docs or Confluence.‍
10. Security — even if your laptop, tablet or smartphone is stolen, you can have a backup on DropBox, Google Drive or iCloud.

<span class="colorbox1" fs-test-element="box1"><p>Learn how to prepare an effective cloud migration strategy to take advantage of all these benefits.</p></span>

It's important to note, that since moving to the cloud is a hard, resource-consuming process, it's key to prepare the application accordingly ahead of time. The process of making the product ready for the switch may include dealing with technical debt, that earlier was put aside.

But for now, let's talk about the cloud in the context of web applications.

Major types of backend architecture

Monolith. The entire backend is deployed in one place so it’s very heavy and difficult to scale for big apps.

Microservices. The backend is divided into many (it depends mostly on the app size but usually it’s from 10 to 80) microservices that can be deployed on different physical servers, each microservice should reflect a business feature e.g., authentication, payments, auctions, emails or inventory.

<span class="colorbox1" fs-test-element="box1"><p>Are microservices always better than monolith? Don't believe the hype! Explore the topic in the monolith vs microservices case study.</p></span>

Functions. In contrary to monolith and microservices they are not daemons (running all the time) but only executed within max a few seconds when there is a need; an example is AWS Lambda written in es7:

XaaS

It’s a general acronym meaning any …aaS solutions.

DBaaS

Database as a service – it’s a platform which hosts our database providing backups, clustering, and high availability. The most popular DBaaS are Amazon Aurora, Amazon DynamicDB, mLab, IBM Cloudant and MongoDB Atlas.

IaaS

Infrastructure as a Service – it’s the lowest level of all XaaS. It gives us a big power but requires a lot of configuration. IaaS gives a virtual machine which we have to maintain. The difference between IaaS and having a physical server room is we don’t have to buy any physical computers and we can have servers in various parts of the world. However comparing with other XaaS, IaaS is more difficult to maintain and it requires a good DevOps engineer who configures the virtual machines to work efficiently and securely.

PaaS

Platform as a Service is a simple way to deploy an app in a given technology (e.g., Node.js, Ruby, PHP, Python, Java, .NET - so it's often used by .NET development companies). The most popular platforms are Heroku and Google App Engine.

Generally, you don’t have to configure CI (continuous integration). Just push a commit, it’ll recognize the app is in Node.js, and it’ll run npm install (you can add additional commands in the postinstall script, which is run by NPM after installing the dependencies) and npm start. If the app is in Ruby, it will run bundle install and similar for other environments.

The main drawback is it’s not too flexible because it’s impossible to install custom system dependencies (e.g., from apt-get) and you can use only one of the available technologies. So if you create your own programming language which doesn’t run on any available platforms (e.g., in Node.js you can use TypeScript, CoffeeScript, Elm… besides JavaScript or in Java Virtual Machine you can use Scala, JRuby, Jython, Kotlin, Groovy… besides Java) but is compiled directly to the bytecode, you cannot use PaaS.

Another disadvantage is the data is not secure. If, for example, you use Heroku as Paas and mLab as a DBaaS, not only mLab has access to your data but Heroku could as well because you never know what code is run actually on the server. Maybe other than your code because they add their own middlewares to log something.

SaaS

Software as a Service gives an out-of-the-box software like NPM / GEM libraries but it doesn’t require any deployment/server maintenance from us.

A simple example is a mailing app such as SparkPost or SendGrid. All we have to do is to send an HTTP request with the email sender address, receiver address, email subject, email content etc. On the other hand, without this kind of tool, we would have to set up an SMTP server and scale it as the number of emails grow.

Other examples are: Google Apps (e.g., Google Drive), DropBox and Slack – these apps can be used by a human user, but they have great integration possibilities as well. Beside just existent SaaS, some companies (e.g., SAP) offer to write new SaaS on demand.

DaaS

Data as a Service is similar to SaaS, it can be even considered as a subset of SaaS. More specifically, it’s an (usually HTTP) API, which returns some data e.g., currency exchange rates, sports results or weather forecasts.

What is the biggest DaaS? Probably Facebook, collecting a lot of data and providing it for Facebook apps. Other popular DaaS are Google Maps, Google Translate API or AccuWeather.

A list of useful DaaS is available here.

FaaS

Function as a Service is even simpler than PaaS. As the name suggests, it’s based on the functions which can be triggered by a given event, so it’s an event-based architecture. The level of simplicity is so high that it’s called a serverless architecture. The developer just writes a function and doesn’t have to ponder about topics such as deployment, server resources, scalability… It’s because FaaS is auto-scalable. Therefore, the billing is based on the real consumption, not on the declared resources needs.

The most prominent example is AWS Lambda, but there are others like Google Cloud Functions, Microsoft Azure Functions, Iron.io and Webtask.io as well.

One of the biggest drawbacks of FaaS are supported technologies. There are even fewer available technologies than with PaaS. More exactly (as of 2017) AWS Lambda supports .NET, Java, Node.js and Python, Microsoft Azure Functions supports .NET, Java, Node.js, and PHP, whereas Google Functions supports only Node.js. So as you can notice, none of the most popular FaaS supports Ruby in contrary to PaaS (e.g., Heroku).

What can FaaS functions do?

Let’s divide the functions according to the features of Microsoft Azure Functions:

• Generic webhook — handles an HTTP request like a controller inside a monolith or microservice, can be called either from our system (another function or a microservice) or from an external system supporting webhooks (it means an external system sends an HTTP request to our webhook) like Stripe or Slack
• GitHub webhook — a particular sort of webhooks called on GitHub events, in the microservices/monolith architecture it could be done with CI
• TimerTrigger — called on specified time, in the microservices/monolith architecture could be done inside the code (setTimeout / setInterval) or with a queuing tool such as RabbitMQ
• CosmosDBTrigger — called when Cosmos DB documents are added or updated so it works like a database trigger. In platforms other than Microsoft Azure Functions, FaaS functions can be triggered from other DBMS
• BlobTrigger — called when Microsoft Azure Storage blobs are added to containers. A useful application is to resize images
• QueueTrigger — enables processing queues, in monolith/microservices architecture could be achieved with a queuing tool like RabbitMQ
• EventHubTrigger — used on the Internet of Things

As you can see, with FaaS, we can implement any algorithm (Turing completeness) because we can handle an HTTP request, we can send another HTTP request and moreover, we can handle time and queuing events.

What FaaS (Function as a Service) cannot do?

The only limits are about the support of specific technologies e.g., a given FaaS provider doesn’t support MQTT protocol so it requires using an application which transforms MQTT to HTTP, another format supported in FaaS, or we need an endpoint part of the system which interacts with the human (web app, mobile app or desktop app) or the physical environment (a robot checking weather conditions, a printer, a light bulb…) – that can all be built in FaaS architecture but requires some adapters outside the FaaS world.

Functions can be combined with microservices, so we can connect FaaS with PaaS, but it’s also possible to build the entire backend on FaaS (with some limits on technologies used on the backend side).

However, let’s discuss another drawback – we write a code that runs on a specific FaaS (e.g., Microsoft Azure Functions) so moving to another FaaS (e.g., Google Functions) could require rewriting even half of the code written as FaaS functions. On the other hand, moving from one PaaS to another should be relatively easy.

What’s next?

There are even more XaaS than you can imagine:

• Analytics as a Service
• Authentication as a Service
• Backup as a Service
• Business as a Service
• Communications as a Service
• Computing as a Service
• Content as a Service
• Desktop as a Service
• Energy Storage as a Service
• Fraud as a Service
• Games as a Service
• Hardware as a Service
• IT as a Service
• Jobs as Service
• Knowledge as a Service
• Logging as a Service
• Mashups as a Service
• Mobile Backend as a Service
• MongoDB as a Service
• Monitoring as a Service
• Network as a Service
• Oracle as a Service
• Payments as a Service
• Quality as a Service
• Query as a Service
• Recovery as a Service
• Replication as a Service
• Robot as a Service
• Routing as a Service
• Search as a Service
• Security as a Service
• Storage as a Service
• Testing as a Service
• Utilities as a Service
• Virtualization as a Service
• Wireless as a Service / WiFi as a Service
• WAN Optimization as a Service

‍

Summary

As you can see, many of the XaaS can even have the same acronym and one can be a subset of another. It’s a difficult question which XaaS should be used in a given project and particular situation. I suppose at the same time various DevOps engineers could choose quite different solutions. Our favorite approach is to create a microservice-oriented architecture in PaaS because it just combines flexibility with simplicity.

Of course, we should make our lives easier by using some external SaaS like SparkPost or Slack integrations and some external DaaS to easily get the data like the current currency exchange rates. Moreover, we can base some (5% ~ 20% dependent on our needs) part of our system on FaaS – simple stateless functions which connect multiple services so using FaaS just will save time on deployment and monitoring.

We hope this article will help you choose the right XaaS (or many of them at the same time) in your project.