Cloud Native Development Patterns and Best Practices

John Gilbert

• Publisher: Packt Publishing
• Year: 2018
• Print ISBN: 9781788473927
• eBook ISBN: 9781788476690
• Edition: 1
• Topic: Computer Science
• Subtopic: Cloud Computing
• Index: Computer Science

Learn to apply cloud-native patterns and practices to deliver responsive, resilient, elastic, and message-driven systems with confidence

Key Features

• Understand the architectural patterns involved in cloud-native architectures
• Minimize risk by evolving your monolithic applications into distributed cloud-native systems
• Discover best practices for applying cloud-native patterns to your enterprise-level cloud applications

Book Description

Build systems that leverage the benefits of the cloud and applications faster than ever before with cloud-native development. This book focuses on architectural patterns for building highly scalable cloud-native systems. You will learn how the combination of cloud, reactive principles, devops, and automation enable teams to continuously deliver innovation with confidence.

Begin by learning the core concepts that make these systems unique. You will explore foundational patterns that turn your database inside out to achieve massive scalability with cloud-native databases. You will also learn how to continuously deliver production code with confidence by shifting deployment and testing all the way to the left and implementing continuous observability in production. There's more—you will also learn how to strangle your monolith and design an evolving cloud-native system.

By the end of the book, you will have the ability to create modern cloud-native systems.

What you will learn

• Enable massive scaling by turning your database inside out
• Unleash flexibility via event streaming
• Leverage polyglot persistence and cloud-native databases
• Embrace modern continuous delivery and testing techniques
• Minimize risk by evolving your monoliths to cloud-native
• Apply cloud-native patterns and solve major architectural problems in cloud environment

Who this book is for

This book is for developers who would like to progress into building cloud-native systems and are keen to learn the patterns involved. Basic knowledge of programming and cloud computing is required.

Foundation Patterns

In the previous chapter, we began our deep dive into the architectural aspects of cloud-native systems with a look at their anatomy. To create these globally scalable systems, we effectively turn the cloud into the database. Following Reactive principles, we leverage event streaming to turn the database inside out by replicating data across components to maximize responsiveness, resilience, and elasticity. Ultimately, we create proper functional and technical bulkheads, so that teams can continuously deliver innovation with confidence.

In this chapter, we begin our discussion of cloud-native patterns. We will discuss the patterns that provide the foundation for creating bounded isolated components. We eliminate all synchronous inter-component communication and build our foundation on asynchronous inter-component communication, replication, and eventual consistency. We will cover the following foundation patterns:

• Cloud-Native Databases Per Component
• Event Streaming
• Event Sourcing
• Data Lake
• Stream Circuit Breaker
• Trilateral API

Cloud-Native Databases Per Component

Leverage one or more fully managed cloud-native databases that are not shared across components and react to emitted events to trigger intra-component processing logic.

Context, problem, and forces

With cloud-native systems, we want to enable everyday companies and empower self-sufficient, full-stack teams to rapidly, continuously, and confidently deliver these global scale systems. Modern high performance, horizontally scalable, sharded databases are critical to achieving global scalability. These databases come in many variations that are specialized for particular workload characteristics. Cloud-native systems are composed of many bounded isolated components. Each component has its own workload characteristics, which necessitates the use of polyglot persistence whereby many different types of databases are employed to support these characteristics.

To be truly isolated, cloud-native components need to control their own persistence. Each bounded isolated component needs to have its own dedicated databases to ensure proper bulkheads. Proper data level bulkheads help ensure that user interactions with components are responsive, that components are resilient to failures in upstream and downstream components, and that components can scale independently. Individual components, not just systems, can benefit from polyglot persistence. Thus, components need more than just their own dedicated database; each component may need multiple, dedicated databases. Mature cloud-native systems are also multi-regional and replicate data across regions. Data life cycle management is also necessary. For example, components that provide online transaction processing (OLTP) features benefit from continuously purging stale data to keep their databases lean. Furthermore, as the data in a system ages and moves through different life cycle stages, it needs to propagate across components and across different types of databases.

Achieving the proper level of database isolation, though critical, is extremely complicated. Running a single database in the cloud across multiple availability zones is complex, running a sharded database in the cloud across availability zones is super complex, and running multiple sharded databases in the cloud can simply require more effort than most companies can afford. Going further, running many sharded databases, multiplied by many components, can seem unattainable. At this point in the typical discussion, there is literally no point in piling on the critical regional replication dimension. The workforce costs and the runtime cost of all these dimensions have the potential of being astronomical. All together this is a significant barrier to entry for proper data level bulkheads. This tends to force teams into a shared database model, despite the significant and potentially catastrophic pitfalls of the shared model.

What is worse is that the shared database model actually appears to be successful at first, at least for the initial components that use these resources. However, as more and more components leverage these shared resources, the responsiveness and scalability of all the components suffer and the impact of a failure becomes more significant. These shared databases also tend to grow and grow because teams are not responsible for the full stack. Centralized operations teams own these shared databases. As a result, component teams neglect data life cycle concerns and the operations team lacks the functional knowledge to archive unneeded data, leading to even worse performance.

Vendor lock-in is a classic database concern. In traditional monolithic applications, object relational mapping tools are leveraged to make applications database agnostic. In cloud-native systems, the startup overhead of these tools can be too much for short-lived component instances. Instead, the tendency is to leverage open source databases that can be deployed across multiple cloud providers. However, the learning curve for operating these databases is significant. Each database product has the potential to add a good 6 months or more to a project before a team can be confident in their ability to run these workloads in production. This further increases the tendency to leverage a shared database model. The effort required to move up the learning curve also tends to lock systems into the database technology decisions that were made early on in the system design, even after there is ample evidence that there are better alternatives.

The lack of distributed transactions based on two-phase commits is another concern. As a matter of course, modern databases favor the BASE model for distributed transactions: Basically Available, Soft state, Eventually consistent. The individual writes to each database follow the traditional ACID model, but a mechanism to achieve eventual consistency across databases is needed.

Solution

Leverage your cloud provider's fully managed cloud-native database services. Employ multiple database types within a component, as needed, to match the component's workload characteristics. Choose the database type, such as document store, blob storage, or search on a table-by-table basis. Each database is dedicated to a specific component and not shared across components. Use the change-data-capture and life cycle management features and react to the emitted events to trigger intra-component processing logic. Use the regional replication features to create multi-regional deployments, as needed.

Resulting context

The primary benefit of this solution is that proper data level bulkheads are achieved in a realistic and cost-effective manner. The shared responsibility model of the cloud allows teams to delegate the undifferentiated tasks of database management to the cloud provider and benefit from the cloud's economies of scale. The learning curve to get up and running with these value-added cloud services is short, which enable teams to focus on the value proposition of their components. Teams take full control of their stack and provision the exact resources need for their components. This isolation makes components responsive because they are not competing for database resources and those resources are optimized for their specific workloads; elastic because the load of the system is spread across many database instances; and resilient because database failures are contained within a component.

One drawback of this solution is that these services tend to be the source of regional outages. As discussed in Chapter 2, The Anatomy of Cloud Native Systems, these outages do not happen frequently, but when they do they can have a dramatic impact on systems that are not prepared for their eventuality. However, these outages are contained to a single region and systems that run in multiple regions are resilient to these outages. We have also discussed that mature cloud-native systems are multi-regional, which provides a more responsive experience for regional users, in addition to active-active redundancy to withstand these outages. To facilitate multi-regional deployments, cloud-native databases provide regional replication features. These features are becoming more and more turnkey, thanks to competition between cloud providers.

Change data capture (CDC) is one of the most important features provided by these databases. As we will see in the Event Sourcing pattern, this feature is critical in implementing transactionally sound eventual consistency across components. In the example ahead, we will see that change data capture is also instrumental in implementing intra-component asynchronous processing flows. Life cycle management features are complimentary to change data capture. For example, in addition to keeping a database lean, a time to live feature will result in a delete event that can be leveraged to generate interesting and valuable time-based event-driven processing logic, over and above just propagating data through its life cycle stages. Versioning and archiving features are also typical of blob storage services.

Query limitations are a perceived drawback of this solution. We are not able to join data across components because they are in different databases. Now, even within a component, each table is isolated and cannot be joined. Plus, the query APIs of these databases tend to lack some of the features we are accustomed to with SQL. The new trend towards multi-model databases is changing this last issue. However, in general, this perceived drawback is rooted in our expectations set by monolithic general-purpose databases. We are accustomed to asking these general-purpose databases to do more work than we should. Ultimately, this resulted in inefficient utilization of scarse resources. Traditionally, we have isolated OLTP databases from OLAP databases for this exact reason. The nature of their performance and tuning characteristics are orthogonal, thus they need to be isolated.

The disposable nature of cloud infrastructure, and specifically cloud-native databases, enables us to take this isolation to the most fine-grained level. This is where the Event Sourcing and CQRS patterns come into play. In those patterns, we will be discussing how they come together with the Event Streaming pattern and eventual consistency to create materialized views that not only overcome this perceived query limitation through the pre-calculation of joins, but actually result in a more responsive, resilient, and elastic solution. I mentioned previously that this is where much of the rewiring of our engineering brains is needed.

Cloud-native databases do not hide many of the details that were encapsulated in relational databases. This is both a good thing and a bad thing. It is bad in that you need to be aware of these details and account for them, but it is good in that these details are easily within your control to optimize your solution. For example, it is a surprise at first that we need to account for all the various details of indexing and that indexes are explicitly priced. However, there was always an implicit price to indexes that was typically ignored at our own peril. Hot shards is another topic of concern that we will address in the example ahead, but essentially you must take care in the modeling of your partition hash keys. Cloud-native databases free us from the limitations of database connection pools, but they introduce capacity throttling. In the Stream Circuit Breaker pattern, we will discuss throttling and retries and so forth. For now, know that some of this logic is handled within the cloud provider SDKs. And while database monitoring is nothing new, the focus will be placed on throttling statistics to determine if and when the capacity settings and auto- scaling policies need to be adjusted.

And finally, the most commonly perceived drawback of this solution, vendor lock-in, brings us around full circle to the primary benefit of the solution. In chapter 1, Understanding Cloud Native Concepts, we discussed how vendor lock-in is rooted in monolithic thinking and that we need to embrace disposable architecture, which is afforded to us by disposable infrastructure and bounded isolated components. The primary drawback of other solutions is that they are difficult and costly to manage and ultimately increase the time to market and drive us to a shared database model that eliminates proper bulkheads. Their complexity and learning curve also leads to their own form of vendor lock-in. Instead, the cloud-native solution empowers self-sufficient, full-stack teams to embrace disposable architecture, which accelerates time to market. Once a component has been proven valuable and if its implementation is lacking, then the team can revisit its design decisions, with the confidence that the previous design decision was the cost of the information that led them to their current level of understanding. In the Data Lake pattern, we will discuss how events can be replayed to seed the data in new and improved implementations of components and thus help alleviate concerns over disposable architecture.

Each cloud provider has its own implementation of the most common database types. AWS has DynamoDB for key-value and document storage, S3 for blob storage, and both Solr and Easticsearch are options for implementing search engines. Azure has CosmosDB for key-value, document, and graph storage, Azure Blob Storage, and Azure Searc...

Table of contents

• Title Page
• Copyright and Credits
• Dedication
• Packt Upsell
• Contributors
• Preface
• Understanding Cloud Native Concepts
• The Anatomy of Cloud Native Systems
• Foundation Patterns
• Boundary Patterns
• Control Patterns
• Deployment
• Testing
• Monitoring
• Security
• Value Focused Migration
• Other Books You May Enjoy