 So, good morning, everyone. Welcome to this workshop with GitLab. It is called the Art and Craft of DevOps. I do see we have around 67, almost 69 people joined in. I'm Monmiri Ray. I am part of the Customer Success Team within GitLab and in APAC. I basically help develop pre-sales solutions when it comes to DevOps or MLops for our customers. So, with that, I will go into the agenda. So, we're here for an hour. And in this one hour, we'll probably just go to a rough intro, a little bit of history on the journey of DevOps, understanding the economic lens. Then we'll go through a little bit of an experiment, a real world one. The Art and Craft of it, which is the topic and the revolution of it. Us as humans, how we play in this DevOps revolution processes and tools to help us enable in this revolution. And finally, GitLab and how we are in this journey with an Art and Craft of it. So, just to begin with, DevOps, it's everywhere. Whether it's in your app development, to any technology to actually even deploying machine learning, it's everywhere. And currently, what people are more looking for and where you are going to accelerate is actually the excellence of it. And to get to that in GitLab, we feel everyone can contribute. So, going back to actually where it all started. Now, Patrick Debois, and apologies if I can't pronounce exactly right, but anyways, he's considered the father of this terminology DevOps. It started around 2008, mainly because of the concept of how IT or around that time was so very siloed in. And there were so many apps specifically, iOS apps that they wanted to go productionized. And they needed a framework to actually think about, okay, what would be a way for all humans to come together, change the whole culture of IT and collaborate together. So, it's 11 years old DevOps, and it's still growing and maturing and iterating and getting better every day. So, that happened 2008, 2009, it sort of peaked. And then came to 2011 and 2012, where then the economist was like, yeah, this agile way of working, fast iteration, but what does that actually mean from a value perspective? So, economists, when they look into something, they look at it as demand supply. So, it's very simple. What they see is a certain price drop of something means more consumption of that and less consumption of something else. And so, let's say for example, tea. So, a drop in price of tea means people will buy more of tea, less of actually coffee, and also anything that complements your tea, like our sugar or milk, more of that. So, what does that mean for in reference to technology? So, when mobile phones actually came out, what was considered from an economist's point of view was actually a drop in price of communication. So, similarly with AI, it's actually considered just very simple drop in price of machine prediction that substitutes human prediction and data is actually the complement of that machine prediction. So, for DevOps, it's even simpler. It's actually the drop in price of transaction cost within the product teams. So, that actually is substituted by all the siloed teams and it's complemented by human judgment and automation. So, from an economist's perspective, it's just that drop of friction cost and transaction cost and complemented by automation and human judgment. So, having a good understanding of that value in simple form within GitLab, this is how simple it can go. What is that whole cycle of DevOps? It's an infinite loop which goes all the way from planning to ideating an idea to going all the way into actually the producing and the production of it through all these various steps to creating, to verifying, packaging, releasing, configuring, monitoring it with security in the development and defending in the operation side of it and a whole management lying on top of this infinite loop with every step, iterating, feeding back and getting better all through that infinite loop. So, that is in nutshell the whole lifecycle of DevOps. So, now we have a little bit understanding of that value and infinite loop. I want to go into a little bit of an experiment in a real-world scenario. So, now with COVID, I think everyone is watching a lot of movies, streaming a lot of YouTube, Netflix, Amazon Prime. So, this is actually an example of a movie streaming engine and the process that actually flows with it. So, traditionally, this is a company where the developers, they built a local streaming engine and then they moved to MVP and then to production. The operations team then it's like, great, now this is ready to produce. So, we go into cloud and deploy it and scale it up and so then the viewers can then enjoy the movie. The viewers, if sometimes if there's too many people joining in or not, they might actually have trouble streaming it, might have quality problems or they might actually love the movie and they send the feedback after seeing and going through that experience. The developers look into that, work on the feedback and the sort of cycle continues. Seems fair, seems reasonable, but how can we do it better? So then, what happens is initially, yes, the local streaming engine is built, ready for production, the operations team goes into cloud, but then what the developers and operations team come together and do is before the viewers actually watch it, they actually force failures, different failure scenarios into that production environment to actually be able to test all kinds of possible scenarios before the users actually come and feedback all the sort of complain whether it's the quality or streaming or slow processing or whatever it is. So, every possible failure injected into it, iterated and concurrently the viewers watch it. This phenomena is called chaos engineering and the viewers then go to it and then later, most of the feedback that comes is happy feedback and continuously it gets happier and happier and happier. This real-world example is actually a real-world example of Netflix. This happened around 2012 where they actually set up a building for failure or rather failure as a service where they injected failure through this chaos monkey too. And disabled their production instances to actually be able to survive any sort of common type of failure which they had collected through time as well so that the customers are not impacted. Now, how do they actually do that? So, I did have an opportunity to actually go through that process with them and the easiest answer they had is actually having the whole DevOps culture where they promote those frequent releases, high automation, software reliability and have those motivations and objects to celebrate it through the wider audience with their larger business team that helps with promote the stability and the upgradability of the applications. So, the greater goals with actually thriving the business and going back to the customer success is easier achieved with this faster adaption of that DevOps culture. So, it goes back to actually then the topic, the art and craft of DevOps. Yes, we have tools. Everybody loves our tools. We have source code management, team size, continuous CI CD, continuous integration, continuous delivery, continuous security, coding, clouds, AI, platform, all of it. But there is a whole human aspect to DevOps or the art of DevOps that is being able to creatively use the existing tools, use the existing historic existing data to innovate the strategy just the way as in that experiment to look into failure as a service was actually a creative way of embracing the DevOps culture and being able to collaborate it together and make a unified decision without being siloed. So, that is the art of DevOps. Now, to be able to embrace the art, there are a lot of changes that actually needs to go. And similar to actually the time we live, there is changes that goes from localization to in a historic era we actually live in this post-modern globalized world. So similar in DevOps, the old way of going into from siloed teams that needs to be a cross-functional team or even one unit of building products together, monoliths to microservices, manual test and release to automated test and release, manual configuration to infrastructure as code, team-defined toolings to tool standardization and rather than annual release, more frequent, small iterative releases. So to talk about how we would actually embrace those changes, I'll talk about the first part which is siloed team to cross-functional teams. And so the humans and teams in this revolution. This is a report from actually McKinsey, where they actually talk about how the future with automation is going to impact the basic genuine skills in getting your test done. So obviously the physical manual skills is going to come down. Your social and emotional skills is going to get really, really high and you're going to have so many tools so being able to adapt and learn through it is actually going to get higher from 70 to 113. So when we look at the human skills and developers, from in the next 10 years, your problem-solving skill needs to be eight times better. Your collaboration, interdependency, the adaptive continuous learning, all around 65 acts, multitasking, leadership, empathy, all of it needs to get better and better and better. Now, that's an individual. So how does a whole team or an organization get to that level to help in that revolution? So how do we go from this localized silo to this globalized, visible, transparent, iterative, collaborative teams? To be able to do that, I will go now into actually certain processes and tools that can help you into that globalized collaborative world. So the summary of the tools, firstly, it'll be talking about tools that help you in collaboration, tools that can help you make fast, small changes, pipelines and automation, infrastructure and code and general practices and how in GitLab we always improve. So change in communication experiences. First and foremost, it has to be open, it has to be inviting and everyone collaborate together. So in GitLab, we use Slack for it, where there are certain teams and certain topics to be able to actually get right into the information. There needs to be a balance of asynchronous and synchronous where you have to have the liberty to have asynchronous conversation but when it comes to the customers, be able to actually act on and jump on actively. So all about the little, little changes slowly, slowly as the organization making that slow process and having the framework done before even actually starting building those software. From private to shared documents. This has been a lot of shift for a lot of people and in many people, they still actually send documents in emails and then there is a little bit down the lane, no track of visibility and transparency, very small changes, having a shared document for the collaboration of meetings or agendas and having that visibility, transparency to be able to lower the friction is also key to the DevOps culture. Now boards, we're getting a little bit flavor of what a GitLab issue board actually looks like. They are amazing. They started off from actually can bans. It was a Japanese method but they are just amazing for getting all sorts of stakeholders, team members starting to plan a project all the way from the idea to production and you can make it as complex and as creative and as much as needed as a team or an organization. You can have like say in this board we have open portfolio management issues and labels. You can have any sort of ways that helps you in that workflow. You can have labels where you can put as it's in development or it's in planning as it's needed for an organization. So it gives the whole team transparency, visibility, responsibility as well and giving the milestones and roadmaps as well as to actually understand how you're actually performing to be is literally another step to making DevOps easier. Here we see actually within GitLab, this is actually an issue where another good example of how we've actually collaborated. So this collaboration is not even internal. This is an external stakeholder who actually wanted a change in a product. So he wanted this cumulative flow diagram that he wanted in his visual health office workflow. Our product team was able to incorporate that and be able to actually revisit it and actually help him with his request. So again, the openness shouldn't just be internal, the external openness of actually listening to the audience and taking that feedback and being able to collaborate to make your software better is also another key lesson for DevOps. So back to the same kind of points in collaboration sharing visibility. So now that we actually have a good understanding of kind of setting the idea of planning. That's kind of what we did. All the things, all the tools that we actually needed to planning. That's great. Now we actually start building and how do we actually start building? Everyone's probably heard of MVP, the minimal viable product. It's for, I think someone called Eric Rees, I think so, who started with that lean startup idea of building this sort of MVPs before actually productionizing. Now we believe that even before MVP, it's too big. How about we actually look into just features of the product, certain little, little step and that can actually get it better and better. And even sometimes features are actually big. So how about MVC? So just minimal viable changes. Little, little changes to the software to be able to unlock the velocity, take the feedback quickly and change it accordingly and keep on building the MVCs till we get to a good feature, till we get to a good product. And that's kind of the little, little steps that go from planning to building to then the later, later stages. Now we've done the planning part and then we've slowly started doing the building part. Now, how do we go from that all the way to actually the production part of monitoring it? It is through various different pipelines of automation and integration. All of these boxes from plan to create, to verify, to package, to release, to configure, to monitor, all of it linked in this one pipeline, parts of it automated, like we see package, release, configure, monitor, automated, create, verify and package is all version control. So every time you're creating something, you have the version of what you've created, you've verified it and you've packaged and you've had different various versions of that put together in one platform. And so this pipeline becomes really, really key. Now you might be wondering what is a pipeline and what it actually sort of looks like. So here is an example of a pipeline where it actually goes into a build, prepare, test, post-test, post-cleaning for security. So it goes into all these different, different stages, very again, small steps, small changes of different sort of scannings. So it could be security scans, continuous scans, or it could also be configuration and development, but this is what it sort of looks like. Typical changes and all of that. So if one part of this pipeline doesn't work, you actually know which part and is able to look into the logs, go back, revisit, re-change and restart the pipeline because it's all simple steps and easily all synchronized and can be done easily. Security in that pipeline is very, very, very key. So again, with every security part to it, we recommend at least having the SAS, DAS, dependency scanning, container scanning and license management into that steps of building your applications. Depending on obviously whether you're building app application iOS or there are much more, but these basic scannings need to be part of your every step. So you actually, that can be automated. So as a developer, a full stack developer, you don't need to worry about if you're doing all the steps right and you have a pipeline that actually tells you and guides you to that process that yes, you have vulnerabilities in these areas may consider it. So you as a developer can actually build it quite freely and collaborate as well. And the QA engineer would exactly know where to go for and stop it from getting developed or redefine the whole development process. So now I'm actually kind of going a little bit into deployment. So once we have kind of the MVCs and even MVFs, how do we actually go about this whole deployment? So again, very small, having a good glimpse of what your product might look in the real world, reviewing your apps. So that's a feature that can actually help you get into the pipeline when it's gone through all the security testing to be able to review what your app looks like. This is actually down through containers. So it's linked in GitLab. This is linked into your Kubernetes containers where you can deploy your review apps and actually have a good glimpse of what it looks like before you shift it even into production. So you can make the little changes if you're not happy with it. And that becomes very, very key in actually this fast iterative cycle to just have a glimpse of what it might look like in the real world, make the little changes again, make sure it's perfect, and then shift it off to production. So we're talking about MV, a little bit of the deployments, and that goes back into, again, a part that we talked about in the time to change of infrastructure as code. This is also really, really important where if you have infrastructure as a code, so it's this whole concept of having the full code packaged up as infrastructure makes deployment a lot easier. So a lot of the times, many, many frustrations come from actually a waiting for configuration, misaligns of environments. So when you have something like a code full package as infrastructure, it's easy, you can just deploy anywhere without actually figuring out all your configurations and the environments are okay and everything that needs to be perfect for the deployment. Again, little, little steps that makes your job easier and faster, tools or mechanism or process just to make it seamless. So having a good understanding of all of this, so what are we in GitLab? And it's AtomCraft and what we believe always improve. So we started off in 2011 with source code and issues, so it's just SEM, but then we realized all the different gaps, taken the feedback from all our different customers and kept on building from 2011 to all the way still building, only I have 2019 till here, but trust me, we still keep on building in 2020 of a full life cycle for your DevOps journey. So whether it's all the way from idea to production, every little feature that I've gone through has been taken the feedback implemented of moving just not from source code management, we're gonna take care of your continuous integration to your continuous delivery, to actually analyzing post delivery security all of that put together. So the same boxes how we see in the pipeline, GitLab, what they've done or what we've done is from manage all the way to that production, a single conversation, single data source, a single permission model, single interference, governments and security tool that can enhance your team collaboration and also your lifestyle analytics to how you are performing in every step of the way to one single application. How do we do that? Now concurrent DevOps, it has three teams. The first team is visibility. So real-time view across the entire life cycle. So there's five motors, see everything that matters, stay in the flow, don't wait on thinking and that's really, really key. So don't wait, you can concurrently keep on working on your things, manage projects, not tools. So make the tools as easy as possible, but focus on actually the ideation of the project and making the project better and improve the cycle time. So just getting better and better with the whole end-to-end lifecycle time just faster and faster and easier unlocking the velocity. Efficient, so always start, start now, work together, work with the whole team collaborated and no more of the hand-offs. So lots of people again with concurrent DevOps can work together, not waiting for the developer team to finish and then the operation team to actually work on something. People can actually come together in this one platform and just work all side by side. And another which is a team with all ethical DevOps is governance. So security, auditability, complements, expedite the auditing process through every stages of the cycle is also key. To be able to actually know and not have DevOps as actually a black box. So you know and you're able to act with certainty how the code is deployed, eliminate all sorts of guess words and then have incremental rollout, you may roll out 10%, 20% to understand the impact and reduce the change of impacts. So again, we looked into that feature of reviewer which helps you actually give you that certainty of what you're deploying. So governments is a key to all of this. So for today and tomorrow within GitLab and this is probably not just GitLab, this is extended to in general the teams in DevOps and what our customers are actually looking for based on our customer feedback. A lot of automation. The automation part, it's just gonna get more and more and more integrated into this full lifecycle journey. Continuous integration. So CI in the DevOps world, having all those different lifecycle which seamlessly is a part of automation but integrating with all the different tools and technology to be able to build and package and verify is important. The delivery, similar once you've integrated, CD comes part of the CI, similar pipeline structures of all different various apps integration important. The other part is continuous feedback. So that whole concept of actually then doing into production but aligning it back to business and figuring out the objectives of where and how you can do better that being automated and continuous is also very key. Some of the other topics that are coming at is obviously cloud deploying all your applications and cloud containerization to make like we see having infrastructure code but being able to deploy it fast, easily and be comfortable with what you're deploying with security is also key. So software development is just getting bigger and bigger and bigger. And you have one development to five to 100, 2000. So all of this put together actually gets that software excellence as a new competitor advantage. The sixth part, the AI and ML part of it is actually my favorite one that comes from the background I come from. That becomes a key in actually building all this software as well. So having the historic data to be able to help operationalize a lot of these machine learning applications into the cloud as the DevOps for machine learning or machine learning for DevOps is also key for the next coming years. So with that, that's all I had to share. And I think I'll be open to question. I do actually also have a feedback form which I can actually put in the Q&A. Your feedback is important. It is valuable. So I would love to actually have some feedback. It is not mandatory. So please don't feel pressured, but I'll probably just link this form as well into the Q&A. Now, oh, okay. I see some chat. Okay, here is the form. It is in the chat crew. Now, I'm gonna just go to some of the questions. Are we able to access the recorded presentation after? Uh-oh. I am not sure if I'm the right person for the question. Hopefully someone from Girls in Tech can get back, but okay, there you go. Yes, you can. All right, I would love to have the slide deck afterwards if possible. Yeah, so I think, yeah, that can be shared. I will send a PDF version as well, absolutely. Very informative session, learning quite a bit. Thank you. I'm glad you've learned. Coming from testing background, I would like to know how important QA testers in DevOps can, unless they develop across functions and don't stick to testing alone. So, it is very, very, very important. It's also a field because if you think about it, it's growing exponentially. And there are a lot of different ethical boundaries that suddenly you've never thought about before. You are needing to think. And it also includes with your log data sharing. Are you installing the right packages or things like that? So, it depends on the maturity of your organization of where you are in that cycle, but it is actually going to emerge as a field by itself and you will have people within the DevOps team as just focusing just on QA and testers. So, that is an emerging field. So, from a GitLab perspective, we are building more in the security respect, the auditing of it, the compliance of it. We recognize how important it is and we want to be able to give our customers the tools to be able to do that. So, I think it's a little bit for personal if you want to be all horizontal, but if QA testers are very important, it is and it will just get more and more through the years. I hope that answers the question. Okay, I have another one. What would you like product and US teams to keep in mind when working with DevOps or developers in general? Yes, so that's a good question. So, I think it actually goes back to a little bit of that people skills. So, collaboration and openness is really, really key and actually, so, originally developers, we didn't, when it actually started the sole concept of DevOps. If you think about how it was in 2009 and 2010, it was a lot of, it was just about, and a little bit is still kind of there, but it is just literally these caveman developers who would just sit in silos and they want to do their own thing and code and then don't disturb them and then once they are done and push it to UX or push it to that. But that is sort of changing now and it has to. So, being able to both sides understand your own languages and actually having, let's say agile way, like that Kanban way where both teams are working together simultaneously at the same time is really, really important and then being able to actually a little bit of the UX team understand the DevOps language and a little bit of DevOps understand UX language and having some sort of framework tools to help you translate that language. So, Kanban is a good example, but in general, putting your customer first or the business outcome first is also a good starting point to actually go back and have that conversation. So, it's all about the outcome and that value rather than I'm a DevOps and I'm a UX and we don't speak together if that actually helps. What do you think is the biggest difference in culture and our operation that create a success versus failure environment or good versus bad? So, from a culture's perspective, again, it is that people's skill. So, it goes back to having a clear understanding of the vision, what is the vision? So, in GitLab, the vision is putting the customer first where everyone can contribute and collaborate together. So, having that sort of a vision rather than, oh, I wanna build a, I just, I'm part of a COVID app. So, I wanna build a COVID app. That's great, but what is that vision then? How are you gonna do it? So, that is really, really important. The other part is that art part that we looked into the streaming engine example is being able to actually adapt and continuously learn from your mistakes. So, that part is also, so you have to be open to your own mistakes and be able to creatively solve that problem using your existing tools. So, it is a very iterative world, things that will consistently keep on changing. So, you have to be able to adapt and continuously learn. So, going back to those software skills of those 10 different things that will 10 times be needed is basically what you need to be able to successfully be successful. Yeah, that's about it. I don't see any more questions. Any more questions? Oh, there are questions in the Q and A. Okay. There's a couple more through on chat from Jane Rubry. Jane Rubry. Is that going to read it? Yeah, that would be great. How far away are we from referring to developers as DevOps engineers, where the operations side really become the norm? So, it really, again, it depends a little bit on that organization. There are actually organizations which actually function with operations being the norm, or that the whole DevOps as one unit already. But, and so, the more the DevOps culture gets, reaches the full audience, the more it's going to get more integrated into it. But having said that, in the next 10 years, with all that automation and so many applications getting deployed into production, people will slowly, slowly, slowly get more and more and more into DevOps engineer. And within 10 years, to be honest, I actually don't know where it's going to be. We might actually have a totally new title with so much automation going on that we'll just be actually having more coffees and have a click on button, plan to production all done. So, don't know where that's going to go, but yes, I think right at this moment, there are already that shift happening. It's just going to get accelerated more and more. Yeah. Is there more questions? Any more questions? Did I miss any? I think that's all for questions. It looks like the Recordings Entire Days program will be available through the Git network. Yeah. And yeah, I did send a feedback form. So if everyone wants to fill in, would love to get all the feedback. And yes, we will be sharing all the discussions. And yeah, well, thank you. Oh, thank you. Thank you so much. Well, I hope everyone is safe through COVID, enjoy the rest of the Girls in Tech conferences. And thank you for joining this. Yeah, I'm not sure actually how, I think we get cut at, oh, okay, there are more questions in the live Q&A. Okay, I've got some questions here, Mon. Yeah. Okay, so how do you suggest- I was looking for that. So figuring out all the questions and everything, yeah. So how do you suggest introducing DevOps culture into a company with 750,000 plus people? I'm part of this team who will be leading this change. And the task is daunting to say the least. Would you incremental step change in ways of working be the ideal approach? So set up people with new systems or would it be better to go hard and go fast? Set up multiple systems and bring people into them fresh project by project? So similar, I would do incremental changes. So again, even to set up a culture instead of actually having a full force into it because even being actually sensitive with the way that there will be a lot of fear of aversion. So it's a process change, it's a culture change, the way a person looks into it. So even simple things, right? Like some people are so used to just sending an email and then the rest of the team doesn't have visibility. So having that sort of little, little changes of having that shared platforms, shared documents visibly, so little, little incremental changes. Being very receptive of the general culture now, the current culture now, taking those little, little changes, whether it can be also you try to, try to implement it for a certain application or a certain business unit and actually see if that works. Have a little bit of AB testing of the culture as well, experiment it and see where it kind of goes if it adds value and then slowly, slowly then roll it out, incrementally roll it out to different teams in different times to be able to then go from MVC to MVP. Ken, we've got another question. What would you like product and UX teams to keep in mind when working with DevOps or developers in general? Collaboration. So being very, very open to understanding the language, each other's language, so active listening, collaboration and realizing that at the end of it, you're building one product. You may be two different entities but you're building one product, so being open to it, yeah. Okay, and next one, your swag in the Git swag is amazing. Why do you think DevOps teams should use GitLab over the other providers? So it really, really again depends. Like I said, for us it's a platform where you are not, you're a part of us, because we are a unit team that you can contribute and we can make each other's products better together. So you're not like an external customer, you're a part of us, I think we went through one example of this customer coming and they wanted a change in the product and we were able to do it. So yeah, so going through the DevOps maturity journey, we would be one team together as one unit. And also this is pretty much one platform where you can actually do a full end-to-end DevOps with one tool. So there you go. So you can have more time, just actually brainstorming and figuring out your software excellence and let the tool do a lot of that automation, pipelines and everything going on with it. So yeah, choose GitLab. And that looks like it did for questions at this point. Yeah, any more? I think we'll just give it a minute maybe. That should be it. No more questions? Yeah, I think if no more question, I'm pretty sure people can take 10 minutes back into their lunchtime before their next session. But I'll still be here until 12.15 because I think we're automatically taken out. So I'll be here till 12.15 for any other questions. But if anyone else wants to jump out and have their lunch till the next, please feel free to do so. And thank you so much.