This is themost comprehensive form of offering by cloud providers, where the end-user simply consumes application features via APIs or directly through their browser over the internet. The end-user is not responsible for software patches, overall maintenance, and application uptime. The cloud provider, however, needs to take care of security aspects around such offerings. Generally, these are multi-tenant systems with common storage for multiple users.
In some form or the other, we all use SaaS applications these days. Common examples are email and cloud-based file storage. In Chapter 1, we discussed the importance of undifferentiated heavy lifting being taken over by cloud services. SaaS excellently fits that concept. The end-user consumes the software application without having to worry about anything else.
This model is the least flexible in terms of change and control, as you are bound by the service boundaries and limitations coming from the provider side. You have less influence on the software features. SaaS is great for companies who don’t want to take ownership of applications that they can simply consume as-is and who don’t want to reinvent the wheel.
Let’s try to visually map our learnings so far to different cloud service tiers and the varied levels of abstraction and control they offer. Different layers are highlighted in Table 2.1, where we can see the ones you have to manage in white and the ones managed by cloud provider in blue:
| On-premises | IaaS | PaaS | SaaS |
| Applications | Applications | Applications | Applications |
| Data | Data | Data | Data |
| Runtime | Runtime | Runtime | Runtime |
| Middleware | Middleware | Middleware | Middleware |
| O/S | O/S | O/S | O/S |
| Virtualization | Virtualization | Virtualization | Virtualization |
| Servers | Servers | Servers | Servers |
| Storage | Storage | Storage | Storage |
| Networking | Networking | Networking | Networking |
Table 2.1: Layers of management under different cloud service tiers
So far, we have covered the underlying principles and abstractions offered by the three cloud tiers. Next, let’s have a look into the key questions you should answer when deciding on what works best for your use case.
What to choose when
Getting started with any of these offerings is fairly simple, but aligning these decisions with long-term success needs several considerations. As we just discussed, these service tiers come with different levels of abstraction. This directly translates to the flexibility you would have in terms of modifications and extensions, should a need arise. Let’s take a look at what factors you need to evaluate and the impact they could have.
Simplicity versus control
Striking the right balance is important to ensure the success and agility of your software teams. The service tier capabilities need to match the software stack you are working with. Whether the team is building a stock trading application or a static website will largely define the level of customization and control they expect from the platform or the underlying infrastructure components. On the other hand, for developing a PoC, developers don’t need extensive customization and performance tuning. This is where AWS PaaS offerings such as AWS Elastic Beanstalk could give them a jumpstart while handling all infrastructure details such as load balancers, DNS and EC2 compute instances.
PaaS requires a certain level of adaptation in the application itself for the user to be able to utilize the framework. In some cases, this introduces a cloud provider lock-in as the application cannot be easily migrated as-is to another service provider in the future.