Far too often, technology transitions are highlighted by the new bells and whistles. This is great for advertising, where “NEW” is the allure. But it frequently leaves IT organizations wondering how they can transition from their current environments to the added business value that these technology transitions enable. In the 1st Part of this webinar series we explored why companies need to be aware of Cloud Computing and the types of problems it can solve for their business. The 2nd webinar in the series (“Overcoming Rigidity and Complexity“) will look at ways to manage the transition to Cloud Computing.
Cisco UCS Servers and Blade Server Evolution, part 1, as the title suggests, discussed blade server evolution and why Cisco UCS is a game changer. Now let’s talk about what the implications are for blade server TCO (Total Cost of Ownership) and how Cisco Unified Computing System scales vs. legacy blade architectures.
Blade Server TCO and Scale
Scale is the crux of the problem that has historically been the barrier for blade servers to deliver on their initial promise. Scale for I/O. Scale for Servers. Scale for Management. Cisco identified these shortfalls in the traditional legacy blade architecture and came to the marketplace with an innovative, game changing redefined architecture – Cisco UCS.
As discussed in “part 1”, to move the bar for blade chassis, we to better consolidate I/O, management and scale. Enter Cisco UCS. Deliver everything at scale: servers and I/O and blade chassis and management etc. Deliver a new design, rather than retreading an old dead end chassis ‘building block’ design.
Efficiency and Scale by Design
The requisite new design is what Cisco delivered. Cisco UCS is a variable chassis count, variable server count, variable I/O capacity, smart scaling architecture.
Figure 1 is the Cisco design, a converged I/O (FCoE – lossless FC and Enet combined) that scales. It provides easy, efficient infrastructure scaling across: multiple chassis, multiple servers, racks, rows and yes, it even includes the integration of rack servers into the solution.
Figure 1: Cisco UCS architecture – 10 x 8 blade chassis = 80 blade servers, 20 cables (add more I/O by simply adding cables – easy scaling)
Figure 2 is a Non-Converged legacy blade chassis I/O architecture. More = more… of everything. More chassis to hold more blades is OK, that makes sense. But more Switches? More cables? More points of Management? More complexity? Not too good.
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.
Part 3 – The Winchester House and the Strategic Imperative for Architectural-led IT Evolution and Transformation
An “architectural-led” approach to your data center, indeed to your overall IT architecture, given the previous discussion in part 1 and part 2 of this blog, is therefore a strategic imperative for progressive organisations. We in Cisco don’t want to see your IT architecture have problems analogous to the Winchester House. So how can you achieve an “architectural-led” approach? I’ll cover 5 key recommendations in this, my final part of this trilogy :-).
Arguably the place to begin a Cisco UCS blade server journey would be with “Why Blade Servers”. ‘Blades’ are cool. There was “Blade Runner” (a cult classic) and the Wesley Snipes “Blade” movies, several TV series with ‘blade’ in the name, on and on; but for data centers and servers? Why blades? Where is the Blade Server TCO & ROI benefit that drives business decisions and therefore innovation and how do blade servers / chassis get there?
Blade servers have been around since about year 2000 and arguably came about as a way to make data center footprints smaller and reduce power consumption (reduced TCO). Nothing new here for blade enthusiasts. Rack servers were taking up more and more space and power in data centers. The concept of blades was brilliant, insightful and simple. Take as many common rack delivered functionalities (services) as possible, and package them together for delivery to a fixed group of servers. The easy targets for this were server power, cooling, and I/O (well, some I/O functions). To look at it another way, a blade chassis takes a data center rack with servers, I/O cables and switches, then shrinks them into a ‘building block unit’. Once you have the ‘unit’, put a single sheet metal wrapper around everything and voila, a blade chassis. Overly simplistic I know, but a close enough visual. If you want a step-by-step evolution, Sean McGee (a colleague of mine here at Cisco) did a darn good overview The “Mini-Rack” Approach To Blade Server Design.