Don't Throw Away Your Servers Yet

Posted On 2015-02-04 by dwirch
Tags: Blog General 
Views: 2667

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 the Author

dwirch has posted a total of 189 articles.

Comments On This Post

No comments on this post yet!

Do you have a thought relating to this post? You can post your comment here. If you have an unrelated question, you can use the Q&A section to ask it.

Or you can drop a note to the administrators if you're not sure where you should post.

Your IP address is:

Before you can post, you need to prove you are human. If you log in, this test goes away.

Code Links