DevOps – Optimizing Success

We need to think differently… uniquely… to solve problems, working together while doing so. DevOps is a term often misused and understood in its infancy, but is becoming more widely […]

We need to think differently… uniquely… to solve problems, working together while doing so. DevOps is a term often misused and understood in its infancy, but is becoming more widely adopted among software development and information technology professionals. I hope to depict my view of what DevOps means to me and give some insight into how it can be used to optimize the success in your business. DevOps is much more than just integrating software development and operations. Let’s break it down into manageable chunks to get a broad picture.

What issues are we having?

In most traditional businesses today where software development meets systems operations, there is a disconnect. There’s a perception the fast-moving world such as web-dependent business models, that projects become more expensive, are late, and produce less than what business wants. In that model, we have to wonder how the industry keeps its jobs. In one example, a development team may create something they think is fantastic for their business partners. They hand it over to the operations team only to find that there is issue after issue and things don’t work whether it be because it isn’t compatible with infrastructure, it doesn’t scale for resources, or maintenance to keep the application running becomes unbearable. Add that with business wanting new changes, development and QA adding new features and fixing bugs, and each team pointing fingers at the other blaming them for issues such as development not thinking operations implemented it properly or willing to change technologies, or operations saying it’s coded poorly and deployments become a nightmare for everyone involved. We soon have what we see as nothing less than just a big mess and failure, all the while business thinks both teams are incompetent. Take a look at this video from Devopsdays as a teaser to summarize the whole idea.

DevOps to the rescue

So now that we have a mess, how can we fix it and do better? Enter DevOps. DevOps is really more of a movement to bring the teams and processes together to make business money. Many misinterpret DevOps as solely a position or job at a company to solve development and production integration problems, but in my mind it is more of the behavior and mentality to optimize the success of the business which can then be led by individuals. All of this needs buy-in from the other team members. The teams and individuals can utilize this DevOps thinking by following the goal of realizing, “Hey! We’re all on the same team”. This may sound broad and obvious, but in practice, it has not traditionally been the view. The more common practice is that each department and team often work independent of one another. Leaders can come to help evangelize the DevOp role. Now that this DevOps movement has been acknowledged by members, we can work together to implement solutions to help solve our issues and make business money.

Who can help?

All of the members subscribing to the DevOps mentality can help and really need to, but when looking at team members to help lead and implement, we find that those who have a multiple-discipline approach tend to be extremely helpful. Someone who has a broad experience, can jump from language to language, and understands system architecture can often be much more helpful in implementing this approach than someone that is just a singular coder such as just .NET development or just PHP development. The DevOps mentality suggests that you have all of the skills needed to at least understand the big picture and solve the issues. While you may have focuses in certain languages as a developer or certain infrastructure technologies as an operations engineer, if you have a larger understanding of what is happening, we can fix the actual issues at hand without prejudice of sticking to solely what we know or have available at the moment. Having individuals fluid and able to adapt is key to the DevOps movement in a business.

If you have someone who only does database development, and another who just codes in ACME++ language, and another who implements ACME OS on their ACME server system, you have a problem. For one, they are probably unwilling to use other technologies because they want to stick to “their system”. I see this all the time where people are unwilling to use other operating systems for example. A place might be unwilling to use MacOS in favor of Windows, or another may not be willing to use Linux because they don’t know it. In other cases, some may never want to touch Windows and only use MacOS or Linux. In all of these cases, I see issues. I have seen every case in business I have done and I see the reason most-often being that it’s too hard for them to learn other technologies, they want to stick to what they know, and they lose the ability to adapt. Usually, what is chosen is what people know rather than what is best for the work. I have seen the same thing with software where someone will go with a particular language because they know it rather than another that would accomplish the same thing in much less time and utilize much less resources. In extreme cases, to make my point, some would rather create and manipulate an Excel spreadsheet on a daily basis rather than have the system automatically process the data for them. I cringe when I see businesses as only allowing specific ideas. Long ago in the infancy of my career I was told that this specific business was only doing things a certain way, the same way they had for years, and I need to think “inside of their box”. Needless to say I saw that stifling innovation and I moved on, being glad I did. More than a decade later I am telling you to think outside of the box to embrace the future.

Now I do digress a bit, in that I understand there are times when a singular technology, method, or process may be appropriate. Depending on circumstances, it may be a better business decision to use what you have knowledge of in lieu of more resource-hungry and less efficient options. At other times, a specific platform may be the most beneficial to business. This, however, should be done in acknowledgement and understanding of those reasons, not as a reaction to them. Anotherwords, solutions are chosen based on their ability to solve a business desire rather than on what is most comfortable to those implementing the solutions. To put it forward, the people doing the work need to be willing to be fluid and adapt, even that means giving up something they are comfortable with. In a nutshell, they need to be willing to change, and to change for appropriate reasons.

The many facets of DevOps

Communication will be key. What we are trying to do is link together the different teams. In the industry, developers and project management teams have already acknowledged this need and have utilized the Agile methodologies to improve this communication and bridge the gap to create what business desires. So development may come up with a great solution using agile, but it still needs to be usable by end-users. One of the next steps of DevOps is to bridge this gap between a developed product to a usable product made available to the public in much the same way that the Agile methodology has helped business create what they want with development. Agile, Scrum, and Kanban has helped to bring communication to the development process. Now, we want to do the same thing with operations.

Going hand-in-hand with communication is building relationships. Because we are integrating teams together, this is so important. Think about what we are trying to do. We’re trying to create solutions for business. If we hand off our product without any insight of how it works or what it needs to do, how can we efficiently maintain it in the end? From the very beginning and all iterations, our relationships should include all team members so we as one business can deliver what is needed, in the end, to make money for our clients. This works in all directions. Operation teams should be assisting developers to develop products on systems that can be supported and developers should be working with the operations folks to be able to support and maintain at a feature-set that business desires and infrastructure needs can be planned to adapt to. Those developers can often bring automation and scripting skills to help efficiently manage the end-products. When we bring together the skills and everyone understands where we are going, we can plan for our futures to make them more successful. What did we say earlier? Problems are solved by having the skills to create solutions for them. Let’s bring them together and use the talent we have. That’s the whole idea.

The DevOps philosophy thrives by keeping things simple. You may hear the term KISS (Keep it Simple Stupid) all over, but it really makes things much easier. By taking away the complexity, we can more easily train new people, create documentation, establish and address security issues, reduce bugs, improve quality, increase time to create, and in general reduce risk to business, all to create a better business. Sometimes when we try new things we may fall on our face, especially when starting, and find it’s not the way to go. We are still ahead, however, and learn from that experience that it didn’t work and can improve where we were. When looking to use new technologies, let’s do so in a smart way that fits business needs. Let’s use new technology in a smart way where we can re-use it. If we create something just because it’s new and is less efficient and more complicated to evolve into our repeatable and maintainable environment, are we really doing the smart thing? In some cases, we might be, and we adapt. In other cases, we find we are just creating another headache for someone else to manage. If we do adopt it, in most cases, I would hold that everyone should be all on board where we create a maintainable, automated, and usable system before introducing added complexity of this feature. If we can’t do that, we should be asking ourselves if it is the right thing to do. If you can’t do it because of a lack of skill-set, then maybe we need to ask if we need to add the skill-set or hire help to accomplish that.

In the end, the goal is to create what business needs and to think as one team rather than multiple departments. So many businesses try to do everything for everyone. Sometimes they need to know when to say “no, this isn’t the right thing for us, and it’s not the right thing for our client”. I know many businesses that actually have more respect for being able to do this and have turned away business to protect their client, their quality of product, and work. I have done the same for myself personally in my career and have always been glad I did. Many businesses want to acquire more and more, only to find an overly-complex and political-rich environment. Instead, I’m a fan of learning to know when you grow vertically to scale and when to start splitting off into separate businesses horizontally because you realize you’ll do better that way. Stockholders of large corporations see it all the time. A business may see it is most beneficial to break-up rather than become larger and larger. Stock prices go up for the companies because they’re not held back by the complexities and misconceptions of other entities. In the end, the simplicity wins and I’d offer that the same holds true here.

One of the best way to keep things simple is to find the repeatable items and automate processes. Obviously, we automate things and it creates our result, and we do that over and over saving time, money, headaches, and more. It’s nice to have things automated and allows us to move on to other things. Now, there is a misconception in the industry where we find repeatable processes and find out how to create our desired outcome by automating them in a repeatable manner. This misconception is that we are concerned with our desired outcome. DevOps tends to address this misconception by focusing on what happens in my process when things don’t work rather than making things repeatable when everything is perfect. Remember, we’re constantly changing our business, and most of the time, the issues don’t arise with processes that are not touched. The issues come in when something changes that we don’t expect. Instead of automating to save time, we now spend our time troubleshooting and hunting for some issue that changed somewhere in our process which breaks our automation. The DevOps mentality suggests that we automate to the problems that can happen, rather than our desired result. In the end, we hopefully have a better system that can alert us when something went wrong, and what went wrong, and we know where to look to repair it.

To see an analogy of the different views of process automation end-results versus process automation delivery, we can look at that of a newbie programmer who makes a program that does some logic that depends on some information. They create it, but it breaks a year later. Now, a new maintainer is looking at the broken issue and doesn’t know where to fix it. Taking a look at the DevOps model, we see the code has proper error-catching and creates a log of issues along with full monitoring of everything. If it’s in compiling the code, we are linked to a continuous integration system and have automated code testing. We know exactly what broke, where it broke, why it broke, and know where to fix it. If something changed in the infrastructure, monitoring systems in place can tell us what is the missing link. Yes, it may have taken a bit more time to setup upfront, but a year from now, it may have saved us a huge amount of time. In other examples, we may have deployments which gracefully rollback to a previous version upon error. In an elastic computing (I don’t like “cloud” because it can mean anything outside of your network and is so ambiguous) setting, you may have systems that can detect the problems that arise and bring up new instances of your application to take over. All of this makes everyone’s job easier. In order to accomplish this, though, you need the coordination of all members to assist and create products to work in this manner.

With DevOps, we bring together all of the different tools to keep pushing ourselves to new and better things. We use continuous integration, automated testing, reusable code repositories, distributed version control systems, automation, monitoring, security tools, backup, provisioning, and other tools to bring people together. We are creating a product together, not just the application that performs logic, or the systems that hold the applications, rather, we are creating a solution, and doing it together.

Optimizing success with DevOps

In the end, we need to realize that DevOps is not a technology problem, it is a business problem. We can use all of the resources available to help address the business problem, but those resources don’t really matter, it’s about how we get there.

DevOps is about culturing an environment of people to work on goals for solutions rather than their own little niche, optimizing the success of the business. As others have said it best, “We’re all on the SAME team”.

 

Share

About ipaul

My name is Paul Hassinger, the founder of ipaul.com. I have been an avid user of computers since a child. I started when I was about 10 years old working on an Atari computer. Since then, I grew and have had exposure to all types of technologies. I started using FIDONet on a BBS as a child and grew to the Internet. My first graphical world wide web experience was in 1993 using Mosaic. Over time I've worked with both small and large computing systems even maintaining systems serving millions of users on some of the largest social networking sites. I hope to use this blog to capture what I've learned over the years and what I do in my daily life so that others and myself may find the information useful.