>>Hey everyone, welcome to the Cube's coverage of AWS Reinvent 2022. Lisa Martin here with you with Subaru ier, one of our alumni who's now the CEO of Aerospike. Sabu. Great to have you on the program. Thank you for joining us. >>Great as always, to be on the cube. Luisa, good to meet you. >>So, you know, every company these days has got to be a data company, whether it's a retailer, a manufacturer, a grocer, a automotive company. But for a lot of companies, data is underutilized, yet a huge asset that is value added. Why do you think companies are struggling so much to make data a value added asset? >>Well, you know, we, we see this across the board when I talk to customers and prospects. There's a desire from the business and from it actually to leverage data to really fuel newer applications, newer services, newer business lines, if you will, for companies. I think the struggle is one, I think one the, you know, the plethora of data that is created, you know, surveys say that over the next three years data is gonna be, you know, by 2025, around 175 zetabytes, right? A hundred and zetabytes of data is gonna be created. And that's really a, a, a growth of north of 30% year over year. But the more important, and the interesting thing is the real time component of that data is actually growing at, you know, 35% cagr. And what enterprises desire is decisions that are made in real time or near real time. >>And a lot of the challenges that do exist today is that either the infrastructure that enterprises have in place was never built to actually manipulate data in real time. The second is really the ability to actually put something in place which can handle spikes yet be cost efficient if you'll, so you can build for really peak loads, but then it's very expensive to operate that particular service at normal loads. So how do you build something which actually works for you, for both you, both users, so to speak? And the last point that we see out there is even if you're able to, you know, bring all that data, you don't have the processing capability to run through that data. So as a result, most enterprises struggle with one, capturing the data, you know, making decisions from it in real time and really operating it at the cost point that they need to operate it at. >>You know, you bring up a great point with respect to real time data access. And I think one of the things that we've learned the last couple of years is that access to real time data, it's not a nice to have anymore. It's business critical for organizations in any industry. Talk about that as one of the challenges that organizations are facing. >>Yeah. When, when, when we started Aerospike, right when the company started, it started with the premise that data is gonna grow, number one, exponentially. Two, when applications open up to the internet, there's gonna be a flood of users and demands on those applications. And that was true primarily when we started the company in the ad tech vertical. So ad tech was the first vertical where there was a lot of data both on the supply side and the demand side from an inventory of ads that were available. And on the other hand, they had like microseconds or milliseconds in which they could make a decision on which ad to put in front of you and I so that we would click or engage with that particular ad. But over the last three to five years, what we've seen is as digitization has actually permeated every industry out there, the need to harness data in real time is pretty much present in every industry. >>Whether that's retail, whether that's financial services, telecommunications, e-commerce, gaming and entertainment. Every industry has a desire. One, the innovative companies, the small companies rather, are innovating at a pace and standing up new businesses to compete with the larger companies in each of these verticals. And the larger companies don't wanna be left behind. So they're standing up their own competing services or getting into new lines of business that really harness and are driven by real time data. So this compelling pressures, one, the customer exp you know, customer experience is paramount and we as customers expect answers in, you know, an instant in real time. And on the other hand, the way they make decisions is based on a large data set because you know, larger data sets actually propel better decisions. So there's competing pressures here, which essentially drive the need. One from a business perspective, two from a customer perspective to harness all of this data in real time. So that's what's driving an inces need to actually make decisions in real or near real time. >>You know, I think one of the things that's been in short supply over the last couple of years is patients we do expect as consumers, whether we're in our business lives, our personal lives that we're going to be getting, be given information and data that's relevant, it's personal to help us make those real time decisions. So having access to real time data is really business critical for organizations across any industries. Talk about some of the main capabilities that modern data applications and data platforms need to have. What are some of the key capabilities of a modern data platform that need to be delivered to meet demanding customer expectations? >>So, you know, going back to your initial question Lisa, around why is data really a high value but underutilized or underleveraged asset? One of the reasons we see is a lot of the data platforms that, you know, some of these applications were built on have been then around for a decade plus and they were never built for the needs of today, which is really driving a lot of data and driving insight in real time from a lot of data. So there are four major capabilities that we see that are essential ingredients of any modern data platform. One is really the ability to, you know, operate at unlimited scale. So what we mean by that is really the ability to scale from gigabytes to even petabytes without any degradation in performance or latency or throughput. The second is really, you know, predictable performance. So can you actually deliver predictable performance as your data size grows or your throughput grows or your concurrent user on that application of service grows? >>It's really easy to build an application that operates at low scale or low throughput or low concurrency, but performance usually starts degrading as you start scaling one of these attributes. The third thing is the ability to operate and always on globally resilient application. And that requires a, a really robust data platform that can be up on a five, nine basis globally, can support global distribution because a lot of these applications have global users. And the last point is, goes back to my first answer, which is, can you operate all of this at a cost point? Which is not prohibitive, but it makes sense from a TCO perspective. Cuz a lot of times what we see is people make choices of data platforms and as ironically their service or applications become more successful and more users join their journey, the revenue starts going up, the user base starts going up, but the cost basis starts crossing over the revenue and they're losing money on the service, ironically, as the service becomes more popular. So really unlimited scale, predictable performance always on, on a globally resilient basis and low tco. These are the four essential capabilities of any modern data platform. >>So then talk to me with those as the four main core functionalities of a modern data platform. How does aerospace deliver that? >>So we were built, as I said, from the from day one to operate at unlimited scale and deliver predictable performance. And then over the years as we work with customers, we build this incredible high availability capability which helps us deliver the always on, you know, operations. So we have customers who are, who have been on the platform 10 years with no downtime for example, right? So we are talking about an amazing continuum of high availability that we provide for customers who operate these, you know, globally resilient services. The key to our innovation here is what we call the hybrid memory architecture. So, you know, going a little bit technically deep here, essentially what we built out in our architecture is the ability on each node or each server to treat a bank of SSDs or solid state devices as essentially extended memory. So you're getting memory performance, but you're accessing these SSDs, you're not paying memory prices, but you're getting memory performance as a result of that. >>You can attach a lot more data to each node or each server in your distributed cluster. And when you kind of scale that across basically a distributed cluster you can do with aerospike, the same things at 60 to 80% lower server count and as a result 60 to 80% lower TCO compared to some of the other options that are available in the market. Then basically, as I said, that's the key kind of starting point to the innovation. We layer around capabilities like, you know, replication change, data notification, you know, synchronous and asynchronous replication. The ability to actually stretch a single cluster across multiple regions. So for example, if you're operating a global service, you can have a single aerospace cluster with one node in San Francisco, one northern New York, another one in London. And this would be basically seamlessly operating. So that, you know, this is strongly consistent. >>Very few no SQL data platforms are strongly consistent or if they are strongly consistent, they will actually suffer performance degradation. And what strongly consistent means is, you know, all your data is always available, it's guaranteed to be available, there is no data lost anytime. So in this configuration that I talked about, if the node in London goes down, your application still continues to operate, right? Your users see no kind of downtime and you know, when London comes up, it rejoins the cluster and everything is back to kind of the way it was before, you know, London left the cluster so to speak. So the op, the ability to do this globally resilient, highly available kind of model is really, really powerful. A lot of our customers actually use that kind of a scenario and we offer other deployment scenarios from a higher availability perspective. So everything starts with HMA or hybrid memory architecture and then we start building out a lot of these other capabilities around the platform. >>And then over the years, what our customers have guided us to do is as they're putting together a modern kind of data infrastructure, we don't live in a silo. So aerospace gets deployed with other technologies like streaming technologies or analytics technologies. So we built connectors into Kafka, pulsar, so that as you're ingesting data from a variety of data sources, you can ingest them at very high ingest speeds and store them persistently into Aerospike. Once the data is in Aerospike, you can actually run spark jobs across that data in a, in a multithreaded parallel fashion to get really insight from that data at really high, high throughput and high speed, >>High throughput, high speed, incredibly important, especially as today's landscape is increasingly distributed. Data centers, multiple public clouds, edge IOT devices, the workforce embracing more and more hybrid these days. How are you ex helping customers to extract more value from data while also lowering costs? Go into some customer examples cause I know you have some great ones. >>Yeah, you know, I think we have, we have built an amazing set of customers and customers actually use us for some really mission critical applications. So, you know, before I get into specific customer examples, let me talk to you about some of kind of the use cases which we see out there. We see a lot of aerospace being used in fraud detection. We see us being used in recommendations and since we use get used in customer data profiles or customer profiles, customer 360 stores, you know, multiplayer gaming and entertainment, these are kind of the repeated use case digital payments. We power most of the digital payment systems across the globe. Specific example from a, from a specific example perspective, the first one I would love to talk about is PayPal. So if you use PayPal today, then you know when you actually paying somebody your transaction is, you know, being sent through aero spike to really decide whether this is a fraudulent transaction or not. >>And when you do that, you know, you and I as a customer not gonna wait around for 10 seconds for PayPal to say yay or me, we expect, you know, the decision to be made in an instant. So we are powering that fraud detection engine at PayPal for every transaction that goes through PayPal before us, you know, PayPal was missing out on about 2% of their SLAs, which was essentially millions of dollars, which they were losing because, you know, they were letting transactions go through and taking the risk that it, it's not a fraudulent transaction with the aerospace. They can now actually get a much better sla and the data set on which they compute the fraud score has gone up by, you know, several factors. So by 30 x if you will. So not only has the data size that is powering the fraud engine actually grown up 30 x with Aerospike. Yeah. But they're actually making decisions in an instant for, you know, 99.95% of their transactions. So that's, >>And that's what we expect as consumers, right? We want to know that there's fraud detection on the swipe regardless of who we're interacting with. >>Yes. And so that's a, that's a really powerful use case and you know, it's, it's a great customer, great customer success story. The other one I would talk about is really Wayfair, right? From retail and you know, from e-commerce. So everybody knows Wayfair global leader in really, you know, online home furnishings and they use us to power their recommendations engine and you know, it's basically if you're purchasing this, people who bought this but also bought these five other things, so on and so forth, they have actually seen the card size at checkout go by up to 30% as a result of actually powering their recommendations in G by through Aerospike. And they, they were able to do this by reducing the server count by nine x. So on one ninth of the servers that were there before aerospace, they're now powering their recommendation engine and seeing card size checkout go up by 30%. Really, really powerful in terms of the business outcome and what we are able to, you know, drive at Wayfair >>Hugely powerful as a business outcome. And that's also what the consumer wants. The consumer is expecting these days to have a very personalized, relevant experience that's gonna show me if I bought this, show me something else that's related to that. We have this expectation that needs to be really fueled by technology. >>Exactly. And you know, another great example you asked about, you know, customer stories, Adobe, who doesn't know Adobe, you know, they, they're on a, they're on a mission to deliver the best customer experience that they can and they're talking about, you know, great customer 360 experience at scale and they're modernizing their entire edge compute infrastructure to support this. With Aerospike going to Aerospike, basically what they have seen is their throughput go up by 70%, their cost has been reduced by three x. So essentially doing it at one third of the cost while their annual data growth continues at, you know, about north of 30%. So not only is their data growing, they're able to actually reduce their cost to actually deliver this great customer experience by one third to one third and continue to deliver great customer 360 experience at scale. Really, really powerful example of how you deliver Customer 360 in a world which is dynamic and you know, on a dataset which is constantly growing at north, north of 30% in this case. >>Those are three great examples, PayPal, Wayfair, Adobe talking about, especially with Wayfair when you talk about increasing their cart checkout sizes, but also with Adobe increasing throughput by over 70%. I'm looking at my notes here. While data is growing at 32%, that's something that every organization has to contend with data growth is continuing to scale and scale and scale. >>Yep. I, I'll give you a fun one here. So, you know, you may not have heard about this company, it's called Dream 11 and it's a company based out of India, but it's a very, you know, it's a fun story because it's the world's largest fantasy sports platform and you know, India is a nation which is cricket crazy. So you know, when, when they have their premier league going on, you know, there's millions of users logged onto the dream alone platform building their fantasy lead teams and you know, playing on that particular platform, it has a hundred million users, a hundred million plus users on the platform, 5.5 million concurrent users and they have been growing at 30%. So they are considered a, an amazing success story in, in terms of what they have accomplished and the way they have architected their platform to operate at scale. And all of that is really powered by aerospace where think about that they are able to deliver all of this and support a hundred million users, 5.5 million concurrent users all with you know, 99 plus percent of their transactions completing in less than one millisecond. Just incredible success story. Not a brand that is you know, world renowned but at least you know from a what we see out there, it's an amazing success story of operating at scale. >>Amazing success story, huge business outcomes. Last question for you as we're almost out of time is talk a little bit about Aerospike aws, the partnership GRAVITON two better together. What are you guys doing together there? >>Great partnership. AWS has multiple layers in terms of partnerships. So you know, we engage with AWS at the executive level. They plan out, really roll out of new instances in partnership with us, making sure that, you know, those instance types work well for us. And then we just released support for Aerospike on the graviton platform and we just announced a benchmark of Aerospike running on graviton on aws. And what we see out there is with the benchmark, a 1.6 x improvement in price performance and you know, about 18% increase in throughput while maintaining a 27% reduction in cost, you know, on graviton. So this is an amazing story from a price performance perspective, performance per wat for greater energy efficiencies, which basically a lot of our customers are starting to kind of talk to us about leveraging this to further meet their sustainability target. So great story from Aero Aerospike and aws, not just from a partnership perspective on a technology and an executive level, but also in terms of what joint outcomes we are able to deliver for our customers. >>And it sounds like a great sustainability story. I wish we had more time so we would talk about this, but thank you so much for talking about the main capabilities of a modern data platform, what's needed, why, and how you guys are delivering that. We appreciate your insights and appreciate your time. >>Thank you very much. I mean, if, if folks are at reinvent next week or this week, come on and see us at our booth. We are in the data analytics pavilion. You can find us pretty easily. Would love to talk to you. >>Perfect. We'll send them there. So Ira, thank you so much for joining me on the program today. We appreciate your insights. >>Thank you Lisa. >>I'm Lisa Martin. You're watching The Cubes coverage of AWS Reinvent 2022. Thanks for watching.

>> And it'll be the fastest 15 minutes of your day from there. >> In three- >> We go Lisa. >> Wait. >> Yes >> Wait, wait, wait. I'm sorry I didn't pin the right speed. >> Yap, no, no rush. >> There we go. >> The beauty of not being live. >> I think, in the background. >> Fantastic, you all ready to go there, Lisa? >> Yeah. >> We are speeding around the horn and we are coming to you in five, four, three, two. >> Hey everyone, welcome to theCUBE's coverage of AWS re:Invent 2022. Lisa Martin here with you with Subbu Iyer one of our alumni who's now the CEO of Aerospike. Subbu, great to have you on the program. Thank you for joining us. >> Great as always to be on theCUBE Lisa, good to meet you. >> So, you know, every company these days has got to be a data company, whether it's a retailer, a manufacturer, a grocer, a automotive company. But for a lot of companies, data is underutilized yet a huge asset that is value added. Why do you think companies are struggling so much to make data a value added asset? >> Well, you know, we see this across the board. When I talk to customers and prospects there is a desire from the business and from IT actually to leverage data to really fuel newer applications, newer services newer business lines if you will, for companies. I think the struggle is one, I think one the, the plethora of data that is created. Surveys say that over the next three years data is going to be you know by 2025 around 175 zettabytes, right? A hundred and zettabytes of data is going to be created. And that's really a growth of north of 30% year over year. But the more important and the interesting thing is the real time component of that data is actually growing at, you know 35% CAGR. And what enterprises desire is decisions that are made in real time or near real time. And a lot of the challenges that do exist today is that either the infrastructure that enterprises have in place was never built to actually manipulate data in real time. The second is really the ability to actually put something in place which can handle spikes yet be cost efficient to fuel. So you can build for really peak loads, but then it's very expensive to operate that particular service at normal loads. So how do you build something which actually works for you for both users, so to speak. And the last point that we see out there is even if you're able to, you know bring all that data you don't have the processing capability to run through that data. So as a result, most enterprises struggle with one capturing the data, making decisions from it in real time and really operating it at the cost point that they need to operate it at. >> You know, you bring up a great point with respect to real time data access. And I think one of the things that we've learned the last couple of years is that access to real time data it's not a nice to have anymore. It's business critical for organizations in any industry. Talk about that as one of the challenges that organizations are facing. >> Yeah, when we started Aerospike, right? When the company started, it started with the premise that data is going to grow, number one exponentially. Two, when applications open up to the internet there's going to be a flood of users and demands on those applications. And that was true primarily when we started the company in the ad tech vertical. So ad tech was the first vertical where there was a lot of data both on the supply set and the demand side from an inventory of ads that were available. And on the other hand, they had like microseconds or milliseconds in which they could make a decision on which ad to put in front of you and I so that we would click or engage with that particular ad. But over the last three to five years what we've seen is as digitization has actually permeated every industry out there the need to harness data in real time is pretty much present in every industry. Whether that's retail, whether that's financial services telecommunications, e-commerce, gaming and entertainment. Every industry has a desire. One, the innovative companies, the small companies rather are innovating at a pace and standing up new businesses to compete with the larger companies in each of these verticals. And the larger companies don't want to be left behind. So they're standing up their own competing services or getting into new lines of business that really harness and are driven by real time data. So this compelling pressures, one, you know customer experience is paramount and we as customers expect answers in you know an instant, in real time. And on the other hand, the way they make decisions is based on a large data set because you know larger data sets actually propel better decisions. So there's competing pressures here which essentially drive the need one from a business perspective, two from a customer perspective to harness all of this data in real time. So that's what's driving an incessant need to actually make decisions in real or near real time. >> You know, I think one of the things that's been in short supply over the last couple of years is patience. We do expect as consumers whether we're in our business lives our personal lives that we're going to be getting be given information and data that's relevant it's personal to help us make those real time decisions. So having access to real time data is really business critical for organizations across any industries. Talk about some of the main capabilities that modern data applications and data platforms need to have. What are some of the key capabilities of a modern data platform that need to be delivered to meet demanding customer expectations? >> So, you know, going back to your initial question Lisa around why is data really a high value but underutilized or under-leveraged asset? One of the reasons we see is a lot of the data platforms that, you know, some of these applications were built on have been then around for a decade plus. And they were never built for the needs of today, which is really driving a lot of data and driving insight in real time from a lot of data. So there are four major capabilities that we see that are essential ingredients of any modern data platform. One is really the ability to, you know, operate at unlimited scale. So what we mean by that is really the ability to scale from gigabytes to even petabytes without any degradation in performance or latency or throughput. The second is really, you know, predictable performance. So can you actually deliver predictable performance as your data size grows or your throughput grows or your concurrent user on that application of service grows? It's really easy to build an application that operates at low scale or low throughput or low concurrency but performance usually starts degrading as you start scaling one of these attributes. The third thing is the ability to operate and always on globally resilient application. And that requires a really robust data platform that can be up on a five nine basis globally, can support global distribution because a lot of these applications have global users. And the last point is, goes back to my first answer which is, can you operate all of this at a cost point which is not prohibitive but it makes sense from a TCO perspective. 'Cause a lot of times what we see is people make choices of data platforms and as ironically their service or applications become more successful and more users join their journey the revenue starts going up, the user base starts going up but the cost basis starts crossing over the revenue and they're losing money on the service, ironically as the service becomes more popular. So really unlimited scale predictable performance always on a globally resilient basis and low TCO. These are the four essential capabilities of any modern data platform. >> So then talk to me with those as the four main core functionalities of a modern data platform, how does Aerospike deliver that? >> So we were built, as I said from day one to operate at unlimited scale and deliver predictable performance. And then over the years as we work with customers we build this incredible high availability capability which helps us deliver the always on, you know, operations. So we have customers who are who have been on the platform 10 years with no downtime for example, right? So we are talking about an amazing continuum of high availability that we provide for customers who operate these, you know globally resilient services. The key to our innovation here is what we call the hybrid memory architecture. So, you know, going a little bit technically deep here essentially what we built out in our architecture is the ability on each node or each server to treat a bank of SSDs or solid-state devices as essentially extended memory. So you're getting memory performance but you're accessing these SSDs. You're not paying memory prices but you're getting memory performance. As a result of that you can attach a lot more data to each node or each server in a distributed cluster. And when you kind of scale that across basically a distributed cluster you can do with Aerospike the same things at 60 to 80% lower server count. And as a result 60 to 80% lower TCO compared to some of the other options that are available in the market. Then basically, as I said that's the key kind of starting point to the innovation. We lay around capabilities like, you know replication, change data notification, you know synchronous and asynchronous replication. The ability to actually stretch a single cluster across multiple regions. So for example, if you're operating a global service you can have a single Aerospike cluster with one node in San Francisco one node in New York, another one in London and this would be basically seamlessly operating. So that, you know, this is strongly consistent, very few no SQL data platforms are strongly consistent or if they are strongly consistent they will actually suffer performance degradation. And what strongly consistent means is, you know all your data is always available it's guaranteed to be available there is no data lost any time. So in this configuration that I talked about if the node in London goes down your application still continues to operate, right? Your users see no kind of downtime and you know, when London comes up it rejoins the cluster and everything is back to kind of the way it was before, you know London left the cluster so to speak. So the ability to do this globally resilient highly available kind of model is really, really powerful. A lot of our customers actually use that kind of a scenario and we offer other deployment scenarios from a higher availability perspective. So everything starts with HMA or Hybrid Memory Architecture and then we start building a lot of these other capabilities around the platform. And then over the years what our customers have guided us to do is as they're putting together a modern kind of data infrastructure, we don't live in the silo. So Aerospike gets deployed with other technologies like streaming technologies or analytics technologies. So we built connectors into Kafka, Pulsar, so that as you're ingesting data from a variety of data sources you can ingest them at very high ingest speeds and store them persistently into Aerospike. Once the data is in Aerospike you can actually run Spark jobs across that data in a multi-threaded parallel fashion to get really insight from that data at really high throughput and high speed. >> High throughput, high speed, incredibly important especially as today's landscape is increasingly distributed. Data centers, multiple public clouds, Edge, IoT devices, the workforce embracing more and more hybrid these days. How are you helping customers to extract more value from data while also lowering costs? Go into some customer examples 'cause I know you have some great ones. >> Yeah, you know, I think, we have built an amazing set of customers and customers actually use us for some really mission critical applications. So, you know, before I get into specific customer examples let me talk to you about some of kind of the use cases which we see out there. We see a lot of Aerospike being used in fraud detection. We see us being used in recommendations engines we get used in customer data profiles, or customer profiles, Customer 360 stores, you know multiplayer gaming and entertainment. These are kind of the repeated use case, digital payments. We power most of the digital payment systems across the globe. Specific example from a specific example perspective the first one I would love to talk about is PayPal. So if you use PayPal today, then you know when you're actually paying somebody your transaction is, you know being sent through Aerospike to really decide whether this is a fraudulent transaction or not. And when you do that, you know, you and I as a customer are not going to wait around for 10 seconds for PayPal to say yay or nay. We expect, you know, the decision to be made in an instant. So we are powering that fraud detection engine at PayPal. For every transaction that goes through PayPal. Before us, you know, PayPal was missing out on about 2% of their SLAs which was essentially millions of dollars which they were losing because, you know, they were letting transactions go through and taking the risk that it's not a fraudulent transaction. With Aerospike they can now actually get a much better SLA and the data set on which they compute the fraud score has gone up by you know, several factors. So by 30X if you will. So not only has the data size that is powering the fraud engine actually gone up 30X with Aerospike but they're actually making decisions in an instant for, you know, 99.95% of their transactions. So that's- >> And that's what we expect as consumers, right? We want to know that there's fraud detection on the swipe regardless of who we're interacting with. >> Yes, and so that's a really powerful use case and you know, it's a great customer success story. The other one I would talk about is really Wayfair, right, from retail and you know from e-commerce. So everybody knows Wayfair global leader in really in online home furnishings and they use us to power their recommendations engine. And you know it's basically if you're purchasing this, people who bought this also bought these five other things, so on and so forth. They have actually seen their cart size at checkout go up by up to 30%, as a result of actually powering their recommendations engine through Aerospike. And they were able to do this by reducing the server count by 9X. So on one ninth of the servers that were there before Aerospike, they're now powering their recommendations engine and seeing cart size checkout go up by 30%. Really, really powerful in terms of the business outcome and what we are able to, you know, drive at Wayfair. >> Hugely powerful as a business outcome. And that's also what the consumer wants. The consumer is expecting these days to have a very personalized relevant experience that's going to show me if I bought this show me something else that's related to that. We have this expectation that needs to be really fueled by technology. >> Exactly, and you know, another great example you asked about you know, customer stories, Adobe. Who doesn't know Adobe, you know. They're on a mission to deliver the best customer experience that they can. And they're talking about, you know great Customer 360 experience at scale and they're modernizing their entire edge compute infrastructure to support this with Aerospike. Going to Aerospike basically what they have seen is their throughput go up by 70%, their cost has been reduced by 3X. So essentially doing it at one third of the cost while their annual data growth continues at, you know about north of 30%. So not only is their data growing they're able to actually reduce their cost to actually deliver this great customer experience by one third to one third and continue to deliver great Customer 360 experience at scale. Really, really powerful example of how you deliver Customer 360 in a world which is dynamic and you know on a data set which is constantly growing at north of 30% in this case. >> Those are three great examples, PayPal, Wayfair, Adobe, talking about, especially with Wayfair when you talk about increasing their cart checkout sizes but also with Adobe increasing throughput by over 70%. I'm looking at my notes here. While data is growing at 32%, that's something that every organization has to contend with data growth is continuing to scale and scale and scale. >> Yap, I'll give you a fun one here. So, you know, you may not have heard about this company it's called Dream11 and it's a company based out of India but it's a very, you know, it's a fun story because it's the world's largest fantasy sports platform. And you know, India is a nation which is cricket crazy. So you know, when they have their premier league going on and there's millions of users logged onto the Dream11 platform building their fantasy league teams and you know, playing on that particular platform, it has a hundred million users a hundred million plus users on the platform, 5.5 million concurrent users and they have been growing at 30%. So they are considered an amazing success story in terms of what they have accomplished and the way they have architected their platform to operate at scale. And all of that is really powered by Aerospike. Think about that they're able to deliver all of this and support a hundred million users 5.5 million concurrent users all with, you know 99 plus percent of their transactions completing in less than one millisecond. Just incredible success story. Not a brand that is, you know, world renowned but at least you know from what we see out there it's an amazing success story of operating at scale. >> Amazing success story, huge business outcomes. Last question for you as we're almost out of time is talk a little bit about Aerospike AWS the partnership Graviton2 better together. What are you guys doing together there? >> Great partnership. AWS has multiple layers in terms of partnerships. So, you know, we engage with AWS at the executive level. They plan out, really roll out of new instances in partnership with us, making sure that, you know those instance types work well for us. And then we just released support for Aerospike on the Graviton platform and we just announced a benchmark of Aerospike running on Graviton on AWS. And what we see out there is with the benchmark a 1.6X improvement in price performance. And you know about 18% increase in throughput while maintaining a 27% reduction in cost, you know, on Graviton. So this is an amazing story from a price performance perspective, performance per watt for greater energy efficiencies, which basically a lot of our customers are starting to kind of talk to us about leveraging this to further meet their sustainability target. So great story from Aerospike and AWS not just from a partnership perspective on a technology and an executive level, but also in terms of what joint outcomes we are able to deliver for our customers. >> And it sounds like a great sustainability story. I wish we had more time so we would talk about this but thank you so much for talking about the main capabilities of a modern data platform, what's needed, why, and how you guys are delivering that. We appreciate your insights and appreciate your time. >> Thank you very much. I mean, if folks are at re:Invent next week or this week come on and see us at our booth and we are in the data analytics pavilion and you can find us pretty easily. Would love to talk to you. >> Perfect, we'll send them there. Subbu Iyer, thank you so much for joining me on the program today. We appreciate your insights. >> Thank you Lisa. >> I'm Lisa Martin, you're watching theCUBE's coverage of AWS re:Invent 2022. Thanks for watching. >> Clear- >> Clear cutting. >> Nice job, very nice job.

(lively music) >> Good morning. Welcome back to theCUBE's coverage at Supercomputing Conference 2022, live here in Dallas. I'm Dave Nicholson with my co-host Paul Gillin. So far so good, Paul? It's been a fascinating morning Three days in, and a fascinating guest, Ian from AWS. Welcome. >> Thanks, Dave. >> What are we going to talk about? Batch computing, HPC. >> We've got a lot, let's get started. Let's dive right in. >> Yeah, we've got a lot to talk about. I mean, first thing is we recently announced our batch support for EKS. EKS is our Kubernetes, managed Kubernetes offering at AWS. And so batch computing is still a large portion of HPC workloads. While the interactive component is growing, the vast majority of systems are just kind of fire and forget, and we want to run thousands and thousands of nodes in parallel. We want to scale out those workloads. And what's unique about our AWS batch offering, is that we can dynamically scale, based upon the queue depth. And so customers can go from seemingly nothing up to thousands of nodes, and while they're executing their work they're only paying for the instances while they're working. And then as the queue depth starts to drop and the number of jobs waiting in the queue starts to drop, then we start to dynamically scale down those resources. And so it's extremely powerful. We see lots of distributed machine learning, autonomous vehicle simulation, and traditional HPC workloads taking advantage of AWS Batch. >> So when you have a Kubernetes cluster does it have to be located in the same region as the HPC cluster that's going to be doing the batch processing, or does the nature of batch processing mean, in theory, you can move something from here to somewhere relatively far away to do the batch processing? How does that work? 'Cause look, we're walking around here and people are talking about lengths of cables in order to improve performance. So what does that look like when you peel back the cover and you look at it physically, not just logically, AWS is everywhere, but physically, what does that look like? >> Oh, physically, for us, it depends on what the customer's looking for. We have workflows that are all entirely within a single region. And so where they could have a portion of say the traditional HPC workflow, is within that region as well as the batch, and they're saving off the results, say to a shared storage file system like our Amazon FSx for Lustre, or maybe aging that back to an S3 object storage for a little lower cost storage solution. Or you can have customers that have a kind of a multi-region orchestration layer to where they say, "You know what? "I've got a portion of my workflow that occurs "over on the other side of the country "and I replicate my data between the East Coast "and the West Coast just based upon business needs. "And I want to have that available to customers over there. "And so I'll do a portion of it in the East Coast "a portion of it in the West Coast." Or you can think of that even globally. It really depends upon the customer's architecture. >> So is the intersection of Kubernetes with HPC, is this relatively new? I know you're saying you're, you're announcing it. >> It really is. I think we've seen a growing perspective. I mean, Kubernetes has been a long time kind of eating everything, right, in the enterprise space? And now a lot of CIOs in the industrial space are saying, "Why am I using one orchestration layer "to manage my HPC infrastructure and another one "to manage my enterprise infrastructure?" And so there's a growing appreciation that, you know what, why don't we just consolidate on one? And so that's where we've seen a growth of Kubernetes infrastructure and our own managed Kubernetes EKS on AWS. >> Last month you announced a general availability of Trainium, of a chip that's optimized for AI training. Talk about what's special about that chip or what is is customized to the training workloads. >> Yeah, what's unique about the Trainium, is you'll you'll see 40% price performance over any other GPU available in the AWS cloud. And so we've really geared it to be that most price performance of options for our customers. And that's what we like about the silicon team, that we're part of that Annaperna acquisition, is because it really has enabled us to have this differentiation and to not just be innovating at the software level but the entire stack. That Annaperna Labs team develops our network cards, they develop our ARM cards, they developed this Trainium chip. And so that silicon innovation has become a core part of our differentiator from other vendors. And what Trainium allows you to do is perform similar workloads, just at a lower price performance. >> And you also have a chip several years older, called Inferentia- >> Um-hmm. >> Which is for inferencing. What is the difference between, I mean, when would a customer use one versus the other? How would you move the workload? >> What we've seen is customers traditionally have looked for a certain class of machine, more of a compute type that is not as accelerated or as heavy as you would need for Trainium for their inference portion of their workload. So when they do that training they want the really beefy machines that can grind through a lot of data. But when you're doing the inference, it's a little lighter weight. And so it's a different class of machine. And so that's why we've got those two different product lines with the Inferentia being there to support those inference portions of their workflow and the Trainium to be that kind of heavy duty training work. >> And then you advise them on how to migrate their workloads from one to the other? And once the model is trained would they switch to an Inferentia-based instance? >> Definitely, definitely. We help them work through what does that design of that workflow look like? And some customers are very comfortable doing self-service and just kind of building it on their own. Other customers look for a more professional services engagement to say like, "Hey, can you come in and help me work "through how I might modify my workflow to "take full advantage of these resources?" >> The HPC world has been somewhat slower than commercial computing to migrate to the cloud because- >> You're very polite. (panelists all laughing) >> Latency issues, they want to control the workload, they want to, I mean there are even issues with moving large amounts of data back and forth. What do you say to them? I mean what's the argument for ditching the on-prem supercomputer and going all-in on AWS? >> Well, I mean, to be fair, I started at AWS five years ago. And I can tell you when I showed up at Supercomputing, even though I'd been part of this community for many years, they said, "What is AWS doing at Supercomputing?" I know you care, wait, it's Amazon Web Services. You care about the web, can you actually handle supercomputing workloads? Now the thing that very few people appreciated is that yes, we could. Even at that time in 2017, we had customers that were performing HPC workloads. Now that being said, there were some real limitations on what we could perform. And over those past five years, as we've grown as a company, we've started to really eliminate those frictions for customers to migrate their HPC workloads to the AWS cloud. When I started in 2017, we didn't have our elastic fabric adapter, our low-latency interconnect. So customers were stuck with standard TCP/IP. So for their highly demanding open MPI workloads, we just didn't have the latencies to support them. So the jobs didn't run as efficiently as they could. We didn't have Amazon FSx for Lustre, our managed lustre offering for high performant, POSIX-compliant file system, which is kind of the key to a large portion of HPC workloads is you have to have a high-performance file system. We didn't even, I mean, we had about 25 gigs of networking when I started. Now you look at, with our accelerated instances, we've got 400 gigs of networking. So we've really continued to grow across that spectrum and to eliminate a lot of those really, frictions to adoption. I mean, one of the key ones, we had a open source toolkit that was jointly developed by Intel and AWS called CFN Cluster that customers were using to even instantiate their clusters. So, and now we've migrated that all the way to a fully functional supported service at AWS called AWS Parallel Cluster. And so you've seen over those past five years we have had to develop, we've had to grow, we've had to earn the trust of these customers and say come run your workloads on us and we will demonstrate that we can meet your demanding requirements. And at the same time, there's been, I'd say, more of a cultural acceptance. People have gone away from the, again, five years ago, to what are you doing walking around the show, to say, "Okay, I'm not sure I get it. "I need to look at it. "I, okay, I, now, oh, it needs to be a part "of my architecture but the standard questions, "is it secure? "Is it price performant? "How does it compare to my on-prem?" And really culturally, a lot of it is, just getting IT administrators used to, we're not eliminating a whole field, right? We're just upskilling the people that used to rack and stack actual hardware, to now you're learning AWS services and how to operate within that environment. And it's still key to have those people that are really supporting these infrastructures. And so I'd say it's a little bit of a combination of cultural shift over the past five years, to see that cloud is a super important part of HPC workloads, and part of it's been us meeting the the market segment of where we needed to with innovating both at the hardware level and at the software level, which we're going to continue to do. >> You do have an on-prem story though. I mean, you have outposts. We don't hear a lot of talk about outposts lately, but these innovations, like Inferentia, like Trainium, like the networking innovation you're talking about, are these going to make their way into outposts as well? Will that essentially become this supercomputing solution for customers who want to stay on-prem? >> Well, we'll see what the future lies, but we believe that we've got the, as you noted, we've got the hardware, we've got the network, we've got the storage. All those put together gives you a a high-performance computer, right? And whether you want it to be redundant in your local data center or you want it to be accessible via APIs from the AWS cloud, we want to provide that service to you. >> So to be clear, that's not that's not available now, but that is something that could be made available? >> Outposts are available right now, that have this the services that you need. >> All these capabilities? >> Often a move to cloud, an impetus behind it comes from the highest levels in an organization. They're looking at the difference between OpEx versus CapEx. CapEx for a large HPC environment, can be very, very, very high. Are these HPC clusters consumed as an operational expense? Are you essentially renting time, and then a fundamental question, are these multi-tenant environments? Or when you're referring to batches being run in HPC, are these dedicated HPC environments for customers who are running batches against them? When you think about batches, you think of, there are times when batches are being run and there are times when they're not being run. So that would sort of conjure, in the imagination, multi-tenancy, what does that look like? >> Definitely, and that's been, let me start with your second part first is- >> Yeah. That's been a a core area within AWS is we do not see as, okay we're going to, we're going to carve out this super computer and then we're going to allocate that to you. We are going to dynamically allocate multi-tenant resources to you to perform the workloads you need. And especially with the batch environment, we're going to spin up containers on those, and then as the workloads complete we're going to turn those resources over to where they can be utilized by other customers. And so that's where the batch computing component really is powerful, because as you say, you're releasing resources from workloads that you're done with. I can use those for another portion of the workflow for other work. >> Okay, so it makes a huge difference, yeah. >> You mentioned, that five years ago, people couldn't quite believe that AWS was at this conference. Now you've got a booth right out in the center of the action. What kind of questions are you getting? What are people telling you? >> Well, I love being on the show floor. This is like my favorite part is talking to customers and hearing one, what do they love, what do they want more of? Two, what do they wish we were doing that we're not currently doing? And three, what are the friction points that are still exist that, like, how can I make their lives easier? And what we're hearing is, "Can you help me migrate my workloads to the cloud? "Can you give me the information that I need, "both from a price for performance, "for an operational support model, "and really help me be an internal advocate "within my environment to explain "how my resources can be operated proficiently "within the AWS cloud." And a lot of times it's, let's just take your application a subset of your applications and let's benchmark 'em. And really that, AWS, one of the key things is we are a data-driven environment. And so when you take that data and you can help a customer say like, "Let's just not look at hypothetical, "at synthetic benchmarks, let's take "actually the LS-DYNA code that you're running, perhaps. "Let's take the OpenFOAM code that you're running, "that you're running currently "in your on-premises workloads, "and let's run it on AWS cloud "and let's see how it performs." And then we can take that back to your to the decision makers and say, okay, here's the price for performance on AWS, here's what we're currently doing on-premises, how do we think about that? And then that also ties into your earlier question about CapEx versus OpEx. We have models where actual, you can capitalize a longer-term purchase at AWS. So it doesn't have to be, I mean, depending upon the accounting models you want to use, we do have a majority of customers that will stay with that OpEx model, and they like that flexibility of saying, "Okay, spend as you go." We need to have true ups, and make sure that they have insight into what they're doing. I think one of the boogeyman is that, oh, I'm going to spend all my money and I'm not going to know what's available. And so we want to provide the, the cost visibility, the cost controls, to where you feel like, as an HPC administrator you have insight into what your customers are doing and that you have control over that. And so once you kind of take away some of those fears and and give them the information that they need, what you start to see too is, you know what, we really didn't have a lot of those cost visibility and controls with our on-premises hardware. And we've had some customers tell us we had one portion of the workload where this work center was spending thousands of dollars a day. And we went back to them and said, "Hey, we started to show this, "what you were spending on-premises." They went, "Oh, I didn't realize that." And so I think that's part of a cultural thing that, at an HPC, the question was, well on-premises is free. How do you compete with free? And so we need to really change that culturally, to where people see there is no free lunch. You're paying for the resources whether it's on-premises or in the cloud. >> Data scientists don't worry about budgets. >> Wait, on-premises is free? Paul mentioned something that reminded me, you said you were here in 2017, people said AWS, web, what are you even doing here? Now in 2022, you're talking in terms of migrating to cloud. Paul mentioned outposts, let's say that a customer says, "Hey, I'd like you to put "in a thousand-node cluster in this data center "that I happen to own, but from my perspective, "I want to interact with it just like it's "in your data center." In other words, the location doesn't matter. My experience is identical to interacting with AWS in an AWS data center, in a CoLo that works with AWS, but instead it's my physical data center. When we're tracking the percentage of IT that's that is on-prem versus off-prem. What is that? Is that, what I just described, is that cloud? And in five years are you no longer going to be talking about migrating to cloud because people go, "What do you mean migrating to cloud? "What do you even talking about? "What difference does it make?" It's either something that AWS is offering or it's something that someone else is offering. Do you think we'll be at that point in five years, where in this world of virtualization and abstraction, you talked about Kubernetes, we should be there already, thinking in terms of it doesn't matter as long as it meets latency and sovereignty requirements. So that, your prediction, we're all about insights and supercomputing- >> My prediction- >> In five years, will you still be talking about migrating to cloud or will that be something from the past? >> In five years, I still think there will be a component. I think the majority of the assumption will be that things are cloud-native and you start in the cloud and that there are perhaps, an aspect of that, that will be interacting with some sort of an edge device or some sort of an on-premises device. And we hear more and more customers that are saying, "Okay, I can see the future, "I can see that I'm shrinking my footprint." And, you can see them still saying, "I'm not sure how small that beachhead will be, "but right now I want to at least say "that I'm going to operate in that hybrid environment." And so I'd say, again, the pace of this community, I'd say five years we're still going to be talking about migrations, but I'd say the vast majority will be a cloud-native, cloud-first environment. And how do you classify that? That outpost sitting in someone's data center? I'd say we'd still, at least I'll leave that up to the analysts, but I think it would probably come down as cloud spend. >> Great place to end. Ian, you and I now officially have a bet. In five years we're going to come back. My contention is, no we're not going to be talking about it anymore. >> Okay. >> And kids in college are going to be like, "What do you mean cloud, it's all IT, it's all IT." And they won't remember this whole phase of moving to cloud and back and forth. With that, join us in five years to see the result of this mega-bet between Ian and Dave. I'm Dave Nicholson with theCUBE, here at Supercomputing Conference 2022, day three of our coverage with my co-host Paul Gillin. Thanks again for joining us. Stay tuned, after this short break, we'll be back with more action. (lively music)

(uplifting music) >> Hello and welcome to The Cube, here in Palo Alto, California for a special program on cloud-native at scale, enabling next generation cloud or SuperCloud for modern application cloud-native developers. I'm John Furrier, host of The Cube. My pleasure to have here Madhura Maskasky, co-founder and VP of Product at Platform9. Thanks for coming in today for this cloud-native at scale conversation. >> Thank you for having me. >> So, cloud-native at scale, something that we're talking about because we're seeing the next level of mainstream success of containers, Kubernetes and cloud-native developers, basically DevOps in the CICD pipeline. It's changing the landscape of infrastructure as code, it's accelerating the value proposition and the SuperCloud as we call it, has been getting a lot of traction because this next generation cloud is looking a lot different, but kind of the same as the first generation. What's your view on SuperCloud as it fits to cloud-native as scales up? >> Yeah, you know, I think what's interesting, and I think the reason why SuperCloud is a really good and a really fit term for this, and I think, I know my CEO was chatting with you as well, and he was mentioning this as well, but I think there needs to be a different term than just multi-cloud or cloud. And the reason is because as cloud-native and cloud deployments have scaled, I think we've reached a point now where, instead of having the traditional data center style model where you have a few large distributors of infrastructure and workload at a few locations, I think the model is kind of flipped around, right, where you have a large number of micro sites. These micro sites could be your public cloud deployment, your private, on-prem infrastructure deployments, or it could be your edge environment, right? And every single enterprise, every single industry is moving that direction. And so you got to refer that with a terminology that indicates the scale and complexity of it. And so I think SuperCloud is an appropriate term for that. >> So, you brought a couple things I want to dig into. You mentioned edge nodes. We're seeing not only edge nodes being the next kind of area of innovation, mainly because it's just popping up everywhere. And that's just the beginning. What even know what's around the corner. You got buildings, you got IOT, OT and IT kind of coming together, but you also got this idea of regions, global infrastructure is a big part of it. I just saw some news around CloudFlare shutting down a site here. There's policies being made at scale. These new challenges there. Can you share, because you got to have edge. So, hybrid cloud is a winning formula. Everybody knows that it's a steady state. >> Madhura: Yeah. >> But across multiple clouds brings in this new un-engineered area, yet it hasn't been done yet. Spanning clouds. People say they're doing it, but you start to see the toe in the water, it's happening, it's going to happen. It's only going to get accelerated with the edge and beyond globally. So I have to ask you, what is the technical challenges in doing this? Because it's something business consequences as well, but there are technical challenges. Can you share your view on what the technical challenges are for the SuperCloud or across multiple edges and regions? >> Yeah, absolutely. So, I think, you know, in the context of this, this term of SuperCloud, I think, it's sometimes easier to visualize things in terms of two axes, right? I think on one end you can think of the scale in terms of just pure number of nodes that you have, deploy number of clusters in the Kubernetes space. And then, on the other access you would have your distribution factor, right? Which is, do you have these tens of thousands of nodes in one site or do you have them distributed across tens of thousands of sites with one node at each site? Right? And if you have just one flavor of this, there is enough complexity but potentially manageable. But when you are expanding on both these axes you really get to a point where that scale really needs some well thought out, well structured solutions to address it. Right? A combination of homegrown tooling along with your, you know, favorite distribution of Kubernetes is not a strategy that can help you in this environment. It may help you when you have one of this or when your scale is not at the level. >> Can you scope the complexity? Because I mean, I hear a lot of moving parts going on there, the technology's also getting better. We're seeing cloud-native becomes successful. There's a lot to configure, there's a lot to install. Can you scope the scale of the problem? Because about at scale, >> Madhura: Yeah. >> Challenges here. >> Yeah. Absolutely. And I think, you know, I like to call it, you know, the problem that the scale creates, you know, there's various problems, but I think one problem, one way to think about it is you know, it works on my cluster problem, right? So, you know, I come from engineering background and there's a, you know, there's a famous saying between engineers and QA and the support folks, right. Which is, it works on my laptop, which is I tested this change, everything was fantastic, it worked flawlessly on my machine, on production, it's not working. And the exact same problem now happens in these distributed environments, but at massive scale, right. Which is that, you know, developers test their applications, et cetera within the sanctity of their sandbox environments. But once you expose that change in the wild world of your production deployment, right. And the production deployment could be going at the radio cell tower at the edge location where a cluster is running there, or it could be sending, you know, these applications and having them run at my customer site where they might not have configured that cluster exactly the same way as I configured it, or they configured the cluster right. But maybe they didn't deploy the security policies or they didn't deploy the other infrastructure plugins that my app relies on. All of these various factors add their own layer of complexity. And there really isn't a simple way to solve that today. And that is just, you know, one example of an issue that happens. I think another, you know, whole new ballgame of issues come in the context of security, right? Because when you are deploying applications at scale in a distributed manner, you got to make sure someone's job is on the line to ensure that the right security policies are enforced regardless of that scale factor. So, I think that's another example of problems that occur. >> Okay. So, I have to ask about scale because there are a lot of multiple steps involved when you see the success of cloud native. You know, you see some, you know, some experimentation. They set up a cluster, say, it's containers and Kubernetes, and then you say, okay, we got this, we configure it. And then, they do it again and again, they call it day two. Some people call it day one, day two operation, whatever you call it. Once you get past the first initial thing, then you got to scale it. Then you're seeing security breaches, you're seeing configuration errors. This seems to be where the hotspot is. And when companies transition from, I got this to, oh no, it's harder than I thought at scale. Can you share your reaction to that and how you see this playing out? >> Yeah, so, you know, I think it's interesting. There's multiple problems that occur when, you know, the two factors of scale, as we talked about start expanding. I think, one of them is what I like to call the, you know, it works fine on my cluster problem, which is back in, when I was a developer, we used to call this, it works on my laptop problem, which is, you know, you have your perfectly written code that is operating just fine on your machine, your sandbox environment. But the moment it runs production, it comes back with P zeros and P ones from support teams, et cetera. And those issues can be really difficult to triage. Right. And so, in the Kubernetes environment, this problem kind of multi-folds, it goes, you know, escalates to a higher degree because you have your sandbox developer environments, they have their clusters and things work perfectly fine in those clusters because these clusters are typically handcrafted or a combination of some scripting and handcrafting. And so, as you give that change to then run at your production edge location, like say your radio cell tower site or you hand it over to a customer to run it on their cluster, they might not have configured that cluster exactly how you did, or they might not have configured some of the infrastructure plugins. And so the things don't work. And when things don't work, triaging them becomes like (indistinct) hard, right? It's just one of the examples of the problem. Another whole bucket of issues is security, which is you have these distributed clusters at scale, you got to ensure someone's job is on the line to make sure that the security policies are configured properly. >> So, this is a huge problem. I love that comment. That's not happening on my system. It's the classic, you know, debugging mentality. >> Madhura: Yeah. >> But at scale it's hard to do that with error prone. I can see that being a problem. And you guys have a solution you're launching. Can you share what Arlon is this new product? What is it all about? Talk about this new introduction. >> Yeah, absolutely. I'm very, very excited. You know, it's one of the projects that we've been working on for some time now because we are very passionate about this problem and just solving problems at scale in on-prem or at in the cloud or at edge environments. And what Arlon is, it's an open source project and it is a tool, it's a Kubernetes native tool for a complete end-to-end management of not just your clusters, but your clusters, all of the infrastructure that goes within and along the sites of those clusters, security policies, your middleware plugins, and finally your applications. So, what Arlon lets you do in a nutshell is in a declarative way, it lets you handle the configuration and management of all of these components in at scale. >> So, what's the elevator pitch simply put for what dissolves in terms of the chaos you guys are reigning in, what's the bumper sticker? >> Yeah. >> What would it do? >> There's a perfect analogy that I love to reference in this context, which is think of your assembly line, you know, in a traditional, let's say, you know, an auto manufacturing factory or et cetera, and the level of efficiency at scale that assembly line brings, right? Arlon, and if you look at the logo we've designed, it's this funny little robot, and it's because when we think of Arlon, we think of these enterprise large scale environments, you know, sprawling at scale creating chaos because there isn't necessarily a well thought through, well-structured solution that's similar to an assembly line, which is taking each component, you know, addressing them, manufacturing, processing them in a standardized way, then handing to the next stage where again, it gets, you know, processed in a standardized way. And that's what Arlon really does. That's like deliver the pitch. If you have problems of scale of managing your infrastructure, you know, that is distributed. Arlon brings the assembly line level of efficiency and consistency for those. >> So keeping it smooth, the assembly line, things are flowing, CICD, pipelining. >> Madhura: Exactly. >> So, that's what you're trying to simplify that OPS piece for the developer. I mean, it's not really OPS, it's their OPS, it's coding. >> Yeah. Not just developer, the OPS, the operations folks as well, right? Because developers, you know, there is, developers are responsible for one picture of that layer, which is my apps, and then maybe that middle layer of applications that they interface with, but then they hand it over to someone else who's then responsible to ensure that these apps are secured properly, that they are logging, logs are being collected properly, monitoring and observability is integrated. And so, it solves problems for both those teams. >> Yeah, it's DevOps. So, the DevOps is the cloud-needed developer. The option teams have to kind of set policies. Is that where the declarative piece comes in? Is that why that's important? >> Absolutely. Yeah. And, you know, Kubernetes really introduced or elevated this declarative management, right? Because you know, Kubernetes clusters are, or your, yeah, you know, specifications of components that go in Kubernetes are defined in declarative way, and Kubernetes always keeps that state consistent with your defined state. But when you go outside of that world of a single cluster, and when you actually talk about defining the clusters or defining everything that's around it, there really isn't a solution that does that today. And so Arlon addresses that problem at the heart of it, and it does that using existing open source, well-known solutions. >> And, I want get into the benefits, what's in it for me as the customer, developer, but I want to finish this out real quick and get your thoughts. You mentioned open source. Why open source? What's the current state of the product? You run the product group over there, Platform9, is it open source? And you guys have a product that's commercial. Can you explain the open-source dynamic? And first of all, why open source? >> Madhura: Yeah. >> And what is the consumption? I mean, open source is great, people want open source, they can download it, look up the code, but you know, maybe want to buy the commercial. So, I'm assuming you have that thought through, can you share? >> Madhura: Yeah. >> Open source and commercial relationship. >> Yeah. I think, you know, starting with why open source, I think, it's, you know, we as a company, we have, you know, one of the things that's absolutely critical to us is that we take mainstream open-source technologies components, and then we, you know, make them available to our customers at scale through either a SaaS model or on-prem model, right? But, so as we are a company or startup or a company that benefits, you know, in a massive way by this open-source economy, it's only right, I think in my mind that, we do our part of the duty, right? And contribute back to the community that feeds us. And so, you know, we have always held that strongly as one of our principles. And we have, you know, created and built independent products starting all the way with Fission, which was a serverless product, you know, that we had built to various other, you know, examples that I can give. But that's one of the main reasons why open source and also open source because we want the community to really firsthand engage with us on this problem, which is very difficult to achieve if your product is behind a wall, you know, behind a block box. >> Well, and that's what the developers want too. I mean, what we're seeing in reporting with SuperCloud is the new model of consumption is I want to look at the code and see what's in there. >> Madhura: That's right. >> And then also, if I want to use it, I'll do it. Great. That's open source, that's the value. But then at the end of the day, if I want to move fast, that's when people buy in. So it's a new kind of freemium, I guess, business model. I guess that's the way is, well, but that's the benefit of open source. This is why standards and open source growing so fast, you have that confluence of, you know, a way for us to try before they buy, but also actually kind of date the application, if you will. We, you know, Adrian (indistinct) uses the dating metaphor, you know, hey, you know, I want to check it out first before I get married. >> Madhura: Right. >> And that's what open source. So, this is the new, this is how people are selling. This is not just open source, this is how companies are selling. >> Absolutely. Yeah. Yeah. You know, I think in, you know, two things, I think one is just, you know, this cloud-native space is so vast that if you're building a close flow solution, sometimes there's also a risk that it may not apply to every single enterprise's use cases. And so having it open source gives them an opportunity to extend it, expand it, to make it proper to their use case if they choose to do so. Right? But at the same time, what's also critical to us is we are able to provide a supported version of it with an SLA that we, you know, that's backed by us, a Saas-hosted version of it as well, for those customers who choose to go that route, you know, once they have used the open-source version and loved it and want to take it at scale and in production and need a partner to collaborate with, who can, you know, support them for that production environment. >> I have to ask you. Now, let's get into what's in it for the customer. I'm a customer, why should I be enthused about Arlon? What's in it for me? You know. 'Cause if I'm not enthused about it, I'm not going to be confident and it's going to be hard for me to get behind this. Can you share your enthusiastic view of, you know, why I should be enthused about Arlon? I'm a customer. >> Yeah, absolutely. And so, and there's multiple, you know, enterprises that we talk to, many of them, you know, our customers, where this is a very kind of typical story that you hear, which is we have, you know, a Kubernetes distribution. It could be on premise, it could be public cloud-native Kubernetes, and then, we have our CICD pipelines that are automating the deployment of applications, et cetera. And then, there's this gray zone. And the gray zone is well before you can, your CICD pipelines can deploy the apps, somebody needs to do all of that groundwork of, you know, defining those clusters and yeah, you know, properly configuring them. And as these things start by being done hand grown. And then, as you scale, what typically enterprises would do today is they will have their homegrown DIY solutions for this. I mean, a number of folks that I talk to that have built Terraform automation, and then, you know, some of those key developers leave. So, it's a typical open source or typical, you know, DIY challenge. And the reason that they're writing it themselves is not because they want to. I mean, of course, technology is always interesting to everybody, but it's because they can't find a solution that's out there that perfectly fits the problem. And so that's that pitch. I think, (indistinct) would be delighted. The folks that we've talk, you know, spoken with, have been absolutely excited and have, you know, shared that this is a major challenge we have today because we have, you know, few hundreds of clusters on EKS Amazon, and we want to scale them to few thousands, but we don't think we are ready to do that. And this will give us the ability to, >> Yeah, I think, people are scared. I won't say scare, that's a bad word. Maybe I should say that they feel nervous because, you know, at scale, small mistakes can become large mistakes. This is something that is concerning to enterprises. And I think, this is going to come up at (indistinct) this year where enterprises are going to say, okay, I need to see SLAs. I want to see track record, I want to see other companies that have used it. >> Madhura: Yeah. >> How would you answer that question to, or challenge, you know, hey, I love this, but is there any guarantees? Is there any, what's the SLA, I'm an enterprise, I got tight, you know, I love the open source trying to free fast and loose, but I need hardened code. >> Yeah, absolutely. So, two parts to that, right? One is Arlon leverages existing open-source components, products that are extremely popular. Two specifically. One is Arlon uses ArgoCD, which is probably one of the highest rated and used CD open-source tools that's out there, right? It's created by folks that are as part of into team now, you know, really brilliant team. And it's used at scale across enterprises. That's one. Second is Arlon also makes use of cluster API (indistinct), which is a Kubernetes' sub-component, right? For life cycle management of clusters. So, there is enough of, you know, community users, et cetera, around these two products, right? Or open-source projects that will find Arlon to be right up in their alley because they're already comfortable, familiar with ArgoCD. Now, Arlon just extends the scope of what ArgoCD can do. And so, that's one. And then, the second part is going back to your point of the comfort. And that's where, you know, Platform9 has a role to play, which is when you are ready to deploy Arlon at scale, because you've been, you know, playing with it in your (indistinct) test environments, you're happy with what you get with it, then Platform9 will stand behind it and provide that SLA. >> And what's been the reaction from customers you've talked to Platform9 customers with, that are familiar with Argo and then Arlon? What's been some of the feedback? >> Yeah, I think, the feedback's been fantastic. I mean, I can give examples of customers where, you know, initially, you know, when you are telling them about your entire portfolio of solutions, it might not strike a card right away. But then we start talking about Arlon, and we talk about the fact that it uses ArgoCD they start opening up, they say, we have standardized on Argo and we have built these components, homegrown, we would be very interested. Can we co-develop? Does it support these use cases? So, we've had that kind of validation. We've had validation all the way at the beginning of Arlon before we even wrote a single line of code saying, this is something we plan on doing. And the customer said, if you had it today, I would've purchased it. So, it's been really great validation. >> All right. So, next question is, what is the solution to the customer? If I asked you, look at, I have, I'm so busy, my team's overworked. I got a skills gap, I don't need another project that's so I'm so tied up right now, and I'm just chasing my tail. How does Platform9 help me? >> Yeah, absolutely. So I think, you know, one of the core tenants of Platform9 has always been that, we try to bring that public cloud like simplicity by hosting, you know, this in a lot of such similar tools in a SaaS-hosted manner for our customers, right? So, our goal behind doing that is taking away or trying to take away all of that complexity from customer's hands and offloading it to our hands, right? And giving them that full white glove treatment as we call it. And so, from a customer's perspective, one, something like Arlon will integrate with what they have, so, they don't have to rip and replace anything. In fact, it will, even in the next versions, it may even discover your clusters that you have today, and, you know, give you an inventory. And then, >> So, customers have clusters that are growing, that's a sign, >> Correct. >> Call you guys. >> Absolutely. Either they have massive large clusters. Right. That they want to split into smaller clusters, but they're not comfortable doing that today, or they've done that already on say, public cloud or otherwise. And now, they have management challenges. >> So, especially, operationalizing the clusters, whether they want to kind of reset everything and remove things around and reconfigure >> Madhura: Yeah. >> And or scale out. >> That's right. Exactly. >> And you provide that layer of policy. >> Absolutely. Yes. >> That's the key value here. >> That's right. >> So, policy-based configuration for cluster scale up. >> Profile and policy-based, declarative configuration and life cycle management for clusters. >> If I asked you how this enables SuperCloud, what would you say to that? >> I think, this is one of the key ingredients to SuperCloud, right? If you think about a SuperCloud environment, there is at least few key ingredients that come to my mind that are really critical. Like they are, you know, life-saving ingredients at that scale. One is having a really good strategy for managing that scale. You know, in a, going back to assembly line in a very consistent, predictable way. So, that Arlon solves, then you need to compliment that with the right kind of observability and monitoring tools at scale, right? Because ultimately issues are going to happen and you're going to have to figure out, you know, how to solve them fast. And Arlon by the way, also helps in that direction, but you also need observability tools. And then, especially if you're running at on the public cloud, you need some cost management tools. In my mind, these three things are like the most necessary ingredients to make SuperCloud successful. And you know, Arlon flows in one, >> Okay, so now, the next level is, okay, that makes sense. It's under the covers kind of speak under the hood. >> Madhura: Yeah. >> How does that impact the app developers of the cloud-native modern application workflows? Because the impact to me seems the apps are going to be impacted. Are they going to be faster, stronger? I mean, what's the impact, if you do all those things as you mentioned, what's the impact of the apps? >> Yeah, the impact is that your apps are more likely to operate in production the way you expect them to, because the right checks and balances have gone through, and any discrepancies have been identified prior to those apps, prior to your customer running into them, right? Because developers run into this challenge today where there's a split responsibility, right? I'm responsible for my code, I'm responsible for some of these other plugins, but I don't own the stack end to end. I have to rely on my OPS counterpart to do their part, right? And so, this really gives them, you know, the right tooling for that. >> So, this is actually a great kind of relevant point, you know, as cloud becomes more scalable, you're starting to see this fragmentation gone of the days of the full-stack developer to the more specialized role. But this is a key point, and I have to ask you because if this Arlon solution takes place, as you say, and the apps are going to be (indistinct), they're designed to do, the question is, what does the current pain look like? Are the apps breaking? What is the signals to the customer, >> Madhura: Yeah. >> That they should be calling you guys up into implementing Arlon, Argo, and on all the other goodness to automate, what does some of the signals, is it downtime? Is it failed apps, is it latency? What are some of the things that, >> Madhura: Yeah, absolutely. >> Would be indications of things are F'ed up a little bit. >> Yeah. More frequent down times, down times that are, that take longer to triage. And so your, you know, your mean times on resolution, et cetera, are escalating or growing larger, right? Like we have environments of customers where they have a number of folks on in the field that have to take these apps and run them at customer sites. And that's one of our partners, and they're extremely interested in this because the rate of failures they're encountering for this, you know, the field when they're running these apps on site, because the field is automating their clusters that are running on sites using their own scripts. So, these are the kinds of challenges, and those are the pain points, which is, you know, if you're looking to reduce your mean time to resolution, if you're looking to reduce the number of failures that occur on your production site, that's one. And second, if you're looking to manage these at scale environments with a relatively small, focused, nimble OPS team, which has an immediate impact on your budget. So, those are the signals. >> This is the cloud-native at scale situation, the innovation going on. Final thought is your reaction to the idea that, if the world goes digital, which it is, and the confluence of physical and digital coming together, and cloud continues to do its thing, the company becomes the application, not where IT used to be supporting the business, you know, the back office and the (indistinct) terminals and some PCs and handhelds. Now, if technology's running, the business is the business. >> Yeah. >> Company is the application. >> Yeah. >> So, it can't be down. So, there's a lot of pressure on CSOs and CIOs now and boards is saying, how is technology driving the top-line revenue? That's the number one conversation. >> Yeah. >> Do you see the same thing? >> Yeah, it's interesting. I think there's multiple pressures at the CXO, CIO level, right? One is that there needs to be that visibility and clarity and guarantee almost that, you know, the technology that's, you know, that's going to drive your top line is going to drive that in a consistent, reliable, predictable manner. And then second, there is the constant pressure to do that while always lowering your costs of doing it, right? Especially, when you're talking about, let's say, retailers or those kinds of large-scale vendors, they many times make money by lowering the amount that they spend on, you know, providing those goods to their end customers. So, I think those, both those factors kind of come into play and the solution to all of them is usually in a very structured strategy around automation. >> Final question. What does cloud-native at scale look like to you? If all the things happen the way we want them to happen, the magic wand, the magic dust, what does it look like? >> What that looks like to me is a CIO sipping at his desk on coffee, production is running absolutely smooth. And he's running that at a nimble, nimble team size of at the most, a handful of folks that are just looking after things, but things are just taking care of themselves. >> John: And the CIO doesn't exist and there's no CISO, there at the beach. >> (laughs) Yeah. >> Thank you for coming on, sharing the cloud-native at scale here on The Cube. Thank you for your time. >> Fantastic. Thanks for having me. >> Okay. I'm John Furrier here, for special program presentation, special programming cloud-native at scale, enabling SuperCloud modern applications with Platform9. Thanks for watching. (gentle music)

>>Everyone, welcome to the cube here in Palo Alto, California for a special presentation on Cloud native at scale, enabling super cloud modern applications with Platform nine. I'm John Furry, your host of The Cube. We've got a great lineup of three interviews we're streaming today. Mattor Makki, who's the co-founder and VP of Product of Platform nine. She's gonna go into detail around Arlon, the open source products, and also the value of what this means for infrastructure as code and for cloud native at scale. Bickley the chief architect of Platform nine Cube alumni. Going back to the OpenStack days. He's gonna go into why Arlon, why this infrastructure as code implication, what it means for customers and the implications in the open source community and where that value is. Really great wide ranging conversation there. And of course, Vascar, Gort, the CEO of Platform nine, is gonna talk with me about his views on Super Cloud and why Platform nine has a scalable solutions to bring cloud native at scale. So enjoy the program, see you soon. Hello and welcome to the cube here in Palo Alto, California for a special program on cloud native at scale, enabling next generation cloud or super cloud for modern application cloud native developers. I'm John Forry, host of the Cube. Pleasure to have here me Makowski, co-founder and VP of product at Platform nine. Thanks for coming in today for this Cloudnative at scale conversation. >>Thank you for having >>Me. So Cloudnative at scale, something that we're talking about because we're seeing the, the next level of mainstream success of containers Kubernetes and cloud native develop, basically DevOps in the C I C D pipeline. It's changing the landscape of infrastructure as code, it's accelerating the value proposition and the super cloud as we call it, has been getting a lot of traction because this next generation cloud is looking a lot different, but kind of the same as the first generation. What's your view on Super cloud as it fits to cloud native as scales up? >>Yeah, you know, I think what's interesting, and I think the reason why Super Cloud is a really good and a really fit term for this, and I think, I know my CEO was chatting with you as well, and he was mentioning this as well, but I think there needs to be a different term than just multi-cloud or cloud. And the reason is because as cloud native and cloud deployments have scaled, I think we've reached a point now where instead of having the traditional data center style model, where you have a few large distributors of infrastructure and workload at a few locations, I think the model is kind of flipped around, right? Where you have a large number of micro sites. These micro sites could be your public cloud deployment, your private on-prem infrastructure deployments, or it could be your edge environment, right? And every single enterprise, every single industry is moving in that direction. And so you gotta rougher that with a terminology that, that, that indicates the scale and complexity of it. And so I think super cloud is a, is an appropriate term for >>That. So you brought a couple things I want to dig into. You mentioned Edge Notes. We're seeing not only edge nodes being the next kind of area of innovation, mainly because it's just popping up everywhere. And that's just the beginning. Wouldn't even know what's around the corner. You got buildings, you got iot, o ot, and it kind of coming together, but you also got this idea of regions, global infrastructures, big part of it. I just saw some news around cloud flare shutting down a site here, there's policies being made at scale. These new challenges there. Can you share because you can have edge. So hybrid cloud is a winning formula. Everybody knows that it's a steady state. Yeah. But across multiple clouds brings in this new un engineered area, yet it hasn't been done yet. Spanning clouds. People say they're doing it, but you start to see the toe in the water, it's happening, it's gonna happen. It's only gonna get accelerated with the edge and beyond globally. So I have to ask you, what is the technical challenges in doing this? Because it's something business consequences as well, but there are technical challenge. Can you share your view on what the technical challenges are for the super cloud across multiple edges and >>Regions? Yeah, absolutely. So I think, you know, in in the context of this, the, this, this term of super cloud, I think it's sometimes easier to visualize things in terms of two access, right? I think on one end you can think of the scale in terms of just pure number of nodes that you have, deploy number of clusters in the Kubernetes space. And then on the other access you would have your distribution factor, right? Which is, do you have these tens of thousands of nodes in one site or do you have them distributed across tens of thousands of sites with one node at each site? Right? And if you have just one flavor of this, there is enough complexity, but potentially manageable. But when you are expanding on both these access, you really get to a point where that skill really needs some well thought out, well-structured solutions to address it, right? A combination of homegrown tooling along with your, you know, favorite distribution of Kubernetes is not a strategy that can help you in this environment. It may help you when you have one of this or when you, when you scale, is not at the level. >>Can you scope the complexity? Because I mean, I hear a lot of moving parts going on there, the technology's also getting better. We we're seeing cloud native become successful. There's a lot to configure, there's a lot to install. Can you scope the scale of the problem? Because we're talking about at scale Yep. Challenges here. >>Yeah, absolutely. And I think, you know, I I like to call it, you know, the, the, the problem that the scale creates, you know, there's various problems, but I think one, one problem, one way to think about it is, is, you know, it works on my cluster problem, right? So, you know, I come from engineering background and there's a, you know, there's a famous saying between engineers and QA and the support folks, right? Which is, it works on my laptop, which is I tested this change, everything was fantastic, it worked flawlessly on my machine, on production, It's not working. The exact same problem now happens and these distributed environments, but at massive scale, right? Which is that, you know, developers test their applications, et cetera within the sanctity of their sandbox environments. But once you expose that change in the wild world of your production deployment, right? >>And the production deployment could be going at the radio cell tower at the edge location where a cluster is running there, or it could be sending, you know, these applications and having them run at my customer's site where they might not have configured that cluster exactly the same way as I configured it, or they configured the cluster, right? But maybe they didn't deploy the security policies or they didn't deploy the other infrastructure plugins that my app relies on all of these various factors at their own layer of complexity. And there really isn't a simple way to solve that today. And that is just, you know, one example of an issue that happens. I think another, you know, whole new ball game of issues come in the context of security, right? Because when you are deploying applications at scale in a distributed manner, you gotta make sure someone's job is on the line to ensure that the right security policies are enforced regardless of that scale factor. So I think that's another example of problems that occur. >>Okay. So I have to ask about scale because there are a lot of multiple steps involved when you see the success cloud native, you know, you see some, you know, some experimentation. They set up a cluster, say it's containers and Kubernetes, and then you say, Okay, we got this, we can configure it. And then they do it again and again, they call it day two. Some people call it day one, day two operation, whatever you call it. Once you get past the first initial thing, then you gotta scale it. Then you're seeing security breaches, you're seeing configuration errors. This seems to be where the hotpot is. And when companies transition from, I got this to, Oh no, it's harder than I thought at scale. Can you share your reaction to that and how you see this playing out? >>Yeah, so, you know, I think it's interesting. There's multiple problems that occur when, you know, the, the two factors of scale is we talked about start expanding. I think one of them is what I like to call the, you know, it, it works fine on my cluster problem, which is back in, when I was a developer, we used to call this, it works on my laptop problem, which is, you know, you have your perfectly written code that is operating just fine on your machine, your sandbox environment. But the moment it runs production, it comes back with p zeros and POS from support teams, et cetera. And those issues can be really difficult to try us, right? And so in the Kubernetes environment, this problem kind of multi folds, it goes, you know, escalates to a higher degree because yeah, you have your sandbox developer environments, they have their clusters and things work perfectly fine in those clusters because these clusters are typically handcrafted or a combination of some scripting and handcrafting. >>And so as you give that change to then run at your production edge location, like say you radio sell tower site, or you hand it over to a customer to run it on their cluster, they might not have not have configured that cluster exactly how you did it, or they might not have configured some of the infrastructure plugins. And so the things don't work. And when things don't work, triaging them becomes like ishly hard, right? It's just one of the examples of the problem. Another whole bucket of issues is security, which is, is you have these distributed clusters at scale, you gotta ensure someone's job is on the line to make sure that these security policies are configured properly. >>So this is a huge problem. I love that comment. That's not not happening on my system. It's the classic, you know, debugging mentality. Yeah. But at scale it's hard to do that with error prone. I can see that being a problem. And you guys have a solution you're launching, Can you share what our lawn is, this new product, What is it all about? Talk about this new introduction. >>Yeah, absolutely. I'm very, very excited. You know, it's one of the projects that we've been working on for some time now because we are very passionate about this problem and just solving problems at scale in on-prem or at in the cloud or at edge environments. And what arwan is, it's an open source project and it is a tool, it's a Kubernetes native tool for complete end to end management of not just your clusters, but your clusters. All of the infrastructure that goes within and along the sites of those clusters, security policies, your middleware plugins, and finally your applications. So what alarm lets you do in a nutshell is in a declarative way, it lets you handle the configuration and management of all of these components in at scale. >>So what's the elevator pitch simply put for what this solves in, in terms of the chaos you guys are reigning in. What's the, what's the bumper sticker? Yeah, >>What would it do? There's a perfect analogy that I love to reference in this context, which is think of your assembly line, you know, in a traditional, let's say, you know, an auto manufacturing factory or et cetera, and the level of efficiency at scale that that assembly line brings, right online. And if you look at the logo we've designed, it's this funny little robot. And it's because when we think of online, we, we think of these enterprise large scale environments, you know, sprawling at scale creating chaos because there isn't necessarily a well thought through, well structured solution that's similar to an assembly line, which is taking each components, you know, addressing them, manufacturing, processing them in a standardized way, then handing to the next stage. But again, it gets, you know, processed in a standardized way. And that's what Arlon really does. That's like the I pitch. If you have problems of scale of managing your infrastructure, you know, that is distributed. Arlon brings the assembly line level of efficiency and consistency >>For those. So keeping it smooth, the assembly on things are flowing. C C I CD pipelining. Exactly. So that's what you're trying to simplify that ops piece for the developer. I mean, it's not really ops, it's their ops, it's coding. >>Yeah. Not just developer, the ops, the operations folks as well, right? Because developers, you know, there is, the developers are responsible for one picture of that layer, which is my apps, and then maybe that middleware of application that they interface with, but then they hand it over to someone else who's then responsible to ensure that these apps are secure properly, that they are logging, logs are being collected properly, monitoring and observability integrated. And so it solves problems for both those >>Teams. Yeah. It's DevOps. So the DevOps is the cloud native developer. The OP teams have to kind of set policies. Is that where the declarative piece comes in? Is that why that's important? >>Absolutely. Yeah. And, and, and, and you know, Kubernetes really in introduced or elevated this declarative management, right? Because, you know, c communities clusters are Yeah. Or your, yeah, you know, specifications of components that go in Kubernetes are defined in a declarative way. And Kubernetes always keeps that state consistent with your defined state. But when you go outside of that world of a single cluster, and when you actually talk about defining the clusters or defining everything that's around it, there really isn't a solution that does that today. And so online addresses that problem at the heart of it, and it does that using existing open source well known solutions. >>Ed, do I wanna get into the benefits? What's in it for me as the customer developer? But I want to finish this out real quick and get your thoughts. You mentioned open source. Why open source? What's the, what's the current state of the product? You run the product group over at platform nine, is it open source? And you guys have a product that's commercial? Can you explain the open source dynamic? And first of all, why open source? Yeah. And what is the consumption? I mean, open source is great, People want open source, they can download it, look up the code, but maybe wanna buy the commercial. So I'm assuming you have that thought through, can you share open source and commercial relationship? >>Yeah, I think, you know, starting with why open source? I think it's, you know, we as a company, we have, you know, one of the things that's absolutely critical to us is that we take mainstream open source technologies components and then we, you know, make them available to our customers at scale through either a SaaS model on from model, right? But, so as we are a company or startup or a company that benefits, you know, in a massive way by this open source economy, it's only right, I think in my mind that we do our part of the duty, right? And contribute back to the community that feeds us. And so, you know, we have always held that strongly as one of our principles. And we have, you know, created and built independent products starting all the way with fi, which was a serverless product, you know, that we had built to various other, you know, examples that I can give. But that's one of the main reasons why opensource and also opensource because we want the community to really firsthand engage with us on this problem, which is very difficult to achieve if your product is behind a wall, you know, behind, behind a block box. >>Well, and that's, that's what the developers want too. I mean, what we're seeing in reporting with Super Cloud is the new model of consumption is I wanna look at the code and see what's in there. That's right. And then also, if I want to use it, I, I'll do it. Great. That's open source, that's the value. But then at the end of the day, if I wanna move fast, that's when people buy in. So it's a new kind of freemium, I guess, business model. I guess that's the way that, Well, but that's, that's the benefit. Open source. This is why standards and open source is growing so fast. You have that confluence of, you know, a way for helpers to try before they buy, but also actually kind of date the application, if you will. We, you know, Adrian Karo uses the dating me metaphor, you know, Hey, you know, I wanna check it out first before I get married. Right? And that's what open source, So this is the new, this is how people are selling. This is not just open source, this is how companies are selling. >>Absolutely. Yeah. Yeah. You know, I think, and you know, two things. I think one is just, you know, this, this, this cloud native space is so vast that if you, if you're building a close flow solution, sometimes there's also a risk that it may not apply to every single enterprises use cases. And so having it open source gives them an opportunity to extend it, expand it, to make it proper to their use case if they choose to do so, right? But at the same time, what's also critical to us is we are able to provide a supported version of it with an SLA that we, you know, that's backed by us, a SAS hosted version of it as well, for those customers who choose to go that route, you know, once they have used the open source version and loved it and want to take it at scale and in production and need, need, need a partner to collaborate with, who can, you know, support them for that production >>Environment. I have to ask you now, let's get into what's in it for the customer. I'm a customer, why should I be enthused about Arlo? What's in it for me? You know? Cause if I'm not enthused about it, I'm not gonna be confident and it's gonna be hard for me to get behind this. Can you share your enthusiastic view of, you know, why I should be enthused about Arlo customer? >>Yeah, absolutely. And so, and there's multiple, you know, enterprises that we talk to, many of them, you know, our customers, where this is a very kind of typical story that you hear, which is we have, you know, a Kubernetes distribution. It could be on premise, it could be public clouds, native es, and then we have our C I CD pipelines that are automating the deployment of applications, et cetera. And then there's this gray zone. And the gray zone is well before you can you, your CS CD pipelines can deploy the apps. Somebody needs to do all of their groundwork of, you know, defining those clusters and yeah. You know, properly configuring them. And as these things, these things start by being done hand grown. And then as the, as you scale, what typically enterprises would do today is they will have their home homegrown DIY solutions for this. >>I mean, the number of folks that I talk to that have built Terra from automation, and then, you know, some of those key developers leave. So it's a typical open source or typical, you know, DIY challenge. And the reason that they're writing it themselves is not because they want to. I mean, of course technology is always interesting to everybody, but it's because they can't find a solution that's out there that perfectly fits the problem. And so that's that pitch. I think Spico would be delighted. The folks that we've talked, you know, spoken with, have been absolutely excited and have, you know, shared that this is a major challenge we have today because we have, you know, few hundreds of clusters on s Amazon and we wanna scale them to few thousands, but we don't think we are ready to do that. And this will give us >>Stability. Yeah, I think people are scared, not sc I won't say scare, that's a bad word. Maybe I should say that they feel nervous because, you know, at scale small mistakes can become large mistakes. This is something that is concerning to enterprises. And, and I think this is gonna come up at co con this year where enterprises are gonna say, Okay, I need to see SLAs. I wanna see track record, I wanna see other companies that have used it. Yeah. How would you answer that question to, or, or challenge, you know, Hey, I love this, but is there any guarantees? Is there any, what's the SLAs? I'm an enterprise, I got tight, you know, I love the open source trying to free fast and loose, but I need hardened code. >>Yeah, absolutely. So, so two parts to that, right? One is Arlan leverages existing open source components, products that are extremely popular. Two specifically. One is Lon uses Argo cd, which is probably one of the highest rated and used CD open source tools that's out there, right? It's created by folks that are as part of Intuit team now, you know, really brilliant team. And it's used at scale across enterprises. That's one. Second is arlon also makes use of cluster api capi, which is a ES sub-component, right? For lifecycle management of clusters. So there is enough of, you know, community users, et cetera, around these two products, right? Or, or, or open source projects that will find Arlan to be right up in their alley because they're already comfortable, familiar with algo cd. Now Arlan just extends the scope of what Algo CD can do. And so that's one. And then the second part is going back to a point of the comfort. And that's where, you know, Platform nine has a role to play, which is when you are ready to deploy Alon at scale, because you've been, you know, playing with it in your DEF test environments, you're happy with what you get with it, then Platform nine will stand behind it and provide that sla. >>And what's been the reaction from customers you've talked to Platform nine customers with, with, that are familiar with, with Argo and then Arlo? What's been some of the feedback? >>Yeah, I, I, I think the feedback's been fantastic. I mean, I can give you examples of customers where, you know, initially, you know, when you are, when you're telling them about your entire portfolio of solutions, it might not strike a card right away. But then we start talking about Arlan and, and we talk about the fact that it uses Argo CD and they start opening up, they say, We have standardized on Argo and we have built these components, homegrown, we would be very interested. Can we co-develop? Does it support these use cases? So we've had that kind of validation. We've had validation all the way at the beginning of our line before we even wrote a single line of code saying this is something we plan on doing. And the customer said, If you had it today, I would've purchased it. So it's been really great validation. >>All right. So next question is, what is the solution to the customer? If I asked you, Look it, I have, I'm so busy, my team's overworked. I got a skills gap. I don't need another project that's, I'm so tied up right now and I'm just chasing my tail. How does Platform nine help me? >>Yeah, absolutely. So I think, you know, one of the core tenets of Platform nine has always been that we try to bring that public cloud like simplicity by hosting, you know, this in a lot of such similar tools in a SaaS hosted manner for our customers, right? So our goal behind doing that is taking away or trying to take away all of that complexity from customer's hands and offloading it to our hands, right? And giving them that full white glove treatment as we call it. And so from a customer's perspective, one, something like arlon will integrate with what they have so they don't have to rip and replace anything. In fact, it will, even in the next versions, it may even discover your clusters that you have today and, you know, give you an inventory and that, >>So customers have clusters that are growing, that's a sign correct call you guys. >>Absolutely. Either they're, they have massive large clusters, right? That they wanna split into smaller clusters, but they're not comfortable doing that today, or they've done that already on say, public cloud or otherwise. And now they have management challenges. So >>Especially operationalizing the clusters, whether they want to kind of reset everything and remove things around and reconfigure Yeah. And or scale out. >>That's right. Exactly. >>And you provide that layer of policy. >>Absolutely. >>Yes. That's the key value >>Here. That's right. >>So policy based configuration for cluster scale up >>Profile and policy based declarative configuration and life cycle management for clusters. >>If I asked you how this enables Super club, what would you say to that? >>I think this is one of the key ingredients to super cloud, right? If you think about a super cloud environment, there's at least few key ingredients that that come to my mind that are really critical. Like they are, you know, life saving ingredients at that scale. One is having a really good strategy for managing that scale, you know, in a, going back to assembly line in a very consistent, predictable way so that our lot solves then you, you need to compliment that with the right kind of observability and monitoring tools at scale, right? Because ultimately issues are gonna happen and you're gonna have to figure out, you know, how to solve them fast. And alon by the way, also helps in that direction, but you also need observability tools. And then especially if you're running it on the public cloud, you need some cost management tools. In my mind, these three things are like the most necessary ingredients to make Super Cloud successful. And, you know, alarm flows >>In one. Okay, so now the next level is, Okay, that makes sense. There's under the covers kind of speak under the hood. Yeah. How does that impact the app developers and the cloud native modern application workflows? Because the impact to me, seems the apps are gonna be impacted. Are they gonna be faster, stronger? I mean, what's the impact if you do all those things, as you mentioned, what's the impact of the apps? >>Yeah, the impact is that your apps are more likely to operate in production the way you expect them to, because the right checks and balances have gone through, and any discrepancies have been identified prior to those apps, prior to your customer running into them, right? Because developers run into this challenge to their, where there's a split responsibility, right? I'm responsible for my code, I'm responsible for some of these other plugins, but I don't own the stack end to end. I have to rely on my ops counterpart to do their part, right? And so this really gives them, you know, the right tooling for >>That. So this is actually a great kind of relevant point, you know, as cloud becomes more scalable, you're starting to see this fragmentation gone of the days of the full stack developer to the more specialized role. But this is a key point, and I have to ask you because if this Arlo solution takes place, as you say, and the apps are gonna be stupid, there's designed to do, the question is, what did, does the current pain look like of the apps breaking? What does the signals to the customer Yeah. That they should be calling you guys up into implementing Arlo, Argo, and, and, and on all the other goodness to automate, What are some of the signals? Is it downtime? Is it, is it failed apps, Is it latency? What are some of the things that Yeah, absolutely would be in indications of things are effed up a little bit. >>Yeah. More frequent down times, down times that are, that take longer to triage. And so you are, you know, the, you know, your mean times on resolution, et cetera, are escalating or growing larger, right? Like we have environments of customers where they, they have a number of folks on in the field that have to take these apps and run them at customer sites. And that's one of our partners. And they're extremely interested in this because the, the rate of failures they're encountering for this, you know, the field when they're running these apps on site, because the field is automating their clusters that are running on sites using their own script. So these are the kinds of challenges, and those are the pain points, which is, you know, if you're looking to reduce your, your meantime to resolution, if you're looking to reduce the number of failures that occur on your production site, that's one. And second, if you are looking to manage these at scale environments with a relatively small, focused, nimble ops team, which has an immediate impact on your, So those are, those are the >>Signals. This is the cloud native at scale situation, the innovation going on. Final thought is your reaction to the idea that if the world goes digital, which it is, and the confluence of physical and digital coming together, and cloud continues to do its thing, the company becomes the application, not where it used to be supporting the business, you know, the back office and the IIA terminals and some PCs and handhelds. Now if technology's running, the business is the business. Yeah. The company's the application. Yeah. So it can't be down. So there's a lot of pressure on, on CSOs and CIOs now and see, and boards is saying, how is technology driving the top line revenue? That's the number one conversation. Yeah. Do you see that same thing? >>Yeah. It's interesting. I think there's multiple pressures at the CXO CIO level, right? One is that there needs to be that visibility and clarity and guarantee almost that, you know, that the, the technology that's, you know, that's gonna drive your top line is gonna drive that in a consistent, reliable, predictable manner. And then second, there is the constant pressure to do that while always lowering your costs of doing it, right? Especially when you're talking about, let's say retailers or those kinds of large scale vendors, they many times make money by lowering the amount that they spend on, you know, providing those goods to their end customers. So I think those, both those factors kind of come into play and the solution to all of them is usually in a very structured strategy around automation. >>Final question. What does cloudnative at scale look like to you? If all the things happen the way we want 'em to happen, The magic wand, the magic dust, what does it look like? >>What that looks like to me is a CIO sipping at his desk on coffee production is running absolutely smooth. And his, he's running that at a nimble, nimble team size of at the most, a handful of folks that are just looking after things with things. So just >>Taking care of, and the CIO doesn't exist. There's no CSO there at the beach. >>Yeah. >>Thank you for coming on, sharing the cloud native at scale here on the cube. Thank you for your time. >>Fantastic. Thanks for having >>Me. Okay. I'm John Fur here for special program presentation, special programming cloud native at scale, enabling super cloud modern applications with Platform nine. Thanks for watching. Welcome back everyone to the special presentation of cloud native at scale, the cube and platform nine special presentation going in and digging into the next generation super cloud infrastructure as code and the future of application development. We're here at Bickley, who's the chief architect and co-founder of Platform nine b. Great to see you Cube alumni. We, we met at an OpenStack event in about eight years ago, or well later, earlier when opens Stack was going. Great to see you and great to see congratulations on the success of platform nine. >>Thank you very much. >>Yeah. You guys have been at this for a while and this is really the, the, the year we're seeing the, the crossover of Kubernetes because of what happens with containers. Everyone now was realized, and you've seen what Docker's doing with the new docker, the open source Docker now just a success Exactly. Of containerization, right? And now the Kubernetes layer that we've been working on for years is coming, bearing fruit. This is huge. >>Exactly. Yes. >>And so as infrastructure's code comes in, we talked to Bacar talking about Super Cloud, I met her about, you know, the new Arlon, our R lawn you guys just launched, the infrastructure's code is going to another level. And then it's always been DevOps infrastructure is code. That's been the ethos that's been like from day one, developers just code. Then you saw the rise of serverless and you see now multi-cloud or on the horizon, connect the dots for us. What is the state of infrastructures code today? >>So I think, I think I'm, I'm glad you mentioned it, everybody or most people know about infrastructures code. But with Kubernetes, I think that project has evolved at the concept even further. And these dates, it's infrastructure as configuration, right? So, which is an evolution of infrastructure as code. So instead of telling the system, here's how I want my infrastructure by telling it, you know, do step A, B, C, and D instead with Kubernetes, you can describe your desired state declaratively using things called manifest resources. And then the system kind of magically figures it out and tries to converge the state towards the one that you specify. So I think it's, it's a even better version of infrastructures code. >>Yeah, yeah. And, and that really means it's developer just accessing resources. Okay. Not declaring, Okay, give me some compute, stand me up some, turn the lights on, turn 'em off, turn 'em on. That's kind of where we see this going. And I like the configuration piece. Some people say composability, I mean now with open source, so popular, you don't have to have to write a lot of code. It's code being developed. And so it's into integration, it's configuration. These are areas that we're starting to see computer science principles around automation, machine learning, assisting open source. Cuz you got a lot of code that's right in hearing software, supply chain issues. So infrastructure as code has to factor in these new, new dynamics. Can you share your opinion on these new dynamics of, as open source grows, the glue layers, the configurations, the integration, what are the core issues? >>I think one of the major core issues is with all that power comes complexity, right? So, you know, despite its expressive power systems like Kubernetes and declarative APIs let you express a lot of complicated and complex stacks, right? But you're dealing with hundreds if not thousands of these yamo files or resources. And so I think, you know, the emergence of systems and layers to help you manage that complexity is becoming a key challenge and opportunity in, in this space that, >>That's, I wrote a LinkedIn post today was comments about, you know, hey, enterprise is the new breed, the trend of SaaS companies moving our consumer comp consumer-like thinking into the enterprise has been happening for a long time, but now more than ever, you're seeing it the old way used to be solve complexity with more complexity and then lock the customer in. Now with open source, it's speed, simplification and integration, right? These are the new dynamic power dynamics for developers. Yeah. So as companies are starting to now deploy and look at Kubernetes, what are the things that need to be in place? Because you have some, I won't say technical debt, but maybe some shortcuts, some scripts here that make it look like infrastructure is code. People have done some things to simulate or or make infrastructure as code happen. Yes. But to do it at scale Yes. Is harder. What's your take on this? What's your >>View? It's hard because there's a per proliferation of methods, tools, technologies. So for example, today it's very common for DevOps and platform engineering tools, I mean, sorry, teams to have to deploy a large number of Kubernetes clusters, but then apply the applications and configurations on top of those clusters. And they're using a wide range of tools to do this, right? For example, maybe Ansible or Terraform or bash scripts to bring up the infrastructure and then the clusters. And then they may use a different set of tools such as Argo CD or other tools to apply configurations and applications on top of the clusters. So you have this sprawl of tools. You, you also have this sprawl of configurations and files because the more objects you're dealing with, the more resources you have to manage. And there's a risk of drift that people call that where, you know, you think you have things under control, but some people from various teams will make changes here and there and then before the end of the day systems break and you have no idea of tracking them. So I think there's real need to kind of unify, simplify, and try to solve these problems using a smaller, more unified set of tools and methodologies. And that's something that we try to do with this new project. Arlon. >>Yeah. So, so we're gonna get into Arlan in a second. I wanna get into the why Arlon. You guys announced that at our GoCon, which was put on here in Silicon Valley at the, at the by intu. They had their own little day over there at their headquarters. But before we get there, Vascar, your CEO came on and he talked about Super Cloud at our inaugural event. What's your definition of super cloud? If you had to kind of explain that to someone at a cocktail party or someone in the industry technical, how would you look at the super cloud trend that's emerging? It's become a thing. What's your, what would be your contribution to that definition or the narrative? >>Well, it's, it's, it's funny because I've actually heard of the term for the first time today, speaking to you earlier today. But I think based on what you said, I I already get kind of some of the, the gist and the, the main concepts. It seems like super cloud, the way I interpret that is, you know, clouds and infrastructure, programmable infrastructure, all of those things are becoming commodity in a way. And everyone's got their own flavor, but there's a real opportunity for people to solve real business problems by perhaps trying to abstract away, you know, all of those various implementations and then building better abstractions that are perhaps business or application specific to help companies and businesses solve real business problems. >>Yeah, I remember that's a great, great definition. I remember, not to date myself, but back in the old days, you know, IBM had a proprietary network operating system, so to deck for the mini computer vendors, deck net and SNA respectively. But T C P I P came out of the osi, the open systems interconnect and remember, ethernet beat token ring out. So not to get all nerdy for all the young kids out there, look, just look up token ring, you'll see, you've probably never heard of it. It's IBM's, you know, connection for the internet at the, the layer too is Amazon, the ethernet, right? So if T C P I P could be the Kubernetes and the container abstraction that made the industry completely change at that point in history. So at every major inflection point where there's been serious industry change and wealth creation and business value, there's been an abstraction Yes. Somewhere. Yes. What's your reaction to that? >>I think this is, I think a saying that's been heard many times in this industry and, and I forgot who originated it, but I think the saying goes like, there's no problem that can't be solved with another layer of indirection, right? And we've seen this over and over and over again where Amazon and its peers have inserted this layer that has simplified, you know, computing and, and infrastructure management. And I believe this trend is going to continue, right? The next set of problems are going to be solved with these insertions of additional abstraction layers. I think that that's really a, yeah, it's gonna continue. >>It's interesting. I just really wrote another post today on LinkedIn called the Silicon Wars AMD Stock is down arm has been on rise, we've remember pointing for many years now, that arm's gonna be hugely, it has become true. If you look at the success of the infrastructure as a service layer across the clouds, Azure, aws, Amazon's clearly way ahead of everybody. The stuff that they're doing with the silicon and the physics and the, the atoms, the pro, you know, this is where the innovation, they're going so deep and so strong at ISAs, the more that they get that gets come on, they have more performance. So if you're an app developer, wouldn't you want the best performance and you'd wanna have the best abstraction layer that gives you the most ability to do infrastructures, code or infrastructure for configuration, for provisioning, for managing services. And you're seeing that today with service MeSHs, a lot of action going on in the service mesh area in, in this community of co con, which will be a covering. So that brings up the whole what's next? You guys just announced our lawn at ar GoCon, which came out of Intuit. We've had Maria Teel at our super cloud event, She's a cto, you know, they're all in the cloud. So they contributed that project. Where did Arlon come from? What was the origination? What's the purpose? Why our lawn, why this announcement? Yeah, >>So the, the inception of the project, this was the result of us realizing that problem that we spoke about earlier, which is complexity, right? With all of this, these clouds, these infrastructure, all the variations around and you know, compute storage networks and the proliferation of tools we talked about the Ansibles and Terraforms and Kubernetes itself, you can think of that as another tool, right? We saw a need to solve that complexity problem, and especially for people and users who use Kubernetes at scale. So when you have, you know, hundreds of clusters, thousands of applications, thousands of users spread out over many, many locations, there, there needs to be a system that helps simplify that management, right? So that means fewer tools, more expressive ways of describing the state that you want and more consistency. And, and that's why, you know, we built AR lawn and we built it recognizing that many of these problems or sub problems have already been solved. So Arlon doesn't try to reinvent the wheel, it instead rests on the shoulders of several giants, right? So for example, Kubernetes is one building block, GI ops, and Argo CD is another one, which provides a very structured way of applying configuration. And then we have projects like cluster API and cross plane, which provide APIs for describing infrastructure. So arlon takes all of those building blocks and builds a thin layer, which gives users a very expressive way of defining configuration and desired state. So that's, that's kind of the inception of, And >>What's the benefit of that? What does that give the, what does that give the developer, the user, in this case, >>The developers, the, the platform engineer, team members, the DevOps engineers, they get a a ways to provision not just infrastructure and clusters, but also applications and configurations. They get a way, a system for provisioning, configuring, deploying, and doing life cycle management in a, in a much simpler way. Okay. Especially as I said, if you're dealing with a large number of applications. >>So it's like an operating fabric, if you will. Yes. For them. Okay, so let's get into what that means for up above and below the, the, this abstraction or thin layer below the infrastructure. We talked a lot about what's going on below that. Yeah. Above our workloads at the end of the day, and I talk to CXOs and IT folks that, that are now DevOps engineers. They care about the workloads and they want the infrastructure's code to work. They wanna spend their time getting in the weeds, figuring out what happened when someone made a push that that happened or something happened. They need observability and they need to, to know that it's working. That's right. And here's my workloads running effectively. So how do you guys look at the workload side of it? Cuz now you have multiple workloads on these fabric, right? >>So workloads, so Kubernetes has defined kind of a standard way to describe workloads and you can, you know, tell Kubernetes, I want to run this container this particular way, or you can use other projects that are in the Kubernetes cloud native ecosystem, like K native, where you can express your application in more at a higher level, right? But what's also happening is in addition to the workloads, DevOps and platform engineering teams, they need to very often deploy the applications with the clusters themselves. Clusters are becoming this commodity. It's, it's becoming this host for the application and it kind of comes bundled with it. In many cases it is like an appliance, right? So DevOps teams have to provision clusters at a really incredible rate and they need to tear them down. Clusters are becoming more, >>It's coming like an EC two instance, spin up a cluster. We've heard people used words like that. That's >>Right. And before arlon you kind of had to do all of that using a different set of tools as, as I explained. So with AR loan you can kind of express everything together. You can say I want a cluster with a health monitoring stack and a logging stack and this ingress controller and I want these applications and these security policies. You can describe all of that using something we call the profile. And then you can stamp out your app, your applications and your clusters and manage them in a very, So >>It's essentially standard, like creates a mechanism. Exactly. Standardized, declarative kind of configurations. And it's like a playbook, just deploy it. Now what there is between say a script like I'm, I have scripts, I can just automate scripts >>Or yes, this is where that declarative API and infrastructure as configuration comes in, right? Because scripts, yes you can automate scripts, but the order in which they run matters, right? They can break, things can break in the middle and, and sometimes you need to debug them. Whereas the declarative way is much more expressive and powerful. You just tell the system what you want and then the system kind of figures it out. And there are these things are controllers which will in the background reconcile all the state to converge towards your desire. It's a much more powerful, expressive and reliable way of getting things done. >>So infrastructure as configuration is built kind of on, it's a super set of infrastructures code because it's >>An evolution. >>You need edge's code, but then you can configure the code by just saying do it. You basically declaring saying Go, go do that. That's right. Okay, so, alright, so cloud native at scale, take me through your vision of what that means. Someone says, Hey, what does cloud native at scale mean? What's success look like? How does it roll out in the future as you, not future next couple years. I mean people are now starting to figure out, okay, it's not as easy as it sounds. Kubernetes has value. We're gonna hear this year at CubeCon a lot of this, what does cloud native at scale >>Mean? Yeah, there are different interpretations, but if you ask me, when people think of scale, they think of a large number of deployments, right? Geographies, many, you know, supporting thousands or tens or millions of, of users there, there's that aspect to scale. There's also an equally important a aspect of scale, which is also something that we try to address with Arran. And that is just complexity for the people operating this or configuring this, right? So in order to describe that desired state, and in order to perform things like maybe upgrades or updates on a very large scale, you want the humans behind that to be able to express and direct the system to do that in, in relatively simple terms, right? And so we want the tools and the abstractions and the mechanisms available to the user to be as powerful but as simple as possible. So there's, I think there's gonna be a number and there have been a number of CNCF and cloud native projects that are trying to attack that complexity problem as well. And Arlon kind of falls in in that >>Category. Okay, so I'll put you on the spot rogue, that CubeCon coming up and now this'll be shipping this segment series out before. What do you expect to see at this year? It's the big story this year. What's the, what's the most important thing happening? Is it in the open source community and also within a lot of the, the people jockeying for leadership. I know there's a lot of projects and still there's some white space in the overall systems map about the different areas get run time and there's ability in all these different areas. What's the, where's the action? Where, where's the smoke? Where's the fire? Where's the piece? Where's the tension? >>Yeah, so I think one thing that has been happening over the past couple of coupon and I expect to continue and, and that is the, the word on the street is Kubernetes is getting boring, right? Which is good, right? >>Boring means simple. >>Well, well >>Maybe, >>Yeah, >>Invisible, >>No drama, right? So, so the, the rate of change of the Kubernetes features and, and all that has slowed but in, in a, in a positive way. But there's still a general sentiment and feeling that there's just too much stuff. If you look at a stack necessary for hosting applications based on Kubernetes, there are just still too many moving parts, too many components, right? Too much complexity. I go, I keep going back to the complexity problem. So I expect Cube Con and all the vendors and the players and the startups and the people there to continue to focus on that complexity problem and introduce further simplifications to, to the stack. >>Yeah. Vic, you've had an storied career VMware over decades with them within 12 years with 14 years or something like that. Big number co-founder here a platform. I you's been around for a while at this game, man. We talked about OpenStack, that project we interviewed at one of their events. So OpenStack was the beginning of that, this new revolution. I remember the early days it was, it wasn't supposed to be an alternative to Amazon, but it was a way to do more cloud cloud native. I think we had a Cloud Aati team at that time. We would joke we, you know, about, about the dream. It's happening now, now at Platform nine. You guys have been doing this for a while. What's the, what are you most excited about as the chief architect? What did you guys double down on? What did you guys pivot from or two, did you do any pivots? Did you extend out certain areas? Cuz you guys are in a good position right now, a lot of DNA in Cloud native. What are you most excited about and what does Platform Nine bring to the table for customers and for people in the industry watching this? >>Yeah, so I think our mission really hasn't changed over the years, right? It's been always about taking complex open source software because open source software, it's powerful. It solves new problems, you know, every year and you have new things coming out all the time, right? Opens Stack was an example and then Kubernetes took the world by storm. But there's always that complexity of, you know, just configuring it, deploying it, running it, operating it. And our mission has always been that we will take all that complexity and just make it, you know, easy for users to consume regardless of the technology, right? So the successor to Kubernetes, you know, I don't have a crystal ball, but you know, you have some indications that people are coming up of new and simpler ways of running applications. There are many projects around there who knows what's coming next year or the year after that. But platform will a, platform nine will be there and we will, you know, take the innovations from the the community. We will contribute our own innovations and make all of those things very consumable to customers. >>Simpler, faster, cheaper. Exactly. Always a good business model technically to make that happen. Yes. Yeah, I think the, the reigning in the chaos is key, you know, Now we have now visibility into the scale. Final question before we depart this segment. What is at scale, how many clusters do you see that would be a watermark for an at scale conversation around an enterprise? Is it workloads we're looking at or, or clusters? How would you, Yeah, how would you describe that? When people try to squint through and evaluate what's a scale, what's the at scale kind of threshold? >>Yeah. And, and the number of clusters doesn't tell the whole story because clusters can be small in terms of the number of nodes or they can be large. But roughly speaking when we say, you know, large scale cluster deployments, we're talking about maybe hundreds, two thousands. >>Yeah. And final final question, what's the role of the hyperscalers? You got AWS continuing to do well, but they got their core ias, they got a PAs, they're not too too much putting a SaaS out there. They have some SaaS apps, but mostly it's the ecosystem. They have marketplaces doing, doing over $2 billion billions of transactions a year and, and it's just like, just sitting there. It hasn't really, they're now innovating on it, but that's gonna change ecosystems. What's the role the cloud play in the cloud need of its scale? >>The, the hyper squares? >>Yeah, yeah. A's Azure Google, >>You mean from a business perspective, they're, they have their own interests that, you know, that they're, they will keep catering to, they, they will continue to find ways to lock their users into their ecosystem of services and, and APIs. So I don't think that's gonna change, right? They're just gonna keep well, >>They got great performance. I mean, from a, from a hardware standpoint, yes. That's gonna be key, >>Right? Yes. I think the, the move from X 86 being the dominant way and platform to run workloads is changing, right? That, that, that, that, and I think the, the hyper skaters really want to be in the game in terms of, you know, the, the new risk and arm ecosystems, the platforms. >>Yeah. Not joking aside, Paul Morritz, when he was the CEO of VMware, when he took over once said, I remember our first year doing the cube. Oh the cloud is one big distributed computer. It's, it's hardware and you got software and you got middleware and he kinda over, well he's kind of tongue in cheek, but really you're talking about large compute and sets of services that is essentially a distributed computer. Yes, >>Exactly. >>It's, we're back in the same game. Thank you for coming on the segment. Appreciate your time. This is cloud native at scale special presentation with Platform nine. Really unpacking super cloud Arlon open source and how to run large scale applications on the cloud, cloud native develop for developers. And John Furrier with the cube. Thanks for Washington. We'll stay tuned for another great segment coming right up. Hey, welcome back everyone to Super Cloud 22. I'm John Fur, host of the Cuba here all day talking about the future of cloud. Where's it all going? Making it super multi-cloud is around the corner and public cloud is winning. Got the private cloud on premise and Edge. Got a great guest here, Vascar Gorde, CEO of Platform nine, just on the panel on Kubernetes. An enabler blocker. Welcome back. Great to have you on. >>Good to see you >>Again. So Kubernetes is a blocker enabler by, with a question mark I put on on there. Panel was really to discuss the role of Kubernetes. Now great conversation operations is impacted. What's just thing about what you guys are doing at Platform nine? Is your role there as CEO and the company's position, kind of like the world spun into the direction of Platform nine while you're at the helm, right? >>Absolutely. In fact, things are moving very well and since they came to us, it was an insight to call ourselves the platform company eight years ago, right? So absolutely whether you are doing it in public clouds or private clouds, you know, the application world is moving very fast in trying to become digital and cloud native. There are many options for you to run the infrastructure. The biggest blocking factor now is having a unified platform. And that's what where we come into >>Patrick, we were talking before we came on stage here about your background and we were kind of talking about the glory days in 2000, 2001 when the first ASPs application service providers came out. Kind of a SaaS vibe, but that was kind of all kind of cloud-like >>It wasn't, >>And web services started then too. So you saw that whole growth. Now, fast forward 20 years later, 22 years later, where we are now, when you look back then to here and all the different cycles, >>In fact, you know, as we were talking offline, I was in one of those ASPs in the year 2000 where it was a novel concept of saying we are providing a software and a capability as a service, right? You sign up and start using it. I think a lot has changed since then. The tooling, the tools, the technology has really skyrocketed. The app development environment has really taken off exceptionally well. There are many, many choices of infrastructure now, right? So I think things are in a way the same but also extremely different. But more importantly now for any company, regardless of size, to be a digital native, to become a digital company is extremely mission critical. It's no longer a nice to have everybody's in the journey somewhere. >>Everyone is going digital transformation here. Even on a so-called downturn recession that's upcoming inflations sea year. It's interesting. This is the first downturn, the history of the world where the hyperscale clouds have been pumping on all cylinders as an economic input. And if you look at the tech trends, GDPs down, but not tech. Nope. Cause pandemic showed everyone digital transformation is here and more spend and more growth is coming even in, in tech. So this is a unique factor which proves that that digital transformation's happening and company, every company will need a super cloud. >>Everyone, every company, regardless of size, regardless of location, has to become modernize their infrastructure. And modernizing infrastructure is not just some, you know, new servers and new application tools. It's your approach, how you're serving your customers, how you're bringing agility in your organization. I think that is becoming a necessity for every enterprise to survive. >>I wanna get your thoughts on Super Cloud because one of the things Dave Alon and I want to do with Super Cloud and calling it that was we, I, I personally, and I know Dave as well, he can, I'll speak from, he can speak for himself. We didn't like multi-cloud. I mean not because Amazon said don't call things multi-cloud, it just didn't feel right. I mean everyone has multiple clouds by default. If you're running productivity software, you have Azure and Office 365. But it wasn't truly distributed. It wasn't truly decentralized, it wasn't truly cloud enabled. It didn't, it felt like they're not ready for a market yet. Yet public clouds booming on premise. Private cloud and Edge is much more on, you know, more, More dynamic, more unreal. >>Yeah. I think the reason why we think Super cloud is a better term than multi-cloud. Multi-cloud are more than one cloud, but they're disconnected. Okay, you have a productivity cloud, you have a Salesforce cloud, you may have, everyone has an internal cloud, right? So, but they're not connected. So you can say, okay, it's more than one cloud. So it's, you know, multi-cloud. But super cloud is where you are actually trying to look at this holistically. Whether it is on-prem, whether it is public, whether it's at the edge, it's a store at the branch. You are looking at this as one unit. And that's where we see the term super cloud is more applicable because what are the qualities that you require if you're in a super cloud, right? You need choice of infrastructure, you need, but at the same time you need a single pan or a single platform for you to build your innovations on, regardless of which cloud you're doing it on, right? So I think Super Cloud is actually a more tightly integrated orchestrated management philosophy we think. >>So let's get into some of the super cloud type trends that we've been reporting on. Again, the purpose of this event is as a pilot to get the conversations flowing with, with the influencers like yourselves who are running companies and building products and the builders, Amazon and Azure are doing extremely well. Google's coming up in third Cloudworks in public cloud. We see the use cases on premises use cases. Kubernetes has been an interesting phenomenon because it's become from the developer side a little bit, but a lot of ops people love Kubernetes. It's really more of an ops thing. You mentioned OpenStack earlier. Kubernetes kind of came out of that open stack. We need an orchestration. And then containers had a good shot with, with Docker. They re pivoted the company. Now they're all in an open source. So you got containers booming and Kubernetes as a new layer there. >>What's, >>What's the take on that? What does that really mean? Is that a new defacto enabler? It >>Is here. It's for here for sure. Every enterprise somewhere in the journey is going on. And you know, most companies are, 70 plus percent of them have 1, 2, 3 container based, Kubernetes based applications now being rolled out. So it's very much here. It is in production at scale by many customers. And it, the beauty of it is yes, open source, but the biggest gating factor is the skill set. And that's where we have a phenomenal engineering team, right? So it's, it's one thing to buy a tool and >>Just be clear, you're a managed service for Kubernetes. >>We provide, provide a software platform for cloud acceleration as a service and it can run anywhere. It can run in public private. We have customers who do it in truly multi-cloud environments. It runs on the edge, it runs at this in stores about thousands of stores in a retailer. So we provide that and also for specific segments where data sovereignty and data residency are key regulatory reasons. We also un on-prem as an air gap version. Can >>You give an example on how you guys are deploying your platform to enable a super cloud experience for your customer? Right. >>So I'll give you two different examples. One is a very large networking company, public networking company. They have hundreds of products, hundreds of r and d teams that are building different, different products. And if you look at few years back, each one was doing it on a different platforms, but they really needed to bring the agility. And they worked with us now over three years where we are their build test dev pro platform where all their products are built on, right? And it has dramatically increased their agility to release new products. Number two, it actually is a light out operation. In fact, the customer says like, like the Maytag service person, cuz we provide it as a service and it barely takes one or two people to maintain it for them. >>So it's kinda like an SRE vibe. One person managing a >>Large 4,000 engineers building infrastructure >>On their tools, >>Whatever they want on their tools. They're using whatever app development tools they use, but they use our platform. What >>Benefits are they seeing? Are they seeing speed? >>Speed, definitely. Okay. Definitely they're speeding. Speed uniformity because now they're building able to build, so their customers who are using product A and product B are seeing a similar set of tools that are being used. >>So a big problem that's coming outta this super cloud event that we're, we're seeing and we heard it all here, ops and security teams. Cause they're kind of part of one thing, but option security specifically need to catch up speed wise. Are you delivering that value to ops and security? Right? >>So we, we work with ops and security teams and infrastructure teams and we layer on top of that. We have like a platform team. If you think about it, depending on where you have data centers, where you have infrastructure, you have multiple teams, okay, but you need a unified platform. Who's your buyer? Our buyer is usually, you know, the product divisions of companies that are looking at or the CTO would be a buyer for us functionally cio definitely. So it it's, it's somewhere in the DevOps to infrastructure. But the ideal one we are beginning to see now many large corporations are really looking at it as a platform and saying we have a platform group on which any app can be developed and it is run on any infrastructure. So the platform engineering teams. So >>You working two sides to that coin. You've got the dev side and then >>And then infrastructure >>Side. >>Okay. Another customer that I give an example, which I would say is kind of the edge of the store. So they have thousands of stores. Retail, retail, you know food retailer, right? They have thousands of stores that are on the globe, 50,000, 60,000. And they really want to enhance the customer experience that happens when you either order the product or go into the store and pick up your product or buy or browse or sit there. They have applications that were written in the nineties and then they have very modern AIML applications today. They want something that will not have to send an IT person to install a rack in the store or they can't move everything to the cloud because the store operations has to be local. The menu changes based on it's classic edge. It's classic edge, yeah. Right? They can't send it people to go install rack access servers then they can't sell software people to go install the software and any change you wanna put through that, you know, truck roll. So they've been working with us where all they do is they ship, depending on the size of the store, one or two or three little servers with instructions that >>You, you say little servers like how big one like a box, like a small little box, >>Right? And all the person in the store has to do like what you and I do at home and we get a, you know, a router is connect the power, connect the internet and turn the switch on. And from there we pick it up. >>Yep. >>We provide the operating system, everything and then the applications are put on it. And so that dramatically brings the velocity for them. They manage thousands of >>Them. True plug and play >>Two, plug and play thousands of stores. They manage it centrally. We do it for them, right? So, so that's another example where on the edge then we have some customers who have both a large private presence and one of the public clouds. Okay. But they want to have the same platform layer of orchestration and management that they can use regardless of the locations. >>So you guys got some success. Congratulations. Got some traction there. It's awesome. The question I want to ask you is that's come up is what is truly cloud native? Cuz there's lift and shift of the cloud >>That's not cloud native. >>Then there's cloud native. Cloud native seems to be the driver for the super cloud. How do you talk to customers? How do you explain when someone says what's cloud native, what isn't cloud native? >>Right. Look, I think first of all, the best place to look at what is the definition and what are the attributes and characteristics of what is truly a cloud native, is CNC foundation. And I think it's very well documented, very well. >>Tucan, of course Detroit's >>Coming so, so it's already there, right? So we follow that very closely, right? I think just lifting and shifting your 20 year old application onto a data center somewhere is not cloud native. Okay? You can't put to cloud, not you have to rewrite and redevelop your application in business logic using modern tools. Hopefully more open source and, and I think that's what Cloudnative is and we are seeing a lot of our customers in that journey. Now everybody wants to be cloudnative, but it's not that easy, okay? Because it's, I think it's first of all, skill set is very important. Uniformity of tools that there's so many tools there. Thousands and thousands of tools you could spend your time figuring out which tool to use. Okay? So I think the complexity is there, but the business benefits of agility and uniformity and customer experience are truly being done. >>And I'll give you an example, I don't know how clear native they are, right? And they're not a customer of ours, but you order pizzas, you do, right? If you just watch the pizza industry, how dominoes actually increase their share and mind share and wallet share was not because they were making better pizzas or not, I don't know anything about that, but the whole experience of how you order, how you watch what's happening, how it's delivered. There were a pioneer in it. To me, those are the kinds of customer experiences that cloud native can provide. >>Being agility and having that flow to the application changes what the expectations >>Are >>For the customer. Customer, >>The customer's expectations change, right? Once you get used to a better customer experience, you learn. >>That's to wrap it up. I wanna just get your perspective again. One of the benefits of chatting with you here and having you part of the Super Cloud 22 is you've seen many cycles, you have a lot of insights. I want to ask you, given your career where you've been and what you've done and now let's CEO platform nine, how would you compare what's happening now with other inflection points in the industry? And you've been, again, you've been an entrepreneur, you sold your company to Oracle, you've been seeing the big companies, you've seen the different waves. What's going on right now put into context this moment in time around Super Cloud. >>Sure. I think as you said, a lot of battles. CARSs being been in an asb, being in a real time software company, being in large enterprise software houses and a transformation. I've been on the app side, I did the infrastructure right and then tried to build our own platforms. I've gone through all of this myself with lot of lessons learned in there. I think this is an event which is happening now for companies to go through to become cloud native and digitalize. If I were to look back and look at some parallels of the tsunami that's going on is a couple of paddles come to me. One is, think of it, which was forced to honors like y2k. Everybody around the world had to have a plan, a strategy, and an execution for y2k. I would say the next big thing was e-commerce. I think e-commerce has been pervasive right across all industries. >>And disruptive. >>And disruptive, extremely disruptive. If you did not adapt and adapt and accelerate your e-commerce initiative, you were, it was an existence question. Yeah. I think we are at that pivotal moment now in companies trying to become digital and cloudnative. You know, that is what I see >>Happening there. I think that that e-commerce is interesting and I think just to riff with you on that is that it's disrupting and refactoring the business models. I think that is something that's coming out of this is that it's not just completely changing the gain, it's just changing how you operate, >>How you think and how you operate. See, if you think about the early days of e-commerce, just putting up a shopping cart that made you an e-commerce or e retailer or an e e e customer, right? Or so. I think it's the same thing now is I think this is a fundamental shift on how you're thinking about your business. How are you gonna operate? How are you gonna service your customers? I think it requires that just lift and shift is not gonna work. >>Nascar, thank you for coming on, spending the time to come in and share with our community and being part of Super Cloud 22. We really appreciate, we're gonna keep this open. We're gonna keep this conversation going even after the event, to open up and look at the structural changes happening now and continue to look at it in the open in the community. And we're gonna keep this going for, for a long, long time as we get answers to the problems that customers are looking for with cloud cloud computing. I'm Sean Fur with Super Cloud 22 in the Cube. Thanks for watching. >>Thank you. Thank you. >>Hello and welcome back. This is the end of our program, our special presentation with Platform nine on cloud native at scale, enabling the super cloud. We're continuing the theme here. You heard the interviews Super Cloud and its challenges, new opportunities around solutions around like Platform nine and others with Arlon. This is really about the edge situations on the internet and managing the edge multiple regions, avoiding vendor lock in. This is what this new super cloud is all about. The business consequences we heard and and the wide ranging conversations around what it means for open source and the complexity problem all being solved. I hope you enjoyed this program. There's a lot of moving pieces and things to configure with cloud native install, all making it easier for you here with Super Cloud and of course Platform nine contributing to that. Thank you for watching.

>>Hello everyone. Welcome to the cube here in Palo Alto, California for a special program on cloud native at scale, enabling next generation cloud or super cloud for modern application cloud native developers. I'm John Forer, host of the Cube. My pleasure to have here me Makoski, co-founder and VP of product at Platform nine. Thanks for coming in today for this Cloudnative at scale conversation. Thank >>You for having >>Me. So Cloudnative at scale, something that we're talking about because we're seeing the, the next level of mainstream success of containers Kubernetes and cloud native develop, basically DevOps in the C I C D pipeline. It's changing the landscape of infrastructure as code, it's accelerating the value proposition and the super cloud as we call it, has been getting a lot of traction because this next generation cloud is looking a lot different, but kind of the same as the first generation. What's your view on super cloud as it fits to cloud native as scales up? >>Yeah. You know, I think what's interesting, and I think the reason why Super Cloud is a really good and a really fit term for this, and I think, I know my CEO was chatting with you as well, and he was mentioning this as well, but I think there needs to be a different term than just multi-cloud or cloud. And the reason is because as cloud native and cloud deployments have scaled, I think we've reached a point now where instead of having the traditional data center style model where you have a few large distributors of infrastructure and workload at a few locations, I think the model is kind of flipped around, right? Where you have a large number of micro sites. These micro sites could be your public cloud deployment, your private on-prem infrastructure deployments, or it could be your edge environment, right? And every single enterprise, every single industry is moving that direction. And so you gotta rougher that with a terminology that, that, that indicates the scale and complexity of it. And so I think super cloud is a, is an appropriate term >>For that. So you brought a couple things I want to dig into. You mentioned edge nodes. We're seeing not only edge nodes being the next kind of area of innovation, mainly because it's just popping up everywhere. And that's just the beginning. We even know what's around the corner. You got buildings, you got I O D OT and IT kind of coming together. But you also got this idea of regions, global infrastructure is big part of it. I just saw some news around CloudFlare shutting down a site here. There's policies being made at scale. These new challenges there, can you share because you gotta have edge. So hybrid cloud is a winning formula. Everybody knows that it's a steady state. Yeah. But across multiple clouds brings in this new un engineered area, yet it hasn't been done yet. Spanning clouds. People say they're doing it, but you start to see the toe in the water, it's happening, it's gonna happen. It's only gonna get accelerated with the edge and beyond globally. So I have to ask you, what is the technical challenges in doing this? Because there's some business consequences as well, but there are technical challenges. Can you share your view on what the technical challenges are for the super cloud or across multiple edges and regions? >>Yeah, absolutely. So I think, you know, in in the context of this, the, this, this term of super cloud, I think it's sometimes easier to visualize things in terms of two access, right? I think on one end you can think of the scale in terms of just pure number of nodes that you have, deploy number of clusters in the Kubernetes space. And then on the other access you would have your distribution factor, right? Which is, do you have these tens of thousands of notes in one site or do you have them distributed across tens of thousands of sites with one node at each site? Right? And if you have just one flavor of this, there is enough complexity, but potentially manageable. But when you are expanding on both these access, you really get to a point where that scale really needs some well thought out, well structured solutions to address it, right? A combination of homegrown tooling along with your, you know, favorite distribution of Kubernetes is not a strategy that can help you in this environment. It may help you when you have one of this or when you, when your scale is not at the level, >>Can you scope the complexity? Because I mean, I hear a lot of moving parts going on there, the technology's also getting better. We we're seeing cloud data become successful. There's a lot to configure, there's a lot to install. Can you scope the scale of the problem? Because we're about at scale Yep. Challenges here. Yeah, >>Absolutely. And I think, you know, I I like to call it, you know, the, the problem that the scale creates, you know, there's various problems, but I think one, one problem, one way to think about it is, is you know, it works on my cluster problem, right? So, you know, I come from engineering background and there's a, you know, there's a famous saying between engineers and QA and the support folks, right? Which is, it works on my laptop, which is I tested this change, everything was fantastic, it worked flawlessly on my machine, on production, it's not working. And the exact same problem now happens in these distributed environments, but at massive scale, right? Which is that, you know, developers test their applications, et cetera within the sanctity of their sandbox environments. But once you expose that change in the wild world of your production deployment, right? >>And the production deployment could be going at the radio cell tower at the edge location where a cluster is running there, or it could be sending, you know, these applications and having them run at my customer site where they might not have configured that cluster exactly the same way as I configured it, or they configured the cluster, right? But maybe they didn't deploy the security policies or they didn't deploy the other infrastructure plugins that my app relies on. All of these various factors add their own layer of complexity. And there really isn't a simple way to solve that today. And that is just, you know, one example of an issue that happens. I think another, you know, whole new ball game of issues come in the context of security, right? Because when you are deploying applications at scale in a distributed manner, you gotta make sure someone's job is on the line to ensure that the right security policies are enforced regardless of that scale factor. So I think that's another example of problems that >>Occur. Okay. So I have to ask about scale because there are a lot of multiple steps involved when you see the success cloud native, you know, you see some, you know, some experimentation. They set up a cluster, say it's containers and Kubernetes, and then you say, Okay, we got this, we can figure it. And then they do it again and again, they call it day two. Some people call it day one, day two operation, whatever you call it. Once you get past the first initial thing, then you gotta scale it. Then you're seeing security breaches, you're seeing configuration errors. This seems to be where the hotspot is. And when companies transition from, I got this to, Oh no, it's harder than I thought at scale. Can you share your reaction to that and how you see this playing out? >>Yeah, so, you know, I think it's interesting. There's multiple problems that occur when, you know, the, the two factors of scale is we talked about start expanding. I think one of them is what I like to call the, you know, it, it works fine on my cluster problem, which is back in, when I was a developer, we used to call this, it works on my laptop problem, which is, you know, you have your perfectly written code that is operating just fine on your machine, your sandbox environment. But the moment it runs production, it comes back with p zeros and POS from support teams, et cetera. And those issues can be really difficult to triage us, right? And so in the Kubernetes environment, this problem kind of multi folds, it goes, you know, escalate to a higher degree because you have your sandbox developer environments, they have their clusters and things work perfectly fine in those clusters because these clusters are typically handcrafted or a combination of some scripting and handcrafting. >>And so as you give that change to then run at your production edge location, like say your radio cell tower site or you hand it over to a customer to run it on their cluster, they might not have not have configured that cluster exactly how you did, or they might not have configured some of the infrastructure plugins. And so the things don't work. And when things don't work, triaging them becomes like ishly hard, right? It's just one of the examples of the problem. Another whole bucket of issues is security, which is, is you have these distributed clusters at scale, you gotta ensure someone's job is on the line to make sure that the security policies are configured >>Properly. So this is a huge problem. I love that comment. That's not not happening on my system. It's the classic, you know, debugging mentality. Yeah. But at scale it's hard to do that with error prone. I can see that being a problem. And you guys have a solution you're launching. Can you share what Arlon is this new product? What is it all about? Talk about this new introduction. >>Yeah, absolutely. I'm very, very excited. You know, it's one of the projects that we've been working on for some time now because we are very passionate about this problem and just solving problems at scale in on-prem or at in the cloud or at edge environments. And what arwan is, it's an open source project and it is a tool, it's a Kubernetes native tool for complete end-to-end management of not just your clusters, but your clusters. All of the infrastructure that goes within and along the sites of those clusters, security policies, your middleware plugins, and finally your applications. So what Arlan lets you do in a nutshell is in a declarative way, it lets you handle the configuration and management of all of these components in at scale. >>So what's the elevator pitch simply put for what dissolves in, in terms of the chaos you guys are reigning in, what's the, what's the bumper sticker? Yeah, >>What would it do? There's a perfect analogy that I love to reference in this context, which is think of your assembly line, you know, in a traditional, let's say, you know, an auto manufacturing factory or et cetera, and the level of efficiency at scale that that assembly line brings, right? Lon. And if you look at the logo we've designed, it's this funny little robot, and it's because when we think of lon, we think of these enterprise large scale environments, you know, sprawling at scale creating chaos because there isn't necessarily a well thought through, well-structured solution that's similar to an assembly line, which is taking each component, you know, addressing them, manufacturing, processing them in a standardized way, then handing to the next stage where again, it gets, you know, processed in a standardized way. And that's what Alon really does. That's like the deliver pitch. If you have problems of scale of managing your infrastructure, you know, that is distributed. Arlon brings the assembly line level of efficiency and consistency for those. >>So keeping it smooth, the assembly line, things are flowing. See c i CD pipelining. Exactly. So that's what you're trying to simplify that ops piece for the developer. I mean, it's not really ops, it's their ops is coding. >>Yeah. Not just developer, the ops, the operations folks as well, right? Because developers, you know, there is, developers are responsible for one picture of that layer, which is my apps, and then maybe that middleware of applications that they interface with, but then they hand it over to someone else who's then responsible to ensure that these apps are secured properly, that they are logging, logs are being collected properly, monitoring and observability is integrated. And so it solves problems for both those teams. >>Yeah, it's dev op, So the DevOps is the cloud needed developer, The kins have to kind of set policies. Is that where the declarative piece comes in? Is that why that's important? >>Absolutely. Yeah. And, and, and, and you know, es really in introduced or elevated this declarative management, right? Because you know, Kubernetes clusters are Yeah. Or your, yeah, you know, specifications of components that go in Kubernetes are defined in a declarative way. And Kubernetes always keeps that state consistent with your defined state. But when you go outside of that world of a single cluster, and when you actually talk about defining the clusters or defining everything that's around it, there really isn't a solution that does that today. And so Arlan addresses that problem at the heart of it, and it does that using existing open source, well known solutions. >>Medo, I want to get into the benefits, what's in it for me as the customer developer, but I want to finish this out real quick and get your thoughts. You mentioned open source. Why open source? What's the, what's the current state of the product? You run the product group over there, Platform nine, is it open source? And you guys have a product that's commercial. Can you explain the open source dynamic? And first of all, why open source? Yeah. And what is the consumption? I mean, open source is great, People want open source, they can download it, look up the code, but maybe wanna buy the commercial. So I'm assuming you have that thought through, can you share that open source and commercial relationship? >>Yeah, I think, you know, starting with why open source? I think it's, you know, we as a company, we have, you know, one of the things that's absolutely critical to us is that we take mainstream open source technologies components and then we, you know, make them available to our customers at scale through either a SAS model or onpro model, right? But, so as we are a company or startup or a company that benefits, you know, in a massive way by this open source economy, it's only right, I think in my mind that we do our part of the duty, right? And contribute back to the community that feeds us. And so, you know, we have always held that strongly as one of our principles. And we have, you know, created and built independent products starting all the way with fi, which was a serverless product, you know, that we had built to various other, you know, examples that I can give. But that's one of the main reasons why open source and also open source because we want the community to really firsthand engage with us on this problem, which is very difficult to achieve if your product is behind a wall, you know, behind, behind a blog box. >>Well, and that's, that's what the developers want too. And what we're seeing in reporting with Super Cloud is the new model of consumption is I wanna look at the code and see what's in there. That's right. And then also, if I want to use it, I, I'll do it. Great. That's open source, that's the value. But then at the end of the day, if I wanna move fast, that's when people buy in. So it's a new kind of freemium, I guess, business model. I guess that's the way it is. Well, but that's, that's the benefit. Open source. This is why standards and open source growing so fast, you have that confluence of, you know, a way fors to try before they buy, but also actually kind of date the application, if you will. We, you know, Adrian Karo uses the dating metaphor, you know, Hey, you know, I wanna check it out first before I get married. Right? And that's what open source, So this is the new, this is how people are selling. This is not just open source, this is how companies are selling. >>Absolutely. Yeah. Yeah. You know, I think in, you know, two things, I think one is just, you know, this, this, this cloud native space is so vast that if you, if you're building a close flow solution, sometimes there's also a risk that it may not apply to every single enterprise's use cases. And so having it open source gives them an opportunity to extend it, expand it, to make it proper to their use case if they choose to do so, right? But at the same time, what's also critical to us is we are able to provide a supported version of it with an SLA that we, you know, that's backed by us, a sa hosted version of it as well, for those customers who choose to go that route, you know, once they have used the open source version and loved it and want to take it at scale and in production and need, need, need a partner to collaborate with, who can, you know, support them for that production environment. I >>Have to ask you now, let's get into what's in it for the customer. I'm a customer, why should I be enthused about Arlo? What's in it for me? You know? Cause if I'm not enthused about it, I'm not gonna be confident and it's gonna be hard for me to get behind this. Can you share your enthusiastic view of, you know, why I should be enthused about Arlo if I'm a >>Customer? Yeah, absolutely. And so, and there's multiple, you know, enterprises that we talk to, many of them, you know, our customers, where this is a very kind of typical story that you will hear, which is we have, you know, a Kubernetes distribution. It could be on premise, it could be public clouds, native Kubernetes, and then we have our C I C D pipelines that are automating the deployment of applications, et cetera. And then there's this gray zone. And the gray zone is well before you can you, your CS CD pipelines can deploy the apps. Somebody needs to do all of that groundwork of, you know, defining those clusters and yeah. You know, properly configuring them. And as these things, these things start by being done hand grown. And then as the, as you scale, what typically enterprises would do today is they will have their home homegrown DIY solutions for this. >>I mean, the number of folks that I talk to that have built Terra from automation, and then, you know, some of those key developers leave. So it's a typical open source or typical, you know, DIY challenge. And the reason that they're writing it themselves is not because they want to. I mean, of course technology is always interesting to everybody, but it's because they can't find a solution that's out there that perfectly fits the problem. And so that's that pitch. I think spic would be delighted. The folks that we've spoken, you know, spoken with, have been absolutely excited and have, you know, shared that this is a major challenge we have today because we have, you know, few hundreds of clusters on s Amazon and we wanna scale them to few thousands, but we don't think we are ready to do that. And this will give us the ability. >>Yeah, I think people are scared. Not, I won't say scare, that's a a bad word. Maybe I should say that they feel nervous because, you know, at scale small mistakes can become large mistakes. This is something that is concerning to enterprises and, and I think this is gonna come up at Cuban this year where enterprises are gonna say, Okay, I need to see SLAs. I wanna see track record, I wanna see other companies that have used it. Yeah. How would you answer that question to, or, or challenge, you know, Hey, I love this, but is there any guarantees? Is there any, what's the sla I'm an enterprise, I got tight, you know, I love the open source kind of free, fast and loose, but I need hardened code. >>Yeah, absolutely. So, so two parts to that, right? One is Arlan leverages existing open source components, products that are extremely popular. Two specifically. One is Arlan uses Argo cd, which is probably one of the highest rated and used CD open source tools that's out there, right? It's created by folks that are as part of into team now, you know, really brilliant team. And it's used at scale across enterprises. That's one. Second is arlon also makes use of cluster api capi, which is a sub-component, right? For lifecycle management of clusters. So there is enough of, you know, community users, et cetera, around these two products, right? Or, or, or open source projects that will find Arlan to be right up in their alley because they're already comfortable, familiar with algo cd. Now Arlan just extends the scope of what Algo CD can do. And so that's one. And then the second part is going back to your point of the comfort. And that's where, you know, Platform nine has a role to play, which is when you are ready to deploy arlon at scale, because you've been, you know, playing with it in your dev tested environments, you're happy with what you get with it, then Platform nine will stand behind it and provide that sla. >>And what's been the reaction from customers you've talked to Platform nine customers with, with, that are familiar with, with Argo and then Arlo? What's been some of the feedback? >>Yeah, I, I, I think the feedback's been fantastic. I mean, I can give you examples of customers where, you know, initially, you know, when you are, when you're telling them about your entire portfolio of solutions, it might not strike a card right away. But then we start talking about Arlan and, and we talk about the fact that it uses Argo cdn, they start opening up, they say, We have standardized on Argo and we have built these components, homegrown, we would be very interested. Can we co-develop? Does it support these use cases? So we've had that kind of validation. We've had validation all the way at the beginning of our lawn before we even wrote a single line of code saying this is something we plan on doing. And the customer said, If you had it today, I would've purchased it. So it's been really great validation. >>All right. So next question is, what is the solution to the customer? If I asked you, Look it, I have, I'm so busy, my team's overworked. I got a skills gap. I don't need another project that's, I'm so tied up right now and I'm just chasing my tail. How does Platform nine help me? >>Yeah, absolutely. So I think, you know, one of the core tenets of Platform nine has always been that we try to bring that public cloud like simplicity by hosting, you know, this in a lot of such similar tools in a SAS hosted manner for our customers, right? So our goal behind doing that is taking away or trying to take away all of that complexity from customer's hands and offloading it to our hands, right? And giving them that full white glove treatment as we call it. And so from a customer's perspective, one, something like arlon will integrate with what they have so they don't have to rip and replace anything. In fact, it will, even in the next versions, it may even discover your clusters that you have today and, you know, give you an inventory. And so >>Customers have clusters that are growing, that's a sign correct call you guys. >>Absolutely. Either they're, they have massive large clusters, right? That they wanna split into smaller clusters, but they're not comfortable doing that today, or they've done that already on say, public cloud or otherwise. And now they have management challenges. >>So especially operationalizing the clusters, whether they want to kind of reset everything and remove things around and reconfigure Yep. And or scale out. >>That's right. Exactly. And >>You provide that layer of policy. >>Absolutely. Yes. >>That's the key value >>Here. That's right. >>So policy based configuration for cluster scale >>Up, well profile and policy based declarative configuration and lifecycle management for >>Clusters. If I asked you how this enables Super Cloud, what would you say to that? >>I think this is one of the key ingredients to super cloud, right? If you think about a super cloud environment, there is at least few key ingredients that that come to my mind that are really critical. Like they are, you know, life saving ingredients at that scale. One is having a really good strategy for managing that scale. You know, in a, going back to assembly line in a very consistent, predictable way. So that are land solves, then you, you need to compliment that with the right kind of observability and monitoring tools at scale, right? Because ultimately issues are gonna happen and you're gonna have to figure out, you know, how to solve them fast. And arlon by the way, also helps in that direction, but you also need observability tools. And then especially if you're running at, on the public cloud, you need some cost management tools. In my mind, these three things are like the most necessary ingredients to make Super Cloud successful. And, you know, our long flows >>In one. Okay, so now the next level is, Okay, that makes sense. Is under the covers kind of speak under the hood. Yeah. How does that impact the app developers of the cloud native modern application workflows? Because the impact to me seems the apps are gonna be impacted. Are they gonna be faster, stronger? I mean, what's the impact if you do all those things as you mentioned, what's the impact of the apps? >>Yeah, the impact is that your apps are more likely to operate in production the way you expect them to, because the right checks and balances have gone through, and any discrepancies have been identified prior to those apps, prior to your customer running into them, right? Because developers run into this challenge today where there's a split responsibility, right? I'm responsible for my code, I'm responsible for some of these other plugins, but I don't own these stack end to end. I have to rely on my ops counterpart to do their part, right? And so this really gives them, you know, the right tooling for >>That. So this is actually a great kind of relevant point, you know, as cloud becomes more scalable, you're starting to see this fragmentation gone of the days of the fulls stack developer to the more specialized role. But this is a key point, and I have to ask you because if this, our low solution takes place, as you say, and the apps are gonna be stupid, they designed to do, the question is, what did, does the current pain look like? Are the apps breaking? What is the signals to the customer Yeah. That they should be calling you guys up into implementing Arlo, Argo and, and all the other goodness to automate? What does some of the signals, is it downtime? Is it, is it failed apps, is it latency? What are some of the things that Yeah, absolutely. That would be indications of things are effed up a little bit. >>Yeah. More frequent down times, down times that are, that take longer to triage. And so your, you know, the, you know, your mean times on resolution, et cetera, are escalating or growing larger, right? Like we have environments of customers where they're, they have a number of folks on in the field that have to take these apps and run them at customer sites. And that's one of our partners, and they're extremely interested in this because the, the, the rate of failures they're encountering for this, you know, the field when they're running these apps on site, because the field is automating their clusters that are running on sites using their own scripts. So these are the kinds of challenges, and those are the pain points, which is, you know, if you're looking to reduce your meantime to resolution, if you're looking to reduce the number of failures that occur on your production site, that's one. And second, if you're looking to manage these at scale environments with a relatively small, focused, nimble ops team, which has an immediate impact on your budget. So those are, those are the signals. >>This is the cloud native at scale situation, the innovation going on. Final thought is your reaction to the idea that if the world goes digital, which it is, and the confluence of physical and digital coming together, and cloud continues to do its thing, the company becomes the application not where it used to be supporting the business, you know, the back office and the immediate terminals and some PCs and handhelds. Now if technology's running, the business is the business. Yeah. Company's the application. Yeah. So it can't be down. So there's a lot of pressure on, on CSOs and CIOs now and boards are saying, How is technology driving the top line revenue? That's the number one conversation. Yep. Do you see the same thing? >>Yeah, it's interesting. I think there's multiple pressures at the cx, OCI O level, right? One is that there needs to be that visibility and clarity and guarantee almost that, you know, the, the, the technology that's, you know, that's gonna drive your top line is gonna drive that in a consistent, reliable, predictable manner. And then second, there is the constant pressure to do that while always lowering your costs of doing it right? Especially when you're talking about, let's say retailers or those kinds of large scale vendors, they many times make money by lowering the amount that they spend on, you know, providing those goods to their end customers. So I think those, both those factors kind of come into play and the solution to all of them is usually in a very structured strategy around automation. >>Final question. What does cloud native at scale look like to you? If all the things happen the way we want 'em to happen, The magic wand, the magic dust, what does it look like? >>What that looks like to me is a CIO sipping at his desk on coffee production is running absolutely smooth. And his, he's running that at a nimble, nimble team size of at the most, a handful of folks that are just looking after things, but things are just taking >>Care and the CIO doesn't exist. There's no seeso there at the beach. >>Yep. >>Thank you for coming on, sharing the cloud native at scale here on the cube. Thank you for your time. >>Fantastic. Thanks for >>Having me. Okay. I'm John Fur here for special program presentation, special programming cloud native at scale, enabling super cloud modern applications with Platform nine. Thanks for watching.

>>Hello, welcome to the Cube here in Palo Alto, California for a special presentation on Cloud native at scale, enabling super cloud modern applications with Platform nine. I'm John Furr, your host of The Cube. We had a great lineup of three interviews we're streaming today. Meor Ma Makowski, who's the co-founder and VP of Product of Platform nine. She's gonna go into detail around Arlon, the open source products, and also the value of what this means for infrastructure as code and for cloud native at scale. Bickley the chief architect of Platform nine Cube alumni. Going back to the OpenStack days. He's gonna go into why Arlon, why this infrastructure as code implication, what it means for customers and the implications in the open source community and where that value is. Really great wide ranging conversation there. And of course, Vascar, Gort, the CEO of Platform nine, is gonna talk with me about his views on Super Cloud and why Platform nine has a scalable solutions to bring cloudnative at scale. So enjoy the program. See you soon. Hello everyone. Welcome to the cube here in Palo Alto, California for special program on cloud native at scale, enabling next generation cloud or super cloud for modern application cloud native developers. I'm John Furry, host of the Cube. A pleasure to have here, me Makoski, co-founder and VP of product at Platform nine. Thanks for coming in today for this Cloudnative at scale conversation. Thank >>You for having me. >>So Cloudnative at scale, something that we're talking about because we're seeing the, the next level of mainstream success of containers Kubernetes and cloud native develop, basically DevOps in the C I C D pipeline. It's changing the landscape of infrastructure as code, it's accelerating the value proposition and the super cloud as we call it, has been getting a lot of traction because this next generation cloud is looking a lot different, but kind of the same as the first generation. What's your view on super cloud as it fits to cloud native as scales up? >>Yeah, you know, I think what's interesting, and I think the reason why Super Cloud is a really good, in a really fit term for this, and I think, I know my CEO was chatting with you as well, and he was mentioning this as well, but I think there needs to be a different term than just multi-cloud or cloud. And the reason is because as cloud native and cloud deployments have scaled, I think we've reached a point now where instead of having the traditional data center style model where you have a few large distributions of infrastructure and workload at a few locations, I think the model is kind of flipped around, right? Where you have a large number of microsites, these microsites could be your public cloud deployment, your private on-prem infrastructure deployments, or it could be your edge environment, right? And every single enterprise, every single industry is moving in that direction. And so you gotta rougher that with a terminology that, that, that indicates the scale and complexity of it. And so I think supercloud is a, is an appropriate term for that. >>So you brought a couple of things I want to dig into. You mentioned edge nodes. We're seeing not only edge nodes being the next kind of area of innovation, mainly because it's just popping up everywhere. And that's just the beginning. Wouldn't even know what's around the corner. You got buildings, you got iot, ot, and IT kind of coming together, but you also got this idea of regions, global infras infrastructures, big part of it. I just saw some news around CloudFlare shutting down a site here. There's policies being made at scale, These new challenges there. Can you share because you can have edge. So hybrid cloud is a winning formula. Everybody knows that it's a steady state. Yeah. But across multiple clouds brings in this new un engineered area, yet it hasn't been done yet. Spanning clouds. People say they're doing it, but you start to see the toe in the water, it's happening, it's gonna happen. It's only gonna get accelerated with the edge and beyond globally. So I have to ask you, what is the technical challenges in doing this? Because there's something business consequences as well, but there are technical challenges. Can you share your view on what the technical challenges are for the super cloud or across multiple edges and regions? >>Yeah, absolutely. So I think, you know, in in the context of this, the, this, this term of super cloud, I think it's sometimes easier to visualize things in terms of two access, right? I think on one end you can think of the scale in terms of just pure number of nodes that you have deploy a number of clusters in the Kubernetes space. And then on the other axis you would have your distribution factor, right? Which is, do you have these tens of thousands of nodes in one site or do you have them distributed across tens of thousands of sites with one node at each site? Right? And if you have just one flavor of this, there is enough complexity, but potentially manageable. But when you are expanding on both these access, you really get to a point where that scale really needs some well thought out, well structured solutions to address it, right? A combination of homegrown tooling along with your, you know, favorite distribution of Kubernetes is not a strategy that can help you in this environment. It may help you when you have one of this or when you, when you scale, is not at the level. >>Can you scope the complexity? Because I mean, I hear a lot of moving parts going on there, the technology's also getting better. We we're seeing cloud native become successful. There's a lot to configure, there's a lot to install. Can you scope the scale of the problem? Because we're talking about at scale Yep. Challenges here. Yeah, >>Absolutely. And I think, you know, I I like to call it, you know, the, the, the problem that the scale creates, you know, there's various problems, but I think one, one problem, one way to think about it is, is, you know, it works on my cluster problem, right? So I, you know, I come from engineering background and there's a, you know, there's a famous saying between engineers and QA and the support folks, right? Which is, it works on my laptop, which is I tested this chain, everything was fantastic, it worked flawlessly on my machine, on production, It's not working. The exact same problem now happens and these distributed environments, but at massive scale, right? Which is that, you know, developers test their applications, et cetera within the sanctity of their sandbox environments. But once you expose that change in the wild world of your production deployment, right? >>And the production deployment could be going at the radio cell tower at the edge location where a cluster is running there, or it could be sending, you know, these applications and having them run at my customer site where they might not have configured that cluster exactly the same way as I configured it, or they configured the cluster, right? But maybe they didn't deploy the security policies, or they didn't deploy the other infrastructure plugins that my app relies on. All of these various factors are their own layer of complexity. And there really isn't a simple way to solve that today. And that is just, you know, one example of an issue that happens. I think another, you know, whole new ball game of issues come in the context of security, right? Because when you are deploying applications at scale in a distributed manner, you gotta make sure someone's job is on the line to ensure that the right security policies are enforced regardless of that scale factor. So I think that's another example of problems that occur. >>Okay. So I have to ask about scale, because there are a lot of multiple steps involved when you see the success of cloud native. You know, you see some, you know, some experimentation. They set up a cluster, say it's containers and Kubernetes, and then you say, Okay, we got this, we can figure it. And then they do it again and again, they call it day two. Some people call it day one, day two operation, whatever you call it. Once you get past the first initial thing, then you gotta scale it. Then you're seeing security breaches, you're seeing configuration errors. This seems to be where the hotspot is in when companies transition from, I got this to, Oh no, it's harder than I thought at scale. Can you share your reaction to that and how you see this playing out? >>Yeah, so, you know, I think it's interesting. There's multiple problems that occur when, you know, the two factors of scale, as we talked about, start expanding. I think one of them is what I like to call the, you know, it, it works fine on my cluster problem, which is back in, when I was a developer, we used to call this, it works on my laptop problem, which is, you know, you have your perfectly written code that is operating just fine on your machine, your sandbox environment. But the moment it runs production, it comes back with p zeros and pos from support teams, et cetera. And those issues can be really difficult to triage us, right? And so in the Kubernetes environment, this problem kind of multi folds, it goes, you know, escalates to a higher degree because you have your sandbox developer environments, they have their clusters and things work perfectly fine in those clusters because these clusters are typically handcrafted or a combination of some scripting and handcrafting. >>And so as you give that change to then run at your production edge location, like say your radio cell tower site, or you hand it over to a customer to run it on their cluster, they might not have not have configured that cluster exactly how you did, or they might not have configured some of the infrastructure plugins. And so the things don't work. And when things don't work, triaging them becomes nightmarishly hard, right? It's just one of the examples of the problem, another whole bucket of issues is security, which is, is you have these distributed clusters at scale, you gotta ensure someone's job is on the line to make sure that these security policies are configured properly. >>So this is a huge problem. I love that comment. That's not not happening on my system. It's the classic, you know, debugging mentality. Yeah. But at scale it's hard to do that with error prone. I can see that being a problem. And you guys have a solution you're launching. Can you share what Arlon is this new product? What is it all about? Talk about this new introduction. >>Yeah, absolutely. Very, very excited. You know, it's one of the projects that we've been working on for some time now because we are very passionate about this problem and just solving problems at scale in on-prem or at in the cloud or at edge environments. And what arlon is, it's an open source project, and it is a tool, it's a Kubernetes native tool for complete end to end management of not just your clusters, but your clusters. All of the infrastructure that goes within and along the site of those clusters, security policies, your middleware, plug-ins, and finally your applications. So what our LA you do in a nutshell is in a declarative way, it lets you handle the configuration and management of all of these components in at scale. >>So what's the elevator pitch simply put for what dissolves in, in terms of the chaos you guys are reigning in, what's the, what's the bumper sticker? Yeah, what >>Would it do? There's a perfect analogy that I love to reference in this context, which is think of your assembly line, you know, in a traditional, let's say, you know, an auto manufacturing factory or et cetera, and the level of efficiency at scale that that assembly line brings, right? Our line, and if you look at the logo we've designed, it's this funny little robot. And it's because when we think of online, we think of these enterprise large scale environments, you know, sprawling at scale, creating chaos because there isn't necessarily a well thought through, well structured solution that's similar to an assembly line, which is taking each component, you know, addressing them, manufacturing, processing them in a standardized way, then handing to the next stage. But again, it gets, you know, processed in a standardized way. And that's what arlon really does. That's like the deliver pitch. If you have problems of scale of managing your infrastructure, you know, that is distributed. Arlon brings the assembly line level of efficiency and consistency for >>Those. So keeping it smooth, the assembly on things are flowing. See c i CD pipe pipelining. Exactly. So that's what you're trying to simplify that ops piece for the developer. I mean, it's not really ops, it's their ops, it's coding. >>Yeah. Not just developer, the ops, the operations folks as well, right? Because developers, you know, there is, developers are responsible for one picture of that layer, which is my apps, and then maybe that middleware of applications that they interface with, but then they hand it over to someone else who's then responsible to ensure that these apps are secure properly, that they are logging, logs are being collected properly, monitoring and observability integrated. And so it solves problems for both >>Those teams. Yeah. It's DevOps. So the DevOps is the cloud needed developer's. That's right. The option teams have to kind of set policies. Is that where the declarative piece comes in? Is that why that's important? >>Absolutely. Yeah. And, and, and, and you know, ES really in introduced or elevated this declarative management, right? Because, you know, s clusters are Yeah. Or your, yeah, you know, specifications of components that go in Kubernetes are defined a declarative way, and Kubernetes always keeps that state consistent with your defined state. But when you go outside of that world of a single cluster, and when you actually talk about defining the clusters or defining everything that's around it, there really isn't a solution that does that today. And so Arlon addresses that problem at the heart of it, and it does that using existing open source well known solutions. >>And do I want to get into the benefits? What's in it for me as the customer developer? But I want to finish this out real quick and get your thoughts. You mentioned open source. Why open source? What's the, what's the current state of the product? You run the product group over at Platform nine, is it open source? And you guys have a product that's commercial? Can you explain the open source dynamic? And first of all, why open source? Yeah. And what is the consumption? I mean, open source is great, People want open source, they can download it, look up the code, but maybe wanna buy the commercial. So I'm assuming you have that thought through, can you share open source and commercial relationship? >>Yeah, I think, you know, starting with why open source? I think it's, you know, we as a company, we have, you know, one of the things that's absolutely critical to us is that we take mainstream open source technologies components and then we, you know, make them available to our customers at scale through either a SaaS model or on-prem model, right? But, so as we are a company or startup or a company that benefits, you know, in a massive way by this open source economy, it's only right, I think in my mind that we do our part of the duty, right? And contribute back to the community that feeds us. And so, you know, we have always held that strongly as one of our principles. And we have, you know, created and built independent products starting all the way with fision, which was a serverless product, you know, that we had built to various other, you know, examples that I can give. But that's one of the main reasons why opensource and also open source, because we want the community to really firsthand engage with us on this problem, which is very difficult to achieve if your product is behind a wall, you know, behind, behind a block box. >>Well, and that's, that's what the developers want too. And what we're seeing in reporting with Super Cloud is the new model of consumption is I wanna look at the code and see what's in there. That's right. And then also, if I want to use it, I'll do it. Great. That's open source, that's the value. But then at the end of the day, if I wanna move fast, that's when people buy in. So it's a new kind of freemium, I guess, business model. I guess that's the way that long. But that's, that's the benefit. Open source. This is why standards and open source is growing so fast. You have that confluence of, you know, a way for developers to try before they buy, but also actually kind of date the application, if you will. We, you know, Adrian Karo uses the dating met metaphor, you know, Hey, you know, I wanna check it out first before I get married. Right? And that's what open source, So this is the new, this is how people are selling. This is not just open source, this is how companies are selling. >>Absolutely. Yeah. Yeah. You know, I think, and you know, two things. I think one is just, you know, this, this, this cloud native space is so vast that if you, if you're building a close flow solution, sometimes there's also a risk that it may not apply to every single enterprises use cases. And so having it open source gives them an opportunity to extend it, expand it, to make it proper to their use case if they choose to do so, right? But at the same time, what's also critical to us is we are able to provide a supported version of it with an SLA that we, you know, that's backed by us, a SAS hosted version of it as well, for those customers who choose to go that route, you know, once they have used the open source version and loved it and want to take it at scale and in production and need, need, need a partner to collaborate with, who can, you know, support them for that production >>Environment. I have to ask you now, let's get into what's in it for the customer. I'm a customer. Yep. Why should I be enthused about Arla? What's in it for me? You know? Cause if I'm not enthused about it, I'm not gonna be confident and it's gonna be hard for me to get behind this. Can you share your enthusiastic view of, you know, why I should be enthused about Arlo? I'm a >>Customer. Yeah, absolutely. And so, and there's multiple, you know, enterprises that we talk to, many of them, you know, our customers, where this is a very kind of typical story that you hear, which is we have, you know, a Kubernetes distribution. It could be on premise, it could be public clouds, native Kubernetes, and then we have our C I C D pipelines that are automating the deployment of applications, et cetera. And then there's this gray zone. And the gray zone is well before you can you, your CS c D pipelines can deploy the apps. Somebody needs to do all of that groundwork of, you know, defining those clusters and yeah. You know, properly configuring them. And as these things, these things start by being done hand grown. And then as the, as you scale, what typically enterprises would do today is they will have their home homegrown DIY solutions for this. >>I mean, the number of folks that I talk to that have built Terra from automation, and then, you know, some of those key developers leave. So it's a typical open source or typical, you know, DIY challenge. And the reason that they're writing it themselves is not because they want to. I mean, of course technology is always interesting to everybody, but it's because they can't find a solution that's out there that perfectly fits the problem. And so that's that pitch. I think Ops FICO would be delighted. The folks that we've talk, you know, spoken with, have been absolutely excited and have, you know, shared that this is a major challenge we have today because we have, you know, few hundreds of clusters on ecos Amazon, and we wanna scale them to few thousands, but we don't think we are ready to do that. And this will give us the >>Ability to, Yeah, I think people are scared. Not sc I won't say scare, that's a bad word. Maybe I should say that they feel nervous because, you know, at scale small mistakes can become large mistakes. This is something that is concerning to enterprises. And, and I think this is gonna come up at co con this year where enterprises are gonna say, Okay, I need to see SLAs. I wanna see track record, I wanna see other companies that have used it. Yeah. How would you answer that question to, or, or challenge, you know, Hey, I love this, but is there any guarantees? Is there any, what's the SLAs? I'm an enterprise, I got tight, you know, I love the open source trying to free fast and loose, but I need hardened code. >>Yeah, absolutely. So, so two parts to that, right? One is Arlan leverages existing open source components, products that are extremely popular. Two specifically. One is Arlan uses Argo cd, which is probably one of the highest and used CD open source tools that's out there. Right's created by folks that are as part of into team now, you know, really brilliant team. And it's used at scale across enterprises. That's one. Second is Alon also makes use of Cluster api cappi, which is a Kubernetes sub-component, right? For lifecycle management of clusters. So there is enough of, you know, community users, et cetera, around these two products, right? Or, or, or open source projects that will find Arlan to be right up in their alley because they're already comfortable, familiar with Argo cd. Now Arlan just extends the scope of what City can do. And so that's one. And then the second part is going back to a point of the comfort. And that's where, you know, platform line has a role to play, which is when you are ready to deploy online at scale, because you've been, you know, playing with it in your DEF test environments, you're happy with what you get with it, then Platform nine will stand behind it and provide that >>Sla. And what's been the reaction from customers you've talked to Platform nine customers with, with that are familiar with, with Argo and then rlo? What's been some of the feedback? >>Yeah, I, I think the feedback's been fantastic. I mean, I can give you examples of customers where, you know, initially, you know, when you are, when you're telling them about your entire portfolio of solutions, it might not strike a card right away. But then we start talking about Arlan and, and we talk about the fact that it uses Argo adn, they start opening up, they say, We have standardized on Argo and we have built these components, homegrown, we would be very interested. Can we co-develop? Does it support these use cases? So we've had that kind of validation. We've had validation all the way at the beginning of our land before we even wrote a single line of code saying this is something we plan on doing. And the customer said, If you had it today, I would've purchased it. So it's been really great validation. >>All right. So next question is, what is the solution to the customer? If I asked you, Look it, I have, I'm so busy, my team's overworked. I got a skills gap. I don't need another project that's, I'm so tied up right now and I'm just chasing my tail. How does Platform nine help me? >>Yeah, absolutely. So I think, you know, one of the core tenets of Platform nine has always been been that we try to bring that public cloud like simplicity by hosting, you know, this in a lot of such similar tools in a SaaS hosted manner for our customers, right? So our goal behind doing that is taking away or trying to take away all of that complexity from customers' hands and offloading it to our hands, right? And giving them that full white glove treatment, as we call it. And so from a customer's perspective, one, something like arlon will integrate with what they have so they don't have to rip and replace anything. In fact, it will, even in the next versions, it may even discover your clusters that you have today and you know, give you an inventory. And that will, >>So if customers have clusters that are growing, that's a sign correct call you guys. >>Absolutely. Either they're, they have massive large clusters, right? That they wanna split into smaller clusters, but they're not comfortable doing that today, or they've done that already on say, public cloud or otherwise. And now they have management challenges. So >>Especially operationalizing the clusters, whether they want to kind of reset everything and remove things around and reconfigure Yep. And or scale out. >>That's right. Exactly. And >>You provide that layer of policy. >>Absolutely. >>Yes. That's the key value here. >>That's right. >>So policy based configuration for cluster scale up, >>Well profile and policy based declarative configuration and lifecycle management for clusters. >>If I asked you how this enables supercloud, what would you say to that? >>I think this is one of the key ingredients to super cloud, right? If you think about a super cloud environment, there's at least few key ingredients that that come to my mind that are really critical. Like they are, you know, life saving ingredients at that scale. One is having a really good strategy for managing that scale, you know, in a, going back to assembly line in a very consistent, predictable way so that our lot solves then you, you need to compliment that with the right kind of observability and monitoring tools at scale, right? Because ultimately issues are gonna happen and you're gonna have to figure out, you know, how to solve them fast. And arlon by the way, also helps in that direction, but you also need observability tools. And then especially if you're running it on the public cloud, you need some cost management tools. In my mind, these three things are like the most necessary ingredients to make Super Cloud successful. And you know, our alarm fills in >>One. Okay. So now the next level is, Okay, that makes sense. Is under the covers kind of speak under the hood. Yeah. How does that impact the app developers and the cloud native modern application workflows? Because the impact to me, seems the apps are gonna be impacted. Are they gonna be faster, stronger? I mean, what's the impact if you do all those things, as you mentioned, what's the impact of the apps? >>Yeah, the impact is that your apps are more likely to operate in production the way you expect them to, because the right checks and balances have gone through, and any discrepancies have been identified prior to those apps, prior to your customer running into them, right? Because developers run into this challenge to their, where there's a split responsibility, right? I'm responsible for my code, I'm responsible for some of these other plugins, but I don't own the stack end to end. I have to rely on my ops counterpart to do their part, right? And so this really gives them, you know, the right tooling for that. >>So this is actually a great kind of relevant point, you know, as cloud becomes more scalable, you're starting to see this fragmentation gone of the days of the full stack developer to the more specialized role. But this is a key point, and I have to ask you because if this RLO solution takes place, as you say, and the apps are gonna be stupid, they're designed to do, the question is, what did does the current pain look like of the apps breaking? What does the signals to the customer Yeah. That they should be calling you guys up into implementing Arlo, Argo and, and all the other goodness to automate? What are some of the signals? Is it downtime? Is it, is it failed apps, Is it latency? What are some of the things that Yeah, absolutely would be indications of things are effed up a little bit. Yeah. >>More frequent down times, down times that are, that take longer to triage. And so you are, you know, the, you know, your mean times on resolution, et cetera, are escalating or growing larger, right? Like we have environments of customers where they're, they have a number of folks on in the field that have to take these apps and run them at customer sites. And that's one of our partners. And they're extremely interested in this because they're the, the rate of failures they're encountering for this, you know, the field when they're running these apps on site, because the field is automating their clusters that are running on sites using their own script. So these are the kinds of challenges, and those are the pain points, which is, you know, if you're looking to reduce your meantime to resolution, if you're looking to reduce the number of failures that occur on your production site, that's one. And second, if you are looking to manage these at scale environments with a relatively small, focused, nimble ops team, which has an immediate impact on your budget. So those are, those are the signals. >>This is the cloud native at scale situation, the innovation going on. Final thought is your reaction to the idea that if the world goes digital, which it is, and the confluence of physical and digital coming together, and cloud continues to do its thing, the company becomes the application, not where it used to be supporting the business, you know, the back office and the maybe terminals and some PCs and handhelds. Now if technology's running, the business is the business. Yeah. Company's the application. Yeah. So it can't be down. So there's a lot of pressure on, on CSOs and CIOs now and boards is saying, How is technology driving the top line revenue? That's the number one conversation. Yep. Do you see that same thing? >>Yeah. It's interesting. I think there's multiple pressures at the CXO CIO level, right? One is that there needs to be that visibility and clarity and guarantee almost that, you know, that the, the technology that's, you know, that's gonna drive your top line is gonna drive that in a consistent, reliable, predictable manner. And then second, there is the constant pressure to do that while always lowering your costs of doing it, right? Especially when you're talking about, let's say retailers or those kinds of large scale vendors, they many times make money by lowering the amount that they spend on, you know, providing those goods to their end customers. So I think those, both those factors kind of come into play and the solution to all of them is usually in a very structured strategy around automation. >>Final question. What does cloudnative at scale look like to you? If all the things happen the way we want 'em to happen, The magic wand, the magic dust, what does it look like? >>What that looks like to me is a CIO sipping at his desk on coffee production is running absolutely smooth. And his, he's running that at a nimble, nimble team size of at the most, a handful of folks that are just looking after things, but things are >>Just taking care of the CIO doesn't exist. There's no ciso, they're at the beach. >>Yep. >>Thank you for coming on, sharing the cloud native at scale here on the cube. Thank you for your time. >>Fantastic. Thanks for >>Having me. Okay. I'm John Fur here for special program presentation, special programming cloud native at scale, enabling super cloud modern applications with Platform nine. Thanks for watching. Welcome back everyone to the special presentation of cloud native at scale, the cube and platform nine special presentation going in and digging into the next generation super cloud infrastructure as code and the future of application development. We're here with Bickley, who's the chief architect and co-founder of Platform nine Pick. Great to see you Cube alumni. We, we met at an OpenStack event in about eight years ago, or later, earlier when OpenStack was going. Great to see you and great to see congratulations on the success of platform nine. >>Thank you very much. >>Yeah. You guys have been at this for a while and this is really the, the, the year we're seeing the, the crossover of Kubernetes because of what happens with containers. Everyone now has realized, and you've seen what Docker's doing with the new docker, the open source Docker now just the success Exactly. Of containerization, right? And now the Kubernetes layer that we've been working on for years is coming, bearing fruit. This is huge. >>Exactly. Yes. >>And so as infrastructures code comes in, we talked to Bacar talking about Super Cloud, I met her about, you know, the new Arlon, our, our lawn, and you guys just launched the infrastructures code is going to another level, and then it's always been DevOps infrastructures code. That's been the ethos that's been like from day one, developers just code. Then you saw the rise of serverless and you see now multi-cloud or on the horizon, connect the dots for us. What is the state of infrastructure as code today? >>So I think, I think I'm, I'm glad you mentioned it, everybody or most people know about infrastructures code. But with Kubernetes, I think that project has evolved at the concept even further. And these dates, it's infrastructure is configuration, right? So, which is an evolution of infrastructure as code. So instead of telling the system, here's how I want my infrastructure by telling it, you know, do step A, B, C, and D instead with Kubernetes, you can describe your desired state declaratively using things called manifest resources. And then the system kind of magically figures it out and tries to converge the state towards the one that you specified. So I think it's, it's a even better version of infrastructures code. >>Yeah. And that really means it's developer just accessing resources. Okay. That declare, Okay, give me some compute, stand me up some, turn the lights on, turn 'em off, turn 'em on. That's kind of where we see this going. And I like the configuration piece. Some people say composability, I mean now with open source so popular, you don't have to have to write a lot of code, this code being developed. And so it's into integration, it's configuration. These are areas that we're starting to see computer science principles around automation, machine learning, assisting open source. Cuz you got a lot of code that's right in hearing software, supply chain issues. So infrastructure as code has to factor in these new dynamics. Can you share your opinion on these new dynamics of, as open source grows, the glue layers, the configurations, the integration, what are the core issues? >>I think one of the major core issues is with all that power comes complexity, right? So, you know, despite its expressive power systems like Kubernetes and declarative APIs let you express a lot of complicated and complex stacks, right? But you're dealing with hundreds if not thousands of these yamo files or resources. And so I think, you know, the emergence of systems and layers to help you manage that complexity is becoming a key challenge and opportunity in, in this space. >>That's, I wrote a LinkedIn post today was comments about, you know, hey, enterprise is a new breed. The trend of SaaS companies moving our consumer comp consumer-like thinking into the enterprise has been happening for a long time, but now more than ever, you're seeing it the old way used to be solve complexity with more complexity and then lock the customer in. Now with open source, it's speed, simplification and integration, right? These are the new dynamic power dynamics for developers. Yeah. So as companies are starting to now deploy and look at Kubernetes, what are the things that need to be in place? Because you have some, I won't say technical debt, but maybe some shortcuts, some scripts here that make it look like infrastructure is code. People have done some things to simulate or or make infrastructure as code happen. Yes. But to do it at scale Yes. Is harder. What's your take on this? What's your view? >>It's hard because there's a per proliferation of methods, tools, technologies. So for example, today it's very common for DevOps and platform engineering tools, I mean, sorry, teams to have to deploy a large number of Kubernetes clusters, but then apply the applications and configurations on top of those clusters. And they're using a wide range of tools to do this, right? For example, maybe Ansible or Terraform or bash scripts to bring up the infrastructure and then the clusters. And then they may use a different set of tools such as Argo CD or other tools to apply configurations and applications on top of the clusters. So you have this sprawl of tools. You, you also have this sprawl of configurations and files because the more objects you're dealing with, the more resources you have to manage. And there's a risk of drift that people call that where, you know, you think you have things under control, but some people from various teams will make changes here and there and then before the end of the day systems break and you have no idea of tracking them. So I think there's real need to kind of unify, simplify, and try to solve these problems using a smaller, more unified set of tools and methodologies. And that's something that we try to do with this new project. Arlon. >>Yeah. So, so we're gonna get into Arlan in a second. I wanna get into the why Arlon. You guys announced that at AR GoCon, which was put on here in Silicon Valley at the, at the community meeting by in two, they had their own little day over there at their headquarters. But before we get there, vascar, your CEO came on and he talked about Super Cloud at our in AAL event. What's your definition of super cloud? If you had to kind of explain that to someone at a cocktail party or someone in the industry technical, how would you look at the super cloud trend that's emerging? It's become a thing. What's your, what would be your contribution to that definition or the narrative? >>Well, it's, it's, it's funny because I've actually heard of the term for the first time today, speaking to you earlier today. But I think based on what you said, I I already get kind of some of the, the gist and the, the main concepts. It seems like super cloud, the way I interpret that is, you know, clouds and infrastructure, programmable infrastructure, all of those things are becoming commodity in a way. And everyone's got their own flavor, but there's a real opportunity for people to solve real business problems by perhaps trying to abstract away, you know, all of those various implementations and then building better abstractions that are perhaps business or applications specific to help companies and businesses solve real business problems. >>Yeah, I remember that's a great, great definition. I remember, not to date myself, but back in the old days, you know, IBM had a proprietary network operating system, so of deck for the mini computer vendors, deck net and SNA respectively. But T C P I P came out of the osi, the open systems interconnect and remember, ethernet beat token ring out. So not to get all nerdy for all the young kids out there, look, just look up token ring, you'll see, you've probably never heard of it. It's IBM's, you know, connection for the internet at the, the layer two is Amazon, the ethernet, right? So if T C P I P could be the Kubernetes and the container abstraction that made the industry completely change at that point in history. So at every major inflection point where there's been serious industry change and wealth creation and business value, there's been an abstraction Yes. Somewhere. Yes. What's your reaction to that? >>I think this is, I think a saying that's been heard many times in this industry and, and I forgot who originated it, but I think that the saying goes like, there's no problem that can't be solved with another layer of indirection, right? And we've seen this over and over and over again where Amazon and its peers have inserted this layer that has simplified, you know, computing and, and infrastructure management. And I believe this trend is going to continue, right? The next set of problems are going to be solved with these insertions of additional abstraction layers. I think that that's really a, yeah, it's gonna >>Continue. It's interesting. I just, when I wrote another post today on LinkedIn called the Silicon Wars AMD stock is down arm has been on a rise. We remember pointing for many years now that arm's gonna be hugely, it has become true. If you look at the success of the infrastructure as a service layer across the clouds, Azure, aws, Amazon's clearly way ahead of everybody. The stuff that they're doing with the silicon and the physics and the, the atoms, the pro, you know, this is where the innovation, they're going so deep and so strong at ISAs, the more that they get that gets come on, they have more performance. So if you're an app developer, wouldn't you want the best performance and you'd wanna have the best abstraction layer that gives you the most ability to do infrastructures, code or infrastructure for configuration, for provisioning, for managing services. And you're seeing that today with service MeSHs, a lot of action going on in the service mesh area in in this community of, of co con, which will be a covering. So that brings up the whole what's next? You guys just announced our lawn at Argo Con, which came out of Intuit. We've had Mariana Tessel at our super cloud event. She's the cto, you know, they're all in the cloud. So they contributed that project. Where did Arlon come from? What was the origination? What's the purpose? Why our lawn, why this announcement? >>Yeah, so the, the inception of the project, this was the result of us realizing that problem that we spoke about earlier, which is complexity, right? With all of this, these clouds, these infrastructure, all the variations around and, you know, compute storage networks and the proliferation of tools we talked about the Ansibles and Terraforms and Kubernetes itself. You can, you can think of that as another tool, right? We saw a need to solve that complexity problem, and especially for people and users who use Kubernetes at scale. So when you have, you know, hundreds of clusters, thousands of applications, thousands of users spread out over many, many locations, there, there needs to be a system that helps simplify that management, right? So that means fewer tools, more expressive ways of describing the state that you want and more consistency. And, and that's why, you know, we built our lawn and we built it recognizing that many of these problems or sub problems have already been solved. So Arlon doesn't try to reinvent the wheel, it instead rests on the shoulders of several giants, right? So for example, Kubernetes is one building block, GI ops, and Argo CD is another one, which provides a very structured way of applying configuration. And then we have projects like cluster API and cross plane, which provide APIs for describing infrastructure. So arlon takes all of those building blocks and builds a thin layer, which gives users a very expressive way of defining configuration and desired state. So that's, that's kind of the inception of, And >>What's the benefit of that? What does that give the, what does that give the developer, the user, in this case, >>The developers, the, the platform engineer, team members, the DevOps engineers, they get a a ways to provision not just infrastructure and clusters, but also applications and configurations. They get a way, a system for provisioning, configuring, deploying, and doing life cycle management in a, in a much simpler way. Okay. Especially as I said, if you're dealing with a large number of applications. >>So it's like an operating fabric, if you will. Yes. For them. Okay, so let's get into what that means for up above and below the the, this abstraction or thin layer below as the infrastructure. We talked a lot about what's going on below that. Yeah. Above our workloads. At the end of the day, you know, I talk to CXOs and IT folks that are now DevOps engineers. They care about the workloads and they want the infrastructures code to work. They wanna spend their time getting in the weeds, figuring out what happened when someone made a push that that happened or something happened. They need observability and they need to, to know that it's working. That's right. And is my workloads running effectively? So how do you guys look at the workload side of it? Cuz now you have multiple workloads on these fabric, >>Right? So workloads, so Kubernetes has defined kind of a standard way to describe workloads and you can, you know, tell Kubernetes, I want to run this container this particular way, or you can use other projects that are in the Kubernetes cloud native ecosystem like K native, where you can express your application in more at a higher level, right? But what's also happening is in addition to the workloads, DevOps and platform engineering teams, they need to very often deploy the applications with the clusters themselves. Clusters are becoming this commodity. It's, it's becoming this host for the application and it kind of comes bundled with it. In many cases it is like an appliance, right? So DevOps teams have to provision clusters at a really incredible rate and they need to tear them down. Clusters are becoming more, >>It's kinda like an EC two instance, spin up a cluster. We very, people used words like that. That's >>Right. And before arlon you kind of had to do all of that using a different set of tools as, as I explained. So with Armon you can kind of express everything together. You can say I want a cluster with a health monitoring stack and a logging stack and this ingress controller and I want these applications and these security policies. You can describe all of that using something we call a profile. And then you can stamp out your app, your applications and your clusters and manage them in a very, so >>Essentially standard creates a mechanism. Exactly. Standardized, declarative kind of configurations. And it's like a playbook. You deploy it. Now what's there is between say a script like I'm, I have scripts, I could just automate scripts >>Or yes, this is where that declarative API and infrastructures configuration comes in, right? Because scripts, yes you can automate scripts, but the order in which they run matters, right? They can break, things can break in the middle and, and sometimes you need to debug them. Whereas the declarative way is much more expressive and powerful. You just tell the system what you want and then the system kind of figures it out. And there are these things about controllers which will in the background reconcile all the state to converge towards your desire. It's a much more powerful, expressive and reliable way of getting things done. >>So infrastructure has configuration is built kind of on, it's as super set of infrastructures code because it's >>An evolution. >>You need edge's code, but then you can configure the code by just saying do it. You basically declaring and saying Go, go do that. That's right. Okay, so, alright, so cloud native at scale, take me through your vision of what that means. Someone says, Hey, what does cloud native at scale mean? What's success look like? How does it roll out in the future as you, not future next couple years? I mean people are now starting to figure out, okay, it's not as easy as it sounds. Could be nice, it has value. We're gonna hear this year coan a lot of this. What does cloud native at scale >>Mean? Yeah, there are different interpretations, but if you ask me, when people think of scale, they think of a large number of deployments, right? Geographies, many, you know, supporting thousands or tens or millions of, of users there, there's that aspect to scale. There's also an equally important a aspect of scale, which is also something that we try to address with Arran. And that is just complexity for the people operating this or configuring this, right? So in order to describe that desired state and in order to perform things like maybe upgrades or updates on a very large scale, you want the humans behind that to be able to express and direct the system to do that in, in relatively simple terms, right? And so we want the tools and the abstractions and the mechanisms available to the user to be as powerful but as simple as possible. So there's, I think there's gonna be a number and there have been a number of CNCF and cloud native projects that are trying to attack that complexity problem as well. And Arlon kind of falls in in that >>Category. Okay, so I'll put you on the spot road that CubeCon coming up and obviously this will be shipping this segment series out before. What do you expect to see at Coan this year? What's the big story this year? What's the, what's the most important thing happening? Is it in the open source community and also within a lot of the, the people jogging for leadership. I know there's a lot of projects and still there's some white space in the overall systems map about the different areas get run time and there's ability in all these different areas. What's the, where's the action? Where, where's the smoke? Where's the fire? Where's the piece? Where's the tension? >>Yeah, so I think one thing that has been happening over the past couple of cons and I expect to continue and, and that is the, the word on the street is Kubernetes is getting boring, right? Which is good, right? >>Boring means simple. >>Well, well >>Maybe, >>Yeah, >>Invisible, >>No drama, right? So, so the, the rate of change of the Kubernetes features and, and all that has slowed but in, in a, in a positive way. But there's still a general sentiment and feeling that there's just too much stuff. If you look at a stack necessary for hosting applications based on Kubernetes, there are just still too many moving parts, too many components, right? Too much complexity. I go, I keep going back to the complexity problem. So I expect Cube Con and all the vendors and the players and the startups and the people there to continue to focus on that complexity problem and introduce further simplifications to, to the stack. >>Yeah. Vic, you've had an storied career, VMware over decades with them obviously in 12 years with 14 years or something like that. Big number co-founder here at Platform. Now you guys have been around for a while at this game. We, man, we talked about OpenStack, that project you, we interviewed at one of their events. So OpenStack was the beginning of that, this new revolution. And I remember the early days it was, it wasn't supposed to be an alternative to Amazon, but it was a way to do more cloud cloud native. I think we had a cloud ERO team at that time. We would to joke we, you know, about, about the dream. It's happening now, now at Platform nine. You guys have been doing this for a while. What's the, what are you most excited about as the chief architect? What did you guys double down on? What did you guys tr pivot from or two, did you do any pivots? Did you extend out certain areas? Cuz you guys are in a good position right now, a lot of DNA in Cloud native. What are you most excited about and what does Platform nine bring to the table for customers and for people in the industry watching this? >>Yeah, so I think our mission really hasn't changed over the years, right? It's been always about taking complex open source software because open source software, it's powerful. It solves new problems, you know, every year and you have new things coming out all the time, right? OpenStack was an example when the Kubernetes took the world by storm. But there's always that complexity of, you know, just configuring it, deploying it, running it, operating it. And our mission has always been that we will take all that complexity and just make it, you know, easy for users to consume regardless of the technology, right? So the successor to Kubernetes, you know, I don't have a crystal ball, but you know, you have some indications that people are coming up of new and simpler ways of running applications. There are many projects around there who knows what's coming next year or the year after that. But platform will a, platform nine will be there and we will, you know, take the innovations from the the community. We will contribute our own innovations and make all of those things very consumable to customers. >>Simpler, faster, cheaper. Exactly. Always a good business model technically to make that happen. Yes. Yeah, I think the, the reigning in the chaos is key, you know, Now we have now visibility into the scale. Final question before we depart this segment. What is at scale, how many clusters do you see that would be a watermark for an at scale conversation around an enterprise? Is it workloads we're looking at or, or clusters? How would you, Yeah, how would you describe that? When people try to squint through and evaluate what's a scale, what's the at scale kind of threshold? >>Yeah. And, and the number of clusters doesn't tell the whole story because clusters can be small in terms of the number of nodes or they can be large. But roughly speaking when we say, you know, large scale cluster deployments, we're talking about maybe hundreds, two thousands. >>Yeah. And final final question, what's the role of the hyperscalers? You got AWS continuing to do well, but they got their core ias, they got a PAs, they're not too too much putting a SaaS out there. They have some SaaS apps, but mostly it's the ecosystem. They have marketplaces doing over $2 billion billions of transactions a year and, and it's just like, just sitting there. It hasn't really, they're now innovating on it, but that's gonna change ecosystems. What's the role the cloud play in the cloud native of its scale? >>The, the hyperscalers, >>Yeahs Azure, Google. >>You mean from a business perspective? Yeah, they're, they have their own interests that, you know, that they're, they will keep catering to, they, they will continue to find ways to lock their users into their ecosystem of services and, and APIs. So I don't think that's gonna change, right? They're just gonna keep, >>Well they got great I performance, I mean from a, from a hardware standpoint, yes, that's gonna be key, right? >>Yes. I think the, the move from X 86 being the dominant way and platform to run workloads is changing, right? That, that, that, that, and I think the, the hyperscalers really want to be in the game in terms of, you know, the the new risk and arm ecosystems and the platforms. >>Yeah, not joking aside, Paul Morritz, when he was the CEO of VMware, when he took over once said, I remember our first year doing the cube. Oh the cloud is one big distributed computer, it's, it's hardware and he got software and you got middleware and he kind over, well he's kind of tongue in cheek, but really you're talking about large compute and sets of services that is essentially a distributed computer. >>Yes, >>Exactly. It's, we're back on the same game. Vic, thank you for coming on the segment. Appreciate your time. This is cloud native at scale special presentation with Platform nine. Really unpacking super cloud Arlon open source and how to run large scale applications on the cloud Cloud Native Phil for developers and John Furrier with the cube. Thanks for Washington. We'll stay tuned for another great segment coming right up. Hey, welcome back everyone to Super Cloud 22. I'm John Fur, host of the Cuba here all day talking about the future of cloud. Where's it all going? Making it super multi-cloud clouds around the corner and public cloud is winning. Got the private cloud on premise and edge. Got a great guest here, Vascar Gorde, CEO of Platform nine, just on the panel on Kubernetes. An enabler blocker. Welcome back. Great to have you on. >>Good to see you >>Again. So Kubernetes is a blocker enabler by, with a question mark. I put on on that panel was really to discuss the role of Kubernetes. Now great conversation operations is impacted. What's interest thing about what you guys are doing at Platform nine? Is your role there as CEO and the company's position, kind of like the world spun into the direction of Platform nine while you're at the helm? Yeah, right. >>Absolutely. In fact, things are moving very well and since they came to us, it was an insight to call ourselves the platform company eight years ago, right? So absolutely whether you are doing it in public clouds or private clouds, you know, the application world is moving very fast in trying to become digital and cloud native. There are many options for you do on the infrastructure. The biggest blocking factor now is having a unified platform. And that's what we, we come into, >>Patrick, we were talking before we came on stage here about your background and we were gonna talk about the glory days in 2000, 2001, when the first as piece application service providers came out, kind of a SaaS vibe, but that was kind of all kind of cloudlike. >>It wasn't, >>And and web services started then too. So you saw that whole growth. Now, fast forward 20 years later, 22 years later, where we are now, when you look back then to here and all the different cycles, >>I, in fact you, you know, as we were talking offline, I was in one of those ASPs in the year 2000 where it was a novel concept of saying we are providing a software and a capability as a service, right? You sign up and start using it. I think a lot has changed since then. The tooling, the tools, the technology has really skyrocketed. The app development environment has really taken off exceptionally well. There are many, many choices of infrastructure now, right? So I think things are in a way the same but also extremely different. But more importantly now for any company, regardless of size, to be a digital native, to become a digital company is extremely mission critical. It's no longer a nice to have everybody's in the journey somewhere. >>Everyone is going digital transformation here. Even on a so-called downturn recession that's upcoming inflation's here. It's interesting. This is the first downturn in the history of the world where the hyperscale clouds have been pumping on all cylinders as an economic input. And if you look at the tech trends, GDPs down, but not tech. >>Nope. >>Cuz the pandemic showed everyone digital transformation is here and more spend and more growth is coming even in, in tech. So this is a unique factor which proves that that digital transformation's happening and company, every company will need a super cloud. >>Everyone, every company, regardless of size, regardless of location, has to become modernize their infrastructure. And modernizing Infras infrastructure is not just some new servers and new application tools, It's your approach, how you're serving your customers, how you're bringing agility in your organization. I think that is becoming a necessity for every enterprise to survive. >>I wanna get your thoughts on Super Cloud because one of the things Dave Ante and I want to do with Super Cloud and calling it that was we, I, I personally, and I know Dave as well, he can, I'll speak from, he can speak for himself. We didn't like multi-cloud. I mean not because Amazon said don't call things multi-cloud, it just didn't feel right. I mean everyone has multiple clouds by default. If you're running productivity software, you have Azure and Office 365. But it wasn't truly distributed. It wasn't truly decentralized, it wasn't truly cloud enabled. It didn't, it felt like they're not ready for a market yet. Yet public clouds booming on premise. Private cloud and Edge is much more on, you know, more, more dynamic, more real. >>Yeah. I think the reason why we think super cloud is a better term than multi-cloud. Multi-cloud are more than one cloud, but they're disconnected. Okay, you have a productivity cloud, you have a Salesforce cloud, you may have, everyone has an internal cloud, right? So, but they're not connected. So you can say okay, it's more than one cloud. So it's you know, multi-cloud. But super cloud is where you are actually trying to look at this holistically. Whether it is on-prem, whether it is public, whether it's at the edge, it's a store at the branch. You are looking at this as one unit. And that's where we see the term super cloud is more applicable because what are the qualities that you require if you're in a super cloud, right? You need choice of infrastructure, you need, but at the same time you need a single pain, a single platform for you to build your innovations on regardless of which cloud you're doing it on, right? So I think Super Cloud is actually a more tightly integrated orchestrated management philosophy we think. >>So let's get into some of the super cloud type trends that we've been reporting on. Again, the purpose of this event is to, as a pilots, to get the conversations flowing with with the influencers like yourselves who are running companies and building products and the builders, Amazon and Azure are doing extremely well. Google's coming up in third cloudworks in public cloud. We see the use cases on premises use cases. Kubernetes has been an interesting phenomenon because it's become from the developer side a little bit, but a lot of ops people love Kubernetes. It's really more of an ops thing. You mentioned OpenStack earlier. Kubernetes kind of came out of that open stack. We need an orchestration and then containers had a good shot with, with Docker. They re pivoted the company. Now they're all in an open source. So you got containers booming and Kubernetes as a new layer there. What's the, what's the take on that? What does that really mean? Is that a new defacto enabler? It >>Is here. It's for here for sure. Every enterprise somewhere else in the journey is going on. And you know, most companies are, 70 plus percent of them have won two, three container based, Kubernetes based applications now being rolled out. So it's very much here, it is in production at scale by many customers. And the beauty of it is, yes, open source, but the biggest gating factor is the skill set. And that's where we have a phenomenal engineering team, right? So it's, it's one thing to buy a tool >>And just be clear, you're a managed service for Kubernetes. >>We provide, provide a software platform for cloud acceleration as a service and it can run anywhere. It can run in public private. We have customers who do it in truly multi-cloud environments. It runs on the edge, it runs at this in stores are thousands of stores in a retailer. So we provide that and also for specific segments where data sovereignty and data residency are key regulatory reasons. We also un OnPrem as an air gap version. >>Can you give an example on how you guys are deploying your platform to enable a super cloud experience for your >>Customer? Right. So I'll give you two different examples. One is a very large networking company, public networking company. They have, I dunno, hundreds of products, hundreds of r and d teams that are building different, different products. And if you look at few years back, each one was doing it on a different platforms but they really needed to bring the agility and they worked with us now over three years where we are their build test dev pro platform where all their products are built on, right? And it has dramatically increased their agility to release new products. Number two, it actually is a light out operation. In fact the customer says like, like the Maytag service person cuz we provide it as a service and it barely takes one or two people to maintain it for them. >>So it's kinda like an SRE vibe. One person managing a >>Large 4,000 engineers building infrastructure >>On their tools, >>Whatever they want on their tools. They're using whatever app development tools they use, but they use our platform. >>What benefits are they seeing? Are they seeing speed? >>Speed, definitely. Okay. Definitely they're speeding. Speed uniformity because now they're building able to build, so their customers who are using product A and product B are seeing a similar set of tools that are being used. >>So a big problem that's coming outta this super cloud event that we're, we're seeing and we've heard it all here, ops and security teams cuz they're kind of too part of one theme, but ops and security specifically need to catch up speed wise. Are you delivering that value to ops and security? Right. >>So we, we work with ops and security teams and infrastructure teams and we layer on top of that. We have like a platform team. If you think about it, depending on where you have data centers, where you have infrastructure, you have multiple teams, okay, but you need a unified platform. Who's your buyer? Our buyer is usually, you know, the product divisions of companies that are looking at or the CTO would be a buyer for us functionally cio definitely. So it it's, it's somewhere in the DevOps to infrastructure. But the ideal one we are beginning to see now many large corporations are really looking at it as a platform and saying we have a platform group on which any app can be developed and it is run on any infrastructure. So the platform engineering teams, >>You working two sides of that coin. You've got the dev side and then >>And then infrastructure >>Side side, okay. >>Another customer like give you an example, which I would say is kind of the edge of the store. So they have thousands of stores. Retail, retail, you know food retailer, right? They have thousands of stores that are on the globe, 50,000, 60,000. And they really want to enhance the customer experience that happens when you either order the product or go into the store and pick up your product or buy or browse or sit there. They have applications that were written in the nineties and then they have very modern AIML applications today. They want something that will not have to send an IT person to install a rack in the store or they can't move everything to the cloud because the store operations has to be local. The menu changes based on, It's a classic edge. It's classic edge. Yeah. Right. They can't send it people to go install rack access servers then they can't sell software people to go install the software and any change you wanna put through that, you know, truck roll. So they've been working with us where all they do is they ship, depending on the size of the store, one or two or three little servers with instructions that >>You, you say little servers like how big one like a net box box, like a small little >>Box and all the person in the store has to do like what you and I do at home and we get a, you know, a router is connect the power, connect the internet and turn the switch on. And from there we pick it up. >>Yep. >>We provide the operating system, everything and then the applications are put on it. And so that dramatically brings the velocity for them. They manage >>Thousands of them. True plug and play >>Two, plug and play thousands of stores. They manage it centrally. We do it for them, right? So, so that's another example where on the edge then we have some customers who have both a large private presence and one of the public clouds. Okay. But they want to have the same platform layer of orchestration and management that they can use regardless of the location. So >>You guys got some success. Congratulations. Got some traction there. It's awesome. The question I want to ask you is that's come up is what is truly cloud native? Cuz there's lift and shift of the cloud >>That's not cloud native. >>Then there's cloud native. Cloud native seems to be the driver for the super cloud. How do you talk to customers? How do you explain when someone says what's cloud native, what isn't cloud native? >>Right. Look, I think first of all, the best place to look at what is the definition and what are the attributes and characteristics of what is truly a cloud native, is CNC foundation. And I think it's very well documented where you, well >>Con of course Detroit's >>Coming here, so, so it's already there, right? So, so we follow that very closely, right? I think just lifting and shifting your 20 year old application onto a data center somewhere is not cloud native. Okay? You can't put to cloud native, you have to rewrite and redevelop your application and business logic using modern tools. Hopefully more open source and, and I think that's what Cloudnative is and we are seeing a lot of our customers in that journey. Now everybody wants to be cloudnative, but it's not that easy, okay? Because it's, I think it's first of all, skill set is very important. Uniformity of tools that there's so many tools there. Thousands and thousands of tools you could spend your time figuring out which tool to use. Okay? So I think the complexities there, but the business benefits of agility and uniformity and customer experience are truly them. >>And I'll give you an example. I don't know how clear native they are, right? And they're not a customer of ours, but you order pizzas, you do, right? If you just watch the pizza industry, how dominoes actually increase their share and mind share and wallet share was not because they were making better pizzas or not, I don't know anything about that, but the whole experience of how you order, how you watch what's happening, how it's delivered. There were a pioneer in it. To me, those are the kinds of customer experiences that cloud native can provide. >>Being agility and having that flow to the application changes what the expectations of the, for the customer. >>Customer, the customer's expectations change, right? Once you get used to a better customer experience, you learn >>Best car. To wrap it up, I wanna just get your perspective again. One of the benefits of chatting with you here and having you part of the Super Cloud 22 is you've seen many cycles, you have a lot of insights. I want to ask you, given your career where you've been and what you've done and now the CEO platform nine, how would you compare what's happening now with other inflection points in the industry? And you've been, again, you've been an entrepreneur, you sold your company to Oracle, you've been seeing the big companies, you've seen the different waves. What's going on right now put into context this moment in time around Super >>Cloud. Sure. I think as you said, a lot of battles. Cars being been, been in an asp, been in a realtime software company, being in large enterprise software houses and a transformation. I've been on the app side, I did the infrastructure right and then tried to build our own platforms. I've gone through all of this myself with a lot of lessons learned in there. I think this is an event which is happening now for companies to go through to become cloud native and digitalize. If I were to look back and look at some parallels of the tsunami that's going on is a couple of paddles come to me. One is, think of it, which was forced to honors like y2k. Everybody around the world had to have a plan, a strategy, and an execution for y2k. I would say the next big thing was e-commerce. I think e-commerce has been pervasive right across all industries. >>And disruptive. >>And disruptive, extremely disruptive. If you did not adapt and adapt and accelerate your e-commerce initiative, you were, it was an existence question. Yeah. I think we are at that pivotal moment now in companies trying to become digital and cloudnative that know that is what I see >>Happening there. I think that that e-commerce was interesting and I think just to riff with you on that is that it's disrupting and refactoring the business models. I think that is something that's coming out of this is that it's not just completely changing the game, it's just changing how you operate, >>How you think, and how you operate. See, if you think about the early days of eCommerce, just putting up a shopping cart didn't made you an eCommerce or an E retailer or an e e customer, right? Or so. I think it's the same thing now is I think this is a fundamental shift on how you're thinking about your business. How are you gonna operate? How are you gonna service your customers? I think it requires that just lift and shift is not gonna work. >>Mascar, thank you for coming on, spending the time to come in and share with our community and being part of Super Cloud 22. We really appreciate, we're gonna keep this open. We're gonna keep this conversation going even after the event, to open up and look at the structural changes happening now and continue to look at it in the open in the community. And we're gonna keep this going for, for a long, long time as we get answers to the problems that customers are looking for with cloud cloud computing. I'm Sean Feer with Super Cloud 22 in the Cube. Thanks for watching. >>Thank you. Thank you, John. >>Hello. Welcome back. This is the end of our program, our special presentation with Platform nine on cloud native at scale, enabling the super cloud. We're continuing the theme here. You heard the interviews Super Cloud and its challenges, new opportunities around the solutions around like Platform nine and others with Arlon. This is really about the edge situations on the internet and managing the edge multiple regions, avoiding vendor lock in. This is what this new super cloud is all about. The business consequences we heard and and the wide ranging conversations around what it means for open source and the complexity problem all being solved. I hope you enjoyed this program. There's a lot of moving pieces and things to configure with cloud native install, all making it easier for you here with Super Cloud and of course Platform nine contributing to that. Thank you for watching.

(upbeat music) >> Hello, and welcome to theCUBE here in Palo Alto, California, for a special program on Cloud Native at Scale, Enabling Next Generation Cloud or Supercloud for Modern Application Cloud Native Developers. I'm John Furrier, host of theCUBE. My pleasure to have here, me Madhura Maskasky, Co-founder and VP of Product at Platform9. Thanks for coming in today for this cloud native at scale conversation. >> Thank you for having me. >> So cloud native at scale, something that we're talking about because we're seeing the next level of mainstream success of containers, Kubernetes and cloud native develop, basically DevOps in the CI/CD pipeline. It's changing the landscape of infrastructure as code. It's accelerating the value proposition. And the Supercloud as we call it, has been getting a lot of traction because this next generation cloud is looking a lot different, but kind of the same as the first generation. What's your view on Supercloud as it fits to cloud native, it scales up. >> Yeah, you know, I think what's interesting. And I think the reason why Supercloud is a really good and a really fit term for this. And I think I know my CEO was chatting with you as well, and he was mentioning this as well, but I think there needs to be a different term than just multicloud or cloud. And the reason is because as cloud native and cloud deployments have scaled, I think we've reached a point now where instead of having the traditional data center style model, where you have a few large distributions of infrastructure and workload at a few locations, I think the model's kind of flipped around, right? Where you have a large number of micro-sites. These micro-sites could be your public cloud deployment, your private OnPrem infrastructure deployment, or it could be your Edge environment, right? And every single enterprise, every single industry is moving in that direction. And so you got to refer that with a terminology that indicates the scale and complexity of it. And so I think Supercloud is an appropriate term for that. >> So you brought a couple things I want to dig into. You mentioned Edge nodes. We're seeing not only Edge nodes being the next kind of area of innovation, mainly because it's just popping up everywhere. And that's just the beginning, wouldn't even know what's around the corner. You got buildings, you got IoT, OT and IT kind of coming together, but you also got this idea of regions. Global infrastructure is a big part of it. I just saw some news around CloudFlare shutting down a site here. There's policies being made at scale, these new challenges there. Can you share, because you got to have Edge. So hybrid cloud is a winning formula. Everybody knows that, it's a steady state. But across multiple clouds brings in this new un-engineered area yet, It hasn't been done yet, Spanning Clouds. People say they're doing it, but you start to see the toe in the water. It's happening, it's going to happen. It's only going to get accelerated with the Edge and beyond globally. So I have to ask you, what is the technical challenges in doing this? Because there's something, business consequences as well, but there are technical challenges. Can you share your view on what the technical challenges are for the Supercloud across multiple edges and regions? >> Yeah, absolutely. So I think, you know, in the context of this term of Supercloud, I think it's sometimes easier to visualize things in terms of two axis, right? I think on one end you can think of the scale in terms of just pure number of nodes that you have deployed, a number of clusters in the Kubernetes space. And then on the other axis, you would have your distribution factor, right? Which is, do you have these tens of thousands of nodes in one site, or do you have them distributed across tens of thousands of sites, with one node at each site, right? And if you have just one flare of this, there is enough complexity, but potentially manageable. But when you are expanding on both these axis, you really get to a point where that scale really needs some well thought out, well structured solutions to address it, right? A combination of homegrown tooling, along with your, you know, favorite distribution of Kubernetes is not a strategy that can help you in this environment. It may help you when you have one of this, or when your scale is not at the level. >> Can you scope the complexity? Because, I mean, I hear a lot of moving parts going on there. The technology is also getting better. We're seeing cloud native become successful. There's a lot to configure. There's lot to install. Can you scope the scale of the problem because we're about at scale challenges here. >> Yeah absolutely, and I think I like to call it, you know, the problem that the scale creates, there's various problems. But I think one problem, one way to think about it is it works on my cluster problem, right? So, you know, I come from engineering background and there's a famous saying between engineers and QA, and the support folks, right. Which is, it works on my laptop, which is I tested this change, everything was fantastic. It worked flawlessly on my machine. On production, it's not working. The exact same problem now happens in these distributed environments, but at massive scale, right. Which is that, you know, developers test their applications, et cetera within these sanctity of their sandbox environments. But once you expose that change in the wild world of your production deployment, right. And the production deployment could be going at the radio cell tower at the Edge location where a cluster is running there. Or it could be sending, you know, these applications and having them run at my customer site, where they might not have configured that cluster exactly the same way as I configured it. Or they configured the cluster right. But maybe they didn't deploy the security policies, or they didn't deploy the other infrastructure plugins that my app relies on. All of these various factors add their own layer of complexity. And there really isn't a simple way to solve that today. And that is just, you know, one example of an issue that happens. I think another, you know, whole new ballgame of issues come in the context of security, right? Because when you are deploying applications at scale, in a distributed manner, you got to make sure someone's job is on the line to ensure that the right security policies are enforced regardless of that scale factor. So I think that's another example of problems that occur. >> Okay, so I have to ask about scale, because there are a lot of multiple steps involved when you see the success of cloud native, you know, you see some experimentation, they set up a cluster, say it's containers and Kubernetes. And then you say, okay, we got this. We configure it. And then they do it again, and again, they call it day two. Some people call it day one, day two operation, whatever you call it. Once you get past the first initial thing, then you got to scale it. Then you're seeing security breaches. You're seeing configuration errors. This seems to be where the hotspot is, in when companies transition from, I got this, to oh no, it's harder than I thought at scale. Can you share your reaction to that and how you see this playing out? >> Yeah, so, you know, I think it's interesting. There's multiple problems that occur when the two factors of scale, as we talked about, start expanding. I think one of them is what I like to call the, it works fine on my cluster problem, which is back in, when I was a developer, we used to call this, it works on my laptop problem. Which is, you know, you have your perfectly written code that is operating just fine on your machine, your sandbox environment. But the moment it runs production, it comes back with P 0s and POS from support teams, et cetera. And those issues can be really difficult to try us, right. And so in the Kubernetes environment, this problem kind of multi-folds. It goes, you know, escalates to a higher degree because you have your sandbox developer environments, they have their clusters, and things work perfectly fine in those clusters, because these clusters are typically handcrafted or a combination of some scripting and handcrafting. And so as you give that change to then run at your production Edge location, like say your radial cell power site, or you hand it over to a customer to run it on their cluster, they might not have configured that cluster exactly how you did, or they might not have configured some of the infrastructure plugins. And so things don't work. And when things don't work, triaging them becomes nightmarishly hard, right? It's just one of the examples of the problem. Another whole bucket of issues is security, which is, as you have these distributed clusters at scale. You got to ensure someone's job is on the line to make sure that the security policies are configured properly. >> So this is a huge problem. I love that comment. That's not happening on my system. It's the classic, you know, debugging mentality. But at scale, it's hard to do that with error prone. I can see that being a problem. And you guys have a solution you're launching, can you share what Arlon is? This new product? What is it all about? Talk about this new introduction. >> Yeah absolutely, I'm very, very excited. You know, it's one of the projects that we've been working on for some time now. Because we are very passionate about this problem and just solving problems at scale in OnPrem or in the cloud or at Edge environments. And what Arlon is, it's an open source project, and it is a tool, a Kubernetes native tool for complete end-to-end management of not just your clusters, but your clusters, all of the infrastructure that goes within and along the sites of those clusters, security policies, your middleware plugins, and finally your applications. So what Arlon lets you do in a nutshell is in a declarative way, it lets you handle the configuration and management of all of these components in at scale. >> So what's the elevator pitch simply put for what this solves in terms of the chaos you guys are reigning in, what's the bumper sticker. What did it do? >> There's a perfect analogy that I love to reference in this context, which is, think of your assembly line, you know, in a traditional, let's say an auto manufacturing factory, or et cetera, and the level of efficiency at scale that that assembly line brings, right. Arlon, and if you look at the logo we've designed, it's this funny little robot. And it's because when we think of Arlon, we think of these enterprise large scale environments, you know, sprawling at scale, creating chaos, because there isn't necessarily a well thought through, well-structured solution that's similar to an assembly line, which is taking each component, you know, addressing them, manufacturing, processing them in a standardized way, then handing to the next stage where again, it gets processed in a standardized way. And that's what Arlon really does. That's like the elevator pitch. If you have problems of scale, of managing your infrastructure, you know, that is distributed, Arlon brings the assembly line level of efficiency and consistency for those problems. >> So keeping it smooth, the assembly line, things are flowing, see CI/CD pipe-lining. So that's what you're trying to simplify that OPS piece for the developer. I mean, it's not really OPS, it's their OPS, it's coding. >> Yeah, not just developer the OPS, the operations folks as well, right. Because developers, you know, developers are responsible for one picture of that layer, which is my apps. And then maybe that middleware of applications that they interface with. But then they hand it over to someone else who's then responsible to ensure that these apps are secured properly, that they are logging, logs are being collected properly. Monitoring and observability is integrated. And so it solves problems for both those teams. >> Yeah, it's DevOps. So the DevOps is the cloud native developer. The OPS team have to kind of set policies. Is that where the declarative piece comes in? Is that why that's important? >> Absolutely, yeah. And you know, Kubernetes really introduced or elevated this declarative management, right. Because you know, Kubernetes clusters are you know your specifications of components that go in Kubernetes are defined in a declarative way. And Kubernetes always keeps that state consistent with your defined state. But when you go outside of that world of a single cluster, and when you actually talk about defining the clusters or defining everything that's around it, there really isn't a solution that does that today. And so Arlon addresses that problem at the heart of it. And it does that using existing open source, well known solutions. >> And do I want to get into the benefits, what's in it for me as the customer, developer, but I want to finish this out real quick and get your thoughts. You mentioned open source. Why open source? What's the current state of the product? You run the product group over there at Platform9. Is it open source, and you guys have a product that's commercial? Can you explain the open source dynamic? And first of all, why open source? And what is the consumption? I mean open source is great. People want opensource, they can download and look up the code, but maybe want to buy the commercial. So I'm assuming you have that thought through. Can you share open source and commercial relationship? >> Yeah, I think, you know, starting with why opensource? I think it's, you know, we, as a company, we have one of the things that's absolutely critical to us is that we take mainstream open source technologies, components, and then we make them available to our customers at scale through either a SaaS model or OnPrem model, right. But so as we are a company or startup, or a company that benefits, you know, in a massive way by this open source economy, it's only right I think in my mind that we do are part of the duty, right. And contribute back to the community that feeds us. And so, you know, we have always held that strongly as one of our principles. And we have, you know, created and built independent products, starting all the way with Fission, which was a serverless product that we had built, to various other examples that I can give. But that's one of the main reasons why open source. And also open source because we want the community to really first-hand engage with us on this problem, which is very difficult to achieve if your product is behind a wall, you know, behind a black box. >> Well, and that's what the developers want too. What we're seeing in reporting with Supercloud is the new model of consumption is I want to look at the code and see what's in there. >> That's right. >> And then also if I want to use it, I'll do it, great. That's open source, that's the value. But then at the end of the day, if I want to move fast, that's when people buy in. So it's a new kind of freemium, I guess, business model. I guess that's the way it is, but that's the benefit of open source. This is why standards and open source is growing so fast. You have that confluence of, you know, a way for developers to try before they buy, but also actually kind of date the application, if you will. We, you know, Adrian Kakroff uses the dating metaphor, you know, hey, you know, I want to check it out first before I get married. And that's what open source is. So this is the new, this is how people are selling. This is not just open source. This is how companies are selling. >> Absolutely, yeah, yeah. You know, I think two things, I think one is just, you know, this cloud native space is so vast that if you're building a cluster solution, sometimes there's also a risk that it may not apply to every single enterprises use cases. And so having it open source gives them an opportunity to extend it, expand it, to make it proper to their use case, if they choose to do so, right. But at the same time, what's also critical to us, is we are able to provide a supported version of it, with an SLA that's backed by us, a SaaS-hosted version of it as well for those customers who choose to go that route. You know, once they have used the open source version and loved it and want to take it at scale and in production and need a partner to collaborate with who can support them for that production environment. >> I have to ask you. Now let's get into what's in it for the customer? I'm a customer. Why should I be enthused about Arlon? What's in it for me? You know, 'cause if I'm not enthused about it, I'm not going to be confident, and it's going to be hard for me to get behind this. Can you share your enthusiastic view of, you know, why I should be enthused about Arlon, if I'm a customer. >> Yeah, absolutely. And so, and there's multiple, you know, enterprises that we talk to, many of them, are customers where this is a very kind of typical story that you will hear, which is we have a Kubernetes distribution. It could be On-Premise. It could be public cloud native Kubernetes. And then we have our CI/CD pipelines that are automating the deployment of applications, et cetera. And then there's this gray zone. And the gray zone is, well before you can, your CI/CD pipelines can deploy the apps, somebody needs to do all of their groundwork of, you know, defining those clusters, and yeah properly configuring them. And as these things start by being done hand-grown. And then as you scale, what typically enterprises would do today is they will have their homegrown DIY solutions for this. I mean, the number of folks that I talk to that have built Terraform automation, and then, you know, some of those key developers leave. So it's a typical open source, or typical, you know, DIY challenge. And the reason that they're writing it themselves is not because they want to. I mean, of course technology is always interesting to everybody, but it's because they can't find a solution that's out there that perfectly fits their problem. And so that's that pitch. I think OPS people would be delighted. The folks that we've talked, you know, spoken with have been absolutely excited and have shared that this is a major challenge we have today, because we have few hundreds of clusters on EKS, Amazon, and we want to scale them to few thousands, but we don't think we are ready to do that. And this will give us the ability to do that. >> Yeah, I think people are scared. I won't say scared, that's a bad word. Maybe I should say that they feel nervous because you know, at scale, small mistakes can become large mistakes. This is something that is concerning to enterprises. And I think this is going to come up at KubeCon this year where enterprises are going to say, okay, I need to see SLAs. I want to see track record. I want to see other companies that have used it. How would you answer that question to, or challenge, you know, hey I love this, but is there any guarantees? Is there any, what's the SLAs? I'm an enterprise, I got tight. You know, I love the open source trying to free, fast and loose, but I need hardened code. >> Yeah, absolutely. So two parts to that, right? One is Arlon leverages, existing opensource components, products that are extremely popular. Two specifically, one is Arlon uses Argo CD, which is probably one of the highest rated and used CD opensource tools that's out there, right. Created by folks that are as part of Intuit team now, you know, really brilliant team, and it's used at scale across enterprises. That's one. Second is Arlon also makes use of cluster API, CAPI, which is a Kubernetes sub-component, right for lifecycle management of clusters. So there is enough of, you know, community users, et cetera, around these two products or open source projects that will find Arlon to be right up in their alley, because they're already comfortable, familiar with Argo CD. Now Arlon just extends the scope of what Argo CD can do. And so that's one. And then the second part is going back to your point of the comfort. And that's where, you know, Platform9 has a role to play, which is when you are ready to deploy Arlon at scale, because you've been, you know playing with it in your DEV test environments, you're happy with what you get with it. Then Platform9 will stand behind it and provide that SLA. >> And what's been the reaction from customers you've talked to, Platform9 customers that are familiar with Argo, and then Arlo? What's been some of the feedback? >> Yeah, I think the feedback's been fantastic. I mean, I can give you examples of customers where you know, initially, when you're telling them about your entire portfolio of solutions, it might not strike a chord right away. But then we start talking about Arlon, and we talk about the fact that it uses Argo CD. They start opening up, they say, we have standardized on Argo, and we have built these components homegrown. We would be very interested. Can we co-develop? Does it support these use cases? So we've had that kind of validation. We've had validation all the way at the beginning of Arlon, before we even wrote a single line of code, saying this is something we plan on doing. And the customer said, if you had it today, I would've purchased it. So it's been really great validation. >> All right, so next question is what is the solution to the customer? If I asked you, look, I'm so busy. My team's overworked, I got a skills gap. I don't need another project. I'm so tied up right now, and I'm just chasing my tail. How does Platform9 help me? >> Yeah, absolutely. So I think, you know, one of the core tenants of Platform9 has always been, that we try to bring that public cloud like simplicity by hosting, you know, this and a lot of such similar tools in a SaaS hosted manner for our customers, right. So our goal behind doing that is taking away, or trying to take away all of that complexity from customer's hands and offloading it to our hands, right. And giving them that full white glove treatment as we call it. And so from a customer's perspective, one, something like Arlon will integrate with what they have, so they don't have to rip and replace anything. In fact, it will even in the next versions, it may even discover your clusters that you have today, and give you an inventory. >> So customers have clusters that are growing. That's a sign, call you guys. >> Absolutely, either they have massive, large clusters, right, that they want to split into smaller clusters, but they're not comfortable doing that today. Or they've done that already on say public cloud or otherwise. And now they have management challenges. >> So, especially operationalizing the clusters, whether they want to kind of reset everything and move things around, and reconfigure, and or scale out. >> That's right, exactly. >> And you provide that layer of policy. >> Absolutely, yes. >> That's the key value here. >> That's right. >> So policy based configuration for cluster scale up. >> Profile and policy based declarative configuration and life cycle management for clusters. >> If I asked you how this enables Supercloud, what would you say to that? >> I think this is one of the key ingredients to Supercloud, right? If you think about a Supercloud environment, there is at least few key ingredients that come to my mind that are really critical. Like they are, you know, life saving ingredients at that scale. One is having a really good strategy for managing that scale, you know, in a going back to assembly line, in a very consistent, predictable way. So that, Arlon solves. Then you need to compliment that with the right kind of observability and monitoring tools at scale, right? Because ultimately issues are going to happen, and you're going to have to figure out, you know, how to solve them fast. And Arlon, by the way also helps in that direction. But you also need observability tools. And then especially if you're running it on the public cloud, you need some cost management tools. In my mind, these three things are like the most necessary ingredients to make Supercloud successful. And you know, Arlon is one of them. >> Okay so now the next level is, okay, that makes sense is under the covers, kind of speak under the hood. How does that impact the app developers of the cloud native modern application workflows? Because the impact to me seems, the apps are going to be impacted. Are they going to be faster, stronger? I mean, what's the impact if you do all those things, as you mentioned, what's the impact of the apps? >> Yeah, the impact is that your apps are more likely to operate in production the way you expect them to, because the right checks and balances have gone through. And any discrepancies have been identified prior to those apps, prior to your customer running into them, right? Because developers run into this challenge today where there's a split responsibility, right. I'm responsible for my code. I'm responsible for some of these other plugins, but I don't own these stack end to end. I have to rely on my OPS counterpart to do their part, right. And so this really gives them the right tooling for that. >> This is actually a great kind of relevant point. You know, as cloud becomes more scalable, you're starting to see this fragmentation, gone are the days of the full stack developer, to the more specialized role. But this is a key point. And I have to ask you, because if this Arlo solution takes place, as you say, and the apps are going to do what they're designed to do, the question is what does the current pain look like? Are the apps breaking? What is the signals to the customer that they should be calling you guys up and implementing Arlo, Argo, and all the other goodness to automate, what are some of the signals? Is it downtime? Is it failed apps? Is it latency? What are some of the things that would be indications of things are effed up a little bit. >> Yeah, more frequent down times, down times that take longer to triage. And so your, you know, your mean times on resolution, et cetera, are escalating or growing larger, right? Like we have environments of customers where they have a number of folks in the field that have to take these apps, and run them at customer sites. And that's one of our partners. And they're extremely interested in this, because the rate of failures they're encountering for this, you know, the field when they're running these apps on site, because the field is automating their clusters that are running on sites using their own script. So these are the kinds of challenges. So those are the pain points, which is, you know, if you're looking to reduce your meantime to resolution. If you're looking to reduce the number of failures that occur on your production site, that's one. And second, if you're looking to manage these at scale environments with a relatively small focused nimble OPS team, which has an immediate impact on your budget. So those are the signals. >> This is the cloud native at scale situation. The innovation going on. Final thought is your reaction to the idea that if the world goes digital, which it is, and the confluence of physical and digital coming together, and cloud continues to do its thing, the company becomes the application. Not where IT used to be supporting the business, you know, the back office, and the immediate terminals and some PCs and handhelds. Now, if technology's running the business, is the business, company's the application. So it can't be down. So there's a lot of pressure on CSOs and CIOs now, and boards are saying, how is technology driving the top line revenue? That's the number one conversation. Do you see the same thing? >> Yeah, it's interesting. I think there's multiple pressures at the CSO, CIO level, right? One, is that there needs to be that visibility and clarity and guarantee almost that, you know, the technology that's going to drive your top line is going to drive that in a consistent, reliable, predictable manner. And then second, there is the constant pressure to do that while always lowering your costs of doing it, right. Especially when you're talking about, let's say retailers, or those kinds of large scale vendors, they many times make money by lowering the amount that they spend providing those goods to their end customers. So I think both those factors kind of come into play and the solution to all of them is usually in a very structured strategy around automation. >> Final question. What does cloud native at scale look like to you? If all the things happen the way we want 'em to happen, the magic wand, the magic dust, what does it look like? >> What that looks like to me is a CIO sipping at his desk on coffee. Production is running absolutely smooth. And he's running that at a nimble, nimble team size of, at the most, a handful of folks that are just looking after things, but things are just taking care of themselves. >> And the CIO doesn't exist. There's no CISO, they're at the beach. >> (laughing) Yeah. >> Madhura, thank you for coming on, sharing the cloud native at scale here on theCUBE. Thank you for your time. >> Fantastic, thanks for having me. >> Okay, I'm John Furrier here for special program presentation, special programming Cloud Native at Scale, Enabling Supercloud Modern Applications with Platform9. Thanks for watching. (upbeat music)

>> The introduction of the modern public cloud in the mid 2000s, permanently changed the way we think about IT. At the heart of it, the cloud operating model attacked one of the biggest problems in enterprise infrastructure, human labor costs. More than half of IT budgets were spent on people, and much of that effort added little or no differentiable value to the business. The automation of provisioning, management, recovery, optimization, and decommissioning infrastructure resources has gone mainstream as organizations demand a cloud-like model across all their application infrastructure, irrespective of its physical location. This has not only cut cost, but it's also improved quality and reduced human error. Hello everyone, my name is Dave Vellante and welcome to Simplifying Hybrid Cloud, made possible by Cisco. Today, we're going to explore Hybrid Cloud as an operating model for organizations. Now the definite of cloud is expanding. Cloud is no longer an abstract set of remote services, you know, somewhere out in the clouds. No, it's an operating model that spans public cloud, on-premises infrastructure, and it's also moving to edge locations. This trend is happening at massive scale. While at the same time, preserving granular control of resources. It's an entirely new game where IT managers must think differently to deal with this complexity. And the environment is constantly changing. The growth and diversity of applications continues. And now, we're living in a world where the workforce is remote. Hybrid work is now a permanent state and will be the dominant model. In fact, a recent survey of CIOs by Enterprise Technology Research, ETR, indicates that organizations expect 36% of their workers will be operating in a hybrid mode. Splitting time between remote work and in office environments. This puts added pressure on the application infrastructure required to support these workers. The underlying technology must be more dynamic and adaptable to accommodate constant change. So the challenge for IT managers is ensuring that modern applications can be run with a cloud-like experience that spans on-prem, public cloud, and edge locations. This is the future of IT. Now today, we have three segments where we're going to dig into these issues and trends surrounding Hybrid Cloud. First up, is DD Dasgupta, who will set the stage and share with us how Cisco is approaching this challenge. Next, we're going to hear from Manish Agarwal and Darren Williams, who will help us unpack HyperFlex which is Cisco's hyperconverged infrastructure offering. And finally, our third segment will drill into Unified Compute. More than a decade ago, Cisco pioneered the concept of bringing together compute with networking in a single offering. Cisco frankly, changed the legacy server market with UCS, Unified Compute System. The X-Series is Cisco's next generation architecture for the coming decade and we'll explore how it fits into the world of Hybrid Cloud, and its role in simplifying the complexity that we just discussed. So, thanks for being here. Let's go. (upbeat music playing) Okay, let's start things off. DD Dasgupta is back on theCUBE to talk about how we're going to simplify Hybrid Cloud complexity. DD welcome, good to see you again. >> Hey Dave, thanks for having me. Good to see you again. >> Yeah, our pleasure. Look, let's start with big picture. Talk about the trends you're seeing from your customers. >> Well, I think first off, every customer these days is a public cloud customer. They do have their on-premise data centers, but, every customer is looking to move workloads, new services, cloud native services from the public cloud. I think that's one of the big things that we're seeing. While that is happening, we're also seeing a pretty dramatic evolution of the application landscape itself. You've got, you know, bare metal applications, you always have virtualized applications, and then most modern applications are containerized, and, you know, managed by Kubernetes. So I think we're seeing a big change in, in the application landscape as well. And, probably, you know, triggered by the first two things that I mentioned, the execution venue of the applications, and then the applications themselves, it's triggering a change in the IT organizations in the development organizations and sort of not only how they work within their organizations, but how they work across all of these different organizations. So I think those are some of the big things that, that I hear about when I talk to customers. >> Well, so it's interesting. I often say Cisco kind of changed the game in server and compute when it developed the original UCS. And you remember there were organizational considerations back then bringing together the server team and the networking team and of course the storage team as well. And now you mentioned Kubernetes, that is a total game changer with regard to whole the application development process. So you have to think about a new strategy in that regard. So how have you evolved your strategy? What is your strategy to help customers simplify, accelerate their hybrid cloud journey in that context? >> No, I think you're right Dave, back to the origins of UCS and we, you know, why did a networking company build a server? Well, we just enabled with the best networking technologies so, would do compute better. And now, doing something similar on the software, actually the managing software for our hyperconvergence, for our, you know, Rack server, for our blade servers. And, you know, we've been on this journey for about four years. The software is called Intersight, and, you know, we started out with Intersight being just the element manager, the management software for Cisco's compute and hyperconverged devices. But then we've evolved it over the last few years because we believe that a customer shouldn't have to manage a separate piece of software, would do manage the hardware, the underlying hardware. And then a separate tool to connect it to a public cloud. And then a third tool to do optimization, workload optimization or performance optimization, or cost optimization. A fourth tool to now manage, you know, Kubernetes and like, not just in one cluster, one cloud, but multi-cluster, multi-cloud. They should not have to have a fifth tool that does, goes into observability anyway. I can go on and on, but you get the idea. We wanted to bring everything onto that same platform that manage their infrastructure. But it's also the platform that enables the simplicity of hybrid cloud operations, automation. It's the same platform on which you can use to manage the, the Kubernetes infrastructure, Kubernetes clusters, I mean, whether it's on-prem or in a cloud. So, overall that's the strategy. Bring it to a single platform, and a platform is a loaded word we'll get into that a little bit, you know, in this conversation, but, that's the overall strategy, simplify. >> Well, you know, you brought platform. I like to say platform beats products, but you know, there was a day, and you could still point to some examples today in the IT industry where, hey, another tool we can monetize that. And another one to solve a different problem, we can monetize that. And so, tell me more about how Intersight came about. You obviously sat back, you saw what your customers were going through, you said, "We can do better." So tell us the story there. >> Yeah, absolutely. So, look, it started with, you know, three or four guys in getting in a room and saying, "Look, we've had this, you know, management software, UCS manager, UCS director." And these are just the Cisco's management, you know, for our, softwares for our own platforms. And every company has their own flavor. We said, we took on this bold goal of like, we're not, when we rewrite this or we improve on this, we're not going to just write another piece of software. We're going to create a cloud service. Or we're going to create a SaaS offering. Because the same, the infrastructure built by us whether it's on networking or compute, or the cyber cloud software, how do our customers use it? Well, they use it to write and run their applications, their SaaS services, every customer, every customer, every company today is a software company. They live and die by how their applications work or don't. And so, we were like, "We want to eat our own dog food here," right? We want to deliver this as a SaaS offering. And so that's how it started, we've being on this journey for about four years, tens of thousands of customers. But it was a pretty big, bold ambition 'cause you know, the big change with SaaS as you're familiar Dave is, the job of now managing this piece of software, is not on the customer, it's on the vendor, right? This can never go down. We have a release every Thursday, new capabilities, and we've learned so much along the way, whether it's to announce scalability, reliability, working with, our own company's security organizations on what can or cannot be in a SaaS service. So again, it's been a wonderful journey, but, I wanted to point out, we are in some ways eating our own dog food 'cause we built a SaaS application that helps other companies deliver their SaaS applications. >> So Cisco, I look at Cisco's business model and I compare, of course compare it to other companies in the infrastructure business and, you're obviously a very profitable company, you're a large company, you're growing faster than most of the traditional competitors. And, so that means that you have more to invest. You, can afford things, like to you know, stock buybacks, and you can invest in R&D you don't have to make those hard trade offs that a lot of your competitors have to make, so-- >> You got to have a talk with my boss on the whole investment. >> Yeah, right. You'd never enough, right? Never enough. But in speaking of R&D and innovations that you're intro introducing, I'm specifically interested in, how are you dealing with innovations to help simplify hybrid cloud, the operations there, improve flexibility, and things around Cloud Native initiatives as well? >> Absolutely, absolutely. Well, look, I think, one of the fundamentals where we're kind of philosophically different from a lot of options that I see in the industry is, we don't need to build everything ourselves, we don't. I just need to create a damn good platform with really good platform services, whether it's, you know, around, searchability, whether it's around logging, whether it's around, you know, access control, multi-tenants. I need to create a really good platform, and make it open. I do not need to go on a shopping spree to buy 17 and 1/2 companies and then figure out how to stich it all together. 'Cause it's almost impossible. And if it's impossible for us as a vendor, it's three times more difficult for the customer who then has to consume it. So that was the philosophical difference and how we went about building Intersight. We've created a hardened platform that's always on, okay? And then you, then the magic starts happening. Then you get partners, whether it is, you know, infrastructure partners, like, you know, some of our storage partners like NetApp or PR, or you know, others, who want their conversion infrastructures also to be managed, or their other SaaS offerings and software vendors who have now become partners. Like we did not write Terraform, you know, but we partnered with Hashi and now, you know, Terraform service's available on the Intersight platform. We did not write all the algorithms for workload optimization between a public cloud and on-prem. We partner with a company called Turbonomic and so that's now an offering on the Intersight platform. So that's where we're philosophically different, in sort of, you know, how we have gone about this. And, it actually dovetails well into, some of the new things that I want to talk about today that we're announcing on the Intersight platform where we're actually announcing the ability to attach and be able to manage Kubernetes clusters which are not on-prem. They're actually on AWS, on Azure, soon coming on GC, on GKE as well. So it really doesn't matter. We're not telling a customer if you're comfortable building your applications and running Kubernetes clusters on, you know, in AWS or Azure, stay there. But in terms of monitoring, managing it, you can use Intersight, and since you're using it on-prem you can use that same piece of software to manage Kubernetes clusters in a public cloud. Or even manage DMS in a EC2 instance. So. >> Yeah so, the fact that you could, you mentioned Storage Pure, NetApp, so Intersight can manage that infrastructure. I remember the Hashi deal and I, it caught my attention. I mean, of course a lot of companies want to partner with Cisco 'cause you've got such a strong ecosystem, but I thought that was an interesting move, Turbonomic you mentioned. And now you're saying Kubernetes in the public cloud. So a lot different than it was 10 years ago. So my last question is, how do you see this hybrid cloud evolving? I mean, you had private cloud and you had public cloud, and it was kind of a tug of war there. We see these two worlds coming together. How will that evolve on for the next few years? >> Well, I think it's the evolution of the model and I, really look at Cloud, you know, 2.0 or 3.0, or depending on, you know, how you're keeping terms. But, I think one thing has become very clear again, we, we've be eating our own dog food, I mean, Intersight is a hybrid cloud SaaS application. So we've learned some of these lessons ourselves. One thing is for sure that the customers are looking for a consistent model, whether it's on the edge, on the COLO, public cloud, on-prem, no data center, it doesn't matter. They're looking for a consistent model for operations, for governance, for upgrades, for reliability. They're looking for a consistent operating model. What (indistinct) tells me I think there's going to be a rise of more custom clouds. It's still going to be hybrid, so applications will want to reside wherever it most makes most sense for them which is obviously data, 'cause you know, data is the most expensive thing. So it's going to be complicated with the data goes on the edge, will be on the edge, COLO, public cloud, doesn't matter. But, you're basically going to see more custom clouds, more industry specific clouds, you know, whether it's for finance, or transportation, or retail, industry specific, I think sovereignty is going to play a huge role, you know, today, if you look at the cloud provider there's a handful of, you know, American and Chinese companies, that leave the rest of the world out when it comes to making, you know, good digital citizens of their people and you know, whether it's data latency, data gravity, data sovereignty, I think that's going to play a huge role. Sovereignty's going to play a huge role. And the distributor cloud also called Edge, is going to be the next frontier. And so, that's where we are trying line up our strategy. And if I had to sum it up in one sentence, it's really, your cloud, your way. Every customer is on a different journey, they will have their choice of like workloads, data, you know, upgrade reliability concern. That's really what we are trying to enable for our customers. >> You know, I think I agree with you on that custom clouds. And I think what you're seeing is, you said every company is a software company. Every company is also becoming a cloud company. They're building their own abstraction layers, they're connecting their on-prem to their public cloud. They're doing that across clouds, and they're looking for companies like Cisco to do the hard work, and give me an infrastructure layer that I can build value on top of. 'Cause I'm going to take my financial services business to my cloud model, or my healthcare business. I don't want to mess around with, I'm not going to develop, you know, custom infrastructure like an Amazon does. I'm going to look to Cisco and your R&D to do that. Do you buy that? >> Absolutely. I think again, it goes back to what I was talking about with platform. You got to give the world a solid open, flexible platform. And flexible in terms of the technology, flexible in how they want to consume it. Some of our customers are fine with the SaaS, you know, software. But if I talk to, you know, my friends in the federal team, no, that does not work. And so, how they want to consume it, they want to, you know, (indistinct) you know, sovereignty we talked about. So, I think, you know, job for an infrastructure vendor like ourselves is to give the world a open platform, give them the knobs, give them the right API tool kit. But the last thing I will mention is, you know, there's still a place for innovation in hardware. And I think some of my colleagues are going to get into some of those, you know, details, whether it's on our X-Series, you know, platform or HyperFlex, but it's really, it's going to be software defined, it's a SaaS service and then, you know, give the world an open rock solid platform. >> Got to run on something All right, Thanks DD, always a pleasure to have you on the, theCUBE, great to see you. >> Thanks for having me. >> You're welcome. In a moment, I'll be back to dig into hyperconverged, and where HyperFlex fits, and how it may even help with addressing some of the supply chain challenges that we're seeing in the market today. >> It used to be all your infrastructure was managed here. But things got more complex in distributing, and now IT operations need to be managed everywhere. But what if you could manage everywhere from somewhere? One scalable place that brings together your teams, technology, and operations. Both on-prem and in the cloud. One automated place that provides full stack visibility to help you optimize performance and stay ahead of problems. One secure place where everyone can work better, faster, and seamlessly together. That's the Cisco Intersight cloud operations platform. The time saving, cost reducing, risk managing solution for your whole IT environment, now and into the future of this ever-changing world of IT. (upbeat music) >> With me now are Manish Agarwal, senior director of product management for HyperFlex at Cisco, @flash4all, number four, I love that, on Twitter. And Darren Williams, the director of business development and sales for Cisco. MrHyperFlex, @MrHyperFlex on Twitter. Thanks guys. Hey, we're going to talk about some news and HyperFlex, and what role it plays in accelerating the hybrid cloud journey. Gentlemen, welcome to theCUBE, good to see you. >> Thanks a lot Dave. >> Thanks Dave. >> All right Darren, let's start with you. So, for a hybrid cloud, you got to have on-prem connection, right? So, you got to have basically a private cloud. What are your thoughts on that? >> Yeah, we agree. You can't have a hybrid cloud without that prime element. And you've got to have a strong foundation in terms of how you set up the whole benefit of the cloud model you're building in terms of what you want to try and get back from the cloud. You need a strong foundation. Hyperconversions provides that. We see more and more customers requiring a private cloud, and they're building it with Hyperconversions, in particular HyperFlex. Now to make all that work, they need a good strong cloud operations model to be able to connect both the private and the public. And that's where we look at Intersight. We've got solution around that to be able to connect that around a SaaS offering. That looks around simplified operations, gives them optimization, and also automation to bring both private and public together in that hybrid world. >> Darren let's stay with you for a minute. When you talk to your customers, what are they thinking these days when it comes to implementing hyperconverged infrastructure in both the enterprise and at the edge, what are they trying to achieve? >> So there's many things they're trying to achieve, probably the most brutal honesty is they're trying to save money, that's probably the quickest answer. But, I think they're trying to look in terms of simplicity, how can they remove layers of components they've had before in their infrastructure? We see obviously collapsing of storage into hyperconversions and storage networking. And we've got customers that have saved 80% worth of savings by doing that collapse into a hyperconversion infrastructure away from their Three Tier infrastructure. Also about scalability, they don't know the end game. So they're looking about how they can size for what they know now, and how they can grow that with hyperconvergence very easy. It's one of the major factors and benefits of hyperconversions. They also obviously need performance and consistent performance. They don't want to compromise performance around their virtual machines when they want to run multiple workloads. They need that consistency all all way through. And then probably one of the biggest ones is that around the simplicity model is the management layer, ease of management. To make it easier for their operations, yeah, we've got customers that have told us, they've saved 50% of costs in their operations model on deploying HyperFlex, also around the time savings they make massive time savings which they can reinvest in their infrastructure and their operations teams in being able to innovate and go forward. And then I think probably one of the biggest pieces we've seen as people move away from three tier architecture is the deployment elements. And the ease of deployment gets easy with hyperconverged, especially with Edge. Edge is a major key use case for us. And, what I want, what our customers want to do is get the benefit of a data center at the edge, without A, the big investment. They don't want to compromise in performance, and they want that simplicity in both management and deployment. And, we've seen our analysts recommendations around what their readers are telling them in terms of how management deployment's key for our IT operations teams. And how much they're actually saving by deploying Edge and taking the burden away when they deploy hyperconversions. And as I said, the savings elements is the key bit, and again, not always, but obviously those are case studies around about public cloud being quite expensive at times, over time for the wrong workloads. So by bringing them back, people can make savings. And we again have customers that have made 50% savings over three years compared to their public cloud usage. So, I'd say that's the key things that customers are looking for. Yeah. >> Great, thank you for that Darren. Manish, we have some hard news, you've been working a lot on evolving the HyperFlex line. What's the big news that you've just announced? >> Yeah, thanks Dave. So there are several things that we are announcing today. The first one is a new offer called HyperFlex Express. This is, you know, Cisco Intersight led and Cisco Intersight managed eight HyperFlex configurations. That we feel are the fastest path to hybrid cloud. The second is we are expanding our server portfolio by adding support for HX on AMD Rack, UCS AMD Rack. And the third is a new capability that we are introducing, that we are calling, local containerized witness. And let me take a minute to explain what this is. This is a pretty nifty capability to optimize for Edge environments. So, you know, this leverages the, Cisco's ubiquitous presence of the networking, you know, products that we have in the environments worldwide. So the smallest HyperFlex configuration that we have is a 2-node configuration, which is primarily used in Edge environments. Think of a, you know, a backroom in a departmental store or a oil rig, or it might even be a smaller data center somewhere around the globe. For these 2-node configurations, there is always a need for a third entity that, you know, industry term for that is either a witness or an arbitrator. We had that for HyperFlex as well. And the problem that customers face is, where you host this witness. It cannot be on the cluster because the job of the witness is to, when the infrastructure is going down, it basically breaks, sort of arbitrates which node gets to survive. So it needs to be outside of the cluster. But finding infrastructure to actually host this is a problem, especially in the Edge environments where these are resource constraint environments. So what we've done is we've taken that witness, we've converted it into a container reform factor. And then qualified a very large slew of Cisco networking products that we have, right from ISR, ASR, Nexus, Catalyst, industrial routers, even a Raspberry Pi that can host this witness. Eliminating the need for you to find yet another piece of infrastructure, or doing any, you know, care and feeding of that infrastructure. You can host it on something that already exists in the environment. So those are the three things that we are announcing today. >> So I want to ask you about HyperFlex Express. You know, obviously the whole demand and supply chain is out of whack. Everybody's, you know, global supply chain issues are in the news, everybody's dealing with it. Can you expand on that a little bit more? Can HyperFlex Express help customers respond to some of these issues? >> Yeah indeed Dave. You know the primary motivation for HyperFlex Express was indeed an idea that, you know, one of the folks are on my team had, which was to build a set of HyperFlex configurations that are, you know, would have a shorter lead time. But as we were brainstorming, we were actually able to tag on multiple other things and make sure that, you know, there is in it for, something in it for our customers, for sales, as well as our partners. So for example, you know, for our customers, we've been able to dramatically simplify the configuration and the install for HyperFlex Express. These are still HyperFlex configurations and you would at the end of it, get a HyperFlex cluster. But the part to that cluster is much, much simplified. Second is that we've added in flexibility where you can now deploy these, these are data center configurations, but you can deploy these with or without fabric interconnects, meaning you can deploy with your existing top of rack. We've also, you know, added attractive price point for these, and of course, you know, these will have better lead times because we've made sure that, you know, we are using components that are, that we have clear line of sight from our supply perspective. For partner and sales, this is, represents a high velocity sales motion, a faster turnaround time, and a frictionless sales motion for our distributors. This is actually a set of disty-friendly configurations, which they would find very easy to stalk, and with a quick turnaround time, this would be very attractive for the distys as well. >> It's interesting Manish, I'm looking at some fresh survey data, more than 70% of the customers that were surveyed, this is the ETR survey again, we mentioned 'em at the top. More than 70% said they had difficulty procuring server hardware and networking was also a huge problem. So that's encouraging. What about, Manish, AMD? That's new for HyperFlex. What's that going to give customers that they couldn't get before? >> Yeah Dave, so, you know, in the short time that we've had UCS AMD Rack support, we've had several record making benchmark results that we've published. So it's a powerful platform with a lot of performance in it. And HyperFlex, you know, the differentiator that we've had from day one is that it has the industry leading storage performance. So with this, we are going to get the fastest compute, together with the fastest storage. And this, we are hoping that we'll, it'll basically unlock, you know, a, unprecedented level of performance and efficiency, but also unlock several new workloads that were previously locked out from the hyperconverged experience. >> Yeah, cool. So Darren, can you give us an idea as to how HyperFlex is doing in the field? >> Sure, absolutely. So, both me and Manish been involved right from the start even before it was called HyperFlex, and we've had a great journey. And it's very exciting to see where we are taking, where we've been with the technology. So we have over 5,000 customers worldwide, and we're currently growing faster year over year than the market. The majority of our customers are repeat buyers, which is always a good sign in terms of coming back when they've proved the technology and are comfortable with the technology. They, repeat buyer for expanded capacity, putting more workloads on. They're using different use cases on there. And from an Edge perspective, more numbers of science. So really good endorsement of the technology. We get used across all verticals, all segments, to house mission critical applications, as well as the traditional virtual server infrastructures. And we are the lifeblood of our customers around those, mission critical customers. I think one big example, and I apologize for the worldwide audience, but this resonates with the American audience is, the Super Bowl. So, the SoFi stadium that housed the Super Bowl, actually has Cisco HyperFlex running all the management services, through from the entire stadium for digital signage, 4k video distribution, and it's completely cashless. So, if that were to break during Super Bowl, that would've been a big news article. But it was run perfectly. We, in the design of the solution, we're able to collapse down nearly 200 servers into a few nodes, across a few racks, and have 120 virtual machines running the whole stadium, without missing a heartbeat. And that is mission critical for you to run Super Bowl, and not be on the front of the press afterwards for the wrong reasons, that's a win for us. So we really are, really happy with HyperFlex, where it's going, what it's doing, and some of the use cases we're getting involved in, very, very exciting. >> Hey, come on Darren, it's Super Bowl, NFL, that's international now. And-- >> Thing is, I follow NFL. >> The NFL's, it's invading London, of course, I see the, the picture, the real football over your shoulder. But, last question for Manish. Give us a little roadmap, what's the future hold for HyperFlex? >> Yeah. So, you know, as Darren said, both Darren and I have been involved with HyperFlex since the beginning. But, I think the best is yet to come. There are three main pillars for HyperFlex. One is, Intersight is central to our strategy. It provides a, you know, lot of customer benefit from a single pane of class management. But we are going to take this beyond the lifecycle management, which is for HyperFlex, which is integrated into Intersight today, and element management. We are going to take it beyond that and start delivering customer value on the dimensions of AI Ops, because Intersight really provides us a ideal platform to gather stats from all the clusters across the globe, do AI/ML and do some predictive analysis with that, and return back as, you know, customer valued, actionable insights. So that is one. The second is UCS expand the HyperFlex portfolio, go beyond UCS to third party server platforms, and newer UCS server platforms as well. But the highlight there is one that I'm really, really excited about and think that there is a lot of potential in terms of the number of customers we can help. Is HX on X-Series. X-Series is another thing that we are going to, you know, add, we're announcing a bunch of capabilities on in this particular launch. But HX on X-Series will have that by the end of this calendar year. And that should unlock with the flexibility of X-Series of hosting a multitude of workloads and the simplicity of HyperFlex. We're hoping that would bring a lot of benefits to new workloads that were locked out previously. And then the last thing is HyperFlex data platform. This is the heart of the offering today. And, you'll see the HyperFlex data platform itself it's a distributed architecture, a unique distributed architecture. Primarily where we get our, you know, record baring performance from. You'll see it can foster more scalable, more resilient, and we'll optimize it for you know, containerized workloads, meaning it'll get granular containerized, container granular management capabilities, and optimize for public cloud. So those are some things that we are, the team is busy working on, and we should see that come to fruition. I'm hoping that we'll be back at this forum in maybe before the end of the year, and talking about some of these newer capabilities. >> That's great. Thank you very much for that, okay guys, we got to leave it there. And you know, Manish was talking about the HX on X-Series that's huge, customers are going to love that and it's a great transition 'cause in a moment, I'll be back with Vikas Ratna and Jim Leach, and we're going to dig into X-Series. Some real serious engineering went into this platform, and we're going to explore what it all means. You're watching Simplifying Hybrid Cloud on theCUBE, your leader in enterprise tech coverage. >> The power is here, and here, but also here. And definitely here. Anywhere you need the full force and power of your infrastructure hyperconverged. It's like having thousands of data centers wherever you need them, powering applications anywhere they live, but manage from the cloud. So you can automate everything from here. (upbeat music) Cisco HyperFlex goes anywhere. Cisco, the bridge to possible. (upbeat music) >> Welcome back to theCUBE's special presentation, Simplifying Hybrid Cloud brought to you by Cisco. We're here with Vikas Ratna who's the director of product management for UCS at Cisco and James Leach, who is director of business development at Cisco. Gents, welcome back to theCUBE, good to see you again. >> Hey, thanks for having us. >> Okay, Jim, let's start. We know that when it comes to navigating a transition to hybrid cloud, it's a complicated situation for a lot of customers, and as organizations as they hit the pavement for their hybrid cloud journeys, what are the most common challenges that they face? What are they telling you? How is Cisco, specifically UCS helping them deal with these problems? >> Well, you know, first I think that's a, you know, that's a great question. And you know, customer centric view is the way that we've taken, is kind of the approach we've taken from day one. Right? So I think that if you look at the challenges that we're solving for that our customers are facing, you could break them into just a few kind of broader buckets. The first would definitely be applications, right? That's the, that's where the rubber meets your proverbial road with the customer. And I would say that, you know, what we're seeing is, the challenges customers are facing within applications come from the the way that applications have evolved. So what we're seeing now is more data centric applications for example. Those require that we, you know, are able to move and process large data sets really in real time. And the other aspect of applications I think to give our customers kind of some, you know, pause some challenges, would be around the fact that they're changing so quickly. So the application that exists today or the day that they, you know, make a purchase of infrastructure to be able to support that application, that application is most likely changing so much more rapidly than the infrastructure can keep up with today. So, that creates some challenges around, you know, how do I build the infrastructure? How do I right size it without over provisioning, for example? But also, there's a need for some flexibility around life cycle and planning those purchase cycles based on the life cycle of the different hardware elements. And within the infrastructure, which I think is the second bucket of challenges, we see customers who are being forced to move away from the, like a modular or blade approach, which offers a lot of operational and consolidation benefits, and they have to move to something like a Rack server model for some applications because of these needs that these data centric applications have, and that creates a lot of you know, opportunity for siloing the infrastructure. And those silos in turn create multiple operating models within the, you know, a data center environment that, you know, again, drive a lot of complexity. So that, complexity is definitely the enemy here. And then finally, I think life cycles. We're seeing this democratization of processing if you will, right? So it's no longer just CPU focused, we have GPU, we have FPGA, we have, you know, things that are being done in storage and the fabrics that stitch them together that are all changing rapidly and have very different life cycles. So, when those life cycles don't align for a lot of our customers, they see a challenge in how they can manage this, you know, these different life cycles and still make a purchase without having to make too big of a compromise in one area or another because of the misalignment of life cycles. So, that is a, you know, kind of the other bucket. And then finally, I think management is huge, right? So management, you know, at its core is really right size for our customers and give them the most value when it meets the mark around scale and scope. You know, back in 2009, we weren't meeting that mark in the industry and UCS came about and took management outside the chassis, right? We put it at the top of the rack and that worked great for the scale and scope we needed at that time. However, as things have changed, we're seeing a very new scale and scope needed, right? So we're talking about a hybrid cloud world that has to manage across data centers, across clouds, and, you know, having to stitch things together for some of our customers poses a huge challenge. So there are tools for all of those operational pieces that touch the application, that touch the infrastructure, but they're not the same tool. They tend to be disparate tools that have to be put together. >> Right. >> So our customers, you know, don't really enjoy being in the business of, you know, building their own tools, so that creates a huge challenge. And one where I think that they really crave that full hybrid cloud stack that has that application visibility but also can reach down into the infrastructure. >> Right. You know Jim, I said in my open that you guys, Cisco sort of changed the server game with the original UCS, but the X-Series is the next generation, the generation for the next decade which is really important 'cause you touched on a lot of things, these data intensive workload, alternative processors to sort of meet those needs. The whole cloud operating model and hybrid cloud has really changed. So, how's it going with with the X-Series? You made a big splash last year, what's the reception been in the field? >> Actually, it's been great. You know, we're finding that customers can absolutely relate to our, you know, UCS X-Series story. I think that, you know, the main reason they relate to it is they helped create it, right? It was their feedback and their partnership that gave us really the, those problem areas, those areas that we could solve for the customer that actually add, you know, significant value. So, you know, since we brought UCS to market back in 2009, you know, we had this unique architectural paradigm that we created, and I think that created a product which was the fastest in Cisco history in terms of growth. What we're seeing now is X-Series is actually on a faster trajectory. So we're seeing a tremendous amount of uptake. We're seeing all, you know, both in terms of, you know, the number of customers, but also more importantly, the number of workloads that our customers are using, and the types of workloads are growing, right? So we're growing this modular segment that exist, not just, you know, bringing customers onto a new product, but we're actually bring them into the product in the way that we had envisioned, which is one infrastructure that can run any application and do it seamlessly. So we're really excited to be growing this modular segment. I think the other piece, you know, that, you know, we judge ourselves is, you know, sort of not just within Cisco, but also within the industry. And I think right now is a, you know, a great example, you know, our competitors have taken kind of swings and misses over the past five years at this, at a, you know, kind of the new next architecture. And, we're seeing a tremendous amount of growth even faster than any of our competitors have seen when they announced something that was new to this space. So, I think that the ground up work that we did is really paying off. And I think that what we're also seeing is it's not really a leap frog game, as it may have been in the past. X-Series is out in front today, and, you know, we're extending that lead with some of the new features and capabilities we have. So we're delivering on the story that's already been resonating with customers and, you know, we're pretty excited that we're seeing the results as well. So, as our competitors hit walls, I think we're, you know, we're executing on the plan that we laid out back in June when we launched X-Series to the world. And, you know, as we continue to do that, we're seeing, you know, again, tremendous uptake from our customers. >> So thank you for that Jim. So Vikas, I was just on Twitter just today actually talking about the gravitational pull, you've got the public clouds pulling CXOs one way and you know, on-prem folks pulling the other way and hybrid cloud. So, organizations are struggling with a lot of different systems and architectures and ways to do things. And I said that what they're trying to do is abstract all that complexity away and they need infrastructure to support that. And I think your stated aim is really to try to help with that confusion with the X series, right? I mean, so how so can you explain that? >> Sure. And, that's the right, the context that you built up right there Dave. If you walk into enterprise data center you'll see plethora of compute systems spread all across. Because, every application has its unique needs, and, hence you find drive node, drive-dense system, memory dense system, GPU dense system, core dense system, and variety of form factors, 1U, 2U, 4U, and, every one of them typically come with, you know, variety of adapters and cables and so forth. This creates the siloness of resources. Fabric is (indistinct), the adapter is (indistinct). The power and cooling implication. The Rack, you know, face challenges. And, above all, the multiple management plane that they come up with, which makes it very difficult for IT to have one common center policy, and enforce it all across, across the firmware and software and so forth. And then think about upgrade challenges of the siloness makes it even more complex as these go through the upgrade processes of their own. As a result, we observe quite a few of our customers, you know, really seeing an inter, slowness in that agility, and high burden in the cost of overall ownership. This is where with the X-Series powered by Intersight, we have one simple goal. We want to make sure our customers get out of that complexities. They become more agile, and drive lower TCOs. And we are delivering it by doing three things, three aspects of simplification. First, simplify their whole infrastructure by enabling them to run their entire workload on single infrastructure. An infrastructure which removes the siloness of form factor. An infrastructure which reduces the Rack footprint that is required. An infrastructure where power and cooling budgets are in the lower. Second, we want to simplify by delivering a cloud operating model, where they can and create the policy once across compute network storage and deploy it all across. And third, we want to take away the pain they have by simplifying the process of upgrade and any platform evolution that they're going to go through in the next two, three years. So that's where the focus is on just driving down the simplicity, lowering down their TCOs. >> Oh, that's key, less friction is always a good thing. Now, of course, Vikas we heard from the HyperFlex guys earlier, they had news not to be outdone. You have hard news as well. What innovations are you announcing around X-Series today? >> Absolutely. So we are following up on the exciting X-Series announcement that we made in June last year, Dave. And we are now introducing three innovation on X-Series with the goal of three things. First, expand the supported workload on X-Series. Second, take the performance to new levels. Third, dramatically reduce the complexities in the data center by driving down the number of adapters and cables that are needed. To that end, three new innovations are coming in. First, we are introducing the support for the GPU node using a cableless and very unique X-Fabric architecture. This is the most elegant design to add the GPUs to the compute node in the modular form factor. Thereby, our customers can now power in AI/ML workload, or any workload that need many more number of GPUs. Second, we are bringing in GPUs right onto the compute node, and thereby our customers can now fire up the accelerated VDI workload for example. And third, which is what you know, we are extremely proud about, is we are innovating again by introducing the fifth generation of our very popular unified fabric technology. With the increased bandwidth that it brings in, coupled with the local drive capacity and densities that we have on the compute node, our customers can now fire up the big data workload, the FCI workload, the SDS workload. All these workloads that have historically not lived in the modular form factor, can be run over there and benefit from the architectural benefits that we have. Second, with the announcement of fifth generation fabric, we've become the only vendor to now finally enable 100 gig end to end single port bandwidth, and there are multiple of those that are coming in there. And we are working very closely with our CI partners to deliver the benefit of these performance through our Cisco Validated Design to our CI franchise. And third, the innovations in the fifth gen fabric will again allow our customers to have fewer physical adapters made with ethernet adapter, made with power channel adapters, or made with, the other storage adapters. They've reduced it down and coupled with the reduction in the cable. So very, very excited about these three big announcements that we are making in this month's release. >> Great, a lot there, you guys have been busy, so thank you for that Vikas. So, Jim, you talked a little bit about the momentum that you have, customers are adopting, what problems are they telling you that X-Series addresses, and how do they align with where they want to go in the future? >> That's a great question. I think if you go back to, and think about some of the things that we mentioned before, in terms of the problems that we originally set out to solve, we're seeing a lot of traction. So what Vikas mentioned I think is really important, right? Those pieces that we just announced really enhance that story and really move again, to the, kind of, to the next level of taking advantage of some of these, you know, problem solving for our customers. You know, if you look at, you know, I think Vikas mentioned accelerated VDI. That's a great example. These are where customers, you know, they need to have this dense compute, they need video acceleration, they need tight policy management, right? And they need to be able to deploy these systems anywhere in the world. Well, that's exactly what we're hitting on here with X-Series right now. We're hitting the market in every single way, right? We have the highest compute config density that we can offer across the, you know, the very top end configurations of CPUs, and a lot of room to grow. We have the, you know, the premier cloud based management, you know, hybrid cloud suite in the industry, right? So check there. We have the flexible GPU accelerators that Vikas just talked about that we're announcing both on the system and also adding additional ones to the, through the use of the X-Fabric, which is really, really critical to this launch as well. And, you know, I think finally, the fifth generation of fabric interconnect and virtual interface card, and, intelligent fabric module go hand in hand in creating this 100 gig end to end bandwidth story, that we can move a lot of data. Again, you know, having all this performance is only as good as what we can get in and out of it, right? So giving customers the ability to manage it anywhere, to be able to get the bandwidth that they need, to be able to get the accelerators that are flexible that it fit exactly their needs, this is huge, right? This solves a lot of the problems we can tick off right away. With the infrastructure as I mentioned, X-Fabric is really critical here because it opens a lot of doors here, you know, we're talking about GPUs today, but in the future, there are other elements that we can disaggregate, like the GPUs that solve these life cycle mismanagement issues. They solve issues around the form factor limitations. It solves all these issues for like, it does for GPU we can do that with storage or memory in the future. So that's going to be huge, right? This is disaggregation that actually delivers, right? It's not just a gimmicky bar trick here that we're doing, this is something that customers can really get value out of day one. And then finally, I think the, you know, the future readiness here, you know, we avoid saying future proof because we're kind of embracing the future here. We know that not only are the GPUs going to evolve, the CPUs are going to evolve, the drives, you know, the storage modules are going to evolve. All of these things are changing very rapidly. The fabric that stitches them together is critical, and we know that we're just on the edge of some of the development that are coming with CXL, with some of the PCI Express changes that are coming in the very near future, so we're ready to go. And the X-Fabric is exactly the vehicle that's going to be able to deliver those technologies to our customers, right? Our customers are out there saying that, you know, they want to buy into to something like X-Series that has all the operational benefits, but at the same time, they have to have the comfort in knowing that they're protected against being locked out of some technology that's coming in the future, right? We want our customers to take these disruptive technologies and not be disrupted, but use them to disrupt their competition as well. So, you know, we're really excited about the pieces today, and, I think it goes a long way towards continuing to tell the customer benefit story that X-Series brings, and, you know, again, you know, stay tuned because it's going to keep getting better as we go. >> Yeah, a lot of headroom for scale and the management piece is key there. Just have time for one more question Vikas. Give us some nuggets on the roadmap. What's next for X-Series that we can look forward to? >> Absolutely Dave. As we talked about, and as Jim also hinted, this is a future ready architecture. A lot of focus and innovation that we are going through is about enabling our customers to seamlessly and painlessly adopt very disruptive hardware technologies that are coming up, no refund replace. And, there we are looking into, enabling the customer's journey as they transition from PCI generation four, to five to six without driven replace, as they embrace CXL without driven replace. As they embrace the newer paradigm of computing through the disaggregated memory, disaggregated PCIe or NVMe based dense drives, and so forth. We are also looking forward to X-Fabric next generation, which will allow dynamic assignment of GPUs anywhere within the chassis and much more. So this is again, all about focusing on the innovation that will make the enterprise data center operations a lot more simpler, and drive down the TCO by keeping them not only covered for today, but also for future. So that's where some of the focus is on Dave. >> Okay. Thank you guys we'll leave it there, in a moment, I'll have some closing thoughts. (upbeat music) We're seeing a major evolution, perhaps even a bit of a revolution in the underlying infrastructure necessary to support hybrid work. Look, virtualizing compute and running general purpose workloads is something IT figured out a long time ago. But just when you have it nailed down in the technology business, things change, don't they? You can count on that. The cloud operating model has bled into on-premises locations. And is creating a new vision for the future, which we heard a lot about today. It's a vision that's turning into reality. And it supports much more diverse and data intensive workloads and alternative compute modes. It's one where flexibility is a watch word, enabling change, attacking complexity, and bringing a management capability that allows for a granular management of resources at massive scale. I hope you've enjoyed this special presentation. Remember, all these videos are available on demand at thecube.net. And if you want to learn more, please click on the information link. Thanks for watching Simplifying Hybrid Cloud brought to you by Cisco and theCUBE, your leader in enterprise tech coverage. This is Dave Vellante, be well and we'll see you next time. (upbeat music)

(bright music) >> Welcome to this Kube Conversation. I'm Dave Nicholson. And today we have a very special guest from Red Hat, Nick Barcet. Nick is the Senior Director of Technology, Technology Strategy at Red Hat. Nick, welcome back to theCUBE. >> Thank you. It's always a pleasure to be visiting you here virtually. >> It's fantastic to have you here. I see a new office surroundings at Red Hat. Have they taken a kind of a nautical theme at the office there? Where are you joining us from? >> I'm joining from my boat now, I've been living on my boat for the past few years, and that's where you'll find me most of the time. >> So would you consider your boat to be on the Edge? >> It's certainly one form of Edge. You know, there are multiple forms of Edge and a boat is one of those forms. >> Let's talk about Edge now. We're having this conversation in anticipation of KubeCon CloudNativeCon that's coming up North America 2021, coming up in Los Angeles. Let's talk about specifically the Edge, where the Edge, Edge computing and Kubernetes come together from a Red Hat perspective. Walk us through that, talk about some of the challenges that people are having at the Edge, why Kubernetes is something that would be considered at the edge. Walk us through that. >> Let's start from the premises that people have been doing stuff at the Edge for ages. I mean, nobody has been waiting for Kubernetes or any other technology to start implementing some form of computing that is happening in their stores, in their factories, wherever. What's really new today is when we talk about Edge computing, it's reusing the same technology we've been using to deploy inside of the data center and expand that all the way to the Edge. And that's what, from my perspective, constituents, Edge computing or the revolution it bring. So that means that the same GitOps, DevSecOps methodology that we were using into that center are now expandable all the way to those devices that leaves in where locations and that we can reuse the same methodology, the same tooling, and that includes Kubernetes. And all the efforts we've been doing over the past couple of years has been to make Kubernetes even more accessible for the various Edge typologies that we are encountering when discussing with our customer that have Edge projects. >> So typically when we think of a Kubernetes environment, you're talking about containers that are contained in pods, that live on physical clusters, despite all of the talk of a no-code and serverless, we still live in a world where applications and microservices run on physical servers. Are there practical limitations in terms of just how small you can scale Kubernetes? How far, how close to the Edge can you get with the Kubernetes deployment? >> So in theory, there is really no limit. As the smallest devices are always bigger than Kubernetes itself. But the reality is you never use just Kubernetes, you use Kubernetes with a series of other projects that makes it complete, or for example, stuff that is going to be reporting telemetry, components that are going to help you automatically scale, et cetera. And the further you go into the Edge, the less of these competence you can afford. So you have to make trade-offs when you reduce the size of the device. Today, what Red Hat offers, is really concentrated to where we can deliver a full OpenShift experience. So the smallest environments on which we would recommend to run OpenShift at the Edge is a single node is roughly 24 gigabytes of RAM, which is you could buy it, sorry, which is already a relatively big Edge device. And when you go a step lower then, that's where we would recommend using a standard rail for Edge configuration or something similar. Not Kubernetes anymore. >> So you said single node, are you let's double click on that for a second. Is that a single physical node that is abstracted in a way to create some level of logical redundancy? When you say single node, walk us through that. We've got containers that are in pods, so what are we talking about? >> You have, based on your requirements, you can have different way of addressing your compute need at the Edge. You can have those smallest of clusters. And this would be three nodes that are delivered, with is the control plane and the worker nodes integrated into one. When you want to go a step further, you could use worker nodes that are controlled remotely via a central control plane that is at a central site. And when you want to go, even one step further deploy Kubernetes on a very small machine, but that remains fully functional even if disconnected that's when you would use the thing that is not anymore a cluster, which is a single note, Kubernetes where you still have access to the full Kubernetes API, regardless of the connectivity of your site, whether it's active or not, whether you're at sea or in the air or not. And that's where we still offer some form of software high vulnerability, because Kubernetes, even on a single node, it'll still detect if a container dies and restarted and provide similar functionality like this, but it won't provide hardware availability since we are a single node. >> And that makes sense. Yeah, that makes, yeah, it makes perfect sense. And I would suggest that we refer to that as a single node cluster, just because we like to mix it up with terminology in our business and sometimes confuse people with it. >> Technically, that was the choice we made, actually. You like to call it a cluster because it's not a cluster >> Exactly. No, I appreciate that. Absolutely. So what's be explicit about what the trade-offs are there. Let's say that I'm thinking of deploying something at the Edge, and I'm going use Kubernetes to orchestrate my container environment and pretend for a moment that space and cost aren't huge limiting factors. I could put a three node cluster in, but the idea of putting in a single node is very, it's attractive. Where does, where's the line drawn in terms of what you would recommend from, you know, what are the trade offs? What am I losing, going to the single node cluster? See I just called that. >> Well, in a nutshell, you're losing hardware high availability. Meaning if one of your server fails since you only have one server, you lose everything. And there is no way around that. That's the biggest trade-off. Then you have also a trade-off on the memory used by the control plane, which you won't be able to use to do something else. So if I have a site with excellent connectivity and the biggest loss of connectivity might be counted in hours, maybe a remote worker use a better solution because this way, I have a single central-side that carries my control plane, and I can use all the RAM and all the CPU's on my local site to deploy my workloads, not to carries a control plane. To give you an example of these trade-off in the telco space, for example, if you're deploying an antenna in a city, you have plenty of antennas covering that city. And therefore, the loss of one antenna is not a big deal. So in that case, you will be tempted to use a remote worker because you will be maximizing your use of the RAM on the sites for the workload, which is let's have people establish communication using their phones. But now, we take another antenna that we are getting to locate in a very remote location. There, if this antenna fail, everybody fails. There's nobody that is able to make calls, even emergency vehicles cannot discuss together very often. So in that case, it's a lot better to have an autonomous deployment, something where the control plane and the workload itself are being run in one box. And this one box in fact can be duplicated. There could be a another box that is either seating in a truck in case of emergency or off, but on the antenna site, so that in case of a major failure, you have a possibility to re to restore it. So it really depends on what's your sets of constraints in terms of availability in SIM of efficiency of your RAM use is going to be that it's going to make you choose between one or the other of the deployment models. >> No, that's a great example. And so it sounds like it's not a one size fits all world, obviously. Now, from the perspective of the marketplace, looking in at Red Hat, participating in this business, some think of Red Hat as the company that deployed Linux 20 years ago. Help us make that connection between Red Hat today and what you've been doing for the last 20 years and this topic of Edge computing, 'cause some people don't automatically think of Red Hat an Edge computing. I do, I think they should, (chuckles) but help us understand that. >> Yeah, obviously a lot of people consider that Red Hat is Red Hat, Linux, and that's it. The Red Hat Enterprise Linux is what we've been known since our beginnings 25 years ago, and what has made our early success. But we consider ourselves more of an infrastructure company. We have been offering for the past 20 years, the various component that you need to deploy server, run and manage your workloads across data centers and make sure that you can store your data, and that you can automate your operations on top of this infrastructure. So we really consider ourselves much more of a company that offers everything that enables you to run your servers and run your workloads on top of your server. And that includes a tool to do virtualization, that includes tool to do continuous deployment of containers. And that's where Kubernetes entered in play about 10 years ago. Well, first it was OPAs that then became Kubernetes and the OpenShift offering that we have today. >> Yeah. Thanks for that. So I have, I've got a final question for you. It's a little bit off topic, but it's related, this is in the category of Nick predicts. So when does Nick predict that we will get to a point where we tip beyond the 50/50 point cloud versus on-premises IT spending, if you accept today that we're still in the neighborhood of 75 to 80% on-premises. When will we hit the 50/50 mark? I'm not asking you for the hundred percent cloud date, but give us a date, you give us a month and a year for 50/50. >> Given the progression of cloud, if there was no Edge, we could said two to three years from now, we would be at this 50/50 mark. But the funny thing is that at the same time, as the cloud progresses, people start realizing that they have needs that needs to be solved locally. And this is why we are deploying Edge-based solution, solution which reliably can provide answers, regardless of the connectivity to the cloud, regardless of the bandwidth. There are things that I would never want to do, like feeding a size on feeds from 4K cameras, into my cloud environment that won't scale, I won't have the bandwidth to do so. And therefore, maybe the answer to your question is, it's going to be asymptotic, and it's almost impossible to predict. >> So that is a much better answer than giving me an exact date and time, because (chuckles) because it reveals exactly the reality that we're living in. Again, there is, you know, it's fit for function. It's not cloud for cloud's sake, compute resources, data, resources have a place that they naturally belong oftentimes. And oftentimes that is on the Edge, whether it's on the edge of the edge of the world in a sailboat or out in a single server, not node, or I keep wanting to single node cluster, it's killing me. I dunno why, I think it's so funny, but a single node implementation of OpenShift where you can run Kubernetes on the Edge, it's a fascinating subject. Anything else that you want to share with us that we didn't get? >> I think one aspect that we never talk enough is how do you manage at the scale of Edge? Because even though each Edge site is very small, you can have thousands, even hundreds of thousands of these single node something that are running all over the place. And I think that what you're seeing in advent cluster management for Kubernetes, and particularly the 2.4 version that we are going to be announcing this week and actually releasing in November is I think a pretty good answer to that problem on how do I deploy with zero touch these devices? How do I update them, upgrade them? How do I deploy the workloads on top of that? How do I ensure to have the right tooling to deploy that at the scale? And we've done the testing now of ACM with up to 2,000 clusters, connected to a single ACMs. And in the future, we are planning on building federation of those, which really gives us the possibility to provide the tooling needed to manage at its scale. >> Excellent. Excellent. Yeah. That's whenever we start talking about anything in the realm of containerization and Kubernetes scale starts to become an issue. It's no longer a question of a human being managing 10 servers and 50 applications. We start talking about tens of thousands and hundreds of thousands of instances where it's beyond human scale. So that's obviously something that's very, very important. Well, Nick, I want to thank you for becoming a Kube veteran once again. Thanks for joining this Kube Conversation from Dave Nicholson, this has been a Kube Conversation in anticipation of KubeCon and CloudNativeCon North America 2021. Thanks for tuning in. (bright music)

>>all right, We're five minutes after the hour. That's all aboard. Who's coming aboard? Welcome everyone to the tutorial track for our launchpad of them. So for the next couple of hours, we've got a SYRIZA videos and experts on hand to answer questions about our new product, Doctor Enterprise Container Cloud. Before we jump into the videos and the technology, I just want to introduce myself and my other emcee for the session. I'm Bill Milks. I run curriculum development for Mirant us on. And >>I'm Bruce Basil Matthews. I'm the Western regional Solutions architect for Moran Tissue esa and welcome to everyone to this lovely launchpad oven event. >>We're lucky to have you with us proof. At least somebody on the call knows something about your enterprise Computer club. Um, speaking of people that know about Dr Enterprise Container Cloud, make sure that you've got a window open to the chat for this session. We've got a number of our engineers available and on hand to answer your questions live as we go through these videos and disgusting problem. So that's us, I guess, for Dr Enterprise Container Cloud, this is Mirant asses brand new product for bootstrapping Doctor Enterprise Kubernetes clusters at scale Anything. The airport Abu's? >>No, just that I think that we're trying Thio. Uh, let's see. Hold on. I think that we're trying Teoh give you a foundation against which to give this stuff a go yourself. And that's really the key to this thing is to provide some, you know, many training and education in a very condensed period. So, >>yeah, that's exactly what you're going to see. The SYRIZA videos we have today. We're going to focus on your first steps with Dr Enterprise Container Cloud from installing it to bootstrapping your regional child clusters so that by the end of the tutorial content today, you're gonna be prepared to spin up your first documentary prize clusters using documented prize container class. So just a little bit of logistics for the session. We're going to run through these tutorials twice. We're gonna do one run through starting seven minutes ago up until I guess it will be ten fifteen Pacific time. Then we're gonna run through the whole thing again. So if you've got other colleagues that weren't able to join right at the top of the hour and would like to jump in from the beginning, ten. Fifteen Pacific time. We're gonna do the whole thing over again. So if you want to see the videos twice, you got public friends and colleagues that, you know you wanna pull in for a second chance to see this stuff, we're gonna do it all. All twice. Yeah, this session. Any any logistics I should add, Bruce that No, >>I think that's that's pretty much what we had to nail down here. But let's zoom dash into those, uh, feature films. >>Let's do Edmonds. And like I said, don't be shy. Feel free to ask questions in the chat or engineers and boosting myself are standing by to answer your questions. So let me just tee up the first video here and walk their cost. Yeah. Mhm. Yes. Sorry. And here we go. So our first video here is gonna be about installing the Doctor Enterprise Container Club Management cluster. So I like to think of the management cluster as like your mothership, right? This is what you're gonna use to deploy all those little child clusters that you're gonna use is like, Come on it as clusters downstream. So the management costs was always our first step. Let's jump in there >>now. We have to give this brief little pause >>with no good day video. Focus for this demo will be the initial bootstrap of the management cluster in the first regional clusters to support AWS deployments. The management cluster provides the core functionality, including identity management, authentication, infantry release version. The regional cluster provides the specific architecture provided in this case, eight of us and the Elsie um, components on the UCP Cluster Child cluster is the cluster or clusters being deployed and managed. The deployment is broken up into five phases. The first phase is preparing a big strap note on this dependencies on handling with download of the bridge struck tools. The second phase is obtaining America's license file. Third phase. Prepare the AWS credentials instead of the adduce environment. The fourth configuring the deployment, defining things like the machine types on the fifth phase. Run the bootstrap script and wait for the deployment to complete. Okay, so here we're sitting up the strap node, just checking that it's clean and clear and ready to go there. No credentials already set up on that particular note. Now we're just checking through AWS to make sure that the account we want to use we have the correct credentials on the correct roles set up and validating that there are no instances currently set up in easy to instance, not completely necessary, but just helps keep things clean and tidy when I am perspective. Right. So next step, we're just going to check that we can, from the bootstrap note, reach more antis, get to the repositories where the various components of the system are available. They're good. No areas here. Yeah, right now we're going to start sitting at the bootstrap note itself. So we're downloading the cars release, get get cars, script, and then next, we're going to run it. I'm in. Deploy it. Changing into that big struck folder. Just making see what's there. Right now we have no license file, so we're gonna get the license filed. Oh, okay. Get the license file through the more antis downloads site, signing up here, downloading that license file and putting it into the Carisbrook struck folder. Okay, Once we've done that, we can now go ahead with the rest of the deployment. See that the follow is there. Uh, huh? That's again checking that we can now reach E C two, which is extremely important for the deployment. Just validation steps as we move through the process. All right, The next big step is valid in all of our AWS credentials. So the first thing is, we need those route credentials which we're going to export on the command line. This is to create the necessary bootstrap user on AWS credentials for the completion off the deployment we're now running an AWS policy create. So it is part of that is creating our Food trucks script, creating the mystery policy files on top of AWS, Just generally preparing the environment using a cloud formation script you'll see in a second will give a new policy confirmations just waiting for it to complete. Yeah, and there is done. It's gonna have a look at the AWS console. You can see that we're creative completed. Now we can go and get the credentials that we created Today I am console. Go to that new user that's being created. We'll go to the section on security credentials and creating new keys. Download that information media Access key I D and the secret access key. We went, Yeah, usually then exported on the command line. Okay. Couple of things to Notre. Ensure that you're using the correct AWS region on ensure that in the conflict file you put the correct Am I in for that region? I'm sure you have it together in a second. Yes. Okay, that's the key. Secret X key. Right on. Let's kick it off. Yeah, So this process takes between thirty and forty five minutes. Handles all the AWS dependencies for you, and as we go through, the process will show you how you can track it. Andi will start to see things like the running instances being created on the west side. The first phase off this whole process happening in the background is the creation of a local kind based bootstrapped cluster on the bootstrap node that clusters then used to deploy and manage all the various instances and configurations within AWS. At the end of the process, that cluster is copied into the new cluster on AWS and then shut down that local cluster essentially moving itself over. Okay. Local clusters boat just waiting for the various objects to get ready. Standard communities objects here Okay, so we speed up this process a little bit just for demonstration purposes. Yeah. There we go. So first note is being built the best in host. Just jump box that will allow us access to the entire environment. Yeah, In a few seconds, we'll see those instances here in the US console on the right. Um, the failures that you're seeing around failed to get the I. P for Bastian is just the weight state while we wait for a W s to create the instance. Okay. Yes. Here, beauty there. Okay. Mhm. Okay. Yeah, yeah. Okay. On there. We got question. Host has been built on three instances for the management clusters have now been created. We're going through the process of preparing. Those nodes were now copying everything over. See that? The scaling up of controllers in the big Strap cluster? It's indicating that we're starting all of the controllers in the new question. Almost there. Yeah. Yeah, just waiting for key. Clark. Uh huh. Start to finish up. Yeah. No. What? Now we're shutting down control this on the local bootstrap node on preparing our I. D. C. Configuration. Fourth indication, soon as this is completed. Last phase will be to deploy stack light into the new cluster the last time Monitoring tool set way Go stack like to plan It has started. Mhm coming to the end of the deployment Mountain. Yeah, America. Final phase of the deployment. Onda, We are done. Okay, You'll see. At the end they're providing us the details of you. I log in so there's a keeper clogging. You can modify that initial default password is part of the configuration set up with one documentation way. Go Councils up way can log in. Yeah, yeah, thank you very much for watching. >>Excellent. So in that video are wonderful field CTO Shauna Vera bootstrapped up management costume for Dr Enterprise Container Cloud Bruce, where exactly does that leave us? So now we've got this management costume installed like what's next? >>So primarily the foundation for being able to deploy either regional clusters that will then allow you to support child clusters. Uh, comes into play the next piece of what we're going to show, I think with Sean O'Mara doing this is the child cluster capability, which allows you to then deploy your application services on the local cluster. That's being managed by the ah ah management cluster that we just created with the bootstrap. >>Right? So this cluster isn't yet for workloads. This is just for bootstrapping up the downstream clusters. Those or what we're gonna use for workings. >>Exactly. Yeah. And I just wanted to point out, since Sean O'Mara isn't around, toe, actually answer questions. I could listen to that guy. Read the phone book, and it would be interesting, but anyway, you can tell him I said that >>he's watching right now, Crusoe. Good. Um, cool. So and just to make sure I understood what Sean was describing their that bootstrap er knows that you, like, ran document fresh pretender Cloud from to begin with. That's actually creating a kind kubernetes deployment kubernetes and Docker deployment locally. That then hits the AWS a p i in this example that make those e c two instances, and it makes like a three manager kubernetes cluster there, and then it, like, copies itself over toe those communities managers. >>Yeah, and and that's sort of where the transition happens. You can actually see it. The output that when it says I'm pivoting, I'm pivoting from my local kind deployment of cluster AP, I toothy, uh, cluster, that's that's being created inside of AWS or, quite frankly, inside of open stack or inside of bare metal or inside of it. The targeting is, uh, abstracted. Yeah, but >>those air three environments that we're looking at right now, right? Us bare metal in open staff environments. So does that kind cluster on the bootstrap er go away afterwards. You don't need that afterwards. Yeah, that is just temporary. To get things bootstrapped, then you manage things from management cluster on aws in this example? >>Yeah. Yeah. The seed, uh, cloud that post the bootstrap is not required anymore. And there's no, uh, interplay between them after that. So that there's no dependencies on any of the clouds that get created thereafter. >>Yeah, that actually reminds me of how we bootstrapped doctor enterprise back in the day, be a temporary container that would bootstrap all the other containers. Go away. It's, uh, so sort of a similar, similar temporary transient bootstrapping model. Cool. Excellent. What will convict there? It looked like there wasn't a ton, right? It looked like you had to, like, set up some AWS parameters like credentials and region and stuff like that. But other than that, that looked like heavily script herbal like there wasn't a ton of point and click there. >>Yeah, very much so. It's pretty straightforward from a bootstrapping standpoint, The config file that that's generated the template is fairly straightforward and targeted towards of a small medium or large, um, deployment. And by editing that single file and then gathering license file and all of the things that Sean went through, um, that that it makes it fairly easy to script >>this. And if I understood correctly as well that three manager footprint for your management cluster, that's the minimum, right. We always insist on high availability for this management cluster because boy do not wanna see oh, >>right, right. And you know, there's all kinds of persistent data that needs to be available, regardless of whether one of the notes goes down or not. So we're taking care of all of that for you behind the scenes without you having toe worry about it as a developer. >>No, I think there's that's a theme that I think will come back to throughout the rest of this tutorial session today is there's a lot of there's a lot of expertise baked him to Dr Enterprise Container Cloud in terms of implementing best practices for you like the defaulter, just the best practices of how you should be managing these clusters, Miss Seymour. Examples of that is the day goes on. Any interesting questions you want to call out from the chap who's >>well, there was. Yeah, yeah, there was one that we had responded to earlier about the fact that it's a management cluster that then conduce oh, either the the regional cluster or a local child molester. The child clusters, in each case host the application services, >>right? So at this point, we've got, in some sense, like the simplest architectures for our documentary prize Container Cloud. We've got the management cluster, and we're gonna go straight with child cluster. In the next video, there's a more sophisticated architecture, which will also proper today that inserts another layer between those two regional clusters. If you need to manage regions like across a BS, reads across with these documents anything, >>yeah, that that local support for the child cluster makes it a lot easier for you to manage the individual clusters themselves and to take advantage of our observation. I'll support systems a stack light and things like that for each one of clusters locally, as opposed to having to centralize thumb >>eso. It's a couple of good questions. In the chat here, someone was asking for the instructions to do this themselves. I strongly encourage you to do so. That should be in the docks, which I think Dale helpfully thank you. Dale provided links for that's all publicly available right now. So just head on in, head on into the docks like the Dale provided here. You can follow this example yourself. All you need is a Mirante license for this and your AWS credentials. There was a question from many a hear about deploying this toe azure. Not at G. Not at this time. >>Yeah, although that is coming. That's going to be in a very near term release. >>I didn't wanna make promises for product, but I'm not too surprised that she's gonna be targeted. Very bracing. Cool. Okay. Any other thoughts on this one does. >>No, just that the fact that we're running through these individual pieces of the steps Well, I'm sure help you folks. If you go to the link that, uh, the gentleman had put into the chat, um, giving you the step by staff. Um, it makes it fairly straightforward to try this yourselves. >>E strongly encourage that, right? That's when you really start to internalize this stuff. OK, but before we move on to the next video, let's just make sure everyone has a clear picture in your mind of, like, where we are in the life cycle here creating this management cluster. Just stop me if I'm wrong. Who's creating this management cluster is like, you do that once, right? That's when your first setting up your doctor enterprise container cloud environment of system. What we're going to start seeing next is creating child clusters and this is what you're gonna be doing over and over and over again. When you need to create a cluster for this Deb team or, you know, this other team river it is that needs commodity. Doctor Enterprise clusters create these easy on half will. So this was once to set up Dr Enterprise Container Cloud Child clusters, which we're going to see next. We're gonna do over and over and over again. So let's go to that video and see just how straightforward it is to spin up a doctor enterprise cluster for work clothes as a child cluster. Undocumented brands contain >>Hello. In this demo, we will cover the deployment experience of creating a new child cluster, the scaling of the cluster and how to update the cluster. When a new version is available, we begin the process by logging onto the you I as a normal user called Mary. Let's go through the navigation of the U I so you can switch. Project Mary only has access to development. Get a list of the available projects that you have access to. What clusters have been deployed at the moment there. Nan Yes, this H Keys Associate ID for Mary into her team on the cloud credentials that allow you to create access the various clouds that you can deploy clusters to finally different releases that are available to us. We can switch from dark mode to light mode, depending on your preferences, Right? Let's now set up semester search keys for Mary so she can access the notes and machines again. Very simply, had Mississippi key give it a name, we copy and paste our public key into the upload key block. Or we can upload the key if we have the file available on our local machine. A simple process. So to create a new cluster, we define the cluster ad management nodes and add worker nodes to the cluster. Yeah, again, very simply, you go to the clusters tab. We hit the create cluster button. Give the cluster name. Yeah, Andi, select the provider. We only have access to AWS in this particular deployment, so we'll stick to AWS. What's like the region in this case? US West one release version five point seven is the current release Onda Attach. Mary's Key is necessary Key. We can then check the rest of the settings, confirming the provider Any kubernetes c r D r I p address information. We can change this. Should we wish to? We'll leave it default for now on. Then what components? A stack light I would like to deploy into my Custer. For this. I'm enabling stack light on logging on Aiken. Sit up the retention sizes Attention times on. Even at this stage, at any customer alerts for the watchdogs. E consider email alerting which I will need my smart host details and authentication details. Andi Slack Alerts. Now I'm defining the cluster. All that's happened is the cluster's been defined. I now need to add machines to that cluster. I'll begin by clicking the create machine button within the cluster definition. Oh, select manager, Select the number of machines. Three is the minimum. Select the instant size that I'd like to use from AWS and very importantly, ensure correct. Use the correct Am I for the region. I commend side on the route device size. There we go, my three machines obviously creating. I now need to add some workers to this custom. So I go through the same process this time once again, just selecting worker. I'll just add to once again, the AM is extremely important. Will fail if we don't pick the right, Am I for a boon to machine in this case and the deployment has started. We can go and check on the bold status are going back to the clusters screen on clicking on the little three dots on the right. We get the cluster info and the events, so the basic cluster info you'll see pending their listen cluster is still in the process of being built. We kick on, the events will get a list of actions that have been completed This part of the set up of the cluster. So you can see here we've created the VPC. We've created the sub nets on We've created the Internet gateway. It's unnecessary made of us and we have no warnings of the stage. Yeah, this will then run for a while. We have one minute past waken click through. We can check the status of the machine bulls as individuals so we can check the machine info, details of the machines that we've assigned, right? Mhm Onda. See any events pertaining to the machine areas like this one on normal? Yeah. Just watch asked. The community's components are waiting for the machines to start. Go back to Custer's. Okay, right. Because we're moving ahead now. We can see we have it in progress. Five minutes in new Matt Gateway on the stage. The machines have been built on assigned. I pick up the U. S. Thank you. Yeah. There we go. Machine has been created. See the event detail and the AWS. I'd for that machine. Mhm. No speeding things up a little bit. This whole process and to end takes about fifteen minutes. Run the clock forward, you'll notice is the machines continue to bold the in progress. We'll go from in progress to ready. A soon as we got ready on all three machines, the managers on both workers way could go on and we could see that now we reached the point where the cluster itself is being configured. Mhm, mhm. And then we go. Cluster has been deployed. So once the classes deployed, we can now never get around our environment. Okay, Are cooking into configure cluster We could modify their cluster. We could get the end points for alert alert manager on See here The griffon occupying and Prometheus are still building in the background but the cluster is available on you would be able to put workloads on it the stretch to download the cube conflict so that I can put workloads on it. It's again three little dots in the right for that particular cluster. If the download cube conflict give it my password, I now have the Q conflict file necessary so that I can access that cluster Mhm all right Now that the build is fully completed, we can check out cluster info on. We can see that Allow the satellite components have been built. All the storage is there, and we have access to the CPU. I So if we click into the cluster, we can access the UCP dashboard, right? Shit. Click the signing with Detroit button to use the SSO on. We give Mary's possible to use the name once again. Thing is, an unlicensed cluster way could license at this point. Or just skip it on. There. We have the UCP dashboard. You can see that has been up for a little while. We have some data on the dashboard going back to the console. We can now go to the griffon, a data just being automatically pre configured for us. We can switch and utilized a number of different dashboards that have already been instrumented within the cluster. So, for example, communities cluster information, the name spaces, deployments, nodes. Mhm. So we look at nodes. If we could get a view of the resource is utilization of Mrs Custer is very little running in it. Yeah. General dashboard of Cuba navies cluster one of this is configurable. You can modify these for your own needs, or add your own dashboards on de scoped to the cluster. So it is available to all users who have access to this specific cluster, all right to scale the cluster on to add a notice. A simple is the process of adding a mode to the cluster, assuming we've done that in the first place. So we go to the cluster, go into the details for the cluster we select, create machine. Once again, we need to be ensure that we put the correct am I in and any other functions we like. You can create different sized machines so it could be a larger node. Could be bigger disks and you'll see that worker has been added from the provisioning state on shortly. We will see the detail off that worker as a complete to remove a note from a cluster. Once again, we're going to the cluster. We select the node would like to remove. Okay, I just hit delete On that note. Worker nodes will be removed from the cluster using according and drawing method to ensure that your workouts are not affected. Updating a cluster. When an update is available in the menu for that particular cluster, the update button will become available. And it's a simple as clicking the button, validating which release you would like to update to. In this case, the next available releases five point seven point one. Here I'm kicking the update by in the background We will coordinate. Drain each node slowly go through the process of updating it. Andi update will complete depending on what the update is as quickly as possible. Girl, we go. The notes being rebuilt in this case impacted the manager node. So one of the manager nodes is in the process of being rebuilt. In fact, to in this case, one has completed already on In a few minutes we'll see that there are great has been completed. There we go. Great. Done. Yeah. If you work loads of both using proper cloud native community standards, there will be no impact. >>Excellent. So at this point, we've now got a cluster ready to start taking our communities of workloads. He started playing or APs to that costume. So watching that video, the thing that jumped out to me at first Waas like the inputs that go into defining this workload cost of it. All right, so we have to make sure we were using on appropriate am I for that kind of defines the substrate about what we're gonna be deploying our cluster on top of. But there's very little requirements. A so far as I could tell on top of that, am I? Because Docker enterprise Container Cloud is gonna bootstrap all the components that you need. That s all we have is kind of kind of really simple bunch box that we were deploying these things on top of so one thing that didn't get dug into too much in the video. But it's just sort of implied. Bruce, maybe you can comment on this is that release that Shawn had to choose for his, uh, for his cluster in creating it. And that release was also the thing we had to touch. Wanted to upgrade part cluster. So you have really sharp eyes. You could see at the end there that when you're doing the release upgrade enlisted out a stack of components docker, engine, kubernetes, calico, aled, different bits and pieces that go into, uh, go into one of these commodity clusters that deploy. And so, as far as I can tell in that case, that's what we mean by a release. In this sense, right? It's the validated stack off container ization and orchestration components that you know we've tested out and make sure it works well, introduction environments. >>Yeah, and and And that's really the focus of our effort is to ensure that any CVS in any of the stack are taken care of that there is a fixes air documented and up streamed to the open stack community source community, um, and and that, you know, then we test for the scaling ability and the reliability in high availability configuration for the clusters themselves. The hosts of your containers. Right. And I think one of the key, uh, you know, benefits that we provide is that ability to let you know, online, high. We've got an update for you, and it's fixes something that maybe you had asked us to fix. Uh, that all comes to you online as your managing your clusters, so you don't have to think about it. It just comes as part of the product. >>You just have to click on Yes. Please give me that update. Uh, not just the individual components, but again. It's that it's that validated stack, right? Not just, you know, component X, y and Z work. But they all work together effectively Scalable security, reliably cool. Um, yeah. So at that point, once we started creating that workload child cluster, of course, we bootstrapped good old universal control plane. Doctor Enterprise. On top of that, Sean had the classic comment there, you know? Yeah. Yeah. You'll see a little warnings and errors or whatever. When you're setting up, UCP don't handle, right, Just let it do its job, and it will converge all its components, you know, after just just a minute or two. But we saw in that video, we sped things up a little bit there just we didn't wait for, you know, progress fighters to complete. But really, in real life, that whole process is that anything so spend up one of those one of those fosters so quite quite quick. >>Yeah, and and I think the the thoroughness with which it goes through its process and re tries and re tries, uh, as you know, and it was evident when we went through the initial ah video of the bootstrapping as well that the processes themselves are self healing, as they are going through. So they will try and retry and wait for the event to complete properly on. And once it's completed properly, then it will go to the next step. >>Absolutely. And the worst thing you could do is panic at the first warning and start tearing things that don't don't do that. Just don't let it let it heal. Let take care of itself. And that's the beauty of these manage solutions is that they bake in a lot of subject matter expertise, right? The decisions that are getting made by those containers is they're bootstrapping themselves, reflect the expertise of the Mirant ISS crew that has been developing this content in these two is free for years and years now, over recognizing humanities. One cool thing there that I really appreciate it actually that it adds on top of Dr Enterprise is that automatic griffon a deployment as well. So, Dr Enterprises, I think everyone knows has had, like, some very high level of statistics baked into its dashboard for years and years now. But you know our customers always wanted a double click on that right to be able to go a little bit deeper. And Griffon are really addresses that it's built in dashboards. That's what's really nice to see. >>Yeah, uh, and all of the alerts and, uh, data are actually captured in a Prometheus database underlying that you have access to so that you are allowed to add new alerts that then go out to touch slack and say hi, You need to watch your disk space on this machine or those kinds of things. Um, and and this is especially helpful for folks who you know, want to manage the application service layer but don't necessarily want to manage the operations side of the house. So it gives them a tool set that they can easily say here, Can you watch these for us? And Miran tas can actually help do that with you, So >>yeah, yeah, I mean, that's just another example of baking in that expert knowledge, right? So you can leverage that without tons and tons of a long ah, long runway of learning about how to do that sort of thing. Just get out of the box right away. There was the other thing, actually, that you could sleep by really quickly if you weren't paying close attention. But Sean mentioned it on the video. And that was how When you use dark enterprise container cloud to scale your cluster, particularly pulling a worker out, it doesn't just like Territo worker down and forget about it. Right? Is using good communities best practices to cordon and drain the No. So you aren't gonna disrupt your workloads? You're going to just have a bunch of containers instantly. Excellent crash. You could really carefully manage the migration of workloads off that cluster has baked right in tow. How? How? Document? The brass container cloud is his handling cluster scale. >>Right? And And the kubernetes, uh, scaling methodology is is he adhered to with all of the proper techniques that ensure that it will tell you. Wait, you've got a container that actually needs three, uh, three, uh, instances of itself. And you don't want to take that out, because that node, it means you'll only be able to have to. And we can't do that. We can't allow that. >>Okay, Very cool. Further thoughts on this video. So should we go to the questions. >>Let's let's go to the questions >>that people have. Uh, there's one good one here, down near the bottom regarding whether an a p I is available to do this. So in all these demos were clicking through this web. You I Yes, this is all a p. I driven. You could do all of this. You know, automate all this away is part of the CSC change. Absolutely. Um, that's kind of the point, right? We want you to be ableto spin up. Come on. I keep calling them commodity clusters. What I mean by that is clusters that you can create and throw away. You know, easily and automatically. So everything you see in these demos eyes exposed to FBI? >>Yeah. In addition, through the standard Cube cuddle, Uh, cli as well. So if you're not a programmer, but you still want to do some scripting Thio, you know, set up things and deploy your applications and things. You can use this standard tool sets that are available to accomplish that. >>There is a good question on scale here. So, like, just how many clusters and what sort of scale of deployments come this kind of support our engineers report back here that we've done in practice up to a Zeman ia's like two hundred clusters. We've deployed on this with two hundred fifty nodes in a cluster. So were, you know, like like I said, hundreds, hundreds of notes, hundreds of clusters managed by documented press container fall and then those downstream clusters, of course, subject to the usual constraints for kubernetes, right? Like default constraints with something like one hundred pods for no or something like that. There's a few different limitations of how many pods you can run on a given cluster that comes to us not from Dr Enterprise Container Cloud, but just from the underlying kubernetes distribution. >>Yeah, E. I mean, I don't think that we constrain any of the capabilities that are available in the, uh, infrastructure deliveries, uh, service within the goober Netease framework. So were, you know, But we are, uh, adhering to the standards that we would want to set to make sure that we're not overloading a node or those kinds of things, >>right. Absolutely cool. Alright. So at this point, we've got kind of a two layered our protection when we are management cluster, but we deployed in the first video. Then we use that to deploy one child clustering work, classroom, uh, for more sophisticated deployments where we might want to manage child clusters across multiple regions. We're gonna add another layer into our architectural we're gonna add in regional cluster management. So this idea you're gonna have the single management cluster that we started within the first video. On the next video, we're gonna learn how to spin up a regional clusters, each one of which would manage, for example, a different AWS uh, US region. So let me just pull out the video for that bill. We'll check it out for me. Mhm. >>Hello. In this demo, we will cover the deployment of additional regional management. Cluster will include a brief architectures of you how to set up the management environment, prepare for the deployment deployment overview and then just to prove it, to play a regional child cluster. So, looking at the overall architecture, the management cluster provides all the core functionality, including identity management, authentication, inventory and release version. ING Regional Cluster provides the specific architecture provider in this case AWS on the LCN components on the D you speak Cluster for child cluster is the cluster or clusters being deployed and managed? Okay, so why do you need a regional cluster? Different platform architectures, for example aws who have been stack even bare metal to simplify connectivity across multiple regions handle complexities like VPNs or one way connectivity through firewalls, but also help clarify availability zones. Yeah. Here we have a view of the regional cluster and how it connects to the management cluster on their components, including items like the LCN cluster Manager we also Machine Manager were held. Mandel are managed as well as the actual provider logic. Mhm. Okay, we'll begin by logging on Is the default administrative user writer. Okay, once we're in there, we'll have a look at the available clusters making sure we switch to the default project which contains the administration clusters. Here we can see the cars management cluster, which is the master controller. And you see, it only has three nodes, three managers, no workers. Okay, if we look at another regional cluster similar to what we're going to deploy now, also only has three managers once again, no workers. But as a comparison, here's a child cluster This one has three managers, but also has additional workers associate it to the cluster. All right, we need to connect. Tell bootstrap note. Preferably the same note that used to create the original management plaster. It's just on AWS, but I still want to machine. All right. A few things we have to do to make sure the environment is ready. First thing we're going to see go into route. We'll go into our releases folder where we have the kozberg struck on. This was the original bootstrap used to build the original management cluster. Yeah, we're going to double check to make sure our cube con figures there once again, the one created after the original customers created just double check. That cute conflict is the correct one. Does point to the management cluster. We're just checking to make sure that we can reach the images that everything is working. A condom. No damages waken access to a swell. Yeah. Next we're gonna edit the machine definitions. What we're doing here is ensuring that for this cluster we have the right machine definitions, including items like the am I. So that's found under the templates AWS directory. We don't need to edit anything else here. But we could change items like the size of the machines attempts. We want to use that The key items to ensure where you changed the am I reference for the junta image is the one for the region in this case AWS region for utilizing this was no construct deployment. We have to make sure we're pointing in the correct open stack images. Yeah, okay. Set the correct and my save file. Now we need to get up credentials again. When we originally created the bootstrap cluster, we got credentials from eight of the U. S. If we hadn't done this, we would need to go through the u A. W s set up. So we're just exporting the AWS access key and I d. What's important is CAAs aws enabled equals. True. Now we're sitting the region for the new regional cluster. In this case, it's Frankfurt on exporting our cube conflict that we want to use for the management cluster. When we looked at earlier Yeah, now we're exporting that. Want to call the cluster region Is Frank Foods Socrates Frankfurt yet trying to use something descriptive It's easy to identify. Yeah, and then after this, we'll just run the bootstrap script, which will complete the deployment for us. Bootstrap of the regional cluster is quite a bit quicker than the initial management clusters. There are fewer components to be deployed. Um, but to make it watchable, we've spent it up. So we're preparing our bootstrap cluster on the local bootstrap node. Almost ready on. We started preparing the instances at W s and waiting for that bastard and no to get started. Please. The best you nerd Onda. We're also starting to build the actual management machines they're now provisioning on. We've reached the point where they're actually starting to deploy. Dr. Enterprise, this is probably the longest face. Yeah, seeing the second that all the nerds will go from the player deployed. Prepare, prepare. Yeah, You'll see their status changes updates. He was the first night ready. Second, just applying second already. Both my time. No waiting from home control. Let's become ready. Removing cluster the management cluster from the bootstrap instance into the new cluster running the date of the U. S. All my stay. Ah, now we're playing Stockland. Switch over is done on. Done. Now I will build a child cluster in the new region very, very quickly to find the cluster will pick. Our new credential has shown up. We'll just call it Frankfurt for simplicity a key and customs to find. That's the machine. That cluster stop with three managers. Set the correct Am I for the region? Yeah, Do the same to add workers. There we go test the building. Yeah. Total bill of time Should be about fifteen minutes. Concedes in progress. It's going to expect this up a little bit. Check the events. We've created all the dependencies, machine instances, machines, a boat shortly. We should have a working cluster in Frankfurt region. Now almost a one note is ready from management. Two in progress. Yeah, on we're done. Clusters up and running. Yeah. >>Excellent. So at this point, we've now got that three tier structure that we talked about before the video. We got that management cluster that we do strapped in the first video. Now we have in this example to different regional clustering one in Frankfurt, one of one management was two different aws regions. And sitting on that you can do Strap up all those Doctor enterprise costumes that we want for our work clothes. >>Yeah, that's the key to this is to be able to have co resident with your actual application service enabled clusters the management co resident with it so that you can, you know, quickly access that he observation Elson Surfboard services like the graph, Ana and that sort of thing for your particular region. A supposed to having to lug back into the home. What did you call it when we started >>the mothership? >>The mothership. Right. So we don't have to go back to the mother ship. We could get >>it locally. Yeah, when, like to that point of aggregating things under a single pane of glass? That's one thing that again kind of sailed by in the demo really quickly. But you'll notice all your different clusters were on that same cluster. Your pain on your doctor Enterprise Container Cloud management. Uh, court. Right. So both your child clusters for running workload and your regional clusters for bootstrapping. Those child clusters were all listed in the same place there. So it's just one pane of glass to go look for, for all of your clusters, >>right? And, uh, this is kind of an important point. I was, I was realizing, as we were going through this. All of the mechanics are actually identical between the bootstrapped cluster of the original services and the bootstrapped cluster of the regional services. It's the management layer of everything so that you only have managers, you don't have workers and that at the child cluster layer below the regional or the management cluster itself, that's where you have the worker nodes. And those are the ones that host the application services in that three tiered architecture that we've now defined >>and another, you know, detail for those that have sharp eyes. In that video, you'll notice when deploying a child clusters. There's not on Lee. A minimum of three managers for high availability management cluster. You must have at least two workers that's just required for workload failure. It's one of those down get out of work. They could potentially step in there, so your minimum foot point one of these child clusters is fine. Violence and scalable, obviously, from a >>That's right. >>Let's take a quick peek of the questions here, see if there's anything we want to call out, then we move on to our last want to my last video. There's another question here about, like where these clusters can live. So again, I know these examples are very aws heavy. Honestly, it's just easy to set up down on the other us. We could do things on bare metal and, uh, open stack departments on Prem. That's what all of this still works in exactly the same way. >>Yeah, the, uh, key to this, especially for the the, uh, child clusters, is the provision hers? Right? See you establish on AWS provision or you establish a bare metal provision or you establish a open stack provision. Or and eventually that list will include all of the other major players in the cloud arena. But you, by selecting the provision or within your management interface, that's where you decide where it's going to be hosted, where the child cluster is to be hosted. >>Speaking off all through a child clusters. Let's jump into our last video in the Siri's, where we'll see how to spin up a child cluster on bare metal. >>Hello. This demo will cover the process of defining bare metal hosts and then review the steps of defining and deploying a bare metal based doctor enterprise cluster. So why bare metal? Firstly, it eliminates hyper visor overhead with performance boost of up to thirty percent. Provides direct access to GP use, prioritize for high performance wear clothes like machine learning and AI, and supports high performance workloads like network functions, virtualization. It also provides a focus on on Prem workloads, simplifying and ensuring we don't need to create the complexity of adding another opera visor. Lay it between so continue on the theme Why Communities and bare metal again Hyper visor overhead. Well, no virtualization overhead. Direct access to hardware items like F p G A s G p us. We can be much more specific about resource is required on the nodes. No need to cater for additional overhead. Uh, we can handle utilization in the scheduling. Better Onda we increase the performances and simplicity of the entire environment as we don't need another virtualization layer. Yeah, In this section will define the BM hosts will create a new project will add the bare metal hosts, including the host name. I put my credentials I pay my address the Mac address on then provide a machine type label to determine what type of machine it is for later use. Okay, let's get started. So well again. Was the operator thing. We'll go and we'll create a project for our machines to be a member off helps with scoping for later on for security. I begin the process of adding machines to that project. Yeah. So the first thing we had to be in post, Yeah, many of the machine A name. Anything you want, que experimental zero one. Provide the IAP my user name type my password. Okay. On the Mac address for the common interface with the boot interface and then the i p m I i p address These machines will be at the time storage worker manager. He's a manager. Yeah, we're gonna add a number of other machines on will. Speed this up just so you could see what the process looks like in the future. Better discovery will be added to the product. Okay. Okay. Getting back there we have it are Six machines have been added, are busy being inspected, being added to the system. Let's have a look at the details of a single note. Yeah, you can see information on the set up of the node. Its capabilities? Yeah. As well as the inventory information about that particular machine. I see. Okay, let's go and create the cluster. Yeah, So we're going to deploy a bare metal child cluster. The process we're going to go through is pretty much the same as any other child cluster. So we'll credit custom. We'll give it a name, but if it were selecting bare metal on the region, we're going to select the version we want to apply. No way. We're going to add this search keys. If we hope we're going to give the load. Balancer host I p that we'd like to use out of dress range on update the address range that we want to use for the cluster. Check that the sea ideal blocks for the Cuban ladies and tunnels are what we want them to be. Enable disabled stack light. Yeah, and soothe stack light settings to find the cluster. And then, as for any other machine, we need to add machines to the cluster. Here. We're focused on building communities clusters, so we're gonna put the count of machines. You want managers? We're gonna pick the label type manager and create three machines is the manager for the Cuban eighties. Casting Okay thing. We're having workers to the same. It's a process. Just making sure that the worker label host level are I'm sorry. On when Wait for the machines to deploy. Let's go through the process of putting the operating system on the notes validating and operating system deploying doctor identifies Make sure that the cluster is up and running and ready to go. Okay, let's review the bold events waken See the machine info now populated with more information about the specifics of things like storage and of course, details of a cluster etcetera. Yeah, yeah, well, now watch the machines go through the various stages from prepared to deploy on what's the cluster build? And that brings us to the end of this particular demo. You can see the process is identical to that of building a normal child cluster we got our complaint is complete. >>All right, so there we have it, deploying a cluster to bare metal. Much the same is how we did for AWS. I guess maybe the biggest different stepwise there is there is that registration face first, right? So rather than just using AWS financials toe magically create PM's in the cloud. You got a point out all your bare metal servers to Dr Enterprise between the cloud and they really come in, I guess three profiles, right? You got your manager profile with a profile storage profile which has been labeled as allocate. Um, crossword cluster has appropriate, >>right? And And I think that the you know, the key differentiator here is that you have more physical control over what, uh, attributes that love your cat, by the way, uh, where you have the different attributes of a server of physical server. So you can, uh, ensure that the SSD configuration on the storage nodes is gonna be taken advantage of in the best way the GP use on the worker nodes and and that the management layer is going to have sufficient horsepower to, um, spin up to to scale up the the environments, as required. One of the things I wanted to mention, though, um, if I could get this out without the choking much better. Um, is that Ah, hey, mentioned the load balancer and I wanted to make sure in defining the load balancer and the load balancer ranges. Um, that is for the top of the the cluster itself. That's the operations of the management, uh, layer integrating with your systems internally to be able to access the the Cube Can figs. I I p address the, uh, in a centralized way. It's not the load balancer that's working within the kubernetes cluster that you are deploying. That's still cube proxy or service mesh, or however you're intending to do it. So, um, it's kind of an interesting step that your initial step in building this, um and we typically use things like metal L B or in gen X or that kind of thing is to establish that before we deploy this bear mental cluster so that it can ride on top of that for the tips and things. >>Very cool. So any other thoughts on what we've seen so far today? Bruce, we've gone through all the different layers. Doctor enterprise container clouds in these videos from our management are regional to our clusters on aws hand bear amount, Of course, with his dad is still available. Closing thoughts before we take just a very short break and run through these demos again. >>You know, I've been very exciting. Ah, doing the presentation with you. I'm really looking forward to doing it the second time, so that we because we've got a good rhythm going about this kind of thing. So I'm looking forward to doing that. But I think that the key elements of what we're trying to convey to the folks out there in the audience that I hope you've gotten out of it is that will that this is an easy enough process that if you follow the step by steps going through the documentation that's been put out in the chat, um, that you'll be able to give this a go yourself, Um, and you don't have to limit yourself toe having physical hardware on prim to try it. You could do it in a ws as we've shown you today. And if you've got some fancy use cases like, uh, you you need a Hadoop And and, uh, you know, cloud oriented ai stuff that providing a bare metal service helps you to get there very fast. So right. Thank you. It's been a pleasure. >>Yeah, thanks everyone for coming out. So, like I said we're going to take a very short, like, three minute break here. Uh, take the opportunity to let your colleagues know if they were in another session or they didn't quite make it to the beginning of this session. Or if you just want to see these demos again, we're going to kick off this demo. Siri's again in just three minutes at ten. Twenty five a. M. Pacific time where we will see all this great stuff again. Let's take a three minute break. I'll see you all back here in just two minutes now, you know. Okay, folks, that's the end of our extremely short break. We'll give people just maybe, like one more minute to trickle in if folks are interested in coming on in and jumping into our demo. Siri's again. Eso For those of you that are just joining us now I'm Bill Mills. I head up curriculum development for the training team here. Moran Tous on Joining me for this session of demos is Bruce. Don't you go ahead and introduce yourself doors, who is still on break? That's cool. We'll give Bruce a minute or two to get back while everyone else trickles back in. There he is. Hello, Bruce. >>How'd that go for you? Okay, >>Very well. So let's kick off our second session here. I e just interest will feel for you. Thio. Let it run over here. >>Alright. Hi. Bruce Matthews here. I'm the Western Regional Solutions architect for Marantz. Use A I'm the one with the gray hair and the glasses. Uh, the handsome one is Bill. So, uh, Bill, take it away. >>Excellent. So over the next hour or so, we've got a Siris of demos that's gonna walk you through your first steps with Dr Enterprise Container Cloud Doctor Enterprise Container Cloud is, of course, Miranda's brand new offering from bootstrapping kubernetes clusters in AWS bare metal open stack. And for the providers in the very near future. So we we've got, you know, just just over an hour left together on this session, uh, if you joined us at the top of the hour back at nine. A. M. Pacific, we went through these demos once already. Let's do them again for everyone else that was only able to jump in right now. Let's go. Our first video where we're gonna install Dr Enterprise container cloud for the very first time and use it to bootstrap management. Cluster Management Cluster, as I like to describe it, is our mother ship that's going to spin up all the other kubernetes clusters, Doctor Enterprise clusters that we're gonna run our workloads on. So I'm gonna do >>I'm so excited. I can hardly wait. >>Let's do it all right to share my video out here. Yeah, let's do it. >>Good day. The focus for this demo will be the initial bootstrap of the management cluster on the first regional clusters. To support AWS deployments, the management cluster provides the core functionality, including identity management, authentication, infantry release version. The regional cluster provides the specific architecture provided in this case AWS and the Elsom components on the UCP cluster Child cluster is the cluster or clusters being deployed and managed. The deployment is broken up into five phases. The first phase is preparing a bootstrap note on its dependencies on handling the download of the bridge struck tools. The second phase is obtaining America's license file. Third phase. Prepare the AWS credentials instead of the ideas environment, the fourth configuring the deployment, defining things like the machine types on the fifth phase, Run the bootstrap script and wait for the deployment to complete. Okay, so here we're sitting up the strap node. Just checking that it's clean and clear and ready to go there. No credentials already set up on that particular note. Now, we're just checking through aws to make sure that the account we want to use we have the correct credentials on the correct roles set up on validating that there are no instances currently set up in easy to instance, not completely necessary, but just helps keep things clean and tidy when I am perspective. Right. So next step, we're just gonna check that we can from the bootstrap note, reach more antis, get to the repositories where the various components of the system are available. They're good. No areas here. Yeah, right now we're going to start sitting at the bootstrap note itself. So we're downloading the cars release, get get cars, script, and then next we're going to run it. Yeah, I've been deployed changing into that big struck folder, just making see what's there right now we have no license file, so we're gonna get the license filed. Okay? Get the license file through more antis downloads site signing up here, downloading that license file and putting it into the Carisbrook struck folder. Okay, since we've done that, we can now go ahead with the rest of the deployment. Yeah, see what the follow is there? Uh huh. Once again, checking that we can now reach E C two, which is extremely important for the deployment. Just validation steps as we move through the process. Alright. Next big step is violating all of our AWS credentials. So the first thing is, we need those route credentials which we're going to export on the command line. This is to create the necessary bootstrap user on AWS credentials for the completion off the deployment we're now running in AWS policy create. So it is part of that is creating our food trucks script. Creating this through policy files onto the AWS, just generally preparing the environment using a cloud formation script, you'll see in a second, I'll give a new policy confirmations just waiting for it to complete. And there is done. It's gonna have a look at the AWS console. You can see that we're creative completed. Now we can go and get the credentials that we created. Good day. I am console. Go to the new user that's being created. We'll go to the section on security credentials and creating new keys. Download that information media access Key I. D and the secret access key, but usually then exported on the command line. Okay, Couple of things to Notre. Ensure that you're using the correct AWS region on ensure that in the conflict file you put the correct Am I in for that region? I'm sure you have it together in a second. Okay, thanks. Is key. So you could X key Right on. Let's kick it off. So this process takes between thirty and forty five minutes. Handles all the AWS dependencies for you. Um, as we go through, the process will show you how you can track it. Andi will start to see things like the running instances being created on the AWS side. The first phase off this whole process happening in the background is the creation of a local kind based bootstrapped cluster on the bootstrap node that clusters then used to deploy and manage all the various instances and configurations within AWS at the end of the process. That cluster is copied into the new cluster on AWS and then shut down that local cluster essentially moving itself over. Yeah, okay. Local clusters boat. Just waiting for the various objects to get ready. Standard communities objects here. Yeah, you mentioned Yeah. So we've speed up this process a little bit just for demonstration purposes. Okay, there we go. So first note is being built the bastion host just jump box that will allow us access to the entire environment. Yeah, In a few seconds, we'll see those instances here in the US console on the right. Um, the failures that you're seeing around failed to get the I. P for Bastian is just the weight state while we wait for AWS to create the instance. Okay. Yeah. Beauty there. Movies. Okay, sketch. Hello? Yeah, Okay. Okay. On. There we go. Question host has been built on three instances for the management clusters have now been created. Okay, We're going through the process of preparing. Those nodes were now copying everything over. See that scaling up of controllers in the big strapped cluster? It's indicating that we're starting all of the controllers in the new question. Almost there. Right? Okay. Just waiting for key. Clark. Uh huh. So finish up. Yeah. No. Now we're shutting down. Control this on the local bootstrap node on preparing our I. D. C configuration, fourth indication. So once this is completed, the last phase will be to deploy stack light into the new cluster, that glass on monitoring tool set, Then we go stack like deployment has started. Mhm. Coming to the end of the deployment mountain. Yeah, they were cut final phase of the deployment. And we are done. Yeah, you'll see. At the end, they're providing us the details of you. I log in. So there's a key Clark log in. Uh, you can modify that initial default possible is part of the configuration set up where they were in the documentation way. Go Councils up way can log in. Yeah. Yeah. Thank you very much for watching. >>All right, so at this point, what we have we got our management cluster spun up, ready to start creating work clusters. So just a couple of points to clarify there to make sure everyone caught that, uh, as advertised. That's darker. Enterprise container cloud management cluster. That's not rework loans. are gonna go right? That is the tool and you're gonna use to start spinning up downstream commodity documentary prize clusters for bootstrapping record too. >>And the seed host that were, uh, talking about the kind cluster dingy actually doesn't have to exist after the bootstrap succeeds eso It's sort of like, uh, copies head from the seed host Toothy targets in AWS spins it up it then boots the the actual clusters and then it goes away too, because it's no longer necessary >>so that bootstrapping know that there's not really any requirements, Hardly on that, right. It just has to be able to reach aws hit that Hit that a p I to spin up those easy to instances because, as you just said, it's just a kubernetes in docker cluster on that piece. Drop note is just gonna get torn down after the set up finishes on. You no longer need that. Everything you're gonna do, you're gonna drive from the single pane of glass provided to you by your management cluster Doctor enterprise Continue cloud. Another thing that I think is sort of interesting their eyes that the convict is fairly minimal. Really? You just need to provide it like aws regions. Um, am I? And that's what is going to spin up that spending that matter faster. >>Right? There is a mammal file in the bootstrap directory itself, and all of the necessary parameters that you would fill in have default set. But you have the option then of going in and defining a different Am I different for a different region, for example? Oh, are different. Size of instance from AWS. >>One thing that people often ask about is the cluster footprint. And so that example you saw they were spitting up a three manager, um, managing cluster as mandatory, right? No single manager set up at all. We want high availability for doctrine Enterprise Container Cloud management. Like so again, just to make sure everyone sort of on board with the life cycle stage that we're at right now. That's the very first thing you're going to do to set up Dr Enterprise Container Cloud. You're going to do it. Hopefully exactly once. Right now, you've got your management cluster running, and they're gonna use that to spend up all your other work clusters Day today has has needed How do we just have a quick look at the questions and then lets take a look at spinning up some of those child clusters. >>Okay, e think they've actually been answered? >>Yeah, for the most part. One thing I'll point out that came up again in the Dail, helpfully pointed out earlier in surgery, pointed out again, is that if you want to try any of the stuff yourself, it's all of the dogs. And so have a look at the chat. There's a links to instructions, so step by step instructions to do each and every thing we're doing here today yourself. I really encourage you to do that. Taking this out for a drive on your own really helps internalizing communicate these ideas after the after launch pad today, Please give this stuff try on your machines. Okay, So at this point, like I said, we've got our management cluster. We're not gonna run workloads there that we're going to start creating child clusters. That's where all of our work and we're gonna go. That's what we're gonna learn how to do in our next video. Cue that up for us. >>I so love Shawn's voice. >>Wasn't that all day? >>Yeah, I watched him read the phone book. >>All right, here we go. Let's now that we have our management cluster set up, let's create a first child work cluster. >>Hello. In this demo, we will cover the deployment experience of creating a new child cluster the scaling of the cluster on how to update the cluster. When a new version is available, we begin the process by logging onto the you I as a normal user called Mary. Let's go through the navigation of the u I. So you can switch Project Mary only has access to development. Uh huh. Get a list of the available projects that you have access to. What clusters have been deployed at the moment there. Man. Yes, this H keys, Associate ID for Mary into her team on the cloud credentials that allow you to create or access the various clouds that you can deploy clusters to finally different releases that are available to us. We can switch from dark mode to light mode, depending on your preferences. Right. Let's now set up some ssh keys for Mary so she can access the notes and machines again. Very simply, had Mississippi key give it a name. We copy and paste our public key into the upload key block. Or we can upload the key if we have the file available on our machine. A very simple process. So to create a new cluster, we define the cluster ad management nodes and add worker nodes to the cluster. Yeah, again, very simply, we got the clusters tab we had to create cluster button. Give the cluster name. Yeah, Andi, select the provider. We only have access to AWS in this particular deployment, so we'll stick to AWS. What's like the region in this case? US West one released version five point seven is the current release Onda Attach. Mary's Key is necessary key. We can then check the rest of the settings, confirming the provider any kubernetes c r D a r i p address information. We can change this. Should we wish to? We'll leave it default for now and then what components of stack light? I would like to deploy into my custom for this. I'm enabling stack light on logging, and I consider the retention sizes attention times on. Even at this stage, add any custom alerts for the watchdogs. Consider email alerting which I will need my smart host. Details and authentication details. Andi Slack Alerts. Now I'm defining the cluster. All that's happened is the cluster's been defined. I now need to add machines to that cluster. I'll begin by clicking the create machine button within the cluster definition. Oh, select manager, Select the number of machines. Three is the minimum. Select the instant size that I'd like to use from AWS and very importantly, ensure correct. Use the correct Am I for the region. I convinced side on the route. Device size. There we go. My three machines are busy creating. I now need to add some workers to this cluster. So I go through the same process this time once again, just selecting worker. I'll just add to once again the am I is extremely important. Will fail if we don't pick the right. Am I for a Clinton machine? In this case and the deployment has started, we can go and check on the bold status are going back to the clusters screen on clicking on the little three dots on the right. We get the cluster info and the events, so the basic cluster info you'll see pending their listen. Cluster is still in the process of being built. We kick on, the events will get a list of actions that have been completed This part of the set up of the cluster. So you can see here. We've created the VPC. We've created the sub nets on. We've created the Internet Gateway. It's unnecessary made of us. And we have no warnings of the stage. Okay, this will then run for a while. We have one minute past. We can click through. We can check the status of the machine balls as individuals so we can check the machine info, details of the machines that we've assigned mhm and see any events pertaining to the machine areas like this one on normal. Yeah. Just last. The community's components are waiting for the machines to start. Go back to customers. Okay, right. Because we're moving ahead now. We can see we have it in progress. Five minutes in new Matt Gateway. And at this stage, the machines have been built on assigned. I pick up the U S. Yeah, yeah, yeah. There we go. Machine has been created. See the event detail and the AWS. I'd for that machine. No speeding things up a little bit this whole process and to end takes about fifteen minutes. Run the clock forward, you'll notice is the machines continue to bold the in progress. We'll go from in progress to ready. A soon as we got ready on all three machines, the managers on both workers way could go on and we could see that now we reached the point where the cluster itself is being configured mhm and then we go. Cluster has been deployed. So once the classes deployed, we can now never get around. Our environment are looking into configure cluster. We could modify their cluster. We could get the end points for alert Alert Manager See here the griffon occupying and Prometheus are still building in the background but the cluster is available on You would be able to put workloads on it at this stage to download the cube conflict so that I can put workloads on it. It's again the three little dots in the right for that particular cluster. If the download cube conflict give it my password, I now have the Q conflict file necessary so that I can access that cluster. All right, Now that the build is fully completed, we can check out cluster info on. We can see that all the satellite components have been built. All the storage is there, and we have access to the CPU. I. So if we click into the cluster, we can access the UCP dashboard, click the signing with the clock button to use the SSO. We give Mary's possible to use the name once again. Thing is an unlicensed cluster way could license at this point. Or just skip it on. Do we have the UCP dashboard? You could see that has been up for a little while. We have some data on the dashboard going back to the console. We can now go to the griffon. A data just been automatically pre configured for us. We can switch and utilized a number of different dashboards that have already been instrumented within the cluster. So, for example, communities cluster information, the name spaces, deployments, nodes. Um, so we look at nodes. If we could get a view of the resource is utilization of Mrs Custer is very little running in it. Yeah, a general dashboard of Cuba Navies cluster. What If this is configurable, you can modify these for your own needs, or add your own dashboards on de scoped to the cluster. So it is available to all users who have access to this specific cluster. All right to scale the cluster on to add a No. This is simple. Is the process of adding a mode to the cluster, assuming we've done that in the first place. So we go to the cluster, go into the details for the cluster we select, create machine. Once again, we need to be ensure that we put the correct am I in and any other functions we like. You can create different sized machines so it could be a larger node. Could be bigger group disks and you'll see that worker has been added in the provisioning state. On shortly, we will see the detail off that worker as a complete to remove a note from a cluster. Once again, we're going to the cluster. We select the node we would like to remove. Okay, I just hit delete On that note. Worker nodes will be removed from the cluster using according and drawing method to ensure that your workloads are not affected. Updating a cluster. When an update is available in the menu for that particular cluster, the update button will become available. And it's a simple as clicking the button validating which release you would like to update to this case. This available releases five point seven point one give you I'm kicking the update back in the background. We will coordinate. Drain each node slowly, go through the process of updating it. Andi update will complete depending on what the update is as quickly as possible. Who we go. The notes being rebuilt in this case impacted the manager node. So one of the manager nodes is in the process of being rebuilt. In fact, to in this case, one has completed already. Yeah, and in a few minutes, we'll see that the upgrade has been completed. There we go. Great. Done. If you work loads of both using proper cloud native community standards, there will be no impact. >>All right, there. We haven't. We got our first workload cluster spun up and managed by Dr Enterprise Container Cloud. So I I loved Shawn's classic warning there. When you're spinning up an actual doctor enterprise deployment, you see little errors and warnings popping up. Just don't touch it. Just leave it alone and let Dr Enterprises self healing properties take care of all those very transient temporary glitches, resolve themselves and leave you with a functioning workload cluster within victims. >>And now, if you think about it that that video was not very long at all. And that's how long it would take you if someone came into you and said, Hey, can you spend up a kubernetes cluster for development development A. Over here, um, it literally would take you a few minutes to thio Accomplish that. And that was with a W s. Obviously, which is sort of, ah, transient resource in the cloud. But you could do exactly the same thing with resource is on Prem or resource is, um physical resource is and will be going through that later in the process. >>Yeah, absolutely one thing that is present in that demo, but that I like to highlight a little bit more because it just kind of glides by Is this notion of, ah, cluster release? So when Sean was creating that cluster, and also when when he was upgrading that cluster, he had to choose a release. What does that didn't really explain? What does that mean? Well, in Dr Enterprise Container Cloud, we have released numbers that capture the entire staff of container ization tools that will be deploying to that workload costume. So that's your version of kubernetes sed cor DNs calico. Doctor Engineer. All the different bits and pieces that not only work independently but are validated toe work together as a staff appropriate for production, humanities, adopted enterprise environments. >>Yep. From the bottom of the stack to the top, we actually test it for scale. Test it for CVS, test it for all of the various things that would, you know, result in issues with you running the application services. And I've got to tell you from having, you know, managed kubernetes deployments and things like that that if you're the one doing it yourself, it can get rather messy. Eso This makes it easy. >>Bruce, you were staying a second ago. They I'll take you at least fifteen minutes to install your release. Custer. Well, sure, but what would all the other bits and pieces you need toe? Not just It's not just about pressing the button to install it, right? It's making the right decision. About what components work? Well, our best tested toe be successful working together has a staff? Absolutely. We this release mechanism and Dr Enterprise Container Cloud. Let's just kind of package up that expert knowledge and make it available in a really straightforward, fashionable species. Uh, pre Confederate release numbers and Bruce is you're pointing out earlier. He's got delivered to us is updates kind of transparent period. When when? When Sean wanted toe update that cluster, he created little update. Custer Button appeared when an update was available. All you gotta do is click. It tells you what Here's your new stack of communities components. It goes ahead. And the straps those components for you? >>Yeah, it actually even displays at the top of the screen. Ah, little header That says you've got an update available. Do you want me to apply? It s o >>Absolutely. Another couple of cool things. I think that are easy to miss in that demo was I really like the on board Bafana that comes along with this stack. So we've been Prometheus Metrics and Dr Enterprise for years and years now. They're very high level. Maybe in in previous versions of Dr Enterprise having those detailed dashboards that Ravana provides, I think that's a great value out there. People always wanted to be ableto zoom in a little bit on that, uh, on those cluster metrics, you're gonna provides them out of the box for us. Yeah, >>that was Ah, really, uh, you know, the joining of the Miranda's and Dr teams together actually spawned us to be able to take the best of what Morantes had in the open stack environment for monitoring and logging and alerting and to do that integration in in a very short period of time so that now we've got it straight across the board for both the kubernetes world and the open stack world. Using the same tool sets >>warm. One other thing I wanna point out about that demo that I think there was some questions about our last go around was that demo was all about creating a managed workplace cluster. So the doctor enterprise Container Cloud managers were using those aws credentials provisioned it toe actually create new e c two instances installed Docker engine stalled. Doctor Enterprise. Remember all that stuff on top of those fresh new VM created and managed by Dr Enterprise contain the cloud. Nothing unique about that. AWS deployments do that on open staff doing on Parramatta stuff as well. Um, there's another flavor here, though in a way to do this for all of our long time doctor Enterprise customers that have been running Doctor Enterprise for years and years. Now, if you got existing UCP points existing doctor enterprise deployments, you plug those in to Dr Enterprise Container Cloud, uh, and use darker enterprise between the cloud to manage those pre existing Oh, working clusters. You don't always have to be strapping straight from Dr Enterprises. Plug in external clusters is bad. >>Yep, the the Cube config elements of the UCP environment. The bundling capability actually gives us a very straightforward methodology. And there's instructions on our website for exactly how thio, uh, bring in import and you see p cluster. Um so it it makes very convenient for our existing customers to take advantage of this new release. >>Absolutely cool. More thoughts on this wonders if we jump onto the next video. >>I think we should move press on >>time marches on here. So let's Let's carry on. So just to recap where we are right now, first video, we create a management cluster. That's what we're gonna use to create All our downstream were closed clusters, which is what we did in this video. Let's maybe the simplest architectures, because that's doing everything in one region on AWS pretty common use case because we want to be able to spin up workload clusters across many regions. And so to do that, we're gonna add a third layer in between the management and work cluster layers. That's gonna be our regional cluster managers. So this is gonna be, uh, our regional management cluster that exists per region that we're going to manage those regional managers will be than the ones responsible for spending part clusters across all these different regions. Let's see it in action in our next video. >>Hello. In this demo, we will cover the deployment of additional regional management. Cluster will include a brief architectural overview, how to set up the management environment, prepare for the deployment deployment overview, and then just to prove it, to play a regional child cluster. So looking at the overall architecture, the management cluster provides all the core functionality, including identity management, authentication, inventory and release version. ING Regional Cluster provides the specific architecture provider in this case, AWS on the L C M components on the d you speak cluster for child cluster is the cluster or clusters being deployed and managed? Okay, so why do you need original cluster? Different platform architectures, for example AWS open stack, even bare metal to simplify connectivity across multiple regions handle complexities like VPNs or one way connectivity through firewalls, but also help clarify availability zones. Yeah. Here we have a view of the regional cluster and how it connects to the management cluster on their components, including items like the LCN cluster Manager. We also machine manager. We're hell Mandel are managed as well as the actual provider logic. Okay, we'll begin by logging on Is the default administrative user writer. Okay, once we're in there, we'll have a look at the available clusters making sure we switch to the default project which contains the administration clusters. Here we can see the cars management cluster, which is the master controller. When you see it only has three nodes, three managers, no workers. Okay, if we look at another regional cluster, similar to what we're going to deploy now. Also only has three managers once again, no workers. But as a comparison is a child cluster. This one has three managers, but also has additional workers associate it to the cluster. Yeah, all right, we need to connect. Tell bootstrap note, preferably the same note that used to create the original management plaster. It's just on AWS, but I still want to machine Mhm. All right, A few things we have to do to make sure the environment is ready. First thing we're gonna pseudo into route. I mean, we'll go into our releases folder where we have the car's boot strap on. This was the original bootstrap used to build the original management cluster. We're going to double check to make sure our cube con figures there It's again. The one created after the original customers created just double check. That cute conflict is the correct one. Does point to the management cluster. We're just checking to make sure that we can reach the images that everything's working, condone, load our images waken access to a swell. Yeah, Next, we're gonna edit the machine definitions what we're doing here is ensuring that for this cluster we have the right machine definitions, including items like the am I So that's found under the templates AWS directory. We don't need to edit anything else here, but we could change items like the size of the machines attempts we want to use but the key items to ensure where changed the am I reference for the junta image is the one for the region in this case aws region of re utilizing. This was an open stack deployment. We have to make sure we're pointing in the correct open stack images. Yeah, yeah. Okay. Sit the correct Am I save the file? Yeah. We need to get up credentials again. When we originally created the bootstrap cluster, we got credentials made of the U. S. If we hadn't done this, we would need to go through the u A. W s set up. So we just exporting AWS access key and I d. What's important is Kaz aws enabled equals. True. Now we're sitting the region for the new regional cluster. In this case, it's Frankfurt on exporting our Q conflict that we want to use for the management cluster when we looked at earlier. Yeah, now we're exporting that. Want to call? The cluster region is Frankfurt's Socrates Frankfurt yet trying to use something descriptive? It's easy to identify. Yeah, and then after this, we'll just run the bootstrap script, which will complete the deployment for us. Bootstrap of the regional cluster is quite a bit quicker than the initial management clusters. There are fewer components to be deployed, but to make it watchable, we've spent it up. So we're preparing our bootstrap cluster on the local bootstrap node. Almost ready on. We started preparing the instances at us and waiting for the past, you know, to get started. Please the best your node, onda. We're also starting to build the actual management machines they're now provisioning on. We've reached the point where they're actually starting to deploy Dr Enterprise, he says. Probably the longest face we'll see in a second that all the nodes will go from the player deployed. Prepare, prepare Mhm. We'll see. Their status changes updates. It was the first word ready. Second, just applying second. Grady, both my time away from home control that's become ready. Removing cluster the management cluster from the bootstrap instance into the new cluster running a data for us? Yeah, almost a on. Now we're playing Stockland. Thanks. Whichever is done on Done. Now we'll build a child cluster in the new region very, very quickly. Find the cluster will pick our new credential have shown up. We'll just call it Frankfurt for simplicity. A key on customers to find. That's the machine. That cluster stop with three manages set the correct Am I for the region? Yeah, Same to add workers. There we go. That's the building. Yeah. Total bill of time. Should be about fifteen minutes. Concedes in progress. Can we expect this up a little bit? Check the events. We've created all the dependencies, machine instances, machines. A boat? Yeah. Shortly. We should have a working caster in the Frankfurt region. Now almost a one note is ready from management. Two in progress. On we're done. Trust us up and running. >>Excellent. There we have it. We've got our three layered doctor enterprise container cloud structure in place now with our management cluster in which we scrap everything else. Our regional clusters which manage individual aws regions and child clusters sitting over depends. >>Yeah, you can. You know you can actually see in the hierarchy the advantages that that presents for folks who have multiple locations where they'd like a geographic locations where they'd like to distribute their clusters so that you can access them or readily co resident with your development teams. Um and, uh, one of the other things I think that's really unique about it is that we provide that same operational support system capability throughout. So you've got stack light monitoring the stack light that's monitoring the stack light down to the actual child clusters that they have >>all through that single pane of glass that shows you all your different clusters, whether their workload cluster like what the child clusters or usual clusters from managing different regions. Cool. Alright, well, time marches on your folks. We've only got a few minutes left and I got one more video in our last video for the session. We're gonna walk through standing up a child cluster on bare metal. So so far, everything we've seen so far has been aws focus. Just because it's kind of easy to make that was on AWS. We don't want to leave you with the impression that that's all we do, we're covering AWS bare metal and open step deployments as well documented Craftsman Cloud. Let's see it in action with a bare metal child cluster. >>We are on the home stretch, >>right. >>Hello. This demo will cover the process of defining bare metal hosts and then review the steps of defining and deploying a bare metal based doctor enterprise cluster. Yeah, so why bare metal? Firstly, it eliminates hyper visor overhead with performance boost of up to thirty percent provides direct access to GP use, prioritize for high performance wear clothes like machine learning and AI, and support high performance workouts like network functions, virtualization. It also provides a focus on on Prem workloads, simplifying and ensuring we don't need to create the complexity of adding another hyper visor layer in between. So continuing on the theme Why communities and bare metal again Hyper visor overhead. Well, no virtualization overhead. Direct access to hardware items like F p g A s G p, us. We can be much more specific about resource is required on the nodes. No need to cater for additional overhead. We can handle utilization in the scheduling better Onda. We increase the performance and simplicity of the entire environment as we don't need another virtualization layer. Yeah, In this section will define the BM hosts will create a new project. Will add the bare metal hosts, including the host name. I put my credentials. I pay my address, Mac address on, then provide a machine type label to determine what type of machine it is. Related use. Okay, let's get started Certain Blufgan was the operator thing. We'll go and we'll create a project for our machines to be a member off. Helps with scoping for later on for security. I begin the process of adding machines to that project. Yeah. Yeah. So the first thing we had to be in post many of the machine a name. Anything you want? Yeah, in this case by mental zero one. Provide the IAP My user name. Type my password? Yeah. On the Mac address for the active, my interface with boot interface and then the i p m i P address. Yeah, these machines. We have the time storage worker manager. He's a manager. We're gonna add a number of other machines on will speed this up just so you could see what the process. Looks like in the future, better discovery will be added to the product. Okay, Okay. Getting back there. We haven't Are Six machines have been added. Are busy being inspected, being added to the system. Let's have a look at the details of a single note. Mhm. We can see information on the set up of the node. Its capabilities? Yeah. As well as the inventory information about that particular machine. Okay, it's going to create the cluster. Mhm. Okay, so we're going to deploy a bare metal child cluster. The process we're going to go through is pretty much the same as any other child cluster. So credit custom. We'll give it a name. Thank you. But he thought were selecting bare metal on the region. We're going to select the version we want to apply on. We're going to add this search keys. If we hope we're going to give the load. Balancer host I p that we'd like to use out of the dress range update the address range that we want to use for the cluster. Check that the sea idea blocks for the communities and tunnels are what we want them to be. Enable disabled stack light and said the stack light settings to find the cluster. And then, as for any other machine, we need to add machines to the cluster. Here we're focused on building communities clusters. So we're gonna put the count of machines. You want managers? We're gonna pick the label type manager on create three machines. Is a manager for the Cuban a disgusting? Yeah, they were having workers to the same. It's a process. Just making sure that the worker label host like you are so yes, on Duin wait for the machines to deploy. Let's go through the process of putting the operating system on the notes, validating that operating system. Deploying Docker enterprise on making sure that the cluster is up and running ready to go. Okay, let's review the bold events. We can see the machine info now populated with more information about the specifics of things like storage. Yeah, of course. Details of a cluster, etcetera. Yeah, Yeah. Okay. Well, now watch the machines go through the various stages from prepared to deploy on what's the cluster build, and that brings us to the end of this particular do my as you can see the process is identical to that of building a normal child cluster we got our complaint is complete. >>Here we have a child cluster on bare metal for folks that wanted to play the stuff on Prem. >>It's ah been an interesting journey taken from the mothership as we started out building ah management cluster and then populating it with a child cluster and then finally creating a regional cluster to spread the geographically the management of our clusters and finally to provide a platform for supporting, you know, ai needs and and big Data needs, uh, you know, thank goodness we're now able to put things like Hadoop on, uh, bare metal thio in containers were pretty exciting. >>Yeah, absolutely. So with this Doctor Enterprise container cloud platform. Hopefully this commoditized scooping clusters, doctor enterprise clusters that could be spun up and use quickly taking provisioning times. You know, from however many months to get new clusters spun up for our teams. Two minutes, right. We saw those clusters gets better. Just a couple of minutes. Excellent. All right, well, thank you, everyone, for joining us for our demo session for Dr Enterprise Container Cloud. Of course, there's many many more things to discuss about this and all of Miranda's products. If you'd like to learn more, if you'd like to get your hands dirty with all of this content, police see us a training don Miranda's dot com, where we can offer you workshops and a number of different formats on our entire line of products and hands on interactive fashion. Thanks, everyone. Enjoy the rest of the launchpad of that >>thank you all enjoy.

>> Hello, everyone. I'm Khalil Ahmad, Senior Director, Architecture at S&P Global. I have been working with S&P Global for six years now. Previously, I worked for Citigroup and Prudential. Overall, I have been part of IT industry for 30 years, and most of my professional career has been within financial sector in New York City metro area. I live in New Jersey with my wife and son, Daniel Khalil. I have a Master degree in software engineering from the University of Scranton, and Master in mathematics University of Punjab, Lahore. And currently I am pursuing TRIUM global Executive MBA. A joint program from the NYU Stern, LSE and HEC Paris. So today, I'm going to talk about building multi-cluster scalable container platform, supporting on-prem hybrid and multicloud use cases, how we leverage that with an S&P Global and what was our best story. As far as the agenda is concerned, I will go over, quickly the problem statement. Then I will mention the work of our core requirements, how we get solutioning, how Docker Enterprise helped us. And at the end, I will go over the pilot deployment for a proof of concept which we leverage. So, as far as the problem statement is concerned. Containers, as you all know, in the enterprise are becoming mainstream but expertise remains limited and challenges are mounting as containers enter production. Some companies are building skills internally and someone looking for partners that can help catalyze success, and choosing more integrated solutions that accelerate deployments and simplify the container environment. To overcome the challenges, we at S&P Global started our journey a few years back, taking advantage of both options. So, first of all, we met with all the stakeholder, application team, Product Manager and we define our core requirements. What we want out of this container platform, which supports multicloud and hybrid supporting on-prem as well. So, as you see my core requirements, we decided that we need first of all a roadmap or container strategy, providing guidelines on standards and specification. Secondly, with an S&P Global, we decided to introduce Platform as a Service approach, where we bring the container platform and provide that as a service internally to our all application team and all the Product Managers. Hosting multiple application on-prem as well as in multicloud. Third requirement was that we need Linux and Windows container support. In addition to that, we would also require hosted secure image registry with role based access control and image security scanning. In addition to that, we also started DevOps journey, so we want to have a full support of CI/CD pipeline. Whatever the solution we recommend from the architecture group, it should be easily integrated to the developer workstation. And developer workstation could be Windows, Mac or Linux. Orchestration, performance and control were few other parameter which we'll want to keep in mind. And the most important, dynamic scaling of container clusters. That was something we were also want to achieve, when we introduce this Platform as a Service. So, as far as the standard specification are concerned, we turn to the Open Container Initiative, the OCI. OCI was established in June 2015 by Docker and other leaders in the technology industry. And OCI operates under Linux Foundation, and currently contains two specification, runtime specification and image specification. So, at that time, it was a no brainer, other than to just stick with OCI. So, we are following the industry standard and specifications. Now the next step was, okay, the container platform. But what would be our runtime engine? What would be orchestration? And how we support, in our on-prem as well as in the multicloud infrastructure? So, when it comes to runtime engine, we decided to go with the Docker. Which is by default, runtime engine and Kubernetes. And if I may mention, DataDog in one of their public report, they say Docker is probably the most talked about infrastructure technology for the past few years. So, sticking to Docker runtime engine was another win-win game and we saw in future not bringing any challenge or issues. When it comes to orchestration. We prefer Kubernetes but that time there was a challenge, Kubernetes did not support Windows container. So, we wanted something which worked with a Linux container, and also has the ability or to orchestrate Windows containers. So, even though long term we want to stick to Kubernetes, but we also wanted to have a Docker swarm. When it comes to on-prem and multicloud, technically you could only support as of now, technology may change in future, but as of now, you can only support if you bring your own orchestration too. So, in our case, if we have control over orchestration control and not locked in with one cloud provider, that was the ideal situation. So, with all that, research, R&D and finding, we found Docker Enterprise. Which is securely built, share and run modern applications anywhere. So, when we come across Docker Enterprise, we were pleased to see that it meets our most of the core requirements. Whether it is coming on the developer machine, to integrating their workstation, building the application. Whether it comes to sharing those application, in a secure way and collaborating with our pipeline. And the lastly, when it comes to the running. If we run in hybrid or multicloud or edge, in Kubernetes, Docker Enterprise have the support all the way. So, three area one I just call up all the Docker Enterprise, choice, flexibility and security. I'm sure there's a lot more features in Docker Enterprise as a suite. But, when we looked at these three words very quickly, simplified hybrid orchestration. Define application centric policies and boundaries. Once you define, you're all set. Then you just maintain those policies. Manage diverse application across mixed infrastructure, with secure segmentation. Then it comes to secure software supply chain. Provenance across the entire lifecycle of apps and infrastructure through enforceable policy. Consistently manage all apps and infrastructure. And lastly, when it comes to infrastructure independence. It was easily forever lift and shift, because same time, our cloud journey was in the flight. We were moving from on-prem to the cloud. So, support for lift and shift application was one of our wishlist. And Docker Enterprise did not disappoint us. It also supported both traditional and micro services apps on any infrastructure. So, here we are, Docker Enterprise. Why Docker Enterprise? Some of the items in previous slides I mentioned. But in addition to those industry-leading platform, simplifying the IT operations, for running modern application at scale, anywhere. Docker Enterprise also has developer tools. So, the integration, as I mentioned earlier was smooth. In addition to all these tools, the main two components, the Universal Control Plane and the Docker Trusted Registry, solve lot of our problems. When it comes to the orchestration, we have our own Universal Control Plane. Which under the hood, manages Kubernetes and Docker swarm both clusters. So, guess what? We have a Windows support, through Docker swarm and we have a Linux support through Kubernetes. Now that paradigm has changed, as of today, Kubernetes support Windows container. So, guess what? We are well after the UCP, because we have our own orchestration tool, and we start managing Kubernetes cluster in Linux and introduce now, Windows as well. Then comes to the Docker Trusted Registry. Integrated Security and role based access control, made a very smooth transition from our RT storage to DTR. In addition to that, binary level scanning was another good feature from the security point of view. So that, these all options and our R&D landed the Docker Enterprise is the way to go. And if we go over the Docker Enterprise, we can spin up multiple clusters on-prem and in the cloud. And we have a one centralized location to manage those clusters. >> Khalil: So, with all that, now let's talk about how what was our pilot deployment, for proof of concept. In this diagram, you can see we, on the left side is our on-prem Data Center, on the right side is AWS, US East Coast. We picked up one region three zones. And on-prem, we picked up our Data Center, one of the Data Center in the United States of America, and we started the POC. So, our Universal Control Plane had a five nodes cluster. Docker Trusted Registry, also has a five node cluster. And the both, but in our on-prem Data Center. When it comes to the worker nodes, we have started with 18 node cluster, on the Linux side and the four node cluster on the Windows side. Because the major footprint which we have was on the Linux side, and the Windows use cases were pretty small. Also, this is just a proof of concept. And in AWS, we mimic the same web worker nodes, virtual to what we have on-prem. We have a 13 nodes cluster on Linux. And we started with four node cluster of Windows container. And having the direct connect from our Data Center to AWS, which was previously existing, so we did not have any connectivity or latency issue. Now, if you see in this diagram, you have a centralized, Universal Control Plane and your trusted registry. And we were able to spin up a cluster, on-prem as well as in the cloud. And we made this happen, end to end in record time. So later, when we deploy this in production, we also added another cloud provider. So, what you see the box on the right side, we just duplicate test that box in another cloud platform. So, now other orchestration tool, managing on-prem and multicloud clusters. Now, in your use case, you may find this little, you know, more in favor of on-prem. But that fit in our use case. Later, we did have expanded the cluster of Universal Control Plane and DTR in the cloud as well. And the clusters have gone and hundreds and thousands of worker nodes span over two cloud providers, third being discussed. And this solution has been working so far, very good. We did not see any downtime, not a single instance. And we were able to provide multicloud platform, container Platform as a Service for our S&P Global. Thank you for your time. If any questions, I have put my LinkedIn and Twitter account holder, you're welcome to ask any question

(bright music) >> Announcer: It's theCUBE. Covering the Virtual Vertica Big Data Conference 2020, brought to you by Vertica. Hello everybody, welcome back to theCUBE's coverage of the Vertica Big Data Conference, the Virtual BDC. My name is Dave Volante, and you're watching theCUBE. And we're here with Joe Gonzalez, who is a Vertica DBA, at MassMutual Financial. Joe, thanks so much for coming on theCUBE I'm sorry that we can't be face to face in Boston, but at least we're being responsible. So thank you for coming on. >> (laughs) Thank you for having me. It's nice to be here. >> Yeah, so let's set it up. We'll talk about, you know, a little bit about MassMutual. Everybody knows it's a big financial firm, but what's your role there and kind of your mission? >> So my role is Vertica DBA. I was hired January of last year to come on and manage their Vertica cluster. They've been on Vertica for probably about a year and a half before that started out on on-prem cluster and then move to AWS Enterprise in the cloud, and brought me on just as they were considering transitioning over to Vertica's EON mode. And they didn't really have anybody dedicated to Vertica, nobody who really knew and understood the product. And I've been working with Vertica for about probably six, seven years, at that point. I was looking for something new and landed a really good opportunity here with a great company. >> Yeah, you have a lot of experience in Vertica. You had a role as a market research, so you're a data guy, right? I mean that's really what you've been doing your entire career. >> I am, I've worked with Pitney Bowes, in the postage industry, I worked with healthcare auditing, after seven years in market research. And then I've been with MassMutual for a little over a year now, yeah, quite a lot. >> So tell us a little bit about kind of what your objectives are at MassMutual, what you're kind of doing with the platform, what application just supporting, paint a picture for us if you would. >> Certainly, so my role is, MassMutual just decided to make Vertica its enterprise data warehouse. So they've really bought into Vertica. And we're moving all of our data there probably about to good 80, 90% of MassMutual's data is going to be on the Vertica platform, in EON mode. So, and we have a wide usage of that data across corporation. Right now we're about 50 terabytes and growing quickly. And a wide variety of users. So there's a lot of ETLs coming in overnight, loading a lot of data, transforming a lot of data. And a lot of reporting tools are using it. So currently, Tableau MicroStrategy. We have Alteryx using it, and we also have API's running against it throughout the day, 24/7 with people coming in, especially now these days with the, you know, some financial uncertainty going on. A lot of people coming and checking their 401k's, checking their insurance and status and what not. So we have to handle a lot of concurrent traffic on top of the normal big query. So it's a quite diverse cluster. And I'm glad they're really investing in using Vertica as their overall solution for this. >> Yeah, I mean, these days your 401k like this, right? (laughing) Afraid to look. So I wonder, Joe if you could share with our audience. I mean, for those who might not be as familiar with the history of just Vertica, and specifically, about MPP, you've had historically you have, you know, traditional RDBMS, whether it's Db2 or Oracle, and then you had a spate of companies that came out with this notion of MPP Vertica is the one that, I think it's probably one of the few if only brands that they've survived, but what did that bring to the industry and why is that important for people to understand, just in terms of whatever it is, scale, performance, cost. Can you explain that? >> To me, it actually brought scale at good cost. And that's why I've been a big proponent of Vertica ever since I started using it. There's a number, like you said of different platforms where you can load big data and store and house big data. But the purpose of having that big data is not just for it to sit there, but to be used, and used in a variety of ways. And that's from, you know, something small, like the first installation I was on was about 10 terabytes. And, you know, I work with the data warehouses up to 100 terabytes, and, you know, there's Vertica installations with, you know, hundreds of petabytes on them. You want to be able to use that data, so you need a platform that's going to be able to access that data and get it to the clients, get it to the customers as quickly as possible, and not paying an arm and a leg for the privilege to do so. And Vertica allows companies to do that, not only get their data to clients and you know, in company users quickly, but save money while doing so. >> So, but so, why couldn't I just use a traditional RDBMS? Why not just throw it all into Oracle? >> One, cost, Oracle is very expensive while Vertica's a lot more affordable than that. But the column-score structure of Vertica allows for a lot more optimized queries. Some of the queries that you can run in Vertica in 2, 3, 4 seconds, will take minutes and sometimes hours in an RDBMS, like Oracle, like SQL Server. They have the capability to store that amount of data, no question, but the usability really lacks when you start querying tables that are 180 billion column, 180 billion rows rather of tables in Vertica that are over 1000 columns. Those will take hours to run on a traditional RDBMS and then running them in Vertica, I get my queries back in a sec. >> You know what's interesting to me, Joe and I wonder if you could comment, it seems that Vertica has done a good job of embracing, you know, riding the waves, whether it was HDFS and the big data in our early part of the big data era, the machine learning, machine intelligence. Whether it's, you know, TensorFlow and other data science tools, it seems like Vertica somehow in the cloud is the other one, right? A lot of times cloud is super disruptive, particularly to companies that started on-prem, it seems like Vertica somehow has been able to adopt and embrace some of these trends. Why, from your standpoint, first of all, from your standpoint, as a customer, is that true? And why do you think that is? Is it architectural? Is it true mindset engineering? I wonder if you could comment on that. >> It's absolutely true, I've started out again, on an on-prem Vertica data warehouse, and we kind of, you know, rolled kind of along with them, you know, more and more people have been using data, they want to make it accessible to people on the web now. And you know, having that, the option to provide that data from an on-prem solution, from AWS is key, and now Vertica is offering even a hybrid solution, if you want to keep some of your data behind a firewall, on-prem, and put some in the cloud as well. So data at Vertica has absolutely evolved along with the industry in ways that no other company really has that I've seen. And I think the reason for it and the reason I've stayed with Vertica, and specifically have remained at Vertica DBA for the last seven years, is because of the way Vertica stays in touch with it's persons. I've been working with the same people for the seven, eight years, I've been using Vertica, they're family. I'm part of their family, and you know, I'm good friends with some of these people. And they really are in tune not only with the customer but what they're doing. They really sit down with you and have those conversations about, you know, what are your needs? How can we make Vertica better? And they listen to their clients. You know, just having access to the data engineers who develop Vertica to be arranged on a phone call or whatnot, I've never had that with any other company. Vertica makes that available to their customers when they need it. So the personal touch is a huge for them. >> That's good, it's always good to get the confirmation from the practitioners, just not hear from the vendor. I want to ask you about the EON transition. You mentioned that MassMutual brought you in to help with that. What were some of the challenges that you faced? And how did you get over them? And what did, what is, why EON? You know, what was the goal, the outcome and some of the challenges maybe that you had to overcome? >> Right. So MassMutual had an interesting setup when I first came in. They had three different Vertica clusters to accommodate three different portions of their business. The data scientists who use the data quite extensively in very large queries, very intense queries, their work with their predictive analytics and whatnot. It was a separate one for the API's, which needed, you know, sub-second query response times. And the enterprise solution, they weren't always able to get the performance they needed, because the fast queries were being overrun by the larger queries that needed more resources. And then they had a third for starting to develop this enterprise data platform and started, you know, looking into their future. The first challenge was, first of all, bringing all those three together, and back into a single cluster, and allowing our users to have both of the heavy queries and the API queries running at the same time, on the same platform without having to completely separate them out onto different clusters. EON really helps with that because it allows to store that data in the S3 communal storage, have the main cluster set up to run the heavy queries. And then you can set up sub clusters that still point to that S3 data, but separates out the compute so that the API's really have their own resources to run and not be interfered with by the other process. >> Okay, so that, I'm hearing a couple of things. One is you're sort of busting down data silos. So you're able to have a much more coherent view of your data, which I would imagine is critical, certainly. Companies like MassMutual, have been around for 100 years, and so you've got all kinds of data dispersed. So to the extent that you can break down those silos, that's important, but also being able to I guess have granular increments of compute and storage is what I'm hearing. What does that do for you? It make that more efficient? Well, they are other business benefits? Maybe you could elucidate. >> Well, one cost is again, a huge benefit, the cost of running three different clusters in even AWS, in the enterprise solution was a little costly, you know, you had to have your dedicated servers here and there. So you're paying for like, you know, 12, 15 different servers, for example. Whereas we bring them all back into EON, I can run everything on a six-node production cluster. And you know, when things are busy, I can spin up the three-node top cluster for the API's, only paid for when I need them, and then bring them back into the main cluster when things are slowed down a bit, and they can get that performance that they need. So that saves a ton on resource costs, you know, you're not paying for the storage, you're paying for one S3 bucket, you're only paying for the nodes, these are two instances, that are up and running when you need them., and that is huge. And again, like you said, it gives us the ability to silo our data without having to completely separate our data into different storage areas. Which is a big benefit, it gives us the ability to query everything from one single cluster without having to synchronize it to, you know, three different ones. So this one going to have there's, this one going to have there's, but everyone's still looking at the same data and replicate that in QA and Devs so that people can do it outside of production and do some testing as well. >> So EON, obviously a very important innovation. And of course, Vertica touts the difference between others who separate huge storage, and you know, they're not the only one that does that, but they are really I think the only one that does it for on-prem, and virtually across clouds. So my question is, and I think you're doing a breakout session on the Virtual BDC. We're going to be in Boston, now we're doing it online. If I'm in the audience, I'm imagining I'm a junior DBA at an organization that maybe doesn't have a Joe. I haven't been an expert for seven years. How hard is it for me to get, what do I need to do to get up to speed on EON? It sounds great, I want it. I'm going to save my company money, but I'm nervous 'cause I've only been at Vertica DBA for, you know, a year, and I'm sort of, you know, not as experienced as you. What are the things that I should be thinking about? Do I need to bring in? Do I need to hire somebody? Do I need to bring in a consultant? Can I learn it myself? What would you advise? >> It's definitely easy enough that if you have at least a little bit of work experience, you can learn it yourself, okay? 'Cause the concepts are still there. There's some you know, little bits of nuances where you do need to be aware of certain changes between the Enterprise and EON edition. But I would also say consult with your Vertica Account Manager, consult with your, you know, let them bring in the right people from Vertica to help you get up to speed and if you need to, there are also resources available as far as consultants go, that will help you get up to speed very quickly. And we did work together with Vertica and with one of their partners, Clarity, in helping us to understand EON better, set it up the right way, you know, how do we take our, the number of shards for our data warehouse? You know, they helped us evaluate all that and pick the right number of shards, the right number of nodes to get set up and going. And, you know, helped us figure out the best ways to get our data over from the Enterprise Edition into EON very quickly and very efficient. So different with yourself. >> I wanted to ask you about organizational, you know, issues because, you know, the guys like you practitioners always tell me, "Look, the tech, technology comes and goes, that's kind of the easy part, we're good at that. It's the people it's the processes, the skill sets." What does your, you know, team regime look like? And do you have any sort of ideal team makeup or, you know, ideal advice, is it two piece of teams? Is it what kind of skills? What kind of interaction and communications to senior leadership? I wonder if you could just give us some color on that. >> One of the things that makes me extremely proud to be working for MassMutual right now, is that they do what a lot of companies have not been doing and that is investing in IT. They have put a lot of thought, a lot of money, and a lot of support into setting up their enterprise data platform and putting Vertica at the center. And not only did they put the money into getting the software that they needed, like Vertica, you know, MicroStrategy, and all the other tools that we were using to use that, they put the money in the people. Our managers are extremely supportive of us. We hired about 40 to 45 different people within a four-month time frame, data engineers, data analysts, data modelers, a nice mix of people across who can help shape your data and bring the data in and help the users use the data properly, and allow me as the database administrator to make sure that they're doing what they're doing most efficiently and focus on my job. So you have to have that diversity among the different data skills in order to make your team successful. >> That's awesome. Kind of a side question, and it's really not Vertica's wheelhouse, but I'm curious, you know, in the early days of the big data, you know, movement, a lot of the data scientists would complain, and they still do that, "80% of my time is spent wrangling data." The tools for the data engineer, the data scientists, the database, you know, experts, they're all different. And is that changing? And to what degree is that changing? Kind of what ending are we in and just in terms of a more facile environment for all those roles? >> Again, I think it depends on company to company, you know, what resources they make available to the data scientists. And the data scientists, we have a lot of them at MassMutual. And they're very much into doing a lot of machine learning, model training, predictive analytics. And they are, you know, used to doing it outside of Vertica too, you know, pulling that data out into Python and Scalars Bar, and tools like that. And they're also now just getting into using Vertica's in-database analytics and machine learning, which is a skill that, you know, definitely nobody else out there has. So being able to have one somebody who understands Vertica like myself, and being able to train other people to use Vertica the way that is most efficient for them is key. But also just having people who understand not only the tools that you're using, but how to model data, how to architect your tables, your schemas, the interaction between your tables and schemas and whatnot, you need to have that diversity in order to make this work. And our data scientists have benefited immensely from the struct that MassMutual put in place by our data management delivery team. >> That's great, I think I saw, somewhere in your background, that you've trained about 100 people in Vertica. Did I get that right? >> Yes, I've, since I started here, I've gone to our Boston location, our Springfield location, and our New York City location and trained, probably about this point, about 120, 140 of our Vertica users. And I'm trying to do, you know, a couple of follow-up sessions per year. >> So adoption, obviously, is a big goal of yours. Getting people to adopt the platform, but then more importantly, I guess, deliver business value and outcomes. >> Absolutely. >> Yeah, I wanted to ask you about encryption. You know, in the perfect world, everything would be encrypted, but there are trade offs. Are you using encryption? What are you doing in that regard? >> We are actually just getting into that now due to the New York and the CCPA regulations that are now in place. We do have a lot of Person Identifiable Information in our data store that does require encryption. So we are going through a month's long process that started in December, I think, it's actually a bit earlier than that, to start identifying all the columns, not only in our Vertica database, but in, you know, the other databases that we do use, you know, we have Postgres database, SQL Server, Teradata for the time being, until that moves into Vertica. And identify where that data sits, what downstream applications, pull that data from the data sources and store it locally as well, and starts encrypting that data. And because of the tight relationship between Voltage and Vertica, we settled on Voltages as the major platform to start doing that encryption. So we're going to be implementing that in Vertica probably within the next month or two, and roll it out to all the teams that have data that requires encryption. We're going to start rolling it out to the downstream application owners to make sure that they are encrypting the data as they get it pulled over. And we're also using another product for several other applications that don't mesh well as well with both. >> Voltage being micro, focuses encryption solution, correct? >> Right, yes. >> Yes, of course, like a focus for the audience's is the, it owns Vertica and if Vertica is a separate brand. So I want to ask you kind of close on what success looks like. You've been at this for a number of years, coming into MassMutual which was great to hear. I've had some past experience with MassMutual, it's an awesome company, I've been to the Springfield facility and in Boston as well, and I have great respect for them, and they've really always been a leader. So it's great to hear that they're investing in technology as a differentiator. What does success look like for you? Let's say you're at MassMutual for a few years, you're looking back, what success look like? Go. >> A good question. It's changing every day just, you know, with more and more, you know, applications coming onboard, more and more data being pulled in, more uses being found for the data that we have. I think success for me is making sure that Vertica, first of all, is always up made, is always running at its most optimal to keep our users happy. I think when I started, you know, we had a lot of processes that were running, you know, six, seven hours, some of them were taking, you know, almost a day long, because they were so complicated, we've got those running in under an hour now, some of them running in a matter of minutes. I want to keep that optimization going for all of our processes. Like I said, there's a lot of users using this data. And it's been hard over the first year of me being here to get to all of them. And thankfully, you know, I'm getting a bit of help now, I have a couple of system DBAs, and I'm training up to help out with these optimizations, you know, fixing queries, fixing projections to make sure that queries do run as quickly as possible. So getting that to its optimal stage is one. Two, getting our data encrypted and protected so that even if for whatever reasons, somehow somebody breaks into our data, they're not going to be able to get anything at all, because our data is 100% protected. And I think more companies need to be focusing on that as well. And third, I want to see our data science teams using more and more of Vertica's in-database predictive analytics, in-database machine learning products, and really helping make their jobs more efficient by doing so. >> Joe, you're awesome guest I mean, we always like I said, love having the practitioners on and getting the straight, skinny and pros. You're welcome back anytime, and as I say, I wish we could have met in Boston, maybe next year at the BDC. But it's great to have you online, and thanks for coming on theCUBE. >> And thank you for having me and hopefully we'll meet next year. >> Yeah, I hope so. And thank you everybody for watching that. Remember theCUBE is running concurrent with the Vertica Virtual BDC, it's vertica.com/bdc2020. If you want to check out all the keynotes, and all the breakout sessions, I'm Dave Volante for theCUBE. We'll be going. More interviews, for people right there. Thanks for watching. (bright music)

>> Sue: Hi, everybody. Thank you for joining us today, for the Virtual Vertica BDC 2020. This breakout session is entitled "Vertica @ Uber Scale" My name is Sue LeClaire, Director of Marketing at Vertica. And I'll be your host for this webinar. Joining me is Girish Baliga, Director I'm sorry, user, Uber Engineering Manager of Big Data at Uber. Before we begin, I encourage you to submit questions or comments during the virtual session. You don't have to wait, just type your question or comment in the question box below the slides and click Submit. There will be a Q and A session, at the end of the presentation. We'll answer as many questions as we're able to during that time. Any questions that we don't address, we'll do our best to answer offline. Alternately, you can also Vertica forums to post your questions there after the session. Our engineering team is planning to join the forums to keep the conversation going. And as a reminder, you can maximize your screen by clicking the double arrow button, in the lower right corner of the slides. And yet, this virtual session is being recorded, and you'll be able to view on demand this week. We'll send you a notification as soon as it's ready. So let's get started. Girish over to you. >> Girish: Thanks a lot Sue. Good afternoon, everyone. Thanks a lot for joining this session. My name is Girish Baliga. And as Sue mentioned, I manage interactive and real time analytics teams at Uber. Vertica is one of the main platforms that we support, and Vertica powers a lot of core business use cases. In today's talk, I wanted to cover two main things. First, how Vertica is powering critical business use cases, across a variety of orgs in the company. And second, how we are able to do this at scale and with reliability, using some of the additional functionalities and systems that we have built into the Vertica ecosystem at Uber. And towards the end, I also have a little extra bonus for all of you. I will be sharing an easy way for you to take advantage of, many of the ideas and solutions that I'm going to present today, that you can apply to your own Vertica deployments in your companies. So stick around and put on your seat belts, and let's go start on the ride. At Uber, our mission is to ignite opportunity by setting the world in motion. So we are focused on solving mobility problems, and enabling people all over the world to solve their local problems, their local needs, their local issues, in a manner that's efficient, fast and reliable. As our CEO Dara has said, we want to become the mobile operating system of local cities and communities throughout the world. As of today, Uber is operational in over 10,000 cities around the world. So, across our various business lines, we have over 110 million monthly users, who use our rides, services, or eat services, and a whole bunch of other services that we provide to Uber. And just to give you a scale of our daily operations, we in the ride business, have over 20 million trips per day. And that each business is also catching up, particularly during the recent times that we've been having. And so, I hope these numbers give you a scale of the amount of data, that we process each and every day. And support our users in their analytical and business reporting needs. So who are these users at Uber? Let's take a quick look. So, Uber to describe it very briefly, is a lot like Amazon. We are largely an operation and logistics company. And employee work based reflects that. So over 70% of our employees work in teams, which come under the umbrella of Community Operations and Centers of Excellence. So these are all folks working in various cities and towns that we operate around the world, and run the Uber businesses, as somewhat local businesses responding to local needs, local market conditions, local regulation and so forth. And Vertica is one of the most important tools, that these folks use in their day to day business activities. So they use Vertica to get insights into how their businesses are going, to deeply into any issues that they want to triage , to generate reports, to plan for the future, a whole lot of use cases. The second big class of users, are in our marketplace team. So marketplace is the engineering team, that backs our ride shared business. And as part of this, running this business, a key problem that they have to solve, is how to determine what prices to set, for particular rides, so that we have a good match between supply and demand. So obviously the real time pricing decisions they're made by serving systems, with very detailed and well crafted machine learning models. However, the training data that goes into this models, the historical trends, the insights that go into building these models, a lot of these things are powered by the data that we store, and serve out of Vertica. Similarly, in each business, we have use cases spanning all the way from engineering and back-end systems, to support operations, incentives, growth, and a whole bunch of other domains. So the big class of applications that we support across a lot of these business lines, is dashboards and reporting. So we have a lot of dashboards, which are built by core data analysts teams and shared with a whole bunch of our operations and other teams. So these are dashboards and reports that run, periodically say once a week or once a day even, depending on the frequency of data that they need. And many of these are powered by the data, and the analytics support that we provide on our Vertica platform. Another big category of use cases is for growth marketing. So this is to understand historical trends, figure out what are various business lines, various customer segments, various geographical areas, doing in terms of growth, where it is necessary for us to reinvest or provide some additional incentives, or marketing support, and so forth. So the analysis that backs a lot of these decisions, is powered by queries running on Vertica. And finally, the heart and soul of Uber is data science. So data science is, how we provide best in class algorithms, pricing, and matching. And a lot of the analysis that goes into, figuring out how to build these systems, how to build the models, how to build the various coefficients and parameters that go into making real time decisions, are based on analysis that data scientists run on Vertica systems. So as you can see, Vertica usage spans a whole bunch of organizations and users, all across the different Uber teams and ecosystems. Just to give you some quick numbers, we have over 5000 weekly active, people who run queries at least once a week, to do some critical business role or problem to solve, that they have in their day to day operations. So next, let's see how Vertica fits into the Uber data ecosystem. So when users open up their apps, and request for a ride or order food delivery on each platform, the apps are talking to our serving systems. And the serving systems use online storage systems, to store the data as the trips and eat orders are getting processed in real time. So for this, we primarily use an in house built, key value storage system called Schemaless, and an open source system called Cassandra. We also have other systems like MySQL and Redis, which we use for storing various bits of data to support serving systems. So all of this operations generates a lot of data, that we then want to process and analyze, and use for our operational improvements. So, we have ingestion systems that periodically pull in data from our serving systems and land them in our data lake. So at Uber a data lake is powered by Hadoop, with files stored on HDFS clusters. So once the raw data lines on the data lake, we then have ETL jobs that process these raw datasets, and generate, modeled and customize datasets which we then use for further analysis. So once these model datasets are available, we load them into our data warehouse, which is entirely powered by Vertica. So then we have a business intelligence layer. So with internal tools, like QueryBuilder, which is a UI interface to write queries, and look at results. And it read over the front-end sites, and Dashbuilder, which is a dash, board building tool, and report management tool. So these are all various tools that we have built within Uber. And these can talk to Vertica and run SQL queries to power, whatever, dashboards and reports that they are supporting. So this is what the data ecosystem looks like at Uber. So why Vertica and what does it really do for us? So it powers insights, that we show on dashboards as folks use, and it also powers reports that we run periodically. But more importantly, we have some core, properties and core feature sets that Vertica provides, which allows us to support many of these use cases, very well and at scale. So let me take a brief tour of what these are. So as I mentioned, Vertica powers Uber's data warehouse. So what this means is that we load our core fact and dimension tables onto Vertica. The core fact tables are all the trips, all the each orders and all these other line items for various businesses from Uber, stored as partitioned tables. So think of having one partition per day, as well as dimension tables like cities, users, riders, career partners and so forth. So we have both these two kinds of datasets, which will load into Vertica. And we have full historical data, all the way since we launched these businesses to today. So that folks can do deeper longitudinal analysis, so they can look at patterns, like how the business has grown from month to month, year to year, the same month, over a year, over multiple years, and so forth. And, the really powerful thing about Vertica, is that most of these queries, you run the deep longitudinal queries, run very, very fast. And that's really why we love Vertica. Because we see query latency P90s. That is 90 percentile of all queries that we run on our platform, typically finish in under a minute. So that's very important for us because Vertica is used, primarily for interactive analytics use cases. And providing SQL query execution times under a minute, is critical for our users and business owners to get the most out of analytics and Big Data platforms. Vertica also provides a few advanced features that we use very heavily. So as you might imagine, at Uber, one of the most important set of use cases we have is around geospatial analytics. In particular, we have some critical internal dashboards, that rely very heavily on being able to restrict datasets by geographic areas, cities, source destination pairs, heat maps, and so forth. And Vertica has a rich array of functions that we use very heavily. We also have, support for custom projections in Vertica. And this really helps us, have very good performance for critical datasets. So for instance, in some of our core fact tables, we have done a lot of query and analysis to figure out, how users run their queries, what kind of columns they use, what combination of columns they use, and what joints they do for typical queries. And then we have laid out our custom projections to maximize performance on these particular dimensions. And the ability to do that through Vertica, is very valuable for us. So we've also had some very successful collaborations, with the Vertica engineering team. About a year and a half back, we had open-sourced a Python Client, that we had built in house to talk to Vertica. We were using this Python Client in our business intelligence layer that I'd shown on the previous slide. And we had open-sourced it after working closely with Eng team. And now Vertica formally supports the Python Client as an open-source project, which you can download to and integrate into your systems. Another more recent example of collaboration is the Vertica Eon mode on GCP. So as most of or at least some of you know, Vertica Eon mode is formally supported on AWS. And at Uber, we were also looking to see if we could run our data infrastructure on GCP. So Vertica team hustled on this, and provided us early preview version, which we've been testing out to see how performance, is impacted by running on the Cloud, and on GCP. And so far, I think things are going pretty well, but we should have some numbers about this very soon. So here I have a visualization of an internal dashboard, that is powered solely by data and queries running on Vertica. So this GIF has sequence have different visualizations supported by this tool. So for instance, here you see a heat map, downgrading heat map of source of traffic demand for ride shares. And then you will see a bunch of arrows here about source destination pairs and the trip lines. And then you can see how demand moves around. So, as the cycles through the various animations, you can basically see all the different kinds of insights, and query shapes that we send to Vertica, which powers this critical business dashboard for our operations teams. All right, so now how do we do all of this at scale? So, we started off with a single Vertica cluster, a few years back. So we had our data lake, the data would land into Vertica. So these are the core fact and dimension tables that I just spoke about. And then Vertica powers queries at our business intelligence layer, right? So this is a very simple, and effective architecture for most use cases. But at Uber scale, we ran into a few problems. So the first issue that we have is that, Uber is a pretty big company at this point, with a lot of users sending almost millions of queries every week. And at that scale, what we began to see was that a single cluster was not able to handle all the query traffic. So for those of you who have done an introductory course, on queueing theory, you will realize that basically, even though you could have all the query is processed through a single serving system. You will tend to see larger and larger queue wait times, as the number of queries pile up. And what this means in practice for end users, is that they are basically just seeing longer and longer query latencies. But even though the actual query execution time on Vertica itself, is probably less than a minute, their query sitting in the queue for a bunch of minutes, and that's the end user perceived latency. So this was a huge problem for us. The second problem we had was that the cluster becomes a single point of failure. Now Vertica can handle single node failures very gracefully, and it can probably also handle like two or three node failures depending on your cluster size and your application. But very soon, you will see that, when you basically have beyond a certain number of failures or nodes in maintenance, then your cluster will probably need to be restarted or you will start seeing some down times due to other issues. So another example of why you would have to have a downtime, is when you're upgrading software in your clusters. So, essentially we're a global company, and we have users all around the world, we really cannot afford to have downtime, even for one hour slot. So that turned out to be a big problem for us. And as I mentioned, we could have hardware issues. So we we might need to upgrade our machines, or we might need to replace storage or memory due to issues with the hardware in there, due to normal wear and tear, or due to abnormal issues. And so because of all of these things, having a single point of failure, having a single cluster was not really practical for us. So the next thing we did, was we set up multiple clusters, right? So we had a bunch of identities clusters, all of which have the same datasets. So then we would basically load data using ingestion pipelines from our data lake, onto each of these clusters. And then the business intelligence layer would be able to query any of these clusters. So this actually solved most of the issues that I pointed out in the previous slide. So we no longer had a single point of failure. Anytime we had to do version upgrades, we would just take off one cluster offline, upgrade the software on it. If we had node failures, we would probably just take out one cluster, if we had to, or we would just have some spare nodes, which would rotate into our production clusters and so forth. However, having multiple clusters, led to a new set of issues. So the first problem was that since we have multiple clusters, you would end up with inconsistent schema. So one of the things to understand about our platform, is that we are an infrastructure team. So we don't actually own or manage any of the data that is served on Vertica clusters. So we have dataset owners and publishers, who manage their own datasets. Now exposing multiple clusters to these dataset owners. Turns out, it's not a great idea, right? Because they are not really aware of, the importance of having consistency of schemas and datasets across different clusters. So over time, what we saw was that the schema for the same tables would basically get out of order, because they were all the updates are not consistently applied on all clusters. Or maybe they were just experimenting some new columns or some new tables in one cluster, but they forgot to delete it, whatever the case might be. We basically ended up in a situation where, we saw a lot of inconsistent schemas, even across some of our core tables in our different clusters. A second issue was, since we had ingestion pipelines that were ingesting data independently into all these clusters, these pipelines could fail independently as well. So what this meant is that if, for instance, the ingestion pipeline into cluster B failed, then the data there would be older than clusters A and C. So, when a query comes in from the BI layer, and if it happens to hit B, you would probably see different results, than you would if you went to a or C. And this was obviously not an ideal situation for our end users, because they would end up seeing slightly inconsistent, slightly different counts. But then that would lead to a bad situation for them where they would not able to fully trust the data that was, and the results and insights that were being returned by the SQL queries and Vertica systems. And then the third problem was, we had a lot of extra replication. So the 20/80 Rule, or maybe even the 90/10 Rule, applies to datasets on our clusters as well. So less than 10% of our datasets, for instance, in 90% of the queries, right? And so it doesn't really make sense for us to replicate all of our data on all the clusters. And so having this set up where we had to do that, was obviously very suboptimal for us. So then what we did, was we basically built some additional systems to solve these problems. So this brings us to our Vertica ecosystem that we have in production today. So on the ingestion side, we built a system called Vertica Data Manager, which basically manages all the ingestion into various clusters. So at this point, people who are managing datasets or dataset owners and publishers, they no longer have to be aware of individual clusters. They just set up their ingestion pipelines with an endpoint in Vertica Data Manager. And the Vertica Data Manager ensures that, all the schemas and data is consistent across all our clusters. And on the query side, we built a proxy layer. So what this ensures is that, when queries come in from the BI layer, the query was forwarded, smartly and with knowledge and data about which cluster up, which clusters are down, which clusters are available, which clusters are loaded, and so forth. So with these two layers of abstraction between our ingestion and our query, we were able to have a very consistent, almost single system view of our entire Vertica deployment. And the third bit, we had put in place, was the data manifest, which were the communication mechanism between ingestion and proxy. So the data manifest basically is a listing of, which tables are available on which clusters, which clusters are up to date, and so forth. So with this ecosystem in place, we were also able to solve the extra replication problem. So now we basically have some big clusters, where all the core tables, and all the tables, in fact, are served. So any query that hits 90%, less so tables, goes to the big clusters. And most of the queries which hit 10% heavily queried important tables, can also be served by many other small clusters, so much more efficient use of resources. So this basically is the view that we have today, of Vertica within Uber, so external to our team, folks, just have an endpoint, where they basically set up their ingestion jobs, and another endpoint where they can forward their Vertica SQL queries. And they are so to a proxy layer. So let's get a little more into details, about each of these layers. So, on the data management side, as I mentioned, we have two kinds of tables. So we have dimension tables. So these tables are updated every cycle, so the list of cities list of drivers, the list of users and so forth. So these change not so frequently, maybe once a day or so. And so we are able to, and since these datasets are not very big, we basically swap them out on every single cycle. Whereas the fact tables, so these are tables which have information about our trips or each orders and so forth. So these are partition. So we have one partition roughly per day, for the last couple of years, and then we have more of a hierarchical partitions set up for older data. So what we do is we load the partitions for the last three days on every cycle. The reason we do that, is because not all our data comes in at the same time. So we have updates for trips, going over the past two or three days, for instance, where people add ratings to their trips, or provide feedback for drivers and so forth. So we want to capture them all in the row corresponding to that particular trip. And so we upload partitions for the last few days to make sure we capture all those updates. And we also update older partitions, if for instance, records were deleted for retention purposes, or GDPR purposes, for instance, or other regulatory reasons. So we do this less frequently, but these are also updated if necessary. So there are endpoints which allow dataset owners to specify what partitions they want to update. And as I mentioned, data is typically managed using a hierarchical partitioning scheme. So in this way, we are able to make sure that, we take advantage of the data being clustered by day, so that we don't have to update all the data at once. So when we are recovering from an cluster event, like a version upgrade or software upgrade, or hardware fix or failure handling, or even when we are adding a new cluster to the system, the data manager takes care of updating the tables, and copying all the new partitions, making sure the schemas are all right. And then we update the data and schema consistency and make sure everything is up to date before we, add this cluster to our serving pool, and the proxy starts sending traffic to it. The second thing that the data manager provides is consistency. So the main thing we do here, is we do atomic updates of our tables and partitions for fact tables using a two-phase commit scheme. So what we do is we load all the new data in temp tables, in all the clusters in phase one. And then when all the clusters give us access signals, then we basically promote them to primary and set them as the main serving tables for incoming queries. We also optimize the load, using Vertica Data Copy. So what this means is earlier, in a parallel pipelines scheme, we had to ingest data individually from HDFS clusters into each of the Vertica clusters. That took a lot of HDFS bandwidth. But using this nice feature that Vertica provides called Vertica Data Copy, we just load it data into one cluster and then much more efficiently copy it, to the other clusters. So this has significantly reduced our ingestion overheads, and speed it up our load process. And as I mentioned as the second phase of the commit, all data is promoted at the same time. Finally, we make sure that all the data is up to date, by doing some checks around the number of rows and various other key signals for freshness and correctness, which we compare with the data in the data lake. So in terms of schema changes, VDM automatically applies these consistently across all the clusters. So first, what we do is we stage these changes to make sure that these are correct. So this catches errors that are trying to do, an incompatible update, like changing a column type or something like that. So we make sure that schema changes are validated. And then we apply them to all clusters atomically again for consistency. And provide a overall consistent view of our data to all our users. So on the proxy side, we have transparent support for, replicated clusters to all our users. So the way we handle that is, as I mentioned, the cluster to table mapping is maintained in the manifest database. And when we have an incoming query, the proxy is able to see which cluster has all the tables in that query, and route the query to the appropriate cluster based on the manifest information. Also the proxy is aware of the health of individual clusters. So if for some reason a cluster is down for maintenance or upgrades, the proxy is aware of this information. And it does the monitoring based on query response and execution times as well. And it uses this information to route queries to healthy clusters, and do some load balancing to ensure that we award hotspots on various clusters. So the key takeaways that I have from the stock, are primarily these. So we started off with single cluster mode on Vertica, and we ran into a bunch of issues around scaling and availability due to cluster downtime. We had then set up a bunch of replicated clusters to handle the scaling and availability issues. Then we run into issues around schema consistency, data staleness, and data replication. So we built an entire ecosystem around Vertica, with abstraction layers around data management and ingestion, and proxy. And with this setup, we were able to enforce consistency and improve storage utilization. So, hopefully this gives you all a brief idea of how we have been able to scale Vertica usage at Uber, and power some of our most business critical and important use cases. So as I mentioned at the beginning, I have a interesting and simple extra update for you. So an easy way in which you all can take advantage of many of the features that we have built into our ecosystem, is to use the Vertica Eon mode. So the Vertica Eon mode, allows you to set up multiple clusters with consistent data updates, and set them up at various different sizes to handle different query loads. And it automatically handles many of these issues that I mentioned in our ecosystem. So do check it out. We've also been, trying it out on DCP, and initial results look very, very promising. So thank you all for joining me on this talk today. I hope you guys learned something new. And hopefully you took away something that you can also apply to your systems. We have a few more time for some questions. So I'll pause for now and take any questions.

>> Jeff: Hello everybody, and thank you for joining us today for the virtual Vertica BDC 2020. Today's break-out session has been titled, "Migrating Your Vertica Cluster to the Cloud." I'm Jeff Healey, and I'm in Vertica marketing. I'll be your host for this break-out session. Joining me here are Sumeet Keswani and Chris Daly, Vertica product technology engineers and key members of our customer success team. Before we begin, I encourage you to submit questions and comments during the virtual session. You don't have to wait, just type your question or comment in the question box below the slides and click Submit. As always, there will be a Q&A session at the end of the presentation. We'll answer as many questions as we're able to during that time. Any questions that we don't address, we'll do our best to answer them offline. And alternatively, you can visit Vertica forums at forum.vertica.com to post your questions there after the session. Our engineering team is planning to join the forums to keep the conversation going. Also as a reminder that you can maximize your screen by clicking the double arrow button in the lower right corner of the slides. And yes, this virtual session is being recorded and will be available to view on demand this week. We'll send you a notification as soon as it's ready. Now let's get started. Over to you, Sumeet. >> Sumeet: Thank you, Jeff. Hello everyone, my name is Sumeet Keswani, and I will be talking about planning to deploy or migrate your Vertica cluster to the Cloud. So you may be moving an on-prem cluster or setting up a new cluster in the Cloud. And there are several design and operational considerations that will come into play. You know, some of these are cost, which industry you are in, or which expertise you have, in which Cloud platform. And there may be a personal preference too. After that, you know, there will be some operational considerations like VM and cluster sizing, what Vertica mode you want to deploy, Eon or Enterprise. It depends on your use keys. What are the DevOps skills available, you know, what elasticity, separation you need, you know, what is your backup and DR strategy, what do you want in terms of high availability. And you will have to think about, you know, how much data you have and where it's going to live. And in order to understand the cost, or the cost and the benefit of deployment and you will have to understand the access patterns, and how you are moving data from and to the Cloud. So things to consider before you move a deployment, a Vertica deployment to the Cloud, right, is one thing to keep in mind is, virtual CPUs, or CPUs in the Cloud, are not the same as the usual CPUs that you've been familiar with in your data center. A vCPU is half of a CPU because of hyperthreading. There is definitely the noisy neighbor effect. There is, depending on what other things are hosted in the Cloud environment, you may see performance, you may occasionally see performance issues. There are I/O limitations on the instance that you provision, so that what that really means is you can't always scale up. You might have to scale up, basically, you have to add more instances rather than getting bigger or the right size instances. Finally, there is an important distinction here. Virtualization is not free. There can be significant overhead to virtualization. It could be as much as 30%, so when you size and scale your clusters, you must keep that in mind. Now the other important aspect is, you know, where you put Vertica cluster is important. The choice of the region, how far it is from your various office locations. Where will the data live with respect to the cluster. And remember, popular locations can fill up. So if you want to scale out, additional capacity may or may not be available. So these are things you have to keep in mind when picking or choosing your Cloud platform and your deployment. So at this point, I want to make a plug for Eon mode. Eon mode is the latest mode, is a Cloud mode from Vertica. It has been designed with Cloud economics in mind. It uses shared storage, which is durable, available, and very cheap, like S3 storage or Google Cloud storage. It has been designed for quick scaling, like scale out, and highly elastic deployments. It has also been designed for high workload isolation, where each application or user group can be isolated from the other ones, so that they'll be paid and monitored separately, without affecting each other. But there are some disadvantages, or perhaps, you know, there's a cost for using Eon mode. Storage in S3 is neither cheap nor efficient. So there is a high latency of I/O when accessing data from S3. There is API and data access cost. There is API and data access cost associated with accessing your data in S3. Vertica in Eon mode has a pay as you go model, which you know, works for some people and does not work for others. And so therefore it is important to keep that in mind. And performance can be a little bit variable here, because it depends on cache, it depends on the local depot, which is a cache, and it is not as predictable as EE mode, so that's another trade-off. So let's spend about a minute and see how a Vertica cluster in Eon mode looks like. A Vertica cluster in Eon mode has S3 as the durability layer where all the data sits. There are subclusters, which are essentially just aggregation groups, which is separated compute, which will service different workloads. So for in this example, you may have two subclusters, one servicing ETL workload and the other one servicing (mic interference obscures speaking). These clusters are isolated, and they do not affect each other's performance. This allows you to scale them independently and isolate workloads. So this is the new Vertica Eon mode which has been specifically designed by us for use in the Cloud. But beyond this, you can use EE mode or Eon mode in the Cloud, it really depends on what your use case is. But both of these are possible, and we highly recommend Eon mode wherever possible. Okay, let's talk a little bit about what we mean by Vertica support in the Cloud. Now as you know, a Cloud is a shared data center, right. Performance in the Cloud can vary. It can vary between regions, availability zones, time of the day, choice of instance type, what concurrency you use, and of course the noisy neighbor effect. You know, we in Vertica, we performance, load, and stress test our product before every release. We have a bunch of use cases, we go through all of them, make sure that we haven't, you know, regressed any performance, and make sure that it works up to standards and gives you the high performance that you've come to expect. However, your solution or your workload is unique to you, and it is still your responsibility to make sure that it is tuned appropriately. To do this, one of the easiest things you can do is you know, pick a tested operating system, allocate the virtual machine, you know, with enough resources. It's something that we recommend, because we have tested it thoroughly. It goes a long way in giving you predictability. So after this I would like to now go into the various platforms, Cloud platforms, that Vertica has worked on. And I'll start with AWS, and my colleague Chris will speak about Azure and GCP. And our thoughts forward. So without further ado, let's start with the Amazon Web Services platform. So this is Vertica running on the Amazon Web Services platform. So as you probably are all aware, Amazon Web Services is the market leader in this space, and indeed really our biggest provider by far, and have been here for a very long time. And Vertica has a deep integration in the Amazon Web Services space. We provide a marketplace offering which has both pay as you go or a bring your own license model. We have many, you know, knowledge base articles, best practices, scripts, and resources that help you configure and use a Vertica database in the Cloud. We have several customers in the Cloud for many, many years now, and we have managed and console-based point and click deployments, you know, for ease of use in the Cloud. So Vertica has a deep integration in the Amazon space, and has been there for quite a bit now. So we communicate a lot of experience here. So let's talk about sizing on AWS. And sizing on any platform comes down to you know, these four or five different things. It comes down to picking the right instance type, picking the right disk volume and type, tuning and optimizing your networking, and finally, you know, some operational concerns like security, maintainability, and backup. So let's go into each one of these on the AWS ecosystem. So the choice of instance type is one of the important choices that you will make. In Eon mode, you know, you don't really need persistent disk. You can, you should probably choose ephemeral disk because it gives you extra speed, and speed with the instance type. We highly recommend the i3.4x instance types, which are very economical, have a big, 4 terabyte depot or cache per node. The i3.metal is similar to the i3.4, but has got significantly better performance, for those subclusters that need this extra oomph. The i3.2 is good for scale out of small ad hoc clusters. You know, they have a smaller cache and lower performance but it's cheap enough to use very indiscriminately. If you were in EE mode, well we don't use S3 as the layer of durability. Your local volumes is where we persist the data. Hence you do need an EBS volume in EE mode. In order to make sure that, you know, that the instance or the deployment is manageable, you might have to use some sort of a software RAID array over the EBS volumes. The most common instance type you see in EE mode is the r4.4x, the c4, or the m4 instance types. And then of course for temp space and depot we always recommend instance volumes. They're just much faster. Okay. So let's go, let's talk about optimizing your network or tuning your network. So the best, the best thing you can do about tuning your network, especially in Eon mode but in other modes too, is to get a VPC S3 endpoint. This is essentially a route table that makes sure that all traffic between your cluster and S3 goes over an internal fabric. This makes it much faster, you don't pay for egress cost, especially if you're doing external tables or your communal storage, but you do need to create it. Many times people will forget doing it. So you really do have to create it. And best of all, it's free. It doesn't cost you anything extra. You just have to create it during cluster creation time, and there's a significant performance difference for using it. The next thing about tuning your network is, you know, sizing it correctly. Pick the closest geographical region to where you'll consume the data. Pick the right availability zone. We highly recommend using cluster placement groups. In fact, they are required for the stability of the cluster. A cluster placement group is essentially, it operates this notion of rack. Nodes in a cluster placement group, are, you know, physically closer to each other than they would otherwise be. And this allows, you know, a 10 Gbps, bidirectional, TCP/IP flow between the nodes. And this makes sure that, you know, you get a high amount of Gbps per second. As you probably are all aware, the Cloud does not support broadcast or UDP broadcast. Hence you must use point-to-point UDP for spread in the Cloud, or in AWS. Beyond that, you know, point-to-point UDP does not scale very well beyond 20 nodes. So you know, as your cluster sizes increase, you must switch over to large cluster mode. And finally, use instances with enhanced networking or SR-IOV support. Again, it's free, it comes with the choice of the instance type and the operating system. We highly recommend it, it makes a big difference in terms of how your workload will perform. So let's talk a little bit about security, configuration, and orchestration. As I said, we provide CloudFormation scripts to make the ease of deployment. You can use the MC point and click. With regard to security, you know, Vertica does support instance profiles out of the box in Amazon. We recommend you use it. This is highly desirable so that you're not passing access keys and secret keys around. If you use our marketplace image, we have picked the latest operating systems, we have patched them, Amazon actually validates everything on marketplace and scans them for security vulnerabilities. So you get that for free. We do some basic configuration, like we disable root ssh access, we disallow any password access, we turn on encryption. And we run a basic set of security checks to make sure that the image is secure. Of course, it could be made more secure. But we try to balance out security, performance, and convenience. And finally, let's talk about backups. Especially in Eon mode I get the question, "Do we really need to back up our system, "since the data is in S3?" And the answer is yes, you do. Because you know, S3's not going to protect you against an accidental drop table. You know, S3 has a finite amount of reliability, durability, and availability. And you may want to be able to restore data differently. Also, backups are important if you're doing DR, or if you have additional cluster in a different region. The other cluster can be considered a backup. And finally, you know, why not create a backup or a disaster recovery cluster, you know, storage is cheap in the Cloud. So you know, we highly recommend you use it. So with this, I would like to hand it over to my colleague Christopher Daly, who will talk about the other two platforms that we support, that is Google and Azure. Over to you, Chris, thank you. >> Chris: Thanks, Sumeet, and hi everyone. So while there's no argument that we here at Vertica have a long history of running within the Amazon Web Services space, there are other alternative Cloud service providers where we do have a presence, such as Google Cloud Platform, or GCP. For those of you who are unfamiliar with GCP, it's considered the third-largest Cloud service provider in the marketspace, and it's priced very competitively to its peers. Has a lot of similarities to AWS in the products and services that it offers, but it tends to be the go-to place for newer businesses or startups. We officially started supporting GCP a little over a year ago with our first entry into their GCP marketplace. So a solution that deployed a fully-functional and ready-to-use Enterprise mode cluster. We followed up on that with the release and the support of Google storage buckets, and now I'm extremely pleased to announce that with the launch of Vertica 10, we're officially supporting Eon mode architecture in GCP as well. But that's not all, as we're adding additional offerings into the GCP marketplace. With the launch of version 10 we'll be introducing a second listing in the marketplace that allows for the deployment of an Eon mode cluster. It's all being driven by our own management consult. This will allow customers to quickly spin up Eon-based clusters within the GCP space. And if that wasn't enough, I'm also pleased to tell you that very soon after the launch we're going to be offering Vertica by the hour in GCP as well. And while we've done a lot to automate the solutions coming out of the marketplace, we recognize the simple fact that for a lot of you, building your cluster manually is really the only option. So with that in mind, let's talk about the things you need to understand in GCP to get that done. So wag me if you think this slide looks familiar. Well nope, it's not an erroneous duplicate slide from Sumeet's AWS section, it's merely an acknowledgement of all the things you need to consider for running Vertica in the Cloud. In Vertica, the choice of the operational mode will dictate some of the choices you'll need to make in the infrastructure, particularly around storage. Just like on-prem solutions, you'll need to understand the disk and networking capacities to get the most out of your cluster. And one of the most attractive things in GCP is the pricing, as it tends to run a little less than the others. But it does translate into less choices and options within the environment. If nothing else, I want you to take one thing away from this slide, and Sumeet said this earlier. VMs running, about AWS, Sumeet said this about AWS earlier. VMs running in the GCP space run on top of hardware that has hyperthreading enabled. And that a vCPU doesn't equate to a core, but rather a processing thread. This becomes particularly important if you're moving from an on-prem environment into the Cloud. Because a physical Vertica node with 32 cores is not the same thing as a VM with 32 vCPUs. In fact, with 32 vCPUs, you're only getting about 16 cores worth of performance. GCP does offer a handful of VM types, which they categorize by letter, but for us, most of these don't make great choices for Vertica nodes. The M series, however, does offer a good core to memory ratio, especially when you're looking at the high-mem variants. Also keep in mind, performance in I/O, such as network and disk, are partially dependent on the VM size, so customers in GCP space should be focusing on 16 vCPU VMs and above for their Vertica nodes. Disk options in GCP can be broken down into two basic types, persistent disks and local disks, which are ephemeral. Persistent disks come in two forms, standard or SSD. For Vertica in Eon mode, we recommend that customers use persistent SSD disks for the catalog, and either local SSD disks or persistent SSD disks for the depot and the temp space. Couple of things to think about here, though. Persistent disks are provisioned as a single device with a settable size. Local disks are provisioned as multiple disk devices with a fixed size, requiring you to use some kind of software RAIDing to create a single storage device. So while local SSD disks provide much more throughput, you're using CPU resources to maintain that RAID set. So you're giving, it's a little bit of a trade-off. Persistent disks offer redundancy, either within the zone that they exist or within the region, and if you're selecting regional redundancy, the disks are replicated across multiple zones in the region. This does have an effect in the performance to VM, so we don't recommend this. What we do recommend is the zonal redundancy when you're using persistent disks, as it gives you that redundancy level without actually affecting the performance. Remember also, in the Cloud space, all I/O is network I/O, as disks are basically block storage devices. This means that disk actions can and will slow down network traffic. And finally, the storage bucket access in GCP is based on GCP interoperability mode, which means that it's basically compliant with the AWS S3 API. In interoperability mode, access to the bucket is granted by a key pair that GCP refers to as HMAC keys. HMAC keys can be generated for individual users or for service accounts. We will recommend that when you're creating HMAC keys, choose a service account to ensure that the keys are not tied to a single employee. When thinking about storage for Enterprise mode, things change a little bit. We still recommend persistent SSD disks over standard ones. However, the use of local SSD disks for anything other than temp space is highly discouraged. I said it before, local SSD disks are ephemeral, meaning that the data's lost if the machine is turned off or goes down. So not really a place you want to store your data. In GCP, multiple persistent disks placed into a software RAID set does not create more throughput like you can find in other Clouds. The I/O saturation usually hits the VM limit long before it hits the disk limit. In fact, performance of a persistent disk is determined not just by the size of the disk but also by the size of the VM. So a good rule of thumb in GCP is to maximize your I/O throughput for persistent disks, is that the size tends to max out at two terabytes for SSDs and 10 terabytes for standard disks. Network performance in GCP can be thought of in two distinct ways. There's node-to-node traffic, and then there's egress traffic. Node-to-node performance in GCP is really good within the zone, with typical traffic between nodes falling in the 10-15 gigabits per second range. This might vary a little from zone to zone and region to region, but usually it's only limited, they're only limited by the existing traffic where the VMs exist. So kind of a noisy neighbor effect. Egress traffic from a VM, however, is subject to throughput caps, and these are based on the size of the VM. So the speed is set for the number of vCPUs in the VM at two gigabits per second per vCPU, and tops out at 32 gigabits per second. So the larger the VM, the more vCPUs you get, the larger the cap. So some things to consider in the NAV ring space for your Vertica cluster, pick a region that's physically close to you, even if you're connecting to the GCP network from a corporate LAN as opposed to the internet. The further the packets have to travel, the longer it's going to take. Also, GCP, like most Clouds, doesn't support UDP broadcast traffic on their virtual NAV ring, so you do have to use the point-to-point flag for spread when you're creating your cluster. And since the network cap on VMs is set at 32 gigabits per second per VM, maximize your network egress throughput and don't use VMs that are smaller than 16 vCPUs for your Vertica nodes. And that gets us to the one question I get asked the most often. How do I get my data into and out of the Cloud? Well, GCP offers many different methods to support different speeds and different price points for data ingress and egress. There's the obvious one, right, across the internet either directly to the VMs or into the storage bucket. Or you can, you know, light up a VPN tunnel to encrypt all that traffic. But additionally, GCP offers direct network interconnect from your corporate network. These get provided either by Google or by a partner, and they vary in speed. They also offer things called direct or carrier peering, which is connecting the edges of the networks between your network and GCP, and you can use a CDN interconnect, which creates, I believe, an on-demand connection from the GCP network, your network to the GCP network provided by a large host of CDN service providers. So GCP offers a lot of ways to move your data around in and out of the GCP Cloud. It's really a matter of what price point works for you, and what technology your corporation is looking to use. So we've talked about AWS, we've talked about GCP, it really only leaves one more Cloud. So last, and by far not the least, there's the Microsoft Azure environment. Holding on strong to the number two place in the major Cloud providers, Azure offers a very robust Cloud offering that's attractive to customers that already consume services from Microsoft. But what you need to keep in mind is that the underlying foundation of their Cloud is based on the Microsoft Windows products. And this makes their Cloud offering a little bit different in the services and offerings that they have. The good news here, though, is that Microsoft has done a very good job of getting their virtualization drivers baked into the modern kernels of most Linux operating systems, making running Linux-based VMs in Azure fairly seamless. So here's the slide again, but now you're going to notice some slight differences. First off, in Azure we only support Enterprise mode. This is because the Azure storage product is very different from Google Cloud storage and S3 on AWS. So while we're working on getting this supported, and we're starting to focus on this, we're just not there yet. This means that since we're only supporting Enterprise mode in Azure, getting the local disk performance right is one of the keys to success of running Vertica here, with the other major key being making sure that you're getting the appropriate networking speeds. Overall, Azure's a really good platform for Vertica, and its performance and pricing are very much on par with AWS. But keep in mind that the newer versions of the Linux operating systems like RHEL and CentOS run much better here than the older versions. Okay, so first things first again, just like GCP, in Azure VMs are running on top of hardware that has hyperthreading enabled. And because of the way Hyper-V, Azure's virtualization engine works, you can actually see this, right? So if you look down into the CPU information of the VM, you'll actually see how it groups the vCPUs by core and by thread. Azure offers a lot of VM types, and is adding new ones all the time. But for us, we see three VM types that make the most sense for Vertica. For customers that are looking to run production workloads in Azure, the Es_v3 and the Ls_v2 series are the two main recommendations. While they differ slightly in the CPU to memory ratio and the I/O throughput, the Es_v3 series is probably the best recommendation for a generalized Vertica node, with the Ls_v2 series being recommended for workloads with higher I/O requirements. If you're just looking to deploy a sandbox environment, the Ds_v3 series is a very suitable choice that really can reduce your overall Cloud spend. VM storage in Azure is provided by a grouping of four different types of disks, all offering different levels of performance. Introduced at the end of last year, the Ultra Disk option is the highest-performing disk type for VMs in Azure. It was designed for database workloads where high throughput and low latency is very desirable. However, the Ultra Disk option is not available in all regions yet, although that's been changing slowly since their launch. The Premium SSD option, which has been around for a while and is widely available, can also offer really nice performance, especially higher capacities. And just like other Cloud providers, the I/O throughput you get on VMs is dictated not only by the size of the disk, but also by the size of the VM and its type. So a good rule of thumb here, VM types with an S will have a much better throughput rate than ones that don't, meaning, and the larger VMs will have, you know, higher I/O throughput than the smaller ones. You can expand the VM disk throughput by using multiple disks in Azure and using a software RAID. This overcomes limitations of single disk performance, but keep in mind, you're now using CPU cycles to maintain that raid, so it is a bit of a trade-off. The other nice thing in Azure is that all their managed disks are encrypted by default on the server side, so there's really nothing you need to do here to enable that. And of course I mentioned this earlier. There is no native access to Azure storage yet, but it is something we're working on. We have seen folks using third-party applications like MinIO to access Azure's storage as an S3 bucket. So it might be something you want to keep in mind and maybe even test out for yourself. Networking in Azure comes in two different flavors, standard and accelerated. In standard networking, the entire network stack is abstracted and virtualized. So this works really well, however, there are performance limitations. Standard networking tends to top out around four gigabits per second. Accelerated networking in Azure is based on single root I/O virtualization of the Mellanox adapter. This is basically the VM talking directly to the physical network card in the host hardware, and it can produce network speeds up to 20 gigabits per second, so much, much faster. Keep in mind, though, that not all VM types and operating systems actually support accelerated networking, and you know, just like disk throughput, network throughput is based on VM type and size. So what do you need to think about for networking in the Azure space? Again, stay close to home. Pick regions that are geographically close to your location. Yes, the backbones between the regions are very, very fast, but the more hops your packets have to make, the longer it takes. Azure offers two types of groupings of their VMs, availability sets and availability zones. Availability zones offer good redundancy across multiple zones, but this actually increases the node-to-node latency, so we recommend you avoid this. Availability sets, on the other hand, keep all your VMs grouped together within a single zone, but makes sure that no two VMs are running on the same host hardware, for redundancy. And just like the other Clouds, UDP broadcast is not supported. So you have to use the point-to-point flag when you're creating your database to ensure that the spread works properly. Spread time out, okay, this is a good one. So recently, Microsoft has started monthly rolling updates of their environment. What this looks like is VMs running on top of hardware that's receiving an update can be paused. And this becomes problematic when the pausing of the VM exceeds eight seconds, as the unpaused members of the cluster now think the paused VM is down. So consider adjusting the spread time out for your clusters in Azure to 30 seconds, and this will help avoid a little of that. If you're deploying a large cluster in Azure, more than 20 nodes, use large closer mode, as point-to-point for spread doesn't really scale well with a lot of Vertica nodes. And finally, you know, pick VM types and operating systems that support accelerated networking. The difference in the node-to-node speeds can be very dramatic. So how do we move data around in Azure, right? So Microsoft views data egress a little differently than other Clouds, as it classifies any data being transmitted by a VM as egress. However, it only bills for data egress that actually leaves the Azure environment. Egress speed limits in Azure are based entirely on the VM type and size, and then they're limited by your connection to them. While not offering as many pathways to access their Cloud as GCP, Azure does offer a direct network-to-network connection called ExpressRoute. Offered by a large group of third-party processors, partners, the ExpressRoute offers multiple tiers of performance that are based on a flat charge for inbound data and a metered charge for outbound data. And of course you can still access these via the internet, and securely through a VPN gateway. So on behalf of Jeff, Sumeet, and myself, I'd like to thank you for listening to our presentation today, and we're now ready for Q&A.

hi everybody thank you for joining us today for the virtual Vertica BBC 2020 today's breakout session is entitled Vertica and en mode at the trade desk my name is su LeClair director of marketing at Vertica and I'll be your host for this webinar joining me is Ron Cormier senior Vertica database engineer at the trade desk before we begin I encourage you to submit questions or comments during the virtual session you don't have to wait just type your question or comment in the question box below the slides and click submit there will be a Q&A session at the end of the presentation we'll answer as many questions as we're able to during that time any questions that we don't address we'll do our best to answer them offline alternatively you can visit vertical forums to post your questions there after the session our engineering team is planning to join the forums to keep the conversation going also a quick reminder that you can maximize your screen by clicking the double arrow button in the lower right corner of the slide and yes this virtual session is being recorded and will be available to view on demand this week we'll send you a notification as soon as it's ready so let's get started over to you run thanks - before I get started I'll just mention that my slide template was created before social distancing was a thing so hopefully some of the images will harken us back to a time when we could actually all be in the same room but with that I want to get started uh the date before I get started in thinking about the technology I just wanted to cover my background real quick because I think it's peach to where we're coming from with vertically on at the trade desk and I'll start out just by pointing out that prior to my time in the trade desk I was a tech consultant at HP HP America and so I traveled the world working with Vertica customers helping them configure install tune set up their verdict and databases and get them working properly so I've seen the biggest and the smallest implementations and everything in between and and so now I'm actually principal database engineer straight desk and and the reason I mentioned this is to let you know that I'm a practitioner I'm working with with the product every day or most days this is a marketing material so hopefully the the technical details in this presentation are are helpful I work with Vertica of course and that is most relative or relevant to our ETL and reporting stack and so what we're doing is we're taking about the data in the Vertica and running reports for our customers and we're an ad tech so I did want to just briefly describe what what that means and how it affects our implementation so I'm not going to cover the all the details of this slide but basically I want to point out that the trade desk is a DSP it's a demand-side provider and so we place ads on behalf of our customers or agencies and ad agencies and their customers that are advertised as brands themselves and the ads get placed on to websites and mobile applications and anywhere anywhere digital advertising happens so publishers are what we think ocean like we see here espn.com msn.com and so on and so every time a user goes to one of these sites or one of these digital places and an auction takes place and what people are bidding on is the privilege of showing and add one or more ads to users and so this is this is really important because it helps fund the internet ads can be annoying sometimes but they actually help help are incredibly helpful in how we get much much of our content and this is happening in real time at very high volumes so on the open Internet there is anywhere from seven to thirteen million auctions happening every second of those seven to thirteen million auctions happening every second the trade desk bids on hundreds of thousands per second um so that gives it and anytime we did we have an event that ends up in Vertica that's that's one of the main drivers of our data volume and certainly other events make their way into Vertica as well but that wanted to give you a sense of the scale of the data and sort of how it's impacting or how it is impacted by sort of real real people in the world so um the uh let's let's take a little bit more into the workload and and we have the three B's in spades late like many many people listening to a massive volume velocity and variety in terms of the data sizes I've got some information here some stats on on the raw data sizes that we deal with on a daily basis per day so we ingest 85 terabytes of raw data per day and then once we get it into Vertica we do some transformations we do matching which is like joins basically and we do some aggregation group buys to reduce the data and make it clean it up make it so it's more efficient to consume buy our reporting layer so that matching in aggregation produces about ten new terabytes of raw data per day it all comes from the it all comes from the data that was ingested but it's new data and so that's so it is reduced quite a bit but it's still pretty pretty high high volume and so we have this aggregated data that we then run reports on on behalf of our customers so we have about 40,000 reports per day oh that's probably that's actually a little bit old and older number it's probably closer to 50 or 55,000 reports per day at this point so it's I think probably a pretty common use case for for Vertica customers it's maybe a little different in the sense that most of the reports themselves are >> reports so they're not it's not a user sitting at a keyboard waiting for the result basically we have we we have a workflow where we do the ingest we do this transform and then and then once once all the data is available for a day we run reports on behalf of our customer to let me have our customers on that that daily data and then we send the reports out you via email or we drop them in a shared location and then they they look at the reports at some later point of time so it's up until yawn we did all this work on on enterprise Vertica at our peak we had four production enterprise clusters each which held two petabytes of raw data and I'll give you some details on on how those enterprise clusters were configured in the hardware but before I do that I want to talk about the reporting workload specifically so the the reporting workload is particularly lumpy and what I mean by that is there's a bunch of work that becomes available bunch of queries that we need to run in a short period of time after after the days just an aggregation is completed and then the clusters are relatively quiet for the remaining portion of the day that's not to say they are they're not doing anything as far as read workload but they certainly are but it's much less reactivity after that big spike so what I'm showing here is our reporting queue and the spike is is when all those reports become a bit sort of ailable to be processed we can't we can't process we can't run the report until we've done the full ingest and matching and aggregation for the day and so right around 1:00 or 2:00 a.m. UTC time every day that's when we get this spike and the spike we affectionately called the UTC hump but basically it's a huge number of queries that need to be processed sort of as soon as possible and we have service levels that dictate what as soon as possible means but I think the spike illustrates our use case pretty pretty accurately and um it really as we'll see it's really well suited for pervert icky on and we'll see what that means so we've got our we had our enterprise clusters that I mentioned earlier and just to give you some details on what they look like there they were independent and mirrored and so what that means is all four clusters held the same data and we did this intentionally because we wanted to be able to run our report anywhere we so so we've got this big queue over port is big a number of reports that need to be run and we've got these we started we started with one cluster and then we got we found that it couldn't keep up so we added a second and we found the number of reports went up that we needed to run that short period of time and and so on so we eventually ended up with four Enterprise clusters basically with this with the and we'd say they were mirrored they all had the same data they weren't however synchronized they were independent and so basically we would run the the tailpipe line so to speak we would run ingest and the matching and the aggregation on all the clusters in parallel so they it wasn't as if each cluster proceeded to the next step in sync with which dump the other clusters they were run independently so it was sort of like each each cluster would eventually get get consistent and so this this worked pretty well for for us but it created some imbalances and there was some cost concerns that will dig into but just to tell you about each of these each of these clusters they each had 50 nodes they had 72 logical CPU cores a half half a terabyte of RAM a bunch of raid rated disk drives and 2 petabytes of raw data as I stated before so pretty big beefy nodes that are physical physical nodes that we held we had in our data centers we actually reached these nodes so so it was on our data center providers data centers and the these were these these were what we built our business on basically but there was a number of challenges that we ran into as we as we continue to build our business and add data and add workload and and the first one is is some in ceremony can relate to his capacity planning so we had to prove think about the future and try to predict the amount of work that was going to need to be done and how much hardware we were going to need to satisfy that work to meet that demand and that's that's just generally a hard thing to do it's very difficult to verdict the future as we can probably all attest to and how much the world has changed and even in the last month so it's a it's a very difficult thing to do to look six twelve eighteen eighteen months into the future and sort of get it right and and and what people what we tended to do is we reach or we tried to our art plans our estimates were very conservative so we overbought in a lot of cases and not only that we had to plan for the peak so we're planning for that that that point in time that those number of hours in the early morning when we had to we had all those reports to run and so that so so we ended up buying a lot of hardware and we actually sort of overbought at times and then and then as the hardware were days it would kind of come into it would come into maturity and we have our our our workload would sort of come approach matching the demand so that was one of the big challenges the next challenge is that we were running on disk you can we wanted to add data in sort of two dimensions the only dimensions that everybody can think about we wanted to add more columns to our big aggregates and we wanted to keep our big aggregates for for longer periods of time so both horizontally and vertically we wanted to expand the datasets but we basically were running out of disk there was no more disk in and it's hard to add a disc to Vertica in enterprise mode not not impossible but certainly hard and and one cannot add discs without adding compute because enterprise mode the disk is all local to each of the nodes for most most people you can do not exchange with sands and other external rays but that's there are a number of other challenges with that so um adding in order to add disk we had to add compute and that basically meant kept us out of balance we're adding more compute than we needed for the amount of disk so that was the problem certainly physical nodes getting them the order delivered racked cables even before we even start such Vertica there's lead times there and and so it's also long commitment since we like I mentioned me Lisa hardware so we were committing to these nodes these physical servers for two or three years at a time and I mentioned that can be a hard thing to do but we wanted to least to keep our capex down so we wanted to keep our aggregates for a long period of time we could have done crazy things or more exotic things to to help us with this if we had to in enterprise mode we could have started to like daisy chain clusters together and that would have been sort of a non-trivial engineering effort because we would need to then figure out how to migrate data source first to recharge the data across all the clusters and we had to migrate data from one cluster to another cluster hesitation and we would have to think about how to aggregate run queries across clusters so if you assured data set spans two clusters it would have had to sort of aggregated within each cluster maybe and then build something on top the aggregated the data from each of those clusters so not impossible things but certainly not easy things and luckily for us we started talking about two Vertica about separation of compute and storage and I know other customers were talking to Vertica as we were people had had these problems and so Vertica inyeon mode came to the rescue and what I want to do is just talk about nyan mode really briefly for for those in the audience who aren't familiar but it's basically Vertigo's answered to the separation of computing storage it allows one to scale compute and or storage separately and and this there's a number of advantages to doing that whereas in the old enterprise days when you add a compute you added stores and vice-versa now we can now we can add one or the other or both according to how we want to and so really briefly how this works this slide this figure was taken directly from the verdict and documentation and so just just to talk really briefly about how it works the taking advantage of the cloud and so in this case Amazon Web Services the elasticity in the cloud and basically we've got you seen two instances so elastic cloud compute servers that access data that's in an s3 bucket and so three three ec2 nodes and in a bucket or the the blue objects in this diagram and the difference is a couple of a couple of big differences one the data no longer the persistent storage of the data the data where the data lives is no longer on each of the notes the persistent stores of the data is in s3 bucket and so what that does is it basically solves one of our first big problems which is we were running out of disk the s3 has for all intensive purposes infinite storage so we can keep much more data there and that mostly solved one of our big problems so the persistent data lives on s3 now what happens is when a query runs it runs on one of the three nodes that you see here and assuming we'll talk about depo in a second but what happens in a brand new cluster where it's just just spun up the hardware is the query will will run on those ec2 nodes but there will be no data so those nodes will reach out to s3 and run the query on remote storage so that so the query that the nodes are literally reaching out to the communal storage for the data and processing it entirely without using any data on on the nodes themselves and so that that that works pretty well it's not as fast as if the data was local to the nodes but um what Vertica did is they built a caching layer on on each of the node and that's what the depot represents so the depot is some amount of disk that is relatively local to the ec2 node and so when the query runs on remote stores on the on the s3 data it then queues up the data for download to the nodes and so the data will get will reside in the Depot so that the next query or the subsequent subsequent queries can run on local storage instead of remote stores and that speeds things up quite a bit so that that's that's what the role of the Depot is the depot is basically a caching layer and we'll talk about the details of how we can see your in our Depot the other thing that I want to point out is that since this is the cloud another problem that helps us solve is the concurrency problem so you can imagine that these three nodes are one sort of cluster and what we can do is we can spit up another three nodes and have it point to the same s3 communal storage bucket so now we've got six nodes pointing to the same data but we've you isolated each of the three nodes so that they act as if they are their own cluster and so vertical calls them sub-clusters so we've got two sub clusters each of which has three nodes and what this has essentially done it is it doubled the concurrency doubled the number of queries that can run at any given time because we've now got this new place which new this new chunk of compute which which can answer queries and so that has given us the ability to add concurrency much faster and I'll point out that for since it's cloud and and there are on-demand pricing models we can have significant savings because when a sub cluster is not needed we can stop it and we pay almost nothing for it so that's that's really really important really helpful especially for our workload which I pointed out before was so lumpy so those hours of the day when it's relatively quiet I can go and stop a bunch of sub clusters and and I will pay for them so that that yields nice cost savings let's be on in a nutshell obviously engineers and the documentation can use a lot more information and I'm happy to field questions later on as well but I want to talk about how how we implemented beyond at the trade desk and so I'll start on the left hand side at the top the the what we're representing here is some clusters so there's some cluster 0 r e t l sub cluster and it is a our primary sub cluster so when you get into the world of eon there's primary Club questions and secondary sub classes and it has to do with quorum so primary sub clusters are the sub clusters that we always expect to be up and running and they they contribute to quorum they decide whether there's enough instances number a number of enough nodes to have the database start up and so these this is where we run our ETL workload which is the ingest the match in the aggregate part of the work that I talked about earlier so these nodes are always up and running because our ETL pipeline is always on we're internet ad tech company like I mentioned and so we're constantly getting costly running ad and there's always data flowing into the system and the matching is happening in the aggregation so that part happens 24/7 and we wanted so that those nodes will always be up and running and we need this we need that those process needs to be super efficient and so what that is reflected in our instance type so each of our sub clusters is sixty four nodes we'll talk about how we came at that number but the infant type for the ETL sub cluster the primary subclusters is I 3x large so that is one of the instance types that has quite a bit of nvme stores attached and we'll talk about that but on 32 cores 240 four gigs of ram on each node and and that what that allows us to do I should have put the amount of nvme but I think it's seven terabytes for anything me storage what that allows us to do is to basically ensure that our ETL everything that this sub cluster does is always in Depot and so that that makes sure that it's always fast now when we get to the secondary subclusters these are as mentioned secondary so they can stop and start and it won't affect the cluster going up or down so they're they're sort of independent and we've got four what we call Rhian subclusters and and they're not read by definition or technically they're not read only any any sub cluster can ingest and create your data within the database and that'll all get that'll all get pushed to the s3 bucket but logically for us they're read only like these we just most of these the work that they happen to do is read only which it is which is nice because if it's read only it doesn't need to worry about commits and we let we let the primary subclusters or ETL so close to worry about committing data and we don't have to we don't have to have the all nodes in the database participating in transaction commits so we've got a for read subclusters and we've got one EP also cluster so a total of five sub clusters each so plus they're running sixty-four nodes so that gives us a 320 node database all things counted and not all those nodes are up at the same time as I mentioned but often often for big chunks of the days most of the read nodes are down but they do all spin up during our during our busy time so for the reading so clusters we've got I three for Excel so again the I three incidents family type which has nvme stores these notes have I think three and a half terabytes of nvme per node we just rate it to nvme drives we raid zero them together and 16 cores 122 gigs of ram so these are smaller you'll notice but it works out well for us because the the read workload is is typically dealing with much smaller data sets than then the ingest or the aggregation workbook so we can we can run these workloads on on smaller instances and leave a little bit of money and get more granularity with how many sub clusters are stopped and started at any given time the nvme doesn't persist the data on it isn't persisted remember you stop and start this is an important detail but it's okay because the depot does a pretty good job in that in that algorithm where it pulls data in that's recently used and the that gets pushed out a victim is the data that's least reasons use so it was used a long time ago so it's probably not going to be used to get so we've got um five sub-clusters and we have actually got to two of those so we've got a 320 node cluster in u.s. East and a 320 node cluster in u.s. West so we've got a high availability region diversity so and their peers like I talked about before they're they're independent but but yours they are each run 128 shards and and so with that what that which shards are is basically the it's similar to segmentation when you take those dataset you divide it into chunks and though and each sub cluster can concede want the data set in its entirety and so each sub cluster is dealing with 128 shards it shows 128 because it'll give us even distribution of the data on 64 node subclusters 60 120 might evenly by 64 and so there's so there's no data skew and and we chose 128 because the sort of ginger proof in case we wanted to double the size of any of the questions we can double the number of notes and we still have no excuse the data would be distributed evenly the disk what we've done is so we've got a couple of raid arrays we've got an EBS based array that they're catalog uses so the catalog storage location and I think we take for for EBS volumes and raid 0 them together and come up with 128 gigabyte Drive and we wanted an EPS for the catalog because it we can stop and start nodes and that data will persist it will come back when the node comes up so we don't have to run a bunch of configuration when the node starts up basically the node starts it automatically joins the cluster and and very strongly there after it starts processing work let's catalog and EBS now the nvme is another raid zero as I mess with this data and is ephemeral so let me stop and start it goes away but basically we take 512 gigabytes of the nvme and we give it to the data temp storage location and then we take whatever is remaining and give it to the depot and since the ETL and the reading clusters are different instance types they the depot is is side differently but otherwise it's the same across small clusters also it all adds up what what we have is now we we stopped the purging data for some of our big a grits we added bunch more columns and what basically we at this point we have 8 petabytes of raw data in each Jian cluster and it is obviously about 4 times what we can hold in our enterprise classes and we can continue to add to this maybe we need to add compute maybe we don't but the the amount of data that can can be held there against can obviously grow much more we've also built in auto scaling tool or service that basically monitors the queue that I showed you earlier monitors for those spikes I want to see as low spikes it then goes and starts up instances one sub-collector any of the sub clusters so that's that's how that's how we we have compute match the capacity match that's the demand also point out that we actually have one sub cluster is a specialized nodes it doesn't actually it's not strictly a customer reports sub clusters so we had this this tool called planner which basically optimizes ad campaigns for for our customers and we built it it runs on Vertica uses data and Vertica runs vertical queries and it was it was wildly successful um so we wanted to have some dedicated compute and beyond witty on it made it really easy to basically spin up one of these sub clusters or new sub cluster and say here you go planner team do what you want you can you can completely maximize the resources on these nodes and it won't affect any of the other operations that were doing the ingest the matching the aggregation or the reports up so it gave us a great deal of flexibility and agility which is super helpful so the question is has it been worth it and without a doubt the answer is yes we're doing things that we never could have done before sort of with reasonable cost we have lots more data specialized nodes and more agility but how do you quantify that because I don't want to try to quantify it for you guys but it's difficult because each eon we still have some enterprise nodes by the way cost as you have two of them but we also have these Eon clusters and so they're there they're running different workloads the aggregation is different the ingest is running more on eon does the number of nodes is different the hardware is different so there are significant differences between enterprise and and beyond and when we combine them together to do the entire workload but eon is definitely doing the majority of the workload it has most of the data it has data that goes is much older so it handles the the heavy heavy lifting now the query performance is more anecdotal still but basically when the data is in the Depot the query performance is very similar to enterprise quite close when the data is not in Depot and it needs to run our remote storage the the query performance is is is not as good it can be multiples it's not an order not orders of magnitude worse but certainly multiple the amount of time that it takes to run on enterprise but the good news is after the data downloads those young clusters quickly catch up as the cache populates there of cost I'd love to be able to tell you that we're running to X the number of reports or things are finishing 8x faster but it's not that simple as you Iran is that you it is me I seem to have gotten to thank you you hear me okay I can hear you now yeah we're still recording but that's fine we can edit this so if I'm just talking to the person the support person he will extend our recording time so if you want to maybe pick back up from the beginning of the slide and then we'll just edit out this this quiet period that we have sir okay great I'm going to go back on mute and why don't you just go back to the previous slide and then come into this one again and I'll make sure that I tell the person who yep perfect and then we'll continue from there is that okay yeah sound good all right all right I'm going back on yet so the question is has it been worth it and for us the answer has been a resounding yes we're doing things that we never could have done at reasonable cost before and we got more data we've got this Y note this law has nodes and in work we're much more agile so how to quantify that um well it's not quite as simple and straightforward as you might hope I mean we still have enterprise clusters we've got to update the the four that we had at peak so we've still got two of those around and we got our two yawn clusters but they're running different workloads and they're comprised of entirely different hardware the dependence has I've covered the number of nodes is different for sub-clusters so 64 versus 50 is going to have different performance the the workload itself the aggregation is aggregating more columns on yon because that's where we have disk available the queries themselves are different they're running more more queries on more intensive data intensive queries on yon because that's where the data is available so in a sense it is Jian is doing the heavy lifting for the cluster for our workload in terms of query performance still a little anecdotal but like when the queries that run on the enterprise cluster the performance matches that of the enterprise cluster quite closely when the data is in the Depot when the data is not in a Depot and Vertica has to go out to the f32 to get the data performance degrades as you might expect it can but it depends on the curious all things like counts counts are is really fast but if you need lots of the data from the material others to realize lots of columns that can run slower I'm not orders of magnitude slower but certainly multiple of the amount of time in terms of costs anecdotal will give a little bit more quantifying here so what I try to do is I try to figure out multiply it out if I wanted to run the entire workload on enterprise and I wanted to run the entire workload on e on with all the data we have today all the queries everything and to try to get it to the Apple tab so for enterprise the the and estimate that we do need approximately 18,000 cores CPU cores all together and that's a big number but that's doesn't even cover all the non-trivial engineering work that would need to be required that I kind of referenced earlier things like starting the data among multiple clusters migrating the data from one culture to another the daisy chain type stuff so that's that's the data point now for eon is to run the entire workload estimate we need about twenty thousand four hundred and eighty CPU cores so more CPU cores uh then then enterprise however about half of those and partly ten thousand of both CPU cores would only run for about six hours per day and so with the on demand and elasticity of the cloud that that is a huge advantage and so we are definitely moving as fast as we can to being on all Aeon we have we have time left on our contract with the enterprise clusters or not we're not able to get rid of them quite yet but Eon is certainly the way of the future for us I also want to point out that uh I mean yawn is we found to be the most efficient MPP database on the market and what that refers to is for a given dollar of spend of cost we get the most from that zone we get the most out of Vertica for that dollar compared to other cloud and MPP database platforms so our business is really happy with what we've been able to deliver with Yan Yan has also given us the ability to begin a new use case which is probably this case is probably pretty familiar to folks on the call where it's UI based so we'll have a website that our customers can log into and on that website they'll be able to run reports on queries through the website and have that run directly on a separate row to get beyond cluster and so much more latent latency sensitive and concurrency sensitive so the workflow that I've described up until this point has been pretty steady throughout the day and then we get our spike and then and then it goes back to normal for the rest of the day this workload it will be potentially more variable we don't know exactly when our engineers are going to deliver some huge feature that is going to make a 1-1 make a lot of people want to log into the website and check how their campaigns are doing so we but Yohn really helps us with this because we can add a capacity so easily we cannot compute and we can add so we can scale that up and down as needed and it allows us to match the concurrency so beyond the concurrency is much more variable we don't need a big long lead time so we're really excited about about this so last slide here I just want to leave you with some things to think about if you're about to embark or getting started on your journey with vertically on one of the things that you'll have to think about is the no account in the shard count so they're kind of tightly coupled the node count we determined by figuring like spinning up some instances in a single sub cluster and getting performance smaller to finding an acceptable performance considering current workload future workload for the queries that we had when we started and so we went with 64 we wanted to you want to certainly want to increase over 50 but we didn't want to have them be too big because of course it costs money and so what you like to do things in power to so 64 nodes and then the shard count for the shards again is like the data segmentation is a new type of segmentation on the data and the start out we went with 128 it began the reason is so that we could have no skew but you know could process the same same amount of data and we wanted to future-proof it so that's probably it's probably a nice general recommendation doubleness account for the nodes the instance type and and how much people space those are certainly things you're going to consider like I was talking about we went for they I three for Excel I 3/8 Excel because they offer good good Depot stores which gives us a really consistent good performance and it is all in Depot the pretty good mud presentation and some information on on I think we're going to use our r5 or the are for instance types for for our UI cluster so much less the data smaller so much less enter this on Depot so we don't need on that nvm you stores the reader we're going to want to have a reserved a mix of reserved and on-demand instances if you're if you're 24/7 shop like we are like so our ETL subclusters those are reserved instances because we know we're going to run those 24 hours a day 365 days a year so there's no advantage of having them be on-demand on demand cost more than reserve so we get cost savings on on figuring out what we're going to run and have keep running and it's the read subclusters that are for the most part on on demand we have one of our each sub Buster's is actually on 24/7 because we keep it up for ad-hoc queries your analyst queries that we don't know when exactly they're going to hit and they want to be able to continue working whenever they want to in terms of the initial data load the initial data ingest what we had to do and now how it works till today is you've got to basically load all your data from scratch there isn't a great tooling just yet for data populate or moving from enterprise to Aeon so what we did is we exported all the data in our enterprise cluster into park' files and put those out on s3 and then we ingested them into into our first Eon cluster so it's kind of a pain we script it out a bunch of stuff obviously but they worked and the good news is that once you do that like the second yon cluster is just a bucket copy in it and so there's tools missions that can help help with that you're going to want to manage your fetches and addiction so this is the data that's in the cache is what I'm referring to here the data that's in the default and so like I talked about we have our ETL cluster which has the most recent data that's just an injected and the most difficult data that's been aggregated so this really recent data so we wouldn't want anybody logging into that ETL cluster and running queries on big aggregates to go back one three years because that would invalidate the cache the depot would start pulling in that historical data and it was our assessing that historical data and evicting the recent data which would slow things out flow down that ETL pipelines so we didn't want that so we need to make sure that users whether their service accounts or human users are connecting to the right phone cluster and I mean we just created the adventure users with IPS and target groups to palm those pretty-pretty it was definitely something to think about lastly if you're like us and you're going to want to stop and start nodes you're going to have to have a service that does that for you we're where we built this very simple tool that basically monitors the queue and stops and starts subclusters accordingly we're hoping that that we can work with Vertica to have it be a little bit more driven by the cloud configuration itself so for us all amazon and we love it if we could have it have a scale with the with the with the eight of us can take through points do things to watch out for when when you're working with Eon is the first is system table queries on storage layer or metadata and the thing to be careful of is that the storage layer metadata is replicated it's caught as a copy for each of the sub clusters that are out there so we have the ETL sub cluster and our resources so for each of the five sub clusters there is a copy of all the data in storage containers system table all the data and partitions system table so when you want to use this new system tables for analyzing how much data you have or any other analysis make sure that you filter your query with a node name and so for us the node name is less than or equal to 64 because each of our sub clusters at 64 so we limit we limit the nodes to the to the 64 et 64 node ETL collector otherwise if we didn't have this filter we would get 5x the values for counts and some sort of stuff and lastly there is a problem that we're kind of working on and thinking about is a DC table data for sub clusters that are our stops when when the instances stopped literally the operating system is down and there's no way to access it so it takes the DC table DC table data with it and so I cannot after after my so close to scale up in the morning and then they scale down I can't run DC table queries on how what performed well and where and that sort of stuff because it's local to those nodes so we're working on something so something to be aware of and we're working on a solution or an implementation to try to suck that data out of all the notes you can those read only knows that stop and start all the time and bring it in to some other kind of repository perhaps another vertical cluster so that we can run analysis and monitoring even you want those those are down that's it um thanks for taking the time to look into my presentation really do it thank you Ron that was a tremendous amount of information thank you for sharing that with everyone um we have some questions come in that I would like to present to you Ron if you have a couple min it your first let's jump right in the first one a loading 85 terabytes per day of data is pretty significant amount what format does that data come in and what does that load process look like yeah a great question so the format is a tab separated files that are Jesus compressed and the reason for that could basically historical we don't have much tabs in our data and this is how how the data gets compressed and moved off of our our bidders the things that generate most of this data so it's a PSD gzip compressed and how you kind of we kind of have how we load it I would say we have actually kind of a Cadillac loader in a couple of different perspectives one is um we've got this autist raishin layer that's homegrown managing the logs is the data that gets loaded into Vertica and so we accumulate data and then we take we take some some files and we push them to redistribute them along the ETL nodes in the cluster and so we're literally pushing the file to through the nodes and we then run a copy statement to to ingest data in the database and then we remove the file from from the nodes themselves and so it's a little bit extra data movement which you may think about changing in the future assisting we move more and more to be on well the really nice thing about this especially for for the enterprise clusters is that the copy' statements are really fast and so we the coffee statements use memory but let's pick any other query but the performance of the cautery statement is really sensitive to the amount of available memory and so since the data is local to the nodes literally in the data directory that I referenced earlier it can access that data from the nvme stores and the kabhi statement runs very fast and then that memory is available to do something else and so we pay a little bit of cost in terms of latency and in terms of downloading the data to the nose we might as we move more and more PC on we might start ingesting it directly from s3 not copying the nodes first we'll see about that what's there that's how that's how we read the data interesting works great thanks Ron um another question what was the biggest challenge you found when migrating from on-prem to AWS uh yeah so um a couple of things that come to mind the first was the baculum the data load it was kind of a pain I mean like I referenced in that last slide only because I mean we didn't have tools built to do this so I mean we had to script some stuff out and it wasn't overly complex but yes it's just a lot of data to move I mean even with starting with with two petabytes so making sure that there there is no missed data no gaps making and moving it from the enterprise cluster so what we did is we exported it to the local disk on the enterprise buses and we then we push this history and then we ingested it in ze on again Allspark X oh so it's a lot of days to move around and I mean we have to you have to take an outage at some point stop loading data while we do that final kiss-up phase and so that was that was a challenge a sort of a one-time challenge the other saying that I mean we've been dealing with a week not that we're dealing with but with his challenge was is I mean it's relatively you can still throw totally new product for vertical and so we are big advantages of beyond is allow us to stop and start nodes and recently Vertica has gotten quite good at stopping in part starting nodes for a while there it was it was it took a really long time to start to Noah back up and it could be invasive but we worked with with the engineering team with Yan Zi and others to really really reduce that and now it's not really an issue that we think that we think too much about hey thanks towards the end of the presentation you had said that you've got 128 shards but you have your some clusters are usually around 64 nodes and you had talked about a ratio of two to one why is that and if you were to do it again would you use 128 shards ah good question so that is a reference the reason why is because we wanted to future professionals so basically we wanted to make sure that the number of stars was evenly divisible by the number of nodes and you could I could have done that was 64 I could have done that with 128 or any other multiple entities for but we went with 128 is to try to protect ourselves in the future so that if we wanted to double the number of nodes in the ECL phone cluster specifically we could have done that so that was double from 64 to 128 and then each node would have happened just one chart that it had would have to deal with so so no skew um the second part of question if I had to do it if I had to do it over again I think I would have done I think I would have stuck with 128 we still have I mean so we either running this cluster for more than 18 months now I think especially in USC and we haven't needed to increase the number of nodes so in that sense like it's been a little bit extra overhead having more shards but it gives us the peace of mind that we can easily double that and not have to worry about it so I think I think everyone is a nice place to start and you may even consider a three to one or four to one if if you're if you're expecting really rapid growth that you were just getting started with you on and your business and your gates that's a small now but what you expect to have them grow up significantly less powerful green thank you Ron that's with all the questions that we have out there for today if you do have others please feel free to send them in and we will get back to you and we'll respond directly via email and again our engineers will be available on the vertical forums where you can continue the discussion with them there I want to thank Ron for the great presentation and also the audience for your participation in questions please note that a replay of today's event and a copy of the slides will be available on demand shortly and of course we invite you to share this information with your colleagues as well again thank you and this concludes this webinar and have a great day you