#fasterapp #cceventThey’re written for readability, for integration, for business function, and for long-term maintenance…

When I was first entering IT I had the good (or bad, depending on how you look at it) fortune to be involved in some of the first Internet-facing projects at a global transportation organization. We made mistakes and learned lessons and eventually got down to the business of architecting a framework that would span the entire IT portfolio.

One of the lessons I learned early on was that maintainability always won over performance, especially at the code level. Oh, some basic tenets of optimization in the code could be followed – choosing between while, for, and do..until conditionals based on performance-related concerns – but for the most part, many of the tricks used to improve performance were verboten, and some based solely on factors like readability. The introduction of local scope for an if…then…else statement, for example, was required for readability, even though in terms of performance this introduces many unnecessary clock ticks that under load can have a negative impact on overall capacity and response time. Microseconds of delays adds up to seconds of delays, after all.

But coding standards in the enterprise lean heavily toward the reality that (1) code lives for a long time and (2) someone other than the original developer will likely be maintaining it. This means readability is paramount to ensuring the long-term success of any development project.

Thus, performance suffers and “rewriting the application” is not an option. It’s costly and the changes necessary would likely conflict with the overriding need to ensure long-term maintainability.

Even modern web-focused organizations like Twitter and Facebook have run into performance issues based on architectural decisions made early in the lifecycle. Many no doubt recall the often very technical discussions regarding Twitter’s design and interaction with its database as a source of performance woes, with hundreds of experts offering advice and criticism.

Applications are not often designed with performance in mind. They are architected and designed to perform specific functions and tasks, usually business-related, and they are developed with long-term maintenance in mind.

This leads to the problem of performance, which can rarely be addressed by the developers due to the constraints placed upon them, not least of which may be an active and very vocal user base.

APPLICATION DELIVERY PUTS the FAST back in APPLICATIONS

This is a core reason the realm of application delivery exists: to compensate for issues within the application that cannot – for whatever reason – be addressed through modification of the application itself. Application acceleration, WAN optimization, and load balancing services combine to form a powerful tier of application delivery services within the data center through which performance-related issues can be addressed. This tier allows load balancing services, for example, to be leveraged as a means to scale out an application, which effectively results in similar (and often greater) performance gains as simply scaling up to redress inherent performance constraints within the application.

Application acceleration techniques improve the delivery of application-related content and objects through caching, compression, transformation, and concatenation. And WAN optimization services address bandwidth constraints that may inhibit delivery of the application, especially those heavy on the data and content side. While certainly developers could modify applications to rearrange content or reduce the size of data being delivered, it is rarely practical or cost-effective to do so. Similarly, it is not cost-effective or practical to ask developers to modify applications to remove processing bottlenecks that may result in unreadable code.

Enterprise applications are not written for speed, but that is exactly what is demanded of them by their users. Both needs must be met, and the introduction of an application delivery tier into the architecture can serve to provide the balance between performance and maintenance by applying acceleration services dynamically. In this way applications need not be modified, but performance and scale is greatly improved.

I’ll be at CloudConnect 2012 and we’ll discuss the subject of cloud and performance a whole lot more at the show!

Sessions

Connect with Lori:	Connect with F5:

Related blogs & articles:

•  From Point A to Point B. 
•  The Three Axioms of Application Delivery 
•  WILS: WPO versus FEO 
•  The Full-Proxy Data Center Architecture 
•  Even the best written code has a weakness 
•  At the Intersection of Cloud and Control… 
•  What is a Strategic Point of Control Anyway?
• The Battle of Economy of Scale versus Control and Flexibility 
• What CIOs Can Learn from the Spartans