Balance proficiency and innovation by building a separate time for each into your development cycle.
See Chapter 8: Patterns for Organization and Culture for full version.

A picture—or, in this case, a high-level outline sketch of your system’s basic architecture—can replace a thousand words, save time, and prevent misunderstandings.
See Chapter 9: Patterns for Development and Process for full version.

The absolute majority of operational tasks need to be automated. Automation reduces interteam dependencies, which allows faster experimentation and leads in turn to faster development.
See Chapter 10: Patterns for Infrastructure and Cloud for full version.

Shift responsibility for testing from humans (manual) to an automated testing framework so the quality of the released products is consistent and continuously improving, allowing developers to deliver faster while spending more of their time improving features to meet customer needs.
See Chapter 9: Patterns for Development and Process for full version.

When possible, purchase solutions for any need that is not your actual core business instead of trying to custom-build perfect tools.
See Chapter 9: Patterns for Development and Process for full version.

When enough information is available, commit to a significant solution for moving the cloud migration forward. Focus on execution rather than research.
See Chapter 7: Patterns for Strategy and Risk Management for full version.

When a problem occurs, focusing on the event instead of the people involved allows them to learn from mistakes without fear of punishment.
See Chapter 8: Patterns for Organization and Culture for full version.

Dev teams have full authority over the services they build, not only creating but also deploying and supporting them.
See Chapter 8: Patterns for Organization and Culture for full version.

Before launching a cloud native transformation, an enterprise’s leadership must make sure the initiative is needed and that the benefits will justify the investment.
See Chapter 7: Patterns for Strategy and Risk Management for full version.

Teams that work together in person develop naturally closer relationships and better collaborative problem-solving abilities, which in turn nurtures greater innovation.
See Chapter 8: Patterns for Organization and Culture for full version.

In a highly distributed system, microservices must communicate with one another via stable and strongly segregated APIs.
See Chapter 9: Patterns for Development and Process for full version.

Create groups of people who have similar skills but are on different teams to cross-pollinate ideas across the company and provide valuable whole-organization perspective.
See Chapter 8: Patterns for Organization and Culture for full version.

When an application is packaged in a container with all its necessary dependencies, it does not rely on the underlying runtime environment and so can run agnostically on any platform.
See Chapter 10: Patterns for Infrastructure and Cloud for full version.

Keeping a short build/test/deliver cycle means code is always ready for production and features can be immediately released to customers—and their feedback quickly returned to developers.
See Chapter 10: Patterns for Infrastructure and Cloud for full version.

Continuous deployment automatically and seamlessly pushes code that has been accepted in the continuous integration/continuous delivery cycle into the production environment.
See Chapter 10: Patterns for Infrastructure and Cloud for full version.

Frequent integration of small iterative changes speeds overall delivery and improves the quality of the code.
See Chapter 9: Patterns for Development and Process for full version.

Dedicate a team of engineers and architects to the task of uncovering the best transformation path and implementing it along the way. This reduces risk embedded in the transformation while the team gains experience helpful for onboarding the remaining teams later.
See Chapter 8: Patterns for Organization and Culture for full version.

Collect data, extract patterns and facts, and use them to make inferences to drive objective decision making.
See Chapter 7: Patterns for Strategy and Risk Management for full version.

Those nearest to a change action get the first chance to make any decisions related to it.
See Chapter 8: Patterns for Organization and Culture for full version.

Automate processes only after a problem has been completely solved and the solution has been run manually a few times.
See Chapter 9: Patterns for Development and Process for full version.

Teams onboarded to the new cloud native system receive demo applications as an educational starting point for building their own cloud native applications.
See Chapter 9: Patterns for Development and Process for full version.

Whether faced with a radical new idea or a big problem, Design Thinking can be used as a process for first brainstorming a robust list of solutions and then narrowing it down to the best possibilities for actual exploration.
See Chapter 8: Patterns for Organization and Culture for full version.

When you’re running forward as fast as you can, it’s difficult to look around you—so appoint one person within the organization to be in charge of situational awareness.
See Chapter 7: Patterns for Strategy and Risk Management for full version.

Provide a “starter kit” of materials, guides, and other resources to help new teams onboard to the new cloud native system quickly and with confidence.
See Chapter 9: Patterns for Development and Process for full version.

When software is built as a series of fully independent, loosely coupled services, the resulting system is, by design, fast, resilient, and highly scalable.
See Chapter 9: Patterns for Development and Process for full version.

An orchestrator (typically Kubernetes) is needed to organize the deployment and management of microservices in a distributed container-based application to assign them across random machines at the instant of execution.
See Chapter 9: Patterns for Development and Process for full version.

Today’s tech-driven marketplace is a constantly shifting environment, no matter what business you are in—so your game plan needs to shift right along with it.
See Chapter 7: Patterns for Strategy and Risk Management for full version.

To ensure allocation of sufficient resources and reasonable delivery time frames, large-scale projects such as cloud native transformation require strong commitment from the top executive team.
See Chapter 7: Patterns for Strategy and Risk Management for full version.

Public cloud vendors can handle all aspects of building and operating a cloud native platform, and their tools are often excellent—but when committing to a vendor/technology/platform it’s important to identify an alternative solution and any costs associated with switching over.
See Chapter 7: Patterns for Strategy and Risk Management for full version.

When dealing with a complex problem with no obvious available solution, run a series of small experiments to evaluate the possible alternatives and learn by doing.
See Chapter 8: Patterns for Organization and Culture for full version.

Make sure your platform is fully provisioned with CI/CD, security, monitoring, observability, and other features essential to production readiness before you try to take it live.
See Chapter 10: Patterns for Infrastructure and Cloud for full version.

One to three months before the new platform goes live, begin training a couple of teams at a time with a pause between each cohort to incorporate feedback and improve the process/materials.
See Chapter 8: Patterns for Organization and Culture for full version.

In an uncertain environment, slowly increase investment in learning and information gathering; eventually you uncover enough information to reduce risk and make better-informed decisions.
See Chapter 7: Patterns for Strategy and Risk Management for full version.

Provide plenty of information about the transformation across the entire company right from the start to create understanding, acceptance of, and support for the initiative.
See Chapter 8: Patterns for Organization and Culture for full version.

The business teams and the tech teams need to collaborate to create an effective customer-feedback loop that drives product improvement.
See Chapter 7: Patterns for Strategy and Risk Management for full version.

When a stable system delivers the value that’s intended and is not a target for technical innovation, focus on improving the system by continuously and incrementally improving delivery and maintenance processes with emphasis on repeatability.
See Chapter 8: Patterns for Organization and Culture for full version.

Building feedback collection into the delivery process closes the loop between engineers and the people who use their products, putting the customer at the center of the product development cycle.
See Chapter 7: Patterns for Strategy and Risk Management for full version.

An organization skilled at acquiring information, creating insight, and transferring knowledge can tolerate risk with confidence and solve difficult problems through experimentation and innovation.
See Chapter 7: Patterns for Strategy and Risk Management for full version.

It’s important not to approach a cloud native transformation by simply attempting a full “lift and shift” of your existing system onto the cloud. But it can be smart to move some intact pieces of it at the very end.
See Chapter 10: Patterns for Infrastructure and Cloud for full version.

Teams charged with innovation need the open-ended freedom to experiment their way to solutions without pressure for delivering specific results on a set schedule—and the freedom to sometimes fail along the way.
See Chapter 8: Patterns for Organization and Culture for full version.

Teams delivering stable and highly repetitive or algorithmic work should be managed for high quality and optimal efficiency.
See Chapter 8: Patterns for Organization and Culture for full version.

People optimize their actions based on how their work is measured. Assessing the wrong things leads people to optimize for the wrong goals.
See Chapter 7: Patterns for Strategy and Risk Management for full version.

To reduce the costs of coordination among teams delivering large monolithic applications, build the software as a suite of modular services that are built, deployed, and operated independently.
See Chapter 9: Patterns for Development and Process for full version.

Once Exploratory Experiments and PoCs have uncovered a probable path to success, build a simple version of a basic but fully functional and production-ready platform with one to three small applications running on it in production.
See Chapter 8: Patterns for Organization and Culture for full version.

Execute non-critical long running tests in the background so they don’t block delivery to production.
See Chapter 9: Patterns for Development and Process for full version.

Small, quick actions that require little investment of time and money but increase knowledge, reduce risk, and benefit the entire organization—inside or outside of a transformation scenario.
See Chapter 7: Patterns for Strategy and Risk Management for full version.

After establishing a transformation vision, the next step is to translate it into pragmatic goals and actions for moving the initiative ahead.
See Chapter 7: Patterns for Strategy and Risk Management for full version.

Cloud native distributed systems require constant insight into the behavior of all running services in order to understand the system’s behavior and to predict potential problems or incidents.
See Chapter 10: Patterns for Infrastructure and Cloud for full version.

Continuously introduce new ways and improve existing ones to help teams continually develop their cloud native knowledge and skills.
See Chapter 8: Patterns for Organization and Culture for full version.

Use open source solutions for any software need that is not directly related to the company’s core business value.
See Chapter 9: Patterns for Development and Process for full version.

Research has created deeper understanding, and a few potentially promising transformation paths have begun to emerge. Continue reducing the risk by focusing on the most promising options and developing them further.
See Chapter 7: Patterns for Strategy and Risk Management for full version.

Frequently reassess vision and objectives to ensure these remain the correct direction to proceed as the business environment shifts.
See Chapter 7: Patterns for Strategy and Risk Management for full version.

Solutions to complex problems are best created collaboratively by teams with high levels of interpersonal connection.
See Chapter 8: Patterns for Organization and Culture for full version.

Create a team to be in charge of architecting, building, and running a single, consistent, and stable cloud native platform for use by the entire organization so that developers can focus on building applications instead of configuring infrastructure.
See Chapter 8: Patterns for Organization and Culture for full version.

A private cloud approach, operated either over the internet or on company-owned on-premises infrastructure, can offer the benefits of cloud computing services like AWS while restricting access to only select users.
See Chapter 10: Patterns for Infrastructure and Cloud for full version.

People are more engaged and creative when they feel comfortable receiving constructive information about their behavior and giving the same in return.
See Chapter 8: Patterns for Organization and Culture for full version.

Before fully committing to a solution that can significantly affect the future, build a small prototype to demonstrate viability and gain better understanding.
See Chapter 8: Patterns for Organization and Culture for full version.

When team members feel they can speak up, express concern, and make mistakes without facing punishment or ridicule, they can think freely and creatively and are open to taking risks.
See Chapter 8: Patterns for Organization and Culture for full version.

Instead of using your own hardware, rely on the hardware managed by public cloud vendors whenever possible.
See Chapter 10: Patterns for Infrastructure & Cloud for full version.

When someone has an idea that requires validation, the costs of doing experiments around it needs to be as low as possible.
See Chapter 9: Patterns for Development and Process for full version.

Provide an easily accessible document laying out a standardized system architecture for all teams to use for building their applications/components. This ensures higher architectural consistency and lowers development costs via better reusability.
See Chapter 9: Patterns for Development and Process for full version.

Build periodic times into the business delivery cycle dedicated to reviewing current strategy in light of shifting market conditions or other new information.
See Chapter 7: Patterns for Strategy & Risk Management for full version.

If teams must be distributed, whether across a city or a continent, build in regular in-person retreats/work sessions as well as robust channels for close and free-flowing communication.
See Chapter 8: Patterns for Organization and Culture for full version.

Developers need to test their daily work in an environment that is easy to spin up and that matches production tooling as closely as possible.
See Chapter 9: Patterns for Development and Process for full version.

People can sometimes use research as a way to avoid making decisions, so hands-on learning through small experiments builds confidence and jump-starts progress.
See Chapter 7: Patterns for Strategy and Risk Management for full version.

Employ release tactics to decrease the chance of problems happening when changes are introduced into the production system.
See Chapter 10: Patterns for Infrastructure and Cloud for full version.

Build security into the platform beginning with the earliest versions to ensure your distributed system is unbreachable by design.
See Chapter 9: Patterns for Development and Process for full version.

In cloud native everyone can do their own provisioning and deployment with no handoffs between teams.
See Chapter 10: Patterns for Infrastructure and Cloud for full version.

The soon-to-arrive future is event-driven, instantaneously scalable services (functions) on the cloud.
See Chapter 9: Patterns for Development and Process for full version.

The SRE (Site Reliability Engineering) team helps the development teams to maintain and improve the application (not the platform or infrastructure).
See Chapter 8: Patterns for Organization and Culture for full version.

Gradually split pieces of the old monolithic application one by one, re-archtect them into services, and move them over time to the new CN platform.
See Chapter 8: Patterns for Organization and Culture for full version.

Just as the new tools, technologies, and infrastructure gradually roll out over the course of a transformation initiative, the organization and its teams must also evolve to work with them properly.
See Chapter 8: Patterns for Organization and Culture for full version.

Proportional allocation of resources among delivery, innovation, and research makes an organization responsive to change while reliably delivering core business value.
See Chapter 7: Patterns for Strategy and Risk Management for full version.

When a person is promoting a good new idea that can take the company’s goals and values into the future, recognize and empower them to lead the action.
See Chapter 7: Patterns for Strategy and Risk Management for full version.

When an organization’s values are clearly stated and prioritized, as well as fully internalized across the company, people have the basis for making day-to-day decisions without needing to seek consent or permission/approval. When an organization’s values are clearly stated and prioritized, day-to-day decisions can be made without seeking consent or permission/approval.
See Chapter 7: Patterns for Strategy and Risk Management for full version.

Defining a high-level transformation path as the very first step helps set the right course through an uncertain environment.
See Chapter 7: Patterns for Strategy and Risk Management for full version.