Cloud Service Translation

This lesson teaches you to translate cloud service names into capabilities and make deliberate portability choices.

In this lesson, you will learn to:

• Match equivalent compute, storage, database, function, network, container, and analytics services across major providers.
• Explain vendor lock-in and identify design choices that make a workload easier or harder to move.
• Distinguish multicloud from hybrid cloud and evaluate when a second provider is justified.

Once an organization has a natural default provider, a new problem appears almost immediately: everyone around you talks about the cloud in a different dialect. A supplier's proposal mentions S3, a colleague who came from a Microsoft shop says Blob Storage, and an article you read describes Cloud Storage. All three are the same idea wearing different badges. Learning to hear past the brand names is one of the quickest ways to sound competent in a room full of stakeholders, and it sets up the more important question underneath: how hard would it be to move later?

Underneath the marketing, the three big providers sell a broadly similar set of building blocks, but each one gives those capabilities a different name. Use the capability first, then translate the label:

A virtual machine is a software-based computer you rent by the hour. Object storage is the bucket-style place you put photos, backups, and static website files. A managed relational database stores data in tables of rows and columns while the provider handles patching and backups. Managed Kubernetes starts and spreads containers across many machines. The table is a translation aid, not a promise that configuration, limits, or migration work are identical.

You do not need to memorize this as a table. What you need is the habit of asking, whenever someone says a product name, "what job does that do?" Once you can answer that, translation across providers is close to automatic.

Here, Simone, a business stakeholder, asks Chris, a cloud adviser, to translate a supplier's cloud-service proposal.

• Simone: The proposal quotes S3 and Lambda. We're an Azure shop. Does that mean the whole thing is unusable?
• Chris: Not at all. S3 is object storage, so on Azure that's Blob Storage. Lambda is code that runs when something triggers it, which is Azure Functions.
• Simone: So it's the same design, just different labels?
• Chris: The shapes match. The exact settings and limits differ, so someone still has to redo the configuration. But nobody's rewriting the application from scratch.

Notice that Chris translates the capability first and only then names the real work involved. That second half is where the next concept lives.

Vendor lock-in means becoming dependent on one provider in a way that makes leaving expensive, slow, or practically impossible. It is worth being precise here, because people often treat lock-in as something a provider does to you. In practice it is mostly something your design does to you.

Consider two ways to run the same small web application. In the first, you package it in a container and run it against standard PostgreSQL, an open database engine every provider offers. If you moved, you would rebuild the surrounding networking, permissions, and deployment plumbing, which is real work but bounded. In the second, you build on a fully proprietary stack: a provider-specific database with its own data format, provider-specific event triggers wiring the pieces together, and workflow logic written in that provider's own tooling. Moving now means rebuilding the data layer, the triggers, and the logic itself.

Consequently, the choices that increase lock-in are usually the convenient ones: proprietary data formats, provider-specific event and orchestration services, and managed features with no equivalent elsewhere. The choices that reduce it are open engines, containers, and keeping business logic in ordinary application code. None of this means proprietary services are wrong. They often save a small team enormous effort. It means the trade-off should be made deliberately, with someone able to say out loud what would have to be rebuilt.

You met these two terms in an earlier course, so treat this as a refresher with a little more depth attached. They get confused constantly, so hold them apart carefully. Multicloud means an organization uses two or more public cloud providers. Hybrid cloud means on-site systems are connected to a public provider so workloads can span both. When a board member says "go multicloud so we're never trapped," they are asking for the first, not the second.

What is worth adding here is when a second provider actually earns its place. A genuine business reason to run two providers does exist. A regulator or a major customer contract may require that a service can be delivered from a second provider, or an acquisition may arrive with an established estate that is cheaper to keep than to migrate. What is not a reason on its own is "flexibility." The costs are concrete: duplicated tooling, monitoring, and security configuration, plus a small engineering team that now has to be competent in two ecosystems instead of one. For most modest organizations, disciplined portable design on one provider buys more real optionality than a second provider ever will.

The takeaway to carry forward is that portability is bought through design decisions, not through provider logos or a second contract. Next you'll spot the pattern directly, matching a set of service names to the capability each one actually delivers, then testing which design choice leaves a small application easiest to move, before writing an assessment that a cost-conscious partner could act on.