About three months ago, I wrote a post describing how we were using cloud capabilities to address very specific business challenges internally here at EMC.
Matt Coviello had just stood up the latest version of his vLab, and started to introduce it to our global presales community.
Now, it's three months later, and much has changed. Most importantly, Matt's team has started to expose these capabilities to selected portions of EMC's Velocity partner community, as Chad shared here.
I thought it might be time to spend some time with Matt, and see how his world had changed in three short months.
Going to cloud (or any variant of the ITaaS model) is all about speed and agility -- making it easier to do things faster. I've observed that once some group stands up their cloud and drives consumption, things have a way of moving exceptionally fast indeed.
Superconductors remove electrical friction; making entirely new things possible. Clouds tend to remove IT friction, also making entirely new things possible.
As a result, I don't have to wait long to revisit folks, and ask what's changed in their world since the last time we spoke.
And that's certainly the case with Matt and EMC's vLab.
To Begin With
The basic idea of vLab is quite simple: create "virtual experiences" of live, real-world EMC products that can be consumed virtually via cloud vs. physical instances. Essentially, removing most of the friction :)
If you're an IT professional (vendor, partner or customer), you know how important it is to be able to work with real, live examples of products.
Matt's experiences are also rather emblematic of what happens when you're far more successful than you really planned to be.
Matt, let's start with the basics?
Sure. Right now, we're on a 2.3x annual growth curve for capacity, and I think the rate might be accelerating. Last year, we did 26,000 reservations, each usually comprising 5 VMs or more, so that's a lot of virtual setup and teardown.
Our major concern right now is capacity -- we're now starting to peak at 100%, and we hate to turn away users.
We're planning a healthy expansion next month, which will bring us to 48 UCS blades with 256 GB of RAM each, all backed by 350 TB of storage. I came in this morning, and noticed we had 1600 VMs live.
So, what's the size of your team?
We run all of this with 8 people on the delivery/ops side, and 4 people doing support. Due to our approach -- capacity can scale linearly, but the people needed to run and operate the system can scale at a much lower rate -- they're on entirely different curves.
For example, we're planning to stand up an instance in Singapore in July to deliver a better experience: latency, support, etc. Not a big footprint initially -- 16 blades, 4TB of RAM, 100TB of disk. We're planning to do that with only 2 additional headcount, mostly driven by our desire to have a regional presence as opposed to having more work to do.
While we're talking about people, how would you say your team is different than what we usually find in enterprise IT settings?
Good question. For starters, we value breadth over depth. Not to say that deep specialization is a bad thing, but we need people who know about a lot of different things, and how they interact to deliver a service.
Motivations are important as well. All of my team cares deeply about owning the service and delivering the best experience possible for the people who are using it. We run into occasional problems like anyone else, and that mindset is incredibly important to keep in mind.
To the extent possible, we like our team to interact directly with the people who are using the service -- to get feedback, suggestions, etc. I don't think you can deliver a differentiated service experience unless you've got real empathy for the folks who are using it.
It's a very motivated, skilled and collaborative team.
So, what advice could you offer to anyone contemplating doing something similar?
I suppose I would start with the obvious -- be prepared for more success than you might be expecting. That's what happened to us. I suppose it's a good problem to have, but it definitely impacts how you think about your game plan.
For example, we designed for scale -- both technology and processes. We use Vblocks so we can focus on the services we deliver instead of all the components.
And let me make this clear -- you cannot have enough automation, period. We're constantly revisiting our processes, and introducing newer forms of automation. I don't think that will ever end.
We thought we had the capacity planning thing worked out, but we were wrong. Ideally, we'd like to run at 70% utilization (vs. the current near-100%!) but the lead times required to acquire and deploy vs. our growth rates means that we ought to be at 70% ideally.
Another thing we've started to do is segment our workloads. Right now, we have two kinds of users -- ad-hoc and events. The ad-hoc user is the employee or partner who wants to do a demo, for example. We've always done that, and we do it pretty well. The newer workloads are big events -- like VMware's PEX -- where we have to pre-reserve a substantial amount of capacity to deliver a better experience.
To be clear, there's nothing in the technology that prevents us from isolating workloads on the same Vblock, it's more of an operational and organizational convenience.
And I think the final thought is monitor your service constantly. You're only as good as your user experience, and you compete for customers by delivering a better experience than the alternative. A lot of the people who use our service have access to other resources, so we know that we're not guaranteed any business.
So, let's talk about EMC's partners, and what they've had to say about vLab?
Sure. Simply put, the ones who are using it love it. We wish we had the capacity to bring more partners on, and we're working on it, but we're not there yet. [Note: the service is currently available to Affiliate Elite, Signature and Premier EMC Velocity Partners]
They love the speed of access. They tell me that they can spin up a demo or a product eval in about 20 minutes or less. Compared to the usual alternatives, that’s huge. They spend more time doing useful stuff as a result.
They tell us that simplicity matters – it’s all about saving time. There's almost no learning curve, and everything is right there when you can find it.
There's considerable EMC breadth there today as well. We've got close to 100 EMC-based "experiences" online today, representing every EMC business unit, with more coming every week.
I think the most important thing, though, is the message it sends: EMC is investing in our partners' businesses. EMC changed the way it does business, which means our partners can change the way they do business.
For example, we got this tweet recently from one of our partners, Varrow.
“@virtualtacit: #EMC vLabs are simply amazing. Bravo. What a killer investment they have made in their partners. Thank you EMC Velocity Team.”
That sort of acknowledgement makes it all worthwhile.
So, what challenges are you facing now?
It's no surprise -- it's funding. We're a victim of our own success!
We started this out as a shared service that was centrally paid for as sort of a startup venture, and now demand has visibly outstripped the small amount of resources we started with. We're going to have to move to some sort of pay-for-service model for the other parts of EMC that are using our capabilities. I suppose that's to be expected, though.
The other thing we'd like to work towards is being able to expose these same capabilities to our customers. They've got the same sort of need for easy-to-consume hands-on experiences as our EMC employees and our partners. That would be really, really cool.
Matt, it sounds like you're having fun.
I am.
Look, it wasn't that long ago when I was a field SE for EMC, lugging around a massive laptop and spending most of my day trying to make stuff work so a customer could see it. What I like about this role is that I've been able to transform the way we do things -- not only for us, but for our partners.
And that's what keeps me going.
Comments