4 Proven Patterns & Practices to Ignite Your Cloud Native Architecture

Your house is not on fire and ships are not sinking at sea. These statements can be made with high confidence as we have established repeatable solutions to protect us from these high risk events. In tackling the modern challenges of large distributed systems, we will learn that real world patterns from land and sea can be applied to the cloud.

When presented with a large problem, our first step is to break it down into small, more manageable pieces. As system architectures have evolved, we have moved from monolithic/layered to service-oriented architectures. Each step along the evolutionary path has broken down our systems further and further — from monolithic to multi-tiered and onto service-oriented architecture. A modern architecture style that continues this trajectory towards granularity is microservices.

1. Microservices

Microservices serve as a means to deconstruct our applications into a suite of small services. Each service is modeled around a single business capability. In doing so, we are placing a fence around our services that marks a boundary around our business context. The term “bounded context” was first introduced in the book Domain-Driven Design as a means to describe this pattern. Each bounded context affords us both technical and organizational independence.

2. Containers

From a technical standpoint, we can individually deploy each service. To further isolate our services, we can have each run in its own process. This is typically accomplished through containers. Containers are hermetically sealed compartments that isolate failure in our processes so that they do not overtake the operating system’s resources. This failure isolation is akin to the shipping technique of bulkheading.

Bulkheads are watertight partitions designed to prevent damage from sinking an entire ship. Containers, like Docker, also pack all of your system’s dependencies inside an isolated process. This handles dependency management in a way that enables parity across all deployment environments.

3. Inverse Conway Maneuver

As for organizational impact, microservices reduce the learning curve for new team members as they need only focus on their specific business context. When it comes to team composition, inverting Conway’s Law is strongly recommended. Conway’s Law states,

“Any organization that designs a system will produce a design whose structure is a copy of the organization’s communication structure.”

Inverting Conway’s Law allows us to align our organizational structure to our bounded contexts. In short, bounded contexts reaffirm that good fences make good neighbors.

When formed around bounded contexts, teams can work faster as context switching is minimized. Pairing a rapid pace with small changes, permits us to accept more risk as recovery from small changes can occur almost instantly. As we remove the fear associated with system changes, we can increase our attempts at delivering experimental features to our customers.

4. Circuit Breakers

There is a reason why our houses don’t burn down due to an excessive use of power — circuit breakers. The circuit breaker stability pattern can be applied programmatically to ensure that our systems don’t go down in flames. Our microservices can employ this mechanism to prevent themselves from communicating with dependencies that are failing and provide a graceful fallback. Once the dependency in question is deemed safe, the circuit can then lift the quarantine and reopen communications.

The circuit breaker has three states:

1. Open: The circuit trips into open state once a service call failure surpasses a given threshold limit after a configured period of time.
2. Half-Open: After a specified period of time, the circuit wakes up to determine whether calls continue to fail (keep open) or are now succeeding (close the circuit).
3. Closed: The circuit acts as a pass-through as calls to dependencies are working as expected.

For more information on implementing the circuit breaker pattern, check out: https://martinfowler.com/bliki/CircuitBreaker.html or https://msdn.microsoft.com/en-us/library/dn589784.aspx

Conclusion

Looking around the corner, what will distributed systems look like when they don’t merely adopt the cloud, but are born in it, molded by it?

According to the Cloud Native Computing Foundation (CNCF), Cloud Native systems are expected to have the following properties:

• Container packaged
• Dynamically managed
• Micro-service oriented

We have covered two out of three cloud native system properties: container packaged and micro-service oriented. To jumpstart your cloud native architecture, apply the four patterns and practices detailed above in the following manner…

1. Start with your people and organize them around bounded contexts — in accordance with the inverse Conway maneuver.
2. Align and model services to your organization’s bounded contexts.
3. Package your microservices in containers to isolate failure.
4. Apply the circuit breaker pattern within your containerized microservices as a means to stabilize your distributed system.