DevOps: a story about automation, open source & the Cloud

Editor's Notes

• #6: Developers are going to come out with the idea, they are going to implement the idea, they are going to take the code that they write and then build it, test it, put it through the release process until it finally gets out into production where your customers can use it Every new feature that you build into your application is going to go through that lifecycle After your customers can get their hands on it, you can start to learn from it Development team can look at the customer usage data from the application, they can get feedback from the customer and they can start to plan and take educated decisions on what they want to do next 2 Important things to note about this development lifecycle First: The speed of the completing that loop (to build a new feature and to get it into the hands of your customers and have your customers start using it and learning from their usage) – the speed of completing that loop determines your business agility The faster we’re able to iterate through the loop, the more responsive you will be to customers and the quicker you will be able to innovate We need to focus on improving that loop as quickly as we can Second thing to note: Developers are adding value to the customer when they are working on the left side, writing new code and building new features Any time the developers spend in the middle of this diagram, all of this time will be lost in the eyes of the customer. Either building the delivery pipeline or handholding changes through that pipeline, all of that time will be lost in the eyes of your customers So what you want to do is maximize your time your developers are writing new features and minimize the time developers are spending in the middle
• #7: And it’s really those 2 things that make the heart of the DevOps, the heart of DevOps is any efficiencies you might make, that can you drive, that helps you loop through this faster. And this is why it’s so confusing to implement DevOps. There are many things you can do here. You can make organizational changes, cultural changes, process changes, tool changes and I think that’s okay, anything that you can use to make improvements to this delivery pipeline and feedback loop count as DevOps
• #8: To make this more concrete, this is a backstory from Amazon’s transformation to DevOps Like most companies, Amazon did not start out using a fully DevOps approach. It did not start out that way. In fact, if you go back to 2001, the Amazon.com retail website was architected as a large monolith, even thought it had multiple tiers and the tiers had many components within them, everything was tightly coupled where they behaved like one big monolith. A lot of start-ups and even projects inside big companies take a monolith-first approach because it’s very easy to get moving quickly, but over time as that project matures, as you add more developers to it, and as the architecture matures, that monolith is going to add overhead into your process and the software development lifecycle is going to begin to slow down. To depict how this was affecting Amazon and actually companies that I’ve worked for in the past, this is how a software development lifecycle for a large monolithic application looks like
• #9: So what we have with a large monolithic app is a very large number of developers working on this one BIG monolithic website, many more that could possibly fit on this slide And even though each one of these developers is working on a very small piece of that application, they still need to bite of the overhead of coordinating those changes with everyone working on that application If a developer is adding a new feature, making a bug fix, they need to make sure that feature is not going to break someone else on that project If they want to upgrade a shared library to take advantage of a new feature, they need to convince everyone working on that application to upgrade to the new shared library at the same time AND If they want to make a quick fix to push out to their customers quickly, they can just do it on their own schedule, they are going to need to coordinate that with all the other developers that have in-process changes at the same time And this leads to something of the effect of a Merge Friday or even a merge week where all the developers take all their in-process changes, merge them together into 1 version, resolve all their conflicts and finally create a master version ready to move out into production And even when you have that big large new version, it still adds a lot of overhead into the delivery pipeline, that whole new codebase needs to be rebuilt All the test cases need to be re-run, and then you need to take this big application and deploy it to your production fleet of instances At some companies, there are even engineering teams whose sole job is to manually push this versions of the application (those new changes) and push them them to production This was adding a lot of overhead, not only to the delivery process, but also impacting the developers it was slowing down the software development lifecycle - our ability to innovate
• #10: The first change to make is the architectural change You need to go through this monolithic application and piece it apart into at the time of Amazon re-architecture something at the time of the re-architecture was called Service-Oriented Architecture (SOA) and today, you could consider microservices You have to go through the code and pull out functional units that serve a single-purpose and wrapped them with a Web Service interface like a RESTful interface Some single purpose service that Amazon used was a service whose sole job it was to render the “Buy” button correctly on the product’s detail pages Amazon also had a single purpose service whose sole job was to calculate the tax correctly on the checkout page So when we create these single purpose services, I would also recommend to set a rule in place, like Amazon did, where the services could only talk to each other through the web service APIs. There is no back-end shared access allowed This enables you to create highly decoupled architecture so that services could iterate independently from one another, without any coordination between the services, as long as they adhere to that standard of web service interface To give you an idea of what Amazon’s microservice architecture looks like, this is a graphic around the year 2009 where it represents Amazon.com’s retail website and all the individual services that make up that experience. Back then, Amazon didn’t have the term called Microservices, but today we would call this microservices architecture
• #11: In addition to that architectural change, you need to make an organizational change Before you had one central hierarchal product development team You need to break that apart as well, in order to break it up into small what some companies like Amazon call “two-pizza teams” The idea behind that name is that you want the teams to be small enough so that you can feed them with just 2 pizzas. Each of these teams were given full ownership to one or maybe a few of these microservices And when I mean full ownership, they would own everything, including talking to customers, whether that would be internal or external, they own defining their features, roadmap, designing their features, implementing them, writing the tests for them, deploying those services into production and also operating those services If anything went wrong anywhere in that full lifecycle, they were the ones accountable for fixing it If a team chose to not to develop the proper amount of tests and that caused releasing bad changes, even unknowingly into production, it was the same engineers that were paged to fix them during the middle of the night That leads to properly aligning incentives so the engineering team was fully motivated so that the entire end-to-end lifecycle operated efficiently This is what you would call a DevOps organization, because they took those responsibilities of development and test and operations and merge those all into a single engineering team
• #13: This problem was that humans make mistakes. Releasing code and/or Infrastructure manually is filled with human error, which brings inconsistencies The solution would be automation, as it would bring consistency of outcome (sometimes it even saves us time).
• #14: Finally, I really like this depiction of needing to go from this (assembling everything in a car manually) To going to the completely automated assembly of cars using autonomous robots So now we need to focus on the robot part or the toolset we are going to use in order to improve the delivery and deployment pipeline in order to improve our ability to innovate
• #28: With the explosion of technologies available to organizations, the choice of technology platform is cripplingly hard. Kubernetes, OpenShift, GKE, containers, cloud-native, microservices, devops, agile, automation, … (it is exhausting) Organizations are not equipped to make most of these decisions… But they are being forced to...