>> Announcer: Live from the Bill Graham Auditorium in San Francisco, it's The Cube, covering PureStorage Accelerate 2018. Brought to you by PureStorage. (upbeat electronic music) >> Man: Graduated ASU. >> Welcome back to PureStorage Accelerate 2018. I am Lisa Martin with The Cube, sporting the clong of Prince, formerly known as, today because we are at the Bill Graham Civic Auditorium, a really cool concert venue that's been here since 1950 and I'm joined by Dave The Who Vellante today. >> Play the toast and tea. (laughs) >> Pretty groovy T-shirt there. And we're joined by a couple of guys, next we've got Axel Streichart, the senior director of business application solutions from Pure and John Meng, senior director of IT operations at Simpson Strong-Tie. Hi guys! >> Hi. >> Lisa: Welcome to The Cube! >> Thank you. >> Thank you. >> So John, first question to you. Tell us about Simpson Strong-Tie. Who are you guys, obviously you're a Pure customer, but give us a little bit of an orientation to the business. >> Sure, so Simpson Strong-Tie, we're a public company based out of Pleasanton, California. We've been in business since about 1956, if I've got my history right, so we've been around for quite a long time. We're a manufacturing organization. Basically, if you're building a home or a deck or if you're needing to put two by fours together, our niche is that little connector, that bracket that connects those two by fours and we do pretty well in that business. Overall our revenue is just shy of a billion dollars, so a pretty decent sized organization. >> Dave: So Pure passed you. >> Yes, last year, you know. >> You okay with that or? >> I'm okay with that. (all laugh) >> So tell us about, from a business perspective, the need for PureStorage specifically with respect to your SAP journey. >> So a couple of years ago when I came on board, the business had made a decision that they were going to get off of their old ERP system onto a new ERP system. When I say old ERP system, I'm being a little respectful there. It's a homegrown application running on SQL which is basically, they lovingly called it Blue Screen because you go to fileshare and you double click on the executable that you need, for example, if you're doing accounts payable or accounts receivables or purchase orders or what have you, you double click on the executable you want, opens up a nice little blue screen and it's a DOS based blue screen and you tab around and enter all your information. They had been running on that application for about 30 years. >> Lisa: Is that all? (laughs) >> Yeah, so quite a while. >> Dave: It works. >> It works, right. If it ain't broke don't fix it, but it was developed by a single person and it was time that the company put on some bootstraps and hitched them up, so they went to market to decide on what ERP application they were going to move to and SAP won out. They had actually been running for a year on a test system hosted by SAP when I came on board, so the decision had already been made, the application wise from an ERP perspective, but the next step in our journey for Simpson, and my challenge, was how do we host this environment? Do we host it in a cloud, do we host it on-prem? And so as I took a, looking at our environment, a very distributed environment, I said, alright, well first and foremost, SAP is a centralized solution. Is there a way for us to create a single environment that our entire company could run on, not only for SAP but everything else, a mixed use environment? And I started having conversations with Pure. They actually let me talk to a couple of their existing customers who were very happy about their mixed use workload including ServiceNow who talked today, so definitely a shout out to them on the conversations we had back a couple of years ago. Anyways, Pure ended up being our foundation for currently our core tenant, which is SAP, but also the future tenant for everything else that we're going to throw on there. And it's been an incredible journey over these last couple of years with them. >> And why the decision to stay on-prem, versus go to the cloud? Was it a function of SAP really not being there in the cloud or your data, you didn't just want to shove your business into the public cloud? >> So there was definitely a lot of analysis that went into that. Just from a financial perspective, I worked with the CFO and we put together a 12 year ROI on cloud versus on-prem and just to kind of really give ourselves some understanding over time what the impact would be of renting versus owning and it was very clear that on-prem financially made sense. Then we had to talk about the business, what was the best for the business. We looked at it from a, when I came there, there was some, the project team looking at SAP had really already made their mind up. They wanted it off of IT. They wanted it in an environment that they trusted, so when I came on board I said, look this is something I've done before. We have experience, we have the in-house expertise, you just trust me that this is the right thing and let me show you how and that's where, honestly, a lot of the information that I was able to pull off of FlashStack, off of SAP, it's a certified solution, talking to ServiceNow I was able to prove to the business that look, hosting it internally made the most sense financially as well as for our business and what we were trying to achieve. >> Made you happy. >> Yeah and it's not just that, but this is a story we're hearing more often now. So customers actually trying this out in the cloud and realizing, number one, the cost, it's not that cost-efficient and effective as they were planning for and seeing, especially when you're making multiple copies of this SAP environments. The costs go through the roof and the other thing is also what a lot of customers then realize is how do you actually get your data and get your communication from your data center back to the cloud provider? You need a big pipe and this communication cost just to get the data out is huge, is sometimes huge. The other thing is SLAs. It sounds like a good thing, but in many cases, SLA's because they're not flexible, you're ending up quarter end you need help and they're saying, nope, talk to you in four days. It's not really acceptable. And the third one is, there's this whole concept around I don't really have to invest now into the knowledge, into the skill set, because I put it all in the cloud. It's not the reality. The reality, you still have to invest into the skills. Isn't that? >> Everything he has said is actually the conversations that we had in-house, absolutely. If you want to do a data migration from QA to Dev or Dev to Production or whatever your landscape is and how you want to move the data, oh, well, that's going to be a charge. Oh well, okay, well I need to spin up this extra project. Oh, well there's another charge. I mean, it's just constant nickel and diming and another key component that you hit on that I failed to mention was hosting it internally allowed us to control the end to end experience for our end users. When you're talking about hosting it in the cloud, your data is somewhere else and you can not control end to end. You can control it up to a certain extent, but then from there all you can rely on is the SLAs and, to his point, the SLAs are only what's on paper, they're not very flexible at all. >> So the business case didn't pan out for the cloud. >> Correct. >> But there's certainly attributes of the cloud that are attractive, so what are those attributes and how are you bringing those on-prem? >> So flexibility. Flexibility is huge for us, the ability to just quickly be able to spin things up and scale them back as needed. I kind of look of it as, look, there's a water line that you're going to use on a day in and day out basis for your organization. Maximize your investment there. On the peaks and valleys that you're going to have, that's where the cloud can really help and so, is cloud completely off the table for us? No, that's where we're going to be able to burst into that sort of scenario. If we need more compute, we need more spin cycles, whatever we need from the cloud, we can throw it up there and then bring it back down, so have much more controllable costs in our mind. >> So a major change in the application environment, migration, from an old platform. You had to freeze the app. Does that freeze the code? >> John: Yep. >> How long did you have to freeze the code for? >> So, when we're talking about, just making sure I understand your question. >> Your home-grown ERP, blue screen, C prompt to the SAP environment. >> Yeah, so the landscape as we have it today, we actually just went live on SAP early February and it's not company wide. It's only a certain branch. In its strength, the beauty of that previous application, it was very de-centralized and each branch where we have a high consolidation of users and workers, each branch had their own data center hosting their own ERP for their branch, so we could freeze their environment just during their time window. >> I see. >> Now the challenge for us today is as we start consolidating, those windows start to overlap, but that's honestly why we've invested in technologies like FlashStack and so forth that come with the redundancy built in so we can work on the environment without having to freeze it or bring it down. >> So you need the speed to compress those discontinuities. >> Yes, yes. >> Dave: In data. >> Absolutely. >> What about data protection? How do you, I know that's an area of expertise of yours. How do you approach data protection in this new environment? Are you doing anything differently? Where does Pure fit? >> It's actually a huge shift for us on how we do things. From a data protection standpoint, we're talking about disaster recovery, business continuity and so we have active passive data centers. We're utilizing what Pure has under the hood to be able to replicate in multiple ways. And that's the beauty of our setup that we've designed is the ability to replicate in multiple ways, because in a multi-tenant environment, yes, there are certain parts of the stack that one shoe will fit all sizes. I would say that PureStorage is that, but when you start getting to the details of each of the applications, they don't all play the same way when it comes to DR or it comes to replication or data protection and we will need to look at each one of those applications and design a data protection strategy around it as we import it in, so for SAP, we do have differencing of how we're going to protect that versus when we bring in our web servers, versus when we bring in SharePoint and other core applications to the business. >> So Axel, you mentioned, well actually it was John, you mentioned that you had the opportunity to talk to ServiceNow and maybe another customer of Pure as well when you were in this decision making process. I imagine ServiceNow's business is probably quite different from Simpson Strong-Tie, so what, Axel, I guess both of you, help us understand, what were some of the similar changes that, say, a ServiceNow faced that you were facing and then Axel, to your point, tell us a little bit about the SAP alliance that you have with Pure and how customers as big as ServiceNow and Simpson Strong-Tie are helping to evolve that relationship? >> Me first? >> Go for it. >> Alright, so one of the biggest strategies, the focus that I had when I was making the decision around hosting SAP, I really wanted to make sure I understood, did I have to go a siloed approach? Was I buying architecture specifically for SAP or could I do a multi-use workload? Multi-purpose was huge for me. I was really, I couldn't understand how, in 2016 when I was looking at this, I'm like, look, it's 2016, I know there's a solution out there that can solve this problem and so that's what I was challenging Pure and they're like, who do you want to talk to? And I said, "Well I want to talk to somebody "who's running SAP and I want to talk to somebody "who's running SAP in a mixed-workload environment." And that's where ServiceNow came into play. And when I was having conversations with them, I said, alright, so you're running mixed workload. Yes, okay, when you have an SAP performance problem, do you have to, is there a lot of effort to show that there's, where the problem in the performance is? And there was a pause on the phone and the guy actually giggled over the phone. I don't know how else to say it. And he's like, "Performance problems? "We don't have any." And so, when you hear that, especially when you're talking about SAP, which is a known beast of an application inside any environment and it will use whatever resource you throw at it and it won't play nice with other apps, when I heard that, I was like, okay, where do I sign? So it was basically that conversation that really said, alright, let's give this a try. The other thing, honestly, for us is SAP is our first tenant and as we start applying other applications to it, we already have our baseline established and we can watch as the other applications are thrown in and it's not impacting anything, SAP, or on their own. >> So FlashStack is going to be able to give you a foundation to not only scale your SAP infrastructure-- >> Absolutely. >> But also to expand to multiple workloads. >> Yeah, for example, some of our public web facing applications, we've already moved them in-house. We used to use a public service provider, a public cloud offering for this web service that I'm talking about. It would take, so you'd go out there and you'd say, you know what, I want a product catalog of all Simpson products and you hit the button. 45 minutes later, it's downloaded, 45 minutes. I took that workload and I put it in our data center. Three minutes. 45 minutes to three minutes. >> Lisa: Wow. >> And then another test was a web crawler, so we did a web crawler across that same web application to confirm when we moved it from one location to the other we didn't miss anything. In the old environment, running on a public cloud infrastructure, it took 20 minutes. 17 seconds on our own. And it was run from the same PC. There was no, it was pretty clear and honestly, when marketing felt that increase in performance and saw it and realized it, they bragged to the CFO and now the CFO's like, okay, when are we going to get this out of SAP? Well we have to get the whole company on SAP before we can really realize this investment, but they're very excited about the opportunities. >> And how long have you had the Pure infrastructure? >> We installed it probably about year and a half ago, because we had to get it prepared. We installed it about a year and a half ago. >> So you haven't had to do any upgrades yet. >> No, not major ones. We actually have our first major one this week. We're actually scheduling it, but one of the questions I was asked on an earlier panel was how due you handle outages with Pure and how has your experience been with support. Well, I'm sorry we haven't had to call support yet. I've heard great stories about it (Lisa laughs) and I know that our guys that are working with support right now to get our upgrades done, they've had nothing but praise, but honestly we haven't had a lot of interaction yet with their support, just because we haven't needed it yet. >> And you have an in-house development staff, application development team? >> Yes. >> Has their work flow changed at all in terms of being able to share data, share copies of data, are you there yet or? >> We're not there yet, but one of the goals of our environment, so we have two data centers and we have load balancers in front of the two data centers. When it comes to hosting our public web side of things, the goal is to have a green and a red environment where you develop on the red, green is your production and when it comes time, you just flip the switch and your development becomes your active. And so, basically, a lot of the nuances and strategies that you get out of public cloud, we're going to attain those using our private cloud infrastructure. >> Essentially use live data of the test environment-- >> Absolutely, absolutely. >> And then cutting over immediately. You couldn't have done that three, four, five years ago. >> Absolutely, absolutely. >> So Axel, we're just about out of time, but how common is John's story with Simpson Strong-Tie in terms of, we haven't had to call support yet. Are you hearing this resonate pretty pervasively in your SAP install base across industries? >> This is a very typical environment. I would call it almost green field, but most of the environments that we are dealing with are brown field, so customers are long-time SAP users and customers and they're going from, let's say, the Oracle environment into a HANA environment and the nice thing about this is that we are actually providing a platform that can help customers no matter where they are in their journey. If they are still in Oracle, they're already on HANA, they're moving onto AI, whatever it might be, they don't have to change anything on the infrastructure, per se, because there is no configuration or tuning necessary, whether it's Oracle, whether it's HANA, whether it's AI, so you're running it off the same platform. The other thing is that I want to mention is, because you asked me about our relationship with SAP. It's a very strong relationship, so we're actually working with SAP worldwide in their core innovation labs, so they have labs around the world where they develop new solutions together with hardware and software partners and they love to work with PureStorage because it is so simple and they're coming from a functional side. They don't care about the infrastructure at all. They're saying as long as it's simple and you can imagine they are pretty much the Switzerland of ERP. We actually recently published a white paper together with SAP around how to actually save license cost, SAP license cost, of up to 75%. Now you would ask yourself, why would SAP do that? Why would they promote something, push something, that actually cuts into their revenue? But for SAP it is more important to increase the adoption rate of HANA rather than the revenue that's behind it, so that's why we are publishing, and it's on the SAP website that you can download and you can see, together with PureStorage. It's an amazing story that we have. >> Let-- >> And honestly, that was part of why we chose Pure in the beginning, they're certified and now I didn't have to go to the business and try to convince them. It was all on paper for us. >> I can't help but notice that you brought a little kitty cat to the set, Axel. Tell us about this little stuffed animal. >> Maybe you heard it in the keynote this morning. We were talking about PureStorage is actually moving from their solution development towards engineered solutions. We want to actually put more application specific functionality and embed it directly into the array and one of the big challenges that a lot of customers have is how do I create copies, clones, and refreshes of my SAP environment? And we have customers it takes them sometimes nine days just for one copy, nine days. Why? Because it's a very complex and complicated end to end process, so we thought about why don't we take this entire process, automate this entire process, and embed it into our array, and we call this tool that we developed and that's available for everybody that, it's included in the maintenance. We call it Copy Automation Tool, CAT. >> The cat! >> That's the cat. (all laugh) >> And that's what we are, and so if people are asking, why is a cat, Copy Automation Tool. >> That's good. >> Very nice. >> I was like, where is this going? >> I like it. >> Brought it home, brought it home. >> Like you said. >> Do I get to keep this cat? Is this, oh. >> You can. >> Ah, very nice. >> This is pretty cool swag. Well Axel and John, thank you so much for stopping by and sharing with us the innovations that Pure and SAP are doing, how you are being successful, and now you are a reference customer for what you guys are achieving. >> Great story. >> Thank you. >> Thank you. >> Thanks guys, appreciate your time. >> Thank you. >> Yep. >> We want to thank you for watching The Cube. I'm Lisa Martin with Dave Vellante and cat. We are live from PureStorage Accelerate 2018. Stick around. Dave and I will be right back with our next guest. (upbeat electronic music)

>> Announcer: Live from San Francisco, it's the CUBE covering Pure Accelerate 2017. (upbeat music) Brought to you by Pure Storage. (sparse percussion fading) >> Welcome back to San Francisco. We're at Pier 70, and this is Pure Accelerate. And this is the CUBE, the leader in live tech coverage. I'm Dave Vellante with my co-host David Floyer. First segment of the day. Welcome! >> Thank you. >> Dave: Todd Graham is here. He's the Vice President of IT Infrastructure at ScanSource, Inc. >> Thank you. >> Dave: Axel Streichardt, who's the Director of Business Applications Solutions at Pure Storage. Gentlemen, welcome to the CUBE. >> Thank you. >> Thanks. >> Okay, so let's get right into it. Well, if we start with ScanSource, what does ScanSource do? Set up the interview with just a little background. >> Sure, so we are an international technology distribution company. We have been around since 1994, public since 1994. Today we're in the US, North, we're in Europe, Latin America, and we are quickly growing to 45 to 47 locations around the globe. We focus, very vertically focused, on technology such as telecommunications. Recently we bought a telecommunications services master agency, so we can deal with service and connectivity. Point of sale and barcode is our original business unit. And we do Voice over IP phone systems, videoconferencing, and those types of technologies today. >> You said you started in '94 and you been public since '94. So you started with an IPO? (panelists laughing) >> It was very early. That's correct. (panelists laughing) >> Wow, that's amazing. I'd love, I got to talk to you afterwards. (panelists laughing) >> That's right. That's right. >> That's like Bitcoin or something. Okay, and then maybe we could set up to the segment here. Axel, I saw you speaking here earlier to an audience. >> Axel: Right. >> Maybe describe the discussion that we're going to have here about cloud. >> We, of course, focusing a lot on the different flavors of cloud and the different deployment models that SAP customers are considering today, right? So it could be on premise. Do you want to do it in a hybrid cloud? Do you want it in a public cloud? And we see that, initially, a lot of customers were thinking and considering public cloud as the solution for SAP workloads. And it is interesting that, in recent months, we actually see that from this initial, let's say, movement we see a lot of customers actually reconsidering and coming back, right? And they're seeing that the economics, the flexibility, the agility that they were thinking about when moving certain SAP workloads to the cloud is actually not really the reality. And the reality caught up with them. And they see that the value that they get from Pure Storage actually to run SAP workloads on Pure Storage make way more sense from an economical and also from an agility perspective, right? And we also see that IDC and some other analysts, even SAP themselves, they are actually saying that probably 60%-70% of all SAP workloads will stay on premise. They will not go into a public cloud or cloud deployment. >> Okay, so, Todd. So tell us about, so you're a ERP customer, SAP customer. You decide to move into the cloud. Maybe tell us about that journey. You moved in, and the pendulum swung back. So add some color to. >> Yeah, we were migrating away from our legacy ERP environment and moving to SAP. It was a greenfield opportunity, so we felt like it was the right time to move into the cloud. We looked very heavily at our internal expertise from an applications standpoint as well as an infrastructure standpoint and felt that this would be the right opportunity to move to that infrastructure as a service, application as a service model. And then we could take time to take our center of excellence team around SAP and do knowledge transfer between the cloud organization, the managed organization, and use it as a ramp for us to educate ourselves more around SAP. Some of the other driving factors were simply. Why do we want to go to the cloud? The elasticity, the ease of deployment, the things that we firmly believed at the time were the right decision. And we felt like it could be done quicker by moving to the cloud to do that. >> Okay, so you moved to the cloud, and then it wasn't the experience that you thought it would be. It was >> Todd: Correct. >> Axel mentioned a bunch of factors. The agility wasn't there. The cost wasn't there. Maybe add some color to that as well. >> Yeah, absolutely, we felt like, with the growth of our company through acquisitions, that speed of deployment was going to be key in the future. And we quickly learned that that was not necessarily the case. Everything became request-driven, SLA-driven, versus actually worrying about what was happening within our application itself. And so we just became another customer that was submitting tickets, if you will, in that environment. Stability and performance, we saw some real impacts to the environment that were actually end-user-affecting, which really began to force us to look for some different solutions. >> Okay. So, David, you just participated in a study. We call it the True Private Cloud. >> David: Right. >> So what was happening was it was a lot of cloud washing going on. >> Right. >> And with Private Cloud, we said, "Well, you know, essentially what people want is "to be able to substantially mimic "the public cloud on private." So they can get back that control and address some of the problems. >> That's right. >> So maybe pick it up from there and talk a little bit about. >> Sure, so yes, this, this is reports that we've done on the amount of spend that'll go to hyper-converged types of products and bring it back in-house and offer the same sort of facilities to the end users as you get from a public cloud but in a private cloud itself. So is that how you've done it? Did you take a package, or how did you go, how did you take your work from the public cloud back into the private cloud? >> So part of that was, we did the initial cost analysis of where we were at. And that was one of the main drivers behind, we really can do this in-house ourselves. That's when we began looking at partners that could help us. It was a perfect time that it had set up within our refresh strategy around our traditional storage and compute environment for us to really look at what the cost factors were. Could we improve the performance and the stability of that environment and improve that service to our end users? And so those are the decisions that we made, right? And then we said, "It's time for us to bring that back in." We can have control. And one of the biggest things, and it was really more than control, it was that we understood our environment. And that was the biggest thing that we saw a challenge with, was trying to convey the importance of what was happening within our deployment of SAP to the managed services provider. >> So what led you to the Pure decision? Like David said, you got some kind of converged infrastructure, whatever, the metaphor for mimicking public cloud. What led you to Pure? And we could talk about what the solution was. >> Yeah, one of the things was just the simplicity of Pure. At first, when we heard the story, we weren't sure we really believed it. We were like, "This is, this is entirely too simple." The evergreen model was very intriguing to us at the time, because we had been in that traditional storage and compute environment where, every three years, we had a massive project and do a forklift upgrade with choose any of the providers. And it was, is what we were doing. We were looking to set ourselves up for SAP HANA in the future. We wanted to build an infrastructure that would allow us to get there. And in all of the due diligence that we did, Pure came out on top with that, with a lot of the story around their compression and dedupe capabilities. Performance around IO was just extremely compelling at the time. >> So you got to love this story. >> Absolutely. >> I mean, you hear this a lot from customers? Is this a unique situation maybe? >> Yeah, we see this a lot from customers. Actually by moving SAP workloads, mission-critical workloads, now to Pure Storage. And what really, it's not just about the evergreen and the simplicity, right? What also resonates very well with customers today is our story around the data platform, right? So that's not about storage anymore. It's really about providing a foundation for certain SAP workloads, and you can seamlessly go from, let's say, typical Oracle SAP deployment, and you can start with HANA deployments. Actually, by using our solution, you can actually reducing the cost by up to 75%, right? So these are all compelling reasons, and this all without any configuration changes or any setups that you need specifically for SAP workloads, right? It is so simple that you can run various SAP workloads on the same platform. And to move this, actually, to another angle is, What if in the future you want to do analytics, big data, internet of thing? Again, it's the same platform, it's the same foundation that you can run all these various SAP workloads on. And I think this is a very compelling story. >> And it's interesting for us. It's not just SAP workloads that are running in that environment. >> Oh, really? >> We're, it's, it's a mixed environment, so we're running everything else on top of that FlashStack today. >> Dave: Well, you've done a lot of work. >> Axel: Sure, yes. >> Well, I've got one other question I'd like to ask you about landscapes. See, you're a big international set of companies that you are servicing. So from a landscape point of view, did you want to centralize that onto one landscape or multiple landscapes? And I would have thought that's an area as well where using Flash was a great advantage that you could actually. >> It is centralized today. And then as we grow, we are giving consideration to, Will we have multiple instances across the globe. But today it is centralized and will be so probably for the next 24 months. >> But what you described earlier, Todd, was this horizontal infrastructure layer that could support mixed workloads. But there's got to be some kind of software, something in the middle that supports that as well. Did you have to write something to >> Orchestrate >> To support that >> Was it, yeah, some kind of orchestration or management, stack. >> No, today it was all, everything that we're doing today is within the Pure UI or within Wmware and UCS Manager today. >> Dave: Okay, well that'll get you pretty far. >> Yeah, yeah. Yeah. >> So where do you, what do you take away from this in terms of where this market's going? You talked about analysts generally say that most SAP workload's going to stay on prem. I think we would generally agree with that. >> Yes. Yeah. >> It's going to be a long slog before they're ready for the cloud. At least the core, mission-critical stuff, right? Okay, so that says there's real pressure on IT organizations to mimic substantially that public cloud experience. Are we there today? With a lot more work to be done? I'd like both of your inputs on that. >> Right, and that's the beauty of it. We're actually providing it, at Pure, the various flavors of cloud. So if customers want to actually go from physical to virtual, we are supporting this, because you can actually run your virtual SAP workloads seamlessly on our storage array. At the same time, if you're already then moving to the next level and you want to have a private cloud environment, right? So we have all the components and capabilities actually built into our product that you can do things like self-service, right? You can have chargeback. You can have all the deployment, right? So all of these features that actually make up a private cloud environment, so we have them in our mix already, right? So we more or less have everything ready for customers today. And if they want to actually go to a hybrid cloud, that's why I'm saying. 30%, maybe, to 40% of SAP workloads might go into a cloud, into a public cloud or a hybrid cloud environment. And we're actually also providing this hybrid cloud capability that you can move workloads seamlessly to an Azure, to an AWS, or to Google Cloud. So we just heard this morning we have this capability to move certain workloads seamlessly from on premise, from on premise Pure, onto AWS, for instance. So we have all the ingredients, so throughout this entire journey that the customer wants to go through, that they can actually move along with this one data platform, and that makes it. >> So, Todd, how do you decide now, knowing what you know, what goes where, what to put in the public cloud, what to put on prem, what's eventually going to be hybrid? >> Well, and we have adopted a strategy of Cloud First, which means, Will the workload or will the application fit in that as-a-service model? Does it necessarily mean that we're going to put everything there? We still believe that most mission-critical, anything around the RP, will most likely remain in-house. And one of the main differences that we saw was the availability in uptime that the Pure system gives us around what we could see that the manu-services providers could provide. And downtime is really not tolerated, and it's one of those things that we need. And when it's down, we've got to have things back up, and we need the availability to our end users. And as we expand across the globe, we're becoming more of a 7 by, maybe today we're a 6 by 20. We're not fully 7-by-24 shop yet. But we're getting to that, and so we're looking at the infrastructure that will help us achieve that goal. >> So you're looking at cloud as an operating model more so than a destination. Is that right? >> Todd: That's correct. That's correct. >> And of course, there's the destination aspect of it, which is a function of, what, performance and cost, and. What do you look at? What are the determinants there? >> Yeah, so performance is obviously key for us. Cost is always an important factor, but it's probably number 3 or 4 on the list, right? Availability, uptime, and performance are our key. And if we can get those, we can get the support and the availability that we need, then maybe it makes sense, right? If it's a web application, if it's something that's very straightforward, again, one of the biggest reasons that we go back to bringing it in-house is we truly understood the environment and how things fit together. Whereas in that manu-services environment, it was very difficult to do that. >> And what about security? We haven't talked much about security today. But where does that fit in in your cloud decision? >> David: Especially internationally, the different rules in different countries, for example. >> Yeah, internationally, it's a challenge with all of the data privacy laws and the things that are country-specific, and we're learning a lot of that in Latin America as well (David chuckling) as we begin to move into those markets. But security is absolutely top of mine. We will work with those cloud services providers, but we've talked to a lot of folks along the AWS and the Azure route. And we're comfortable with where the security around the cloud is going. We're talking to a lot of new cloud security brokers to understand what they can bring to the table as well. And it's not just an IT discussion. It's a legal discussion, right >> Right. >> We're having those legal teams come back to us and say, "Well, what does this mean?" Right? Where is the data going to live? And is it going to fit within our retention models and all of the things that we have in place today? >> Alright, good. Okay, we got to leave it there. But Axel, I'll give you the last word. >> The last word? Pure Accelerate. Give me the bumper sticker. >> So we are really excited to have, actually, a confirmation from a customer side to see that the strategy and the direction that we're going here at Pure is exactly on par with what customers are actually demanding and what they want when it comes to SAP or mission-critical workloads. So I'm really glad that we're hearing this now from a customer and get the confirmation from a customer. So I'm just really super duper excited to have Todd here with us to hear from, directly from a customer. >> Excellent. Alright, Cloud First. The CUBE, we hope you're first, we're first on your playlist. Gentlemen, thank you very much for coming on the CUBE. >> Thank you. Thank you. >> I appreciate it. Alright, keep it right there, buddy. We'll be back with our next guest right after this short break. (upbeat percussion music)

>>and hello, we're back. I've got my panel and we are doing things real time here. So sorry for the delay a few minutes late. So the way let's talk about things, the reason we're here and we're going around the room and introduce everybody. Got three special guests here. I got my evil or my john and the normal And we're going to talk about get ops I called it future office just because I want to think about what's the next thing for that at the end, we're gonna talk about what our ideas for what's next for getups, right? Um, because we're all starting to just get into get ups now. But of course a lot of us are always thinking about what's next? What's better? How can we make this thing better? So we're going to take your questions. That's the reason we're here, is to take your questions and answer them. Or at least the best we can for the next hour. And all right, so let's go around the room and introduce yourself. My name is Brett. I am streaming from Brett from that. From Brett. From Virginia Beach in Virginia beach, Virginia, United States. Um, and I talk about things on the internet, I sell courses on you, to me that talk about Docker and kubernetes Ive or introduce yourself. >>How's it going? Everyone, I'm a software engineer at axel Springer, currently based in Berlin and I happen to be Brett Brett's teaching assistant. >>All right, that's right. We're in, we're in our courses together almost every day. Mm john >>hey everyone, my name is john Harris, I used to work at Dhaka um, I now work at VM ware is a star field engineer. Um, so yeah, >>and normal >>awesome by the way, you are streaming from Brett Brett, >>I answered from breath to breath. >>Um I'm normal method. I'm a distinguished engineer with booz allen and I'm also a doctor captain and it's good to see either in person and it's good to see you again john it's been a little while. >>It has the pre covid times, right? You're up here in Seattle. >>Yeah. It feels, it feels like an eternity ago. >>Yeah, john shirt looks red and reminds me of the Austin T shirt. So I was like, yeah, so we all, we all have like this old limited edition doctor on E. >>T. That's a, that's a classic. >>Yeah, I scored that one last year. Sometimes with these old conference church, you have to like go into people's closets. I'm not saying I did that. Um, but you know, you have to go steal stuff, you to find ways to get the swag >>post post covid. If you ever come to my place, I'm going to have to lock the closets. That >>that's right, That's right. >>So the second I think it was the second floor of the doctor HQ in SAn Francisco was where they kept all the T shirts, just boxes and boxes and boxes floor to ceiling. So every time I went to HQ you just you just as many as you can fit in your luggage. I think I have about 10 of these. You >>bring an extra piece of luggage just for your your shirt shirt grab. Um All right, so I'm going to start scanning questions uh so that you don't have to you can you help you all are welcome to do that. And I'm going to start us off with the topic. Um So let's just define the parameters. Like we can talk about anything devops and here we can go down and plenty of rabbit holes. But the kind of, the goal here is to talk about get ups and get ups if you haven't heard about it is essentially uh using versioning systems like get like we've all been getting used to as developers to track your infrastructure changes, not just your code changes and then automate that with a bunch of tooling so that the robots take over. And essentially you have get as a central source of truth and then get log as a central source of history and then there's a bunch of magic little bits in the middle and then supposedly everything is wonderful. It's all automatic. The reality is is what it's often quite messy, quite tricky to get everything working. And uh the edges of this are not perfect. Um so it is a relatively new thing. It's probably three, maybe four years old as an official thing from. We've uh so we're gonna get into it and I'll let's go around the room and the same word we did before and um not to push on that, put you on the spot or anything. But what is, what is one of the things you either like or either hate about getups um that you've enjoyed either using it or you know, whatever for me. I really, I really love that I can point people to a repo that basically is hopefully if they look at the log a tracking, simplistic tracking of what might have changed in that part of the world or the environment. I remember many years past where, you know, I've had executive or some mid level manager wants to see what the changes were or someone outside my team went to see what we just changed. It was okay, they need access to this system into that dashboard and that spreadsheet and then this thing and it was always so complicated and now in a world where if we're using get up orbit bucket or whatever where you can just say, hey go look at that repo if there was three commits today, probably three changes happened. That's I love that particular part about it. Of course it's always more complicated than that. But um Ive or I know you've been getting into this stuff recently. So um any thoughts? Yeah, I think >>my favorite part about get ops is >>reproducibility. Um >>you know the ability to just test something and get it up and running >>and then just tear it down. >>Uh not >>being worried that how did I configure it the first time? I think that's my favorite part about >>it. I'm changing your background as we do this. >>I was going to say, did you just do it get ups pushed to like change his >>background, just a dialogue that different for that green screen equals false? Uh Change the background. Yeah, I mean, um and I mean I think last year was really my first year of actually using it on anything significant, like a real project. Um so I'm still, I still feel like I'm very new to john you anything. >>Yeah, it's weird getups is that thing which kind of crystallizes maybe better than anything else, the grizzled veteran life cycle of emotions with the technology because I think it's easy to get super excited about something new. And when I first looked into get up, so I think this is even before it was probably called getups, we were looking at like how to use guest source of truth, like everything sounds great, right? You're like, wait, get everyone knows, get gets the source of truth, There's a load of robust tooling. This just makes a sense. If everything dies, we can just apply the get again, that would be great. Um and then you go through like the trough of despair, right? We're like, oh no, none of this works. The application is super stateless if this doesn't work and what do we do with secrets and how do we do this? Like how do we get people access in the right place and then you realize everything is terrible again and then everything it equalizes and you're kind of, I think, you know, it sounds great on paper and they were absolutely fantastic things about it, but I think just having that measured approach to it, like it's, you know, I think when you put it best in the beginning where you do a and then there's a magic and then you get C. Right, like it's the magic, which is >>the magic is the mystery, >>right? >>Magic can be good and bad and in text so >>very much so yeah, so um concurrence with with john and ever uh in terms of what I like about it is the potential to apply it to moving security to left and getting closer to a more stable infrastructures code with respect to the whole entire environment. Um And uh and that reconciliation loop, it reminds me of what, what is old is new again? Right? Well, quote unquote old um in terms of like chef and puppet and that the reconciliation loop applied in a in a more uh in a cleaner interface and and into the infrastructure that we're kind of used to already, once you start really digging into kubernetes what I don't like and just this is in concurrence with the other Panelist is it's relatively new. It has um, so it has a learning curve and it's still being, you know, it's a very active um environment and community and that means that things are changing and constantly and there's like new ways and new patterns as people are exploring how to use it. And I think that trough of despair is typically figuring out incrementally what it actually is doing for you and what it's not going to solve for you, right, john, so like that's that trough of despair for a bit and then you realize, okay, this is where it fits potentially in my architecture and like anything, you have to make that trade off and you have to make that decision and accept the trade offs for that. But I think it has a lot of promise for, for compliance and security and all that good stuff. >>Yeah. It's like it's like the potentials, there's still a lot more potential than there is uh reality right now. I think it's like I feel like we're very early days and the idea of especially when you start getting into tooling that doesn't appreciate getups like you're using to get up to and use something else and that tool has no awareness of the concept so it doesn't flow well with all of the things you're trying to do and get um uh things that aren't state based and all that. So this is going to lead me to our first question from Camden asking dumb questions by the way. No dumb questions here. Um How is get apps? Not just another name for C. D. Anybody want to take that as an answer as a question. How is get up is not just another name for C. D. I have things but we can talk about it. I >>feel like we need victor foster kids. Yeah, sure you would have opinions. Yeah, >>I think it's a very yeah. One person replied said it's a very specific it's an opinionated version of cd. That's a great that's a great answer like that. Yeah. >>It's like an implement. Its it's an implementation of deployment if you want it if you want to use it for that. All right. I realize now it's kind of hard in terms of a physical panel and a virtual panel to figure out who on the panel is gonna, you know, ready to jump in to answer a question. But I'll take it. So um I'll um I'll do my best inner victor and say, you know, it's it's an implementation of C. D. And it's it's a choice right? It's one can just still do docker build and darker pushes and doctor pulls and that's fine. Or use other technologies to deploy containers and pods and change your, your kubernetes infrastructure. But get apps is a different implementation, a different method of doing that same thing at the end of the day. Yeah, >>I like it. I like >>it and I think that goes back to your point about, you know, it's kind of early days still, I think to me what I like about getups in that respect is it's nice to see kubernetes become a platform where people are experimenting with different ways of doing things, right? And so I think that encourages like lots of different patterns and overall that's going to be a good thing for the community because then more, you know, and not everything needs to settle in terms of only one way of doing things, but a lot of different ways of doing things helps people fit, you know, the tooling to their needs, or helps fit kubernetes to their needs, etcetera. Yeah, >>um I agree with that, the, so I'm gonna, since we're getting a load of good questions, so um one of the, one of the, one of the, I want to add to that real quick that one of the uh from the, we've people themselves, because I've had some on the show and one of things that I look at it is distinguishing is with continuous deployment tools, I sort of think that it's almost like previous generation and uh continuous deployment tools can be anything like we would consider Jenkins cd, right, if you if you had an association to a server and do a doctor pull and you know, dr up or dr composed up rather, or if it did a cube control apply uh from you know inside an ssh tunnel or something like that was considered considered C. D. Well get ops is much more rigid I think in terms of um you you need to apply, you have a specific repo that's all about your deployments and because of what tool you're using and that one your commit to a specific repo or in a specific branch that repo depends on how you're setting it up. That is what kicks off a workflow. And then secondly there's an understanding of state. So a lot of these tools now I have uh reconciliation where they they look at the cluster and if things are changing they will actually go back and to get and the robots will take over and will commit that. Hey this thing has changed um and you maybe you human didn't change it, something else might have changed it. So I think that's where getups is approaching it, is that ah we we need to we need to consider more than just a couple of commands that be runnin in a script. Like there needs to be more than that for a getups repo to happen anyway, that's just kind of the the take back to take away I took from a previous conversation with some people um >>we've I don't think that lost, its the last piece is really important, right? I think like for me, C d like Ci cd, they're more philosophical ideas, write a set of principles, right? Like getting an idea or a code change to environments promoting it. It's very kind of pipeline driven um and it's very imperative driven, right? Like our existing CD tools are a lot of the ways that people think about Cd, it would be triggered by an event, maybe a code push and then these other things are happening in sequence until they either fail or pass, right? And then we're done. Getups is very much sitting on the, you know, the reconciliation side, it's changing to a pull based model of reconciliation, right? Like it's very declarative, it's just looking at the state and it's automatically pulling changes when they happen, rather than this imperative trigger driven model. That's not to say that there aren't city tools which we're doing pull based or you can do pull based or get ups is doing anything creatively revolutionary here, but I think that's one of the main things that the ideas that are being introduced into those, like existing C kind of tools and pipelines, um certainly the pull based model and the reconciliation model, which, you know, has a lot in common with kubernetes and how those kind of controllers work, but I think that's the key idea. Yeah. >>Um This is a pretty specific one Tory asks, does anyone have opinions about get ops in a mono repo this is like this is getting into religion a little bit. How many repos are too many repose? How um any thoughts on that? Anyone before I rant, >>go >>for it, go for it? >>Yeah. How I'm using it right now in a monitor repo uh So I'm using GIT hub. Right, so you have what? The workflow and then inside a workflow? Yeah, mo file, I'll >>track the >>actual changes to the workflow itself, as well as a folder, which is basically some sort of service in Amman Arepa, so if any of those things changes, it'll trigger the actual pipeline to run. So that's like the simplest thing that I could figure out how to, you know, get it set up using um get hubs, uh workflow path future. Yeah. And it's worked for me for writing, you know? That's Yeah. >>Yeah, the a lot of these things too, like the mono repo discussion will, it's very tool specific. Each tool has various levels of support for branch branching and different repos and subdirectories are are looking at the defense and to see if there's changes in that specific directory. Yeah. Sorry, um john you're going to say something, >>I was just going to say, I've never really done it, but I imagine the same kind of downsides of mono repo to multiple report would exist there. I mean, you've got the blast radius issues, you've got, you know, how big is the mono repo? Do we have to pull does the tool have to pull that or cashier every time it needs to determine def so what is the support for being able to just look at directories versus you know, I think we can get way down into a deeper conversation. Maybe we'll save it for later on in the conversation about what we're doing. Get up, how do we structure our get reposed? We have super granular repo per environment, Perper out reaper, per cluster repo per whatever or do we have directories per environment or branches per environment? How how is everything organized? I think it's you know, it's going to be one of those, there's never one size fits all. I'll give the class of consultant like it depends answer. Right? >>Yeah, for sure. It's very similar to the code struggle because it depends. >>Right? >>Uh Yeah, it's similar to the to the code problem of teams trying to figure out how many repose for their code. Should they micro service, should they? Semi micro service, macro service. Like I mean, you know because too many repose means you're doing a bunch of repo management, a bunch of changes on your local system, you're constantly get pulling all these different things and uh but if you have one big repo then it's it's a it's a huge monolithic thing that you usually have to deal with. Path based issues of tools that only need to look at a specific directory and um yeah, it's a it's a culture, I feel like yeah, like I keep going back to this, it's a culture thing. Does your what is your team prefer? What do you like? What um what's painful for everyone and who's what's the loudest pain that you need to deal with? Is it is it repo management? That's the pain um or is it uh you know, is that that everyone's in one place and it's really hard to keep too many cooks out of the kitchen, which is a mono repo problem, you know? Um How do we handle security? So this is a great one from Tory again. Another great question back to back. And that's the first time we've done that um security as it pertains to get up to anyone who can commit can change the infrastructure. Yes. >>Yes. So the tooling that you have for your GIT repo and the authentication, authorization and permissions that you apply to the GIT repo using a get server like GIT hub or get lab or whatever your flavor of the day is is going to be how security is handled with respect to changes in your get ups configuration repository. So um that is completely specific to your implementation of that or ones implementation of of how they're handling that. Get repositories that the get ups tooling is looking at. To reconcile changes with respect to the permissions of the for lack of better term robot itself. Right? They get up tooling like flux or Argosy. D Um one kid would would create a user or a service account or uh other kind of authentication measures to limit the permissions for that service account that the Gaddafi's tooling needs to be able to read the repose and and send commits etcetera. So that is well within the realm of what you have already for your for your get your get um repo. Yeah. >>Yeah. A related question is from a g what they like about get apps if done nicely for a newbie it's you can get stuff done easily if you what they dislike about it is when you have too many get repose it becomes just too complicated and I agree. Um was making a joke with a team the other week that you know the developer used to just make one commit and they would pass pass it on to a QA team that would then eventually emerging in the master. But they made the commits to these feature branches or whatever. But now they make a commit, they make a pR there for their code then they go make a PR in the helm chart to update the thing to do that and then they go make a PR in the get ups repeal for Argo. And so we talked about that they're probably like four or five P. R. Is just to get their code in the production. But we were talking about the negative of that but the reality was It's just five or 4 or five prs like it wasn't five different systems that had five different methodologies and tooling and that. So I looked at it I was like well yeah that's kind of a pain in the get sense but you're also dealing with one type. It's a repetitive action but it's it's the one thing I don't have to go to five different systems with five different ways of doing it. And once in the web and one's on the client wants a command line that I don't remember. Um Yeah so it's got pros and cons I think when you >>I think when you get to the scale where those kind of issues are a problem then you're probably at the scale where you can afford to invest some time into automation into that. Right? Like what I've when I've seen this in larger customers or larger organizations if there ever at that stage where okay apps are coming up all the time. You know, there's a 10 X 100 X developer to operations folks who may be creating get repose setting up permissions then that stuff gets automated, right? Like, you know, maybe ticket based systems or whatever. Developers say I need a new app. It templates things or more often using the same model, right of reconciliation and operators and the horrific abuse of cogs that we're seeing in the communities community right now. Um You know, developers can create a crd which just says, hey, I'm creating a new app is called app A and then a controller will pick up that app a definition. It will go create a get a repo Programmatically it will add the right definitely will look up and held up the developers and the permissions that need to be able to get to that repo it will create and template automatically some name space and the clusters that it needs in the environments that it needs, depending on, you know, some metadata it might read. So I think, you know, those are definite problems and they're definitely like a teething, growing pain thing. But once you get to that scale, you kind of need to step back and say, well look, we just need to invest in time into the operational aspect of this and automating this pain away, I think. Yeah, >>yeah. And that ultimately ends in Yeah. Custom tooling, which it's hard to avoid it at scale. I mean, there's there's two, there's almost two conversations here, right. There is what I call the Solo admin Solo devops, I bought that domain Solo devops dot com because, you know, whenever I'm talking to dr khan in the real world, it's like I asked people to raise hands, I don't know how we can raise hands here, but I would ask people to raise hands and see how many of you here are. The sole person responsible for deploying the app that your team makes and like a quarter of the room would raise their hand. So I call that solo devops like those, that person can't make all the custom tooling in the world. So they really need dr like solutions where it's opinionated, the workflow is sort of built in and they don't have to wrangle things together with a bunch of glue, you know, in other words bash. Um and so this kind of comes to a conversation uh starting this question from lee he's asking how do you combine get ops with ci cd, especially the continuous bit. How do you avoid having a human uh sort of the complaint the team I was working with has, how do you avoid a human editing and get committing for every single deploy? They've settled on customized templates and a script for routine updates. So as a seed for this conference, this question I'm gonna ask you all uh instead of that specific question cause it's a little open ended. Um Tell me whether you agree with this. I I kind of look at the image, the image artifact because the doctor image or container image in general is an artifact that I I view it that way and that thing going into the registry with the right label or right part of the label. Um That tag rather not the label but the tag that to me is like one of the great demarche points of, we're kind of done with Ci and we're now into the deployment phase and it doesn't necessarily mean the tooling is a clear cut there, but that artifact being shipped in a specific way or promoted as we sometimes say. Um what do you think? Does anyone have opinions on that? I don't even know if that's the right opinion to have so mhm. >>So um I think what you're, what you're getting at is that get ups, models can trigger off of different events um to trigger the reconciliation loop. And one way to do that is if the image, if it notices a image change in the registry, the other is if there's a commit event on a specific rebo and branch and it's up to, you are up to the person that's implementing their get ups model, what event to trigger there, that reconciliation loop off of, You can do both, you can do one or the other. It also depends on the Templeton engine that you're using on top of um on top of kubernetes, such as helm or um you know, the other ones that are out there or if you're not even doing that, then, you know straight. Yeah, mo um so it kind of just depends, but those are the typically the two options one has and a combination of of those to trigger that event. You can also just trigger it manually, right? You can go into the command line and force a a, you know, a really like a scan or a new reconciliation loop to occur. So it kind of just, I don't want to say this, but it depends on what you're trying to do and what makes sense in your pipeline. Right? So if you're if you're set up where you are tag, if you're doing it based off of image tags, then you probably want to use get ups in a way that you're using the image tags. Right. And the pattern that you've established there, if you're not really doing that and you're more around, like, different branches are mapped to different environments, then triggered off of the correct branch. And that's where the permissions also come into play. Where if you don't want someone to touch production and you've got your getups for your production cluster based off of like uh you know, a main branch, then whoever can push a change to that main branch has the authority to push that change to production. Right? So that's your authentication and permissions um system same for the registry itself. Right. So >>Yeah. Yeah. Sorry, anyone else have any thoughts on that? I was about to go to the next topic, >>I was going to say. I think certain tools dictate the approach, like, if you're using Argosy d it's I think I'm correct me if I'm wrong, but I think the only way to use it right now is just through image modification. Like, the manifest changes, it looks at a specific directory and anything changes then it will do its thing. And uh Synchronize the cost there with whatever's and get >>Yeah, flux has both. Yeah, and flux has both. So it it kind of depends. I think you can make our go do that too, but uh this is back to what we were saying in the beginning, uh you know, these things are changing, right? So that might be what it is right now in terms of triggering the reconciliation loops and get ups, tooling, but there might be other events in the future that might trigger it, and it's not completely stand alone because you still need you're tooling to do any kind of testing or whatever you have in terms of like the specific pipeline. So oftentimes you're bolting in getups into some other part of broader Cfd solution. That makes sense. Yeah, >>we've got a lot of questions about secrets or people that are asking about secrets. >>So my my tongue and cheek answered the secrets question was, what's the best practices for kubernetes? Secrets? That's the same thing for secrets with good apps? Uh getups is not last time I checked and last time I was running this stuff get ups is not has nothing to do with secrets in that sense. It's just there to get your stuff running on communities. So, um there's probably a really good session on secrets at dr concept. I >>would agree with you, I agree with you. Yeah, I mean, get off stools, I mean every every project of mine handles secrets differently. Uh huh. And I think I'm not sure if it was even when I was talking to but talking to someone recently that I'm very bullish on get up actions, I love get up actions, it's not great for deployments yet, but we do have this new thing and get hub environments, I think it's called. So it allows me at least the store secrets per environment, which it didn't have the concept of that before, which you know, if you if any of you running kubernetes out there, you typically end up when you start running kubernetes, you end up with more than one kubernetes, like you're going to end up with a lot of clusters at some point, at least many multiple, more than two. Um and so if you're trying to store secret somewhere, you do have and there's a discussion happening in chat right now where people are talking about um sealed secrets which if you haven't heard of that, go look that up and just be versed on what sealed secrets is because it's a it's a fantastic concept for how to store secrets in the public. Um I love it because I'm a big P. K. I nerd but um it's not the only way and it doesn't fit all models. So I have clients that use A W. S. Secrets because they're in A W. S. And then they just have to use the kubernetes external secret. But again like like like normal sand, you know, it's that doesn't really affect get ops, get ops is just applying whatever helm charts or jahmal or images that you're, you're you're deploying, get off. It was more about the approach of when the changes happen and whether it's a push or pull model like we're talking about and you know, >>I would say there's a bunch of prerequisites to get ups secrets being one of them because the risk of you putting a secret into your git repo if you haven't figured out your community secrets architecture and start diving into getups is high and removing secrets from get repose is you know, could be its own industry, right. It's >>a thing, >>how do >>I hide this? How do I obscure this commit that's already now on a dozen machines. >>So there are some prerequisites in terms of when you're ready to adopt get up. So I think is the right way of saying the answer to that secrets being one of them. >>I think the secrets was the thing that made me, you know, like two or three years ago made me kind of see the ah ha moment when it came to get ups which, which was that the premier thing that everyone used to say about get up about why it was great. Was its the single source of truth. There's no state anywhere else. You just need to look at git. Um and then secrets may be realized along with a bunch of other things down the line that is not true and will never be true. So as soon as you can lose the dogmatism about everything is going to be and get it's fantastic. As long as you've understood everything is not going to get. There are things which will absolutely never be and get some tools just don't deal with that. They need to earn their own state, especially in communities, some controls on their own state. You know, cuz sealed secrets and and other projects like SOps and I think there are two or three others. That's a great way of dealing with secrets if you want to keep them in get. But you know, projects like vault more kind of like what I would say, production grade secret strategies. Right? And if you're in AWS or a cloud, you're more likely to be using their secrets. Your secret policy is maybe not dictated by you in large organizations might be dictated by CSO or security or Great. Like I think once if you, if you're trying to adopt getups or you're thinking about it, get the dogmatism of get as a single point of truth out of your mind and think about getups more as a philosophy and a set of best practice principles, then you will be in much better stead, >>right? Yeah. >>People are asking more questions in chat like infrastructure as code plus C d essentially get ups or C I rather, um, these are all great questions and a part of the debate, I'm actually just going to throw up on screen. I'm gonna put this in chat, but this is, this is to me the source, Right? So we worked with when they coined the term. We, a lot of us have been trying to get, if we talk about the history for a minute and then tell me if I'm getting this right. Um, a lot of us were trying to automate all these different parts of the puzzle, but a lot of them, they, some things might have been infrastructure as code. Some things weren't, some things were sort of like settings is coded, like you're going to Jenkins and type in secrets and settings or type in a certain thing in the settings of Jenkins and then that it wasn't really in get and so what we was trying to go for was a way to have almost like eventually a two way state understanding where get might change your infrastructure but then your infrastructure might also change and needs to be reflected in the get if the get is trying to be the single source of truth. Um and like you're saying the reality is that you're never gonna have one repo that has all of your infrastructure in it, like you would have to have, you have to have all your terra form, anything else you're spinning up. Right. Um but anyway, I'm gonna put this link in chat. So this guide actually, uh one of things they talk about is what it's not, so it's, it's kind of great to read through the different requirements and like what I was saying well ago um mhm. Having having ci having infrastructure as code and then trying a little bit of continuous deployment out, it's probably a prerequisite. Forget ops so it's hard to just jump into that when you don't already have infrastructure as code because a machine doing stuff on your behalf, it means that you have to have things documented and somewhere and get repo but let me put this in the in the >>chitty chat, I would like to know if the other panelists agree, but I think get apps is a okay. I would say it's a moderate level, it's not a beginner level communities thing, it's like a moderate level advanced, a little bit more advanced level. Um One can start off using it but you definitely have to have some pre recs in place or some understanding of like a pattern in place. Um So what do the other folks think about that opinion? >>I think if you're if you're trying to use get out before, you know what problem you have, you're probably gonna be in trouble. Right. It's like having a solution to it probably don't have yet. Mhm. Right. I mean if if you're just evil or and you're just typing, keep control apply, you're one person right, Get off. It doesn't seem like a big a big jump, like, I mean it doesn't like why would I do that? I'm just, I'm just gonna inside, it's the type of get commit right, I'm typing Q control apply. But I think one of the rules from we've is none of your developers and none of your admins can have cute control access to the cluster because if you can't, if you do have access and you can just apply something, then that's just infrastructure as code. That's just continuous deployment, that's, that's not really get ops um, getups implies that the only way things get into the cluster is through the get up, get automation that you're using with, you know, flux Argo, we haven't talked about, what's the other one that Victor Farsi talks about, by the way people are asking about victor, because victor would love to talk about this stuff, but he's in my next life, so come back in an hour and a half or whatever and victor is going to be talking about sys, admin list with me. Um >>you gotta ask him nothing but get up questions in the next, >>confuse them, confuse them. But anyway, that, that, that's um, it's hard, it's hard to understand and without having tried it, I think conceptually it's a little challenging >>one thing with getups, especially based off the we've works blog post that you just put up on there. It's an opinionated way of doing something. Uh you know, it's an opinionated way of of delivering changes to an environment to your kubernetes environment. So it's opinionated were often not used to seeing things that are very opinionated in this sense, in the in the ecosystem, but get apps is a opinionated thing. It's it's one way of doing it. Um there are ways to change it and like there are options um like what we were talking about in terms of the events that trigger, but the way that it's structured is an opinion opinionated way both from like a tooling perspective, like using get etcetera, but also from a devops cultural perspective, right? Like you were talking about not having anyone access cube control and changing the cluster directly. That's a philosophical opinion that get ups forces you to adopt otherwise. It kind of breaks the model and um I just I want everyone to just understand that. That is very opinion, anything in that sense. Yeah, >>polygamy is another thing. Infrastructure as code. Um someone's mentioning plummy and chat, I just had actually my life show self plug bread that live go there. I'm on Youtube every week. I did the same thing. These these are my friends um and had palami on two weeks ago uh last week, remember uh and it was in the last couple of weeks and we talked about their infrastructure as code solution. Were actually writing code instead of um oh that's an interesting take on uh developer team sort of owning coding the infrastructure through code rather than Yamil as a data language. I don't really have an opinion on it yet because I haven't used it in production or anything in the real real world, but um, I'm not sure how much they are applying trying to go towards the get up stuff. I will do a plug for Solomon hikes. Who has a, the beginning of the day, it's already happened so you can go back and watch it. It's a, it's a, what's it called? Q. Rethinking application delivery with Q. And build kit. So go look this up. This is the found co founder of Dr and former CTO Solomon hikes at the beginning of the day. He has a tool called dagger. I'm not sure why the title of the talk is delivering with Q. And built it, but the tool is showing off in there for an hour is called dagger. And it's, it's an interesting idea on how to apply a lot of this opinionated automated stuff to uh, to deployment and it's get off space and you use Q language. It's a graph language. I watched most of it and it was a really interesting take. I'm excited to see if that takes off and if they try that because it's another way that you can get a little bit more advanced with your you're get deployments and without having to just stick everything in Yemen, which is kind of what we're in today with helm charts and what not. All right. More questions about secrets, I think. I think we're not going to have a whole lot of more, a lot more about secrets basically. Uh put secrets in your cluster to start with and kubernetes in encrypted, you know, thing. And then, you know, as it gets harder, then you have to find another solution when you have five clusters, you don't wanna have to do it five times. That's when you have to go for Walton A W. S secrets and all >>that. Right? I'm gonna post it note. Yeah. Crm into the cluster. Just kidding. >>Yes, there are recordings of this. Yes, they will be later. Uh, because we're that these are all gonna be on youtube later. Um, yeah, detects secrets cushion saying detect secrets or get Guardian are absolute requirements. I think it's in reference to your secrets comment earlier. Um, Camels asking about Cuban is dropping support for Docker that this is not the place to ask for that, but it, it is uh, basically it's a Nonevent Marantz has actually just created that same plug in available in a different repos. So if you want to keep using Docker and kubernetes, you know, you can do it like it's no big deal. Most of us aren't using doctor in our communities anyway, so we're using like container D or whatever is provided to us by our provider. Um yeah, thank you so much for all these comments. These are great people helping each other and chat. I feel like we're just here to make sure the chats available so people can help each other. >>I feel like I want to pick up on something when you mentioned pollux me, I think there's a um we're talking about getups but I think in the original like the origination of that I guess was deploying applications to clusters right, picking up deployment manifest. But I think with the gloomy and I obviously terra form and things have been around a long time, folks are starting to apply this I think I found one earlier which was like um kub stack the Terror Forms get ups framework. Um but also with the advent of things like cluster A. P. I. Um in the Cuban at the space where you can declare actively build the infrastructure for your clusters and build the cluster right? We're not just talking about deploying applications, the cluster A. P. I will talk to a W. S. Spin up, VPc spin up machines, you know, we'll do the same kind of things that terra form does and and those other tools do I think applying getups principles to the infrastructure spin up right, the proper infrastructure as code stuff, constantly applying Terror form um you know, plans and whatever, constantly applying cluster Api resources spinning up stuff in those clouds. That's a super interesting. Um you know, extension of this area, I'd be curious to see if what the folks think about that. >>Yeah, that's why I picked this topic is one of my three. Uh I got I got to pick the topics. I was like the three things that there like the most bleeding edge exciting. Most people haven't, we haven't basically we haven't figured all this out yet. We as an industry, so um it's I think we're gonna see more ideas on it. Um what's the one with the popsicle as the as the icon victor talks about all the time? It's not it's another getups like tool, but it's um it's getups for you use this kubernetes limit and then we have to look it up, >>You're talking about cross plane. >>So >>my >>wife is over here with the sound effects and the first sound effect of the day that she chooses to use is one. >>All right, can we pick it? Let's let's find another question bret >>I'm searching >>so many of them. All right, so uh I think one really quick one is getups only for kubernetes, I think the main to tooling to tools that we're talking about, our Argosy D and flux and they're mostly geared toward kubernetes deployments but there's a, it seems like they're organized in a way that there's a clean abstraction in with respect to the agent that's doing the deployment and the tooling that that can interact with. So I would imagine that in the future and this might be true already right now that get ups could be applied to other types of deployments at some point in the future. But right now it's mostly focused and treats kubernetes as a first class citizen or the tooling on top of kubernetes, let's say something like how as a first class citizen? Yeah, to Brett, >>to me the field, back to you bret the thing I was looking for is cross plane. So that's another tool. Um Victor has been uh sharing a lot about it in Youtube cross plane and that is basically runs inside a kubernetes, but it handles your other infrastructure besides your app. It allows you to like get ops, you're a W. S stuff by using the kubernetes state engine as a, as a way to manage that. And I have not used it yet, but he does some really great demos on Youtube. So people are liking this idea of get off, so they're trying to figure out how do we, how do we manage state? How do we uh because the probably terra form is that, well, there's many problems, but it's always a lot of problems, but in the get outs world it's not quite the right fit yet, It might be, but you still, it's still largely as expected for people to, you know, like type the command, um, and it keeps state locally the ss, clouds and all that. And but the other thing is I'm I'm now realizing that when I saw the demo from Solomon, I'm going back to the Solomon hikes thing. He was using the demo and he was showing it apply deploying something on S three buckets, employing internet wifi and deploying it on google other things beyond kubernetes and saying that it's all getups approach. So I think we're just at the very beginning of seeing because it all started with kubernetes and now there's a swarm one, you can look up swarm, get office and there's a swarm, I can't take the name of it. Swarm sink I think is what's called swarm sink on git hub, which allows you to do swarm based getups like things. And now we're seeing these other tools coming out. They're saying we're going to try to do the get ups concepts, but not for kubernetes specifically and that's I think, you know, infrastructure as code started with certain areas of the world and then now then now we all just assume that you're going to have an infrastructure as code way of doing whatever that is and I think get off is going to have that same approach where pretty soon, you know, we'll have get apps for all the clouds stuff and it won't just be flexor Argo. And then that's the weird thing is will flex and Argo support all those things or will it just be focused on kubernetes apps? You know, community stuff? >>There's also, I think this is what you're alluding to. There is a trend of using um kubernetes and see rDS to provision and control things that are outside of communities like the cloud service providers services as if they were first class entities within kubernetes so that you can use the kubernetes um focus tooling for things that are not communities through the kubernetes interface communities. Yeah, >>yeah, even criticism. >>Yeah, yeah, I'm just going to say that sounds like cross plane. >>Yeah, yeah, I mean, I think that's that's uh there were, you know, for the last couple of years, it's been flux and are going back and forth. Um they're like frenemies, you know, and they've been going back and forth with iterating on these ideas of how do we manage this complicated thing? That is many kubernetes clusters? Um because like Argo, I don't know if the flux V two can do this, but Argo can manage multiple clusters now from one cluster, so your, you can manage other clusters, technically external things from a single entity. Um Originally flux couldn't do that, but I'm going to say that V two can, I don't actually >>know. Um I think all that is gonna, I think that's going to consolidate in the future. All right. In terms of like the common feature set, what Iver and john what do you think? >>I mean, I think it's already begun, right, I think haven't, didn't they collaborate on a common engine? I don't know whether it's finished yet, but I think they're working towards a common getups engine and then they're just going to layer on features on top. But I think, I mean, I think that's interesting, right, because where it runs and where it interacts with, if we're talking about a pull based model, it shouldn't, it's decentralized to a certain extent, right? We need get and we need the agent which is pulling if we're saying there's something else which is orchestrating something that we start to like fuzzy the model even right. Like is this state living somewhere else, then I think that's just interesting as well. I thought flux was completely decentralized, but I know you install our go somewhere like the cargo has a server as well, but it's been a while since I've looked in depth at them. But I think the, you know, does that muddy the agent only pull model? >>I'm reading a >>Yeah, I would say that there's like a process of natural selection going on as as the C. N. C. F. Landscape evolves and grows bigger and a lot of divide and conquer right now. But I think as certain things kind of get more prominent >>and popular, I think >>it starts to trend and it inspires other things and then it starts to aggregate and you know, kind of get back into like a unified kind of like core. Maybe like for instance, cross plane, I feel like it shouldn't even really exist. It should be, it like it's a communities add on, but it should be built in, it should be built into kubernetes, like why doesn't this exist already >>for like controlling a cloud? >>Yeah, like just, you know, having this interface with the cloud provider and be able to Yeah, >>exactly. Yeah, and it kinda, you're right. That kinda happens because you do, I mean when you start talking about storage providers and networking providers was very specific implementations of operators or just individual controllers that do operate and control other resources in the cloud, but certainly not universally right. Not every feature of AWS is available to kubernetes out of the box. Um and you know, it, one of the challenges across plane is you gotta have kubernetes before you can deploy kubernetes. Like there's a chicken and egg issue there where if you're going to use, if you're going to use our cross plane for your other infrastructure, but it's gotta, but it has to run on kubernetes who creates that first kubernetes in order for you to put that on there. And victor talks about one of his videos, the same problem with flux and Argo where like Argo, you can't deploy Argo itself with getups. There has to be that initial, I did a thing with, I'm a human and I typed in some commands on a server and things happened but they don't really have an easy deployment method for getting our go up and running using simply nothing but a get push to an existing system. There's something like that. So it's a it's an interesting problem of day one infrastructure which is again only day one, I think data is way more interesting and hard, but um how can we spend these things up if they're all depending on each other and who is the first one to get started? >>I mean it's true of everything though, I mean at the end of that you need some kind of big bang kind of function too, you know, I started running start everything I >>think without going over that, sorry, without going off on a tangent. I was, I was gonna say there's a, if folks have heard of kind which is kubernetes and Docker, which is a mini kubernetes cluster, you can run in a Docker container or each container will run as a as a node. Um you know, that's been a really good way to spin up things like clusters. KPI because they boot strap a local kind, install the manifests, it will go and spin up a fully sized cluster, it will transfer its resources over there and then it will die itself. Right? So that, that's kind of bootstrapping itself. And I think a couple of folks in the community, Jason to Tiberius, I think he works for Quinyx metal um has, has experimented with like an even more minimal just Api server, so we're really just leveraging the kubernetes ideas of like a reconciliation loop and a controller. We just need something to bootstrap with those C R D s and get something going and then go away again. So I think that's gonna be a pattern that comes up kind of more and more >>Yeah, for sure. Um, and uh, the next, next quick answer to the question, Angel asked what your thoughts on getups being a niche to get or versus others vcs tools? Well, if I knew anyone who is using anything other than get, I would say no, you know, get ops is a horrible name. It should just be CVS office, but that doesn't or vcs ops or whatever like that, but that doesn't roll off the tongue. So someone had to come up with the get ups phrase. Um but absolutely, it's all about version control solutions used for infrastructure, not code. Um might get doctor asks a great question, we're not gonna have time for it, but maybe people can reply and chat with what they think but about infrastructure and code, the lines being blurred and that do develop, how much of infrastructure does developer do developers need to know? Essentially, they're having to know all the things. Um so unfortunately we've had way more questions like every panel here today with all the great community, we've got way more questions we can handle in this time. So we're gonna have to wrap it up and say goodbye. Go to the next live panel. I believe the next one is um on developer, developer specific setups that's gonna be peter running that panel. Something about development in containers and I'm sure it's gonna be great. Just like this one. So let's go around the room where can people find you on the internet? I'm at Brett fisher on twitter. That's where you can usually find me most days you are? >>Yeah, I'm on twitter to um, I'll put it in the chat. It's kind of confusing because the TSR seven. >>Okay. Yeah, that's right. You can't just say it. You can also look at the blow of the video and like our faces are there and if you click on them, it tells you our twitter in Arlington and stuff, john >>John Harris 85, pretty much everywhere. Get hub Twitter slack, etc. >>Yeah >>and normal, normal faults or just, you know, living on Youtube live with Brett. >>Yeah, we're all on the twitter so go check us out there and thank you so much for joining. Uh thank you so much to you all for being here. I really appreciate you taking time in your busy schedule to join me for a little chit chat. Um Yes, all the, all the cheers, yes. >>And I think this kid apps loop has been declarative lee reconciled. >>Yeah, there we go. And with that ladies and gentlemen, uh bid you would do, we will see you in the next, next round coming up next with Peter >>bye.