What provisioning the Cloud infrastructure and cooking have in common…
I like to cook. Sometimes, I’ll grab whatever ingredients I have on hand, put them in a Dutch oven, throw in a few spices, and make a delicious casserole that can never be repeated. At other times, I’ll follow a recipe to the letter, measure and weigh everything that goes in, and produce a great meal that I can repeat consistently each time.
When provisioning servers and blades for a Cloud infrastructure, the same 2 choices exist: follow your instinct and build a working (but not repeatable) system, or follow a recipe that will ensure that systems are built in an exacting fashion, every time. Without a doubt, the latter method is the only way to proceed.
Enter the Cisco Tidal Server Provisioner (an OEM from www.linmin.com) , an integral component of Cisco Intelligent Automation for Cloud and Cisco Intelligent Automation for Compute. TSP lets you easily create “recipes” that can be easily deployed onto physical systems and virtual machines with repeatability and quality, every time. These recipes can range from simple, e.g., install a hypervisor or an operating system, to very complex: install an operating system, then install applications, run startup scripts, configure the system, access remote data, register services, etc.
Once you have a recipe (we call it a Provisioning Template), you can apply it to any number of physical systems or virtual machines without having to change the recipe. Some data centers use virtualization for sand box development and prototyping, and use physical servers and blades for production. Some data centers do the opposite: prototype on physical systems, then run the production environment in a virtualized environment. And of course, some shops are “all physical” or “all virtual”. Being able to deploy a recipe-based payload consistently on both physical and virtual systems provides the ultimate flexibility. Yes, once you’ve created a virtual machine, you’ll likely use VMware vSphere services to deploy, clone and move VMs, but as long as you’re using TSP to create that “first VM”, you have the assurance that you have a known-good, repeatable way of generating the golden image. When time comes to update the golden image, don’t touch the VM: instead, change the recipe, provision a new VM, and proceed from there.
The USS Cisco took off for the Gestalt IT Networking Tech Field Day 2 with Captain Omar Sultan (see picture below, courtesy of techfieldday.com), Data Center Solutions Sr. Marketing Manager, at the helm. Tech Field Day networking industry experts gathered on the bridge, cleverly disguised as the Cisco Cloud Innovation Center (CICC) Lab, for an informal, no-holds-barred conversation on recent Nexus portfolio announcements, the continued march towards automated provisioning of cloud services and ever-evolving VM networking technologies.
Captain Omar at Cisco Networking Tech Field Day 2
For those who weren’t at the event or haven’t seen the video recording yet, please excuse my unabashed geekiness, but you’ll have to watch the first minute of the video to get the above reference. As a new member of the Data Center Solutions Marketing team, this is also my first foray into the Cisco blog-o-sphere, so I hope to share some fresh viewpoints on the day’s events.
Several things were made very apparent during the Tech Field Day session:
Where I grew up, you could buy individual cigarettes. While I played ball at the park, I’d see the young men approach the paper kiosk to get a cigarette. Not a pack, just one lonely stick. The customers overpaid on per-cigarette basis but it helped them manage their budget I’d watch them and think nothing of it. It was normal.
People also could buy shampoo in ketchup-sized packages. Unilever still sells them in India. I grew up in the third world, it was the bronze age, but only only on good days. We’re back to bronze with cloud computing, and I’m hyper ready.
For me, the biggest invention cloud computing brings about is unreliable level services. And how important it is to have low quality service levels available on a metered basis. A metered basis the customer can manage. Hear me out.
Today, Amazon’s block storage is unpredictable for databases. The latency in the network is funky. Machines fail to start. Machines don’t fail to fail. Service levels in the cloud don’t exist.
This is not your typical datacenter. It’s a bronze age datacenter. No great expectations, but diminished expectations. And for a young segment of the market, it’s just right and couldn’t be be better.
I sat down with a young start up and asked them why do they use cloud computing if it’s so unreliable, if it requires so much more coding.
Answer: They have more time than money. And the money they have, they have to be parsimonious, avaricious and cautious. They are ok coding more to deal with the cloud’s weirdness. But running out of cash would kil them. The bronze age suits them just fine.
So all the cool kids in Silicon Valley are super excited about writing software for “Designed-to-Fail’ infrastructure. We can’t wait for a chaos monkey to spank us. Well… that’s a San Francisco thing.
So what’s the lesson of this meditation? It’s that service levels are important. Too high and they prevent innovation, too low and they prevent operation.
For a while now, I’ve been bothered with the word commodity. Like legacy, greenfield, there are value judgements implicit in the words. When we apply them to technology adoption, they serve as marketing oars to rock the new tech boat, but are not useful when you need a fish for dinner.
And this article on the NYSE community cloud is a great example of why there are no commodity clouds.
The NYSE’s community cloud platform is design to ensure that its customers are treated fairly, and it ensures them that the maximum latency that any user will experience in this data center is 70 microseconds (one millionth of a second) round-trip for any message, O’Sullivan said.
“We guarantee that nobody will have an advantage on the network,” said O’Sullivan. “It’s designed to be a level playing field for trading.
Basically, this compute service comes with a latency service level and a promise that no one gets better latency, thus ensuring a level playing field for traders.
So it’s “level-playing-field-as-a-service;” which is right and ridiculous. Right because that’s the differentiators; ridiculous that I have to pull the *aaS to describe what before I would have simply called “service.”
There was a time when coffee was called a commodity, then Howard Schultz of Starbucks came along, and Peet’s came along, and next, we are all paying $5 for coffee.
After just getting back from a great week at Cisco Live 2011, I wanted to highlight one of the demonstrations that garnered a huge amount of attention from attendees (customers & partners). This is from our CITEIS project, which is Cisco’s internal Private Cloud.
This demonstration highlights a number of unique Cisco Data Center technologies, along with partner technologies: