IaaS vs PaaS vs SaaS and other WTFaaS

The acronyms IaaS, PaaS, and SaaS have practically become buzzwords, appearing in almost every advertisement for IT services. In short, not all *aaS are equally applicable and useful for your business.

Today I will try to explain the differences between them and analyze cases where they can help save or, conversely, spend your annual budget within a day. We will also try to delve into the calculation methodology. Sometimes these services can be beneficial, and other times they can be extremely detrimental to your budget. Let's explore how they work.

All "as-a-Service" models primarily differ in how much responsibility you shift from your team to an external service provider. Do you lack a DBA and have neither the desire nor the ability to administer a database? You take DBaaS and use a cloud-based version of PostgreSQL. All technical details related to updates, backups, scaling, and other tasks are handled automagically. It just works.

However, one must not forget the old truth that "there are no clouds, only other people's servers." Somewhere in the backend, your provider's engineers still solve the same problems. Moreover, it can still break, become unavailable, and lose backups. Therefore, such services should always be regarded not as a silver bullet solving all problems, but as another model of working with infrastructure, optimizing the company’s capital and operational expenditures.

Here are the main models you might encounter:

Infrastructure as a Service (IaaS)
One of the most classic and widespread models. You rent virtual machines, IP addresses with networks, storage for your applications' data, and similar resources.

What is delegated:

1. Building data centers and maintaining physical infrastructure
2. Networks and network security
3. Server capacities. These can be both virtual and bare metal.
4. Storage and space for data

Examples: Amazon Web Services (AWS), Microsoft Azure, Google Compute Engine (GCE)

Platform as a Service (PaaS)
A commonly encountered model where you increase the number of delegated functions. In addition to all infrastructure matters, you also remove the responsibility for maintaining operating systems and various frameworks for your applications. This often includes delegating business intelligence (BI) systems.

Essentially, you get a ready-made platform to run your application with minimal effort.

What is delegated:

1. Building data centers and maintaining physical infrastructure
2. Networks and network security
3. Server capacities. These can be both virtual and bare metal.
4. Storage and space for data
5. Operating system
6. Frameworks and environments for applications

Examples: Google App Engine, Microsoft Azure App Service, Heroku

Software as a Service (SaaS)
Generally, except for some specific models, this is the highest level of delegation, which implies that you do not plan to maintain and update the application itself. This is one of the oldest and most widespread models. All questions of scaling, security, compatibility, environment, and timely updates are handled by the application provider.

Need to store code and ensure all CICD? You don't need to deploy infrastructure for Gitlab; you can just rent it as a cloud service. The same goes for email services, which few small and medium-sized companies will handle themselves. More often, they just rent "email as a service" from major vendors like Google or Microsoft.

What is delegated:

1. Building data centers and maintaining physical infrastructure
2. Networks and network security
3. Server capacities. These can be both virtual and bare metal.
4. Storage and space for data
5. Operating system
6. Frameworks and environments for applications
7. Application

Examples: CRM systems, email services, Enterprise resource planning (ERP)

In addition to the classic three models, many others are often highlighted, either for marketing purposes or if the model does not fit well into the described options.

Database as a Service (DBaaS)
You are provided with a database with high-level management tools. Essentially, a variety of SaaS.

Function as a Service (FaaS)
A model very similar to PaaS, but the level of abstraction for the developer is even higher. When scaling, the developer does not see the server processes being generated but pays exclusively for the function's runtime. For example, this could be an API for an online store, where payment is directly proportional to the number of requests from customers. However, there is a rather unpleasant risk of budget overruns in case of DDoS attacks and sudden bot raids.

Typical examples: AWS Lambda, Google Cloud Functions, Microsoft Azure Functions, IBM/Apache's OpenWhisk

Anything as a Service (XaaS)
An umbrella term that includes everything else. For example: Storage as a Service, Network as a Service, Disaster Recovery as a Service.

Delegation is wonderful. You can focus on business needs and quickly start generating profit and satisfying your clients' needs, which is the main reason for creating a startup. In the initial stages, when you are just starting to get your first visitors, everything is fine. You achieve significant savings on DevOps engineers' salaries, who create and maintain your infrastructure and code deployment, DBA specialists who deploy and maintain your databases. Security engineers are also not your headache – all security issues are handled by the cloud provider.

Problems usually arise suddenly as your business grows. This is particularly evident in the case of FaaS. Creating serverless applications on something like AWS Lambda is very quick and convenient. You focus only on new features and immediately implement them, increasing your business's value to customers. Unfortunately, the downside of this simplicity is the need to strictly control the efficient use of cloud resources. When, during a surge in visitors, inefficient code generates 80+ million requests, you will be extremely unpleasantly surprised by the bill from the cloud provider. Billing almost always works with a certain delay, and the set limits often do not react in time to short spikes.

Remember that for such models, you must always pay close attention to optimization:

1. Number of function executions. Launch only what is needed. Avoid unnecessary requests. Cache if possible.
2. Duration of their work. Strictly monitor timeouts in your code and logic. Hundreds of thousands of function executions hanging for a long time waiting for an external event will not make you happy.
3. Memory allocated for the function

Data transfer. Pay attention to the direction of data flows. They are billed very differently within and between regions. Transmit only what is truly necessary.

In general, like any tool, *aaS models can be used to quickly scale your business. Let's try to look at a simple hypothetical example:

DBA Employee:
● Salary: $100,000/year
● Additional costs (bonuses, work equipment, etc.): 30% of salary.
● Total costs: $130,000/year

DBaaS - 1 DB:
● Subscription cost: $2,000/month
● Additional costs for storage and computing: $500/month
● Monthly cost: $2,500
● Annual cost: $30,000/year

In reality, DBA costs will be even higher since they can get sick, go on vacation, or be absent for other reasons. Therefore, employee costs will most likely be at least twice as high.

All this math works well as long as:
● You are small
● You have 1-3 lightweight databases
● You do not need to optimize complex heavy queries
● The architecture is relatively simple, and you can easily migrate data if necessary and restore it in case of an emergency.

As soon as the number and size of databases exceed a certain mark, costs quickly start consuming the budget. I know of a case where a mid-sized company, after abandoning its DBAs and migrating to AWS, saw a roughly 20-fold increase in operational expenses. Remember, there are no clouds - only servers you do not manage.

1. All tools are important to use correctly. Optimization mistakes are cheap while you are a small company. Later, they will shoot you in the foot.
2. *aaS models will help you quickly scale your business. You can easily increase capacity or add an infrastructure element, and then just as quickly cut costs. This is not possible with permanent employees.
3. In the long run, at volumes above average, your employees are more cost-effective than vendor services.
4. The downside of convenient integration with various FaaS and PaaS is heavy vendor lock-in. In case of necessity, you will not be able to quickly migrate to another provider. The higher the degree of delegation of functions, the greater the dependency of your business on the vendor.

And most importantly, remember that the right infrastructure is still built by people. Everything works magically out of the box only in marketing brochures. Reality hits hard when your business needs to at least minimally deviate from what is built into the vendor's boxed product.

If you feel that *aaS is no longer sufficient for you, and you are not ready to expand your own team, attracting experienced specialists for specific projects will be the most cost-effective and transparent solution in terms of expenses. Contact us, we are always here to take care of your infrastructure and business.