Over the last several years growth in cloud computing has skyrocketed. (Don’t believe me? Ask Google.) Setting the numbers aside, and just taking anecdotal evidence from here on the ground level, much of this growth comes from businesses who are abandoning their traditional managed servers hosted by the likes of Rackspcae and Liquid Web, and instead spinning up AWS or GCP instances in an unmanaged environment.

And therein lies a problem that no one seems to be worried about. These organizations are leaving managed space for the wild west of unmanaged space. This shouldn’t be an issue for large organizations who have Sys Admins on staff. Those professionals should be up to the task of managing servers.

But for smaller organizations, this move (which is often done to try and save money) adds a whole level of complexity that no one in technology or management is properly addressing. You see, the servers that the dev group has used to develop solutions for the business are highly complex technical entities themselves. And if Liquid Web used to be the entity responsible for maintaining the software on that server, who’s responsible over at AWS?

Before you make the jump into an unmanaged environment (cloud or not) you have to know the answers to the following.

What technologies are we actually using, and how are we becoming aware of flaws, updates, and patches?
You can’t maintain a service you don’t know you’re supposed to be maintaining. The tech people will need to know exactly what’s out there, and the state that it’s in. Do you have an open source FTP server that hasn’t seen a code-change since 1999? You probably need to get rid of that entirely and replace it with a better maintained package. You also need to be sure that when you “flip the switch” you don’t accidentally take out a service you’ve forgotten about. If Sales loses VoIP it’ll eat into your cost savings very quickly.

How are you using those technologies–especially what parts of large software packages are you using?
It’s entirely possible that you’re using MySQL, but you’ve entirely disabled the ability to login without an SSH key. In that case, you’ll be able to postpone any updates that deal with problems related to having that feature enabled. You’ll need a solid understanding of which parts of a software package you’re using. You can’t completely ignore an update in most cases, but you don’t necessarily have to stay-late on a Friday if the update doesn’t actually address a problem you’re actually going to encounter.

Who is going to be responsible for what?
So, now that you know what you’re using, and how bad it is, it’s time to assign blame–I mean–responsibilities (more on this in a minute.)

If you’ve got a Systems Administrator, or a DevOps pro, this is where they tend to shine. They’re used to dealing with the mess that comes with a LAMP stack, and so you should probably just make them the responsible party across the board. If you don’t have one of these people, then you’re going to have to make these assignments using your current technical staff. Architects, Leads, and Senior Devs are your best bet if you’re without someone with the actual technical ability. They tend to have the kind of access needed to do these maintenance tasks already. Of course, they’re also highly compensated, and rarely find themselves with nothing to do on a Tuesday. This leads us to the next question…

When are you going to let your people do this work?
Again, for a Sys Admin, this is their actual job description, so they generally handle this pretty well. But a Senior Dev doesn’t necessarily know everything there is to know about the Cron server. How long will this patch take? Will it take out anything else? Can we go back? Did you smoke test it? All this is going to take some time. Not to mention, it assumes that the Dev even knows how to do this work.

How are you going to prioritize the fixes?
The Senior Dev needs to patch the Cron server she’s responsible for. She also has to finish the sprint tasks, and she’s got Thursday off. Do we fail the sprint so the server is kept up-to-date? What are the chances that the patch will cause more problems then the actual vulnerability you’re patching against? What if she’s also responsible for the SMS server? Which one goes first? What happens if the vulnerability happens while she’s on vacation? Who’s her backup? Did you think of that?

It isn’t a great idea to step into an unmanaged space unless you have the technical chops available to handle the new responsibility that comes with it. That said, it’s important to remember that you don’t have to run unmanaged servers to join the cloud. Most old-school vendors are offering managed cloud computing, and AWS and GCP also offer managed tiers. Of course, they cost more money, and that makes the savings in moving less attractive. But, what’s the cost of a massive data breach, or the loss of a key technical person who looks squarely at you in the exit interview and says “Patching an FTP server from 1999 isn’t part of development. It wasn’t my job. Now it isn’t again.”

In an effort at full disclosure, this blog is hosted on a managed hosting service, specifically because I don’t have the time to deal with every single WordPress vulnerability, patch, and update.