DevOps as Plumbing

iStock-918319088.jpg

Let me tell you a story about plumbing.

As a young homeowner, I was house-rich and cash-poor, and because of that I needed to handle breakdowns myself as much as possible. I learned to do electrical work, cabling, drywall, basic carpentry, and plumbing. Of them all, I found the greatest satisfaction with plumbing work. Sweating copper pipes together was elegant, utilitarian, and beautiful. Not all joints were the same, so there were challenges to overcome each time, but a clean weld and a solid seal was a mark of satisfaction. There were a handful of tools that took care of most of my problems; a few pipe wrenches, a hacksaw, a pipe cutter, flux, a blowtorch, a bucket, and a mess of couplers were enough to tackle a majority of my issues. The bucket was multi-use. It could be used for when there was a leak, or as a receptacle for my tears when things went badly.

Then things changed. I’m not a tradesman, so I can’t say exactly why this change happened, but the next time I needed to do work, there was a new infrastructure that was taking over. The aisles that were outfitted with row upon row of shiny copper pipe were being replaced with bland white tubes and flexible colored bundles. My jobs didn’t change; I still needed to get water from one place to another without a bucket, but my materials were different.

Like all skills I’ve picked up, I needed to start learning new approaches. Since the objective didn’t change, but the approach and the materials have, there was a learning curve but with the same goal in mind.  A  new infrastructure and implementation philosophy had its own nuances. Flux was out, to be replaced with inline couplers or chemical cements. Cutting was relegated to special slicing tools. Supporting new plumbing codes, using new techniques that shortened the time it took to accomplish a task. Everything about it changed, except the goal—getting water from one place to another, getting it there quickly and at the right temperature (a temperature requirement that is always changing). Thankfully, the bucket stayed the same.

You may ask yourself, how is moving from copper to CPVC or PEX anything at all like working in IT? Well, although the infrastructure may have changed, your job has remained the same: to provide services to your end user regardless of where their services reside. You could be working with a team that is containerizing everything or a team that’s shifted everything to a cloud platform, but none of that matters. Making sure that the end users can do their job is your job.

Where and how the user does their work is immaterial. Realistically, it doesn’t matter where the work is done, be that on a bunch of physical servers, within a plethora of virtual servers, in a private cloud, hybrid cloud, public cloud, or within a SaaS solution. In that light we’ve added the Cloud Management forums to THWACK. It’s the work that’s valuable to your organization and why you have a job. The tool and the approach that was right last year may not be the same for the next year. This is why SolarWindsRegistered AppOpticsTm, LogglyRegistered, PapertrailTm, and PingdomRegistered share the spotlight with products like Network Performance Monitor and Server & Application Manager. You can easily take what you know, combine it with your years of experience, and apply them to this new emerging IT environment, armed with tools that are purpose-built for the new plumbing.

New approaches, tools, and skills never, ever replace your existing skillset; they just supplement it. That’s what makes for great IT professionals.  There are times when I’ve had to go back and sweat copper while helping a friend or replacing an old water softener. Your legacy skills and tools are just as viable, but you need to know when and how to use them.

So, don’t be afraid to think about picking up some new tools and taking a different approach to solve problems that are ultimately the same as before—helping your users do their jobs—on some new infrastructure. The skills you picked up in your past are valuable, useful, and reduce the learning curve when challenged with something totally new.  Your skills, those which help you work through problems from a multitude of angles, are the ones needed with any new infrastructure.

But if there’s one thing I can recommend, it would be to not forget the bucket.

Parents
  • SLA's wth penalties never seem to come close to covering more than 1% of the estimated impact of an outage when it comes to Internet / WAN / Cloud services.  Last year I saw a local business experience an all-day WAN provider failure that cost the customer an estimated $800,000.00.  I sympathized with them, but this type of service is the unfortunate rule in rural America instead of the exception.  There are few or no competitors for that business due to the low density of people, businesses, and cities.  Providers to those customers charge what they wish and offer ridiculous SLA penalties ($10 reimbursement if your business has no access to WAN or Internet services for one business day).  That makes it challenging to get on board with the cloud, and even more so when cloud providers' services become unavailable for any number of reasons.

    I trust my data centers.  Things that must be accessed through the cloud/Internet?  Not so much.  It's all a matter of having had bad experiences with the cloud--sometimes at the fault of the cloud provider, sometimes at the fault of an ISP. 

    Many of my satellite offices are in small towns with only a single power option, at the stubby end of a powerline.  When power is interrupted due to a storm or human error, power is out for their entire city for one to three days, depending on the cause, its location, and availability of replacement parts and qualified technicians.  My biggest satellite offices have generator backups, but they are not inexpensive to run.

Comment
  • SLA's wth penalties never seem to come close to covering more than 1% of the estimated impact of an outage when it comes to Internet / WAN / Cloud services.  Last year I saw a local business experience an all-day WAN provider failure that cost the customer an estimated $800,000.00.  I sympathized with them, but this type of service is the unfortunate rule in rural America instead of the exception.  There are few or no competitors for that business due to the low density of people, businesses, and cities.  Providers to those customers charge what they wish and offer ridiculous SLA penalties ($10 reimbursement if your business has no access to WAN or Internet services for one business day).  That makes it challenging to get on board with the cloud, and even more so when cloud providers' services become unavailable for any number of reasons.

    I trust my data centers.  Things that must be accessed through the cloud/Internet?  Not so much.  It's all a matter of having had bad experiences with the cloud--sometimes at the fault of the cloud provider, sometimes at the fault of an ISP. 

    Many of my satellite offices are in small towns with only a single power option, at the stubby end of a powerline.  When power is interrupted due to a storm or human error, power is out for their entire city for one to three days, depending on the cause, its location, and availability of replacement parts and qualified technicians.  My biggest satellite offices have generator backups, but they are not inexpensive to run.

Children
No Data
Thwack - Symbolize TM, R, and C