Complex Complexity. Simplified.
We in IT live in a complex world. While complexity is rapidly increasing, we are working hard on simplifying it. The two things occurring at the same time certainly do not make for a smooth or even linear transition, but at a minimum we are keeping complexity from overwhelming the number of man-hours available to manage the overall IT world.
Our simplification efforts are across the board, which is an amazing phenomenon that I will happily lay the credit for on the DevOps world. While DevOps continues to mean different things to different people, that is the very reason we are seeing improvement in most areas of dev and operations both. And all of these efforts, while providing other benefits, generally work to make someone’s life easier by easing the burden of IT. Whether it be self-service to assist users, automated provisioning to help operations, or CI/CD to help developers, life gets easier and deployment times get faster through these efforts.
It can be daunting to glance across the datacenter and try to plug in every moving part or electron from BIOS to the app serving customers in that VM or cloud instance. It’s a ton. Heck just vCloud is a ton to manage, and that’s only a small part of the overall infrastructure that most shops use to serve customers every day.
As regular readers know, I’m a developer that learned operations as a tool to play more with development, then honed ops skills writing for a networking magazine and working for a networking company. Development is still my first love, and I still do a fair share, but that’s not my job role these days. The net result of a varied set of interests and history is that I’ve played with most of the DevOps technologies out there. I’ve got Jenkins running against a personal Spring/Android project, I use stacki and several of the application provisioning tools together for work, I’ve auto-spun AWS images and hooked up networking for work (not at StackIQ), and scripted installations of a ton of apps in a variety of languages/scripting tools. The list goes on.
And they work. I check in my code on Sunday night after a weekend sprint, and let Jenkins take it from there. I set up servers to be installed by stacki, and they are while I eat lunch, then I set Ansible to fill them with apps, and it does. Sitting at a command prompt and parsing RPM dependencies has never been a fun part of the job for me, and the amount I spend on it is far less, even though I’m installing more.
So we are making progress, but because while we simplify and automate, complexity is growing, it sometimes feels like we’re not. Because progress is not a linear thing. Stacki can install Linux on your servers, be they physical or virtual, but the app installation will require more work. Puppet, Ansible, Chef or any of a handful of others can install the apps once you’ve told them how and what the dependencies are, but then they’re in the cloud or VMs. If the cloud is internal or you’re using VMs, now you need to deploy a different set of servers and apps to be the infrastructure, while the existing infrastructure has to be retargeted to cloud or VM. But then you have a complex server/application provisioning environment that needs some coordination, so a provisioning management tool becomes useful or necessary (depending today on environment size)… Thus does the progress line jump around.
But we’re getting there. As I’ve mentioned before, networking and remote storage are still the weak points in the automation/DevOps cycle, but they are catching up fast.
Some impacted by the differing areas of DevOps are worried about the impact on their jobs. Don’t be. Hovering over servers, trying to make them do what they’re supposed to, hour after hour, day after day can be eliminated by DevOps and automation. Let them be. Turn your focus to the 50K other things that are not happening because of the time investment in basic configuration and maintenance. Take any chance you get to reduce man-hours on this stuff, so you can spend those man-hours moving the business forward.
And if you really love puzzling out how to get a sharded database to work across four different systems spread to three physical locations plus GCE while maintaining strict response times through several layers of security… Well someone has to figure it out to tell the deployment tools what to do, so breathe easy – you can spend the time figuring it out, but not have to do it over and over for the next several years.