xpressvasup.blogg.se

In our examples here, we will host our services across eu-west-1 (Dublin) and eu-west-2 (London) regions, which would be a good choice for spreading European-based workloads.

We also need to consider application state, as we do not want a customer to start a session in one location and then attempt to continue it in another region unless they are synchronized. Do we route our integration applications to backends in the same region, cross-region, or balanced between the two? For HA purposes, clearly we don’t want to have services running in one region that are fully dependent on another, as that achieves nothing. We should also consider where our backend services are hosted and how these relate to our integrations and APIs. That would cause variations in end-to-end response time that would at best be unpredictable and at worst could cause race conditions or other data consistency errors. We don’t want some requests to be routed fully within the EU, whilst others get routed from the EU, to the USA, and back to the EU, for example. This is particularly important in active-active configurations where a user request may be dynamically served from either region. When deploying across multiple regions for high availability we should stick with regions that are still within the same continent or within a reasonable distance from each other (e.g., eu-west-1 & eu-west-2, or us-east-1 & us-east-2). If all our users and clients are located in North America, we probably don’t want to have integration workloads located in Asia-Pacific, for example. Any upstream latency will fall within the bounds of Anypoint Monitoring that allows us to easily monitor and alert on unexpected changes or poor response times. That way you get the lowest possible latency between the client and the API. A point of best practice is that outward-facing APIs should reside as close to the clients as possible. We must remain mindful of latency and the impact on user experience. Where will your users be accessing our APIs from? Where do your client applications run? Where are your backends? Before you do this though, you should consider the rest of our architecture. So you’ve decided that we want to have multi-region availability to provide maximum fault tolerance. In the second part, we will discuss a more evolved approach that uses a dynamic content distribution system to route incoming traffic.

We’ll then see how that would be constructed in practice using a simple DNS-based approach. In the first post of this two-part series, we’ll look at building a highly-available Runtime Fabric instance and how that is enhanced with a multi-region approach.