Coffee Shop Computing

View from the CloudEditor: George Pallis • [email protected]

52 Published by the IEEE Computer Society 1089-7801/14/$31.00 © 2014 IEEE IEEE INTERNET COMPUTING

Your Coffee Shop Uses Cloud ComputingChristoph Fehling, Frank Leymann, and Ralph Retter • University of Stuttgart

IT applications and physical businesses often face similar challenges: customers

have to be served quickly; throughput and availability should be increased. Here,

the authors cover the architectural design phases of a cloud application and

describe common best practices relevant in each phase. To avoid IT complexity,

they use a coffee shop as a real-world analogy.

I T experts have a long‐established relationship with coffee and related products — you could even call it love. Coffee shops making our

favorite products are places to relax and work, but they can also inspire IT architectures.1 We can transfer a coffee shop’s efforts at increasing the amount of processed orders while optimizing resource use to IT application architectures.

Here, we examine cloud computing patterns,2 capturing best practices for building and managing cloud applications. We abstracted these patterns from existing applications, architecture guidelines, and documentation of cloud offerings to express common, underlying architectural concepts. Each pattern is a similarly structured and human‐read-able document describing an abstract solution to address reoccurring architectural problems in cloud applications. Patterns avoid provider‐ or implementation-language‐specific terminology, thus documenting design knowledge gained from practice in a provider‐independent form.

Patterns and the Coffee Shop AnalogyPatterns can describe the following:

• cloud environments from different providers and how they’re hosted;

• the behavior of different cloud offerings and when to use a certain offering; and

• how to design applications using these offer-ings, and manage them at runtime.

Using patterns, IT architects can compare cloud providers in terms of those patterns they support,

and can design applications without consider-ing the specific offering’s idiosyncrasies too early in the design process. Furthermore, the design knowledge captured in patterns can be more easily applied to different cloud providers.

For fundamental cloud computing patterns, we show that coffee shops similarly handle the five design phases of cloud applications: decomposi-tion, workload, data (state), component refinement, and elasticity and resiliency. In other words, you can experience all the design phases first-hand by buying a coffee.

Figure 1 shows the coffee shop we consider as an analogy. Customers entering the shop form a line waiting to place their orders at a set of cash registers. Employees take the order, collect the payment, and write the customer’s name and desired product on a cup. They then place this cup on a separate table, where it waits for processing by baristas handling the coffee machine for regu-lar coffee products, such as drip coffee or espresso. Baristas also operate a set of blenders for frozen coffee products. After processing, a barista places the finished product on a second table, where the customer retrieves it; here, the information on the cup is used as a correlation identifier.3

Phase 1: DecompositionBy nature, clouds are large distributed systems pro-viding resources for computation, communication, and storage.4 Monolithic applications that com-prise one component and use a single server for hosting do not benefit from this distributed envi-ronment. Instead, cloud application architectures must distribute an application’s functions among

IC-18-05-VftC.indd 52 04/08/14 2:14 PM

Your Coffee Shop Uses Cloud Computing

SEPTEMbER/OCTObER 2014 53

cloud resources.5 The best practice for decomposing application functionality is captured by the distributed applica-tion pattern: a cloud application divides provided functionality among multiple application components that can be scaled out independently (see Figure 2).2

This pattern summarizes three decomposition strategies. Layer‐based decomposition divides the application into layers based on the provided func-tionality — for example, user interface, processing, and data handling layers. Components are assigned to these lay-ers and may interact only with com-ponents on the same layer or one layer below to ensure that interfaces between components are well‐defined and dependencies are reduced.

Process‐based decomposition con-siders the business process the applica-tion supports using modeling languages such as the Business Process Execu-tion Language (BPEL)6 or Business Process Model and Notation (BPMN).7 These business process models are composed of multiple activities, a control flow that describes the activity order, and data elements that the process handles. Individual activities can then enact distributed external functionality, often realized as Web services.8

The coffee shop uses the third decom-position strategy: pipes‐and‐filters‐ based decomposition. Functionality is divided based on the processing func-tion (Figure 2) — user interface, coffee processing, and special processing for frozen coffee. These components inter-act asynchronously via messages — the coffee cups in the request queue and the result queue — that coordinate the pro-cessing between components. After a pipes‐and‐filters‐based decomposition, an application forms a processing pipe-line that continuously handles requests that traverse processing components.

Phase 2: WorkloadThe workload the application experi-ences substantially affects its devel-opment after decomposition. Logical application components are commonly

grouped and assigned to multiple tiers — for example, to multiple virtual serv-ers. Components assigned to a single tier are more tightly integrated than those assigned to different tiers. Com-ponent interaction between tiers thus commonly requires some serializa-tion and deserialization of data and interaction via a network, whereas communication within a tier can omit these steps, resulting in higher perfor-mance. In a cloud environment, tiers can commonly scale independently. Therefore, an IT architect should con-sider the workload that components experience to ensure that those within a tier experience similar workload when logical components are summa-rized to tiers. We differentiate between five workload patterns2:

• IT resources with an equal utiliza-tion over time experience static workload.

• IT resources with a peaking utili-zation at reoccurring time inter-vals experience periodic workload.

• IT resources with an equal utiliza-tion over time disturbed by a strong peak occurring only once experi-ence once‐in‐a‐lifetime workload.

• IT resources with a random and unforeseeable utilization over time experience unpredictable workload.

• IT resources with a utilization that grows or shrinks constantly over time experience continuously changing workload.

In the coffee shop, the user group generates periodic workload: peaks occur in the morning when customers start their day, and in the afternoon when school is out. Because the coffee shop in our example has only one user group, all components experience this workload. So, the periodic workload pattern is annotated to all coffee shop components during this phase, as Fig-ure 2 shows. However, the severity of the peaks differs significantly due to the processing complexity. Whereas handling customer orders at cash reg-isters and placing a cup with a name and order in the request queue have the same complexity for each request, creating a normal coffee is already more complex. For a frozen coffee with whipped cream, chocolate syrup, and sprinkles, this difference becomes even more obvious. The result queue again experiences the same workload as the cash registers, but it typically has a lesser impact here, because the more coffee products are created, the more customers are waiting for them. The result queue rarely needs to store a lot of finished products.

Figure 1. Coffee shop. The process of buying a coffee is a useful analogy to cloud application design.

Alex(Mocha)

Ben(Chai)

Chris(Coffee)

Drew(Latte)

Frank(Frappu.)

Eve(Tea)

IC-18-05-VftC.indd 53 04/08/14 2:14 PM

View from the Cloud

54 www.computer.org/internet/ IEEE INTERNET COMPUTING

In IT applications, we often find a similar impact from workload, where input complexity is similar for all requests, but request handling in the back end has higher complexity. Assigning all the components of such an application to one server and scal-ing the application by adding servers is suboptimal under such conditions. This would equate to building addi-tional coffee shops in warmer regions to handle the higher demand for frozen coffee products, rather than just adding more blenders to one coffee shop.

Phase 3: Data (State)As a prerequisite for later scalabil-ity and resiliency considerations, the location where data are stored and data consistency are extremely impor-tant. This is because the elastic scal-ing of resources and their replacement in case of failures are significantly affected by state information, which might need to synchronize with newly provisioned resources or could be lost during a resource failure. We differen-tiate two types of state. Session state is the state of a user’s interaction with

an application — for example, a shop-ping basket in an online shop. Appli-cation state is the data an application handles, such as the customer data, the currently processed orders, and so on. Two patterns characterize the means by which an application handles these state types2:

• Stateful component. Multiple in stances of a scaled‐out applica-tion component synchronize their internal state to provide a unified behavior.

Figure 2. The coffee shop with patterns applied. Numbers correspond to one of the five cloud application design phases: (1) decomposition, (2) workload, (3) data, (4) component refinement, and (5) elasticity and resiliency. (Patterns are derived from our previous work: www.cloudcomputingpatterns.org.)

Statefulcomponent

Statelesscomponent

Dataabstractor3,14159...

3,14

Eventualconsistency

Userinterfacecomponent

Message-orientedmiddleware

Batchprocessingcomponent

Multi-componentimage

Processingcomponent

Watchdog

Elasticloadbalancer

Elasticqueue

Periodicworkload

User interface

Node-basedavailability

Environment-basedavailability

Request queue

Periodicworkload

Coffee processing

Periodicworkload

Statelesscomponent

Node-basedavailability

Special processing

Periodicworkload

Statelesscomponent

Employees

Customers

Statefulcomponent

Result queue

Periodicworkload

Statefulcomponent

Message-orientedmiddleware

Distributedapplication





Alex(Mocha)

Ben(Chai)

Chris(Coffee)

Drew(Latte)

Frank(Frappu.)

Eve(Tea)

4

2 2 2 2

2

1 1 1 1

1

3 3 3 3

3

3

3

3 4 4

4

4

4

5

5 5 5

5

5

IC-18-05-VftC.indd 54 05/08/14 6:52 PM



• Stateless component. State is han-dled external to application com-ponents to ease their scaling‐out and make the application more tolerant to component failures.

To make stateful components resilient to failures that would lead to data loss, such components often replicate han-dled data. So, changes to the data must be consistent for all replicas. This con-sistency can be either guaranteed at all times or eventually, as data is changed2:

• Strict consistency. Data is stored at different locations to improve response times and avoid loss in case of failures, while replica con-sistency is ensured at all times.

• Eventual consistency. Performance and data availability during net-work partitioning are enabled by ensuring data consistency eventu-ally and not at all times.

Considering the overall number of replicas (n) and the number of replicas accessed during read (r) and write (w) operations, these two patterns mainly differ regarding the enforced ratio. With strict consistency, at least one replica with current data is accessed by enforcing n < w + r. With eventual consistency, this condition is relaxed, and data updates are reflected in rep-licas over time, often by exchanging them via asynchronous messages.

When considering data in the coffee shop during this phase, state informa-tion is kept only in messages — the cof-fee cups with orders and names on them and the customer who knows what he or she ordered. Employees are thus stateless components and more easy to replace — for example, if one needs to use the restroom or goes outside for a smoke. An order’s status in the coffee shop displays eventual consistency to customers, because they’re uncertain about their order status until it’s deliv-ered to the pickup counter. This eventual consistency is supported by implement-ing the data abstractor pattern: data is

abstracted to inherently support even-tually consistent data storage using abstractions and approximations.2

If the business case allows it, the application abstracts the state display, thus inherently letting the state be incon-sistent without the user realizing it. For example, temperature sensors could be abstracted to a change indication, such as “temperature rises” or “temperature decreases.” Available slots in a parking lot might not be indicated as concrete numbers, but as a more abstract traf-fic light. In the coffee shop, employees are usually unable to handle the user request, “Where is my coffee?” Even if the session state is also provided — “Where is the coffee for Chris?” — an employee can answer correctly only if currently holding the respective coffee cup in hand. Otherwise, retrieving the order status from all possible replicas —

that is, the request queues and other employees — would be time consuming. Therefore, employees can most likely not tell an order’s consistent state, but will answer with something like, “It will be ready in about five minutes.” They abstract the inconsistent state and lie a little bit as the business case allows. In IT applications, similar situations can arise where it is more beneficial for the business to be a little creative about state rather than decrease the applica-tion’s performance and availability.

Phase 4: Component RefinementOnce we’ve considered state, we must refine the application’s functional aspects. We use the following two pat-terns for main application functionality2:

• User interface component. Custom-izable synchronous user interfaces are accessed by humans, whereas application‐internal interaction is realized asynchronously to ensure loose coupling.

• Processing component. Elastically scaled components handle process-ing functionality. Functionality is made configurable to support dif-ferent customer requirements.

User interface components handle the synchronous interaction with human users. In the coffee shop, these are the employees at cash registers. Orders and payments are processed syn-chronously here before an employee generates the asynchronous process-ing request (the cup with the name and order). The processing pattern describes how the application can handle these

processing requests by keeping them in a queue and spreading them among multiple processing components, much as baristas will take cups from the request queue, handle the order, and put the finished coffee in the result queue. Also employing this concept is the competing consumer pattern,3 in which multiple message processing compo-nents read from the same input queue and write to the same output queue, thus enabling load balancing. The pro-cessing component can be extended with additional functionality using the following pattern.

With the batch processing compo-nent, requests are delayed until environ-mental conditions make their processing feasible.2 This component waits to han-dle processing requests from the request

Coffee shop employees aren’t as flexible as most cloud resources. Calling them to come to work and sending them home every few minutes would be impractical.

IC-18-05-VftC.indd 55 04/08/14 2:14 PM

View from the Cloud


queue, much like the barista making frozen coffee might wait for multiple similar orders to come in to fill up the blender, thus reducing the overall pro-cessing time compared to making each frozen coffee individually. Similarly, cloud applications could wait for fea-sible conditions, such as low utilization of resources or a reduced resource price to process requests. Of course, the cof-fee shop and cloud applications must both consider the assured service level for this delayed processing. If only one frozen coffee is requested, the customer still expects it to be made in a timely manner.

These user interface and process-ing components must now communi-cate with each other. Message‐oriented middleware provides asynchronous communication while hiding the com-plexity of addressing, routing, or data formats to make interaction robust and flexible.2 This pattern characterizes the behavior of message exchange via queues. In the coffee shop, each cup is handled exactly once, but in cloud applications, message queues can dis-play different behavior. For example, messages could be delivered at least once, affecting components’ interaction with the queue as well as the means to cope with message duplicates.

Finally, the refined functional com-ponents must be assigned to tiers — for example, virtual servers. In this scope, we must consider the follow-ing pattern. With a multi‐component image, virtual servers host multiple application components that might not be active at all times to reduce provisioning and decommissioning operations.2 Multiple components are summarized to an image and are then provisioned and decommissioned as a unit, for example, as one virtual server. This lets the application easily reassign these units to serve as dif-ferent components. In cloud applica-tions, this avoids the time it takes to provision new resources and reduces the overall number of provisioning and decommissioning requests. Such

dynamic reassignments might even enable a non‐cloud infrastructure to allow flexibility, just as the coffee shop does. Coffee shop employees aren’t as flexible as most cloud resources. Call-ing them to come to work and sending them home every few minutes would be impractical. Therefore, coffee shops usually ensure that employees can fulfill different roles: baristas can help out as employees at cash registers and vice versa.

Phase 5: Elasticity and ResiliencyThe last design phase for cloud appli-cations considers how components are provisioned and decommissioned to meet the current workload and cope with failures. Additional management components are added to the applica-tion to ensure elastic scalability and resiliency. For elastic scalability, IT architects must first determine the cur-rent workload and reflect it by adjust-ing resource numbers. The following patterns differ with regard to how they determine the current workload2:

• Elasticity manager. The utilization of IT resources hosting an application determines the number of required application component instances.

• Elastic load balancer. The num-ber of synchronous accesses to an elastically scaled‐out application determines the number of required application component instances.

• Elastic queue. The number of accesses via messaging lets the application adjust the number of required application component instances.

Many cloud providers offer an elasticity manager out of the box that commonly monitors the utiliza-tion of servers running an application. The elastic load balancer and the elas-tic queue consider the actual requests to the application. The load balancer monitors synchronous user requests and scales components accordingly.

The queue does the same for mes-sages handled by a monitored queue. It is thus more flexible in reacting to workload changes and might, for example, wait while messages pile up until their processing is feasible — similar to the batch processing pattern.

To assure resiliency, IT architects must consider both the cloud provid-er’s assured resource availability and error detection to handle failures. We characterize availability using the fol-lowing two patterns2:

• Node‐based availability. A cloud provider guarantees that individ-ual nodes are available, such as individual virtual servers, middle-ware components, or hosted appli-cation components.

• Environment‐based availability. A cloud provider guarantees that the environment hosting individual nodes, such as virtual servers or hosted application components, will be available.

With node‐based availability, the customer knows the availability of resources such as servers or middle-ware deployments that host the appli-cation components as an uptime percentage. Through redundancy, the application’s availability can increase. With environment‐based availabil-ity, the provider does not ensure the availability of individual resources but only of a set of resources or an interface via which the customer or application can provision replace-ment resources. The overall availabil-ity then relies on redundancy and the application’s ability to automatically provision resource replacements in case of failures. We describe failure detection via the watchdog pattern, which we can also use in the scope of node‐based availability: applica-tions cope with failures automatically by monitoring and replacing appli-cation component instances if the provider‐assured availability is insuf-ficient.2 The watchdog, thus, evaluates

IC-18-05-VftC.indd 56 04/08/14 2:14 PM



monitoring information from a cloud provider and verifies correct compo-nent functionality on the application level. In case of failure, the watchdog automatically replaces components.

Scalability and resiliency are also important in the coffee shop. Similar to an elastic load balancer and elastic queue, the number of customers and coffee cups awaiting processing can

determine the required number of work-ers, although provisioning takes longer. The coffee shop also considers avail-ability assurances. The coffee ma chine is vital and provides node‐based

Table 1. Cloud computing patterns.

Icon Pattern Intent

Phase 1: Decomposition

Distributed application A cloud application divides provided functionality among multiple application components that can be scaled out independently.

Phase 2: Workload

Static workload IT resources have an equal utilization over time.

Periodic workload IT resources have a peaking utilization at reoccurring time intervals.

Once-in-a-lifetime workload IT resources have an equal utilization over time disturbed by a strong peak occurring only once.

Unpredictable workload IT resources have a random and unforeseeable utilization over time.

Continuously changing workload

IT resources have a utilization that grows or shrinks constantly over time.

Phase 3: Data (state)

Stateful component Multiple instances of a scaled-out application component synchronize their internal state to provide a unified behavior.

Stateless component State is handled external to application components to ease scaling-out and to make the application more tolerant to component failures.

Strict consistency Data is stored at different locations to improve response time and failure resiliency, while consistency of replicas is ensured at all times.

Eventual consistency Performance and data availability are increased by ensuring data consistency eventually and not at all times.

Data abstractor Data is altered to inherently support eventually consistent data storage through the use of abstractions and approximations.

Phase 4: Component refinement

User interface component Customizable user interfaces are accessed by humans. Application-internal interaction is realized asynchronously to ensure loose coupling.

Processing component Processing functionality is handled by elastically scaled components. Functionality is made configurable to support different requirements.

batch-processing component Requests are delayed until environmental conditions make their processing feasible.

IC-18-05-VftC.indd 57 04/08/14 2:14 PM

View from the Cloud


availability. It is thus maintained fre-quently to keep this availability as high as possible. Employees, on the other hand, “fail” often due to sickness, rest-room breaks, and so on. Therefore, the overall set of employees ensures envi-ronment‐based availability to custom-ers — even if one fails, another will take over to make the coffee.

Lessons LearnedIn the coffee shop, we found many best practices that are common in the real world to ensure high‐availability and high processing throughput. We can transfer these to cloud applications using the discussed patterns, which are summarized in Table 1. During the five cloud application design phases, we learned the following lessons.

DecompositionBecause cloud environments are large distributed systems by nature, IT archi-tects must decompose a cloud applica-tion’s functionality into components.

These components can then be hosted on multiple cloud resources. This decomposition into separate compo-nents forming a processing pipeline is also visible in the coffee shop.

WorkloadEven though application components might experience the same workload type, the actual processing complexity can differ significantly. Scaling an appli-cation as a holistic unit — for example, by hosting all application components on a single server — can, therefore, be very inefficient. Similarly, a coffee company would not scale to meet an increased demand for frozen coffee products in warmer regions by building more cof-fee shops. It would simply increase the number of blenders in a shop.

Data (State)Whenever possible, the application components should not handle ses-sion and application states. Instead, such states should be kept in requests

or in communication and storage offerings. In a coffee shop, employees do not memorize the order status or communicate it directly; the coffee cups act as an asynchronous form of communication to manage state. Fur-thermore, an application should “lie” about the actual state whenever the business case allows it, because this makes scaling and resiliency less com-plex to handle. Coffee shop employees most likely handle inquiries about an order status in this fashion by simply approximating the remaining time.

Component RefinementUser interface and processing compo-nents should interact asynchronously. The tiers that are scaled, such as vir-tual servers, should be configured to possibly fulfill the functionality of multiple application components. This lets the application reassign resources more flexibly. Similarly, a coffee shop manager will train employees to fulfill different roles.

Table 1. (Continued)

Message‐oriented middleware

Asynchronous communication is made robust and flexible by hiding the complexity of addressing, routing, or data formats.

Multi‐component image Virtual servers host multiple components that might not be active at all times to reduce provisioning and decommissioning operations.

Phase 5: Elasticity and resiliency

Elasticity manager The use of IT resources on which an application is hosted is used to adjust the number of required application component instances.

Elastic load balancer The number of synchronous accesses is used to adjust the number of required application component instances.

Elastic queue The number of accesses via messaging is used to adjust the number of required application component instances.

Node‐based availability A cloud provider guarantees the availability of individual nodes, such as virtual servers, middleware, or hosted application components.

Environment‐based availability

A cloud provider guarantees the availability of the environment hosting individual nodes, such as virtual servers or application components.

Watchdog Applications cope with failures automatically by monitoring and replacing faulty application component instances.

All patterns are adapted from our book.2

IC-18-05-VftC.indd 58 04/08/14 2:14 PM



Elasticity and ResiliencyCloud applications should respect a provider’s availability assurances. With low node‐based availability or environ-ment‐based availability, a watchdog can help identify and handle failures. The coffee shop manager commonly fulfills this role in the real world.

Overall, we have seen that real-world businesses employ many concepts

that make cloud applications scalable and resilient toward resource failures. These concepts should thus be com-mon knowledge. However, IT appli-cation designers often neglect these concepts, creating holistic applica-tions that are hard to manage during runtime. The patterns we’ve discussed here capture these concepts common in the real world with an IT‐specific viewpoint. Their detailed descriptions and a lot more patterns are available in our book.2

AcknowledgmentsThis work was partially funded by the Co.M.B.

project of the Deutsche Forschungsgemeinschaft

(DFG) under the promotional references SP

448/27-1, LE 2275/5-1. The pattern icons and the

coffee shop graphic have been released under the

creative commons attribution share alike license:

www.cloudcomputingpatterns.com.

References1. G. Hohpe, “Your Coffee Shop Doesn’t Use

Two‐Phase Commit,” IEEE Software, vol.

22, no. 2, 2005, pp. 64–66.

2. C. Fehling et al., Cloud Computing Patterns:

Fundamentals to Design, Build, and Man-

age Cloud Applications, Springer, 2014.

3. G. Hohpe and B. Woolf, Enterprise Inte-

gration Patterns: Designing, Building, and

Deploying Messaging Solutions, Addison‐

Wesley, 2004.

4. P. Mell and T. Grance, The NIST Definition

of Cloud Computing, US Nat’l Inst. of Stan-

dards and Technology (NIST), 2011.

5. J. Varia, “Architecting for the Cloud: Best

Practices,” Amazon white paper, 2010; http://

jineshvaria.s3.amazonaws.com/public/

cloudbestpractices-jvaria.pdf.

6. Web Services Business Process Execution

Language Version 2.0, Oasis, 2007.

7. Business Process Model and Notation

(BPMN) Version 2.0, Object Management

Group, 2011.

8. S. Weerawarana, F. Curbera, and F. Ley-

mann, Web Services Platform Architecture:

SOAP, WSDL, WS-Policy, WS Addressing,

WS-BPEL, WS-Reliable Messaging, and

More, Prentice Hall, 2005.

Christoph Fehling is a research associate and

PhD student in the Institute of Architecture

of Application Systems at the University of

Stuttgart, Germany. His research interests

include IT architecture patterns focused

especially on cloud computing. Fehling

received a Dipl.-Inf. in computer science

from the University of Stuttgart. He is a

member of the Hillside Group. Contact him

at [email protected].

Frank Leymann is a full professor of com-

puter science and director of the Institute

of Architecture of Application Systems at

the University of Stuttgart, Germany. His

research interests include service-oriented

architectures and associated middleware,

workflow and business process manage-

ment, cloud computing and associated sys-

tems management aspects, and patterns.

Leymann is an invited expert to consult

for the European Commission in the area

of cloud computing. Contact him at frank.

[email protected].

Ralph Retter is an architect at Bosch Softtec,

where he works on connected vehicle top-

ics. He received a PhD in computer science

from the University of Stuttgart. Retter is a

frequent speaker at conferences and a coau-

thor of the book Cloud Computing Patterns

(Springer, 2014). Contact him at ralph.retter@

gmx.net.

Selected CS articles and columns are also available for free at http://

ComputingNow.computer.org.

N e w s l e t t e r sStay Informed on

Hot Topics

computer.org/newsletters

IC-18-05-VftC.indd 59 04/08/14 2:14 PM

Documents

Coffee Shop Computing