DevSecOps Course for Beginners – API Security

Key Takeaways

Learn the essential concepts of DevSec Ops and why integrating security throughout the software development life cycle is more important than ever. Your instructor, Scott Bllye, brings years of experience in cyber security, DevOps, and API security, and will guide you through the foundations of building secure development practices. You'll learn how DevSec Ops goes beyond just adding security at the end and instead bakes it into every stage from planning and coding to testing and deployment. The course will also highlight the real world stakes of modern cyber threats, the growing importance of API security, and the challenges organizations face in keeping up with rapid development cycles. By the end, you'll have a clear roadmap for making security a core part of your development process. >> Hey there, I'm Dan Barona, co-founder of Apisec University, and I'm excited to welcome you to this free code camp course, Dev Sec Ops, part one, taught by the veteran security engineer, Scott Bllye. Dev Sec Ops is about more than just adding security at the end of the pipeline. It's about baking it into every stage from planning and coding to testing and development. In this course, Scott breaks down what DevSec Ops really is, why it matters, and how to start building it into your own development processes, whether you're a developer, DevOps engineer, or just trying to shift security left. And if you'd like to earn a certificate for completing this course, it's easy. Just go to episcuniversity.com, take a quick assessment, and you can claim your free certificate to share with your team or network. Let's get into it and start building more secure development culture from the ground up. Hello, welcome to the Apisc University course on API security in the world of DevSec Ops. I'm Scott Bllye and I'm going to be your host during this course. I'm the director of security technologies for system integration solutions and I've been there for a little over a year. I run the cyber security professional services business unit. SIS has a long history of about 35 years in professional staffing and security teams placement, DevOps engineers, etc. And prior to being at SIS, I was at nooname security where I ran a number of accounts as a senior technical account manager on the cyber security side of things. And I made sure that customers who made the investment into an API security product had the results that they were looking for in terms of the tooling being used appropriately and collecting the data that they're looking for to achieve the security objective that they need for their security program. Prior to that, I was at AWS where I ran the enterprise support security improvement program. I was also a senior technical account manager there and I ran a number of very large customers AWS operations and the security improvement program was a very interesting security program that I enjoyed quite a lot. What we did was we looked at customers cyber security capabilities holistically from hiring and training through all the way to the very granular aspects of how are you implementing security groups, how are you handling tagging. And what we did is we provide customers with a way to measure their cloud security posture and make informed data-driven decisions about how to adjust their resource allocation from people training software packages that need to be purchased etc. so that they can improve their security posture in a measurable way and they could repeat that process and see how they were doing. So very much assessment based but what it did is it provided a lot of value to customers so they could determine how they need to readjust their priorities. Prior to that I have been the director of IT and cyber security and I also was a consultant and ran my own cyber security and IT consulting business uh in Southern California for about 15 years. So, I like to say I've seen a lot of what can go right and what can go wrong in the IT and cyber security space. I'm very happy about the course that we're going to be teaching here. Now, our agenda, this course is going to be chopped up into three different parts. The first part we're going to be doing today or however long it takes you to get through this course. And starting with the introduction, which I've just completed, we're also going to talk about what are the stakes. Why do we care about this subject matter in the first place? Why dev sec ops? And what do we even mean by that? And why API security? Now, this course is primarily going to be about the DevSec Ops side of things, but we're going to bookend it all with API security because that's what we're really driving toward and then DevOps versus Dev Sec Ops. You can't understand DevSec Ops without understanding DevOps properly first. And then we're going to do the first of our overview into DevSec Ops with the principles that make DevSec Ops relevant and important. Last but not least, it's not all just bits and bites. It's about the people. So, we're going to look at how do people work within a DevSec Ops cultural transformation and what are they trying to achieve and how can you help your organization get there better? And last but not least, contact. how can you get a hold of me and SIS so that we can help you with your security needs or if you have any questions about the course. The future parts are going to be a DevSec Ops deep dive. We're going to look at every single step of the process from planning to feedback and monitoring within the DevSec Ops life cycle for software applications. And then part three, we're going to take that same deep dive and we're going to go even deeper into the API security side of things. This is going to be quite a lengthy course I believe and we're just on part one right now. So without further ado, let's get started. So what are the stakes here? Why do we care about this dev sec ops and API security situation? The truth is we're at war. Cyber breaches are now an active part of armed conflict, if not a leading indicator of physical warfare. Russia's first cyber attack on Ukraine and their power grid occurred in December 2015. fully 7 years before the most recent invasion. China, North Korea, Russia, these are all nation state actors that actively target US government data resources as well as the political parties on both sides of the aisle. But government isn't the primary target. According to Mandant, financial services firms are twice as likely to be targeted as government orgs last year. North Korea funds many of its activities via ransomware payments and the Bitcoin payments that they generate. and organized crime is part and parcel to Russian government activities and this includes cyber crime. Chinese hackers have been exfiltrating intellectual property from US firms for years. The war has come to us whether you're in the US or you're elsewhere as we're seeing Europe is in a destabilized situation. So these problems are everywhere. The government isn't coming to save the day. Let's set aside the latest headlines about CISA and Doge. I'm recording this in summer of 2025. With regard to a breach, there is a fundamental disconnect between law enforcement and their requirements to gather evidence by setting the bait versus the private sector's need to simply stop the bleeding and get back to revenue generating activities at minimal cost. This is before we even touch upon the complexities of international jurisdiction. I'm sure we all know that we can use VPNs and appear like we are anywhere in the world. Not only is the government not coming to help, they're partially responsible for this entire mess. The NSA's stockpile of zeroday attacks that had been paid for in the late 90s and the early 2000s was hacked and stolen and sold on the dark web 10 years ago. That was in 2014, I believe. So, if it seems like attacks are on the rise, they are. The bad guys have access to the same capabilities as the good guys, including AI, for all of their attacks at an unprecedented scale. And they only have to succeed once. The good guys have to win every single time. Now, I know we're talking to a global audience here, so hopefully it's mainly good guys that are going to be watching this, but the truth is that cyber crime now costs 10 trillion annually. According to IBM, the average cost of a data breach is now $4.9 million. But that that breach brings with it not just costs from remediation and fines and consulting fees and the like, but indirect costs like business impact, lost customers, lost IP, lost trust. Don't forget the cost of the free identity protection that we all get about 8 to 10 times a year. Large firms face greater financial risk in the aggregate, but a smaller firm faces greater risk existentially. small and medium-sized businesses are hit more often by total volume and with greater direct impact. In fact, bankruptcy is not off the table. So, for those of us that are attending courses like this and learning about API security and left responsible for securing our organizations, we're the ones left holding the bag. Our code, our applications and infrastructure are the front lines in an economic war where every new innovation that we come up with is a weapon that can be turned against us. So why dev sec ops? The reality is that threat actors cannot breach an organization and steal data or plant ransomware or any of the other activities that they do if there aren't vulnerabilities. So what they're doing is exploiting vulnerabilities. And it's the role of developers and infrastructure managers to control those vulnerabilities either through preventing them from existing in the first place or putting in compensating controls. The success of DevOps over the last 10 years or so in making sure that developers have the ability to get code to market quickly in a very reliable and repeatable way has led to an increase in vulnerability rates. Now, why is that? How did that happen? As developers are able to get code to market faster and faster, the security teams fall further and further behind. Unfortunately, we all know that it is more efficient to fix code problems in dev versus ops. Once code is running in production and you have customers relying upon it, it's incredibly difficult to make those changes and have them not be breaking changes in many cases. So if you can fix those problems in the development cycle prior to release, you're going to end up with a much more satisfying and efficient outcome. The problem is there's about a 1200 to1 ratio of developers to apps engineers and that ratio isn't improving anytime soon. So as a result there's an enormous workload for apps teams to keep up with the pace of innovation and code release that the developers are putting out into the world and they just can't do it. it's not really possible. So when we look at dev sec ops, the concept is applying DevOps principles to security as well and making sure that security is involved with the DevOps process at every stage. We're going to get into more detail about that here pretty soon. But when you start looking at how to accomplish this, it's not just we're going to stand up some tools. It's technology, it's processes, and it's the people that are involved. And then through the course of this program in three parts, we're going to be talking about how to accomplish all of those aspects. And the thing to remember is there's going to be a lot of information that comes at you about DevSec Ops through this course. But don't feel like you have to do all of it at once. It's supposed to be an iterative lift, not a burden. You make one change, get it through your next sprint. Make another change, get it through your next sprint. The process is meant to be one that you take on through cycles. It's part of your daily work to improve the work. And we're talking about exactly what that means shortly. Now, why API security? 85% of web attacks are now API attacks. Gartner predicted a few years ago that APIs were going to become the number one attack vector, and that has now come to pass. Why is that? There's a common phrase that data is the new gold. It's the most valuable resource on the planet. Now, as a result of that, you have an enormous number of mal actors trying to gain access to that data at the exact same time that organizations are trying to monetize that data and get it out to market and sell it to partners, etc., in order to extract the value that they have in the data that they control whether it's an AI application or whether it's traditional data mining or whether it's just selling personal information that you've approved by allowing yourself to be sold every remember anytime you are consuming something that's free you're the product so what you want to do is protect your data and when it comes to the dev sec ops world and to API security with the absence of the perimeter in modern architectures for software where the data itself needs to be the new perimeter. So when APIs have access to data directly the way that they do, we end up with a tremendous attack surface of data that has the ability for malicious actors to be able to take that data and extract it at scale because of the modern software architectures that exist. Think microservices, think serverless architectures, etc. APIs are how all of that communication takes place. And as a result, an API vulnerability and an exploit that takes place in one environment can impact another environment. And that means not just apps that are connected between different functions and services within one organization, but when you're consuming resources from a third party, from a business partner, you can also impact their organization. If the prices that you sell your goods and services for are maliciously changed, that can impact your partner who is consuming those prices through your APIs. So that's just one small example of how you can have a data breach on your side that affects a partner. So that's one of those indirect costs, but it's not just about you anymore. The other thing that's important about APIs, I've had people tell me, "Oh, we have Yeah, we have APIs, but they're all internal. So, we're not really worried about API security." I'd ask you, what about ransomware? That affects internal networks. That affects data servers and backup servers and everything else. Those aren't open to the public. And yet through a lateral movement exploit, once an malicious actor lands on a system, they're able to then pivot and attack another system. APIs have the same problem. If an API is internal, sure, it's behind some protected network. You have various VPC security controls in place like ACL's and security groups and other checks. But that doesn't mean that a lateral movement exploit can't still take advantage of your API infrastructure even for an internal private API. So just because it's internal doesn't mean it's secure. This course isn't going to go into in part one a lot of detail about API security, but I want to make sure that we maintain the reference of API security around this entire conversation over the next several hours as we get into all of this information because API security is where we're driving. But we have a lot of groundwork to cover before we really get into the API security details. Now, as we do that, what I want to do is make sure that we stay focused on the foundation of API security. We're going to be mainly talking about DevSec Ops in this part, but API security I want you to keep in your mind. The four fundamentals are discovery, which is API asset inventory, change detection, network mapping, and reconnaissance. What I mean by that is there's an old saying of if you can't see it, you can't protect it. It's an old adage in the cyber security space and that's absolutely true with APIs as well. One of the fundamental problems with the API ecosystem these days is that organizations have far more APIs in play than they realize. They have no idea how many APIs they have. They don't know how they function, what their purpose is, who owns them, how they're authenticated, etc. The problem is pervasive throughout the entire technology industry. I've seen it with my own eyes. Now, once you see something, once you have discovery under control and you have an inventory, the next step that you want to take is posture management. I typically think of this primarily as vulnerability management. There's more to it than that. It's not just vulnerability of code, it's vulnerabilities in your infrastructure configuration control. And also, how do you prioritize remediation of vulnerabilities once they're discovered? Posture management can also be thought of the first baby step in your shift left process, which is a lot of what people a lot of people think of dev sec ops as shift left, but it's not. There's more to it than that. So, posture management is the first baby step left because a vulnerability hasn't necessarily been exploited yet. So it's the first ship, first step left in the timeline. On the right hand side of that same timeline, you have runtime protection. Did a bad guy do a bad thing at a particular point in time. I've heard people say right of boom. So you have a bad event that's taken place takes place at a certain point in the timeline. To the right of that is everything that takes place after incident response, remediation, getting back to proper business function, etc. Runtime production is responsible for the shift right side of things where you have running workloads in production that are perhaps being exploited or that have abnormal anomalous behavior within the application and within the APIs that consume the application. Runtime protection is how you observe that. So you're detecting and preventing attackers and suspicious behavior in real time. The fourth component of API security and these foundational concepts is active testing. And what I mean by that is essentially dynamic application security testing of your APIs. Remember APIs are about code consumption. So static testing aside from the API spec file, the open API spec file or a postman collection. Aside from those two components that you're going to scan, the API testing that you do is primarily dynamic. It requires a running environment. When you're thinking about shift left, that active testing component is where everything really comes together. So, we're going to talk at length about that and about the various stages that lead up to a testing capability in the DevSec Ops portion of the course that we're going to get into shortly. Active testing is about securing your APIs in dev. That's that shift left motion to stop vulnerabilities for production. Next up, we're going to talk about DevOps. To start to understand Dev Sec Ops, we first have to understand DevOps. DevOps has come about as the primary methodology for releasing code to market faster than ever before and more reliably. So DevOps, as you can see here, we have a diagram that describes the development cycle, a feedback loop here, and an operation cycle with its own feedback loop. And they're connected across each of the two stages of DevOps. You have five individual stages within each cycle. We'll start with the planning phase. Planning is where just as the name implies, you are determining what your software application is going to be. Might be at a bar on a napkin. You're sketching things out. It might be a very lengthy and involved planning stage. When we get to the deep dive on dev sec ops, we'll go in depth on what all of the different steps could be for a planning stage. But the main idea here is that it's before you actually start writing any code. Next up is the development stage. The development stage is where the code actually is written. Your developers are using their idees and they're getting all the code written until they have a functional capable solution. Then build stage is where they are starting to construct the software application into a consumable resource. And then testing is when you're validating that it actually works the way that it's supposed to. Now notice that at the testing stage, the development cycle feeds back into itself. You may conduct a series of tests and determine, ah, this isn't actually working the way that I meant for it to. I need to make some changes or we need to improve performance or we need to prove improve reliability or it may result in inaccurate results garbage in garbage out etc. So you may feed back into a development cycle again. Now in the devops universe this is typically done in sprints where you'll develop, build and test, develop, build and test and eventually you'll have something that's ready for release. And in fact you may have a release candidate. The release candidate begins to exit the development cycle and enter the operations cycle. The operation cycle begins with delivery. Delivery is different than deployment. Delivery is making sure that the code is ready to be deployed. We'll talk more about that in depth later, but it's preparing for deployment. Deployment is actually putting the code into production, excuse me, wherein the code is actually delivered to a customer and is consumable. Next up is operations phase. while you're operating. So the operation cycle includes an operate phase. The operation phase is where your code is running with customers and you're observing the results in the monitoring phase. So operations has a lot of maintenance activities and things like that are involved. Monitoring is about being able to feed that cycle of information of what you're observing back into deployment and you're continually observing what's happening. So the operations phase is also running its own cycle and you may end up running in the operations cycle for quite a long time while nothing's happening in dev or both of these cycles may be running at the same time and you're continually kicking stuff off from one side to the other. Now once your operation cycle has run for a while and you're ready to feed that information, the lessons you've learned back into the overall process, you're back into the planning stage. And that's why these are connected. So they feed back and forth into each other on a continual cycle. Now the beauty of DevOps is that it has enabled us to get code to market fast. It's enabled it to be done reliably. Think about infrastructure as code and lots of other capabilities that come along with the ability to do these things in a very reliable fashion. Modern app teams are able to release code to market as often as thousands of times a day. Companies like Google and Amazon have enormous software development capabilities and because they adhere to DevOps principles, they're able to get code out very fast. Let's talk a little bit about the history of what that looks like and what it means to be able to accomplish this. In order to understand DevOps, we need to talk a bit about software development history and the way that projects used to be managed. Once upon a time, in the olden days, software was delivered on floppy discs and CDROMs and DVDs. More recently, this is before the era of downloading everything and it just all worked. In order to get that product to market on a CDROM, the methodology that was typically used was called waterfall. And what that meant is you had a series of very linear steps that were undertaken. So you have requirements phase, design phase, implementation, testing, and maintenance. And what would happen as a result of that process is you would end up with a very well- definfined CDROM or floppy disc set that was mailed out or available in retail stores for customers to purchase. Now there might be updates that were available etc for download but this was an area when that was not a particularly feasible methodology. Nowadays, agile is the project management philosophy that's in in place more often, and it has a number of advantages. As you can see from the diagram here, you have a more of a cyclical nature that very much resembles the DevOps cycle that we just saw. You start with a backlog of requirements that then moves into an analyze phase. The analyze phase lets you determine what should you be working on. You define what the sprint is going to look like. You design it. you test it and then ultimately it's deployable, right? And you go through that agile phase, that agile process regularly, typically in sprints that last a week, two weeks, a month, however long your sprint cycle is, and you're able to get code to market very quickly, and this is the project management side of things. The advantages of agile over waterfall are speed to market team ownership because your team takes full ownership of the entire development cycle rather than it being done by a committee or having been defined early on by a different team and then your development team is only responsible for the delivery of the code you've been assigned. Your team is involved in the design stage and everything. It's all very much a closelyknit group. Client engagement is much higher in an agile methodology because each sprint you're checking in with the client or the end user in order to determine are we making progress toward the goal. Are there items that need to be updated and changed etc. And then last but not least error remediation because you're going through this testing cycle more quickly. You're able to remediate problems that occur much faster. On the waterfall side the advantages are that it's very linear with testing. So, if you think about something like a rocket launch, once upon a time, waterfall was the way to do that. We'll talk about more about that in just a moment. But if you're going to launch a rocket into space, you better get it right the first time. That was the thinking. As a result, you end up with lots of testing, very expensive, it's slow, but ultimately you get something out that's perfect or as perfect as you can make it. It's very structured, lots of planning steps, and there's a light touch from the client. the client is going to be involved at the early stages in order to determine what are we trying to accomplish and how are we going to get there and then you go away, you do the thing and you come back and you've got a completed activity. The other thing that's good about waterfall is team efficiencies. Your team is only engaged on the part of the work that you need to do at any given time versus agile where the team the entire team is involved the whole process. And last but not le least, one of the advantages of waterfall is sequential deliverables. You know what those deliverables are going to be. you know what order they're going to occur and it all takes place in a certain order. Under certain circumstances, that makes a lot of sense. The traditional thinking was that even made sense for launching rockets. SpaceX has obviously proven that is not necessarily correct. By building inexpensive rockets, launching them, and watching them blow up, and figure out why they blew up, you're able to get rocket development to occur faster. And this has led to a revolution in how a space launch takes place. The other thing that's important to know about waterfall versus agile is that in business speed matters. And so agile's ability to get code to market faster has proven to be a real gamecher. And the other thing that's important that I spent some time at AWS as I mentioned and Amazon is fairly famous for its two pizza team methodology. What's interesting about that is that the two pizza team, the idea is that any team that's responsible for a work product should be able to be fed during a meeting by two pizzas. That means the team size is relatively limited. And if your team grows beyond that two pizza size, you should cut the team up and divide that workload into different groups because you have too many people working on one thing, it should be divided up into smaller chunks of work. We'll talk more about that shortly. What's interesting about how Amazon has done that is it's taken a microervices software architecture approach and applied it to business use to business methodologies. As a result, much of the Amazon business is run like many series of tiny startups. Each business unit is responsible for its own work output. It's responsible for the analysis, the definition, the design, the testing. Everything is very agile. As a result, Amazon's been able to move very quickly. Many other companies follow this methodology as well, but it's a very agile approach toward business as well as software development. Now, we're going to talk more about DevOps, but to talk about DevOps, we're going to talk about manufacturing first. It's important to understand where some of these ideas came from. In the 70s and the early 80s, Toyota was basically beating all of the American auto manufacturers at their own game. They were making cars faster, less expensively, and more reliably than the American manufacturers. And no one could quite figure out how they were doing it. The way they were doing it was the Toyota production system, which was really based on lean manufacturing. Nowadays, we understand what lean manufacturing is, but at the time it was a revolutionary idea. In order to get these ideas out into the world so that American manufacturers could start to take advantage of Toyota's capabilities, there were books written. Some of these were here. The Toyota way was the first. It was written by Jeffrey Liker. But the one that really changed the way that American business worked was a novel called The Gold. And that's what's on screen now. It was written by Eliahu M. Goldrret and it was published in 1984. And instead of being dry business text, it was a novel. It was paced like a thriller about a team that needed to adopt lean manufacturing in order to save the business. Very compelling story characters that you could relate to. People had their own home lives and things like that. Everything you look for in a novel was present in the goal. Yet it take took place in a scenario that popularized this lean manufacturing concept. And one of the important parts about Toyota system is called the andon cord. The andon cord is a cord that was literally hanging by each production station at the Toyota manufacturing plant where if a worker observed a problem of any size or any scale, they could pull the andon cord and the entire assembly line would come to a screeching halt. It did that so that all of the other workers that were the best in their field would come descend upon the problem that had been observed and identify a solution to the problem so that it could be remediated, fed back into the manufacturing process, and then the production line would start again with that problem resolved. As a result, you have fewer and fewer errors, fewer and fewer defects make it out to customers, and you have a more reliable product. This was a revolutionary concept, wildly expensive in the American sense, but Toyota had a different culture and philosophy about how to get product to market. And it was that pride of ownership and pride of work product that really made a big difference. And the Toyota production system is how they were able to accomplish that. Now, as a result of the success of Toyota's process, lean manufacturing and the goal popularizing all of that, lean manufacturing from 1984 until let's say 2020 was absolutely the way to approach business. As a result, you end up with very fast time to market for for products. Just in time, what's the phrase? just in time manufacturing and supply chains where your supplies that you need to build a product arrive just as you need them, which made for very efficient, lean manufacturing approaches that kept costs down, kept supply chains moving freely. That was all great right up until the pandemic basically blew up global supply chains and we discovered there were some problems with that. In the software world, we would define that as a high availability and resilience problem. We'll talk more about that later. But the high avail high availability problem was made very apparent as a result of the pandemic. Now, why am I talking about this Toyota process? Because for many years, it was thought that applying Toyota's lean manufacturing technique didn't make any sense in the world of software. It's not a physical thing. You don't have stuff that needs to get shipped around and it was a different process. Enter the Phoenix Project. In 2013, Jean Kim, Kevin Bear, George Spafford wrote The Phoenix Project, which was a novel based on the goal, but it was about DevOps. It was about software development and release and IT operations. Now, it was primarily focused on the operations side of DevOps. How do you get work done? How do you get things out the door? How do you monitor them? How do you improve processes and procedures? and it was about the overall workflow methodologies. Now, what I have on screen here, not only is the Phoenix Project cover, so you can go find it. I consider it required reading. The goal is background reading, but the Phoenix Project is essentially required reading for anyone that works in software, security, DevOps, any of this. If you haven't read the Phoenix Project, please go read it. The audiobook is available. It's great as well. If you have a commute or just like to have things on, listen to audiobooks or podcasts in the background, please, please get it. It's available at the library, I'm sure, as well. The three most important concepts in the Phoenix project are called the three ways. And now, normally I don't read directly from the screen, but I'm going to make an exception in this place because I feel like these three concepts are important enough that they really define what we're talking about in DevOps and as a result, what we're talking about in Dev Sec Ops. Because again you can't understand dev secc ops without first understanding devops. So the first way is called flow and I'm quoting the first way enables fast left to right flow of work from development to operations to the customer. In order to maximize flow we need to make work visible reduce our batch sizes and intervals of work. Build-in quality by preventing defects from being passed to downstream work centers and constantly optimize for the global goals. By speeding up flow through the technology value stream, we reduce the lead time required to fulfill internal or customer requests, especially the time required to deploy code into the production environment. By doing this, we increase the quality of work as well as our throughput and boost our ability to out experiment the competition. The resulting practices include continuous build integration test and deployment processes, creating environments on demand, limiting work in process WIP, and building systems and organizations that are safe to change. This is from the DevOps handbook, which I'll talk about in just a moment. This is where the flow way is defined very clearly. In the Phoenix project, there are series of conversations that get at this and makes it very easy to absorb. What I'm going to do now is we're going to go back through that whole statement and kind of break it down a little bit and understand it a little more clearly. So the first way enables fast left to right flow of work from development to operations to the customer. So this is talking about that same timeline that we talked about earlier on of shift left and shift right. So the right hand side of the timeline is in the security sense is after something has occurred. In the software development sense, the right side of the timeline is code being released to customers for consumption. Here we're talking about the same thing. Development on the lefth hand side, operations through to the customer on the right hand side. You have the same thing with the DevOps cycle where they're both there. Development is on the left, operations is on the right. Now the first way enabling fast flow from left to right means speed to market. That makes sense. In order to maximize flow, we need to make work visible. Visible meaning transparent. Your teams need to have open communication that so they understand what they're working on. You need to have work streams that are visible to the other teams so everyone has an understanding of what's occurring in any workflow. If you think about Confluence in the Jira software development tool, I'm sorry, the Jira, the software development tool from Atlassian, you have the ability to go look at tickets and see what's being worked on. You have the ability to see the different work streams. It's important to make sure that your teams know what's going on. You reduce your batch sizes and intervals of work. What that means is instead of taking a monolith, a giant project, and working on it all at once and testing it once it's all complete, you break it down smaller and smaller. This is the idea behind microservices. This all works because when you're working on a very tiny piece of code rather than testing all of Windows, if you're just working on the clock, that's something that's much more bite-size that you can test more efficiently in order to make it updatable, maintainable, testable, and releasable. So reducing batch sizes means you're also working on smaller sets of work within that small piece of work. So using the clock analogy, if you're making an update to the way that the clock works, maybe you're just updating the way the second hand moves around, how does it refresh on the screen, etc. Maybe you're working a timer that's part of the clock application, or maybe the timer itself needs to be spun out as a separate application. Constantly reducing your batch size is one of the first ways to achieve fast flow from left to right. Intervals of work. Also, the idea of a sprint. Sprints are typically about two weeks long. Maybe you have longer sprints because you're starting your DevOps transition to get away from waterfall methodologies. You're trying out agile, but you still need to make that adjustment. Maybe your sprints are longer at first. As you make the sprints shorter and shorter, you're automatically going to be making smaller and smaller changes to the code, which means your batch sizes reduce, as well as your interval time between start and stop period for your for your sprint. Next up, build in quality by preventing defects from being passed to downstream work centers. That's the andon chord. When you observe a problem, you stop the line. You fix the problem before it makes its way on. That's the idea in CI/CD pipelines of if a test fails, you don't publish it. It doesn't get to build. It doesn't get to the integration stage because you've stopped that that that build process and the developer has to fix it before it can move on. That's that concept being built into software and constantly optimize for the global goal. So you're always keeping in mind the objective of the organization and your overall project rather than just being focused on your specific work task. Is the idea of not losing sight of the forest for the trees. By speeding up flow through the technology value stream, we reduce the lead time required to fulfill internal or customer requests, especially the time required to deploy code into the production environment. That's the whole idea of moving fast from left or you're getting all of your development and testing work done so that you can make its way to production to service customers whether they're internal or external. By doing this we increase the quality of work as well as our throughput and boost our ability to out experiment the competition. Out experimenting is one of the important concepts here. When you are constantly releasing new ideas and innovations to market, sometimes they're great ideas, sometimes they're not. Amazon's Fire Phone, I think it was called, was an example. They spent a ton of money on it and it was a spectacular failure. But the VP that was in charge of that project once they announced that they were pulling out of it, went to lunch and was the first to arrive with Jeff Bezos there, this is a story that Bezos has told many times. When he arrived, he sat down at the far end of the table because he just expected an absolute tongue lashing because Bezos could be pretty famously difficult. However, Bezos asked him to come sit down at the table next to him and before anybody else got there, he said, "Look, I don't want you to apologize for anything. We made a big swing and it was a miss. But if you don't take the big swing, you never connect. You never hit a home run. You miss 100% of the chances you don't take." So, that was a very important thought for Amazon to be able to have such a large experiment not work out and yet heads didn't roll, etc. What they were able to do was take a lot of the technology that they developed for that Fire phone and they were able to put it into I believe it ended up being a big part of Alexa which obviously was a huge hit and remains so to this day. So the idea of experimentation getting code and features and capabilities to market fast so you can see what works and doesn't work gives organizations a huge advantage. And that advantage sometimes works out sometimes it doesn't. But overall, by getting code to market fast, you're able to try things faster than the competition. That's what gives you an edge in business. And it all starts with the ability to get code to market faster. So each of these things are really about supporting business outcome. And that what it's all about. The resulting practices include continuous build, integration, test, and deployment processes. We'll talk about all of those steps later. Creating environments on demand. This is the idea behind infrastructure as code. Limiting work in progress, WIP. They talk about that a lot in the Phoenix project. It's essentially what's being worked on at any given time. When you have too much happening all at once, it becomes unwieldy. When you reduce that batch size and all of that, you're able to work more efficiently and get things done quicker. And last but not least, building systems and organizations that are safe to change. The operation cycle when work is in production and customers are consuming it. If you have smaller badge sizes and have done all of the things that are necessary on the lefth hand side in development, that means that when you make an update and it goes to production, it's less likely to be a breaking change that will interrupt production for customers. As a result, you're you have a safer environment that you are able to experiment within more easily. You can try something out. And part of that has to do with high availability and resiliency. Is your system going to withstand changes that could be breaking? And also, do you have the ability to do like AB testing and canary testing when you're releasing features so they can be consumed on a more bite-size capacity and by smaller numbers of customers so that if there is a breaking change, it doesn't break everything for everyone, but only for some. So, that's from the DevOps handbook. I haven't talked about the DevOps handbook. It's up next. The DevOps handbook I consider recommended reading. What is essentially a follow-up book to the Phoenix project that was published in 2016. It was written by Jean Kim, Jez Humble, Patrick Dubois, and John Willis. And what it is is really real world case studies of effective DevOps implementations from the people who did it first. So you'll read about folks from Google and Pinterest and eBay who developed a lot of these capabilities and put them into play and what were their real world business use cases. So it's not a novel. It's a project. It's a business management book, but it's very much following on to the same concepts that were made human in the Phoenix project. On this screen, I have the second way. Remember, there are three ways that are talked about in the Phoenix project. The second way is feedback. I mentioned feedback loops earlier on when we were looking at the DevOps cycle. The two things feeding back to each other. The second way is feedback. The second way enables the fast and constant flow of feedback from right to left at all stages of our value stream. It requires that we amplify feedback to prevent problems from happening again or enable faster detection and recovery. By doing this, we create quality at the source and generate or embed knowledge where it is needed. This allows us to create ever safer systems of work where problems are found and fixed long before a catastrophic failure occurs. By seeing problems as they occur and swarming them until effective countermeasures are in place, we continually shorten and amplify our feedback loops, a core tenant of virtually all modern process improvement methodologies. This maximizes the opportunities for our organization to learn and improve. Like I said, from the the DevOps handbook, I'll go through these again quickly. I think the sections of the course so far where I've talked about these concepts should already be fairly clear. So I'll belabor the point. But second way enables the fast and constant flow of feedback from right to left at all stages of our value stream. Remember we're trying to make work flow from left to but the idea of feedback moving from right to left enables the later stages to inform the prior stages. Remember the operation cycle is going and going and it's going to feed back into the development cycle. That feedback loop of all of the learnings from the operations, what happened when the code was running in production, getting back to your development cycle, informs the developers of what should change next. Typically, this looks like tickets in Jira, etc. But the concept is what's important. It requires that we amplify feedback to prevent problems from happening again or enable faster detection and recovery. So, the faster you find a problem on the right or even during testing on the lefth hand side in development, the faster you find a problem, the faster you're able to fix it. That's the idea behind shift left. You want all of your problem detection to happen earlier, including security remediation. We're going to talk about a lot later, but right now it's about these principles of moving problem detection and fixing from right to left. And that requires a feedback mechanism. By doing this, we create quality at the source and generate or embed knowledge where it is needed. So again, getting the developers what they need early on so that they can fix the problem. This allows us to create ever safer systems of work. I talked about that with the experimentation where problems are found and fixed long before a catastrophic failure occurs by seeing problems as they occur and swarming them until effective countermeasures are in place. Remember the andon chord that's the same concept. We continually shorten and amplify our feedback loops. The other thing about the andon chord when applied to modern software development is typically that's going to be a war room. You got a team that establishes a call where everyone is able to get together. You do screen sharing etc. These are techniques that we all use but this is where these ideas come from. We continually shorten and amplify our feedback loops, a core tenant of virtually all modern process improvement methodologies. This maximizes the opportunities for our organization to learn and improve. That feeds into the third way is continual learning and experimentation. Now the third book that I have here which is also recommended reading is the unicorn project. This was published in 2019. It was written by Jean Kim as a solo ever. It is also a novel and it follows the same storyline as the Phoenix project but it's a different team. It's the actual software development team. You remember how I mentioned that the Phoenix project primarily talked about operations and workflow. The Unicorn project primarily deals with the development team that was responsible for all the software that was being written during the events of the Phoenix project. So if you're interested in software development and DevOps, which clearly you are by taking this course, I recommend the Unicorn project as well. Now the third way, continual learning and experimentation. The third way enables the creation of a generative, high trust culture that supports a dynamic, disciplined, and scientific approach to experimentation and risk-taking, facilitating the creation of organizational learning both from our successes and failures. Furthermore, by continually shortening and amplifying our feedback loops, we create ever safer systems of work and are better able to take risks and perform experiments that help us learn faster than our competition and win in the marketplace. also from the DevOps handbook. So this is about the third way. I'll go through it again really quickly. Third way enables the creation of a generative high trust culture that supports a dynamic, disciplined and scientific approach to experimentation and risk-taking. Now the high trust culture, we're going to talk more about this later on, but this is the concept of psychological safety. You trust each other. You trust that if a mistake is made through an experiment that you're not going to end up getting fired for it. That kind of concept. And this is particularly important in the security field. We're going to talk about that a little bit more later. The disciplined scientific approach to experimentation and risk-taking means having data to make decisions about whether or not an experiment is working out or not or whether a risk is worth taking. But you still take that risk. Amazon also has the concept of two-way doors. Some doo