Decompose the Application by Workload
Applications are typically composed of multiple workloads. Different workloads can, and often do, have different requirements, different levels of criticality to the business, and different levels of financial consideration associated with them. By decomposing an application into workloads, an organization provides itself with valuable flexibility. A workload-centric approach provides better controls over costs, more flexibility in choosing technologies best suited to the workload, workload specific approaches to availability and security, flexibility and agility in adding and deploying new capabilities, etc.
Scenarios
When thinking about resiliency, it’s sometimes helpful to do so in the context of scenarios. The following are examples of typical scenarios:
Scenario 1 – Sports Data Service
A customer provides a data service that provides sports information. The service has two primary workloads. The first provides statistics for the player and teams. The second provides scores and commentary for games that are currently in progress.
Scenario 2 – E-Commerce Web Site
An online retailer sells goods via a website in a well-established model. The application has a number of workloads, with the most popular being “search and browse” and “checkout.”
Scenario 3 – Social
A high profile social site allows members of a community to engage in shared experiences around forums, user generated content, and casual gaming. The application has a number of workloads, including registration, search and browse, social interaction, gaming, email, etc.
Scenario 4 - Web
An organization wishes to provide an experience to customers via its web site. The application needs to deliver experiences on both PC-based browsers as well as popular mobile device types (phone, tablet) The application has a number of workloads including registration, search and browse, content publishing, social commenting, moderation, gaming, etc.
Example of Decomposing by Workload
Let’s take a closer look at one of the scenarios and decompose it into its child workloads. Scenario #2, an ecommerce web site, could have a number of workloads – browse & search, checkout & management, user registration, user generated content (reviews and rating), personalization, etc.
Example definitions of two of the core workloads for the scenario would be:
Browse & Search enables customers to navigate through a product catalog, search for specific items, and perhaps manage baskets or wish lists. This workload can have attributes such as anonymous user access, sub-second response times, and caching. Performance degradation may occur in the form of increased response times with unexpected user load or application-tolerant interrupts for product inventory refreshes. In those cases, the application may choose to continue to serve information from the cache.
Checkout & Management helps customers place, track, and cancel orders; select delivery methods and payment options; and manage profiles. This workload can have attributes such as secure access, queued processing, access to third-party payment gateways, and connectivity to back-end on-premise systems. While the application may tolerate increased response time, it may not tolerate loss of orders; therefore, it is designed to guarantee that customer orders are always accepted and captured, regardless of whether the application can process the payment or arrange delivery.
Comments
Post a Comment