Podcast #180 Hyper-Converged

TRANSCRIPT

Ken: Good day, and welcome to episode 180 of our Momenta Digital Thread podcast series. Today, I'm pleased to host Stephen Berard, our Chief Technology Officer here at Momenta. Stephen is a digital industry technical strategist with over 25 years in software architecture, design, and operations, with expertise in driving large-scale, highly reliable distributed cloud and IoT solutions. As Chief Architect at Schneider Electric, Stephen directed the technical strategy for EcoStruxure, Schneider Electric's IoT platform. Prior, Stephen spent seven years as Technical Program Manager at Microsoft on the Windows core OS team, where he advanced data center power management, drove battery life improvements, and defined the Connected Standby experience. Stephen, welcome to our Digital Thread podcast.

[00:01:28]

Stephen: Hi, Ken, it's great to be here. I look forward to an engaging conversation.

[00:01:32]

Ken: As well. I always say this, I always- it's taken so long for us to get together. But you've been with us for over three and a half years at Momenta. And there has been no excuse at this point. I'm glad I finally got you to participate in this. We call this the Digital Thread podcast, and very much about your own personal and professional digital thread. In other words, the one or more thematic threads that define your digital industry journey. What would you consider to be your digital thread, Stephen?

[00:02:01]

Stephen: That's a great question. I've always been interested in networking and communications. When I did my study at university, the internet that we know today was starting to come about. I think my first email address was a BitNet address, if you remember those days. Around then, TCP/IP was starting to emerge as a de facto standard. And I was interested in what could be possible once everything was networked. This was way before we had fiber to the home and video and things that are mobile devices. It was an interesting time, and I was intrigued by that. During my studies, I landed an excellent internship where I was introduced to the concept of network management systems. At the time, these were systems like HP OpenView. And during that, I was managing all these devices, mostly telecom routers, firewalls, and other things connected to the network- all centrally, all remotely. I was intrigued by the ability to configure an IT device in Ireland over our WAN. And so, that was a defining moment for me. That internship ultimately turned into my first professional role. I was technically responsible as a network management engineer for a small fleet of these remote devices.

I then transitioned to software engineering; this was all with APC, one of the first companies I worked at. Instead of just using those and operating those devices, I wrote the code behind them. I worked on the agents and the management software for that. At that time, it was all SNMP, the Simple Network Management Protocol, which, ironically, is still in use today. And from that, that was my entry into what we now call IoT. While others in the industry came from things like SCADA and control systems and other on-premises solutions into the IoT, I came from a bit more of an IT in a datacenter thing. In the early 2000s, I transitioned, as you mentioned, over to the Windows kernel team, and I worked on several issues that are related to power management and battery life. But again, that thread of managing those things remotely en masse over the network was still there. Many of the things I worked on were not SNMP but were related to using things like group policy to manage them en masse. And then ultimately, I ended up at Schneider Electric, where I was an IoT architect, so formal IoT role there. And again, the IoT is about connecting and communicating to these devices. That thread through everything is that network connectivity and dealing with these things en masse and the power.

[00:04:14]

Ken: That's an interesting angle in terms of vectors. We always see the convergence of IoT as people who have come from, let's say, an industrial background. Think PLC, DCS, etc. Telco, right? This certainly speaks to yours as well. And then generally, just other forms of engineering usually involve machine-to-machine. Your vector is certainly one of the strong ones to lead you to IoT. I liked the fact you got your start at APC in '95. You were architecting software for the enterprise management of their data center business line. Many will know that APC is a market leader in power conditioning and management, so think of uninterruptible power supplies. I see the product name for your profile was infrastructure at the time. Indeed, a precursor to the later work at Schneider Electric, who I believe acquired APC. What were some of the early lessons you learned at that intersection of large-scale enterprise deployment and management of critical equipment?

[00:05:16]

Stephen: Yes, APC coined that term with that stylized 'x.' When Schneider Electric acquired APC, they brought that forward into the EcoStruxure name. And they kept that same 'x.' I always enjoyed that because it shows some of the roots because I started my career at APC, so it was always nice to see that. Joining APC was interesting. I joined when they were a small company with less than $100 million in sales annually. And then when I finally left, ten years later, they were at about 2 billion in sales. And then, a few years later, they were eventually acquired by Schneider Electric. I get to see that company transition and be part of the organization as a transition from a small company to a midsized company and from a midsized company to a large enterprise company. And so fantastic set of lessons that I got to learn through that. One of the exciting things is that agile development is commonplace if you look at how software today is done. But at that time, that wasn't the case. You couldn't go to Barnes and Noble and pick up a book on Scrum or agile development; that didn't exist. But our team was interesting and dynamic. We were a small software team within a large hardware organization – but we had a lot of autonomy and flexibility to experiment with things. And I remember getting some early agile white papers and manifestos and stuff that I think were sourced from some of my colleagues on UseNet if you remember that. And we get to experiment with a lot of that. We get to do things like automatic build servers. We did some iterative development in our releases. We did a shared development. We took over a conference room, and I'll add that as our shared office. We got to experiment with that well before these things were commonplace. It was an interesting experience to be part of that early on, learn about that culture, help shape it, and see what works. That was tremendously useful. We were also given the freedom to try out new things. One example I'll use here is our team was responsible for software that ran on servers. It was there to monitor the battery system. If anything were to interrupt the power or the battery condition, it would properly shut down those servers so that data and databases at the time were preserved. While that seems straightforward, our product ran across many platforms, including NETWORTH, NT, and many different flavors of Unix.

And so, the original codebase was written in C++, but it became quite convoluted and difficult to maintain. I was part of the team that was tasked with re-architecting the product. That was my first experience at big-scale software re-architecture. The other thing we tried to do, we said, "Hey, listen, we have to run across all these platforms. What can we do? What tools can we use to make that easier?" We used this thing that had a wonderful tagline, "Write once, run anywhere." If you remember that, as you can guess, that was Java. I got early exposure to that. We started working on Java 1.0. and 1.1 came out right in the middle of our product release, so very early in the Java days. I got hands-on experience with that; I watched how Java evolved and morphed into what it is today. If you look up 'Java power,' some of the tons of the software we use today, whether Netflix or Amazon- large systems are all built on Java. It was unique and interesting to be at the forefront of that way back then. I'm happy to say the code that we re-architected is still used in production today, which is interesting. I don't think many people can say that their software's still running 20 years later. In the end, APC was a great culture. I learned the culture of continuous learning. That imprinted on me the type of environment and culture I crave and want to work within.

[00:08:35]

Ken: Speaking of large enterprise companies, in 2005, you joined Microsoft, focused on the intersection of power management and core operating system features. What were some of your key initiatives and wins there at the time?

[00:08:48]

Stephen: Microsoft could not have been a more different culture from APC. I felt like a fish out of water for almost 18 months. The cultural cadence was so different for me. But ultimately, I had a successful career. I spent another ten years at Microsoft, found my place there, and enjoyed my time there. I worked on a number of interesting projects and two key projects that highlight that I'm proud of; the first is enabling power management on Windows Server. At the time, power management features were not enabled by default on Windows servers. A lot of the hardware had these power-saving capabilities. Those technologies came from the mobile side of the world, but they were not turned on at servers by default. And this was a time well before virtualization was popular. You have these servers running at full speed, full power, taking no advantage of power management. But were at super, low utilization, somewhere below- like less than 5%. I can't remember the exact number, but I think the average utilization was in the 2% to 3% range. The amount of energy was just wasted, and the amount of heat and cooling required was obscene. What we wanted to do, we felt strongly on the team about energy efficiency and what we could do there. We felt that we should be able to turn this on by default, and that would be the default state, meaning that people would use this en masse in data centers. And it turns out that there was a lot of, I would say, cultural inertia around that. There was this thinking that enabling that would somehow decrease the server's performance.

The OEMs competed on how good their servers were or how performant their servers were. There was a lot of reluctance on the OEM side to enable this by default. This was a major project. I know it sounds simple- turning that on by default, but we had a lot to overcome in that inertia. I worked closely with the Windows Performance team to develop a set of metrics and measure various hardware with and without this enabled. I worked with some people from the EPA, Energy Star Program, Lawrence Berkeley National Labs, and Climate Savers Computing Initiative to build understanding around this, get some real data on this and help change that mindset. In the end, we were able to get everybody to agree that we could turn this on. We did some detailed measurements and found that turning it on hurt performance. But that performance was so negligible that it was unnoticed by many. On the flip side, we saved over 18% with the same workload on the same hardware regarding energy efficiency. When you translate that over the number of Windows servers, the amount of energy saved by that was just massive. And so, to me, that was one major project that I'm proud of at Microsoft. And in the end, I received the Microsoft Environmental Action Award for the work we did on that. The second issue that I think I'd highlight is, and you mentioned this in the intro earlier, came during the Windows 8 release. Here, we were trying to compete and build a Windows tablet experience that could compete with the iPad. And if you look at iPads and mobile devices, the power experience is very different from a PC. You don't shut down your phone when you're done at the end of the day. Things are always on, always connected.

I worked across different teams to bring that experience, define what that experience is for Windows and then bring that experience to life. And in the end, that experience was called Connected Standby in Windows 8. It's now been renamed Modern Standby; that's the new evolution. But in essence, it's that mobile experience that you have, where you can get emails when your screen is off. Your device is always on, connected, and reachable when you don't shut down. If you think about things that we're used to know, like taking VoIP calls and a call from Teams, the ability for that device to ring even though it's "off" requires a lot of magic behind the scenes. And so, I helped bring that into existence. The Windows 8 team worked with a large virtual team working with folks on the kernel, hardware, firmware, OEMs, and many of our partners. So fortunate to be part of that experience and change how that is fundamental to what it is, fundamental to how the power experience is today on Windows PCs. If you buy a modern laptop today, then connect to standby, Modern Standby is the default experience you get in there, so it's nice to be able to see that. Those are the two key things that I'm proud of from my days at Microsoft.

[00:12:43]

Ken: And when Stephen, in many of our Team's call, isn't functioning as CTO for Momenta, he often will take the blame for almost any Microsoft woe we have with the systems that we use. He said, "You can probably blame a decision I made way back for that problem." He's a useful poster child to have.

[00:13:04]

Stephen: Yeah, when you work on the kernel team when, when you see an issue like that, you're either know the one person who made that decision that caused that problem, or you make up a person who did it. It's an interesting perspective.

[00:13:15]

Ken: Well, let's fast forward to Schneider Electric. You joined them in 2012, ultimately serving as Chief Architect of their EcoStruxure IoT platform. This was an interesting time as each of the major OT players was developing their platform in the wake of GE's early success with Predix. What were some of the key design considerations for this platform?

[00:13:37]

Stephen: Yeah, indeed, GE set the frame of reference for IoT platforms. They invested a lot of money there; there was a lot of marketing and a lot of hubbub around Predix. And Schneider leaned into that and said, "Hey, we need to build something like that." And we're talking 2012, which is- as I look at the calendar now, ten years ago- that was early in the IoT platform game. The services you know and expect from Google, Amazon, Microsoft Clouds, and other IoT platforms largely didn't exist. A lot of that had to be built from scratch. There was no device connectivity service like you have with AWS IoT Core or Azure IoT Hub. We had to build a lot of that, and we had to understand what the core features were needed. Our initial goals were to build those core services pertaining to connectivity, device management, data management, data storage, etc. The intent was to core out that functionality from all the different product teams. If you look at all the different products and services across Schneider, they are connected or ultimately will be connected. And if every team is building an MQTT connectivity server and firmware update over the air, etc. That's just a massive waste of engineering resources. The goal of our team was to centralize those cores and then allow their lines of business to be able to focus on the things and the value that they deliver to their customers. The data center folks could rebuild features for data center management and not worry about sending data over MQTT. Our goal was to deliver those core services. But we didn't just want to deliver them as a- "Here's a package, you can go run that as part of your solution." We delivered those as managed services. Everything we designed and implemented, we ultimately also operated, managed, and maintained.

And so that was a big pivot, big pivot, especially for a company, an industrial one like Schneider Electric. That's common place for the cloud providers; it's common place in SAS. But for an industrial player that does mostly SCADA on-premises systems, this was a very, very foreign concept. We had to design a bunch of these things and operate them. It was an interesting time to be there because to build that organization, to build that know-how within the organization, was an immense challenge. And we always got fast feedback. I remember I was based in the Grenoble site. And our support people were just across from me, and my desk faced their area. And I can always tell when we ship the bad release because there would be a bunch of grumblings and groanings, and they would come over and walk to my desk. And so, we had a good, fast feedback loop. It was an interesting time to be there. I think some of the other things that we wanted to do in terms of design criteria is we want it to be portable. At the time, we selected Microsoft and Microsoft Azure, as are our cloud partners and the platform that we wanted to build on.

But we needed the ability to potentially run on-premises should our customers need that or run on another cloud, or there are certain situations like, for example, China. China's a bit different; we likely need to operate on a local cloud provider there. We wanted the platform to be portable. That meant that we had to design so that we weren't relying too heavily on managed services that were vendor lock-in. At the same time, we also didn't want to reimplement everything ourselves. We had to find that good balance between using managed services, creating good abstractions, and then building things ourselves. That was a delicate balance, and I think we struck a good balance in the end. But it was a key challenge in the design criteria. Overall, I think it was an interesting time to work on IoT. As I look back now, one of the things that I remember from working in centers, I always felt like we were behind. I thought GE was out in front, like, "Man, we're just so late to this IoT game." Looking back at it retrospectively, I realized how early we were and how much of a front-runner Schneider Electric and EcoStruxure are. It's great to be part of that experience.

[00:17:22]

Ken: It's interesting. I had a conversation this morning with somebody I would consider to be a very strong advocate of Edge computing. We had the same conversation because he was involved very early with some telco companies on some of their stuff. And he was discussing how slow this industrial space moves. And in some sense, even though you think you're behind, you might be a bit of a pioneer.

[00:17:45]

Stephen: Absolutely.

[00:17:46]

Ken: Yeah, interesting timing. I know you were saying it was almost ten years since you've been at Schneider. You've been at Momenta three and a half years already, which is incredible because time has flown. You serve as CTO for our venture capital work and support many key advisory efforts, mainly by the side M&A. Tell us a bit about your remit. And what have been some of your favorite projects during those three and a half years?

[00:18:09]

Stephen: Yeah, it's hard to believe it's three and a half years. But as they say, time flies when you're having fun, right? I joined Momenta to be part of the advisory team. The idea was to leverage my experience from Schneider and work on several projects to help mostly large industrial companies and equipment manufacturers through that digital transformation journey. There were a lot of lessons I learned in my time at Schneider and during EcoStruxure, many of them the hard way. We tried many things and failed and had to pivot and learn the right way to do things. And that experience was a hard one. And the intent was to leverage that, and I got to be part of some interesting and incredible projects on the advisory team. One of my favorite projects was a large industrial equipment company. And this is a company that casts their products out of metal, like metal mechanical devices. They're sold through the channel with traditional sales and service manually, inspected manually, there was no digital connectivity, and there was no sort of digitization of that process. And so that project has been an ongoing project for at least two years when I was part of that early on. And now they're selling their products online; they have connectivity to their products, and the products are monitored. They're even doing predictive analytics for when they should service that equipment or when a potential optimization setting might need to be changed to improve optimization and things of that nature. It's rewarding to see a company go through that process and be there to help them out.

As you mentioned today, I've mostly transitioned over to our ventures team in the role of the CTO. Here, I helped craft our investment thesis. I look to identify what technology is coming up, the trends, what that means to us in industry, and what we need to pay attention too. I weave that into our approach to investment and our investment thesis. As we're looking at new investments, I also do a lot on the due diligence side of things. Again, I focus mostly on the technology side, but I help figure out, like, are these the right characteristics? Does this company have the technology underpinnings to support the kind of business you're trying to do? I help a lot on that due diligence side. And then, I would say that the third thing I do on the ventures team is to help advise our portfolio companies. I sit on the board of several of our investment companies. I help provide advisory services to them as they face different challenges and navigate the waters of growth.

[00:20:16]

Ken: It sounds like a great position and at a great company. I can say so myself.

[00:20:23]

Stephen: Well, it's nice and exciting in many ways, too, because you get to see a wide breadth of different things. The boards I sit on and the companies there could not be more different. And to get that kind of breadth of experience and work with those different companies is fulfilling.

[00:20:37]

Ken: I think of Momenta often as a perspective platform. When you're sitting up, elevated, and working across several different companies, you have visibility into them. You get to see trends and see the emergence of trends, or in some sense, tag these trends early on. I know we've been involved in Edge for quite a while because you can't be an OT and not talk about Edge. After all, OT is Edge by definition. But I know in some of the recent work you've done, you've coined what I consider a new term, and that's Hyper-Converged Edge or HCE. Tell me, what does the term mean? And how does it differ from the more widely known Hyper-Converged Infrastructure or HCI?

[00:21:17]

Stephen: That's a great question. And we look at Edge, and you're right. It is where we are in IoT. If you look at HCI or Hyper-Converged Infrastructure, that's well known. And in many ways, it's fundamentally changed how we've managed IT. I believe a similar transition is needed in the IoT or Industrial Edge. It's tempting to look at HCI and just say, we can just scale that down. We can put that into this bar Edge or this IoT Edge, and it'll work. And on the surface, it looks that way. But I believe that a very different approach is required. And that's were looking at the term, and we've coined the term Hyper-Converged Edge or HCE. At this IoT Edge, you have a wide variety of hardware skews. There's a very limited set and variety in hardware in the data centers and data closets. On the IoT Edge side of things- very, very different. There are gateways, and there are different CPU architectures, they have different amounts of memory, and they're on four networks. It's a very, very different environment. And so, the types of solutions and the technology to support those are very different. That's not to say we're not going to use some of the technologies from HCI, like virtualization and containerization, or even some clustering like you see with Kubernetes. We need to adapt to how the platform's features are to support those kinds of scenarios. I can give a couple of examples. Suppose you look at how these devices get installed in the industrial space. They're generally wired up by electricians, physically put in on a wall or in a ceiling joist somewhere or connected to a factory line and wired up by an electrician. That person generally doesn't understand how to configure an IP address or change a firewall rule to make sure that that can communicate back to the cloud. So how you approach developing the solution so that the electrician can install it requires thinking about that problem space differently. This joke that we have when we're talking about this is, "Hey, the pizza delivery guy should be able to plug that in and get it to work." And that's exactly the technology, I think, that's needed in this space.

[00:23:16]

Ken: That's a good example of how many IT technologies are impacting the OT side. Again, going back to my conversation earlier today, the gentleman talked about virtualization all the way out to the chip effectively and described that as what HC would be. And it's an interesting model. You mentioned earlier how different the platform play was for Schneider at the time and the cultural change and business model change they had to go through to support that. As we think about this, I'll call it new Edge or HCE. How do you think it'll affect the OT's established order of technology providers? In other words, who will be the likely winners from your perspective?

[00:24:04]

Stephen: That is an excellent question. And if I had a perfect answer to that, I probably could make some good investments and retire early. I think what you're going to see, and we'll continue to see, two common threads. One is that the cloud providers are trying to capitalize on the Edge. You have the likes of Microsoft and Amazon and Google, Oracle, IBM, and others that have a good set of cloud services and cloud platforms and want to extend that to the Edge. On the other side, you have the established on-premises players, as we tend to call them, those industrials that have on-premises hardware or software- or both. They're providing those solutions, and they're already at the Edge, and they want to connect. If you look at the side of cloud folks, they desires to drive everything to the cloud. And so, I think in many ways, while they are Edge, they're very cloud-like Edge. They're not quite that hardcore Edge. Suppose you look at the industrial players and the on-premise solutions. In that case, I think we will see those companies- the way they're approaching that take hold. And that's what we're looking at with HCE. Now, at the same time, I think they're missing some of that technology that the cloud providers have. I think the dynamic you'll see is a number of these established on-premises players, Edge players, make several strategic acquisitions to bring on the talent and the technology to support that HCE that we're talking about. They'll have to be linked with the clouds because many cloud providers also play in this space. And many of those industrial players are the core partners of those cloud players. But I think you will see this driven by those initial on-premise players. But again, they don't have that technology today. I think some interesting startups are out there, interesting open-source projects that they will bring on board and use as a formation for that, as well as the talent and the mindset.

[00:25:53]

Ken: Going back to your comment, you'd invest in them if you knew who the winners are. Knowing who the winners are, I think you're already advising us on who to invest in. And I would, of course, advise you not to share that. So that's why you're front and center to our ventures team. Having listened, of course, to our Digital Thread podcasts quite often, you know that in the end, we always like to ask about one's inspiration. Stephen, what would you consider to be your inspiration?

[00:26:23]

Stephen: Well, I've always been intrigued by technology. What it can do, where it's going, and quite honestly, the pace and the acceleration you get with technology. If you go back to TCP/IP and the internet being an early theme for me, you look at where that is now. You have LinkedIn, Facebook, Netflix, and on-demand everything. Satellite internet from SpaceX, and just how fast that technology has moved. And we're seeing that not only in computers and IT but also in biotechnology and health sciences and electric vehicles, and it's transforming everything. I've always been intrigued by that technology, so I think that's one of the key drivers.

The other thing that's been a driver for me, and I can't point to a single source or single book, but the whole idea of being a continuous learner. Early on, my father said, "Hey, you need to get good at learning, not just learn. You're growing up in a world where it's not just about going to learn a skill and then doing that for the rest of your life; you need to learn continuously." And so, he instilled that spirit of learning into me. And if you look at themes, I think Satya Nadella, when he came over and took over at Microsoft, inspired that culture of learning and experimentation. So that's always been a driver for me. And I think the pairing of the technology and that continuous learning leads to a pretty interesting life. And I've had some great experiences and had some great opportunities. And I think I'm just getting started.

[00:27:41]

Ken: Earlier in the conversation, you talked about how this converged to bring you to IoT. I would think, conversely, that this idea of continuous learning is a needed skill relative to IoT because the very definition of IoT is ethereal. And of course, today, it includes the cloud, tomorrow the Edge. And next day, looking at AIML at the Edge optimization and adaptive behavior on and on and on. It's a series of learning exercises in some sense. And thus, I would say, a needed skillset, so it's a good background. Stephen, thank you for sharing this time and these insights with us today.

[00:28:20]

Stephen: Well, thanks, Ken. I appreciate it. And I'm sorry it's taken us three and a half years to get on the podcast, but it's good to be here.

[00:28:27]

Ken: Well, it's good to finally be able to have the conversation that we probably should have had a long time ago. But then again, with three and a half years of seasoning to it. This has been Stephen Berard, our own Chief Technology Officer here at Momenta and architect for the Hyper-Converged Edge.

[The End]