Cloud Data Centers: Core Concepts - Part 4

In this episode, hosts Lois Houston and Nikita Abraham, along with Principal OCI Instructor Orlando Gentil, break down the differences between Infrastructure-as-a-Service, Platform-as-a-Service, and Software-as-a-Service.

 

The conversation explores how each framework influences control, cost efficiency, expansion, reliability, and contingency planning.

 

Cloud Tech Jumpstart: https://mylearn.oracle.com/ou/course/cloud-tech-jumpstart/152992

Oracle University Learning Community: https://education.oracle.com/ou-community

LinkedIn: https://www.linkedin.com/showcase/oracle-university/

X: https://x.com/Oracle_Edu

 

Special thanks to Arijit Ghosh, David Wright, Kris-Ann Nansen, Radhika Banka, and the OU Studio Team for helping us create this episode.

-----------------------------------------------------

Episode Transcript:

00:00

Welcome to the Oracle University Podcast, the first stop on your cloud journey. During this series of informative podcasts, we’ll bring you foundational training on the most popular Oracle technologies. Let’s get started!

00:25

Nikita: Welcome to the Oracle University Podcast! I’m Nikita Abraham, Team Lead: Editorial Services with Oracle University, and with me is Lois Houston, Director of Innovation Programs.

Lois: Hey there! Last week, we spoke about how hypervisors, virtual machines, and containers have transformed data centers. Today, we’re moving on to something just as important—the main cloud models that drive modern cloud computing.

Nikita: Orlando Gentil, Principal OCI Instructor at Oracle University, joins us once again for part four of our discussion on cloud data centers. 

01:01

Lois: Hi Orlando! Glad to have you with us today. Can you walk us through the different types of cloud models? 

Orlando: These are commonly categorized into three main service models: Infrastructure-as-a-Service, Platform-as-a-Service, and Software-as-a-Service.

Let's use the idea of getting around town to understand cloud service models. IaaS is like renting a car. You don't own the car, but you control where it goes, how fast, and when to stop.

In cloud terms, the provider gives you the infrastructure—virtual machines, storage, and networking—but you manage everything on top—the OS, middleware, runtime, and application. Thus, it's like using a shuttle service. You bring your bags—your code, pick your destination—your app requirements, but someone else drives and maintains the vehicle.

You don't worry about the engine, fuel, or routing planning. That's the platform's job. Your focus stays on development and deployment, not on servers or patching. SaaS is like ordering a taxi. You say where you want to go and everything else is handled for you. It's the full-service experience.

In the cloud, SaaS is software UXs over the web—Email, CRM, project management. No infrastructure, no updates, just productivity. 

02:32

Nikita: Ok. How do the trade-offs between control and convenience differ across SaaS, PaaS, and IaaS?

Orlando: With IaaS, much like renting a car, you gain high control. You are managing components like the operating system, runtime, your applications, and your data. In return, the provider expertly handles the underlying virtual machines, storage, and networking. This model gives you immense flexibility.

Moving to PaaS, our shuttle service, you shift to a medium level of control but gain significantly higher convenience. Your primary focus remains on your application code and data. The provider now takes on the heavy lifting of managing the runtime environment, the operating system, the servers themselves, and even the scaling.

Finally, SaaS, our taxi service, offers the highest convenience with the lowest control level. Here, your responsibility is essentially just using the application and managing your specific configurations or data within it. The cloud provider manages absolutely everything else—the entire infrastructure, the platform, and the application itself.

03:52

Nikita: One of the top concerns for cloud users is cost optimization. How can we manage this?

Orlando: Each cloud service model offers distinct strategies to help you manage and reduce your spending effectively, as well as different factors that drives those costs.

For Infrastructure-as-a-Service, where you have more control, optimization largely revolves around smart resource management. This means rightsizing your VMs, ensuring they are not overprovisioned, and actively turning off idle resources when not in use.
Leveraging preemptible or spot instances for flexible workloads can also significantly cut costs. Your charges here are directly tied to your compute, storage, and network usage, so efficiency is key.

Moving to Platform-as-a-Service, where the platform is managed for you, optimization shifts slightly. Strategies include choosing scalable platforms that can efficiently handle fluctuating demand, opting for consumption-based pricing where available, and diligently optimizing your runtime usage to minimize processing time.

Costs in PaaS are typically based on your application usage, runtime hours, and storage consumed. Finally, for Software-as-a-Service where you can consume a ready-to-use application, cost optimization centers on licensing and usage.

This involves consolidating tools to avoid redundant subscriptions, selecting usage-based plans if they align better with your needs, and crucially, eliminating any unused license. SaaS costs are generally based on subscription or per user fees. Understanding these nuances is essential for effective cloud financial management. 

05:52

Lois: Ok. And what about scalability? How does each model handle the ability to grow and shrink with demand, without needing manual hardware changes?

Orlando: How you achieve and manage that scalability varies significantly across our three service models. For Infrastructure-as-a-Service, you have the most direct control over scaling. You can implement manual or auto scaling by adding or removing virtual machines as needed, often leveraging load balancers to distribute traffic. In this model, you configure the scaling policies and parameters based on your specific workload.

Moving to Platform-as-a-Service, the scaling becomes more automated and elastic. The platform automatically adjusts resources based on your application's demand, allowing it to seamlessly handle traffic spikes or dips. Here, the provider manages the underlying scaling behavior, freeing you from that operational burden.

Finally, with Software-as-a-Service, scalability is largely abstracted and invisible to the user. The application scales automatically in the background, with the entire process fully managed by the provider. As a user, you simply benefit from the application's ability to handle millions of users without ever needing to worry about the infrastructure. Understanding these scaling differences is crucial for selecting the right model for your application's need. 

07:34

Join the Oracle University Learning Community and tap into a vibrant network of over 1 million members, including Oracle experts and fellow learners. This dynamic community is the perfect place to grow your skills, connect with likeminded learners, and celebrate your successes. As a MyLearn subscriber, you have access to engage with your fellow learners and participate in activities in the community. Visit community.oracle.com/ou to check things out today! 

08:05

Nikita: Welcome back! We’ve talked about cost optimization and scalability in cloud environments. But what about ensuring availability? How does that work? 

Orlando: Availability refers to the ability of a system or service to remain accessible in operational, even in the face of failures or extremely high demand.

The approach of achieving and managing availability, and crucially, your role versus the provider's differs greatly across each model. With Infrastructure-as-a-Service, you have the most direct control over your availability strategy.
You will be responsible for designing an architecture that includes redundant VMs, deploying load balancers, and potentially even multi-region setups for disaster recovery.

Your specific roles involves designing this architecture and managing your failover process and data backups. The provider’s role, in turn, is to deliver the underlying infrastructure with defined service level agreements, SLAs, and health monitoring.

For Platform-as-a-Service, the platform itself offers a higher degree of built-in, high availability, and automated failover. While the provider maintains the runtime platform’s availability, your role shifts.

You need to ensure your application's logic is designed to gracefully handle retries and potential transient failures that might occur. Finally, with Software-as-a-Service, availability is almost entirely handled for you. The provider ensures fully abstracted redundancy and failover behind the scenes.

Your role becomes largely minimal, often just involving a specific application’s configurations. The provider is entirely responsible for the full application uptime and the underlying high availability infrastructure. Understanding these distinct roles in ensuring availability is essential for setting expectations and designing your cloud strategy efficiently.

10:19

Lois: Building on availability, let’s talk Disaster Recovery.

Orlando: DR is about ensuring your systems and data can be recovered and brought back online in the event of a significant failure, whether it's a hardware crash, a natural disaster, or even human error.

Just like the other aspects, the strategy and responsibilities for DR vary significantly across the cloud service models. For Infrastructure-as-a Service, you have the most direct involvement in your DR strategy.

You need to design and execute custom DR plans. This involves leveraging capabilities like multi-region backups, taking VM snapshots, and setting up failover clusters. A real-world example might be using Oracle Cloud compute to replicate your VMs to a secondary region with block volume backups to ensure business continuity. Essentially, you manage your entire DR process here.

Moving to Platform-as-a-Service, disaster recovery becomes a shared responsibility. The platform itself offers built-in redundancy and provide APIs for backup and restore. Your role will be to configure the application-level recovery and ensure your data is backed up appropriately, while the provider handles the underlying infrastructure's DR capability.

An example could be Azure app service, Oracle APEX applications, where your apps are redeployed from source control like Git after an incident. Finally, with Software-as-a-Service, disaster recovery is almost entirely vendor managed.

The provider takes full responsibility, offering features like auto replication and continuous backup, often backed by specific Recovery Point Objective (RPO) and Recovery Time Objective (RTO) SLAs.

A common example is how Microsoft 365 or Salesforce manage user data backups in restoration. It's all handled seamlessly by the provider without your direct intervention. Understanding these different approaches to DR is crucial for defining your own business continuity plans in the cloud.

12:46

Lois: Thank you, Orlando, for this insightful discussion. To recap, we spoke about the three main cloud models: IaaS, PaaS, and SaaS, and how each one offers a different mix of control and convenience, impacting cost, scalability, availability, and recovery. 

Nikita: Yeah, hopefully this helps you pick the right cloud solution for your needs. If you want to learn more about the topics we discussed today, head over to mylearn.oracle.com and search for the Cloud Tech Jumpstart course. In our next episode, we’ll take a close look at the essentials of networking. Until then, this is Nikita Abraham…

Lois: And Lois Houston, signing off!

13:26

That’s all for this episode of the Oracle University Podcast. If you enjoyed listening, please click Subscribe to get all the latest episodes. We’d also love it if you would take a moment to rate and review us on your podcast app. See you again on the next episode of the Oracle University Podcast.