Demystifying the Latest Cloud Terminology – Part 2

In Part 1 of this blog series, I covered what cloud native applications and microservices are – and left you dangling as to what containers are. I also mentioned “bees” but that’s irrelevant. Here, in Part 2, I explain:

• Containers
• Hybrid and composite clouds
• Software-defined everything

---

What Are Containers?

The history of containers is almost as long as the history of virtual machines, although people seem to think containers are new. Nope – containers have been around for decades and, in a cloud context, they’ve been used by Google for nearly ten years already. The reason everyone is talking about them now is because they’ve been made easier to use by a company called Docker. That reminds me, I need a new pair of chinos.

Containers can be thought of as light-weight, operating system-dependent virtual machines. They don’t have the isolation qualities of real virtual machines but they don’t have all the heaviness of virtual machines either, such as the longish boot times and the self-contained operating system.

Containers have mostly been available on Linux and they use operating system features to isolate resources for an application. So an application running inside a container thinks the world is as big as the container and has no idea that it’s “riding on the back of one of four elephants (physical servers), which are on the back of a large turtle (data center) swimming through space.” It’s all sounds very Yellow Submarine.

Containers are loved by developers, since Docker solutions went mainstream, because they are easy to configure and lightning fast to use. When you’re a developer having to use multiple systems (test, staging, and production) and running multiple tests each day, then containers compare to virtual machines like a Ferrari Formula 1 car compares to a family estate – yes I’m showing my Italian roots here. Containers aren’t without their downsides though. Microservices aren’t easy to do and they are not always the right answer. In fact, Martin Fowler recommends starting with a monolithic approach and refactoring an application if it emerges that a microservices approach might be better.

Also, at a technical level, it’s important to note that containers aren’t virtual machines. This means they don’t have the isolation features of virtual machines and so they are less secure. A virtual machine is like a house on a shared estate; a container is like a rented room in a shared house on a shared estate. Containers are stateless, which means that they are built brand new each time. When you turn them on, their configuration decides how the container is built, which includes connecting to services (which might be stateful). There are no persistent disks and the networking is “interesting” in that you can have hundreds or thousands of ephemeral containers popping up and down on your network.

What Are Hybrid and Composite Clouds?

In 2011 NIST defined the cloud using three perspectives:

1. The service model (IaaS, PaaS, SaaS, and there are now more)
2. The deployment model (public, private, hybrid, and there are now more)
3. The five essential characteristics of cloud

The deployment model has generated much industry debate, with the general acceptance now being that this is actually a spectrum of possible models, ranging from “I only do on-premise private cloud” on one-side, all the way across to “I’m all-in on public cloud” on the other. Many people are, in reality, somewhere along the spectrum and still moving – using a combination of the two but generally moving in one direction or the other.

Hybrid, or composite, cloud has been a dominant theme by purveyors of private clouds (think both traditional non-cloud hardware and software vendors). Although recently, some public clouds (think new cloud service providers such as AWS and Microsoft Azure) have embraced the notion of hybrid cloud, but mostly from the perspective of them reaching into your data center to pull your applications and data into their public cloud.

Be warned though, hybrid cloud is the most difficult thing. Ever. It looks great on PowerPoint slides, Visio diagrams, and whiteboards but the reality is much blurrier, and implementation is very varied. Hybrid cloud can be expensive, complex, and difficult. And Gartner recently reported that 95% of private clouds are failing, with 31% blaming the failure to change in the operational model.
If you read vendor marketing you could be forgiven for thinking that you could buy a hybrid cloud with your credit card. You can’t – it’s a “solution” not a product, and it’s a complex solution at that. There’s no universally-agreed idea in the industry of what a hybrid cloud is, and if you look at the online cloud architectures from all the top vendors, you’ll find none of them agree on what a hybrid cloud architecture is. This is because they’ve molded the hybrid cloud solution to fit their product portfolio, rather than the other way around.

Finally, there are definitely situations that make sense to connect on-premise to public clouds if you want to leverage things like cloud storage for backup and archive. You can even connect the other way, from public cloud to on-premise to point cloud-based big data analytics at your on-premise datasets. And to do this, you really don’t have to have complicated hybrid cloud management software.

What Is Software-Defined Everything?

When Marc Andreessen said “Software is eating the world” he was talking about companies like Uber, Airbnb, and others that are using software with cloud, mobile, social, and analytics to disrupt traditional business models. This concept has been picked up by the traditional IT vendors who have moved from calling their products “cloud-ready” to now prefixing their existing products with “software-defined.”

You’ll see this in most IT sectors and in most cases, software-defined means the management or “control plane” has been decoupled from the “data plane” (think storage disk or network port). For example:

• Software-defined storage: Data is still stored on physical media such as flash, disk, and tape, so software-defined refers to the control plane, which was software-defined before but now it might have an API or, more likely, be more distributed or more converged depending on your perspective.
• Software-defined network: The network is still made up of ports and cables. But whereas previously the software was proprietary and ran on an application specific integrated chip (ASIC), the control plane now runs somewhere else, could be open source, probably runs on cheap servers instead of expensive routers, and uses an API.
• Software-defined datacenter: There are now software data centers inside physical datacenters. Think of a virtual datacenter that creates software virtual machines, networks, and storage (on top of real stuff, of course), probably via an API.

The real meaning of software-defined is when it applies to businesses and their processes and operations. And this is what Marc originally meant. It means that a business process, from order to cash, is written in software and uses APIs and cloud services. These companies that software-define their businesses are the ones that are really disrupting and winning markets.

So there you have it, five examples of cloud terminology hopefully demystified by yours truly. Is there anything else I should cover?

Image credit