Resilient Cloud-Based Applications & Ambassador Pattern

For applications to function properly in a cloud-based environment, they need to be designed with resiliency in mind. This means incorporating features such as circuit breaking, routing, metering and monitoring, and the ability to make network-related configuration updates. This can be a daunting task for many organizations, as it may be difficult or impossible to update legacy applications or existing code libraries to add these features. But it's important to understand why these features are essential and how they can be implemented to take full advantage of the benefits of cloud-based computing.

What is Resilience?

For an application to be resilient, it must handle failures gracefully and continue functioning without interruption. This includes small failures like individual component failures to larger ones like complete data center outages. By design, cloud-based applications are more resilient than traditional ones because they are built on a distributed system that can tolerate individual component failures.

Why is Resilience Important?

This is because the cloud enables organizations to achieve grander scale and agility, but only if the applications can take advantage of those benefits. If an application is not resilient, it will not be able to handle failures gracefully and ultimately cause more downtime and disruptions.

How Can You Implement Resilient Cloud-Based Applications?

There are a few key things you need to do to implement resilient cloud-based applications:

1. Use circuit breakers to prevent cascading failures.
2. Implement routing algorithms that can automatically reroute traffic around failed components.
3. Meter and monitor network usage to identify potential bottlenecks.
4. Make network-related configuration updates dynamically without requiring code changes or redeployments.
5. Manage network and security functionality centrally, using a standard set of tools and processes.
6. Configure network calls for each application instance, considering different languages and frameworks.
7. Implement fault tolerance and self-recovery.

Fault tolerance is the property that ensures that the system continues running despite being hit by faults or errors. On the other hand, self-recovery means that the system can heal itself automatically after a failure. Together, these two properties make up the basics of building a resilient cloud-based application. Here are a few best practices on that -

1. Employing message queues or other messaging systems to decouple components of your system
2. Monitoring your system closely so that you can detect and diagnose problems quickly
3. Putting in place backup and disaster recovery procedures so that you can recover from significant failures rapidly
4. Automating as much of the process as possible to minimize human error
5. Doing regular stress testing on your system to ensure that it can handle peak loads without breaking down

Resilience and fault tolerance are factors to consider designing applications for the cloud. Additionally, the design should consider implementing a proxy. There are many everyday use cases for proxies:

• API Gateway: An API gateway is a type of proxy that is used for creating APIs. API gateways allow developers to create APIs without worrying about details such as security or performance metrics.
• Service Mesh: A service mesh is a proxy used for managing communication between services in a microservices architecture. Service meshes provide features such as load balancing, monitoring, and routing.
• Application Proxy: An application proxy is a proxy for accessing applications located behind a firewall or in another network. Application proxies provide features such as security and availability while hiding the details of the underlying infrastructure from developers.

An ambassador is a type of proxy service that facilitates communication between two separate processes. Implementing the ambassador is essential to application migration as well as implementing apps on the cloud. Ambassador services can be used in a number of different scenarios. For example, if you have a microservices-based architecture, you can use an ambassador service to help route traffic between services. Or, if you have a legacy application that doesn't have built-in support for modern protocols, you can use an ambassador service to provide that support. There are many other uses for ambassador services as well; these are just two examples.

Here is Microsoft’s documentation about the pattern - Ambassador pattern