I’ve been working with Cisco UCS since the very beginning. From the earliest days, whenever a customer ran into problems, I would often be asked to help figure out what was going wrong and to help fix it. Generally, this would involve a review of the system, and when we found less desirable configurations we would work with the partner and customer to clean things up. As a part of this process, I began documenting the good and the bad I saw, which evolved into what I describe as UCS “better” practices. This post aims to describe some of these practices and why they are useful. Follow-up posts will expand on this and include additional important practices. Read More »
How do you treat hardware like software? That question sounds like a contradiction, but we’ve been helping customers answer this question for the past six years with Cisco UCS. When you abstract all configuration and identity of hardware and transform it into software defined infrastructure (SDI), or better yet, policy driven infrastructure, you’re moving down the path of managing the “infrastructure as code.”
An essential aspect of this automated management is encapsulating the best practices of your server, storage and network experts as policies and templates. Cisco describes these as Service Profiles. The Service Profiles combined with the open Application Program Interface (API) in UCS provide a common “language’ for provisioning and configuring the infrastructure across the different types of devices. As we examined in a previous blog in this series, the combination of true SDI plus best practices defined in Service Profiles makes sure routine tasks are implemented consistently and correctly to reduce risk. Our customers are receiving tremendous benefits using Service-Profiles today with their existing UCS blade and rack systems, and we have extended this same management framework to our composable infrastructure.
Here’s where it gets fun: DevOps and Infrastructure as Code
“Did you say compostable infrastructure? That means using a biodegradable cardboard chassis that can go in the compost bin, right?” This conversation is more common than you think right now as people are introduced to this for the first time. So what exactly does composable infrastructure mean? Perhaps the best description I’ve heard comes from James Leach who recently told me “our customers need us to wrap code around the server, not sheet metal.” I think that concept gets at it pretty well, and no surprise since he’s one of the people behind our M-Series Modular Servers and Cisco System Link technology. Still, it’s early days for this concept in the industry and many customers we talk to haven’t been exposed to the term.
We took some time recently to interview Jed Scaramella from IDC to help explain it all. Here’s another segment in that series, this one focused on answering the question, “What is Composable Infrastructure?”
Composable infrastructure is is emerging out of two trends: disaggregated servers and software-defined infrastructure. Both are prerequisite capabilities: you need be able to take humpty dumpty apart AND put him together again. Disaggregation is where we unbind local shared storage and network I/O from the processor and memory. Subsystems are no longer bound by the server chassis or the traditional motherboard. Then, with a unified control plane and API, these physical and logical resources are pooled and management software composes the resources on demand, so the system can be created to conform to the unique requirements of the workload. That’s the software-defined part.
Path to “Infrastructure as Code”
While many are just beginning to talk about composable infrastructure as a future strategy (“Houston, we have a vision…”) Cisco has been executing on disaggregated systems and software defined infrastructure since the introduction of UCS, through three key areas of innovation:
We recently sat down with IDC analyst, Jed Scaramella, to talk about an interesting and accelerating trend in data center technology: composable infrastructure. With UCS M-Series servers, Cisco has taken an important step forward in this space. To help frame things up, we asked Jed for his take on the market drivers and customer needs fueling innovation. We’ve broken the conversation with Jed into a series and hope to shed some light on how this will re-shape computing architecture and the opportunities for IT.
Last week I introduced this topic, the pervasive problem of “comatose” servers in data centers, based upon an interesting recent eWeek article entitled “30 Percent of Servers Worldwide Sit Idle”, which in turn was based upon the research report by Stanford University in conjunction with the Anthesis Group. In my blog, I described the costs of this problem, ranging from the obvious (e.g. power and facilities) to the hidden (e.g. un-used software licenses). This week I’ll discuss why this happens and what you can do about this problem.