Application scaling is easy, except when it isn't

everythingpossible - Fotolia


Be the application scaling voice of reason in operations

It's not easy to tell application owners no, but overallocating resources in the name of application scalability can do more harm than good in production.

So, you want what?

This is often the response from the IT administrator who gets a resource request for the business's next competitive app.

There's a downright scary amount of IT resource overallocation in the name of application scaling. This problem stems, in large part, from application owners who request hosting resources for off-the-shelf software, not from developers sizing in-house apps.

It's not simply a case of someone making an unreasonable request; often, they don't know what they need. Ops must find the balance between requirements today and reasonable expectations for application scalability in the near future. In five years, the app will have been updated or replaced, but owners still worry about future demand from the outset.

App ops professionals must truly understand both sides of the problem. There's an important role in operations for app analysts who deal with resource requests and evaluate demand. What's the actual need and design of the deployment? How can you tell? Virtual machines and cloud resources are not free -- more on that later. Through collaboration, teams can right-size the production environment for each application.

My app needs to scale

The resource requester is often an application owner or analyst. They are not an infrastructure expert. Rather the opposite: Their job is to ensure the application runs smoothly for the end customer. The application's scalability must meet demand today and tomorrow, without a negative customer experience. The specifications for performance and scaling often come from the application vendor or the associated consultant, not the application owner.

No vendor wants to see its product function poorly, so that vendor always recommends generous specifications to ensure ideal operations. These specifications will not be ideal for the data center; in fact, they may be very heavy on resources, with little consideration for actual demand and specific environment factors.

My servers need higher utilization

Application owners armed with these impressive resource requirements will see infrastructure managers as misers who rarely give up a CPU cycle in the name of application scaling. The truth is somewhere in between.

Infrastructure and operations is a department tasked to do more with less to support the cost and resource savings path of an organization. Since virtualization and data center consolidation became the norm, the trend has been more streamlined resources provisioned in quicker time frames. Infrastructure teams can no longer afford to grant large resource requests from application owners without proper vetting.

Whether in-house or hosted, IT resources cost real money in terms of reserved space and operational costs.

This impasse is not the fault of application owners, nor is it the infrastructure admins' fault: It's management's fault. Before you start cheering, the problem is mostly unintentional. Management and relevant lines of business decide on the right application -- most applications should be business-driven, not IT-driven. IT is the vehicle in which the application is deployed. Management also has a continual push for cost and resource savings, and IT often generates a large part of a company's overall expenses.

The applications team needs to fulfill the application direction from management, and infrastructure must control costs, also based on management's direction. Both sides of this argument are valid; therefore, the struggle continues.

Find an app and infrastructure happy medium

With this deeper understanding of the challenge, IT organizations can do a few things to minimize the struggles. Both infrastructure and applications teams must be at the table when management evaluates a new application. IT might not have a say in what application is a new business driver, but it's a business driver and the vehicle for applications.

Early collaboration helps to remove those information gaps between applications and infrastructure that lead to starved apps or overprovisioned and idle IT resources. Too often, a new application is chosen in a vacuum and pushed down to both infrastructure and applications, because businesses incorrectly interpret their virtual and cloud resources as free. Whether in-house or hosted, IT resources cost real money in terms of reserved space and operational costs. The same level of vetting, policy and thought process should go into virtual and cloud-based resources as would go into a capital expenditure for new hardware.

Some companies have put in chargeback systems to hold app owners accountable, but chargeback systems are often complicated and ill-suited for companies that lack internal billing. Operations can adopt a chargeback mentality without actual billing: Design the new application on hardware, estimating the physical cost first before deploying into a virtualized or cloud environment. This proves the resources needed for today's demand and expected application scaling are not free.

Next Steps

This will create a more accountable and cost-effective application deployment plan -- but it is only the first step. The real test comes when the application is deployed and turned over to the operations team, where some resources may be reclaimed.

Dig Deeper on DevOps Team Organization