When building and delivering software, DevOps practices, such as automated testing, continuous integration, and continuous delivery, allow organizations to move more quickly by speeding the delivery of quality software features, that increase business value. Infrastructure automation tools, such as Chef, Puppet, and Ansible, allow the application of these practices to compute nodes through server provisioning using software scripts. These scripts are first-class software artifacts that benefit from source code version control, automated testing, continuous integration, and continuous delivery.
Regular readers of this blog will recognize a recurring theme in this series: DevOps is fundamentally about reinforcing desired quality attributes through carefully constructed organizational process, communication, and workflow. When teaching software engineering to graduate students in Carnegie Mellon University's Heinz College, I often spend time discussing well known tech companies and their techniques for managing software engineering and sustainment. These discussions serve as valuable real-world examples for software engineering approaches and associated outcomes, and can serve as excellent case studies for DevOps practitioners. This posting will discuss one of my favorite real-world DevOps case studies: Amazon.
In the post What is DevOps?, we define one of the benefits of DevOps as "collaboration between project team roles." Conversations between team members and the platform on which communication occurs can have a profound impact on that collaboration. Poor or unused communication tools lead to miscommunication, redundant efforts, or faulty implementations. On the other hand, communication tools integrated with the development and operational infrastructures can speed up the delivery of business value to the organization. How a team structures the very infrastructure on which they communicate will directly impact their effectiveness as a team. ChatOps is a branch of DevOps focusing on the communications within the DevOps team. The ChatOps space encompasses the communication and collaboration tools within the team: notifications, chat servers, bots, issue tracking systems, etc.
When Agile software development models were first envisioned, a core tenet was to iterate more quickly on software changes and determine the correct path via exploration--essentially, striving to "fail fast" and iterate to correctness as a fundamental project goal. The reason for this process was a belief that developers lacked the necessary information to correctly define long-term project requirements at the onset of a project, due to an inadequate understanding of the customer and an inability to anticipate a customer's evolving needs.
In our last post, DevOps and Docker, I introduced Docker as a tool to develop and deploy software applications in a controlled, isolated, flexible, and highly portable infrastructure. In this post, I am going to show you how easy it is to get started with Docker. I will dive in and demonstrate how to use Docker containers in a common software development environment by launching a database container (MongoDB), a web service container (a Python Bottle app), and configuring them to communicate forming a functional multi-container application. If you haven't learned the basics of Docker yet, you should go ahead and try out their official tutorial here before continuing.
Docker is quite the buzz in the DevOps community these days, and for good reason. Docker containers provide the tools to develop and deploy software applications in a controlled, isolated, flexible, highly portable infrastructure. Docker offers substantial benefits to scalability, resource efficiency, and resiliency, as we'll demonstrate in this posting and upcoming postings in the DevOps blog.
On the surface, DevOps sounds great. Automation, collaboration, efficiency--all things you want for your team and organization. But where do you begin? DevOps promises high return on investment in exchange for a significant shift in culture, process, and technology. Substantially changing any one of those things in an established organization can feel like a superhuman feat. So, how can you start your organization on the path to DevOps without compromising your existing business goals and trajectories?
Environment parity is the ideal state where the various environments in which code is executed behave equivalently. The lack of environment parity is one of the more frustrating and tenacious aspects of software development. Deployments and development both fall victim to this pitfall too often, reducing stability, predictability, and productivity. When parity is not achieved, environments behave differently, which makes troubleshooting hard and can make collaboration seem impossible. This lack of parity is a burden for too many developers and operational staff. Looking back on almost every problem I have seen in new production deployments, I find it hard to think of one issue that wasn't due in some part to lack of parity. For developers, this pain is felt when integrating and testing code.
In line with its risk management program, an organization might decide to host unsupported applications on its supported or unsupported operating systems. In this post, I describe how organizations should upgrade, replace, or retire unsupported software assets, including operating systems.