Sidestepping Dependency Ordering with AppSwitch

Sidestepping Dependency Ordering with AppSwitch

  • January 23, 2019
Table of Contents

Sidestepping Dependency Ordering with AppSwitch

We are going through an interesting cycle of application decomposition and recomposition. While the microservice paradigm is driving monolithic applications to be broken into separate individual services, the service mesh approach is helping them to be connected back together into well-structured applications. As such, microservices are logically separate but not independent.

They are usually closely interdependent and taking them apart introduces many new concerns such as need for mutual authentication between services. Istio directly addresses most of those issues. An issue that arises due to application decomposition and one that Istio doesn’t address is dependency ordering – bringing up individual services of an application in an order that guarantees that the application as a whole comes up quickly and correctly.

In a monolithic application, with all its components built-in, dependency ordering between the components is enforced by internal locking mechanisms. But with individual services potentially scattered across the cluster in a service mesh, starting a service first requires checking that the services it depends on are up and available.

Source: istio.io

Share :
comments powered by Disqus

Related Posts

Istio Multicluster

Istio Multicluster

Istio Multicluster is a feature of Istio–the basis of Red Hat OpenShift Service Mesh–that allows for the extension of the service mesh across multiple Kubernetes or Red Hat OpenShift clusters. The primary goal of this feature is to enable control of services deployed across multiple clusters with a single control plane. The main requirement for Istio multicluster to work is that the pods in the mesh and the Istio control plane can talk to each other.

Read More
Deployment strategies for the Jaeger Agent

Deployment strategies for the Jaeger Agent

If you’ve been following the evolution of the Kubernetes templates for Jaeger, you might have noticed an important change recently: the Jaeger Agent is not being deployed as a DaemonSet anymore. Instead, instructions are now being provided on how to deploy it as a “Sidecar”. The Agent component was developed to act as a “buffer” between the tracer and the collector.

Read More
Rate Limiting at the Edge

Rate Limiting at the Edge

I’m sure many of you have heard of the “Death Star Security” model—the hardening of the perimeter, without much attention paid to the inner core—and while this is generally considered bad form in the current cloud native landscape, there is still many things that do need to be implemented at edge in order to provide both operational and business logic support. One of these things is rate limiting. Modern applications and APIs can experience a burst of traffic over a short time period, for both good and bad reasons, but this needs to be managed well if your business model relies upon the successful completion of requests by paying customers.

Read More