>>Hey, welcome to the live panel. My name is Brett. I am your host, and indeed we are live. In fact, if you're curious about that, if you don't believe us, um, let's just show a little bit of the browser real quick to see. Yup. There you go. We're live. So, all right. So how this is going to work is I'm going to bring in some guests and, uh, in one second, and we're going to basically take your questions on the topic designer of the day, that continuous integration testing. Uh, thank you so much to my guests welcoming into the panel. I've got Carlos, Nico and Mandy. Hello everyone. >>Hello? All right, >>Let's go. Let's go around the room and all pretend we don't know each other and that the internet didn't read below the video who we are. Uh, hi, my name is Brett. I am a Docker captain, which means I'm supposed to know something about Docker. I'm coming from Virginia Beach. I'm streaming here from Virginia Beach, Virginia, and, uh, I make videos on the internet and courses on you to me, Carlos. Hey, >>Hey, what's up? I'm Carlos Nunez. I am a solutions architect, VMware. I do solution things with computers. It's fun. I live in Dallas when I'm moving to Houston in a month, which is where I'm currently streaming. I've been all over the Northeast this whole week. So, um, it's been fun and I'm excited to meet with all of you and talk about CIA and Docker. Sure. >>Yeah. Hey everyone. Uh, Nico, Khobar here. I'm a solution engineer at HashiCorp. Uh, I am streaming to you from, uh, the beautiful Austin, Texas. Uh, ignore, ignore the golden gate bridge here. This is from my old apartment in San Francisco. Uh, just, uh, you know, keeping that, to remember all the good days, um, that that lived at. But, uh, anyway, I work at Patrick Corp and I work on all things, automation, um, and cloud and dev ops. Um, and I'm excited to be here and Mandy, >>Hi. Yeah, Mandy Hubbard. I am streaming from Austin, Texas. I am, uh, currently a DX engineer at ship engine. Um, I've worked in QA and that's kind of where I got my, uh, my Docker experience and, um, uh, moving into DX to try and help developers better understand and use our products and be an advocate for them. >>Nice. Well, thank you all for joining me. Uh, I really appreciate you taking the time out of your busy schedule to be here. And so for those of you in chat, the reason we're doing this live, because it's always harder to do things live. The reason we're here is to answer a question. So we didn't come with a bunch of slides and demos or anything like that. We're here to talk amongst ourselves about ideas and really here for you. So we've, we obviously, this is about easy CII, so we're, we're going to try to keep the conversation around testing and continuous integration and all the things that that entails with containers. But we may, we may go down rabbit holes. We may go veer off and start talking about other things, and that's totally fine if it's in the realm of dev ops and containers and developer and ops workflows, like, Hey, it's, it's kinda game. >>And, uh, these people have a wide variety of expertise. They haven't done just testing, right? We, we live in a world where you all kind of have to wear many hats. So feel free to, um, ask what you think is on the top of your mind. And we'll do our best to answer. It may, might not be the best answer or the correct answer, but we're going to do our best. Um, well, let's get it start off. Uh, let's, let's get a couple of topics to start off with. Uh, th the, the easy CGI was my, one of my three ideas. Cause he's the, one of the things that I'm most excited about is the innovation we're seeing around easier testing, faster testing, automated testing, uh, because as much as we've all been doing this stuff for, you know, 15 years, since 20 years since the sort of Jenkins early days, um, it it's, it seems like it's still really hard and it's still a lot of work. >>So, um, let's go around the room real quick, and everybody can just kind of talk for a minute about like your experience with testing and maybe some of your pain points, like what you don't like about our testing world. Um, and we can talk about some pains, cause I think that will lead us to kind of talk about what, what are the things we're seeing now that might be better, uh, ideas about how to do this. I know for me, uh, testing, obviously there's the code part, but just getting it automated, but mostly getting it in the hands of developers so that they can control their own testing. And don't have to go talk to a person to run that test again, or the mysterious Jenkins platform somewhere. I keep mentioning Jenkins cause it's, it is still the dominant player out there. Um, so for me, I'm, I'm, I, I don't like it when I'm walking into a room and there's, there's only one or two people that know how the testing works or know how to make the new tests go into the testing platform and stuff like that. So I'm always trying to free those things so that any of the developers are enabled and empowered to do that stuff. So someone else, Carlos, anybody, um, >>Oh, I have a lot of opinions on that. Having been a QA engineer for most of my career. Um, the shift that we're saying is everyone is dev ops and everyone is QA. Th the issue I see is no one asked developers if they wanted to be QA. Um, and so being the former QA on the team, when there's a problem, even though I'm a developer and we're all running QA, they always tend to come to the one of the former QA engineers. And they're not really owning that responsibility and, um, and digging in. So that's kind of what I'm saying is that we're all expected to test now. And some people, well, some people don't know how it's, uh, for me it was kind of an intuitive skill. It just kind of fit with my personality, but not knowing what to look for, not knowing what to automate, not even understanding how your API end points are used by your front end to know what to test when a change is made. It's really overwhelming for developers. And, um, we're going to need to streamline that and, and hold their hands a little bit until they get their feet wet with also being QA. >>Right. Right. So, um, uh, Carlos, >>Yeah, uh, testing is like, Tesla is one of my favorite subjects to talk about when I'm baring with developers. And a lot of it is because of what Mandy said, right? Like a lot of developers now who used to write a test and say, Hey, QA, go. Um, I wrote my unit tests. Now write the rest of the test. Essentially. Now developers are expected to be able to understand how testing, uh, testing methodologies work, um, in their local environments, right? Like they're supposed to understand how to write an integration tasks federate into and tasks, a component test. And of course, how to write unit tests that aren't just, you know, assert true is true, right? Like more comprehensive, more comprehensive, um, more high touch unit tests, which include things like mocking and stubbing and spine and all that stuff. And, you know, it's not so much getting those tests. Well, I've had a lot of challenges with developers getting those tests to run in Docker because of usually because of dependency hell, but, um, getting developers to understand how to write tests that matter and mean something. Um, it's, it's, it can be difficult, but it's also where I find a lot of the enjoyment of my work comes into play. So yeah. I mean, that's the difficulty I've seen around testing. Um, big subject though. Lots to talk about there. >>Yeah. We've got, we've already got so many questions coming in. You already got an hour's worth of stuff. So, uh, Nico 81st thoughts on that? >>Yeah, I think I definitely agree with, with other folks here on the panel, I think from a, um, the shift from a skillset perspective that's needed to adopt the new technologies, but I think from even from, uh, aside from the organizational, um, and kind of key responsibilities that, that the new developers have to kinda adapt to and, and kind of inherit now, um, there's also from a technical perspective as there's, you know, um, more developers are owning the full stack, including the infrastructure piece. So that adds a lot more to the plate in Tim's oaf, also testing that component that they were not even, uh, responsible for before. Um, and, um, also the second challenge that, you know, I'm seeing is that on, you know, the long list of added, um, uh, tooling and, you know, there's new tool every other day. Um, and, um, that kind of requires more customization to the testing, uh, that each individual team, um, any individual developer Y by extension has to learn. Uh, so the customization, uh, as well as the, kind of the scope that had, uh, you know, now in conferences, the infrastructure piece, um, uh, both of act to the, to the challenges that we're seeing right now for, um, for CGI and overall testing, um, uh, the developers are saying, uh, in, in the market today. >>Yeah. We've got a lot of questions, um, about all the, all the different parts of this. So, uh, let me just go straight to them. Cause that's why we're here is for the people, uh, a lot of people asking about your favorite tools and in one of this is one of the challenges with integration, right? Is, um, there is no, there are dominant players, but there, there is such a variety. I mean, every one of my customers seems like they're using a different workflow and a different set of tools. So, and Hey, we're all here to just talk about what we're, what we're using, uh, you know, whether your favorite tools. So like a lot of the repeated questions are, what are your favorite tools? Like if you could create it from scratch, uh, what would you use? Pierre's asking, you know, GitHub actions sounds like they're a fan of GitHub actions, uh, w you know, mentioning, pushing the ECR and Docker hub and, uh, using vs code pipeline, I guess there may be talking about Azure pipelines. Um, what, what's your preferred way? So, does anyone have any, uh, thoughts on that anyone want to throw out there? Their preferred pipeline of tooling? >>Well, I have to throw out mine. I might as Jenkins, um, like kind of a honorary cloud be at this point, having spoken a couple of times there, um, all of the plugins just make the functionality. I don't love the UI, but I love that it's been around so long. It has so much community support, and there are so many plugins so that if you want to do something, you don't have to write the code it's already been tested. Um, unfortunately I haven't been able to use Jenkins in, uh, since I joined ship engine, we, most of our, um, our, our monolithic core application is, is team city. It's a dotnet application and TeamCity plays really well with.net. Um, didn't love it, uh, Ms. Jenkins. And I'm just, we're just starting some new initiatives that are using GitHub actions, and I'm really excited to learn, to learn those. I think they have a lot of the same functionality that you're looking for, but, um, much more simplified in is right there and get hubs. So, um, the integration is a lot more seamless, but I do have to go on record that my favorite CICT tools Jenkins. >>All right. You heard it here first people. All right. Anyone else? You're muted? I'm muted. Carlin says muted. Oh, Carla says, guest has muted themselves to Carlos. You got to unmute. >>Yes. I did mute myself because I was typing a lot, trying to, you know, try to answer stuff in the chat. And there's a lot of really dark stuff in there. That's okay. Two more times today. So yeah, it's fine. Yeah, no problem. So totally. And it's the best way to start a play more. So I'm just going to go ahead and light it up. Um, for enterprise environments, I actually am a huge fan of Jenkins. Um, it's a tool that people really understand. Um, it has stood the test of time, right? I mean, people were using Hudson, but 15 years ago, maybe longer. And, you know, the way it works, hasn't really changed very much. I mean, Jenkins X is a little different, but, um, the UI and the way it works internally is pretty familiar to a lot of enterprise environments, which is great. >>And also in me, the plugin ecosystem is amazing. There's so many plugins for everything, and you can make your own if you know, Java groovy. I'm sure there's a perfect Kotlin in there, but I haven't tried myself, but it's really great. It's also really easy to write, um, CIS code, which is something I'm a big fan of. So Jenkins files have been, have worked really well for me. I, I know that I can get a little bit more complex as you start to build your own models and such, but, you know, for enterprise enterprise CIO CD, if you want, especially if you want to roll your own or own it yourself, um, Jenkins is the bellwether and for very good reason now for my personal projects. And I see a lot on the chat here, I think y'all, y'all been agreed with me get hub actions 100%, my favorite tool right now. >>Um, I love GitHub actions. It's, it's customizable, it's modular. There's a lot of plugins already. I started using getting that back maybe a week after when GA and there was no documentation or anything. And I still, it was still my favorite CIA tool even then. Um, and you know, the API is really great. There's a lot to love about GitHub actions and, um, and I, and I use it as much as I can from my personal project. So I still have a soft spot for Travis CAI. Um, you know, they got acquired and they're a little different now trying to see, I, I can't, I can't let it go. I just love it. But, um, yeah, I mean, when it comes to Seattle, those are my tools. So light me up in the comments I will respond. Yeah. >>I mean, I, I feel with you on the Travis, the, I think, cause I think that was my first time experiencing, you know, early days get hub open source and like a free CIA tool that I could describe. I think it was the ammo back then. I don't actually remember, but yeah, it was kind of an exciting time from my experience. There was like, oh, this is, this is just there as a service. And I could just use it. It doesn't, it's like get hub it's free from my open source stuff. And so it does have a soft spot in my heart too. So yeah. >>All right. We've got questions around, um, cam, so I'm going to ask some questions. We don't have to have these answers because sometimes they're going to be specific, but I want to call them out because people in chat may have missed that question. And there's probably, you know, that we have smart people in chat too. So there's probably someone that knows the answer to these things. If, if it's not us, um, they're asking about building Docker images in Kubernetes, which to me is always a sore spot because it's Kubernetes does not build images by default. It's not meant for that out of the gate. And, uh, what is the best way to do this without having to use privileged containers, which privileged containers just implying that yeah, you, you, it probably has more privileges than by default as a container in Kubernetes. And that is a hard thing because, uh, I don't, I think Docker doesn't lie to do that out of the gate. So I don't know if anyone has an immediate answer to that. That's a pretty technical one, but if you, if you know the answer to that in chat, call it out. >>Um, >>I had done this, uh, but I'm pretty sure I had to use a privileged, um, container and install the Docker Damon on the Kubernetes cluster. And I CA I can't give you a better solution. Um, I've done the same. So, >>Yeah, uh, Chavonne asks, um, back to the Jenkins thing, what's the easiest way to integrate Docker into a Jenkins CICB pipeline. And that's one of the challenges I find with Jenkins because I don't claim to be the expert on Jenkins. Is there are so many plugins because of this, of this such a huge ecosystem. Um, when you go searching for Docker, there's a lot that comes back, right. So I, I don't actually have a preferred way because every team I find uses it differently. Um, I don't know, is there a, do you know if there's a Jenkins preferred, a default plugin? I don't even know for Docker. Oh, go ahead. Yeah. Sorry for Docker. And jacon sorry, Docker plugins for Jenkins. Uh, as someone's asking like the preferred or easy way to do that. Um, and I don't, I don't know the back into Jenkins that well, so, >>Well, th the new, the new way that they're doing, uh, Docker builds with the pipeline, which is more declarative versus the groovy. It's really simple, and their documentation is really good. They, um, they make it really easy to say, run this in this image. So you can pull down, you know, public images and add your own layers. Um, so I don't know the name of that plugin, uh, but I can certainly take a minute after this session and going and get that. Um, but if you really are overwhelmed by the plugins, you can just write your, you know, your shell command in Jenkins. You could just by, you know, doing everything in bash, calling the Docker, um, Damon directly, and then getting it working just to see that end to end, and then start browsing for plugins to see if you even want to use those. >>The plugins will allow more integration from end to end. Some of the things that you input might be available later on in the process for having to manage that yourself. But, you know, you don't have to use any of the plugins. You can literally just, you know, do a block where you write your shell command and get it working, and then decide if, for plugins for you. Um, I think it's always under important to understand what is going on under the hood before you, before you adopt the magic of a plugin, because, um, once you have a problem, if you're, if it's all a lockbox to you, it's going to be more difficult to troubleshoot. It's kind of like learning, get command line versus like get cracking or something. Once, once you get in a bind, if you don't understand the underlying steps, it's really hard to get yourself out of a bind, versus if you understand what the plugin or the app is doing, then, um, you can get out of situations a lot easier. That's a good place. That's, that's where I'd start. >>Yeah. Thank you. Um, Camden asks better to build test environment images, every commit in CII. So this is like one of those opinions of we're all gonna have some different, uh, or build on build images on every commit, leveraging the cash, or build them once outside the test pile pipeline. Um, what say you people? >>Uh, well, I I've seen both and generally speaking, my preference is, um, I guess the ant, the it's a consultant answer, right? I think it depends on what you're trying to do, right. So if you have a lot of small changes that are being made and you're creating images for each of those commits, you're going to have a lot of images in your, in your registry, right? And on top of that, if you're building those images, uh, through CAI frequently, if you're using Docker hub or something like that, you might run into rate limiting issues because of Docker's new rate, limiting, uh, rate limits that they put in place. Um, but that might be beneficial if the, if being able to roll back between those small changes while you're testing is important to you. Uh, however, if all you care about is being able to use Docker images, um, or being able to correlate versions to your Docker images, or if you're the type of team that doesn't even use him, uh, does he even use, uh, virgins in your image tags? Then I would think that that might be a little, much you might want to just have in your CIO. You might want to have a stage that builds your Docker images and Docker image and pushes it into your registry, being done first particular branches instead of having to be done on every commit regardless of branch. But again, it really depends on the team. It really depends on what you're building. It really depends on your workflow. It can depend on a number of things like a curse sometimes too. Yeah. Yeah. >>Once had two points here, you know, I've seen, you know, the pattern has been at every, with every, uh, uh, commit, assuming that you have the right set of tests that would kind of, uh, you would benefit from actually seeing, um, the, the, the, the testing workflow go through and can detect any issue within, within the build or whatever you're trying to test against. But if you're just a building without the appropriate set of tests, then you're just basically consuming almond, adding time, as well as all the, the image, uh, stories associated with it without treaty reaping the benefit of, of, of this pattern. Uh, and the second point is, again, I think if you're, if you're going to end up doing a per commit, uh, definitely recommend having some type of, uh, uh, image purging, um, uh, and, and, and garbage collection process to ensure that you're not just wasting, um, all the stories needed and also, um, uh, optimizing your, your bill process, because that will end up being the most time-consuming, um, um, you know, within, within your pipeline. So this is my 2 cents on this. >>Yeah, that's good stuff. I mean, those are both of those are conversations that could lead us into the rabbit hole for the rest of the day on storage management, uh, you know, CP CPU minutes for, uh, you know, your build stuff. I mean, if you're in any size team, more than one or two people, you immediately run into headaches with cost of CIA, because we have now the problem of tools, right? We have so many tools. We can have the CIS system burning CPU cycles all day, every day, if we really wanted to. And so you re very quickly, I think, especially if you're on every commit on every branch, like that gets you into a world of cost mitigation, and you probably are going to have to settle somewhere in the middle on, uh, between the budget, people that are saying you're spending way too much money on the CII platform, uh, because of all these CPU cycles, and then the developers who would love to have everything now, you know, as fast as possible and the biggest, biggest CPU's, and the biggest servers, and have the bills, because the bills can never go fast enough, right. >>There's no end to optimizing your build workflow. Um, we have another question on that. This is another topic that we'll all probably have different takes on is, uh, basically, uh, version tags, right? So on images, we, we have a very established workflow in get for how we make commits. We have commit shots. We have, uh, you know, we know get tags and there's all these things there. And then we go into images and it's just this whole new world that's opened up. Like there's no real consensus. Um, so what, what are your thoughts on the strategy for teams in their image tag? Again, another, another culture thing. Um, commander, >>I mean, I'm a fan of silver when we have no other option. Um, it's just clean and I like the timestamp, you know, exactly when it was built. Um, I don't really see any reason to use another, uh, there's just normal, incremental, um, you know, numbering, but I love the fact that you can pull any tag and know exactly when it was created. So I'm a big fan of bar, if you can make that work for your organization. >>Yep. People are mentioned that in chat, >>So I like as well. Uh, I'm a big fan of it. I think it's easy to be able to just be as easy to be able to signify what a major changes versus a minor change versus just a hot fix or, you know, some or some kind of a bad fix. The problem that I've found with having teams adopt San Bernardo becomes answering these questions and being able to really define what is a major change, what is a minor change? What is a patch, right? And this becomes a bit of an overhead or not so much of an overhead, but, uh, uh, uh, a large concern for teams who have never done versioning before, or they never been responsible for their own versioning. Um, in fact, you know, I'm running into that right now, uh, with, with a client that I'm working with, where a lot, I'm working with a lot of teams, helping them move their applications from a legacy production environment into a new one. >>And in doing so, uh, versioning comes up because Docker images, uh, have tags and usually the tax correlate to versions, but some teams over there, some teams that I'm working with are only maintaining a script and others are maintaining a fully fledged JAK, three tier application, you know, with lots of dependencies. So telling the script, telling the team that maintains a script, Hey, you know, you should use somber and you should start thinking about, you know, what's major, what's my number what's patch. That might be a lot for them. And for someone or a team like that, I might just suggest using commit shots as your versions until you figure that out, or maybe using, um, dates as your version, but for the more for the team, with the larger application, they probably already know the answers to those questions. In which case they're either already using Sember or they, um, or they may be using some other version of the strategy and might be in December, might suit them better. So, um, you're going to hear me say, it depends a lot, and I'm just going to say here, it depends. Cause it really does. Carlos. >>I think you hit on something interesting beyond just how to version, but, um, when to consider it a major release and who makes those decisions, and if you leave it to engineers to version, you're kind of pushing business decisions down the pipe. Um, I think when it's a minor or a major should be a business decision and someone else needs to make that call someone closer to the business should be making that call as to when we want to call it major. >>That's a really good point. And I add some, I actually agree. Um, I absolutely agree with that. And again, it really depends on the team that on the team and the scope of it, it depends on the scope that they're maintaining, right? And so it's a business application. Of course, you're going to have a product manager and you're going to have, you're going to have a product manager who's going to want to make that call because that version is going to be out in marketing. People are going to use it. They're going to refer to and support calls. They're going to need to make those decisions. Sember again, works really, really well for that. Um, but for a team that's maintaining the scripts, you know, I don't know, having them say, okay, you must tell me what a major version is. It's >>A lot, but >>If they want it to use some birds great too, which is why I think going back to what you originally said, Sember in the absence of other options. I think that's a good strategy. >>Yeah. There's a, there's a, um, catching up on chat. I'm not sure if I'm ever going to catch up, but there's a lot of people commenting on their favorite CII systems and it's, and it, it just goes to show for the, the testing and deployment community. Like how many tools there are out there, how many tools there are to support the tools that you're using. Like, uh, it can be a crazy wilderness. And I think that's, that's part of the art of it, uh, is that these things are allowing us to build our workflows to the team's culture. Um, and, uh, but I do think that, you know, getting into like maybe what we hope to be at what's next is I do hope that we get to, to try to figure out some of these harder problems of consistency. Uh, one of the things that led me to Docker at the beginning to begin with was the fact that it wa it created a consistent packaging solution for me to get my code, you know, off of, off of my site of my local system, really, and into the server. >>And that whole workflow would at least the thing that I was making at each step was going to be the same thing used. Right. And that, that was huge. Uh, it was also, it also took us a long time to get there. Right. We all had to, like Docker was one of those ones that decade kind of ideas of let's solidify the, enter, get the consensus of the community around this idea. And we, and it's not perfect. Uh, you know, the Docker Docker file is not the most perfect way to describe how to make your app, but it is there and we're all using it. And now I'm looking for that next piece, right. Then hopefully the next step in that, um, that where we can all arrive at a consensus so that once you hop teams, you know, okay. We all knew Docker. We now, now we're all starting to get to know the manifests, but then there's this big gap in the middle where it's like, it might be one of a dozen things. Um, you know, so >>Yeah, yeah. To that, to that, Brett, um, you know, uh, just maybe more of a shameless plug here and wanting to kind of talk about one of the things that I'm on. So excited, but I work, I work at Tasha Corp. I don't know anyone, or I don't know if many people have heard of, um, you know, we tend to focus a lot on workflows versus technologies, right. Because, you know, as you can see, even just looking at the chat, there's, you know, ton of opinions on the different tooling, right. And, uh, imagine having, you know, I'm working with clients that have 10,000 developers. So imagine taking the folks in the chat and being partnered with one organization or one company and having to make decisions on how to build software. Um, but there's no way you can conversion one or, or one way or one tool, uh, and that's where we're facing in the industry. >>So one of the things that, uh, I'm pretty excited about, and I don't know if it's getting as much traction as you know, we've been focused on it. This is way point, which is a project, an open source project. I believe we got at least, uh, last year, um, which is, it's more of, uh, it's, it is aim to address that really, uh, uh, Brad set on, you know, to come to tool to, uh, make it extremely easy and simple. And, you know, to describe how you want to build, uh, deploy or release your application, uh, in, in a consistent way, regardless of the tools. So similar to how you can think of Terraform and having that pluggability to say Terraform apply or plan against any cloud infrastructure, uh, without really having to know exactly the details of how to do it, uh, this is what wave one is doing. Um, and it can be applied with, you know, for the CIA, uh, framework. So, you know, task plugability into, uh, you know, circle CEI tests to Docker helm, uh, Kubernetes. So that's the, you know, it's, it's a hard problem to solve, but, um, I'm hopeful that that's the path that we're, you know, we'll, we'll eventually get to. So, um, hope, you know, you can, you can, uh, see some of the, you know, information, data on it, on, on HashiCorp site, but I mean, I'm personally excited about it. >>Yeah. Uh I'm to gonna have to check that out. And, um, I told you on my live show, man, we'll talk about it, but talk about it for a whole hour. Uh, so there's another question here around, uh, this, this is actually a little bit more detailed, but it is one that I think a lot of people deal with and I deal with a lot too, is essentially the question is from Cameron, uh, D essentially, do you use compose in your CIO or not Docker compose? Uh, because yes I do. Yeah. Cause it, it, it, it solves so many problems am and not every CGI can, I don't know, there's some problems with a CIO is trying to do it for me. So there are pros and cons and I feel like I'm still on the fence about it because I use it all the time, but also it's not perfect. It's not always meant for CIA. And CIA sometimes tries to do things for you, like starting things up before you start other parts and having that whole order, uh, ordering problem of things anyway. W thoughts and when have thoughts. >>Yes. I love compose. It's one of my favorite tools of all time. Um, and the reason why it's, because what I often find I'm working with teams trying to actually let me walk that back, because Jack on the chat asked a really interesting question about what, what, what the hardest thing about CIS for a lot of teams. And in my experience, the hardest thing is getting teams to build an app that is the same app as what's built in production. A lot of CGI does things that are totally different than what you would do in your local, in your local dev. And as a result of that, you get, you got this application that either doesn't work locally, or it does work, but it's a completely different animal than what you would get in production. Right? So what I've found in trying to get teams to bridge that gap by basically taking their CGI, shifting the CII left, I hate the shift left turn, but I'll use it. >>I'm shifting the CIO left to your local development is trying to say, okay, how do we build an app? How do we, how do we build mot dependencies of that app so that we can build so that we can test our app? How do we run tests, right? How do we build, how do we get test data? And what I found is that trying to get teams to do all this in Docker, which is normally a first for a lot of teams that I'm working with, trying to get them all to do all of this. And Docker means you're running Docker, build a lot running Docker, run a lot. You're running Docker, RM a lot. You ran a lot of Docker, disparate Docker commands. And then on top of that, trying to bridge all of those containers together into a single network can be challenging without compose. >>So I like using a, to be able to really easily categorize and compartmentalize a lot of the things that are going to be done in CII, like building a Docker image, running tests, which is you're, you're going to do it in CII anyway. So running tests, building the image, pushing it to the registry. Well, I wouldn't say pushing it to the registry, but doing all the things that you would do in local dev, but in the same network that you might have a mock database or a mock S3 instance or some of something else. Um, so it's just easy to take all those Docker compose commands and move them into your Yammel file using the hub actions or your dankest Bob using Jenkins, or what have you. Right. It's really, it's really portable that way, but it doesn't work for every team. You know, for example, if you're just a team that, you know, going back to my script example, if it's a really simple script that does one thing on a somewhat routine basis, then that might be a lot of overhead. Um, in that case, you know, you can get away with just Docker commands. It's not a big deal, but the way I looked at it is if I'm, if I'm building, if I build something that's similar to a make bile or rate file, or what have you, then I'm probably gonna want to use Docker compose. If I'm working with Docker, that's, that's a philosophy of values, right? >>So I'm also a fan of Docker compose. And, um, you know, to your point, Carlos, the whole, I mean, I'm also a fan of shifting CEI lift and testing lift, but if you put all that logic in your CTI, um, it changes the L the local development experience from the CGI experience. Versus if you put everything in a compose file so that what you build locally is the same as what you build in CGI. Um, you're going to have a better experience because you're going to be testing something more, that's closer to what you're going to be releasing. And it's also very easy to look at a compose file and kind of, um, understand what the dependencies are and what's happening is very readable. And once you move that stuff to CGI, I think a lot of developers, you know, they're going to be intimidated by the CGI, um, whatever the scripting language is, it's going to be something they're going to have to wrap their head around. >>Um, but they're not gonna be able to use it locally. You're going to have to have another local solution. So I love the idea of a composed file use locally, um, especially if he can Mount the local workspace so that they can do real time development and see their changes in the exact same way as it's going to be built and tested in CGI. It gives developers a high level of confidence. And then, you know, you're less likely to have issues because of discrepancies between how it was built in your local test environment versus how it's built in NCI. And so Docker compose really lets you do all of that in a way that makes your solution more portable, portable between local dev and CGI and reduces the number of CGI cycles to get, you know, the test, the test data that you need. So that's why I like it for really, for local dev. >>It'll be interesting. Um, I don't know if you all were able to see the keynote, but there was a, there was a little bit, not a whole lot, but a little bit talk of the Docker, compose V two, which has now built into the Docker command line. And so now we're shifting from the Python built compose, which was a separate package. You could that one of the challenges was getting it into your CA solution because if you don't have PIP and you got down on the binary and the binary wasn't available for every platform and, uh, it was a PI installer. It gets a little nerdy into how that works, but, uh, and the team is now getting, be able to get unified with it. Now that it's in Golang and it's, and it's plugged right into the Docker command line, it hopefully will be easier to distribute, easier to, to use. >>And you won't have to necessarily have dependencies inside of where you're running it because there'll be a statically compiled binary. Um, so I've been playing with that, uh, this year. And so like training myself to do Docker going from Docker dash compose to Docker space, compose. It is a thing I I'm almost to the point of having to write a shell replacement. Yeah. Alias that thing. Um, but, um, I'm excited to see what that's going, cause there's already new features in it. And it, these built kit by default, like there's all these things. And I, I love build kit. We could make a whole session on build kit. Um, in fact there's actually, um, maybe going on right now, or right around this time, there is a session on, uh, from Solomon hikes, the seat, uh, co-founder of Docker, former CTO, uh, on build kit using, uh, using some other tool on top of build kit or whatever. >>So that, that would be interesting for those of you that are not watching that one. Cause you're here, uh, to do a check that one out later. Um, all right. So another good question was caching. So another one, another area where there is no wrong answers probably, and everyone has a different story. So the question is, what are your thoughts on CII build caching? There's often a debate between security. This is from Quentin. Thank you for this great question. There's often a debate between security reproducibility and build speeds. I haven't found a good answer so far. I will just throw my hat in the ring and say that the more times you want to build, like if you're trying to build every commit or every commit, if you're building many times a day, the more caching you need. So like the more times you're building, the more caching you're gonna likely want. And in most cases caching doesn't bite you in the butt, but that could be, yeah, we, can we get the bit about that? So, yeah. Yeah. >>I'm going to quote Carlos again and say, it depends on, on, you know, how you're talking, you know, what you're trying to build and I'm quoting your colors. Um, yeah, it's, it's got, it's gonna depend because, you know, there are some instances where you definitely want to use, you know, depends on the frequency that you're building and how you're building. Um, it's you would want to actually take advantage of cashing functionalities, um, for the build, uh, itself. Um, but if, um, you know, as you mentioned, there could be some instances where you would want to disable, um, any caching because you actually want to either pull a new packages or, um, you know, there could be some security, um, uh, disadvantages related to security aspects that would, you know, you know, using a cache version of, uh, image layer, for example, could be a problem. And you, you know, if you have a fleet of build, uh, engines, you don't have a good grasp of where they're being cashed. We would have to, um, disable caching in that, in that, um, in those instances. So it, it would depend. >>Yeah, it's, it's funny you have that problem on both sides of cashing. Like there are things that, especially in Docker world, they will cash automatically. And, and then, and then you maybe don't realize that some of that caching could be bad. It's, it's actually using old, uh, old assets, old artifacts, and then there's times where you would expect it to cash, that it doesn't cash. And then you have to do something extra to enable that caching, especially when you're dealing with that cluster of, of CIS servers. Right. And the cloud, the whole clustering problem with caching is even more complex, but yeah, >>But that's, that's when, >>Uh, you know, ever since I asked you to start using build kits and able to build kit, you know, between it's it's it's reader of Boston in, in detecting word, you know, where in, in the bill process needs to cash, as well as, uh, the, the, um, you know, the process. I don't think I've seen any other, uh, approach there that comes close to how efficient, uh, that process can become how much time it can actually save. Uh, but again, I think, I think that's, for me that had been my default approach, unless I actually need something that I would intentionally to disable caching for that purpose, but the benefits, at least for me, the benefits of, um, how bill kit actually been processing my bills, um, from the builds as well as, you know, using the cash up until, you know, how it detects the, the difference in, in, in the assets within the Docker file had been, um, you know, uh, pretty, you know, outweigh the disadvantages that it brings in. So it, you know, take it each case by case. And based on that, determine if you want to use it, but definitely recommend those enabling >>In the absence of a reason not to, um, I definitely think that it's a good approach in terms of speed. Um, yeah, I say you cash until you have a good reason not to personally >>Catch by default. There you go. I think you catch by default. Yeah. Yeah. And, uh, the trick is, well, one, it's not always enabled by default, especially when you're talking about cross server. So that's a, that's a complexity for your SIS admins, or if you're on the cloud, you know, it's usually just an option. Um, I think it also is this, this veers into a little bit of, uh, the more you cash the in a lot of cases with Docker, like the, from like, if you're from images and checked every single time, if you're not pinning every single thing, if you're not painting your app version, you're at your MPN versions to the exact lock file definition. Like there's a lot of these things where I'm I get, I get sort of, I get very grouchy with teams that sort of let it, just let it all be like, yeah, we'll just build two images and they're totally going to have different dependencies because someone happened to update that thing and after whatever or MPM or, or, and so I get grouchy about that, cause I want to lock it all down, but I also know that that's going to create administrative burden. >>Like the team is now going to have to manage versions in a very much more granular way. Like, do we need to version two? Do we need to care about curl? You know, all that stuff. Um, so that's, that's kind of tricky, but when you get to, when you get to certain version problems, uh, sorry, uh, cashing problems, you, you, you don't want those set those caches to happen because it, if you're from image changes and you're not constantly checking for a new image, and if you're not pinning that V that version, then now you, you don't know whether you're getting the latest version of Davion or whatever. Um, so I think that there's, there's an art form to the more you pen, the less you have, the less, you have to be worried about things changing, but the more you pen, the, uh, all your versions of everything all the way down the stack, the more administrative stuff, because you're gonna have to manually change every one of those. >>So I think it's a balancing act for teams. And as you mature, I to find teams, they tend to pin more until they get to a point of being more comfortable with their testing. So the other side of this argument is if you trust your testing, then you, and you have better testing to me, the less likely to the subtle little differences in versions have to be penned because you can get away with those minor or patch level version changes. If you're thoroughly testing your app, because you're trusting your testing. And this gets us into a whole nother rant, but, uh, yeah, but talking >>About penny versions, if you've got a lot of dependencies isn't that when you would want to use the cash the most and not have to rebuild all those layers. Yeah. >>But if you're not, but if you're not painting to the exact patch version and you are caching, then you're not technically getting the latest versions because it's not checking for all the time. It's a weird, there's a lot of this subtle nuance that people don't realize until it's a problem. And that's part of the, the tricky part of allow this stuff, is it, sometimes the Docker can be almost so much magic out of the box that you, you, you get this all and it all works. And then day two happens and you built it a second time and you've got a new version of open SSL in there and suddenly it doesn't work. Um, so anyway, uh, that was a great question. I've done the question on this, on, uh, from heavy. What do you put, where do you put testing in your pipeline? Like, so testing the code cause there's lots of types of testing, uh, because this pipeline gets longer and longer and Docker building images as part of it. And so he says, um, before staging or after staging, but before production, where do you put it? >>Oh man. Okay. So, um, my, my main thought on this is, and of course this is kind of religious flame bait, so sure. You know, people are going to go into the compensation wrong. Carlos, the boy is how I like to think about it. So pretty much in every stage or every environment that you're going to be deploying your app into, or that your application is going to touch. My idea is that there should be a build of a Docker image that has all your applications coded in, along with its dependencies, there's testing that tests your application, and then there's a deployment that happens into whatever infrastructure there is. Right. So the testing, they can get tricky though. And the type of testing you do, I think depends on the environment that you're in. So if you're, let's say for example, your team and you have, you have a main branch and then you have feature branches that merged into the main branch. >>You don't have like a pre-production branch or anything like that. So in those feature branches, whenever I'm doing CGI that way, I know when I freak, when I cut my poll request, that I'm going to merge into main and everything's going to work in my feature branches, I'm going to want to probably just run unit tests and maybe some component tests, which really, which are just, you know, testing that your app can talk to another component or another part, another dependency, like maybe a database doing tests like that, that don't take a lot of time that are fascinating and right. A lot of would be done at the beach branch level and in my opinion, but when you're going to merge that beach branch into main, as part of a release in that activity, you're going to want to be able to do an integration tasks, to make sure that your app can actually talk to all the other dependencies that it talked to. >>You're going to want to do an end to end test or a smoke test, just to make sure that, you know, someone that actually touches the application, if it's like a website can actually use the website as intended and it meets the business cases and all that, and you might even have testing like performance testing, low performance load testing, or security testing, compliance testing that would want to happen in my opinion, when you're about to go into production with a release, because those are gonna take a long time. Those are very expensive. You're going to have to cut new infrastructure, run those tests, and it can become quite arduous. And you're not going to want to run those all the time. You'll have the resources, uh, builds will be slower. Uh, release will be slower. It will just become a mess. So I would want to save those for when I'm about to go into production. Instead of doing those every time I make a commit or every time I'm merging a feature ranch into a non main branch, that's the way I look at it, but everything does a different, um, there's other philosophies around it. Yeah. >>Well, I don't disagree with your build test deploy. I think if you're going to deploy the code, it needs to be tested. Um, at some level, I mean less the same. You've got, I hate the term smoke tests, cause it gives a false sense of security, but you have some mental minimum minimal amount of tests. And I would expect the developer on the feature branch to add new tests that tested that feature. And that would be part of the PR why those tests would need to pass before you can merge it, merge it to master. So I agree that there are tests that you, you want to run at different stages, but the earlier you can run the test before going to production. Um, the fewer issues you have, the easier it is to troubleshoot it. And I kind of agree with what you said, Carlos, about the longer running tests like performance tests and things like that, waiting to the end. >>The only problem is when you wait until the end to run those performance tests, you kind of end up deploying with whatever performance you have. It's, it's almost just an information gathering. So if you don't run your performance test early on, um, and I don't want to go down a rabbit hole, but performance tests can be really useless if you don't have a goal where it's just information gap, uh, this is, this is the performance. Well, what did you expect it to be? Is it good? Is it bad? They can get really nebulous. So if performance is really important, um, you you're gonna need to come up with some expectations, preferably, you know, set up the business level, like what our SLA is, what our response times and have something to shoot for. And then before you're getting to production. If you have targets, you can test before staging and you can tweak the code before staging and move that performance initiative. Sorry, Carlos, a little to the left. Um, but if you don't have a performance targets, then it's just a check box. So those are my thoughts. I like to test before every deployment. Right? >>Yeah. And you know what, I'm glad that you, I'm glad that you brought, I'm glad that you brought up Escalades and performance because, and you know, the definition of performance says to me, because one of the things that I've seen when I work with teams is that oftentimes another team runs a P and L tests and they ended, and the development team doesn't really have too much insight into what's going on there. And usually when I go to the performance team and say, Hey, how do you run your performance test? It's usually just a generic solution for every single application that they support, which may or may not be applicable to the application team that I'm working with specifically. So I think it's a good, I'm not going to dig into it. I'm not going to dig into the rabbit hole SRE, but it is a good bridge into SRE when you start trying to define what does reliability mean, right? >>Because the reason why you test performance, it's test reliability to make sure that when you cut that release, that customers would go to your site or use your application. Aren't going to see regressions in performance and are not going to either go to another website or, you know, lodge in SLA violation or something like that. Um, it does, it does bridge really well with defining reliability and what SRE means. And when you have, when you start talking about that, that's when you started talking about how often do I run? How often do I test my reliability, the reliability of my application, right? Like, do I have nightly tasks in CGI that ensure that my main branch or, you know, some important branch I does not mean is meeting SLA is meeting SLR. So service level objectives, um, or, you know, do I run tasks that ensure that my SLA is being met in production? >>Like whenever, like do I use, do I do things like game days where I test, Hey, if I turn something off or, you know, if I deploy this small broken code to production and like what happens to my performance? What happens to my security and compliance? Um, you can, that you can go really deep into and take creating, um, into creating really robust tests that cover a lot of different domains. But I liked just using build test deploy is the overall answer to that because I find that you're going to have to build your application first. You're going to have to test it out there and build it, and then you're going to want to deploy it after you test it. And that order generally ensures that you're releasing software. That works. >>Right. Right. Um, I was going to ask one last question. Um, it's going to have to be like a sentence answer though, for each one of you. Uh, this is, uh, do you lint? And if you lint, do you lent all the things, if you do, do you fail the linters during your testing? Yes or no? I think it's going to depend on the culture. I really do. Sorry about it. If we >>Have a, you know, a hook, uh, you know, on the get commit, then theoretically the developer can't get code there without running Melinta anyway, >>So, right, right. True. Anyone else? Anyone thoughts on that? Linting >>Nice. I saw an additional question online thing. And in the chat, if you would introduce it in a multi-stage build, um, you know, I was wondering also what others think about that, like typically I've seen, you know, with multi-stage it's the most common use case is just to produce the final, like to minimize the, the, the, the, the, the image size and produce a final, you know, thin, uh, layout or thin, uh, image. Uh, so if it's not for that, like, I, I don't, I haven't seen a lot of, you know, um, teams or individuals who are actually within a multi-stage build. There's nothing really against that, but they think the number one purpose of doing multi-stage had been just producing the minimalist image. Um, so just wanted to kind of combine those two answers in one, uh, for sure. >>Yeah, yeah, sure. Um, and with that, um, thank you all for the great questions. We are going to have to wrap this up and we could go for another hour if we all had the time. And if Dr. Khan was a 24 hour long event and it didn't sadly, it's not. So we've got to make room for the next live panel, which will be Peter coming on and talking about security with some developer ex security experts. And I wanted to thank again, thank you all three of you for being here real quick, go around the room. Um, uh, where can people reach out to you? I am, uh, at Bret Fisher on Twitter. You can find me there. Carlos. >>I'm at dev Mandy with a Y D E N D Y that's me, um, >>Easiest name ever on Twitter, Carlos and DFW on LinkedIn. And I also have a LinkedIn learning course. So if you check me out on my LinkedIn learning, >>Yeah. I'm at Nicola Quebec. Um, one word, I'll put it in the chat as well on, on LinkedIn, as well as, uh, uh, as well as Twitter. Thanks for having us, Brett. Yeah. Thanks for being here. >>Um, and, and you all stay around. So if you're in the room with us chatting, you're gonna, you're gonna, if you want to go to see the next live panel, I've got to go back to the beginning and do that whole thing, uh, and find the next, because this one will end, but we'll still be in chat for a few minutes. I think the chat keeps going. I don't actually know. I haven't tried it yet. So we'll find out here in a minute. Um, but thanks you all for being here, I will be back a little bit later, but, uh, coming up next on the live stuff is Peter Wood security. Ciao. Bye.

[Music] welcome back to red hat summit 2021 my name is dave vellante and you're watching the cube where we go out to the events and extract the signal from the noise of course virtually in this case and i'm pleased to welcome victor carumpus who is the senior vice president of digital banking at bank mandiri coming in from jakarta welcome to the cube victor great to see you hi dave great to see you and great to be invited here thank you yeah you're very welcome i i wonder if you could just give us an overview of the bank maybe talk a little bit about your strategy your customers you know what the what the focus is of your company and what your role is there okay uh maybe i'm i'll give a short overview about bang mandir itself so bang money is a state-owned enterprise owned by the government but we also public company currently we already have a very big distribution channel in so uh you know indonesia is an island country it's very huge country so we are we are representing all over indonesia from province of aceh and i'm up to profits of papua and we have about 2600 branches all over indonesia and about uh 15 000 atms all over indonesia so bangladesh itself is focused on a lot of segment customers like indonesia from the corporate side small medium enterprise and also retail banking now uh we are we are currently focused in turning ourselves to become having to have more digital capability and currently in our uh current situations actually it is very good uh about 95 percent of our transactions is already coming from the electronic channel so it's only about five percent that coming from the branches but we know that this is still a journey uh and we are building more digital capability and features and functions on our digital channels to our customer got it um okay and so your your your digital journey kind of coincides i guess in a way with your your your container uh adoption journey uh i think that started a few years ago um and so maybe you could talk a little bit about that i i mean in thinking about modernizing your application portfolio obviously containers been around forever but they weren't packaged in a way that could actually be easily you know utilized and now you're seeing people in i.t roles like yourself really leaning in maybe you could talk about some of the technology considerations that impacted that desire to actually leverage containers i think uh first it's about the scalability because with a monolithic architecture it's kind of difficult to scale up for only specific features by doing container microservices we have options to scale up in a very fast way because one of the features is auto scaling on the container architectures uh one monitor is a very focused on the transaction banking so you might say bangladesh is supporting the economy of the country because in a in any given time in bangladesh we we're running about four thousand transactions per seconds that's a huge transactions number and have having said that uh our channel like i told you already running about 95 percent of the transactions so scalability is always important for us because especially like like now is the the in indonesia is a festive month it's a ramadan month where muslim is actually doing fasting but at the same time actually there's a lot of needs and people do a lot of transactions and on this kind of festive seasons the transition can be increased up to 40 or 50 suddenly and that's kind of things always happen in bangladesh and we must be ready and we must have a scalability on demand now containerization is enabling us to do that other thing is about flexibility because on the old days actually when we want to set up a new environment it's very difficult and takes a lot of time and that's affecting the time to market our products by doing the containerizations and putting it on a ci cd continuous integration called the development plan platform we are we call devsecops platform that kind of things becoming automatic because we set up the devsecos platform and the third one is the consistency actually so by by doing the contact investigations we can put the the apis on our back-end apis in the container itself and actually it's deliverable environment and a consistent experience to our customer because for example we promise our customer that every transaction should be finished within two seconds from their mobile banking up to our hosts and back forward to their mobile banking is only two seconds so that kind of thing is driving us to move to the current technology which we're using containerization and micro services great okay so 4 000 transactions per second you can't can't do that on erc20 ethereum for all you crypto fans out there that's that's pretty high volume uh and if i understand it correctly victor your role is really to envision this digital environment and then ultimately make it happen from a technology standpoint is that correct that's product that's got it yeah so okay so you now have a number of of product lines and teams you're using the same container platform maybe you could share with our audience some of the best practices and learnings that that you've taken away on this journey so i think first of all we can reuse a lot of components by doing this containerization platform is different when we still use the monolithic platform like the application server of java application server uh by using containerization actually uh be providing like a service banking as a service so whenever we build a new channel for example the first one we built a new service for example like a fun transfer service but when we create another channel for example a corporate banking electronic channel or we create another uh let's say wealth management channel whatever we already built before can be reusable instantly by using this technology so uh if i might say that actually there is a lot of best practices coming by using this platform and my team get a lot of benefit in terms of faster development time and also they can deliver the product and service in a high quality manner minimize the number of errors as well you know there's a lot of choices out there obviously i wonder if you could share what led you to the choice of red hat and open shift okay so first of all before we choose the platform actually we also comparing ourselves with the with the fintechs and also with the big tech in indonesia as well so we see we see that actually they already start using kubernetes and uh their platform is quite stable and even they can support about 90 to 100 million of customers without any issues at all so when we see this uh we choose a lot of we learn about a lot of platform and we finally choose opencv because we think that openshift and we we already do our research openshift is quite stable and for banks like us that have for having 4500 transaction per seconds stability is number one uh availability is also number one now uh having said that after doing our research we choose openshift and we implemented openshift in our environment because we promise our customers to provide 99.95 percent uh availability can i just i'm sorry to interrupt you victor can you just repeat that you cut out a little bit so you you said you you promised your customers to deliver and then you cut out a little bit can you just repeat what you just said there okay so we're giving a promise to our to our customer providing a 99.95 availability so this is the starting point of our channel sure in the efficiency we have efficient also to providing four nines which is 99.99 but i mean the starting point is 99.95 and because we have that the demand that requirement that's one of the reason we choose the openshift and red hat as our technology stack platform got it okay and so i have a question um what was it like in terms of just the skills and the adoption uh for your developers uh was it was it a big gap to go from where you were to you know where you are today did you have to what kind of training did you have to do did you have to do any sort of outsourcing to accelerate that maybe you could describe that how you close that skills gap so definitely in the beginning is quite challenging because although they are using modern languages like jaffa or kotlin but uh to understand the concept and to design correctly yes we we did a lot of training to them uh it takes a it takes me about three months to give them the proper training uh in terms of building the right uh microservices platform and also to building modular architecture in terms of the customer channel because this will be the fundamental when you build it correctly in the beginning and actually at the later point you will enjoy the benefit so the first three months actually is training and doing research and development and doing a lot of trial and errors but after the three months actually we already have the right technology stack have the right models and our devsecops is already working then actually after that the speed is very fast because uh it sprints uh we do agile way of working the agiles dlc it's only one month so every one month we already have new features coming in so that's what we call a huge transformation a digital transformation inside of our bank it's three months actually not bad i mean i would i would have thought on average it's going to take five or six months to get people up to speed so three months is pretty good and i'm also inferring that you weren't just paving the cow path you weren't just saying okay let's take our traditional and then you know re refactor it to digital you had to re-envision what digital looked like because the digital is different uh than the traditional uh so so that's actually pretty good uh ramp rate i wonder if you could just go ahead and comment if you could because when you say about uh revamp so actually it's not on the id side not only but also the business side we implement new way as well so actually if clearly they're implementing a new model so they're using a design thinking and also a co-creation model where now when we building a product so we're not writing the old product in a new way no we totally building it from from scratch and involving our key customer and our stakeholder when we're building this product so actually we implementing new models what we call design thinking and also uh co-creation with our customer so that's actually changing the face of the customer electronic channel a lot and and actually when we when we want to to deploy we invite our customer to test it first we call it like usability testing if they like it we continue to design if they they don't like it they give us a feedback how they would like it to be changed and and that's we appreciate our customer feedback because customers experience is everything now yeah so so the product can be accepted if the experience on that product is really making customer uh solving their problem solving the customer problem and making them enjoying uh doing transactions in our mobile banking product i think this is a really important point for people to understand so you weren't just paving the cow path i call it you're taking the old and and just trying to refactor it and make it exactly turn it into digital you had to really think about the business the business processes the dependencies the customer experience and then bring it back um what have been some of the business outcomes of this initiative and maybe you could we then after that we can get into some of the the future plans so so the outcome uh i think this journey uh since last year uh not last year actually since no october 2019 we already started the journey uh what took us by surprise is actually the pandemic uh suddenly the first three months when we have the pandemic of coffee we are being forced to close a lot of branches for temporary because we want to avoid the pandemic situations and that time actually the the demand using our digital channel is increasing a lot but because we already prepared actually we get the benefit one of the thing is uh the business benefit is relating so during the pandemic nobody can come to the branch and mostly the account opening actually happening online so uh we even got about 9000 account opening per day which is something that we are not imagining before so uh the benefit is very clear by using this this technology actually enabling us to provide digital capability for our customer and enabling us to open more accounts we see ourselves can grow even not linear but exponentially grow by using this platform uh talking about that indonesia is a is a huge country with we have about 200 250 million populations and actually there's still a lot of people is not having a bank account at all now by doing this actually we open opportunity doing financial inclusion for those people that need a banking account now they can reach us by using the digital platform as well yeah that's an awesome story and it goes back to the to the reason the real motivator for for moving to kubernetes and containers was scale uh and and you know it's you obviously started your digital journey prior to the pandemic but a lot of customers and i'm sure you as well were were forced to speed up a portion anyway of the digital component uh because of the pandemic like you said you couldn't people couldn't walk into the branches so but now you've got some more time to think about that journey you've had a lot of learnings 2020 was like a petri dish of experimentation but but in real time having to serve customers what's the future look like for the bank's technology journey okay so basically we uh we are not stopping only on the retail side yeah uh we want to redefine our customer journey also on the wholesale side and also on the small medium enterprise there is still a lot of things that need to be done uh and required by the customer actually so uh on the on the on the sme side we want to give them easier access uh for uh financing their businesses i think when we are back to the new normal uh the business need to have funding for for starting their business again so building an sme platform for them will will help a lot and will help the country as well on the retail side actually like i told you uh we are focusing on the more financial inclusion because uh i give you example right uh from the 230 million of indonesians uh populations i think by today maybe it's only about 50 million customers that already have a banking account so there is still a lot of people that need an access faster and cheaper and more efficient way for doing banking transactions so that's this also will become our focus and the last part is actually corporate what we see now a lot of the corporate require us to open uh api connectivity doing open banking with them the government actually the central bank supporting it supporting all the banks they are trying to create an api playbooks now and then they create they want to create an api standard for all the core all the use corporate also can connect it to the bank directly using api so this is also our focus because it will help the country economy when the economy costs the transaction costs getting more efficient getting more cheaper and there's a lot of transaction can be supported by our bank as well so i think i think that's the the future that we are imagining and i'm really hope that the pandemi will be finished and we come back to the to the new normal and we can support more transactions for this country yeah you're here to that i call it the new abnormal but so this is this is a great story everybody loves to talk about disruption we do as well and but people think oh it's out with out with the old in with the new and it's not like that this is a great story victor of uh of an established incumbent that is modernizing its its applications and its digital experience and of course the incumbent has the advantage of it's a real business it has customers that has a data it has experiences it and if it can modernize its infrastructure and and it's in its application portfolio it actually has an advantage because it's got way more features way more data way more customers and more resources so victor thanks so much for coming on thecube i really appreciate you sharing your story thank you dave thank you for inviting me thank you that was our pleasure and thank you for watching red hat summit 21 this is thecube you

>> [Narrator} From theCUBE studios in Palo Alto, in Boston, connecting with thought leaders all around the world. This is theCUBE conversation. >> Hi, I'm Stu Miniman and welcome back to theCUBE on cloud. We're talking about developers and well, so many people remember the meme from 2010 of Steve Ballmer jumping around on stage developer, developers and developers. Many people know what is really important about developers they probably read the 2013 book called "The New Kingmakers" by Stephen O'Grady. And I'm really happy to welcome to the program Rachel Stephens who's an industry analyst with RedMonk who was cofounded by the aforementioned Stephen O'Grady. Rachel great to see you. Thank you so much for joining us. >> Well, thank you so much for having me. I'm excited to be here. I've had the opportunity to read some of what you've done. We've interacted on social media. We've come to talk at events back when we used to do those in people. In person I don't- >> Busy times >> So glad that you get to come on the program, especially you were the ones that I reached out when we had this developer track. If you could just give our audience a little bit about your background that developer credit that you have because as I joke, I've got a closet full of hoodies but I'm an infrastructure guy by training. I've been learning about, containers and serverless and all this stuff for years but I'm not myself much a developer I've touched a thing or two in the years. >> Yeah. So happy to be here. RedMonk has been around since 2002 and have kind of been beating that developer drum ever since then kind of. As the company, I'm the founder. Stephen James noticed that the decision making the developers is really a driver for what was actually ending up in the enterprise. And as even more true as cloud came onto the scene as open source exploded. And I think it's become a lot more of a common view now but in those early days, it was probably a little bit more of a controversial opinion. But I have been with the firm for coming up on five years now. I work as an industry analyst. We kind of help people understand bottoms up technology adoption trends. So that that's where I spend my time focusing is what's getting used in the enterprise. Why, what kind of trends are happening? And so, yeah, that's where we all come from. That's the history of RedMonk in 30 seconds. >> Awesome. Rachel, you talk about the enterprise and developers. For the longest time I just said there was this huge gap. You talk about bottoms up. It's like, well, developers use the tools that they want. If they don't have to, they don't pay for anything. And the general IT and the business sides of the house were like, "We don't know what those people in the corner are doing, it's important." And things like that. But today it feels like that that's closed a bunch. Where are we in your estimation? Are our developers, do they have a clear seat at the table? The title we had for this is whether the enterprise developer is enterprise developer and oxymoron in 2020, in 2021? >> I think enterprise developers have a lot more practical authority than people give them credit for, especially if you're kind of looking at that old view of the world where everything is driven by a buyer decision or kind of this top down purchasing motion. And we've really seen that authority of what is getting used and why change a lot in the last year, And like last decade, even more of people who are able to choose the tools that meet the job and bring in tools, regardless of whether they may be have that official approval through the right channels. Because of the convenience of trying to get things up and running we are asking developers to do so much right now and to go faster and shifting things left. And so the things that they are responsible for incorporating into the way they are building apps is growing, and so as we are asking developers to do more and to do more quickly, the tools that they need to do those tasks to get these apps built, the decision making is falling to them. This is what I need. This is what needs to come in. And so we are seeing basically the tools that enterprise are using are the tools that developers want to be using and they kind of just find their way into the enterprise. >> Now, I want to key off what you were talking about. Just developers are being asked to do more and more. We see these pendulum swings in technology. There was a time where it was like, "Well, I'll outsource it because that'll be easier and maybe it'll be less expensive." And number one, we found it wasn't necessarily cheaper. Number two, I couldn't make changes and I didn't understand what was happening. So when I talked to enterprises today absolutely, I need to have skillsets internally. I need to be able to respond to things fast and therefore I need skills and I need people that can build what they have. What do you see? What are those skill sets that are so important today? we've talked so many times over the years there's the skills gap. We don't have enough data scientists. We don't have enough developers. We don't have any of these things. So what do we have? And where were things trending? >> Yeah, it's one of those things for developers where they both have probably the most full tool set that we've seen in this industry in terms of things that are available to them. But it's also really hard because it also indicates that there's just this fragmentation at every level of the stack. And there's this explosion of choice in decisions that is happening up and down the stack of how are we going to build things. And so it's really tricky to be a developer these days in that you are making a lot of decisions, and you are wiring a lot of things together, and you have to be able to navigate a lot of things. And I think one of the things that is interesting here is that we have seen the phrase like full stack developer really carried a lot of panache maybe earlier this decade and has kind of fallen away just because we've realized that it's impossible for anybody to be able to span this whole broad spectrum of all of the things we are asking people to do. So we're seeing this explosion of choice which is meaning that there is a little bit more focus in where developers, we're trying to actually figure out what is my niche, what is it that I'm supposed to focus on? And so it's really just this balancing of act of trying to see this big picture of how to get this all put together and also have this focused area realizing that you have to specialize at some point. >> Rachel is such a great point there we've absolutely seen that Cambrian explosion of developer tools that are out there. If you go to the CNCF as landscape and look at everything out there or go to any of your public cloud providers there's no way that anybody even working for those companies know a good portion of the tools that are out there. So nobody can be a master of everything. How about from a cloud standpoint? There's the discussion of, what do I shift left? Can I just say okay, this piece of it, it can be a managed service, I don't need to think about it versus what skills that I need to have in house? What is it that's important? And obviously, as analysts, we know it varies greatly across companies, but what are some of those top things that we need to make sure that enterprises have the skillset and the tools in house that they should understand and what can they push off to their platform of choice? >> Yeah, I think your comment about managed services is really prescient because one of the trends that we are watching closely it's just this rise of managed services. And it kind of ties back into the concept you had before about like what in NITMSA have like the Nicholas car, IT doesn't matter, and we're pushing this all away. And then we realized, "Oh, we got to bring that all back." But we also realized we really want as enterprises want to be spending our time doing differentiated work and why we're together your entire infrastructure isn't necessarily differentiated for a lot of companies. And so it's trying to find this mix of where can I push my abstraction higher or to find a managed service that can do something for me? And we're seeing that happen in all levels of the stack. And so what we're seeing is this rise of composite apps, where we're going to say, "Okay, I'm going to pull in back end APIs from a whole bunch of tools like Twilio or Stripe or Alsera, or Algolia all of those things are great tools that I can incorporate into my app, and I can have this great user interface that I can use. And then I don't have to worry quite so much about building it all myself but I am responsible for wiring it all together. So I think it's that wired together set of interests that is happening for developers has the tool set that they are spending a lot of time with. So we see the managed services being important playing an important role in how apps are composed. And it's the composition of that app sort of is happening internally. >> One of the regular research items that I see at a RedMonk is, what languages, where are the trends going? There's been some relative stability but then some things change. I look at the tool set, you mentioned full stack developer. I talked to a full stack developer a couple of years ago and he's like, "Like, ah." Like Terraform is my life and I love everything and I've used it forever. And that was 18 months. And I kind of laugh because it's like, okay, I measure a lot of the technologies that I use in the decades, not that, "Oh wait, this came out six months ago and it's kind of mature." And of course, CICD come on, if it's six weeks old it's probably gone through a lot of iterations. So what do you say, do you have any research that you can share as to looking forward? What are the skill sets we need? How should we be training our force? What do we need to be looking at in this kind of next decade of cloud? >> Yeah, so when you spoke about languages we do a semi-annual review of language usage as seen on GitHub and discussion as seen on Stack Overflow which we fully recognize is not a perfect representation of how these languages are used in the broader world but those are data sets that we have access to that are relatively large and open. So just before anyone writes me, angry letters I said that's not the way that we should be doing it (laughs) but one of the things that we've seen over time is that there is a lot of relative stability in those top tier languages in terms of how they are used. And there's some movement at the bottom but the trends we're seeing where the languages are moving is type safety and having a safer language and the communities that are building upon other communities. So things like we're seeing Kotlin, that is able to kind of piggyback off of being a JVM based language and having that support from Google or we're seeing TypeScript where it can piggyback off of the breadth of deployment of JavaScript, things like that. So those things where we're combining together multiple trends that developers are interested in the same time, combined with an ecosystem that's already rich and full. And so we're seeing that there's definitely still movement in languages that people are interested in but also language on its own is probably pretty stable. So as you start to make language choices as a developer that's not where we're seeing a ton of like turnover. Language frameworks on the other hand, like if you're a JavaScript developer and all of a sudden, there's just explosion of frameworks that you need to choose from. That's maybe a different story, a lot more turnover there and harder to predict, but language trends are a little bit more stable over time. >> There's a lot change. Changing over time. Boy, I got to dig into, relatively recently I went down like the JAMStack ecosystem I've been digging into serverless for a number of years. What's your take on that? There's certain people I talked to and they're like, "I don't even need to be a coder. I can be a marketing person, and I can get things done." When I talked to some developers they're like, "Citizen developers, they're not developers, come on. I really need to be able to do this." So I'll give you your choice as to, serverless and some of these trends to kind of expand who can code and develop. >> Yeah, so for both trans like JAMstack and serverless, one of the things that we see kind of early in the iteration of a technology is that it is definitely not going to be the right tool for every app. And the number of apps that they approach will fit for, will grow as the tool develops and that you add more functionality over time. And all of these platforms expand the capability but definitely not the correct tool choice in every case. That said we do watch both of those areas with extreme interest in terms of what this next generation of apps can look like and probably will look like in a lot of cases. And I think that it is super interesting to think about who gets to build these apps, because I think one of the things that we probably haven't landed on the right language yet is what we should call these people because I don't think anyone associates themselves as a low code person, like if you're someone from marketing and all of a sudden you can build something technical that's really cool. And you're excited about that nobody else on your team can build. You're not walking around saying, "I am a low code marketing person" Like that's demeaning. Like I know I'm a technical marketer. Look what I just did. And if you're someone who codes professionally for a living and you use a low code tool to get something out the door quickly and you don't want to demean or say, "oh hi, I did a low code, that in a sec." Everybody is just trying to solve problems. And everybody is trying to figure out how to do things in the most effective way possible and making trade offs all the time. And so I don't think that the language of low code really is anything that resonates with any of the actual users of low code tools. And so I think that's something that we as an industry need to work on finding the correct language because it doesn't feel like we've landed there yet. >> Yeah, quick Rachel, what want to get your take on just careers for developers now to think about in 2020, everyone is distributed lots of conversations about where do we work? Can we bring your remote? Many of the developers I talked to already were remote. I had a chance to interview the head of remote for GitHub there were over a thousand people and they're fully remote. So, remote absolutely a thing for developers. But if you talk about careers it's no longer, "Oh, Hey, here's my CV." It's, "I'm on GitHub. You can see the code I've done." We haven't talked about open source yet. So give us your take on kind of developers today, career paths and kind of the online community there. >> Yeah. Oh, this could be its whole own conversation. (laughs) I'll try to figure it out the, my points. So I think one of the things that we are trying to figure out in terms of balance is how much are we expecting people to have done on the side? It's like a side project hustle versus doing exclusively getting your job done and not worrying too much about how many green squares you have on your GitHub profile. And I think it's a really emotional and fraught discussion in a lot of quarters because it can be exclusionary for people saying that you need to be spending your time on the side, working on this open source project because there are people who have very different life circumstances. Like if you're someone who already has kids or you're doing elder care or you are working another job and trying to transition into becoming a developer, it's a lot to ask these people to also have a side hustle. That said, it is probably working on open source having an understanding of how tools are done, having this experience and skills that you can point to and contributions you can point to, is probably one of the cleaner ways that you can start to move in the industry and break through to the industry because you can show your skills to other employers. You can kind of maybe make your way in as a junior developer because you've worked on a project and you make those connections. And so it's really still, again, it's one of those balancing act things where there's not a perfect answer because there really is two correct sides of this argument. And both of the things are true at the same time where it's it's hard to figure out what that early career path maybe looks like or even advancing in a career path if you're already a developer, it's, it's tricky. >> Well, I want to get your take on something too. I go back a decade or two, when I started working with Linux about 20 years ago back in the crazy days where it was just kind of lot of work and patches everywhere, and lots of different companies trying to figure out what they would be doing. And most of the people contributing to the free software before we even were calling it open source most of the time it was their side hustle. It was the thing they're doing. It was their passion project. I've seen some research in the last year or so that says the majority of people that are contributing to open source are doing it for their day job. Obviously there's lots of big companies. There's plenty of small companies. When I go to the Linux Foundation shows I mean, you've got whole companies that, that's their whole business. So I want to get your take on governance, contribution from the individual versus companies there's a lot of change going on there. Heck the public clouds, their impact on what's happening open source. What are you seeing there? And what's good, what's bad? What do we need to do better as a community? >> Yeah, I think the governance of opensource projects is definitely a live conversation that we're having right now about what does this need to look like? What role do companies need to be having, and how things are put together is a contribution or leadership position in the name of the individual or the name of the company. Like all of these are live conversations that are ongoing in a lot of communities. I think one of the things that is interesting overall though is just watching if you're taking a really zoomed out view of what open source looks like, where it was at one point deemed at cancer by one of the vendors in this space, and now it is something that is just absolutely, an inherent part of most tech vendors and end users is an important part of how they are building and using software today. Like open source is really an integral tool in what is happening in the enterprise and what's being built in the enterprise. And so I think that it is a natural thing that this conversation is evolving in terms of what is the enterprise's role here and how are we supposed to govern for that? And I don't think that we have landed on all the correct answers yet but I think that just looking at that long view it makes sense that this is an area where we are spending some time focusing. >> So Rachel, without giving away state secrets we know RedMonk, you do lots of consulting out there. What advice do you give to the industry? We said, we're making progress. There's good things there. But if we say, okay, I want to at 2030, look back and say, "Boy, this is wonderful for developers, everything's going good." What things have we've done along the way, where have we made progress? >> Yeah, so I think it kind of ties back to the earlier discussion we were having around composite apps and thinking about what that developer experience looks like, I think that right now it is incredibly difficult for developers to be wiring everything together. And there's just so much for developers to do to actually, get all of these apps from source to production. So when we talk with our customers, a lot of our time is spent thinking, how can you not only solve this individual piece of the puzzle, but how can you figure out how to fit it into this broader picture of what it is the developers are trying to accomplish? How can you think about where you're art fits not only your tool or your project whatever it is that you are working on, how does this fit? Not only in terms of your one unique problem space but where does this problem space fit in the broader landscape? Because I think that's going to be a really key element of what the developer experience looks like in the next decade, is trying to help people actually, get everything wired together in a coherent way. >> Rachel, no shortage of work to do there, really appreciate you joining us thrilled to have you finally as a CUBE alumni. Thanks so much for joining. >> Thank you for having me. I appreciate it. >> All right. Thank you for joining us. This is the Developer Content for theCUBE on cloud. I'm Stu Miniman. And as always, thank you for watching theCUBE. (upbeat music)

[Music] everyone welcome to this cube conversation here in Palo Alto California I'm John Fourier co-host of the cube were in the cube studios our next guest is Adam Weinstein who's the CEO of a company called cursor so introducing curse it's hot startup growing in the data analytics space doing something unique very innovative around changing the game on data data catalogs but more importantly how data is being used and consumed and also kind of revitalized so Adam welcome to the cube conversation thanks for joining us thanks for having me excited to be here so you guys are a young startup you're in a really good wave right now it's the cloud data the changing nature of data take him into explain what cursor does what's the company what's the focus how big you raise money start the update yeah yeah so I'll give you a quick background on me that sort of leads into that right so spent most of my career as an analyst I might say right so working with data living in data good the bad the ugly right and spent last couple years prior to this at LinkedIn working an analytics team there and one of the challenges we had as an organization was you know finding what was where and who worked on what so when you had literally a thousand people across the company of 10% of the business touching data on a daily basis one thing we struggled with was knowing you know who was working on what what was where what was accurate what was maybe outdated data was getting created it insane velocity was talking earlier little we were creating a trillion events a day inside the business and so you know as an analytics practitioner if you all it became increasingly difficult to get to a quick answer there was no search to go and say okay I want to look for this question as I've been asked before and if so where's the data so you know there was this new space called data cataloging at the time that seemed interesting with the cataloging was really only looking at how do we create like a yellow pages of data not necessarily how do you put it in the workflow of a person that's then taking that and acting on it and then you know feeding that insight that they may have created back into that sort of cataloging feel right so it's all an opportunity to create something new that really supported an analyst and really was you know mindful of how their day-to-day what job existed and you know that was that was cursor right what's the role of the analyst now because one of the things that's challenging the industry was this idea of and you just go back five years data science is the next big thing there are more open jobs in data science than there are people but then this also trend came on around humanizing data science and not requiring you to know hardcourt C++ or Python or having all this wrangling environments doing all this provisioning of stuff to get started to his idea of okay can we level up that and also can he make it easier almost like using Excel yeah I thought of the kind of the trend what's your thought on the current state of the data analyst role no I think that there is a lot of analytics work that maybe five years ago you know was being done and and there was no automation around it and in the next five years it'll get it wouldn't say automated away but I'll be at heavily automated away called 80% of the workload but that 20% use or 20% of data that it's really difficult to understand and may not be able to you know get an answer out of it automatically that that's not you know that needs people and someone that understands the business that's technical enough to go dive into the data and even though that may not be the hundred percent that existed before the amount of like effort that's needed to decipher it I think is is maybe even greater than it used to be because the rate of data getting created is so much greater to is the demand for more solutions how about cursor how big are you guys who's on the team what's the product is it SAS as a software sir give a quick overview now great so we're small or seven person team right now I started the company a little over a year and a half ago you know the idea was to get a solution to market that was lightweight enough that someone could come and download it and try it very quickly without having to go through a long enterprise sale cycle they could get something on their computer literally stand it up in five minutes start putting in a data and having it you know identify and help with their day-to-day job the team is is volunteering - me right so you know there's that we have folks from Salesforce where you know I came from a company called ExactTarget the tails for spot Pandora thumbtack were basically tried to bring people together that if all you know seen companies scale and data scale and and you know bring those insights alongside them so first generation data scale yet the classic you know web scale build it out on open source grow it have things break rebuild it yeah I mean we levered some open source I think you for us right now how do we get something that unique to market as quickly as possible right so there's things that we can use that that are out there that are that are available that are you know especially if they're you know standardized right we'll make use of them but other times well we've built quite a bit of stuff on our own and our solution lives you can't live in the cloud it can also live on premise and actually see a lot of customers deploy it in a hybrid manner so they may have this sort of collaboration layer live in the cloud but it's pointing at data that's both cloud-based and on-prem and even though that data may get migrated to the cloud over the next several years a lot of large enterprises are still so are you guys going to market by selling a product as freemium what's the and is it software they download on-premise is it SAS in the cloud you talk about the go to market and how people engage with the product no it's heavily SAS in the cloud right so I think sort of companies that are in a heavily regulated industry that really haven't yet figured out that cloud model you know our products SAS delivered there is a client that lives on the users local machine and the reason that exists is just for security purposes because data is still often behind the firewall so like you can ask your security guy hey poke a hole in the firewall for this company I've never heard of or you can have a tool that lives on the machine that sort of brokers that in a fall way you guys are flexible we're flexible right you don't necessarily need that right if you deploy it in your own infrastructure obviously there's there's no need to then have that client it can it can handle things so why curse or what are the market drivers for you guys what's driving your business yeah we saw this need errors I felt this needed very acutely LinkedIn which is you know with analysts are getting you know hundreds or thousands of questions as a team on a daily or weekly basis if they're within a large organization how do you address some meaningful portion of those with automation so if a questions been asked before and you've got you know great solutions like a tableau or a look or a thought spot or a power bi like you've got tons of reporting solutions around the business but there's no place to go and say hey where's the answer to this question which one of those is it in is it a Salesforce report is a tableau dashboard and and so you'd ask your friendly analysts who'd be happy to help but like that's taking them away from doing things that are new and so I I kind of became that switchboard unfortunately and so I saw an opportunity to create a solution that would sort of want to meet me and that's that's really obviously index all the questions kind of see what the frequency was the behavior you have the analytics kind of packaging it up in the catalog yeah and taking it a step further I think what are the topics how do you map topics and understand okay there's a fire in Aisle seven and that fire happens to be churn and it's q3 and why is fire on turn and how do we dig into the data behind turn and get some water they made an insight surround it and then you know but yes certainly the step one is being able to direct people on the right to the right place once you get beyond that doe to understanding what our company's data is and what the sort of you know size and shape and characteristics of it are you can actually take it a step further and you know really sort of recommend things which is what we want the alternatives I'm not having like a data catalog and a cursor is to go ask your resident analyst or hope that someone posted something on slack and then you search through slow I mean all kinds of I mean really not up not a viable no it's a hodgepodge of solutions right so one of the things we saw in this is interesting having been at LinkedIn is that you know more and more teams around organizations are hiring analyst talent they may not call it analyst I might call like a citizen data scientist they might call it a researcher they might even call it an engineer like a data engineer a lot of overlapping skills and what the real need is is like someone to be on that team that knows their data inside and out but yet can help answer like you said sort of the ad hoc question that comes up you know every day and and so for that like you know if they can use her sword answer 80% of those or you know as many as possible right we've got it's interesting I do see the same kind of knee-jerk reaction when LinkedIn and and other clients that have a similar profile where they have a lot of data I certainly see that when they get hired what's the kind of what's the marching orders go jump into the data and figure it out is there I mean because this is kind of an evolving new position that's growing very very fast what are they directed to do I mean what's this what's the job responsible it's a great question so I think one of the challenges is how do you onboard people when when there is no place to start right like it's okay here the hundred places we store data go figure it out with Lauren on your own we had built a little bit of a training and onboarding every college they really have start as a PowerPoint deck and then it expanded into some code and some additional training but you know there is no solution for that right I think our internally we had this notion that you know somewhere between three and six months the person was ramped enough to begin to be productive it was like how we how do you measure ROI on a person when you hire them right and that was LinkedIn where I think we were pretty you know we were out here we you know we have you know quite a few nerds right like I think we're pretty good at organizing things relatively speaking I can't imagine what that's like in productivity just write some Python code spit out some Angela is that good enough look yeah I guess then or sink-or-swim kind of mentality and then you know to get someone else in there yeah and the nuance of the data has gotten just because everyone's mindset is record everything right like it becomes harder and harder to actually get a quick answer so gonna give an example like you know looking at data do you know if something's you know test data if it's you know fake data if it's you know if there's something you need to be mindful of like in e-commerce how do you account for returns how do you account for you know fraud how do you account for things that you know if you look at the data and say I just want to add up all my orders and get some total amount of receipts like you would think oh that's my sales for the day but then you forget like there are all these things that if you don't know the data really well that you miss out on and so yeah multiply that by you know large corporates what's the phrasing needle in a stack of needles I'm trying to find it like everything in there so I mean data structures data cleanliness yep these are huge issues huge and you know we will address every single one of them many think we're courser wants to sit is in between a lot of best-of-breed solutions right so we're not building a new Hadoop we think we do a great job of storing data whether you want to call it a lake or you know something beyond a lake right like you know there are plenty of data stores in an organization to do a great job at storing data you know on the opposite end of the spectrum like in terms of visualizing data are actually generating you know insights they're a great bi solution to the market but in between those two sort of you know ends of the spectrum there's a lot of work that gets done and that's what we want to live Adam talked about the innovation and the tech behind cursor and then just you know innovation in general the way you see it and the team sees it because you're on the Front Range of a new trend bleeding edge cutting edge whatever you want to call it certainly you're pushing the envelope yeah yeah what's the core tech for cursor sir where's the innovation lie has it all tie together sure so we have a you know a couple different deployment models but our most common one is we have a you know a cloud layer that enables collaboration so anytime a company is using our product you know metadata we don't ever look at company data that's one promise we've made because we want to work in regulated industries we want to be in places where there are high security environments but we never pushed actual data to the cloud but met about a company's data so you know what's the name of a column you know what's the name of a database who's used often have they used it what dashboard names are using all those kinds of things could push to our cloud you know we use a language called Kotlin which is a java derivative to write most of our back-end code mostly because a lot of legacy data stores or you know designed to interoperate with Java and then you know we have a client component that lives on a user's machine and that's what facilitates a lot of the day-to-day work and we do that just for security purposes because you know because most data is behind a firewall whether it's cloud based or not is you know it gets independent of that it's oftentimes not publicly accessible we can't expect our cloud will be able to get directly to it right whether or in WSG CP or arouser we can work with any of them you know we you know expected the company's security policies requires some sort of you know local connectivity and so that's you know that that client it's actually just a product called electron that wraps you know react front ends are very very common and you know paradigms you know we try to pick packages that we think have some staying power cuz you know every time the wind blows there's a new framework that's you know the latest and greatest so that's that's awesome I talked about the marketplace and customer interactions you have up so you guys are a year and a half into this or so what's the feedback what are you seeing what are you learning what are the key signals from the marketplace that you're seeing that's supporting your company the direction you're going share some anecdotes and data around what you're seeing and hearing so we launched the the first personal product it was last May and what we were trying to do was get something out there in the wild that anybody could try and get value out of without having to go through like it's a sort of long enterprise sale cycle so download it you can use it you can share it with the guy next to you think of like an Evernote or a Google Drive style approach to actually being able to do something and you know so that that had some great success rate when we went out with announcement we announced we'd you know fun with the company we roughly we got 1500 users in the first four months just that we're trying it it was across about four to five hundred companies of four ish five ish users a company and that will let us get a bunch of feedback which was great right some of it was hey we don't like this and other words hey double down here and the key thing that we learned was they're sort of three audiences that we're serving right one is that traditional analysts which you know hopefully that was the case cuz that's where I came from and that was the goal there's also two other audiences I didn't expect as much of one being software engineers and software engineers that you know constantly pulled into you know like you said find the needle on the pile of needles and they don't want that to be their day job but they do want to like do it once and then share it with the rest organization and they don't have a place to do that today so there's a poly there's a great great you know audience of softwares and then the last one is actually business leaders that are the ones asking the questions and they want to find a place that they can go to that you know will answer the majority of them and so the feedback we've gotten is that there's probably three skins of the product that we're gonna have to build ones for that analysts the second a little bit more technical for an engineer and the third is actually very business-friendly which is just you know you don't care about sequel code you don't want Python code you don't want any code at all you just want to know the reports here or if it's not ask Danny that's interesting so the feedback of the marketplace is kind of lays out the workflow stakeholders yeah you know the analysts got to do their job and doesn't want to be coding so they bring the coder and coders once the kid put gets pulled into the project so they're doing their thing and they certainly want to get back to their coding but get pulled in for business reasons the business wants a search and discover yeah kind of all kind of coming together that seems to be the stakeholders it's the stakeholders exactly right I mean I think it's it almost lines up probably engineer analyst business leader right like in the engineer oftentimes is the one that has to go build a pipeline if that's what's needed right and the analyst is the one that consumes from it and then business leaders the one that looks the report every morning and says hope that's bad and really what you're getting down to his classic software development kind of thinking of DevOps and cloud computing which is you don't what you want to automate repetitive tasks and you don't want one offs all right so engineer doesn't want to do one office of constant one-off pipelining yep yep know that you hit the nail on the head like I think you know it like the whole notion of like self-service bi or self-service data like it it's aspirational I think it will be forever right even as you get into AI and yes automated AI and in you know a certain percentage of problems will always be able to be automated but a certain percentage won't be right it was get more point about the reporting is it's only good as the data being reported so you might feel good he's looking at a dashboard with underlying data that sucks and you're like you're dead in the water that's that's a very true thing unfortunately we saw that you know not just did like every company feels that but I talk about the environment and customer base okay as as you worked at linkedin which i think is a very acute example because you know linkedin is one of those magical companies where they really hit the data equation really well obviously it's like a resume for recruiters and it turned into a social network and then they got a treasure trove of data all kinds of gesture data they got great metadata on profiles now they've got a feed so again it's like Facebook analyst this data and so the unknowns probably got came came piling in so it's great proxy for as enterprises and businesses start thinking about how to think about the tsunami of new kinds of data not just grow the data but like hey there's all kinds of new data mobile the touch point gesture day all those kinda stuffs coming together how should they think about setting up a plan so if I'm a customer say hey you know I got a date I got Cuban of you data I got consumption data all these new things and what do I do yeah how do I create a holistic architecture yep take advantage of the different data silos or data sets but yet not screw up the operations of those days yes we can't stop right what's your advice on that cuz it seems to be a core problem it is and one of the things I think I've come to believe is that you know companies will get together and they'll spend months or even years coming up with like an architecture of the future right and and I don't believe that you can come up you know and sit in a room no matter how many days it takes and come up with something that's gonna be you know all things to all people like you're gonna basically need solutions that are nimble enough to be to be you know installed and get value very very quickly even if just a small amount of value and then grow with you over time so of course that's sort of the way we're set up right like you know you can come have a small team so take take on marketing operations D and they work with advertising data they're dealing with how do you get you know a lead and convert them into a sale they can use you know a product like cursor or I think any other good product in the marketplace should be you know you designed it this way where you you nibble on it you get some value and then you deploy it to other teams once you've learned how to how to best do that I think the like Big Bang approach of like hey this is our solution that's gonna you know work for everyone is really tough okay take an area we can get time to value quicker right and is it like a data Lake of model where you just kind of throw some data into one corpus or so we can have a base data doesn't actually live ever within cursor right we may you know if you're actually operating on it say you're an analyst you're writing some Python you're writing some sequel like yes I mean you for the sake of seeing in the UI it will temporarily be cached and encrypted there but we never actually store any company data we just point to it and when in in what we've built are these really intelligent connectors they can go mine what's there so if we're looking at a tableau instance we can say okay here all the dashboards there here all the code behind those dashboards here the table the data stores those dashboards are hitting here's are often they're consumed Oh every Monday morning at 9:00 a.m. 250 people in New York hit this dashboard and how do we learn from that and then hopefully make recommendations on it like what happens when data underlying a dashboard changes every Monday morning and all of a sudden it doesn't should that be a red flag somewhere that you know we should tell somebody that hey there's probably an issue with this so we're trying to really learn from things that are already there today as opposed to having you create new things what's next what's going on now how you going forward what's the key objectives for you guys yeah so I think there's two things really stage business like you can get sort of pulled into this hey we want to be a generic solution for everything what we found is that there probably a couple industries that are really they feel this problem really acutely and some of its financial services actually retail surprisingly just given you know dispersion of data inside retail so we've had pretty good success in both of those areas and I think our next step will be to actually probably formalize some you know sort of play books if you will and continue down that path and then integrations are that are the next thing right like we integrate with a bunch of stuff but we definitely won't agree with everything and there's you know an infinite amount of tools out there right so we want to continue to you know partner with companies that have you know Best of Breed solutions work with them to create deep integrations we're not trying to displace them what is trying to you know complement them and help drive you know the traffic to them that's looking for what's in there and so like that integration work is really never-ending why should the company keep up the old way to bring in the new way what's your what's your yeah I don't think they're actually having to give up the old way I think it's you know there are some things that you're gonna naturally be transitioning off of right there's there's always gonna be a bi solution that transitions from you know legacy to new whatever legacy may be defined as and as you're doing that there's there's there's this missing ingredient I feel like how do I track what's where when you could say that that was sort of solved by data catalog so I think the old data catalog is kind of dead and I think what's really happening is that you need something that works with you know where you are and every day whether you're an analyst a business leader or an engineer right and they can follow you along not disrupt you from your day-to-day workflow and also be intelligent about what's what what's where and that's sort of what we're trying to build well great to chat thanks for coming in spending the time talking about cursor congratulations on the venture thanks looking forward to seeing that be round coming soon yeah thanks for having you very much it's coming soon be round a round a round seed round and yeah it will definitely be on the on the near term horizon and Weinstein CEO cursor serial entrepreneur here inside the cube innovating around the data this is the new model this is what's going on it's the new wave that they're ride I'm John furry with the cube thanks for watching [Music]