Feature
The software architecture of the future is microservices. That much is certain, but what’s up in the air now is whether that future can be pushed far enough ahead for investments in present architecture to be fully amortized before they’re finally allowed to expire.
VMware CEO Pat Gelsinger started off his company’s announcements today around virtualized microservices with a bridge metaphor. When you see a vendor break out the bridge metaphor, you realize it’s not a ferry or a steamboat or an airplane. It’s something that stays grounded on both sides.
Building a Bridge
“This is a picture that we believe faces every IT manager today,” Gelsinger said.
“Fundamentally, they have the vast majority of their assets and spending in the client/server world, and they need to plant their strategy for the emerging mobile/cloud world. And across that, they have nominally flat budgets. So how do they deal with that challenge?”
It was a long and drawn-out metaphor by way of introducing VMware’s answer to CoreOS, and more recently to last week’s announcement of Nano Server by Microsoft.
It’s VMware’s own minimalized Linux, called Photon, designed to run within remotely managed containers for microservices running on cloud platforms — particularly on Cloud Foundry, the open source services platform stewarded by Pivotal, a company spun off by VMware in 2013.
VMware CTO Kit Colbert introduced Photon as an integral part of future editions of the vSphere virtualization system. He described it a lightweight Linux designed not just for Docker containers but also CoreOS’s Rocket, whose first prototype was released last December, and the Pivotal Garden system re-engineered for use with Cloud Foundry.
Garden, Rocket and Docker are all systems for packaging a server-side virtual machine with only those portions of the operating system and supporting libraries necessary to it. By far, Docker has gained the most ground in this emerging market, though it’s still astonishingly young.
Container technologies threaten the stability of virtualization environments such as VMware’s vSphere, because they suggest the feasibility of hosting applications on a cloud platform without any of vSphere’s overhead. Virtual machines often host applications that were not designed for the cloud. Containers point the way to a new way of writing applications that are so designed.
VMware found itself acknowledging that fact Monday by at least addressing the need for what it calls “cloud-native applications.” Gelsinger and Colbert acted as though they were coining the phrase, as ifMicrosoft hadn’t launched Azure in 2008.
For its part Monday, Microsoft attempted to upstage VMware with a cloud services announcement of its own. A few hours prior to VMware’s event, Azure CTO Mark Russinovich published a blog postannouncing a microservices-specific hosting and management platform within the Azure cloud, called Azure Service Fabric.
Providing less detail than a Russinovich-penned message typically does, he promised a system that “provides the benefits of orchestration and automation for microservices with new levels of app awareness and insight.”
But he also mentioned the use of “both stateless and stateful microservices,” in a manner that stopped just short of invoking another bridge metaphor.
He did promise demonstrations, beginning next week at the company's Build 2014 conference in San Francisco.
What we can expect to see then, as well as at Microsoft's Ignite conference in Chicago the following week, are demonstrations of conventional applications being paired with Nano Server, shrink-wrapped in containers, and deployed to Azure with minimal extra provisioning. Inevitably, attendees will ask for a performance comparison between stateful and stateless applications.
And Russinovich is (at least typically) the kind of fellow who never leaves questions open.
The State of Statelessness
Statelessness and statefulness are less philosophical than their names may imply, though they’re just as esoteric.
All programs, as you can imagine, are comprised of lists of instructions. The first complex language interpreters enabled the reuse of instructions. For instance, the first BASIC moved the interpreter’s line pointer to a different line by stating its line number, as in GOTO 320.
Learning Opportunities
Webinar
Apr
24
The State of Outsourcing: At the Crossroads of AI, Quality, and Cost Savings
Learn how companies can maximize the results from their outsourcing investments.
Register
Webinar
Apr
30
Supercharge Contact Center Efficiency with Generative AI
Learn practical strategies to reduce post-call documentation time by over 8 minutes.
Register
Conference
May
1
Qualtrics X4 Salt Lake City 2024
Register
Webinar
May
2
Unleash AI for Crisis Management: Transform Threats into Triumphs
Learn how Sprinklr Insights provides real-time insights on current events, trends, and brand crises to empower your team.
Register
Webinar
May
9
Driving Customer-Centricity in the Financial Services Industry
Discover how financial organizations are leveraging generative AI technologies.
Register
Conference
May
9
An Irish Roundtable in the Valley: The Economic Impact of AI on the World of Work Stanford 2024
Exploring the Impact of AI On the World of Work with Irish diaspora leaders and tech business champions from the North of Ireland
Register
The first truly reusable code used functions with names instead of numbers. Control was passed to a function by giving it the data parameters it expected, and the function usually returned a single datum of output. Most of Microsoft Windows, by weight, is made up of libraries of reusable code designed to be called by other code. In fact, the word “application” was actually coined to mean the use of a library by a program.
The first monolithic applications were designed to be hosted and used on the machines they were installed on, which meant they all used the same libraries. Server/client applications created the division of labor necessary for a CMS, or other class of business application, to be used by multiple users.
State, in this scenario, is a way for the server part to keep track of what the user is doing with the client part. You’ve heard of “cookies;” they’re a way for a Web server to borrow a few bytes of storage on the client for remembering state. A stateful application, therefore, is one that uses some kind of state mechanism to enable it to pick up where it left off, when it has to switch between users.
Scaling a conventional CMS in the cloud typically means replicating the server portion, and load-balancing between the replicates to ensure even utilization. That works for a few hundred users on-premise; it fails for a few hundred thousand in the cloud.
Stateless services don’t need to keep track of state. They expect specific inputs and provide discrete outputs, and in the meantime interact with the outside world as little as possible.
It seems counter-intuitive as a programming practice, but consider this: Perhaps you’ve seen a chess master play a dozen or more games at once. And you wonder, how does he keep track of that many strategies at one time? The part you’re imagining is the state of each game.
But the best chess-playing algorithms in history don’t keep track of any strategies between moves whatsoever. Given a chessboard, they come up with the best next move, then forget what they just did. They’re stateless.
Playback
VMware is at least listening to the right experts. In a taped message during Monday’s announcement, Adrian Cockcroft — the visionary engineer behind the Netflix service platform — explained microservices quite correctly.
“What it’s really about is breaking large applications into smaller chunks that can be deployed individually, and which let the company, the product be more agile,” said Cockcroft.
He went on to describe an automation of software development processes where updates that previously required months of planning and re-engineering now take place in seconds. No, that’s not a misprint.
“When you’ve got a pipeline to production that takes seconds,” he continued, “it doesn’t make sense to try to redeploy five million lines of Java in some huge, monolithic tarball.
"What you really want to be doing is deploying the components of it and have everyone deploying all the time.”
So did VMware get Cockcroft’s message? Evidently not, as Kit Colbert proceeded just minutes later to characterize Photon (perhaps inaccurately, from a technical standpoint) as an integrationplatform whose aim is to fuse Linux with the virtualization layer, and in turn with containers.
Customers are already running vSphere, said Colbert, and what they’re looking for is a way for the container environment to be integrated with the conventional virtual machine environment.
Since Linux is becoming the standard building block around which Photon and other minimalistic systems are being formed, he remarked, “it really makes sense to try and simplify our customers’ lives by baking Linux into the hypervisor, melding them together, to have one unit for compute for these next-generation applications.
“What this means is, there’s simpler management, because you’re managing just one thing,” continued Colbert, “and the other piece is that it’s better security, since we can really drive deeper integration in there.”
In the past, Microsoft and Oracle were able to leverage fear of change as a motivator for continued investment in fixed platforms. “Fixed” doesn’t work very well in the cloud, although from some vendors’ perspectives, it would be nice if things could stay fixed for just a little while longer.
