Bring Reality Into Development

[article]
The Network Isn't Always the Cause of Problems
Member Submitted
Summary:

The causes of many distributed application performance problems lie in the application itself, not the network. Therefore, as the first stop in the application lifecycle, the application development organization must play a key role in distributed application performance.

Today, business applications are not developed for multi-tiered distributed infrastructures, resulting in poor performance and reliability.

These issues unequivocally impact a company's bottom line, not just in terms of lost time and revenue, which can reach over $10M an hour for business critical applications, but also in terms of lost reputation. Moreover they impact the productivity of the entire IT organization, from Development to Quality Assurance (QA) to Network Management, as the applications are sent back through the development cycle multiple times. Given the ever-growing complexity of application infrastructures and the advent of .NET and Web Services technology, these problems are only going to escalate.

The causes of many distributed application performance problems lie in the application itself, not the network. Therefore, as the first stop in the application lifecycle, the application development organization must play a key role in distributed application performance. Developers who typically focused on the quality and usability of the application code, now must realize the full implication of deploying this code in a widely distributed environment that includes remote end-users and limited network resources.

To deliver expected performance in production the first time around, distributed business applications must be developed for the actual network conditions they will encounter in production–right from the start. This means providing developers with a work environment that emulates the production network, and takes into account its bandwidth limitations, geographic distances, data packet loss, and other network conditions. The developers need to experience what the remote endusers will actually experience when they use the application over the production network, whether it's slow response time due to low bandwidth, or time outs caused by the time it takes for a transaction to travel to the server.

Enhancing unit and integration testing by providing a work environment that's as true-to-life as possible ultimately empowers developers to ensure higher application quality and reliability once these applications are deployed. Furthermore this work process will reduce the number of problems that typically surface during QA and production, and directly lead to fewer iterations and shorter deployment cycles. All this helps to eliminate the frustration, finger pointing and firefighting that occur across IT when post-deployment problems arise, and ultimately leads to improved time-tomarket, increased cost savings and, most importantly, end-user satisfaction.

Notes:
Shunra Software recently released Shunra\Stratus 2.0. Designed for the software development team, Shunra\Stratus extends unit and integration testing for distributed application code. It lets software developers "see and feel" exactly how their application modules will perform over the target production network under a variety of real and potential remote end-user network conditions, directly from their desktops.

Shunra\Stratus is intuitive, and very easy to setup and use. It seamlessly integrates with the existing development environment and does not require users to be networking experts.

About the author

CMCrossroads is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.