Microservices are Real, the Cloud not so Much
The wifi did not work on the plane from Seattle to Denver. It was .TXT time. At least I could write something for my intro to the “clouds” track on a text file for Gluecon, one of the best conferences in tech (IMHO). I had started the day in Vancouver B.C., after having spent the past two days at OpenStack, an organization that has grown to such an extent that they had 6,000 people attending their conference.
In Vancouver I sat down with Duncan Johnston-Watt of Cloudsoft, one of our sponsors at The New Stack, and two other writer/analysts: Ben Kepes and Paul Miller, who both write for Forbes, work as analysts and do consulting.
The conversation turned to the work Paul, Ben and I do. We talked about the perspectives writers bring to this world of the new stack. Shop talk, sure, but it helped me think through what I could share based on all those conversations I’ve had with people about the world of the “cloud.”
What came of all this? What follows is a construct that explores the “cloud” for the talk I gave at Gluecon. I have since filled it out to some extent following the track based in part what was discussed at the conference.
The Cloud Does Not Exist
First, let’s break things down by the standard ways to think about the cloud. The cloud is a metaphor to understand the complexities of services and software on sophisticated, fast and distributed infrastructure. It’s not AWS, nor OpenStack, nor the virtualized data centers owned by the big banks.
What we really have are islands of privately owned data centers. Some are more efficient than others, but they are still largely isolated, and that scenario does not look like it is going to change soon.
The more efficient data centers are increasingly application-centric. But in reality, these operations are not that much different compared to the virtualized operations that most developers have come to know. Developers run apps on a service that manages virtual machines. The VM is launched and managed from a physical server or a cluster. These are machines that people operate. The people who work on these machines perform almost the same work that has been done for the past two decades.
The changes, the new thinking, comes from developers and a new generation of operations teams that manage application at scale. The more efficient service providers have adapted by offering services on the infrastructure they have built. They have learned that people can’t manage the machines and the services with an inefficient infrastructure. The machines need to do the work so multiple services can be deployed and managed.
But it’s a lot of work just to keep up. There is just too much to follow and analyze. For example, Donnie Berkholz of 451 Research pointed out in his presentation at Gluecon how programming languages are fragmenting:
Here’s his full presentation:
Complexities abound as more layers of abstraction get added to virtualized environments. But the VM-centric way is getting more efficient. Mirage OS, for example, embodies the concept of unikernels, which are specialized OS kernels that are written as a high-level language and act as individual software components. That’s according to a talk by Anil Madhavapeddy and David J. Scott given last year. Here are some other unikernels getting developed that they cite. To Donnie’s point, notice the number of languages represented in the list:
Interestingly, as we wrote about earlier this month, Drawbridge is a kind of virtualization-driven isolation mechanism created by Microsoft Research, originally built as a testing mechanism. Its design enabled processes that its creators dubbed “picoprocesses” (“microservices” sounds too much like the company trademark) to run on minimalized kernels addressed remotely by way of APIs. Without even realizing it at first, Microsoft was creating a containerization architecture.
Robots in the House
Which brings us to containers and the symbolism they embody for what we mean by being app-centric. A container is a process that is hosted on a machine. But what changes does that bring? Undoubtedly a deeper complexity, as containers in production will be in numbers an order of magnitude more than in comparison to virtual machines. Then there is the orchestration to consider, the underlying networks, how storage is managed and the monitoring that has to be at the center of the universe.
With more complexities comes a greater need for software to program the machines. The machines still require people to maintain them, but isn’t that a task that a robot will eventually do? Checking the instruments, the health of the cluster, etc. Robots can do that, right? The software will become the network and the storage, too, and the robot will be programmed to know the language that the machines are speaking as the data passes between them. It’s too complex for the human mind to understand. No number of people can do the work that machines do, much less translate the data in its passing. We’ve learned that data centers can operate with just a few people. It’s the orchestration that requires management.
It’s a reminder of a story Scott Fulton did about Google’s Borg and the choice they made for not virtualizing:
“The vast majority of the Borg workload does not run inside virtual machines,” the Borg team writes, “because we don’t want to pay the cost of virtualization.”
The team does not go into detail as to what that cost consisted of, but it’s a very safe bet they were referring to 1) an extra hypervisor layer, which leads to 2) a complex division of labor along two separate scales, limiting overall system scalability, not to mention 3) the monetary cost in procuring, supporting, and maintaining the necessary hardware.
The application, with its container orchestration, gives plenty of reasons why microservices are so often discussed in conversations with technologists. Adrian Cockcroft, in his keynote at Gluecon, discussed the progression from virtual machines to containers, which allows for deployments taking seconds to live for minutes or hours, compared to VMs, which deploy in minutes and live for weeks. AWS Lambda is even more ephemeral, responding in milliseconds and living for seconds.
It’s increasingly evident that efficiency and complexity are inevitably paired. More so, the question becomes who will handle the complexity? The human managing the machine, or the robot managing the complexities of the machines and how they communicate?
