 And yeah, thanks Pete and welcome everybody. Thank you for spending this next 45 minutes with us. Like Pete said, we are talking about overcoming costs of digital transformation through DevOps. I'm Mon-Mirie Ray, but you can call me Mon. And yes, I am part of the GitLab APAC team, part of the customer success team, specializing in MLOps and DevOps. So, what are we talking today? How are we spending this time? So firstly, we're gonna talk actually a little bit about why is this even a topic today and what is really digital transformation and then relating it with costs. So the whole power of actually making it cheap and a case study for it, the economic lens of digitization and then little bit tips and tactics through DevOps in that digitization and cost strategy and then holistically simplifying with GitLab. So let's start with why are we talking about this? To actually unravel that, I do wanna actually start that with a story. And this goes back to actually 2018. And it was a room full of people where it's an economist, technology economist, Nobel Prize winner, Daniel Kahneman, who's got that picture on that top right. And then there was, I think the Google achieve AI economist as well as the Microsoft and the Obama Digital Transformation Advisor. They're all in this room in 2018 and really really unraveling, what does AI mean to the society? What is digital transformation? How do we actually make development of software better? And Professor Daniel Kahneman, he basically ends that conference with this story and the story goes like this. A well-known novelist wrote me some time ago that he's planning a novel. The novel is about a love triangle between two humans and a robot. And what he wanted to know is how would the robot be different from the individuals? And I propose three main differences. The first one is obvious, the robot will be much better at statistical race. The other one is that the robot would have much higher emotional intelligence. Now that's a tricky one because we think we humans have a better emotional intelligence. But the way Professor Kahneman was saying is in the way that let's say we want to understand human faces, recognition, there are a lot of things that the computer can pick up quite faster than we as humans can pick up. So that's what he meant by emotional intelligence. Now the third one is the one that we are gonna spend a lot of time on is the tricky one, is that the robot would be wiser. Wisdom is spread, wisdom is not having a narrow view. That's the sense of wisdom, it's broad framing and robot will be endowed with broad framing. And I really do not see why when it has learned enough it will not be wiser than we people because we don't have broad framing. We are narrow thinking, we are noisy thinkers, it's very easy to improve on us. So this whole next part of this presentation we will focus a lot on how we as humans are narrow thinkers, are noisy thinkers and how we can use digitization to actually improve upon that. So to first focus on actually the narrow thinkers, the noisy thinkers, the humans, how we actually go about the process of any changes or any transformation. So it's basically to three different areas, judgment, action and decision. I'm gonna take a little bit example and relate it to digitization through this way. So the first is formally machines, they enhance human productivity. And it was in the first era, in the nineties of the digitization movement, lot of the manual tasks has been done by the computers or to the digitization journey and humans actually do the mental tasks. The era of digitization we are right now, it blurs that line between that physical and mental task. So for example, if a bank is uncertain whether a credit card charges fraudulent or not, the bank compares the payoff by refusing the legitimate charge to the payoff from approving a fraudulent charge. Now, judgment is the process that we as humans first look at it and we put that judgment in that process or in the computer decision making. So in simple cases, we can actually have it all automated. In complex cases, when that digitization process cannot add value, then the decision makers cannot just use judgment but will choose that action given an best result on average. So then there's some tasks that require judgment that's a switching railway trades that can be automated. And as automation proceeds, machines can substitute for humans and hence starts slowly, slowly that journey of transformation. So to actually look into what is digital transformation, the value of digital transformation, it is a movement that gets us closer and closer every day to almost automated decision making by enabling precise judgment and anything automated, substitutes something manual and has the power of being cheap. So the power of being cheap, transversely cheaper capabilities, it has impacted businesses, models, entire industry all through. Obviously a good example is internet, which is an example of recent innovation. It has made everything from communication, distribution research, everything cheaper. But what does that actually mean to this current digitization of software development cycle? Now to empower that, I wanna go through that example of cell phones. So mobile phones, the whole journey actually started in the 1960s to 1980s where Motorola actually led the industry. They were prototyping and working to find a way to turn military style radio phones into consumer devices. So 1983, almost 4,000 US dollars, Motorola, Dynar, TAC, that was considered revolutionally. In 1990s, we focused on making cell phones more affordable, reducing the costs through service contracts. And came the era of the Motorola micro-TAC, which was $3,000, to then all the way to, in 1993, the $900 Simon Personal Communicator. Then 2000s is what we call the smartphone's developer, which is taken away from actually a term called the dumb phones. And it's all about changing, not only helping with your current strategy of communication, but changing the way you look into communication. And then further in 2010 and future, that smartphone totally, totally, not just has developed, but it evolves to what we have currently is, I forget the number of iPhone, but iPhone 11 to 11, $1100, it's constantly, constantly developed and evolved. This is a classic example of digital transformation where you actually make things affordable. Once things are made affordable, there is a drop in cost, everyone starts using it. And once everyone starts using it, innovation gets better and better. And the whole strategy of how you do a current software is changed with time. So that goes to the economic lens of DevOps. A certain price drop on something means more consumption. So let's say if there's a drop in price of tea, people buy more of tea, less of coffee, and everything that complements that, like sugar and milk is bought more. So what does that actually mean for a lot of different technology? So for mobile phone, like we saw, there was a drop in price of communication. For AI, it's a drop in price of machine prediction. For DevOps, it's a drop in price of transaction costs within teams that helps in redrawing the boundaries to create cross-functional teams. And the sugar and milk for DevOps is actually technology, automation, and human judgment. So now I'm gonna take AI DevOps, mobile phones, and talk what does that mean for digitization, the economic lens of digitization. It is the drop in price of decision-making. And when digitization is framed as cheap decision-making, its potential becomes very clear. So then digitization is at the heart of making any decisions under uncertainty. It increases productivity, so whether it's operating machines, to handling documentings, to communicating with stakeholders or customers. And uncertainty has always constrained strategy, so better digitization creates opportunity for new business structure and strategies to compete. So now that we have a little bit more understanding of what we consider the digital transformation from an economic lens, from a price lens, from what on the core value it is, it's a drop in the price of decision-making, we wanna go a little bit more as to understanding what does that mean for DevOps. So in GitLab, we, and a lot of different people have various ways of looking at this infinite loop, but DevOps is an infinite loop. It starts with the planning and goes all the way to monitoring to various cycles and stages of development and operationalizing, where each part of that cycle is managed. The development is fully secured and every step of that operationalization fully, fully defended. And through this process, everything is orchestrated and there is a balance between choice and control. Now, with this understanding of DevOps, before we actually go into the next phase of going into the best practice of digital transformation DevOps, we will actually have some polling questions to understand where we are as an audience in the journey of DevOps, what are the challenges we are facing and how are the team structures. So Tim is gonna actually have this polling part ready and we will give everyone a minute to be able to vote for it. I see people still voting, so I'll give a few more seconds. Yeah, I think we can end the poll here. So, all right, so we have the results of the poll and the questions were keeping your teams aligned and working on the right things at the right time can be challenging. How many tools do you have to use to understand their current status? So 25% said one to two, 40% two to five, 13% greater than five and then 25% not sure. And then which challenge in the DevOps process do you feel takes up the majority of your resources to solve currently? And 40% has said manual complex processes that's low development. So I wanna actually go into then part of this whole strategy of we totally agree with the poll results. So currently where the software cycle is, we love tools and we keep on looking into various different tools to do various different tasks but humans remember we are noisy thinkers, we are narrow noisy thinkers. It is too hard to integrate all of that and understand all of that. So yes, the last decade we have spent a lot of time buying a lot of tools, buying a lot of software but that comes with the technical depth, integration dilemmas, understanding different processes, different languages to understand the way the tool comes and that comes with a cost. So there is multiple silos of teams, tools. There is like a great 40% is still a lot of manual work, there's repeated work, there's a lot of waiting time. Then there is also a lot of legacy systems and that is where we are currently at the software cycle. And so to be able to actually use automated decision-making and reduce the cost, we need to figure ways to simplify our tool cycle, flatten it across various teams, be able to scale things easily, go away from the manual work to automated work and be able to monitor it all through every stage of those DevOps lifecycle and then have it all defended with security through all processes so that doesn't become a later stage. And in GitLab, we believe that we can have it through single application, fewer hands-off, fewer integrations, faster built-in automation, higher quality of your code to your process and a security built-in. Now for the next couple of actually slides, I do wanna go to how in GitLab we actually enable that a little bit more in-deep through all these different phases. And to do that, I wanna start actually with looking into the old expensive way to cheap ways and how we actually do that. So, silo team to cross-functional team, monoliths to microservices, manual testing release to automated testing release, manual configuration to infrastructure as a code, team defining to link to tool standardization and annual release to frequent releases. So from a higher end broader strategy, these are the things that actually make digital transformation through DevOps cheaper. But to even start beginning that, there are little tricks that one gets better and better in that digitization journey. The first simple strip is changing our communication experience. This might seem very simple and very, very trivial, but there has been so much, so much cost that goes into time as well as cost in just sending each other emails. So this is just an example of Slack and it's great. It actually helps in open and inviting collaboration. There was a balance of asynchronous and synchronous. You can have teams to actually get the right audience, have topics set accordingly, but little steps like that helps in the visibility, the collaboration and the transparency in communication. The next part is moving from actually private to shared documents. So similar kind of concept as communication, where it's open agenda, meeting collaboration, everything documented, but actually shared. Shared globally with anyone in the team or organization, but having these little, little practices gets you better and better every day, dialing up the accuracy of digitization. This is an example of now we go into ideation of a project. So if you have a software, you start to build with. When we start building that, having the use of boards across teams, and in GitLab we have the scrum or Kanban boards, and then assigning and ideating, having the idea and then assigning different tasks to the idea, having the right alignment with groups, whether we call and having subgroup layers to give visibility as well as giving ownership of tasks and having clarity about it all across the organization is key to digitization and dropping that cost. So later there is no need of repeated work or not understanding on that alignment, confusions and everything that goes with not having your strategy of your software structured through a very simple process of having boards. The next is a part of what we are also going through. So we are part in the middle of a global pandemic. And I think right now, GitLab has been a remote company for a while now, and it's always been a remote company and I think it's the largest remote company, but this is something that everybody's embracing now, being in the middle of the global pandemic. So having seamless development is also important. So whether it's a project that you do, being able to have GitLab at home versus office to an agency, having the project import, export archives, features that you could develop anywhere, and includes artifacts, context, something that we do is we license users and not instances. Again, similarly, it's all about giving people the flexibility to be able to seamlessly develop no matter where you are. And then with through APIs, which is again key to digitization, being able to automate these processes by setting times, schedulers when projects is exported or imported, all a part of just the fundamental basics before you ideating a software. So communication, having the infrastructure to be able to code anywhere. Now that we've actually had a good understanding of little tips on communication, seamless development. Then we go into actually the process of GitLab. It's a single application that once goes from planning to monitoring where every part of your tasks and tasks that you've put on your board of creating and verifying and packaging of software is all version controlled. Every part of it is log tracked and it is automatically seamlessly orchestrated through the GitLab CI pipeline that goes straight into the releasing of the software to deploying it to then configuring and as well as then monitoring the logs of every step of the way, whether it's through the cycle analytics or how you've gone from productivity to scaling it or monitoring for security as well. So that starts the starting of the software journey where every part of it needs to be automated, harmoniously integrated, but also have governance and control and visibility with every step of the way version controlled. We've talked about a little bit of how we actually go about the communication, then the development and a little bit on end to end application that is harmoniously put together. But when we go about actually building the software, we all know about MVP, which is minimal viable product, but through this digitization journey, we have started appreciating even lesser than MVP, MVF, minimal viable features. And in GitLab, we believe that you can go even lesser, which is minimal viable changes, which basically means that every little, little change can add value. You can actually govern that, understand those different changes very quickly and not depend on annual or the final MVP that's already built, but little, little changes that you can vastly actually look into it as well as QA it and redo things very fast than to actually wait later once the MVP is kind of done. This not only helps in actually the drop in cost, but also unlocks the velocity and makes things go in time frames much faster with frequent releasing. So again, moving from that concept of MVP to all the way to minimal viable changes. Now, all through this whole process of unified development, pipelines, having these orchestrated pipelines where everything is synchronously integrated is again key. So we've talked about these different stages. We've talked about the Kanban board communication. We've talked a little about the seamless development, these minimal viable changes, version controls, but all of this needs to be harmoniously integrated. This is an example of all the different phases that a software went through from building, preparing to testing, post-testing and post-cleanup, all the various treatment that any part of those little tasks can be actually triggered as well as tested. And if you need to actually not go to the rest of the cycle and stop it based on a certain bug or a certain vulnerability, that needs to be actually have visibility and orchestrated. So pipeline for every minimal viable changes, pipeline for every commit that helps with that automated testing, security scans, continuing scans, configuration deployment. And later, this pipeline can be extending into what we call assembly lines, which is again key to automation because one time you might be doing a software application, which is just a bunch of Java rules, then that might be extended into, let's say, an AI application or a prediction engine. And so this pipeline is key where you make it easy, automate it and extend it into every different application based on what you need. So it can be extended to DevOps, to DevSecOps, to MLops, to DataOps, every part of that operation that needs to be integrated and have visibility all throughout. We've talked a little of security in the pipeline and security is paramount. Now there is a concept that there is, once you build a software or it's in the MVP phase and then it goes to the security team to actually get a better understanding of your code, your containers and your scans. That causes repeated work that also causes frictions and misalignments. So having the security a part of when you're doing that minimal viable changes is really, really key. So having that in every little commit in GitLab, we have the SAS, DAS, dependency scanning, container scanning and license management for every little, little change of the code that you do. So later when a team is actually in that stage almost bridging between development and production, you're not actually wasting time of figuring out of the container that you didn't scan or the code that needs different sort of scanning and the security team is, and the developers have a lot of friction on it. So having that automatic security a part of your code is again key. The other part is, which is very, very important is having a sense of review, of a sense of imagination of what you're developing, what it actually might look in production. And so starting small and then keep on reviewing with all the different changes of how your little review impacts the larger picture. So review apps are key to actually help in that transformation and automatically help in building those softwares. Again, a simple thing, but very, very key to this transformation journey. We've talked a little bit of actually going code as a infrastructure, but why is this really, really important at this stage? The way we do software now, we're not only building one or two software, we are building, we have billions and billions of lines of codes written in total on a yearly basis. So, and it's just gonna get scaled and scaled and scale more. So having code as an infrastructure, packaging it makes it just easier to deploy, whether you're doing in Canary or whether you're doing it in Kubernetes, but having a concept of actually packaging and containerizing it. So it's just easy. It's just a shift from development to production or deployment makes things a lot more easier. So that is again, fundamentals of dropping the cost in the digital transformation journey. So we've talked about the whole process and everything. Now, the other part is monitoring and having insights into every stage of the cycle. So there is developer insights that goes into how your code is doing, what about your repository, contribution charts, but then there is productivity insights into, when is your code getting reviewed? Sorry about that. What about your group analysis? Who are in your groups? How many times are they pushing codes? Similarly, with your operation of your application, so whether it's environments, community environments or any sort of dashboards that helps with through that monitoring of from the planning stage to the defending stage. And then you need security reports which goes into vulnerability and container scannies and how you're performing on a daily basis. These sort of insights helps better in your roadmap of actually understanding how well, where, what part is time consuming? What part is expensive? What part can you improvise? Very, very key to actually getting better and better in the digitalization journey and dropping the cost proactively rather than reactively. So similar insights across all missions, these are all the various kinds of dashboards that you can get from road mats to canvads to your CI CD to productive, to groups and projects and sites, all of that put together. So to link and sum it up as to the little techniques that we've seen, we have cost saving strategies to, that helps with flattening it, scaling it, automating it, monitoring it. Sorry about that. I'm just gonna take a little bit of a water break. Sorry about that. So we've looked into these different strategies, of scaling it, automating it, monitoring and defending it and to look into the techniques that we've seen through DevOps. Just a summary of what we saw is using boards for collaboration, scaling, scaling easy with infrastructure as code, automating, using your CI pipelines, which extends to security, to assembly lines, to machine learning, to whatever part of the journey you are at your software cycle, monitoring it through lock tracking, visibility and insights across all missions and defending that through security through every step of the way. Now, these are the all the tactics that one can use. In GitLab, this is all done through one software. It's not three, four different tools. We've had people poll that they use, I think it was 25% use more than five tools and that can be very, very confusing and it's hard to integrate. In GitLab, we believe that you can do it all through this one single application where a developer, a security person, a product manager, they all can speak the same language without wondering if there is friction or misalignment and the software can be synchronously seamlessly developed. And then similarly, in Git, we use GitOps to actually reduce that friction. This is just an example of what we talked about that once you have your task aligned, the developer creates the issue, creates a merge request. You commit your change that triggers the CI pipeline. Once you've done the change, the app is reviewed and then there is a discussion you can have with the product owner, scrum master, QA engineers. Your changes are approved and it goes into the delivery cycle where every step of the way is monitored. This is how one can actually help with the simplified flattening, scaling, automating, monitoring, defending, cost saving strategies. So all in all, to reduce that technical depth, concurrent DevOps is what makes it happen. So there are three ways of looking into it. Concurrent DevOps is visible. Everyone knows what is happening at what stage. It is not synchronous. So you can manage and improve your cycle time. It's efficient, so there is no hand over time. So people can work immediately and it's governed all through the way to make it simplified and you can act with certainty which is the key to digital transformation. So cheap, almost automated decision-making where you can act with certainty with every part of it governed. So with that, I would want to put it all together back to actually where we started. So we started with a very futuristic person on Professor Daniel Kahneman and his story. And then we went through a little bit journey on little tips in the DevOps cycle one can use to actually help drop that cost. But there is some sort of a dissonance still in every software development cycle. In one hand you have autonomous cars, you have Siri and they feel they are a little bit more advanced. They've proven the point of digitization. But, and then you have the futuristic people but there is no way there is still a struggle in reconciling this and using these technologies in our everyday life, in our everyday work. And so there is a dissonance in these two different thoughts of minds. And the way I would like to end it is that that goes back to the ops of digital transformation, which is nothing but a thesis of time. So the more you dial up, it's like a knob. So the more you dial up the accuracy of digital transformation, the cheaper your current strategy becomes. And this is not just for Google and Microsoft and Teslas, Netflix, this is just for everybody. And once you get better and better at it, you not only execute the current strategy but you actually reinvent a new strategy like they saw in mobile phones. It reinvented the smartphones reinvented the way we look into communication. So for example, if let's say the Amazon recommendation engine, right now it's 20% accurate once you've bought three pairs of sneakers, it can recommend you write one. So it's around 20 to 30% accurate. And let's say it gets more data and then it gets more automatic and the infrastructure gets better and better and the accuracy dials up to 95%. And instead of, once it gets to 95%, now what can happen after that? So theoretically, hypothetically, Amazon can then decide that they can ship you the shoes before you buy them. And then you choose if you want to keep it or not. Now that's a hypothetical situation but that actually shows how you actually not only help with your current strategy but you actually reinvent that strategy. So with that, I do want to conclude that at the end digital transformation, there are tips for DevOps but it is a thesis of time and it is about humans, how we want to use and enable us with all the existing technology to creatively reduce the cost to this journey together. So that's it for me. Thank you so much for joining and your feedback is appreciated. So there is a link to it. I will post that on the chat and I'm up for questions. Hey, Mon, Peter here. Thank you so much for presenting that. We do have three questions that have been asked throughout the webinar. So first question from Eldren is how to reduce the learning curve for the teams on CI CD? How to reduce the learning curve? I think it again starts with first small. Firstly, understanding where your team is currently at. Now the CI CD tool, what kind of different people are part of it? So the CI CD might feel very different to a security, to a developer, to even a machine learning scientist. So having a common line, having a common language that can actually help contribute. So a single tool, single application is a good start and having minimal viable changes when you are enabling that education is again a good start. So flattening it, simplifying the tool process of it and being able to integrate it into their current ecosystem of tools as well. Great, second question from Ammar is, is the code analysis quality supported for different programming languages like MATLAB? Yes, so happy to share that as well. Yes, the code analysis is, we do support a lot of different languages through it. We do support obviously MATLAB, not yet for it, it's also based on how many people are actually using it. So it depends on what you're using for. So let's say you're using MATLAB for machine learning, there is, it is not a plugin, but we can actually have that as a part embedded. But in general, let's say if you're a Python quarter, a Java quarter, a Go quarter, that's all a part of that plugins. Great, next question is, how does code analysis compare with the likes of SonarCube and Synopsys? How is the vulnerability database maintained and how often is it updated? Yeah, good question. So we are, our code analysis is open sourced. So it's based on everything that is open sourced. It is updated on a regular basis. So it is all automatically updated pretty much instantly based on the open source resources as well. So, and then it is reviewed as well on an instant basis. So it is a part of our CI CD pipeline and the review and the updates are pretty much instant. Right, we've got a few questions or a few people have asked about the recording of the webinar. So yes, it is recorded and the link will be shared along with the slides. Couple more questions, Mon. Do we need to check in all dependencies for automated build or can you get it from package manager? We can get it from package manager. Great. And another question, does the CI CD features require additional components or plugins for .NET core applications? We do support .NET. You do not need any other plugin for it. So our web ID and our CI CD can actually handle that. Yep. Okay, great. And we've got a question from Nikhil about interactive. Is there an interactive learning section part of GitLab or a GitLab tour in Glend's responded to that? So Glend will reach out to you in terms of, I guess, further knowledge sharing. And anyone else that's interested, we can also send you some links and details on that as well. There's another question. How would you recommend an older vintage developer to start adopting CI CD? When I started learning, even test driven development wasn't a thing. And now it is hard to get the time to go back and relearn these new foundations. I think, well, firstly, I wanna answer it by saying, it's a little bit easier to be honest. So I've been a data scientist and I don't know neural networks as well as my grandma or actually my dad as well. But I know how to apply it. So I think your experience is actually very key because you know the fundamentals. But once, I think there is like, maybe a little bit more on the experience that is a lot different. So that might take a little bit of that learning curve like a month of actually understanding what is that application. But once you get that, you're probably a lot more in a better place than any of us. And I think a lot of these tools there, whether it's CI CD or any, it is getting more user friendly. So it is time to adhere to audiences that are not just developers. So it is also changing the way one actually enables and understands. So you're much more closer to the journey than any of any new school people to actually understand and get better and learn it faster. But one key thing I would probably kind of say is instead of actually a lot of the courses that there are, they go straight into the application rather than actually the fundamentals. Just knowing that full fundamentals of CI CD can sometimes help as well. And if needed, we can recommend courses as well. Right, thanks a lot, Mon. And then the final question, is there a good set of resources to get started with trialling and prototyping GitLab? Yes, so absolutely. So GitLab is all transparent. So we have an unfiltered YouTube channel that goes through a lot of different techniques, a lot of different, how do you actually start with GitLab? We have a full, very transparent handbook as well that goes a lot detailed. It depends on the style you are. If you wanna have videos or do you wanna just read through? And yes, so that's a great place to actually start. And whenever you have any questions, you can literally raise an issue to us. And there is a page in the handbook that goes how we do it. And we will respond right away. Good, another question that's come through from Venkata. Our clients use proper monitoring tools like AppDynamics. Will it be possible to integrate with GitLab? If so, can that be, can we get a unified dashboard? Yeah, so it can be totally integrated to GitLab. Now, for the unified dashboard, we have the GitLab. It depends on if you want metrics out of the AppDynamics or any other tool. The GitLab metrics that can have the dashboards and we also have an API so, and you can take that. Now to have the unified dashboard, the best probably practice is taking the GitLab API as well as your other tool API and be able to integrate it and have the unified dashboard. That can be fully done. It is not a plugin because we don't know what tools you might be using. It can be integrated but that can also be created, a dashboard because the API is pretty easy to use. Great, thanks for that. That was the last question. Yanesh, we'll have a team member reach out to you for further information. We'll also be following up with everybody that joined the session today with the link to really recording. Really appreciate your time. Thank you, Mindful, running for a great presentation. We had heaps of great positive feedback along the way. So I appreciate everyone's time and we are running our next one again next month. So be on the lookout for invitation for our next webinar in August. Thank you very much. Thanks. Bye.