Moving to cloud-based architecture provides scalability, security, and increased collaboration. Learn what are the major types of backend architecture and how SaaS, FaaS, Daas, and others differ from one another.
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.
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.
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.
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:
It’s a general acronym meaning any …aaS solutions.
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.
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.
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). 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.
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.
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.
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.
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).
Let’s divide the functions according to the features of Microsoft Azure Functions:
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.
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.
There are even more XaaS than you can imagine:
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. My 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.
I hope this article will help you choose the right XaaS (or many of them at the same time) in your project.
Get actionable product building tactics in your mailbox, monthly.
No previous chapters
No next chapters