Asp e mail validation

AS the ASP model gains favour with time and resource pressed network managers, Packeteer's VP worldwide marketing, Todd krautkremer, looks at creating an application infrastructure.

IMAGINE A FUTURE where service providers handle all of our data rather than storing it on our individual PCs throughout our vast networks. Envision a future where an organisation can focus on its core competencies, instead of its network. This is already beginning to happen with an innovative breed of service providers focused on delivering outsourced application hosting services. This is a new market that is growing rapidly as companies realise the benefits of allowing a service provider to manage their mission-critical applications. Forrester Research Group has estimated that the Application Service Provision (ASP) market will grow from $150m today to $6bn by the end of 2001.

This potentially huge new sector is unsurprisingly a great temptation for service providers and many carriers are planning expansions and partnerships to take advantage of the lucrative ASP opportunity. But the ASP industry is still very much in its infancy and faces complex technical challenges with few accepted standards.

However, ASP will enable organisations, large and small, to outsource their IT requirements, whether this be e-commerce, CRM or ERP systems, or newer services such as net-based telephony and streaming media. But before this can successfully happen a new Internet infrastructure is needed. Service providers have mastered delivery of the network (frame relay, ATM, VPN etc.) by building a flexible network infrastructure. As they move into the application market, service providers enter an entirely new business model requiring new skills and new management tools.

To be successful, ASPs need to create an `application infrastructure' to sit on top of their existing network architecture. It provides a framework for application service level agreements, provisioning, quality of service (QoS), performance analysis, application-based billing, and differentiated services -- essential functions for inspiring customer confidence and forging long-term outsourcing relationships. An application infrastructure facilitates customer trust, cost containment and, ultimately, profitability.

Service providers also have their own valid concerns regarding this emerging field:

* Where is the dividing line between my responsibility and my customer's?

* How do I avoid wasting time and money solving problems that aren't mine?

* How do I ensure my applications live up to commitments?

* Can I validate my applications' good performance upon delivery?

* Can I offer application-based billing?

These types of real-world questions drive the requirements for an application infrastructure, describing many of the needed components and features. Most service providers are familiar with SLAs as commitments regarding uptime or time between failures. But these traditional measurements are insufficient when providers enter the ASP space.

APPLICATION SERVICE LEVEL AGREEMENTS (ASLAs)

A new agreement between customer and service provider is required for this new field, namely the application service level agreement (ASLA). This is a precise, application-specific agreement, specifying the nature and quality of deliverables. They form the foundation of the contract between ASPs and customers. For example, an ASLA might state that at least 96 per cent of the transactions for a Great Plains application delivered with Citrix Meta Frame will complete within 1.5 seconds.

Meaningful, measurable, enforceable ASLAs and the ability to efficiently deliver on them are a large part of any application infrastructure. Managing ASLAs involves the definition, measurement, enforcement and validation of ASP commitments. Effective management requires a reasonable level of integration and cross-communication between the tools that handle these components. This is a tall order and triggers several per-application requirements, among them a well-understood point of demarcation, response time analysis, a method of enforcing performance commitments and a unifying wrapper that puts all the pieces together.

Applications often flow across multiple networks, including those of ASP delivery-chain providers and the customer, before reaching the end user. It is often difficult to determine exactly when and where service-affecting problems arise. An ASP's support costs can spiral out of control as they spend an increasing amount of time troubleshooting problems that fall outside of their responsibility and control. A clear, unambiguous, and application-aware demarcation point (demarc) between provider and customer is critical and defines service boundaries and contains delivery costs.

Unlike a traditional service provider demarc, the ASP demarc must not only provide a geographical location that divides ASP and customer responsibilities, it must also analyse and evaluate deliverables on a per-application basis. A demarc will be of no use if an ASP can not tell if its obligations were met. The demarc determines:

* Where an ASP's responsibility ends.

* How service levels are contracted and validated.

* Which party does diagnostic investigations and support.

A lack of clarity about the nature and destination of ASP deliverables can undermine the most carefully constructed ASP financial plan. The well-placed demarc saves valuable resources, contains costs and facilitates a positive and productive relationship with customers.

It is in the ASP's best interests to offer the customer confirmation and validation of deliverables to build trust and avoid conflict. Both the ASP and the customer need to validate deliverables, although in different ways. The customer wants intuitive confirmation that they got what they paid for. The ASP needs more comprehensive analysis including detailed per-application metrics.

An optimum solution offers:

* High-level graphs and reports for both customers and ASPs, comparing committed performance with actual performance.

* Multiple response time metrics describing delay portions attributed to the server, the ASP network, and the customer network. In other words, response times must describe each side of the demarc. These metrics serve not only as a diagnostic aid but also to substantiate an ASP's pitch for selling managed network services inside the customer's own network.

* Remote access, ensuring that network and system administrators can validate application behaviour from a variety of locations, including the customer's. Browser-based user interfaces are ideal.

* Detailed graphs and reports for ASPs to explore application behaviour to a greater depth for diagnostic or planning purposes. These could cover per-application metrics on average and peak usage, response time, top users, users with the slowest performance, most popular applications or websites, retransmissions and more. In addition, reports should indicate on which side of the demarc problems reside.

* Raw metrics to import into third party reporting applications, allowing all parties to use their favourite tools.

ENFORCEMENT

An ASLA that states application and performance commitments and checks compliance is very helpful, but not helpful enough. ASPs also need the means to enforce ASLAs. In other words, they need to make sure they can and do meet their performance obligations. An optimal solution takes the ASLA as input and then imposes the desired per-application performance.

Suppose an ASP hosts Microsoft Exchange and a Great Plains accounting application running over Citrix MetaFrame. Exchange's timely benefits -- email, information sharing and public folders -- come at the price of Exchange's tendency to consume bandwidth and leave other applications sluggish. The accounting application is business-critical and the ASP needs to deliver consistent, prompt performance. The key to enforcing performance is to differentiate each application needing special treatment and then to appropriately and precisely assign resources, such as bandwidth, that are in contention. These two tasks should be done automatically, using a rule-based system that is configured once in advance and maintained only as needed to reflect business policies.

For example, in the above scenario, Exchange traffic needs to be differentiated from Great Plains traffic so that separate bandwidth controls can be applied. The scenario gets more complex if the ASP adds one more hosted applications, also running over Citrix MetaFrame. If the two Citrix applications need different treatment, then a solution needs to distinguish between them.

Each application needs an appropriate rule covering resource access. Bandwidth is a common resource in contention, but other resources are also important, such as choice of server. For example, the ASP might include the following two rules among those defined for the sample scenario: