The Software Defined Data Center isn't a Monolith - CTO041
As I do often, I found myself in a great Twitter conversation. This time it was if OpenStack is needed if you are pursuing a container only strategy. It evolved into a conversation around if the Software-Defined Data Center has a single pane of glass for management or even a single API for consumption. I’m joined by Eric Wright and we discuss the future of the software-defined data center. Do container and container management replace the need for enterprise OpenStack deployments? Should all net new be on containers? — Keith Townsend (@CTOAdvisor) June 26, 2016 Show Notes Eric Twitter Virtual Design Masters Eric’s Blog Subscribe iTunes | RSS
Transcript
Hi, welcome to episode 40 of the CTO Advisor. I'm joined with VM Turbos Eric Wright. He's a principal architect. We got into a really great Twitter conversation around OpenStack and containers. Is there a need for OpenStack? If you're gonna go with all container infrastructure, can you go for all container infrastructure? And then that evolved into the software-defined data center and API access. So we just had to have a full-on blog, not just blog post, because I think I write a blog post about it, but a full-on podcast and expand upon the conversation.
You'll notice that my audio is a little different because I had to do this outside of my regular studio, but I think you'll enjoy the conversation either way. Really enjoyed it, hope you will too. Eric, can you go ahead and introduce yourself? All right, thanks Keith for having me on. My name is Eric Wright. Most folks would know me as Disco Posse on Twitter. com and co-creator of Virtual Design Master, sir. So hopefully we'll get a chance to talk about the Virtual Design Masters near the end of the show, but I'm really kind of geeked to have you on.
We got into a really expanded Twitter conversation, which is a little bit too big of a conversation for Twitter with this API to the software-defined data center. I don't know if we can throw any more buzz words in that. That's like, oh wow, two dreams in one, basically. It was interesting, and it's always tough, like you said, in Twitter, 140 character plus mentions and everything. It cuts down pretty quickly, and I always feel bad when I jump into a conversation sometimes because it's that neat thing where you open up a really good topic.
You said, do containers relieve the need for OpenStack? It's one of those ones that jumps up, and it's a great conversation. Literally, this could be a blog post and everything, so after we had two back-and-forths, I was like, hey, we should talk about this one. This is kind of a cool topic. I think that was the initial question, which kind of led on to this follow-on question, and I think it's worth having that first question, which is a basic question. Does containers relieve the need for an OpenStack or even a vCenter or vCloud real iSuite?
Where do you see the role of containers versus OpenStack or with OpenStack? I think the trick is the infrastructure as a service or even traditional virtualization is still going to live for a long time side-by-side with containers as they come on board and become a new place where we start to do things. I did an article recently, I think actually yesterday or today, it's one that's always caught my eye, the idea that we're about to mess up containers the same way that we messed up virtualization when we first tried it, and so this is the neat thing.
If you're container focused and your application focused, containers make a lot of sense. In fact, the PaaS people, if you talk to folks that run OpenShift or Cloud Foundry, especially working at Pivotal or Red Hat, they're going to tell you that containers are even useless at this point. Let's just bypass the container, go right to the code, and then you'll go even further up the stack and the serverless folks are going to say, why do you need that? Just use S3 and use Lambda and just do event-driven stuff.
It's very quick to think that we don't need all the stuff underneath, but it's definitely a plus one to the existing environment, in my opinion anyways. So I think that I agree with that statement, that basically this is not a one-shoe-fit-all and you'll be able to magically start to build an infrastructure based on a container-only paradigm and then, you know, star VMs and OpenStack and legacy infrastructure. So there's going to be a combination of a bunch of stuff, a bunch of IaaS containers, PaaS, and even traditional hardcore virtual, or I'm sorry, physical machines.
But at the end of the day, it looks like, you know, the promise, or at least on the surface, the promise of this software-defined data center is that we have less stuff to manage. This just sounds like more stuff to manage. What's your view? Yeah, and then that's where this fun thing comes in, of defining what the software-defined data center is, and I think that was one of the things that came up, is this thing of like single pane of glass and, you know, we as speakers and community, you know, fronted folks that are out in there all the time, we kind of poke and laugh whenever we hear single pane of glass because it's, all right, everybody drink, you know, like that's buzzword bingo in the greatest way because there is multiple single panes of glass in everybody's data center.
And I think that's the difference. So the, like the SDDC, in my definition of it, is simply, you know, an API-powered, virtualized infrastructure, whether it's going to be, you know, true self-service cloud or whether it's going to be traditional virtualization, but it ultimately is, has got an abstraction layer, which is presented by an externally facing API, preferably a RESTful API. That's the real focus of it. So the SDDC in itself isn't the pane of glass, it's the stuff that, you know, powers everything else and then you have multiple single panes of glass that consume the SDDC resources.
It becomes all these, an enabling infrastructure for other software- defined infrastructure, which again is just something that's abstracted by an API so that it can be consumed by other software. So if you're an infrastructure architect, there's plenty of complexities still to manage. The underlay, whether it's abstracted via, you know, to AWS and Google Compute, just that alone, you still have container management on top of that, you have PaaS solutions to integrate, you have SAS to integrate, there's still a lot of, awful lot of integration work that needs to be done.
I think this came to kind of one of my last points or questions, is the consumption of that software-defined data center. So the ideal, I think, behind the software-defined data center, or at least some of the advertisement, is to reduce the complexity of consumption. The developer, the end-user, who's ever utilizing those services provided by the SDDC, has a, in theory, RESTful API or some type of API to the data center in which they can consume it, or a self-service portal, whatever the model of consumption.
However, is it too ambitious to think that there'll be a single API to that software-defined data center? The manager of managers, the API of APIs. The API of APIs. I mean, there's plenty of vendors out there that, you know, since the onset of the word cloud, there's been cloud aggregators that's promised us, you know, a single API to multiple clouds. Yeah, there's an interesting thing of, you know, who is going to be the single authoritative source of anything? And I think that's the the challenge we have as an industry.
We're always seeking this single source as if one will rise above, like, the Highlander, and all others will fall because of the strength of this one single thing. But we've realized, you know, contrary to how we were in the in the late 90s and early 2000s, if you were an IBM storage shop and then you got a deal on some EMC storage, the first thing you did was you planned a full 100% migration to EMC storage and you got rid of your IBM storage.
And now we live side-by-side amongst all of these things. We've realized that use case driven and best-of-breed becomes the driver for stuff, which is where containers are interesting, and PaaS is interesting, and Lambda, and this event-driven serverless stuff is very interesting. Because, you know, let VMs be VMs. Long-running, monolithic stuff that needs to be moved around so that the underlying infrastructure can be powered down around it without outage. VM, perfect architecture. Container, something that can spin up, horizontally scale, has the ability to live with latency in east-west networking.
Because if we thought we had VM sprawl, you haven't seen anything until you've seen containers, right? And then they're smaller, more nimble, faster to boot, and typically the applications written into them are resilient at the application tier, so that if a container just drops off the earth, then no one notices because the application is horizontally distributed. Then you get platform-as-a-service. Again, we run a distributed platform in which you can just push code and data, life is good, easier to deploy, and resiliency is built at the infrastructure tier.
You move further up and you get the event. Again, you know, each abstraction layer is all consuming physical hardware underneath, so that's not going away. But it's just definitely a shift in the model in which one will not replace the other, but it will live side by side, and we get to choose now, which creates confusion if you're selling these products, because the sales cycle is significantly longer, because you can now say, well, should you be running, you know, cloud A versus cloud B versus cloud C, and competition is great, but not when you're one of the competing vendors and you're chasing really long POs, especially when you get into enterprise.
I mean, you can say from your experiences, you know, working in a big three consulting like you've seen, what people believe will be a rapid deployment of infrastructure, and it turns into an 18 to 24 month project of just learning how you're going to deploy it before you even let it hit the ground, right? Or in my case, a permanent job. That's right, exactly. So, I think we got a show title or potentially a blog post title, which is the software-defined data center is not a monolith.
There is no, I think, short-term and long-term, whether you're planning a migration to cloud, public cloud proper, or if you're doing a hybrid solution, if you're looking at containers, if you're looking at service computing, the concept of one API, one data center architecture to rule them all is kind of a bygone area. We're not going to make the data center great again. It's going to be, I don't want to call it a hodgepodge because it's planned and it's well thought out, but it will be a multitude of a bunch of different things.
Yeah, it will not be a melting pot. It'll be a plurality, right? Like, it's going to be much more Canadian political than US political. We will have everything live happily amongst each other. You know, maybe one getting a little bit more strength than the other in consumption, but yeah, 100% agree. So, let's wrap up and talk about Virtual Design Masters, something that if you're new to the podcast, you may have never heard, or if you're not kind of steeped in a virtualization community, what is Virtual Design Masters?
Oh, this is the fun stuff. So, I co-found this interesting event. I was watching Ink Master and, you know, Kitchen Master and all these sort of something-something masters, and it was neat to see that there's this idea of presenting a really, you know, challenging recipe to build or particular challenge to solve in a very short period of time and having people who are maybe not huge experts or well-known experts, you know, in it, but they're really good and they think they deserve that title.
And I said to Angelo Rucciani and Angelo's co-founder, or sorry, co-leader of the Toronto VMUG with me, and I said, like, it would be really cool if we could do this for IT, kind of like VCDX, which is the VMware Certified Design Expert, kind of like the CCIE of VMware. And I said, if we could take that concept and make it a reality show, so we'd say, like, here's a crazy set of requirements, you've got 24 hours or 48 hours, go. You know, and we realized, of course, that's kind of tough because how do we get people together and whatnot?
But as we talked about it while watching a basketball game just, you know, hanging out, and then, like, an hour later, he texts me. He's like, okay, let's figure out how we do this. We've got to make it happen. So we went out to the community and said, hey, we're looking for a challenge. You know, we wanted to create this interesting way that we're going to challenge people to be able to create a design with very interesting requirements. So somebody submit.
And Melissa, who folks may know her as vMist33, emailed us in this idea around a zombie apocalypse that had occurred, and we had five-year-old hardware that was the limitation, and you had to do this crazy design with five-year-old hardware. And it was really, really intense. And so we kicked off this thing, and it became a real fun event to run. And then in the final, we actually got somebody some cloud time. We got a couple of prizes. And it has since now, we're in the season four.
It's actually starting. We're in the midst of a live series right now, and it's gonna culminate into July. And this was something where the community wrapped around it so well that, in fact, folks that competed and other folks that watched are now judges. And so this year, we have Rene Vandenbetum. He's vcdx133 on Twitter. Rene's an amazing contributor to the community. And in fact, two years ago or last year, he provided a grand prize, which was paying for somebody's vcdx defense fee, as well as giving them mentoring, which is really, really cool, you know.
Yeah, that's really impressive. So how often is Virtual Design Masters? And if someone wanted to enter this really intense competition, how would they get more information? io, that's the main page, which will bring you to the site. It'll show you a list of the competitors, the judges, what the challenges are. We're in the throes of it right now for season four. And we typically, the plan was always to have it end prior to VMworld, because we know everybody's kind of busy leading into that.
And so it's definitely challenging, because our folks are doing day jobs, they have families, and then they're doing this in their spare time at night. They're given a wild set of requirements of like six days, you know, or five days to complete a challenge. And our fourth challenge, which is really cool, is a live deployment into real infrastructure. And that's, they're given a little bit more time for that one, because obviously there's a bit more care and feeding required. But it's pretty cool.
When you think of this year, we have VM Turbo, so it has jumped in and they've given $1,000 towards the grand prize. And we have, I think, in total we have about three to four thousand dollars worth of prizes. Oh wow. And these are almost all community-contributed. So that's powerful. com as well. And you can follow at VDM Challenge on Twitter, and you can sort of see what happens live. And we've got the lists. If you go to the Season 4, it'll show you the list of the live events, and those are also recorded so people can go back and watch them after the fact.
Well, Eric, I really appreciate you taking the time to enlighten us on software-defined data center containers. This stuff is really, I think, for the layman or the person just coming into it, this can be quite overwhelming. If people wanted to follow you again, what's the Twitter handle and the blog? com is my personal blog. And of course, if you go, I do a lot of writing for the VM Turbo. We have a side blog we run. It's called About Virtualization.
com, yes, that's the Canadian about. So people always hook me because I say that funny. You can see a lot of my open topic content, and then you can also find me. com. And I look forward to interacting with folks through whatever means they would like to. It's always great to open up and meet new folks in the community. All right, Eric. Thanks a lot, and you have a great one. Thanks, Keith. All right, man. That is a wrap, and we finished right on time.
Nailed it.