Cloud Application Architecture Patterns

Chapter 1. Cloud Applications

A Note for Early Release Readers

With Early Release ebooks, you get books in their earliest form—the author’s raw and unedited content as they write—so you can take advantage of these technologies long before the official release of these titles.

This will be the 1st chapter of the final book.

If you have comments about how we might improve the content and/or examples in this book, or if you notice missing material within this chapter, please reach out to the editor at [e-mail].

Cloud computing is revolutionizing information technology. As the IT environment evolves, application architectures need to evolve to take advantage of the new technology, and IT professionals need to evolve their skills to succeed with the new technology. These cloud application techniques apply to developing a new application so that it will run well on cloud as well as migrating an existing application from traditional IT to cloud computing.

Introduction to Cloud Applications

Some readers may wonder why applications need to be structured differently for cloud. To explain why, let’s cover a couple of background topics:

• Cloud computing defined - How IT infrastructure in the cloud works

• Cloud computing practices - IT practices for making applications work with cloud computing

Then, once we’re all on the same page, we’ll go to the first pattern, which is the root pattern for this entire book, Cloud Application.

Cloud computing defined

Let’s begin with what we mean by “the cloud.”

As the saying goes, the cloud is just someone else’s computer. However, a cloud is way more useful than just a computer. What makes a cloud valuable is that someone made a bunch of their computers available for you to use, enabled you to manage your own usage, and enabled their computers to be shared by others as well as you.

The National Institute of Standards and Technology (NIST) provides this definition of cloud computing:

Cloud computing is a model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction.

Cloud computing has several qualities that make a pool of configurable computing resources easy to share:

• Universal access — A cloud can be accessed from any network connection, typically the internet but an enterprise may host its own private cloud internally and public clouds can support private network connections.

• Shared resources — A cloud enables multiple applications to run on the same hardware. Capacity that is not being used by one application is available to be used by others.

• Distributed computing — A cloud isn’t just one computer, it’s lots of computers, plus storage and networking, which acts like one huge computer. An application doesn’t run on just one computer, it runs on several and the parts need to work together over the network.

• Virtualized computing — The cloud’s compute, storage, and networking hardware is managed by a layer of virtualization that can divvy up one computer to act like many smaller ones as well as combine many computers to behave like one large computer—the cloud—with a giant pool of capacity.

• Elastic computing — An application is not limited to a fixed amount of capacity. The capacity can grow and shrink dynamically as the client load on the application changes.

• Multitenant — Multiple users and organizations share a cloud. The cloud controls who has access to which applications and resources and enforces isolation between them.

• Self-service — When an organization wants to provision some capacity or deploy a workload, they don’t send a request to the cloud’s central administration staff. Users are able to perform these tasks themselves.

• API-driven — The resources and services that comprise the cloud are used and managed via APIs. Some APIs are only available internally, enabling the cloud provider to monitor and manage the cloud. Other APIs are available externally, enabling self-service by the customers.

• Multicloud — As much as it’s convenient to think of “the cloud,” there isn’t just one cloud, there are lots of them: Ones for different stages of the software development lifecycle (SDLC), for different geographies, and for different lines of business. Multiple vendors host different public clouds, and enterprises host their own private clouds.

These qualities are what make a cloud more than just someone else’s computer.

Now we have a basic idea of what the cloud is. Next, to understand why cloud applications are different and need to be developed differently, let’s review how cloud computing compares with traditional IT.

Cloud computing practices

As developers create applications to be deployed on traditional IT, they bake into the application a number of assumptions about how the hardware works, and therefore how the application can and should work. When an application is going to be deployed on cloud computing, many of these assumptions are significantly different.

Cloud computing has certain characteristics that differ from traditional IT and affect how cloud applications need to work:

• Reliability through redundancy — A traditional IT application is only as reliable as its hardware, so developers tasked with making their applications reliable expect either 100% reliable hardware or accept downtime as unavoidable. Cloud computing embraces inexpensive commodity machines, any one of which is less than 100% reliable, together with realizing that planned outages are necessary for maintenance and unplanned outages can’t be avoided completely. To run reliably on unreliable infrastructure, a cloud application must be more reliable than its infrastructure, which it achieves by using redundancy.

• Eventual consistency — A traditional IT application uses ACID transactions to enforce immediate consistency, even distributed across multiple resources, requiring the complexity and overhead of a transaction manager, concurrency locking, rollback, recovery, and retry. Cloud computing services employ eventual consistency. Cloud application developers cannot depend on distributed transactions and must design for eventual consistency, which counterintuitively actually makes the applications more reliable.

• Generic hardware — A traditional IT application typically requires specific hardware, whereas cloud computing provides generic hardware that will evolve in the future. A cloud application must be infrastructure neutral so that it can run anywhere.

• Application mobility — Traditional IT developers assume that once an application is deployed on a computer, it will always run on that computer. Cloud computing moves a running application from one computer to another to balance load and avoid outages. A cloud application must be transportable so that that cloud platform can easily relocate it and it will keep working after relocation.

• Multitenant — Developers design a traditional IT application to be the only one running on a computer and to use all of its resources. Cloud computing often runs multiple applications on the same computer and isolates each one to limit the resources it can use. A cloud application must be designed to share its hardware.

• Horizontal scaling — A traditional IT application runs on a single computer and scales by growing on that computer, whereas cloud computing scales a cloud’s capacity by adding more computers and scales a workload by running it on multiple computers. To support scaling across multiple computers, a cloud application must be able to run as multiple copies that act like a single bigger application running on one big computer. Multiple copies also makes the application more reliable by avoiding a single point of failure. Horizontal scaling can be applied manuallly or automatically.

• Stateless — A traditional IT application stores user data for long-term use by multiple units of work. A cloud application loads data to perform a unit of work but must not store data between units of work.

• Immutable — When bugs are found in a traditional IT application, fixes are applied by patching the running application. A cloud application is deployed as a release that does not change while running.

• Componentized — A traditional IT application is often a single complex set of code with little separation of concerns, all deployed in a large process that requires a large computer. Cloud computing hosts workloads on parts of multiple smaller computers. A cloud application runs better when designed as multiple components with limited interdependencies that can each run on a different computer.

• Service catalog — Many traditional IT applications either implement their own low-level services like data persistence and multithreading, or must be deployed into an application server that includes middleware services the applications require. Many cloud computing platforms provide a catalog of reusable middleware services. As much as practical, a cloud application should delegate middleware functionality to shared services.

• Cloud database — A traditional IT application stores all of its data in a single relational database that the application must force fit its data into, whereas cloud computing platforms often provide a variety of database types that are easy to provision and can fit different types of data more naturally. A cloud application should provision databases from the cloud platform’s service catalog and should use the best database for each set of data.

• Self-provisioning — When a development team needs a traditional IT environment provisioned for their application, they submit requests and the IT’s central operations team performs the provisioning. For a cloud environment, that same development team can perform the provisioning themselves. A cloud application should be designed to deploy into a cloud environment that is self-provisioned.

These differences explain how an application developed for cloud needs to work differently than one developed for traditional IT. They also show how a traditional IT application moved as-is to the cloud doesn’t work as well in the cloud as an application designed specifically for the cloud. The more an application’s design takes advantage of these cloud capabilities, the better it will run in the cloud. As you can see, adopting the cloud means that application developers need to adopt a new mindset embodying a new set of practices.

We’ve now seen what the cloud is and how cloud computing differs from traditional IT. With all of that under our belts, it’s time to begin discussing how to architect applications for the cloud. We’ll start with the root pattern for this entire book, Cloud Application.

Cloud Application

You are developing a new application or modernizing an existing application. You want your application to take advantage of cloud technology, both so that it will run better and so that your team will be able to follow better development practices.

How can I build applications to take the maximum advantage of all the features of the cloud for the best future proofing and agility?

Experienced application developers who are new to cloud are used to developing traditional IT applications and tend to fall back on those practices out of habit. Those practices tend to develop an application that doesn’t work well on cloud, so even a newly developed application doesn’t work much better on cloud than a traditional IT application migrated onto cloud with minimal changes. The developers either ignore these limitations or get into a game of whack-a-mole trying to fix problems in code that wasn’t designed well for cloud.

Cloud offers highly-desirable capabilities that traditional IT applications cannot take advantage of:

• Low cost, commodity hardware - Traditional IT applications expect hardware to be specialized and highly reliable, but cloud infrastructure usually is not.

• Grid computing - Traditional IT applications hardcode assumptions about the hardware they will be deployed on, whereas cloud is a loosely-defined pool of hardware and the application could be deployed anywhere.

• Unlimited scalability - Traditional IT applications are not designed to take advantage of the seemingly infinite compute capacity of cloud.

Traditional IT applications are unable to take advantage of these cloud capabilities. These characteristics that work fine for traditional IT applications work poorly in the cloud:

• Monolithic - A traditional IT application is typically architected as one big program that runs on a single computer.

• Complex transactions - A traditional IT application typically performs several steps that must all complete successfully or none of them should, requiring that all of the steps are performed in a transaction and each step can roll back.

• Infrastructure dependent - A traditional IT application is typically designed for a particular operating system with device drivers for specific hardware.

• Stationary - A traditional IT application is typically deployed once to run forever on a computer that is expected to run forever.

• Vertical scaling - A traditional IT application can scale only as much as its computer is able, becoming constrained by its computer’s limits on CPU, memory, storage and network bandwidth.

• Stateful - A traditional IT application stores data in memory instead of a database to avoid database transactions.

• Patchable - To fix bugs and add features in a traditional IT application, patching is often preferred because a new version of the application that includes the fixes would be too difficult to redeploy.

• Exclusive resources - A traditional IT application is typically designed to be the only application running on a computer, such that two applications may conflict.

• Homogeneous data - A traditional IT application typically stores all of its data in a single enterprise database of record with a strictly defined one-size-fits-all schema.

Developers may naturally design traditional IT applications with these characteristics, but these characteristics will make an application work badly in the cloud. Developers designing applications for cloud need newer approaches that work better in cloud.

Therefore,

Architect an application as a cloud application, designing it to take maximum advantage of the capabilities of cloud while avoiding its shortcomings.

Structure a cloud application as a distributed set of microservices that takes advantage of backend services provided by the cloud platform, accessed by client applications that run outside the cloud. (See Figure 1-1.)

Figure 1-1. Cloud Application

Developers adopting cloud need to make a conscious effort to develop applications with these qualities, to design the application to take advantage of the strengths of cloud (such as shared resources and elastic computing) while working around its weaknesses (such as unreliable infrastructure and eventual consistency).

Cloud application design avoids the characteristics that make traditional IT applications run on cloud less effectively and instead embodies these corresponding characteristics:

• Modular and distributed - A cloud application is composed of multiple components that can run on multiple computers.

• Simple transactions - A cloud application performs tasks as units that can succeed or fail independently.

• Infrastructure independent - A cloud application can run unchanged on a range of commodity hardware that evolves over time.

• Movable - The cloud can relocate a cloud application from one computer to another to balance load and avoid outages.

• Horizontal scaling - A cloud application can run across multiple computers, each with its own resources and bandwidth, avoiding bottlenecks.

• Stateless - A cloud application works best when the latest data is always persisten in the databases.

• Immutable - A cloud application does not change after it is deployed and can always easily be redeployed.

• Shared resources - Multiple cloud applications often run on a single computer.

• Data persistence flexibility - A cloud application often uses multiple databases designed for different tasks with varying approaches to storing data.

These characteristics of a more flexible application can be nice to have on traditional IT and are practically required to run well on cloud.

---

Some of the main benefits of building Cloud Applications are availability, scalability, and flexibility. An application developed for the cloud tends to more modular, modules that can be deployed and scaled independently of other parts of the application.

As explained in this chapter’s “Introduction to Cloud Applications”, designing applications for cloud is fairly different from the way traditional IT applications are designed. Organizations accustomed to developing applications for traditional IT may find cloud difficult to adopt until they adopt these new architectural approaches for cloud applications.

Follow these best practices and related patterns to architect an application that works well in cloud:

• Cloud native - The application is a Cloud-Native Application, embodying a Cloud-Native Architecture that takes advantage of cloud capabilities.

• Microservices - The application is not just cloud native but can be implemented as a Distributed Architecture, usually incorporating a Microservices Architecture composed of Microservices that modularize the application into decoupled components that limit the boundaries of code changes and can run distributed across multiple computers. This supports Polyglot Development so that each module can be implemented in a different language. The microservices incorporate a Microservice Design that models the enterprise’s business domain and the user requirements.

• Event driven - While it is typical for a business process or microservice to orchestrate preplanned work of other microservices, it can also be helpful to use an Event-Driven Architecture of Reactive Components to choreograph ad hoc interactions between microservices.

• Cloud storage - The application takes advantage of Cloud-Native Storage that is scalable and reliable in the cloud. A cloud platform typically includes a variety of Cloud Databases, each of which is optimized for a particular data structure and usage, so an application can take advantage of Polyglot Persistence to segment data into encapsulated sets and store each set of data in the storage technology that works best for that data.

• Client applications - The application running on the servers in the cloud supports a variety of Cloud Application Clients, with different Client Applications for different platforms such as computers, mobile devices, and even other applications.

Cloud applications facilitate an application development process that makes agile development easier to achieve. A cloud application can be the goal of developing a new application from scratch, or can be the result of Application Migration and Modernization that transforms an existing traditional IT application into a cloud application.

One of the most difficult aspects of modernization can be transforming an application while it is already being used in production. One way to address this is to Strangle the Monolith which transforms an application incrementally while keeping the existing application running.

Examples

Some examples of applications hosted on the cloud using a cloud application architecture:

• E-commerce: A retailer’s website that enables consumers to purchase products for mail-order delivery.

• Banking: A customer self-service website which enables customers to view their accounts, deposit checks, and transfer money.

• High performance computing (HPC): An enterprise uploads data to cloud for analysis and processing by artificial intelligence.

E-commerce: Three-tier architecture

An e-commerce application enables its users to order products, often by placing them in a shopping cart and checking out to make payment and place the order for delivery. Purchasing mail-order products was first performed by telephone, then later by website. The telephone customer service representative used an application hosted on traditional IT, often hosted in the computer on their desk. The first websites, though accessible over the web, were hosted in traditional IT on servers that were little more than fancy desktop computers. As cloud became commonplace, these applications became hosted on the cloud.

Whether the user is the customer buying products or a representative facilitating the purchase, the architecture for the cloud application is the same. The application has functionality and databases for customers purchasing products. Both the customer and representative access the cloud application via client applications that run in web browsers, on mobile devices, and even as thick clients deployed on desktop computers.

Figure 1-2. E-commerce Cloud Application

As Figure 1-2 shows, the business logic for purchasing products runs as a program hosted in the cloud. In this example, the business logic and its corresponding data consists of product catalogs, warehouse inventories, customers, and orders. The enterprise has an existing payment processing system still hosted on traditional IT that is PCI (payment card industry) compliant, so the cloud application uses it to manage payments. The warehouse has an existing inventory management system hosted on-site on traditional IT, which the cloud application uses to query product availability. Customers can make self-service purchases by accessing the website in a web browser or using a mobile application. If the customer calls to place their order, the customer service representative uses the same cloud application but accesses it via their own client, perhaps a thick client application running on their desktop terminal.

Banking: System of engagement

Many enterprises have existing systems of record (SoRs) that cannot be moved to cloud (or at last haven’t been moved so far). Yet cloud can still be helpful for making those systems accessible to large numbers of users across a variety of user interfaces. To do so, the enterprise implements a system of engagement (SoE) deployed in cloud that provides controlled access to functionality in the SoRs. The SoE provides a new customer experience through a single modern user interface such as a web browser that facilitates access to existing SoR functionality. In both a three-tier cloud application and an SoE cloud application, the middle tier runs in the cloud. In a three-tier application, the middle tier contains the majority of the domain logic, relying on existing SoRs relatively little. In an SoE, the middle tier is mainly a facade that delegates to the SoRs for all domain logic and computation. Whereas the SoRs are difficult to use because of their legacy technology–such as COBOL copybooks, a limited number of concurrent network connections, batch processing–SoEs use modern technology–such as JSON and XML, web services, scalability for a huge numbers of concurrent users. The SoE adapts the SoRs so users can access them as a unified, modern application.

Consider a bank that wants to make its customers and partners able to interact directly with its financial services. Those services are often provided by systems of record that almost certainly do not run in cloud and will not be migrated anytime soon. Rather than rewrite these business-critical systems, and rather than giving public Internet users direct access to these business-critical systems, an SoE running in the cloud can scale to support numerous concurrent users on a variety of devices with security to control access to the SoRs via a limited number of shared connections. The SoE provides the external functionality while reusing the existing systems to implement much of that functionality.

The bank may rely on existing systems to manage different types of accounts–such as checking, savings, mortgages, credit cards. These systems may not even know that multiple accounts are owned by the same customer, or that two customers with separate accounts also own a joint account. Part of the goal for an SoE is to enable a customer to see all of their accounts and manage them together, such as transferring funds between accounts.

Another driver for a system of engagement is supporting new types of client applications made possible by the Internet. Whereas bank tellers used to access the bank’s systems of record via dumb terminals, customers today want self-service access to their accounts using websites and mobile apps. Meanwhile, other devices like ATMs (automatic teller machines) need access. Telephone customer service representatives, bank tellers, and even telephone voice prompt systems and Internet chatbots need access to these systems and need to be able to see all of the accounts for a customer. This system of engagement is a new application and should be developed to run in the cloud.

Figure 1-3. Banking Cloud Application

Notice that this banking architecture diagram (Figure 1-3) looks a lot like the e-commerce architecture diagram (Figure 1-2). This is the basic architecture of a cloud application. The business domains–e-commerce and banking–are very different, but the cloud architectures are very similar.

Figure 1-3 shows a bank with:

• Systems of record (SoRs): Existing applications in the enterprise, such as ones for different types of accounts like checking, savings, mortgages, and credit cards

• Client applications: New client types such as web browsers and mobile apps, and support for new and existing roles like tellers, ATMs, and customer service agents

• System of engagement (SoE): A program in the middle, hosted in the cloud, that integrates with the SoRs to reuse their functionality, and that is able to support the range of client applications and large numbers of concurrent users

An SoE can be thought of as a facade for the SoRs, but it’s a very powerful facade. It implements security to protect the SoRs and control which users can access what. Most SoRs were never designed to handle very many concurrent users, but SoEs scale to handle large numbers of users connecting at the same time over the Internet and internal networks, managing a small number of connections to the SoRs and sharing them amongst a large number of users.

The cloud makes it possible for many old school businesses–such as banks, insurance companies, airlines, hotels, phone companies, utility companies, hospitals, ticket sellers–to make their old technology new again without changing it by adding a system of engagement that reuses what they already have and exposes it in new ways.

Data analytics: Cloud-scale job management

High performance computing (HPC) hardware such as high performance GPU (graphics processing unit) CPUs can greatly accelerate performing analytics and artificial intelligence on data. An enterprise can avoid the expense of installing HPC hardware in their own data center by instead using the compute capacity in a cloud. Not only will the cloud vendor incur the expense of continuously installing the latest model GPUs, it can also provide large capacities that enable more data to be analyzed concurrently. If the enterprise only needs the capacity at specific times, rather than own capacity that often sits idle, it can pay-as-you-go: rent cloud capacity only when needed and pay for only what they use.

To facilitate this model, the enterprise doesn’t have to store its data in the cloud. Instead, it can break its data into sets and sends them to the cloud to process in batches. Figure 1-4 shows the architecture.

Figure 1-4. HPC Cloud Application

The client application runs where the data is stored, often in its own data center. That application breaks the data into jobs, then uploads each job for the cloud to perform and receives the results. Each job is managed in the cloud serverlessly. The cloud may have the capacity to manage large numbers of jobs concurrently, perhaps in multiple data centers in multiple locations. Multiple enterprises can submit jobs to be managed, all sharing the cloud’s capacity and each paying only for the capacity they use. The data is not stored in the cloud long-term, so access to it in the cloud is limited.

Some public clouds make uploading data expensive. If multiple jobs will upload the same data, it can be stored on the cloud instead so that it only has to be uploaded once. If all of the on-prem data will eventually be processed as jobs, the cloud database can be a replica of the on-prem database, such that synchronizing the replica keeps the data current.

A domain-specific example of cloud-scale job performance: A user’s survey equipment could take numerous photographs of a large terrain over time and upload them to the cloud for visual analysis using artificial intelligence. The AI could identify the photos that show interesting anomalies and send their IDs back to the user, filtering for the interesting photos far faster than people could. When the equipment takes lots of photos, the cloud can scale to process them all at the same time and the user only pays for the capacity they use. This approach also applies to other problem domains such as enabing next generation machine learning tools, performing simulations, and supporting research.

Conclusion: Wrapping Up Cloud Applications

In this chapter, we’ve examined the fundamental pattern for this whole book, Cloud Application. For an application to work well in the cloud, it needs to be designed for the cloud.

As we have seen in this chapter, there are important considerations that should be addressed when developing a new application or modernizing an existing application for the cloud. The Introduction showed how cloud computing has evolved from previous computing architectures. Then this chapter addressed the latest iteration of computing architecture—the cloud—as well as what the cloud is and how cloud computing differs from traditional IT.

Cloud applications are different from traditional IT applications. Cloud has newer, better qualities that traditional IT does not, qualities that make a set of computers easy to share. While traditional IT incorporates several practices that don’t work well on shared computing, cloud incorporates rather opposite practices that make shared computing useful. Meanwhile, the industry is adopting several newer application development practices and cloud helps facilitate applying those practices. The cloud application topic space is vast, with a lifecycle including numerous aspects that range from application architecture to deployment to complex topologies, more subject matter than can fit in one book, so this book focuses on the first part, the application’s architecture.

We’ve seen that while cloud applications may seem completely new and unknown, their structure has evolved from earlier technologies–from mainframe computers to desktop computers to client/server computing to what is now cloud-native computing.

We’ve reviewed the basic structure of a cloud application, how it solves the challenge of designing an application to work well on cloud. We reviewed examples for e-commerce, banking, and high performance computing (HPC), showing that this cloud application solution can be applied across a range of industries using several architectural variations.

The next chapter will explore that although traditional IT and cloud applications are different, they both run on computers and therefore both embody the same fundamental Application Architectures. Then we’ll discuss about the basic capabilities an application should include to make it run well on cloud, best practices for designing a Cloud-Native Application.