figure 3. (a) the typical front-end saas application pattern. (b) the application’s focus on
business logic.
4
other
Service
5
Service
Request
1
6
Response
Application
data Cache 7
Session
State
2
8
Backend
Feed Processing
Session State
Manager
(a)
Session-state management. As each
request with a partner is processed, it
has the option to record session state
that describes the work in progress
for that partner. This is automatically
managed so that subsequent requests
can easily fetch the state to continue work. The session-state manager
works with dynamically scalable and
load-balanced services. It implements
the application’s policy for session-state survival and fault tolerance.
Each of these concierge services depends on the application abiding by
the constraints of the usage pattern
as described for the typical front-end
SaaS application.
other
Service
Service
Request
Response
Application
data Cache
Session
State
Backend
Feed Processing
Session State
Manager
(b)
requests arrive at the system and are
processed with a request-response pattern using session state, other services,
and cached reference data.
When a front-end application fits
into the constraints of the pattern just
described, a lot of concierge services
may be supplied to the application.
These services simplify the development of the app, ease the operational
challenges of the service, and facilitate
sharing of cloud resources to efficiently meet SLAs defined for the applications. Some possible concierge services include:
Auto-scaling. As the workload rises,
additional servers are automatically allocated for this service. Resources are
taken back when load drops.
Auto-placement. Deployment, migration, fault boundaries, and geographic
transparency are all included. Applications are blissfully ignorant.
Capacity planning. This includes
analysis of traffic patterns of service
usage back to incoming user work-
load. Trends in incoming user work-
load are tracked.
stateless Request Processing
Incoming requests for a service are
routed to one of many servers capable
of responding to the request. At this
point, no state is associated with the
session present in the target server
(we will get it later if needed). It is reasonable to consider this a stateless
request (at least so far) and select any
available server.
The plumbing keeps a pool of servers that can implement the service.
Incoming requests are dynamically
routed and load balanced. As demand
increases and decreases, the concierge
services of the plumbing can automatically increase and decrease the number of servers.
Composite request processing.
Frequently, a service calls another service to get the job done. The called service may, in turn, call another service.
This composite call graph may get
quite complex and very deep. Each of
these services will need to complete to
build the user’s response. As requests
come in, the work fans out, gets processed, and then is collected again. In
2007, Amazon reported that a typical
request to one of its e-commerce sites
resulted in more than 150 service requests. 4 Many SaaS applications follow the pattern shown in Figure 3a:
1. A request arrives from outside (
either Web service or HTML).
2. The service optionally requests
its session state to refresh its memory
about the ongoing work.
3. The response comes back from
the session-state manager.
4. Other services are consulted if
needed.
