Cloud Foundations: Making Sense of Monoliths, Microservices, and the Economics of the Cloud

Cloud Foundations, part of my M.S. in AI Engineering coursework at Quantic, was a genuinely new area of learning for me. I had dabbled with AWS before, spinning up a service here and there, but this course was a deeper dive into how cloud systems are actually architected and why they're built the way they are.

The first big distinction was Monolithic versus Microservices architectures. A monolith bundles everything, the UI, business logic, and data access, into a single deployable unit. It's simple to build and reason about early on, but it gets harder to scale and update as it grows. Microservices break that same system into independent, loosely coupled services that can be developed, deployed, and scaled on their own. The tradeoff is clear: monoliths trade long-term flexibility for short-term simplicity, and microservices trade operational complexity for independent scalability.

From there, the course walked through how operating systems function on physical machines versus virtual machines, which set up the real payoff: containerization. Seeing the progression from bare-metal, to VMs, to containers made it obvious why containers caught on. VMs virtualize an entire operating system, which is heavy. Containers virtualize at the application layer instead, packaging just the code and its dependencies, so they're lighter, faster to start, and more portable across environments.

The cloud deployment models, IaaS, PaaS, FaaS, and SaaS, took the longest for me to cleanly separate. They sit on a spectrum of how much infrastructure you manage versus how much the provider manages for you. IaaS hands you raw virtual infrastructure, networking, storage, and compute, and you handle everything above that. PaaS takes care of the underlying infrastructure so you can focus purely on code. FaaS goes further still, letting you run individual functions without thinking about servers at all. SaaS sits at the far end, where the provider manages everything and you simply use the finished application. Having years of experience as a SaaS end user, without ever thinking about what sat underneath, actually helped this click once I could map tools I already use every day onto that spectrum.

The last piece was the business side: Total Cost of Ownership, CAPEX, and OPEX, and how they tie into economies of scale. On-premises infrastructure is a CAPEX-heavy model, large upfront investment in hardware that you own and depreciate over time. Cloud infrastructure shifts that to OPEX, an ongoing operating expense that scales with usage instead of a big upfront bet. Understanding TCO means looking past the sticker price of either option and accounting for maintenance, staffing, downtime, and scaling costs over the full lifecycle. That's the lens cloud providers use to make the economies-of-scale argument: by pooling infrastructure across thousands of customers, they can offer lower marginal costs than most companies could achieve running their own data centers.

Coming out of this course, I have a much clearer mental model of what's actually happening beneath the AI applications and products I build, from the architecture decisions to the economics driving why cloud-native is the default today.

This reflects my personal learning experience and does not represent Quantic or reproduce course materials

Adding another checkpoint here, as I continue along on the course I will share my journey learning the new material. Thank you for reading!