Transcript
to edge control, simplifying distributed IT at scale. See what we did there with the play on words. So I'm John Collins, I'm VP of engagement at Gigarm. I would like the audience to know I did once have a real job. I did used to work in a NOC, I was manhandling network devices with screwdrivers and cables and everything else, just like you guys out there. But these days, I work as an industry analyst, where I think about stuff and write about stuff, don't get shouted at anymore. So really excited to be here. Really excited to be joined by Craig from scale computing. And you're still living with the customers experiences every day. We're going to cover a lot of stuff, we're going to cover, you know, what edge computing is to organizations today, how to simplify it, what steps can can organizations take. But first, Craig, introduce yourself a bit and say what you want to get out of this webinar. Thanks for having me on today, John. So I'm Craig Terek, the vice president of product management at scale computing. I have been with the company for about 16 years now, I've seen the company through a lot of really fun transitions, including this most recent trend of edge computing. So I'm excited about the topic today. Great stuff. It is. I mean, what a space to to be working in at the moment with everything that's going on. I mean, you could throw in any single technology buzzword and it would it would be landing on on the edge right now. But I think one thing that's really. That I've seen over the past five years as it's evolved is and I can remember doing studies and working with customers not that long ago, where the edge was still seen as this kind of adjunct. It was very small devices with very small workloads and maybe a bit of Wi-Fi, maybe a bit of this, but it's moved to half rack, very powerful GPU, but all kinds of things you can now put at the edge and all kinds of workloads you can run at the edge to a much smarter environment. How are you seeing that kind of evolve? Because you're and I followed you guys as well. You've been at the forefront of all of this evolution. So how have you seen this evolution? Yeah, it mirrors exactly what you're saying. I mean, it's been a for years. First of all, nobody searches for edge computing like that just doesn't really happen. Somebody says, hey, I need an edge computing solution. What they say is I have some AI inferencing application that I'm trying to get out there at the edge of my network, and I don't exactly know how I'm going to do that or they've got some legacy application that's been out there forever that they probably called remote office, branch office. And they're now looking at, OK, how these point solutions, what do I need to do next to actually support this and make sure that I'm ready for whatever that next thing that's coming down the pike is. So what I've seen probably in the last two years is that it went from a we know this onslaught is coming of this proliferation of devices, proliferation of data, kind of this need for on premises computing and being able to make real time decisions of data to now we're actually starting to see people roll it out. In fact, we have really interesting use case of a large retailer right now that's using kind of AI out at the edge and using it almost like think of it as Siri in the pockets of every one of their their employees to be able to go through the 15000 products that they have across their portfolio and being able to get really detailed with somebody on the floor. So the first thing is they use computer vision to identify what that person may need some assistance. I'm going to go over and talk to them and then kind of have this Siri in their pocket that goes in depth on their product. That's the kind of evolution we've seen from this almost mythical. We've got something coming down the pike to like a real world use cases of delivering value out at the edge. And that's a really good example. You're showing that because it's not just bigger, as I was implying, being able to do more. It's actually more complex in terms of the number of things. So you're linking with multiple devices, you're sharing information horizontally as well as kind of from edge to cloud and back, which is the big change. And when you're seeing all of that happen, how conscious are people about data flows, data management, data security, even data sovereignty? What what kinds of risks are they then juggling with as they're handling that stuff? It depends on the use case in a lot of ways. There are definitely certain industries that everything has to live local. I never want anything to leave my local network. I want the data, talk about data sovereignty. It's I want it on premises. I never wanted to leave. There's personally identifiable information that has to live here. And then there are others that are, you know, as long as they've got a good, secure connection to the Internet, that that honestly, that workload could run just about anywhere and they can securely access that. And we commonly will see a hybrid of the two of those. I will say in our business, we made an acquisition of a company called Adaptive back in February of this year. We now call the product SC Connect. And it's a really interesting SD-WAN with SASE solution for that exact type of use case, the connectivity into those sites and being able to really lock that down. So we are seeing that more and more, I would say. And everything that you're saying as well, it's it's not just if you're in manufacturing, you know, we've been talking about I think the term IoT was coined in 1999 or something like that was around the time RFID was was really popular. And well, there's going to be things everywhere. So these things go back decades, literally. But the devices themselves, I'm thinking away from the sensors and towards the smartness, if you like, the devices themselves are becoming actually part of the corporate workload. And I'm building all of this to use the phrase mission critical, by the way, it's not just if a sensor goes wrong, well, you'll replace it tomorrow when you whereas this is actually on the critical path of our data paths and everything else. Yeah. And as soon as you start to attach mission critical to any workload, all of a sudden it's got new requirements. It's I can't deal with downtime. I need that application up running for processing in my widgets or in a manufacturing use case or being able to do transactions in a retail scenario or patient outcomes in a health care scenario. It really, depending on the industry, the actual outcome is different, but the need is the same. And that having to have that application up running available all the time, that's that's the mission critical nature of it. And that's isn't it great, but isn't it great when it all works? Going to move on to what's causing that to not work right now. I mean, sure, you'd love people to just buy your biggest box and everything would be great, but there's a lot of heritage stuff going on out there, isn't there? Yeah, there really is. I mean, it's it's the the age of some of the operating systems that we have seen in the market is just astounding and they don't seem to be going anywhere. But at the same time, there are newer and more interesting use cases. And what tends to happen is you look at that use case kind of in a bubble and you say, all right, well, this this new thing that I'm being asked of, you know, new computer vision application that I want to put out of my sites. You almost frame it within this small box that says it's going to provide ROI for our use case, but you're not framing it across everything you have out there. And it's almost this fragmentation that happens where you say, well, in any individual vacuum decision, it was the right decision. But if you don't take a step back and realize that you've made that decision over and over and over and every time you make that decision, it means you got to roll a truck. You have to put a new hardware device out there to manage. You have a new operating system on top of that to manage. You've got a new application on top of that to manage. And it's all separated and segregated. And the result is a lot of operational friction, a lot of operational overhead that if you if you just take a step back at the outset and think, you know, if I can create a platform on which to run this application, as well as those legacy applications and anything in the future, then all of a sudden you can really stop drinking from the fire hose of every hair on fire. I've got to get this new application out and now have a platform on which you can deploy and all the benefits that come along with that. Yeah, absolutely. I'm building a picture here. I'm going to throw in another word that we love. We love words ending in ation, don't we, in this industry. So rationalization. But essentially, there's all these new opportunities of what people are trying to do. I mean, you mentioned AI almost in passing as kind of, yeah, sure, we want to do inference workloads at the edge. Yeah, sure, we want it. And then the reality is that it's a lot of boxes trying to do a lot of overlapping things. And that obviously you talked about the operational overhead. And as I said, I used to work in a knockout. I can imagine what it feels like to kind of have every single device type has got a different screen. Some of them talk to the security platform. Some of them don't. When an alert happens, you're then kind of scrabbling around five different windows trying to work out which particular thing to diagnose it and then which particular thing to fix it. So you've got all of that going on and it's just holding organizations right back. I mean, are you hearing from your customers, I guess, we've just had enough kind of statements or are they just kind of wanting to do more and they're scratching their heads about it? Or how does it manifest? It tends to be the latter. I think a lot of the people that are drowning right now don't even recognize that they are. They're kind of in this, this is just what we've always done mentality. And they don't realize that every single time you throw that new application out there, they're adding to that operational overhead of having to manage it all. And I think once once they have seen the life preserver of here's a platform that allows you to run all your applications and centrally manage them and kind of have visibility across your entire fleet, all of a sudden then they take a breath and think, oh, well, you know, that one application that we've been talking about rolling out, maybe we can expedite that or maybe, you know, whatever project that they have on the back burner that they've always wanted to do, all of a sudden it becomes a real possibility to actually deploy and implement. Yeah, and it creates an opportunity, doesn't it? I think if there's one thing I learned when I used to run stuff myself and I had a budget and so on and so forth, whilst certain things cause pain, they also give me a reason to go to my boss and say, I need to fix this. And in fixing one thing, I can fix other things at the same time. So it does create that opportunity. So I want to talk a bit about the radar. So we were here to discuss the GigaOM radar and your position very well in the GigaOM radar. But first, first, let's go, if I may, I'll just say a few words about what the radar is and why we do it. So GigaOM is an analyst firm like Gartner or any of the other firms. But our secret sauce, if you like, is we hire practitioners rather than career analysts. So our reports are written by engineers who only really care about would it work for me if I was still doing the job that I used to be doing or in some cases I'm still doing as a consultant or whatever it happens to be. So we have the radar model, which is essentially the difference between are you a feature organisation as a vendor? Do you do one thing really, really well or do you do lots of things, maybe a bit less well, or maybe do all of them really well? We've got that dimension. And then are you a rapidly changing, innovative organisation versus are you a really stable lockdown kind of organisation? And that's the material that we hand out to our customers. This particular sector of edge deployments, full stack edge radar that we put together is particularly interesting because of the diversity of the vendors that are operating in this space. And this is kind of normal, given the fact that it has been in so much flux. And when you think of it as a historically fragmented environment, then organisations starting to converge onto the same desire to platformise, to reduce that fragmentation. So we have vendors coming from different perspectives. We've got hyperscalers in there. We've got you guys and appliance oriented histories in there. We've got very big organisations and start-ups in there. But overall, as I say, out of the 16 vendors, you come across very well. You're one of the leaders in the platform side of things. So that suggests, and read the report, everyone, that suggests that you're doing a lot of things really well. But the one thing I wanted to pick up on, we break the report down into the functional requirements. So the key criteria of the products and then the non-functional criteria, which we call business criteria. So can it scale? Can it perform at scale? How well does it respond under pressure and reliability and ecosystem and those sorts of things? And you had the highest score in the report on this. The number doesn't matter. The number is 4.3. So what? We can dig into that. But I'd like to know, back at you, how much effort do you put into not just putting the functions, you're the product person, this is your domain here. So how do you plan for making sure that you can deliver massive levels of reliability at scale, given the complexity of the environments that we're talking about here? Well, first, I want to compliment you on the radar. It's impressive that it's a really strong field that you dug into. That is the background. So, you know, I will say the fact that you dug right into the one thing that we never really market, but is fundamental to everything we do, it's reliability. You know, we talk about scalability. We talk about simplicity. We talk about, you know, high availability, that sort of thing. But we don't talk about reliability. For this to operate at scale, no pun intended. I don't know how many times I have to say that in my career, but no pun intended. For this to operate at scale, it just has to work. And I'll say that if you go out and look at the reviews of our platform, whether that's a small business operating in the middle of Idaho or, you know, a giant... In fact, kind of preparing for today, I was looking at a bunch of interesting use cases, like there's a maritime MSP that's putting our clusters out on ships that are going over, you know, open ocean. When you're in environments like that, where you cannot get to the infrastructure, it just has to work. And if there are failures, it needs to reliably react to that. And so we put a ton of effort into making sure that the product does what we say it does, and then once you have a really solid foundation, you can build on top of that. So some of the newer fun features that we've included, so we, you know, we have zero-touch provisioning allows you to kind of plug in networking, plug in power and have this system go from unboxing to being able to run applications with, you know, no real IT expertise on-prem to do that. We've extended that all the way through the application layer. So we have, we've got a certified Ansible collection, we've got a Terraform provider, but we've also built our own application deployment product, our feature within the product that allows you to define, here are the applications that I want on this site. And so after you stand this thing up, we can get the applications up and running. All that's to say it's like new, cool, innovative, fun, works well with Kubernetes and all sorts of cloud-native technologies, but we would not be able to do that if the underlying foundation wasn't as reliable as it is. And it's one of those things where I can say it over and over, but until you actually have this product in hand, it's somewhat hard to believe. The closest I can get to that is look at literally every single, you're going to see two things at almost every single review of the product. One is that the reliability, it does what it says it does. And then the other thing is, if I have a problem, I can call support and they will answer, usually within about 90 seconds. And, you know, it's not just a tier one person that's going to hand you off to somebody else or finger pointed. It is, we own the problem from start to finish. And both those things really shine through in pretty much any interaction with our company. And you're reminding me, actually, one of the very early conversations I had with you guys, you brought up a shipping example. And I'm always, so top tip, if anyone out there has ever thought of being an analyst, a really good question to ask is, what's the origin story for the company? And because generally you'll find out, oh, they came from a regulated industry environment, therefore they'll have that stuff really sewn up. And with you guys, yeah, you'd already worked in really frontier, if I can use that term these days, given that AI is taking it over, you've already worked in hard environments. And so you just know that it just has to work. Whereas some organizations that might have come just from a software perspective in the enterprise, there are certain aspects of reliability. They think, well, yeah, of course, Wi-Fi will always work because we're metropolitan kind of thing. So I get it. And I hear you on that one. It extends out to the fleet management elements of what you do. And everything that we were talking about before, one of the issues organizations have, major issues organizations have with the fragmentation is there's generally not enough people to manage all of the devices that are out there, be it 300,000, 3,000, 300,000, it's the number of people relative to the number of alerts that are going on, just the time required to manage all of that. And so what have you brought to the party in terms of, you've mentioned a bit in terms of the deployment aspects, but overall end to end, what does fleet management mean to you and what are people asking for and how do you deliver on that? Yeah, I mean, part of it's centralized visibility and orchestration. There's another angle to it, which is kind of interesting. So scale computing was actually acquired last year around this time by a company called Acumera. And Acumera, we kept the scale computing brand because it's got a lot of value in the market, I would say, just all of what people know us to do. But what Acumera brought with them was two or three actually really interesting technologies. I'll focus on two of them, though. One is a product that they call Reliant, that on paper sounds a lot like HyperCore. It looks like HCI stack that's going to provide the ability to do a two node solution where if there's a failure, we're going to react to it and everything. But instead of, you're talking about origin stories. Our origin story at scale computing is that, you know, it needed to go in a remote spot and have no IT expertise and it's just going to work from the ground up. They approached the problem from a really different perspective. It was a, I need to operate this at scale across thousands and thousands of sites, but I want to be able to treat every individual site slightly differently. I want a homogenous interaction with an API, but I want to be able to kind of treat all these little snowflakes out there well. And one of the Reliant kind of claim to fame customers is Taco Bell. We've got 7,000 plus locations, maybe over 8,000 at this point. And in order to operate at scale like that, you basically have to have that API first mentality. And they have a really interesting technology called hashing that allows them to really make bespoke understanding of a given environment and have these site level variables built into that API. And so I will say that, you know, with with fleet management and what we do on the scale computing HyperCore side, we're able to kind of hand over the tools to say here, this is how you would operationalize this at scale with a Reliant technology. It's more of an as a service offering. And so you can think of the HyperCore fleet manager, you know, former legacy scale computing product as a self-managed tool, whereas the Reliant product is a fully managed service with outcome driven results. And we say, these are the things we're going to try to drive to and let us manage that for you. And we built the tools and kind of everything we need to be able to do that at scale. And what's happening is we're converging these products over time. And so even even later this year, there's going to be some interesting announcements around how these two technologies are coming together to really satisfy that full spectrum of I want self-management all the way through to I want it managed on behalf of me by scale. And along with that comes a really cool operational technologies that we can pass along to the end user to interact with as well. The other technology that came along with that was a product called Acuvigil, which is a 24-7 kind of managed network service that we offer at scale computing now. And all that's being kind of intertwined with the vision of how these things come together. You can imagine it's like a lot of the problems that you were talking about as you're centrally operating as a NOC, one of the biggest issues that we see out there is the network. It's not the infrastructure always. And so if the if the network's not reliable, if you don't have full visibility and control of that network, it becomes a problem. And so these things kind of converging together over time is what we're expecting to see in the market is what we're doing internally on the roadmap. Yeah, I completely agree in terms of particularly now back to what we talked about at the beginning with with AI inference, data movement becomes fundamental to what people are expecting to see in a much higher level, very different level of dashboard. Fantastic. So going to start wrapping up now, if that's OK. And we talked before about what should be the what should be the takeaways. Just by the way, that's another great example of the origin story. You've got the configurability on one side and then the reliability on the other side and put the both together and you've just got this this end to end thing. So so so best of luck with that. I knew there was there was something in my head. I had to get it out. There you go. There you go, guys. So my takeaway action obviously would be read the radar. We put a lot of effort into these documents to help people understand the space, help people understand how to think about evaluating what vendors are available. And we're very strong on the fact that there's there's never a one size fits all, particularly in this area where there's different there's very different reasons why people might be wanting to deploy at the edge. And there's very different kinds of vendors. So generally, the platform side is going to have a more comprehensive offering than the feature side. But don't rule out anything, guys, in terms of the radar and just use that as your starting point for understanding of how to think about it and how to evaluate for your own needs. So that's that's mine. Please read the radar. Craig, what would be your starting point for moving forward? What's the next steps? Well, I'll say I'll second yours. I will say read the reports. Really useful to understand just the lay of the land of where all these products and services really fit together out there in the market. But the next actionable step, I would say, is let's start a POC. And I've said a lot of almost outlandish things about how great the product is. But until you try it, you won't actually believe it. And every every fleet starts with one. We have a lot of technologies, a lot of just go from proof of concept to pilot, pilot all the way through to full rollout. And we've got a team of really smart people that can kind of help you navigate that process. It can be really complex. I think part of the challenge that people have when they start doing this is to define what success looks like for them. And our team's really good at helping through that, defining, you know, this is here's why we're doing this. This is what the outcomes are going to be and kind of every step along the way to give you confidence and knowing that at the end of that step, you're ready to graduate on to the next one with a full slate of features, functionality and a full team behind it to make sure that you're successful in the next step behind that. OK, I'm going to endorse your POC point and then I'm going to raise you. So on the POC, clearly, if you're putting together what I would say is start a POC in terms of do the things necessary to start a POC. So understand the problem you're trying to solve. Understand what are the criteria that what does success look like? So have something as measurable as possible in terms of success. And that could be we're going to be able to reduce our operational costs or it could be we're going to be able to rationalise certain systems or we're going to be able to run a workload we couldn't do before. So whether or not you end up running a POC, which is a very good idea in this space, you will need to do all of those things anyway. So start down that track. Start thinking about what it is that you need to have in place. So where I raise you, a lot of the conversation we've had has been on the more technical side in terms of how hard it is for you guys out there, the operational engineers and networking teams and people running this stuff and managing the stuff and overseeing the environment. And there's an additional layer to this, which is why are we building any of this stuff anyway? So have a think in terms of what are the business drivers for these needs? Are we trying to increase the number of customers, improve customer service? Create new experiences? Are we trying to increase our sales? What is it that the business is going to get out of this? And the reason to do that is because sooner or later, someone's going to sign off on this and they will sign off a lot more easily on something that actually gives them benefit on the business side, as well as giving the benefit on the technical side. There you go. I'll throw that one back here. So any last thoughts in terms of the... We've got the POC, we've got the rationale. What would you say, from all your customer experience, success looks like and what would you leave people with just as a thought of thing you could throw in there? As you were talking through kind of the business justification behind a project like this, we see it fall into a couple of different categories. Usually it's, I'm going to keep the lights on, I've got to reduce the cost of kind of maintenance of what I already have out there, or it's kind of a future-proofing exercise of I want to achieve something in the future. And as you said, a lot of times that's driven based on some type of business outcome of a customer experience, patient outcomes or what have you in a given environment, but I will say what's coming for everyone is an inferencing explosion. And so back to that in, I will say whatever solution you decide to go with, make sure that it's flexible enough to not just work with what you have out there today or what you're planning for this current spread that you're working on, but what that you don't quite have visibility into is the next one to two to three years down the road. So factor that in as well. Brilliant. Well, let's leave it with that. Yeah, absolutely. That clicks into, think about everything around it, including the network, which you said earlier. Thank you so much, Craig, been brilliant speaking to you and good luck everyone out there in terms of your edge deployments and getting this stuff right, because there's so much dependency on the edge increasingly as we move into the future. Awesome. Thank you, John.
