I’m always interested in datacenters because I live in Northern Virginia, where a new one opens about once a month, leveraging a huge bundle of fiber coming out of the ground near Dulles Airport and cheap power sources. Indeed, they now call my region “Datacenter Alley.”
A report by JLL shows that the strong movement of data from private corporate servers to cloud services, coupled with a growing corporate interest in internet of things (IoT) initiatives, is pushing the demand for these new datacenters. With data usage skyrocketing, major cloud providers expect triple their infrastructure by 2020, so they are building or renting datacenter space to keep up with the growth.
You’ve made the leap and have implemented a DevOps strategy in your organization. If everything is going just great, this post may not be for you. But if you haven’t implemented DevOps, or you have and things just don’t seem to be progressing as quickly as you had hoped, let’s discuss some of the reasons why your DevOps might be slow.
Before we get too far along into why your DevOps initiative might be slow, let’s first ask: Is it really slow? If DevOps is new to your company, there may be some period of adjustment as the teams get used to communicating with each other. Additionally, it’s possible that your expectations of how fast things should be might be out of alignment with how they really are. It’s easy to think that by transitioning to DevOps, everything will be all unicorns and rainbows and instantly churning out code to make your lives better. However, depending on where you start to focus, there could be some time before you start to see benefits.
What We Have Here is a Failure to Communicate
If you’ve been following the previous three posts in this blog series, it should come as no surprise that one of the key factors that could slow down your DevOps projects is communication. Do you have a process set up to interface the developers and operations personnel so that everyone agrees on the best way to communicate back and forth? Are your developers getting the information they need from operations in a timely manner? Can operations communicate feature requests, issues, and operations specific information to developers efficiently? If the answers to any of these questions are no, then you’ve started down the path of identifying your issue.
Keep in mind that just because you have a process in place to establish communication channels between the developers and operations personnel, you may still encounter issues. Just because a process has been established doesn’t mean it is the right process, or that people are following it. When evaluating, make sure that you don’t assume that the processes are appropriate for your company.
I’m Not Buying That
Sometimes, employees simply won't buy into DevOps. Maybe they think that they can get things done faster without user input and as a result, they ditch all processes that were in place to help facilitate developer-operator communications. As mentioned in DevOps Pitfalls, culture is a huge contributing factor to the success or failure of any DevOps initiative. The process becomes behavior which, in turn, becomes culture. If the process is being ignored, your organization needs to come up with a way of dealing with employees who choose not to follow it. This gets into a whole HR policy discussion which is way outside the scope of this blog.
I Used to Be a Developer, Now I’m a Developer Times Two!
Before you started doing DevOps, it’s likely you already had developers, and they already had a job writing code for some projects. Whether it’s because you are increasing automation or building software for a software-defined data center, the projects that you are considering the lead into DevOps are not the only projects that your developers are working on. When you make the choice to implement DevOps processes, carefully review your developers' current workloads. Based on your findings, you may need to hire more developers to help ensure that the project rolls out smoothly and in a reasonable time frame.
It doesn’t matter if you are developing a new software tool or deploying a new phone system, there is a tendency for a lot of people to want to get everything rolled into one big release. By doing so, users get to see the full glory of your project and you can sit back and enjoy being completely done with something.
The issue with this approach is that this could take a lot more time than users are expecting. It would be better to have some clear communication up front to identify the features that are time-critical for users to have, and build and release those first with a schedule to release the remaining features. By using this approach, developers and operators get an early win to address the critical issue. This is then followed up by additional wins as new functionality gets rolled into the software in future, short-timeline releases.
As you can see, reasons for a slow DevOps process are varied but can be largely attributed to the communications that are in place between developers and operators. What other issues have you seen that have slowed down a DevOps process?
In the next and final post in this series, we'll wrap up some of what has been discussed in the series, and also address some of the comments and questions that have cropped up along the way. Finally, I’ll leave you with some DevOps resources to give you more information than I can possibly provide in five blog posts!
In previous posts in this “My Life” blog series, I’ve written quite a bit about the project management/on-task aspects of how I keep my focus and direction top of mind while I practice and place emphasis on my goals. But, what happens when something doesn’t work?
In some cases, the task we’re trying to accomplish may be just too hard. In some cases, we’re just not there yet. Practice, in this case, is the right answer. As my french horn teacher used to say, "Practice does not make perfect. Perfect practice makes perfect." The problem, particularly in my guitar playing, is that I’m flying a little blind because I have no teacher helping me to practice perfectly. But, imagine a tricky chord sequence that has had me failing during practice. If I don’t burn through the changes as often as possible in my practice time, I’ll definitely fail when I’m on stage, attempting to play it in front of a live audience.
In an effort to avoid the embarrassment of that failure, I sandbox. At least that’s how I see it.
The same analogy can be transposed to my thoughts about implementing a new build of a server, an application that may or may not work in my VMware architecture, etc. We don’t want to see these things fail in production, so we test them out as developer-type machines in our sandbox. This is a truly practical approach. By making sure that all testing has taken place prior to launching a new application in production, we're helping to ensure that we'll experience as little downtime as possible.
I look at these exercises as an effort to enable a high degree of functionality.
The same can be said as it reflects on training myself to sleep better, or to gain efficiency in my exercise regime. If I were to undertake a new weightlifting program, and my lifts are poorly executed, I could strain a muscle or muscle group. How would that help me? It wouldn’t. I work out without a trainer, so I rely on the resources that are available to me, such as YouTube, to learn and improve. And when I’ve got a set of motions down pat, the new exercise gets rolled into my routine. Again, I’ve sandboxed and learned what lessons I need to know by trial and error. This helps me avoid potentially hazardous roadblocks, and in the case of my guitar, not looking like a fool. Okay, let’s be clear... avoid looking more like a fool than usual.
I know that this doesn’t feel spontaneous. Actually, it isn’t. Again, as I relate it to musical performance, the correlation is profound. If I know via practice and a degree of comfort with the material, it allows my improvisation to take place organically. I always know where I am, and where I want to be in the midst of a performance, and thus, my capacity to improvise can open up.