DevOps: The Basic Concepts I suppose my first blog post should help explain the basic concepts of DevOps in simple English. However, someone has already created an excellent video on that account. No use in recreating the wheel. See transcript and video at link Meet Dave. Dave works for a company whose success is contingent on its ability to offer new and exciting products to its online customers faster than competitors. Dave is a developer, who writes code for new products, new features, security updates and bug fixes. Unfortunately, he needs to wait weeks for his work to be placed into production. This delay increases the pressure of staying competitive because some competitors are able to deploy new products and features much faster. In addition, the delay makes it very challenging for Dave to manage both the code that is pending to be pushed into production and the development of the next product and/or feature that he is responsible for producing. When Dave’s code is finally deployed into the production environment, occasionally unforeseen errors or problems occur. This mostly happens because Dave is focused on writing code for his Development Environment and it’s not identical to the Production Environment. Meet Dave’s coworker Anna! She’s a System Administrator from the Operations team. She is responsible for maintaining and assuring the uptime of the Production Environment. The number of servers that she needs to administer is constantly growing because her company continues to launch new products and customers are consuming more of their services. This increase in servers has caused some challenges for Anna. The tools that she used to administer a few servers are not as effective when used to administer a much larger volume of servers. This challenge affects how new code is deployed in her production environment. Usually, when new code is released it takes a little massaging to fit into her environment. This is why she requires code deployments to be scheduled and are only allowed once a month. Once the new code is actually deployed, it’s her responsibility to diagnoses any errors or problems caused by the changes. Sometimes to her, it feels as though the Developers have tossed their work over the wall to her and her team. So, What can be done to help Dave and Anna work better? Ultimately, they want the same thing, happy customers! What if Dave the Developer and Anna from Operations * Worked better together? * Thought more alike? * Broke down silos? * Shared responsibilities? This would require them to change their mindset on how DEV and Ops work. DevOp Stages: Basic Concepts DevOps integrates developers and operations teams in order to improve collaboration and productivity, by automating infrastructure, automating workflows and continuously measuring application performance. If Anna’s and Dave’s teams were more DevOps oriented, they would do a few things differently. They would place more focus on automation. DevOps teams try to automate everything from testing of new code to how infrastructure is provisioned. They would write software in small chunks that are integrated, tested, monitored and deployed usually in hours, versus the traditional way of writing large chunks of software over weeks or months to then do weeks or months of testing. Plus they will have identical development and production environments based on the same configurations. Writing small chunks of the software will allow them to increase the frequency of the deployments and improve the time to deploy new code. It also enables them to adopt an iterative process to monitor, measure and improve the code and operations every day. Improve their ability to respond to market needs, or other things that impact software. Instead of building and configuring software plus infrastructure manually on an ad-hoc basis, Anna’s and Dave’s teams would write Configuration Management Code that describes how things should be built. As a result, they will have the ability to build infrastructure at scale to dozens, hundreds or even thousands of servers), in multiple locations, using different types of hardware. Another change that a DevOps oriented team would do, is to use a source control system to help manage and document all of the changes to both the Application Code and Configuration Management Code. The change that Anna and Dave would implement is to adopt a discipline of application performance monitoring and optimization in almost real-time. This will allow Dave and the rest of his developers to understand the performance impact of their changes. The ultimate goal is to have a Production Environment that gives their customers a great experience. So what benefits does having a DevOps-oriented team give Anna’s and Dave’s company? Well, it allows them to increase the rate of Software Delivery and improves the company’s ‘Time to Market’ potentially from Months and Weeks to Days and Hours. This will be a huge competitive advantage. It also allows them to maintain better Business Focus by automating their infrastructure so they can focus on things that improve the business and their online content. They will spend more time on the things that add more value to their organizations When a company is able to build and offer better products, this means they have happier customers, and happier developers. How does a DevOps oriented team actually accomplish this? Well as mentioned before, a culture change is needed, or changes in the mindsets of the two groups that need to work closer together. The other component to the formula is getting the right tools. New tools are needed in this new fast pace world. They will need a tool that allows them to test their code and programs. An example of this is Jenkins. They will need a tool for Source Control such as GitHub. This will allow them to manage and document all the changes to their Application Code and their Configuration Management Code. They will need tools for Configuration Management, such as Chef, Puppet and Saltstack. These tools will allow them to deploy applications in an automated fashion, maybe across hundreds or thousands of servers in different locations. They will also need new tools that allow them to continuously measure the performance of their environment. Generating, reading and analyzing system logs is extremely helpful to monitor an environment; but now that many environments have hundreds or thousands of servers, new tools like new relic are required to make sense on all the data.This will allow them to know how the entire application is performing and identify bottlenecks. But many companies don’t know how to use these new tools or do not have the skills to automate the software delivery process. In Conclusion, DevOps is a new philosophy that can help software organizations innovate faster and be more responsive to business needs. It promotes collaboration between developers and operations, which improves quality or software deployments, and more frequent software releases. Adopting a DevOps philosophy requires a new mindset, new tools, and new skills.