All Applications Are NOT Created Equal

It is an interesting twist in the IT world that with the increased usage of purchased packages and the growth of on-demand IT, we increasingly find ourselves talking about “Applications”. This is a good reference point, it addresses all of the things running on our servers with one fell swoop, but much like when you talk about “vehicles”, the phrase has little meaning beyond discussing similarities. In the IT sense of the word, Application can be defined as a program running on hardware. In the datacenter sense of the word, it can be a program running on one of our servers, or an outsourced service, or in the cloud. In the business sense, an “application” is “something that helps us get our daily job done”, and that includes (sometimes) many “IT” applications that the user sees as a single thing.

Imagine taking a mechanic from a construction outfit, an aerodynamics designer from a car company, and a maintenance specialist from a military armored unit and putting them in the same room. The very first thing they would have to do is hash out the definition of “vehicle” – to one it is a car, to another construction equipment, and the third sees vehicle primarily in the sense of Armored Fighting Vehicle (AFV – tanks and armored cars). It is not the point of this blog to remind you that business people see applications differently than you, if you’ve been in IT for more than a year, you already know that. But I mention it here for clarity.

For this blog, we’ll use cars as our limited definition of vehicle and “Software that IT is responsible for” as our limited definition of applications, and won’t mention it again. After we’re agreed on terminology, the next problem area crops up immediately. While a Yugo, a BMW, and a Jeep are all cars by any definition I know of (my Jeep is even registered as a station wagon), they have vastly different uses, markets, and weaknesses. The same is true of applications. Your Database Management System is certainly not in the same category of “application” as the static web server you inherited in that acquisition a few months back and are planning on removing as soon as you have time to redirect users to your website. Yes, I know you are aware of that too, please bear with me, I’m setting this up, not telling you the obvious.

       

The Toddler plays with a construction “Vehicle”

And this permeates applications to many levels. Every application is a unique entity with unique requirements, strengths, weaknesses, uses, and misuses… And that is where we tend to start to lose control of the conversation. The idea that web server A has completely different needs that web server B even though both are running the same web server software sometimes causes confusion beyond the people responsible for the daily care and feeding of these web servers. In fact, we in IT tend to talk about the “Accounts Payable System” or “HR System” rather than “The web server serving up HR Apps”. For this reason (or because we’re lazy, one of the two).

But as we move to an increasingly virtualized world, our application inventory must start to include important parts that just didn’t matter when the application didn’t have to share resources. How much disk does it require was always a concern, so you’re in the clear there, but what about the volume of IP traffic the application generates? In a virtualized environment, it is sharing network cards, and this could quickly become an issue. The same with memory and CPU usage, both of which were only a concern if you ran out on the physical box, but now you can run into issues earlier because other applications are using those resources too.

ASCOD – A Spanish AFV army-technology

A few years back, when virtualization was picking up, we saw a case where a company had “load balanced” several instances of a critical application to the same physical server. While not the worst architectural decision ever made, it certainly wasn’t a good one. These days you don’t see that particular mistake, but you do see an increasing number of virtual machines sharing the same set of physical hardware. Without including in your software inventory what a given application requires in terms of machine resources, you can’t predict when that physical server will need an upgrade or how to better distribute load. And no matter where you are in the virtualization process, I guarantee this will become more important to you in the coming year or so – either due to some serious performance issues or attempts to implement internal cloud.

And you thought virtualization was going to make your life easier? It did that by eliminating a ton of hardware, but it did not eliminate your dependence upon hardware. That’s what the Cloud is supposed to do, but that comes with some caveats also, because it will shift pressure from your local network to your WAN connection. After all, now you have apps “out there” that need to communicate – even if only for reporting – with apps “in here”, and that, by definition, adds traffic to your WAN link. BIG-IP LTM and BIG-IP WOM can help, as can other tools, but you’ll need to be more proactive in monitoring WAN throughputs as you move to the cloud, though the cloud will ostensibly free you from worrying about how much is running on a given machine. I would urge caution though, since implementation at the cloud provider is going to determine whether you actually get all the resources your applications desire. And again, you don’t have to worry about the hardware, but you will have to worry about the size of the bill at the end of the month, so monitoring is a must.

The IT world is changing yet again, but any rumors of IT’s demise have been greatly exaggerated. You’re essential to the business, what you do will change, but the need to have you around is still visible on the distant horizon. Keep your skills honed though, new architectures require new thought patterns.

An Advert for the inimical Yugo Autoblog.com