- Erica Mixon, Senior Site Editor
Large tech companies with extensive resources, such as Amazon Web Services and Facebook, have undergone the transition from a traditional to a software-defined data center, but few organizations have attempted to follow suit -- at least, not yet.
A common barrier to software-defined data center (SDDC) adoption is a lack of a coordinated vision. The technology team at stock photography company Shutterstock, however -- led by its CIO David Giambruno -- has achieved a proof of concept for an API-driven SDDC.
Giambruno's previous experience prepared him for the overwhelming task. As CIO of Tribune Media, he reorganized the company's IT infrastructure after Tribune split its media and publishing businesses in 2014. His team replaced the legacy infrastructure with VMware's network, storage and compute services, including NSX, and built a software-defined data center. He also used ecosystem components such as PaloAlto and Riverbed.
Now in his role at Shutterstock, Giambruno is leading another SDDC transformation, and recently shared his top challenges and lessons learned with SearchDataCenter.
You built an SDDC at Tribune. Is there anything you'd do differently this time around?
David Giambruno: The difference between then and now is really the ecosystems around SDDCs. When I did it a couple of years ago, I was literally pulling all of the vendors into a room. A lot of my effort was really around vendor management, getting the vendors all in the same room to work. … I literally had a greenfield, I didn't have to worry about changing the wheels on the car while the wheel was moving -- I just had to build the car.
The hard part was wrapping peoples' heads around an SDDC because it's very orthogonal to traditional network storage and compute. People have gotten used to the idea of a virtual server, but a virtual network? Those are very different. I joke that I'm old enough that I remember when cache was the thing in storage, so the time you took spindles away from a DBA they all freaked out on you. It's a mental transition. The technology's not hard; it's easy to understand. But it is a different operating paradigm.
Since a lot of companies aren't at that stage of SDDC adoption yet, who do you turn to for resources if you need them?
Giambruno: I kind of look at it differently. I have a team [at Shutterstock] who's never done this before, but who's really smart. I brought in some vendors, and asked my team to try, and in two weeks they've set up an SDDC and have it running. We're not running the company on it yet, but it is that proof of concept. I argue that it's [about] letting teams be successful and giving them the time to be creative and engineer and giving them the opportunity to, in a way, fail. I tell them, 'You need to break this. You need to understand what it doesn't do and how to do it.'
For us, getting infrastructure out of the way -- whether we run it on our internal data centers or we run it on Amazon -- it needs to be the same process and the same capability. And we need to make it transparent and frictionless for our dev and product teams to do what they do. The more I get the infrastructure out of the way, the easier it is for [development and product teams] to do their jobs and for us to meet our shareholders' and business teams' requirements and needs, and provide value.
How did you for building an SDDC?
Giambruno: The way I think about it is that an SDDC is a precursor to what I call indiscriminate computing: your ability to move your compute and your assets and your applications where they need to be based on their requirements or an economic model.
I believe in ubiquitous computing. Unless you're doing very specialized compute, it is compute, storage, and networking. They're just three big blobs. Again, they're different businesses, so I would argue an SDDC is key to us, but the real thing that I'm doing is an API-driven infrastructure. SDDC is a component of that.
With an SDDC, there are APIs for everything, so I can enable our software deployment for our product. They can have an API through Puppet and deploy through the infrastructure, and we can set up the key metrics, so if we're seeing load increase on our conservative platform, we can automatically expand that, or I can move that up to AWS.
I've got some drivers from the leadership team: [They said] 'We want to move to AWS, we want to be faster.' Okay. I would argue that an SDDC makes you incredibly fast when you look at what we need to do as a company and how we need to service dev and products team -- it's that API-driven economy. They just want to be able to fire code out and know that that code gets deployed and we're operating and monitoring it and we're ensuring that stuff is staying up. If we see problems, we can have a data-driven discussion because an SDDC gives you a tremendous amount of visibility into what's going on across your infrastructure to answer questions and give everybody a single pane of glass so that you can have a fact-based discussion.
How do you approach technology procurement and vendor decisions? At Tribune, you went with VMware. Does that influence your thinking at Shutterstock?
Giambruno: We have not gotten there yet. We are in the proof-of-concept phase where the engineering teams are playing with technology and running use cases to determine the best outcome and know the performance envelopes. We have one full stack running but we have testing to do. … In building the next generation API-driven infrastructure we are looking at the landscape with fresh eyes to make the best choice for Shutterstock.
We're going to have an SDDC to come up with ways to deploy our code that's easy and fast and so we have indiscriminate computing, whether it's the AWS or internal data center, the process should be the same. Our governance, our security, our KPIs, all of that we should be able to manage through a single pane of glass -- that's the nirvana statement.
There's [also] automating our operations, so that I can turn my team around to continuously help our customers internally, because we are a service organization. I use technology to get things out of the way or to accelerate, because speed is our competitive advantage. If you want more capacity, you should be able to, with keystrokes, add CPU, add , autoscale, scale up, scale sideways. My job is to get that whether it's an internal or external capability, but make that transparent. Those are becoming table stakes. And I would argue that an SDDC delivers those capabilities in a very efficient and effective manner.
How have you evolved your skills or your staff's skills to adapt to an SDDC environment?
Giambruno: SDDC stuff isn't that scary. It's software, so you're moving hardware teams into software. You have to give them the exposure and the time to learn, and that's just a leadership thing. You have to make the team for them to do that. And that's why I build proof of concepts and let them build it, and get them the help when they need it, so they can learn. I want to take them along on the journey. There's just not that many people who have done this, so you're not going to go out and hire these people -- you're going to have to grow them. It's not instant soup; you plant the seed, you water the seed, and then you move.
You've mentioned a single pane of glass -- do you believe that exists at this point?
Giambruno: When I say a single pane of glass, I think of a cube. Your drill downs will take you to other panes. What you're really trying to build is a big cube where all your data is in one place, and your ability [is] to focus on that piece of data, whether it's a security view, a network view, a SAN view, the ability to quickly rotate -- so that at 100,000 feet, you can get a single pane of glass and that would be across the infrastructure.
You can get another pane of glass for your apps, because you don't have a screen big enough; you need a wall to do that. It's the ability to rotate the cube very quickly. And there is a scale [issue], so if you have 200,000 servers, it's hard to get that on a single pane of glass because there's a lot more context.
Your CEO, Jon Oringer, is technologically savvy. Does that ease some of the tension you'd normally find in that relationship?
Giambruno: [Jon] asks awesome questions; it's not just the 'what', it's the 'how.' Like, not 'What are you buying' but 'How are you buying it?' And I find that really fun. I say this with affection, but I have that job that you cannot explain to your mother. And so, most CEOs in a technology company, my answer would be, why do they care? 'You're buying a server? Which CPU [and] how much RAM?' Those are things I would never expect people to know.
[Jon and I] can have a very rich conversation about what it's going to do for the company because he understands. I've never had that, and I find it fascinating. There's never tension; every company has a process for purchasing technology -- there's a procurement process, a vendor selection process -- whatever, you just follow it. There'll be questions along the way.
Can you share any insider secrets about IT infrastructure overhaul?
Giambruno: One thing is, I would not try and migrate. … We set up a new SDDC and we're going to move some things onto it. I would not try and change things in flight. And you need to work with your vendor ecosystem. If you're going to start with an SDDC, you're going to deal with vendors who have made physical things for a really long time, and they're good at that. In an SDDC, I can spin up thousands of servers really quick, all with virtual firewalls. Now, depending on your licensing structure, you just may owe somebody $20 million for all those servers you just lit up. Speed is awesome, the ability to whip up infrastructure is awesome; you just have to understand your contracts and how to negotiate those things for the unintended consequences.
For many, SDDC adoption is in the distant future
Know these terms to an SDDC
Integration and scalability are priorities for an SDDC