figure 5. saas application interface from the back-end to the front-end.
incoming Read
Requests
A-e
A-e
A-e
F-j
F-j
F-j
K-o
K-o
K-o
P-t
P-t
P-t
u-Z
u-Z
u-Z
cess session state are easy to call. This
provides support for a scalable and robust SaaS application.
The application session state, application reference-data cache, and
calls to other services are available as
concierge services. The platform prescribes how to access these services,
and the application need not know
what it takes to build them. By constraining the application functionality, the platform can increase the concierge services.
A-e
F-j
K-o
Automatic Pub-Sub
distribution of
updates
An example of session state is a shopping cart on an e-commerce site such
as Amazon.com.
The plumbing for the session-state
manager handles scaling. As the number of sessions grows, the session-state manager automatically increases
its capacity.
This plumbing is also responsible
for the durability of the session state.
Typically, the durability requirements
mandate that the session state survive
the failure of a single system. Should
this be written to disk on a set of systems in the cloud? Should it be kept in
memory over many systems to provide
acceptable durability? Increased durability requires more system implementation cost and may require increased latency to ensure the request
is durable.
Typically, a session-state manager
is used so frequently that it must provide a very aggressive SLA for both
reads and writes. A 5ms or 10ms guarantee is not unusual. This means it
is not practical to wait for the session state to be recorded on disk. It
is common for the session state to be
acknowledged as successfully written
when it is present on two or three replicas in memory. Shortly thereafter, it
will likely be written to disk.
Applying changes to the back end.
P-t
u-Z
Feeds
from
Partners
Backend
Processing
(Feed and Crawl)
Crawl
the Web
Sometimes, front-end requests actually “do work” and apply application
changes to the back end. For example,
the user pushes Submit and asks for its
work to be completed.
Application changes to the back end
may be either synchronous, in which
the user waits while the back end gets
the work done and answers the request; or asynchronous, in which the
work is enqueued and processed later.
Amazon.com provides an example of asynchronous back-end app
changes. When the user presses Submit, a portion of the front end quickly
acknowledges the receipt of the work
and replies that the request has been
accepted. Typically, the back end
promptly processes the request, and
the user receives an email message in a
second or two. Occasionally, the email
message takes 30 minutes or so when
the asynchronous processing at the
back end is busy.
Automatic services, state, and data.
By understanding the usage pattern of
a SaaS application, the platform can
lessen the work needed to develop an
application and increase its benefits.
As suggested in Figure 3b, the application should simply worry about its
business logic and not about the sys-tem-level issues. Interfaces to call other services, access cached data, and ac-
Patterns in saas applications:
the Back end
This section explores the patterns used
in the back-end portion of a typical
SaaS application. What does this back
end do for the application? How does it
typically do it?
The back end of a SaaS application
receives data from a number of sources:
˲ Crawling. Sometimes the back end
has applications that look at the Internet or other systems to see what can be
extracted.
˲ Data feeds. Partner companies or
departments may send data to be ingested into the back-end system.
˲ Logging. Data is accumulated about
the behavior of the front-end system.
These logs are submitted for analysis
by the back-end system.
˲ Online work. Sometimes, the front
end directly calls the back end to do
some work on behalf of the front-end
part of the application. This may be
called synchronously (while the user
waits) or asynchronously.
All of these sources of data are fed
into the back end where they are remembered and processed.
Many front-end applications use
reference data that is periodically updated by the back end of the SaaS application. Applications are designed to
deal with reference data that may be
stale. The general model for processing reference data is:
1.Incoming information arrives
at the back end from partners’ feeds,
Web crawling, or logs from system activity. Online work may also stimulate
the back-end processing.
2. The application code of the back
end processes the data either as batch
jobs, event processing with shorter latency, or both.
3. The new entries in the reference-