7 signs you're doing devops wrong
Here we take a look at some of the most common misconceptions and flawed implementations of devops. Chances are, your company has fallen prey to at least one of them. That doesn’t necessarily mean you aren't practicing devops. It simply means you have a ways to go before your company can fulfill the promise. Devops isn't an award or title you can achieve. It's a philosophy, culture, and way of approaching the task of shipping code.
Read on, take a step back, and assess your company’s commitment to its devops mission. Candor and honesty are essential to guiding your team in the right direction.
IT departments need "stuff" to operate. They need hardware: computers, servers, server racks, network switches, routers, and load balancers. They also need software: operating systems, antivirus products, productivity software, project management solutions, various line-of-business applications, and software to monitor the health and performance of hardware and software alike.
IT departments have been buying "stuff" since their inception. When the first company decided to use computers as part of their business practices, purchasing as the lifeblood of IT was born. It's natural for IT higher-ups to think they can buy the next big thing that will help them help the business succeed. This is why some companies give themselves the false impression that they can buy "the devops."
But it’s not for the wrong intentions. Many CIOs who attend devops conferences or talk about devops with fellow CIOs begin to see what devops can do for their company. Some decide they want “the devops” -- and they want it now! What they don't understand is that devops is not a product or service to purchase. It is a mind-set or mode of operation.
That’s not to say you can’t purchase a block of hours from highly paid consultants to learn devops principles, but by doing so, ultimately you are purchasing knowledge that requires significant work on your part to implement. Your team must absorb what's being taught, and only then will devops practices begin to take root.
"Devops" cannot be obtained overnight with a simple check and a little training. It is a transformational approach to core processes, and it takes time, dedication, and especially a team that can implement devops practices, many of which will fly against your company's previous modes of operation.
If your company has a devops budget, you're doing devops wrong.
This misapplication of devops runs in parallel to No. 1 above. IT shops acquire tools to do their jobs more effectively. It’s encoded in the job. IT shops have tools to manage clients and servers, as well as storage, compute, and networking resources. But when it comes to tools and devops, companies often get confused. To be sure, devops greatness cannot be achieved without tools. But when companies ignore other areas of devops and focus solely on the tools themselves, problems arise. Tools may be essential, but they are only part of what makes devops tick.
Various configuration management products associated with devops certainly help you build a devops culture. Without them, you undoubtedly are not practicing devops. You can code together your own tools to automate previously manual processes such as code testing, deployments, and server builds, or you can purchase tools geared to complete these tasks; either way automation is a huge part of devops. Without tools, you'd still be manually building test servers, running through runbooks, and checking off tick boxes on a checklist.
But devops consists of a number of facets that go beyond configuration management; don't focus in on only one simply because a solution exists and it's tangible. If you look for something tangible to latch onto in your journey to be a devops ninja, you will fail.
If your company bought Chef or Puppet as a cure-all for its devops needs, you're doing devops wrong.
To hammer the point home, automation is the crux of devops. Automation is of paramount importance in an organizational devops culture. Companies practicing devops have a strong desire to automate everything possible. Automation allows them to remove human error and standardize processes across the entire software development lifecycle.
Businesses know that automation is the seed that grows other devops principles such as establishing consistent, routine code deployments. Without automation, reliable code deployments, in particular, would not be possible. Automation is a crucial philosophy to adopt when driving toward a devops culture.
So if you find yourself having conversations with co-workers that include statements like, "We don't have time to automate," or "Let's just do it manually this time. It'll be faster," then you're not doing devops. When embarking on a new project, if automating everything possible isn't the first idea that comes to your head you're probably not at devops mastery yet.
Devops-heavy cultures realize that even though it may take more time to introduce automation up front it will pay off through more reliable and faster code deployments in the future. Your company must understand that everything is on the table for automation. This means deployments, testing, code check-in policies, servers builds -- everything.
If your company spends hours poring over checklists to ensure code is ready to be deployed, you're doing devops wrong.
Now that we've addressed automation it's important to address deployment frequency. The sole purpose of devops is to fix bugs and release new features to production faster. That's not done by following a traditional waterfall model; that's done by being agile.
At its heart, the agile methodology consists of releasing small changes as often as possible. Its premise is to not plan every little detail ahead of time before releasing to production. It is about defining what is considered "production ready," representing that with a set of automated tests, and trusting that the tests written correctly define what it means for code to be "production ready."
Devops is synonymous with concepts like continuous integration and continuous deployment. Notice the key word in both terms: continuous. Devops is about consistently having developers check code in as often as possible, which kicks off automated tests.
For the true devops rock stars, it's also about taking that code and sending it directly to production through continuous deployment. If your company allows developers to check in code that goes through automated pre-check-in tests, gets handed over to another set of tests to ensure that the code is ready for production, then goes live on your production servers if deemed ready automatically, then you know you've achieved devops greatness.
If your company releases code changes less frequently than the harvest moon, you're doing devops wrong -- no matter how small the changes or how quickly you make them.
Culture is often considered a "soft" aspect of IT, but it couldn’t be more essential to devops. This is where companies often fail to achieve the promise of devops. They might be automating with the optimal mix of tools. They might be continuously updating their code. But their inability to fully assimilate devops culture gets them every time.
For example, when the code you committed goes on to blow up a production database, what happens to you Does your boss publicly scold you Do you get immediately called into a manager’s office for a "closed door" meeting Is losing your job or your ability to deploy code to production ever again a possible outcome of committing code If so, then your company is not practicing devops.
Instead, picture this: The meltdown of the production database is treated as a learning opportunity. Your manager brings everyone into a postmortem meeting to provide candid feedback. Everyone exhibits a level of candor that might make you squirm, but it's never at a level that places blame. The root cause is determined, and new tests are built around your mistake so that it's caught next time and everyone acts like it's simply another day. This is when you know your company has adopted an important devops philosophy.
If you are no longer trusted with commit rights to production because you have made or might make a mistake, you're doing devops wrong.
Devops philosophy has borrowed heavily from lean, and not blaming others for systemic errors is a key facet that has influenced the human aspect of devops. As with embracing failure, removing individual blame for problems associated with the system is essential to successful devops practices.
True devops practitioners believe that when something goes wrong the fault doesn't lie with the individual using the system but the system itself. For developers and systems ops to get along, a blameless culture must be supported. Suppose a developer creates an application, tests the application on his computer, and hands the code over to operations. If a problem occurs when ops puts the code into production, ops can’t blame the developer for writing shoddy code, nor can the developer blame operations for not managing servers correctly.
Devops resolves this issue by first figuring out the difference between the two testing environments. Once discovered, the fix is implemented, and preferably, an automated test is created to ensure that, in the future, any flawed code will fail the newly automated test, which will prevent that change from ever getting into production.
If your company is firing staff simply for bringing down production, you're doing devops wrong -- regardless of any presumed role or responsibilities you attribute to those involved.
Devops weds the word "developer" to the word "operations." If your developers and operations people still aren't on speaking terms, you don't have a chance at doing devops right. Devops is all about collaboration. It's about coming together as a team to help the company, as a whole, achieve its goal. If your operations people refuse to communicate to developers other than throwing work over the proverbial wall, your devops dreams are toast.
This is the most important part of the devops philosophy. All of the activities I've touched on previously move toward this end result. It doesn't mean developers should be forced to eat lunch with operations people or operations staff must invite developers to their weddings. It's not about liking one another; it's about looking past our human emotions to work as a professional team to build a product that propels the business forward.
If your company has developers on one floor and operations on another, with code commit messages as the only means of communication, you're doing devops wrong.
Devops is not for every company. There are situations that warrant a more meticulous approach to code management. However, even if your company isn't fully committed to building a devops culture, there are many facets of the devops philosophy that can be applied to your practices successfully.
Above all, devops is a cultural philosophy. It takes patience, lots of hard work, an understanding of people, and a business that will support it to truly thrive.
Related articles