Search Tools Links Login

Don't Throw Away Your Servers Yet


Recently, Jon Evans of TechCrunch posted a really intriguing article discussing why your software development package is behind schedule. It's a really good article, and I agree with 66 percent of it. He makes and explains two of the three points really well. As a systems guy, I take a bit of umbrage with the third point.

Entitled "Please Stop Running Your Own Servers Already", the gist of the section is, "Move your servers to the cloud and fire your sysadmins."

The whole section follows this line of thinking, in my opinion. Maybe I am getting excited for no real reason; maybe I need to just calm down and go with the flow. But maybe not.

Embracing the new, and the old

There is a process in place for a reason: it's so we don't break stuff when deploying whatever is thrown over the wall from the dev side of the house. Sorry, that's how it is. You can preach devops, togetherness, and sing kumbaya around the water cooler, but unless all teams embrace those concepts, it's still just slinging code over the wall. I can't tell you how many times I have heard a developer say "it works on my machine. It must be your sever."

System administrators, those worth a damn anyway, are right in not allowing anyone else to access production platforms. These people have been charged with the stability, reliability, and security of platforms, services, and infrastructure. Letting some random developer log into a machine, fail the deployment, then tweak the machine to get the service running might be all well and good if you're running a business out of your moms basement.

However, when you are running a nationwide business, dealing with many different servers, in geographically dispersed farms, it's imperative that all servers are configured identically. This is done so services supplied by each server run as expected, and produced the right results. If Joe Dev gets the app running on one box by installing BillyBobsSuperLib.DLL on one machine, well, guess what – there goes compliance with uniformity. The DLL may have some unintended side effects, though.

Would you care to chase down the broken box if you have 100 machines scattered around the country? Oh, did Joe Dev not document what he did? Good luck.

Why are sysadmins jerks?

Systems guys don't restrict access just because we are control freaks. Well, yes we are. But we are control freaks for the right reasons: Availability, reliability, and security. Would you want me firing up Visual Studio and making random code changes to your product, without knowing what else could be affected? Didn't think so.

We sysadmins like to keep our toolshed neat and tidy. If everything is in its place, as designed, we know where to look to find a problem that might arise. We know about dangerous interactions that might occur between applications, services, patches, updates, and etc.

Also, we are responsible for safeguarding your information, which means backing it up, preparing for disaster recovery, and things like that. If you go and install a random SQL instance, and don't tell anyone about it, well, it's not going to get backed up or otherwise safeguarded.

Is your app ready for the cloud?

To be fair, Mr. Evans does mention "unless your circumstances are truly exceptional, a full cost/benefit analysis usually points very firmly towards moving your servers to The Cloud."

I think something else that needs to be taken into account is the readiness of the application to be deployed to the cloud. In the past, I've worked in many a large company, one in particular stands out in my mind. I won't name them here, though.

CompanyX had this application that heavily leveraged Active Directory, Exchange, and SQL. Every time some changed screens or refreshed a query in the application, a role check was performed against an ADAM instance, as well as a credential check against Active Directory. Oh, and did I mention the file share on a completely separate server that was treated as both an archive and a temp directory by the application?

There was a lot of pressure to move this application to a cloud provider like AWS or Azure. The product owners were warned of the potential costs, in both money and security, of moving this app to a cloud provider. These warnings were ignored, and vendors were contacted.

When the product owners saw the projected costs of running the application AWS, you could hear jaws drop three floors away. I never heard a word about moving the app to the cloud after that. Instead, a complete re-write of the application was undertaken.

CompanyX learned a hard lesson. The application was homegrown, and took seven years to build, and it still didn't work right. A lot of money was wasted, as well as a lot of man hours. The moral is that cloud nirvana is not as simple or as close as you might think.

And finally, in conclusion

I like Jon. He has the same hairstyle as me, and I generally like most of the stuff that he posts. This one section of one article just rubbed me the wrong way.

Moving your stuff to the cloud can be a good thing, and systems guys won't lose their jobs over it. But your apps have to be ready. 'nuff said.

About this post

Posted: 2015-02-04
By: dwirch
Viewed: 3,251 times

Categories

General

Blog

Attachments

No attachments for this post


Loading Comments ...

Comments

No comments have been added for this post.

You must be logged in to make a comment.