Dominant Designs in Software Engineering: DevOps
This is part three of the Dominant Designs, a series of articles taking an in-depth look into the emergence of 4 different dominant designs in software engineering and how to recognize them in an acquisition
__________________________________________________________
“Imagine a world where product owners, Development, QA, IT Operations, and Infosec work together, not only to help each other, but also to ensure that the overall organization succeeds. By working toward a common goal, they enable the fast flow of planned work into production (e.g., performing tens, hundreds, or even thousands of code deploys per day), while achieving world-class stability, reliability, availability, and security”
- The DevOps Handbook, Gene Kim, Jez Humble, Patrick Debois, John Willes
So far in this series — I’ve explained how dominant designs emerged in software engineering and two dominant designs: microservices and serverless functions. In this chapter of the Dominant Designs in Software Engineering, you and I will take a look at a more mature (and the coolest sounding) design — DevOps.
Related: Dominant Designs in Software Engineering: Microservices Architecture
“Connected applications that make little parts of our lives easier are the technological revolution of the twenty-first century…” But cars are not. Cars have been around for a lot longer. So let’s use the analogy of a sports car to understand what DevOps is.
When a sports car is being developed, the engineers go through rigorous lab testing, run thousands of aerodynamics and performance simulations, and crunch a lot of numbers before handing over the working prototype to the track and road test team.
Do you see a problem here?
A car meant for the tarmac spends most of its developmental life cycle inside the factory and no number of simulations can mimic the environment of a real road and more importantly, the feedback of a test driver.
Software development faces a similar problem. The developers who write the code and the operations teams responsible for the server and production environment are distinct departments in an organization and DevOps is what happens if they weren’t.
Development and Operations
Writing code isn’t enough — it needs to perform correctly and well. However, the teams that develop the software and the ones that deploy and manage it are different and each role requires expertise in different areas. There are other teams involved in the process as well, each with their own set of skills, responsibilities, and priorities.
The end goal of all of these teams is to produce a great product that offers a great experience to the user and so logic dictates that these teams would work together… except that’s rarely the case.
Then there’s the problem of the team sizes. These teams are taking backlog from Product/Business, building out functionality in code, and deploying the bits to lower environments. The teams should be of a size that is just right to collaborate effectively. Too large of a team and they can’t help each other and silos emerge, too small and the team is overwhelmed without support. One way to avoid either of these situations is to follow the 2-pizza rule which says if you cannot feed your team on 2 pizzas, then your team might be too big.
The key here is to avoid any undue burden. Quite often, functional departments, especially the development and operations, find themselves in a competition to outdo each other — and this competition isn’t healthy.
In most IT departments, development is responsible for creating new features to improve the product and do it fast enough to maintain a competitive edge over its competitors. Operations, on the other hand, is responsible for ensuring stable, reliable, and secure hosting environments and deployments. In other words, each side wants different things.
The result? More technical debt, delays, increased costs, and lost opportunities due to increased time to market.
The solution? Adopting a method of software development that sees all of these departments as part of a greater team that works together at every step. That’s it. That’s all DevOps is. Thanks for reading and I’ll catch you guys in the next part of this series.
I am kidding, of course. DevOps is also an…
Iterative Process
The code is developed, tested, and deployed in iterations, instead of at once. This is one of the principles of DevOps, and a practice adopted by companies looking to increase efficiency and decrease costs. Chances are that you’ve already heard of this method being used in companies that have adopted agile development. Oftentimes it is called the “fail fast and often” methodology.
Agile development was an earlier movement that promoted the “lean startup” mindset in software development. Agile focused on writing lots of small chunks of code (as features/functionality) and pushing them out as updates continuously in the development cycle, instead of creating and deploying the entire app at once.
DevOps is similar to Agile in this way, but DevOps focuses more on testing, security, and automation and less on simply churning out updates — quality over quantity.
DevOps Practices
The iterative process is one of the fundamental practices that have led to the emergence of other DevOps practices. For instance, the controlled flow of work.
In a non-tech company, manufacturing, for instance, the work produced is physical and its movement can easily be traced (inventory increases, decreases, shifts, etc) but it’s much harder to track the amount of work completed in development shops since a lot of work can be done with a single click and very little may be achieved through hours of work.
To make software development more efficient, the work has to be made visible. One of the ways of doing this is through a Kanban board which is a visual representation of the work that’s being done.
Another DevOps practice is reducing the sizes of batches. This doesn’t mean less work needs to be done, instead, it means less work done at a time since software development is far more efficient when it’s done in small batches. Reducing the batch sizes means each batch is more likely to be completed (fewer WIPs) and more updates can be pushed out faster (better customer service).
Another DevOps practice is using feedback loops. The goal of any DevOps team is to avoid catastrophic failures but it’s also nearly impossible to create a perfectly safe system with no possible vulnerabilities. So instead of pursuing a “perfect system”, DevOps teams prevent the big, catastrophic problems by solving the small problems.
One way of doing this is to keep the customer in the feedback loop and taking quick action whenever a problem appears. Solving many small problems is still significantly faster than a catastrophic failure.
There are many other DevOps practices as well, including using Microservices and Infrastructure as Code but all of these practices are adopted to achieve one goal — better customer service. You see, under DevOps, the value stream is always improving the product for the customers — when it’s being built (left to right, Delivery Pipeline) as well as when it’s being used (right to left, Feedback Loop).
The Continuous Development Pipeline
The continuous development pipeline is the heart of DevOps. It refers to the strategy of using a CI/CD pipeline (continuous integration and continuous deployment) and this is what makes software development through DevOps so fast.
Continuous Integration is the process of integrating different versions or iterations of the code into a controlled repository or mainline several times a day. CI makes it easier to develop, to introduce new, albeit small changes while also being able to monitor what all updates were introduced and when (makes the debugging process faster).
Continuous Deployment is the process of delivering updates in the form of bug fixes, features, configuration changes, etc. very quickly and several times a day as well. Together CI and CD form the “assembly line” of a DevOps project.
Like an actual assembly line, the delivery pipeline in DevOps is highly automated. Once the code checks in (enters the CI pipeline), it is merged, ran through a battery of automated tests and code scans for vulnerabilities, deployed to lower environments and then further tested by QA team
Every DevOps pipeline is different but a typical pipeline is built into these 4 stages: build automation and continuous integration; test automation; and deployment automation. Companies can use Jenkins, one of the most powerful open-source, Java-based CI/CD tools available right now.
To further improve speed and consistency, many “elite” companies (more on that later) use infrastructure-as-code (IaC), another DevOps practice. With IaC, DevOps teams can automate the process of setting up lower environments and infrastructure components. As soon as the cloud receives IaC definitions, it dynamically provisions and tears down environments.
Why DevOps Became Dominant?
For starters, DevOps was built upon many of the principles of Agile, an already very popular software development movement so it was able to solve all of the problems that Agile solved but in addition to that, it also solved some of the problems created by Agile development.
Here are some of the challenges businesses were able to overcome with DevOps:
- It stops bottlenecks by ensuring both Development and Operations teams are working at the same pace and there is no pressure on either team.
- It aligns the goals of both Development and Operations, ensuring that the latter understands the business value of each piece of code and the former gets enough feedback through testing.
- Automated testing is one of the strong suits of DevOps which significantly decreases the time to market.
Solving these challenges by integrating the development and operations teams means that enterprises see direct and significant improvement in the following areas:
- Development Cycle
The development cycle of any product is cut-down significantly when it’s being built in iterations than all at once. The iterative process also gives developers more time to innovate and adapt to market trends and changes.
2. Time to Market
Creating the product isn’t good enough — the software must reach the market before the competition does. DevOps shines in this area as well as it increases the frequency and speed of releases. Each new update adds new features, greater functionality, and improves the software for the end-user, faster than the competition. Automation of the deployment speeds delivery!
3. Reliability
Software developed under the DevOps method faces significantly fewer system crashes. This is achieved through automated testing where engineers develop test scripts. These scripts are supported by the CI/CD tools (like Jenkins) and test behaviors, functionality, user acceptance, and more as soon as code is checked in and ready to move to different environments.
If any problems do occur, the fast-paced delivery of updates means that the lead times between bug fixes are also shorter.
4. Security
Automation in DevOps also improves security as each batch passes through automated compliance testing before delivery.
5. Scalability
Automation is fundamental to DevOps. For instance, through Infrastructure as Code, developers can create development and production environments and automate most of the testing process in an efficient and consistent manner.
These were some of the broader benefits of DevOps to enterprises but just how much does DevOps affect a company?
DevOps By The Numbers
The Accelerate State of DevOps report surveys over 31,000 professionals around the globe and classifies different companies and developers on various performance metrics with the top-performers classified as Elite.
In 2019, this is how the Elite performers stacked up against the Low performers:
Elite performers had:
- 208x more frequent code deployments.
- 106x faster lead time from commit to deploy.
- 2,604x faster time to recover from incidents.
- 7x lower change failure rate.
The difference between the top-performers and worst-performers in DevOps is so significant because of the difference in software delivery performance. The top companies are leveraging the latest technologies and methods like loosely coupled architecture, trunk-based development, automated testing, and more while the worst-performers aren’t.
Conclusion: What Makes DevOps Successful?
A company that’s suffering because of its software delivery and wants to implement the DevOps model does not have to go through an expensive digital transformation to see improvement, and even if it does, it’s not guaranteed to improve the bottom line. And while moving to a public cloud may help overcome the infrastructure barrier and increase the frequency of releases, the biggest improvement will come after companies change how their software development teams work.
DevOps is a mindset, not a step-by-guide that enterprises can follow to get a competitive edge. If in today’s corporate environment enterprises want to outdo their competition, they must encourage innovation and not promote their development and operations department to prioritize the lowest costs. In fact, the race to achieving lower costs is not very different from a race to the bottom.
Prioritize innovation, focus on frequent releases, and find other ways to improve the working environment, processes, and operations — lower costs, better quality, and faster time to market will all come as a result.
