What we do
You're currently viewing Softcat.ie, would you like to continue?Yes, I want to view Softcat.ie
Michael Bird: Hello and welcome to Explain IT, brought to you by Softcat. Explain IT is a show for IT professionals that aims to simplify the complex and often over complicated bits of Enterprise IT, without compromising on detail. I’m host Michael Bird and over the next 20 or so minutes I'll be challenging our panel of experts to take a different area of the IT ecosystem and, of course, ‘Explain IT’. This week we're going to be looking at hyperconverged infrastructure, cutting through the marketing to explore what it is, how it works and the benefits it can provide to an organisation. With me to help discuss, demystify and explain are Sam Routledge, Softcat’s CTO, Tim Jeans, Softcat’s Datacentre and Cloud Practice Manager and Paul Petty, Laing O’Rourke’s Infrastructure team leader.
So Sam, what exactly is hyperconverged infrastructure? Is it the evolution of infrastructure?
Sam Routledge: Evolution is an interesting word, and I think there’s an element of that. If you look at it, we have three phases of development of infrastructure in the ‘post mainframe era’, the first was, you’d buy a load of servers, you’d buy a network, you’d buy a load of storage and you’d connect the three together. Or perhaps, your reseller or integrator would connect it all together for you. That was great, worked really well, was given some serious momentum by the advent of virtualisation.
Michael Bird: And that’s called the traditional model, would you call it?
Sam Routledge: Yeah, we’d call that the traditional model, or the three-tier architecture, probably, interchangeably. There was a next evolution of that, which was referred to as converged infrastructure, which was when you bought all of those three tiers, either from a single vendor, or as an integrated stack. So the idea being, that you bought server, storage and networking in one big rack, and it was integrated, delivered, implemented and supported by one organisation. Now that might be that you bought all the components from an individual vendor, HPE, for example, or it might be that it was a stack that was brought together by a vendor, like the V-Block model, which was a coagulation of VMware, Cisco and EMC, or it might be that it was more of an ‘integrated in the field’ model, a la FlexPod, where it was VMware or Microsoft, Cisco and NetApp that was integrated in the field and validated as a design and supported as such. Hyperconverged is the next iteration, in that we’re delivering all of those elements, really through software now, rather than hardware, so there’s an overlap with the software defined storage or software defined infrastructure conversation, where all of that stuff is consolidated into a single box and the storage resides physically within the individual server and is delivered up as a SAN through software, the networking is managed and ‘defined’, is the word, through software. So you end up with a grid based, or a block based architecture that scales out rather than scales up, which I think is quite an advantage in this cloud-like world, in that it gives you an infrastructure that has some of the feel of cloud, in that you can scale it out bit by bit, rather than having to buy it in big chunks and size it for five years of future use, which you don’t necessarily know what that looks like. What would you add to that, Tim?
Tim Jeans: If you think about a traditional architecture, the challenge is, you need to be able to see how far you’re going to go, in order to buy the right frame. You don’t have to fully populate it, but you need to know what frame to buy, particularly from a storage perspective. The beauty of hyperconverged, is that no matter how far you’re going to go, you start with the same entry point. So in an infrastructure world that is increasingly unpredictable, we’ve stopped asking customers, ‘How far do you think you’re going to scale,’ because the answer is always, “well, I don’t know, and how could I know? Digital transformation’s here, but we don’t really know what that means for our infrastructure yet.” So, not knowing how far you’re going to go, does not hinder you, initially, and equally, it doesn’t increase that initial cost.
Michael Bird: So where does cloud fit into all this, then?
Tim Jeans: Well, I think cloud is a really good fit for lots of workloads, but I think the challenge for infrastructure teams has been that, actually, if you needed a certain commercial model, or if you needed a certain service within a certain period of time, then cloud was the only answer, and I think what hyperconverged gives you is a model for infrastructure, whereby, actually from a cost per VM or cost per workload, or whatever it is, you can imitate what you can do in cloud. But equally, or more importantly, from a speed of response perspective, you can get things done immediately. That traditional three-tier architecture, whilst it still has its place, as we’ll discuss later, one of the challenges from a design perspective – you need to design the networking, design the storage, design the compute – that goes away, you’re buying a node. So you know what that node looks like, and therefore you can crack straight on into the services and the delivery.
Michael Bird: So I guess that leads me quite nicely on to the next question. We've got Paul, who, as we said earlier, is Laing O'Rourke’s infrastructure team leader. Paul, you've got some of this stuff in your organisation, so what has been the benefit of hyperconverged infrastructure to your organisation, or, I guess, to organisations in general?
Paul Petty: The benefits are probably really standard across most businesses who take on hyperconverged. The number one benefit is simplification of infrastructure. It's infrastructure that just works. It’s literally plumbed in, there’s no mass configuration or fine tuning requirements particularly needed for it. And scale is done as needed, so in our case, we can start very small, implementation is easy because we just pick a particular project and that particular project can fund a small implementation rather than having to go through a whole architecture design to buy storage, compute and networking for that one project. We can start small and then the next project that comes on we’ll just drop onto that and then we’ll just scale one block at a time, one node at a time, or multiple nodes at a time, as needed. So the process of traditionally architecting and scaling throughout our infrastructure services has been greatly simplified. There's another benefit on that which is from a procurement basis; it's a lot easier to have a small incremental growth model, than it is to have these three, four, five yearly lift and shift projects when your infrastructure retires. It’s much easier to get through commercially, it’s much more appealing to the business to have that small, almost operational cost of project by project or growth by growth as needed, rather than buying five years up front and hoping that we've sized it right five years ago.
Sam Routledge: Which you probably didn't, cos things change.
Paul Petty: Absolutely you couldn't. All the information you can have in the world - what you did previously in the last five years, it's not going to match what you going to do in the next five years, it’s just too much change, too rapid.
Tim Jeans: And I think it's fair to say, Paul, that we've seen internally, far greater interest from the commercial team as well as from the leadership team in terms of what those infrastructure tools are now, than there was previously, which I presume is because of these wins that they’ve seen, in terms of how quickly you are able to deliver, or delays that have gone away.
Paul Petty: Yes, infrastructure agility is a big win in itself, but to labour the procurement model a bit more, they quite like the simple model of commercial. With traditional architecture you've got lots of different components that will have different end of life, different support cycles, maintenance and patching and they all have cost associated with them, whether it’s internal costs or if you have to go out to companies like Softcat to get a PS in to patch or maintain environments for you - that very much goes away with the hyperconverged model, particularly which vendor you go to, but the idea is they’re software defined, so it's ‘one button does this, one option does this’ and that's how it runs. There isn't a huge learning curve with them, it can be quite generalist in terms of who uses it, who consumes it and as a result therefore makes you a lot more agile and your team is a lot more focused on the business services.
Michael Bird: So you can go to your finance team and previously, you’d say, “we need some storage, we need some networking, we need some licences, we need some compute,” now you can just say to them, “there's this one box - does it all.”
Paul Petty: Yes previously we would have to do trend analysis over the last six months or 12 months and show where we predict where we were going to run out of storage in 12 months time, so we’re getting ahead of the curve to be able to get the purchase orders raised and budgeted for. With this approach we can literally just wait for the project to come along that needs a bit of growth; we've always got a little bit of overhead, just from spare capacity anyway, and the next project that comes along that will take up the growth just pays for an extra bit of expansion. It's an easier model to do by far.
Sam Routledge: That chargeback, showback, costback model is much easier when it's block based, grid based, scale out little bit by little bit. It means that you can cost things much more easily per project or per VM, or show a part of the business how much a particular service costs to run. We think that that's quite important because if you look at how people think things work in a cloud world, you've got a very clear cost model and that's not so easy to break down with traditional three-tier architecture, it's much easier to deliver that back to the business using hyperconverged.
Paul Petty: You're quite right. The business - a lot of businesses - have seen the public ‘how to cost’ model and they go, “great, I want that,” but then when you scale that over three to four, five years, the on-premise solution typically beats it in price, hands down.
Sam Routledge: We always tell people cloud ain’t necessarily cheaper, even if all the marketing tells you it is. In some scenarios it can be,
Paul Petty: It always is for the first couple of months.
Sam Routledge: But you’ve got to architect properly, you've got to you've got to be cloud-native if you want it to be cheaper.
Paul Petty: Yeah and that comes with its own set of challenges and costs associated as well.
Tim Jeans: The point around showback that's worth making is that it's not just that what cloud can do, it’s also the challenge that not having showback has created. So if you think, traditional three-tier architecture - really hard to calculate what the cost of a virtual machine is, or a specific service, and equally, with the advent of virtualisation it became far easier to consume. So suddenly you’ve got this big cost and you've got no way of working out what goes where, so to any division, it just kind of sees it as free. And when something is seen as free, but suddenly IT has a huge cost, it’s really hard to get those two things to marry up. Is that fair, Paul?
Paul Petty: Yeah so IT is not seen as so much of an overhead, more of an enabler to the business.
Michael Bird: So that leads on to the next question then, so how can an organisation take advantage of this? Do they rip out all the stuff they currently have in their datacentre and start again, or can they use some of the stuff they’ve already got? How does that work?
Sam Routledge: So we don't think that's necessary, I mean you absolutely can do that - if you are at the end of the line with your existing infrastructure, it's at the end of maintenance and you need to replace it; if your workloads are in the right scenario, and we can certainly help with the sizing for that, you can absolutely replace what you've got with a hyperconverged approach. It's not necessary to do that, so what we see a lot of organisations do is leave what they've got on the existing infrastructure and what goes on to hyperconverged is the expansion workloads, the stuff that you're prototyping, the new projects that you don't know how big they’re going to be and we think that's a really good place to start. And it may be, over time, that more and more of your workloads gravitate into hyperconverged, but while there’s still a place for the three-tier architecture, that's a really good place to start and I think that's where you’ve come from, isn’t it, Paul?
Paul Petty: Yeah, we had a small project requirement and we looked into hyperconverged to help us build up a new datacentre. It was a Greenfield site, however we didn't have a huge workload in day one.
Sam Routledge: So you weren’t replacing your existing...?
Paul Petty: No, we weren’t, we were literally just expanding our capabilities. The long-term intention is to replace, but from day one we didn't obviously have the budget to rip and replace the whole datacentre which would have been a significant cost. So for us, being able to start with a very small three or four node cluster, get up and running, get the feel for the product, get the feel for how it changes how we work with it and then migrate workloads over to it, over time and then just grow that infrastructure up to the point that we need it to be right size for a whole datacentre was what’s fantastic; it's simple to do, it was exactly that - simplification of infrastructure. There was minimal effort, it was mostly done by one or two people, with some outside assistance. It's not this big traditional uplift of infrastructure effort that was required previously with our old three-tier stack.
Tim Jeans: I think it's important to start with specific use cases because we spoke about the benefits in terms of being able to start small, no matter how far you’re going to go, but equally waiting for those opportunities to refresh your whole infrastructure in one go, given what Paul mentioned around lifecycle management, so waiting for the network and the compute and the storage to all line up and need refreshing at the same time is quite challenging. It’s like waiting for Halley's Comet - from a cost perspective it's hard to get those hyperconverged to stack up unless you’ve got those three things aligning, so starting with a small use case which you can then expand out as you need to is quite an important way of giving yourself options, actually, if nothing else.
Michael Bird: Let's look at the future then, through our crystal ball. What do we expect to see in the future? Ultraconverged infrastructure? Everyone in the cloud?
Sam Routledge: So I don't think anyone's invented ultraconverged infrastructure yet, but I'm sure it's going to come at some point, that's clearly going to be the next big thing. I think what we’ll probably see is that, for a period of time, hyperconverged will be accretive to what's gone before, as we talked about earlier, it's not commonly, not always going to be a rip and replace, there’s still a place for traditional three-tier architecture for your stable or your static or long-term workloads, you’re probably not going to change that for the time being. You may even continue with that model when the refresh rolls around. I think hyperconverged will be for your project work and your growth workloads, maybe stuff will migrate over time. You mention the cloud, clearly we will see more and more people putting some of their workloads in the cloud. We think hyperconverged is part of that conversation because it's on premise infrastructure that feels more cloud-like and the control plane stuff around where you put your workload becomes a really important thing as people use cloud more and more.
Tim Jeans: I think the reason why it's important is because we go back to why hyperconverged has been successful, it's about simplicity and if you end up with a three-tier architecture, a hyperconverged architecture in AWS deployment, a Google deployment, an Azure deployment, then actually that simplicity has gone away. Having a control plane that allows you to get visibility of what’s where, optimise what’s where, understand the costs and therefore make intelligent and consistent decisions as to what infrastructure is platformed where, I think is going to be really important.
Michael Bird: So do you think we’ll get to a scenario where you’ll have a single application which has all of your on-premise, all of your stuff that's in Azure, all of your stuff that's in Amazon…?
Sam Routledge: I think that's the Nirvana state that we’re looking for. I think that, where five years ago the battle was about the hypervisor, now the battle is about workload arbitrage - where do you put your workload and who's going to be the control point? Is it Cisco, controlling it from a network standpoint? Is it VMware controlling it because they own the virtualisation space? Is it Nutanix, who are the guys with the momentum in the hyperconverged space? They’ve all got a play and it'd be really interesting to see how that squares up.
Paul Petty: I think the other big thing that will come alongside all that is automation. And that's a key thing to be able to automate all of your workloads between all those various environments. Automation and network virtualisation, which is a big player, again I think we said earlier, there's a number of players in that space and there’s huge developments coming, almost quarterly these days, so when you get all that tied in together, plus you’re simplifying on premise infrastructure, you’ve got a really flexible, agile platform, or series of platforms, all converged together. So ultraconverged could be the convergence of hyperconverged and public cloud maybe.
Sam Routledge: That's a really good point, I like that scenario, that makes sense, because ultraconverged is therefore the software element that arbitrates as to where your workload gets placed, based on business logic.
Paul Petty: Exactly that.
Sam Routledge: You’ve just invented something new and magnificent
Michael Bird: You heard it here first
Tim Jeans: Cut that out, we’ll make money out of that.
Paul Petty: Let’s get down the patent office now!
Michael Bird: So, to summarise?
Sam Routledge: So to summarise all of that, you've got options in infrastructure these days. You can continue with your three-tier architecture, you can start to integrate some hyperconverged for those flexible, growing, shrinking, moving around workloads, you're clearly going to use the cloud in almost every organisation for something at some point. You probably need some help deciding on what the appropriate strategy is for you - we've clearly got quite a bit of experience in working out what's the best platform for these workloads and, should hyperconverged be appropriate, helping you to size it and choose the appropriate one. I think there's a future in each of those areas - you will have traditional three-tier, you will have hyperconverged, you will have cloud for the foreseeable future. It's a case of deciding which is the best strategy for your organisation and for a given subset of workloads within your organisation.
Tim Jeans: Whatever that decision process is, have that documented to such an extent that you could articulate that to a senior business leaders. As an IT organisation, make sure you could explain to your senior leadership what you put where and why and when, because that's expected and I think that's part of the cultural change that we’ve seen since the advent of cloud.
Michael Bird: And Paul, some advice for people who are in your role, looking at reviewing hyperconverged infrastructure?
Paul Petty: The main things would be, look at what you're trying to get out from it. Look at what your use cases are, look where your wins can be, whether that’s commercial, whether that’s operational. Clearly, if you use it right, there's advantages in all those areas. Focus on technology stack and try and look forward ahead with regards to where your time is being spent currently and where you'd like to spend your time in the next 12 to 18 months, post implementation.
Michael Bird: Excellent, ok Sam, Tim and Paul, thank you so much for your time. Listeners, if there's anything in this show that has piqued your interest, and if you'd like to find out some more around hyperconverged infrastructure, do make sure you check out the show notes. We’ll put some of the stuff that we've talked about today, as well as a few ways you can get in touch with someone at Softcat. So you’ve been listening to Explain IT from Softcat. Thanks for listening, and goodbye.