mirror of https://github.com/istio/istio.io.git
27 lines
44 KiB
HTML
27 lines
44 KiB
HTML
<!doctype html><html lang=en itemscope itemtype=https://schema.org/WebPage><head><meta charset=utf-8><meta http-equiv=x-ua-compatible content="IE=edge"><meta name=viewport content="width=device-width,initial-scale=1,shrink-to-fit=no"><meta name=theme-color content="#466BB0"><meta name=title content="Sidestepping Dependency Ordering with AppSwitch"><meta name=description content="Addressing application startup ordering and startup latency using AppSwitch."><meta name=author content="Dinesh Subhraveti (AppOrbit and Columbia University)"><meta name=keywords content="microservices,services,mesh,appswitch,performance"><meta property="og:title" content="Sidestepping Dependency Ordering with AppSwitch"><meta property="og:type" content="website"><meta property="og:description" content="Addressing application startup ordering and startup latency using AppSwitch."><meta property="og:url" content="/v1.0/blog/2019/appswitch/"><meta property="og:image" content="/v1.0/img/istio-logo-blue-background.svg"><meta property="og:image:alt" content="Istio Logo"><meta property="og:image:width" content="112"><meta property="og:image:height" content="150"><meta property="og:site_name" content="Istio"><meta name=twitter:card content="summary"><meta name=twitter:site content="@IstioMesh"><title>Istioldie 1.0 / Sidestepping Dependency Ordering with AppSwitch</title><script async src="https://www.googletagmanager.com/gtag/js?id=UA-98480406-2"></script><script>window.dataLayer=window.dataLayer||[];function gtag(){dataLayer.push(arguments);}
|
||
gtag('js',new Date());gtag('config','UA-98480406-2');</script><script>var branchName="release-1.0";var docTitle="Sidestepping Dependency Ordering with AppSwitch";</script><link rel=alternate type=application/rss+xml title="Istio Blog" href=/v1.0/feed.xml><link rel="shortcut icon" href=/v1.0/favicons/favicon.ico><link rel=apple-touch-icon href=/v1.0/favicons/apple-touch-icon-180x180.png sizes=180x180><link rel=icon type=image/png href=/v1.0/favicons/favicon-16x16.png sizes=16x16><link rel=icon type=image/png href=/v1.0/favicons/favicon-32x32.png sizes=32x32><link rel=icon type=image/png href=/v1.0/favicons/android-36x36.png sizes=36x36><link rel=icon type=image/png href=/v1.0/favicons/android-48x48.png sizes=48x48><link rel=icon type=image/png href=/v1.0/favicons/android-72x72.png sizes=72x72><link rel=icon type=image/png href=/v1.0/favicons/android-96x196.png sizes=96x196><link rel=icon type=image/png href=/v1.0/favicons/android-144x144.png sizes=144x144><link rel=icon type=image/png href=/v1.0/favicons/android-192x192.png sizes=192x192><link rel=manifest href=/v1.0/manifest.json><meta name=apple-mobile-web-app-title content="Istio"><meta name=application-name content="Istio"><link rel=stylesheet href="https://fonts.googleapis.com/css?family=Chivo:400,100,100italic,300,300italic,400italic,500,500italic,700,700italic,900,900italic"><link rel=stylesheet href="https://fonts.googleapis.com/css?family=Work Sans:400,100,100italic,300,300italic,400italic,500,500italic,700,700italic,900,900italic"><link rel=stylesheet href=https://maxcdn.bootstrapcdn.com/bootstrap/4.0.0/css/bootstrap.min.css integrity=sha384-Gn5384xqQ1aoWXA+058RXPxPg6fy4IWvTNh0E263XmFcJlSAwiGgFAW/dAiS6JXm crossorigin=anonymous><link rel=stylesheet href=https://use.fontawesome.com/releases/v5.0.6/css/all.css><link rel=stylesheet href=/v1.0/css/light_theme_archive.css title=light><link rel="alternate stylesheet" href=/v1.0/css/dark_theme_archive.css title=dark><script src=/v1.0/js/styleSwitcher.min.js></script></head><body class=language-unknown><header><nav class="navbar navbar-expand-md navbar-dark fixed-top bg-dark justify-content-between"><a class=navbar-brand href=/v1.0/><span class=logo><svg viewBox="0 0 300 300"><circle cx="150" cy="150" r="150" stroke-width="2" /><polygon points="65,240 225,240 125,270"/><polygon points="65,230 125,220 125,110"/><polygon points="135,220 225,230 135,30"/></svg></span><span class=brand-name>Istioldie 1.0</span></a>
|
||
<button class=navbar-toggler type=button data-toggle=collapse data-target=#navbarCollapse aria-controls=navbarCollapse aria-expanded=false aria-label="Toggle navigation">
|
||
<span class=navbar-toggler-icon></span></button><div class="collapse navbar-collapse justify-content-end" id=navbarCollapse><ul id=navbar-links class="navbar-nav active"><li class=nav-item><a class=nav-link title="Learn how to deploy, use, and operate Istio." href=/v1.0/docs/>Docs</a></li><li class=nav-item><a class="nav-link active" title="Posts about using Istio." href=/v1.0/blog/2019/announcing-1.0.6/>Blog</a></li><li class=nav-item><a class=nav-link title="A bunch of resources to help you deploy, configure and use Istio." href=/v1.0/help/>Help</a></li><li class=nav-item><a class=nav-link title="Get a bit more in-depth info about the Istio project." href=/v1.0/about/>About</a></li><li class="nav-item dropdown" id=gearDropdown style=white-space:nowrap><a title="Options and Settings" href class=nav-link data-toggle=dropdown aria-label=Tools aria-haspopup=true aria-expanded=false><i style=width:1em class="fa fa-lg fa-cog"></i></a><div class="dropdown-menu dropdown-menu-right" aria-labelledby=gearDropdown><a class=dropdown-item id=light-theme-item href onclick="setActiveStyleSheet('light');return false;">Light Theme</a>
|
||
<a class=dropdown-item id=dark-theme-item href onclick="setActiveStyleSheet('dark');return false;">Dark Theme</a><div class=dropdown-divider></div><h6 class=dropdown-header>Other versions of this site</h6><a href=https://istio.io class=dropdown-item>Current Release</a>
|
||
<a href=https://preliminary.istio.io class=dropdown-item>Next Release</a>
|
||
<a href=https://archive.istio.io class=dropdown-item>Older Releases</a></div></li><li class=nav-item><a id=search_show class=nav-link href title="Search istio.io" aria-label=Search><i style=width:1em class="fa fa-lg fa-search"></i></a></li></ul><form name=cse id=search_form class="form-inline mr-sm-2" role=search><input type=hidden name=cx value=013699703217164175118:iwwf17ikgf4>
|
||
<input type=hidden name=ie value=utf-8>
|
||
<input type=hidden name=hl value=en>
|
||
<input type=hidden id=search_page_url value=/v1.0/search.html>
|
||
<input id=search_textbox class=form-control name=q type=text aria-label="Search this site">
|
||
<button id=search_close type=reset aria-label="Cancel Search"><i class="far fa-lg fa-times-circle"></i></button></form></div></nav></header><div class=blog><div class=container-fluid><div class="row row-offcanvas"><div class="col-0 col-md-3 col-xl-2 sidebar-offcanvas"><nav class="sidebar d-print-none"><div class=spacer></div><div class=directory role=tablist><div class=card><div class=card-header role=tab id=header0><a data-toggle=collapse href=#collapse0 title="Blog posts for 2019." role=button aria-controls=collapse0><div><img src=/v1.0/img/blog.svg alt=Icon class=page_icon>
|
||
2019 Posts</div></a></div><div id=collapse0 class="collapse show" data-parent=#sidebar role=tabpanel aria-labelledby=header0><div class=card-body><ul class=tree><li><a title="Istio 1.0.6 patch release." href=/v1.0/blog/2019/announcing-1.0.6/>Announcing Istio 1.0.6</a></li><li><span class=current title="Addressing application startup ordering and startup latency using AppSwitch.">Sidestepping Dependency Ordering with AppSwitch</span></li><li><a title="Describes how to deploy a custom ingress gateway using cert-manager manually." href=/v1.0/blog/2019/custom-ingress-gateway/>Deploy a custom ingress gateway using cert-manager</a></li><li><a title="Istio has a new discussion board." href=/v1.0/blog/2019/announcing-discuss.istio.io/>Announcing discuss.istio.io</a></li></ul></div></div></div><div class=card><div class=card-header role=tab id=header1><a data-toggle=collapse href=#collapse1 title="Blog posts for 2018." role=button aria-controls=collapse1><div><img src=/v1.0/img/blog.svg alt=Icon class=page_icon>
|
||
2018 Posts</div></a></div><div id=collapse1 class=collapse data-parent=#sidebar role=tabpanel aria-labelledby=header1><div class=card-body><ul class=tree><li><a title="Istio 1.0.5 patch release." href=/v1.0/blog/2018/announcing-1.0.5/>Announcing Istio 1.0.5</a></li><li><a title="How to use Istio for traffic management without deploying sidecar proxies." href=/v1.0/blog/2018/incremental-traffic-management/>Incremental Istio Part 1, Traffic Management</a></li><li><a title="Istio 1.0.4 patch release." href=/v1.0/blog/2018/announcing-1.0.4/>Announcing Istio 1.0.4</a></li><li><a title="Istio 1.0.3 patch release." href=/v1.0/blog/2018/announcing-1.0.3/>Announcing Istio 1.0.3</a></li><li><a title="Istio 1.0.2 patch release." href=/v1.0/blog/2018/announcing-1.0.2/>Announcing Istio 1.0.2</a></li><li><a title="Istio 1.0.1 patch release." href=/v1.0/blog/2018/announcing-1.0.1/>Announcing Istio 1.0.1</a></li><li><a title="Istio hosting an all day Twitch stream to celebrate the 1.0 release." href=/v1.0/blog/2018/istio-twitch-stream/>All Day Istio Twitch Stream</a></li><li><a title="How HP is building its next-generation footwear personalization platform on Istio." href=/v1.0/blog/2018/hp/>Istio a Game Changer for HP's FitStation Platform</a></li><li><a title="Istio is ready for production use with its 1.0 release." href=/v1.0/blog/2018/announcing-1.0/>Announcing Istio 1.0</a></li><li><a title="Automatic application onboarding and latency optimizations using AppSwitch." href=/v1.0/blog/2018/delayering-istio/delayering-istio/>Delayering Istio with AppSwitch</a></li><li><a title="Describe Istio's authorization feature and how to use it in various use cases." href=/v1.0/blog/2018/istio-authorization/>Micro-Segmentation with Istio Authorization</a></li><li><a title="How to export Istio Access Logs to different sinks like BigQuery, GCS, Pub/Sub through Stackdriver." href=/v1.0/blog/2018/export-logs-through-stackdriver/>Exporting Logs to BigQuery, GCS, Pub/Sub through Stackdriver</a></li><li><a title="Introduction, motivation and design principles for the Istio v1alpha3 routing API." href=/v1.0/blog/2018/v1alpha3-routing/>Introducing the Istio v1alpha3 routing API</a></li><li><a title="Describes how to configure Istio ingress with a network load balancer on AWS." href=/v1.0/blog/2018/aws-nlb/>Configuring Istio Ingress with AWS NLB</a></li><li><a title="Using Kubernetes namespaces and RBAC to create an Istio soft multi-tenancy environment." href=/v1.0/blog/2018/soft-multitenancy/>Istio Soft Multi-tenancy Support</a></li><li><a title="An introduction to safer, lower-risk deployments and release to production." href=/v1.0/blog/2018/traffic-mirroring/>Traffic Mirroring with Istio for Testing in Production</a></li><li><a title="Describes a simple scenario based on Istio's Bookinfo example." href=/v1.0/blog/2018/egress-tcp/>Consuming External TCP Services</a></li><li><a title="Describes a simple scenario based on Istio's Bookinfo example." href=/v1.0/blog/2018/egress-https/>Consuming External Web Services</a></li></ul></div></div></div><div class=card><div class=card-header role=tab id=header2><a data-toggle=collapse href=#collapse2 title="Blog posts for 2017." role=button aria-controls=collapse2><div><img src=/v1.0/img/blog.svg alt=Icon class=page_icon>
|
||
2017 Posts</div></a></div><div id=collapse2 class=collapse data-parent=#sidebar role=tabpanel aria-labelledby=header2><div class=card-body><ul class=tree><li><a title="Improving availability and reducing latency." href=/v1.0/blog/2017/mixer-spof-myth/>Mixer and the SPOF Myth</a></li><li><a title="Provides an overview of Mixer's plug-in architecture." href=/v1.0/blog/2017/adapter-model/>Mixer Adapter Model</a></li><li><a title="Istio 0.2 announcement." href=/v1.0/blog/2017/0.2-announcement/>Announcing Istio 0.2</a></li><li><a title="How Kubernetes Network Policy relates to Istio policy." href=/v1.0/blog/2017/0.1-using-network-policy/>Using Network Policy with Istio</a></li><li><a title="Using Istio to create autoscaled canary deployments." href=/v1.0/blog/2017/0.1-canary/>Canary Deployments using Istio</a></li><li><a title="Istio Auth 0.1 announcement." href=/v1.0/blog/2017/0.1-auth/>Using Istio to Improve End-to-End Security</a></li><li><a title="Istio 0.1 announcement." href=/v1.0/blog/2017/0.1-announcement/>Introducing Istio</a></li></ul></div></div></div></div></nav></div><div class="col-12 col-md-9 col-xl-8"><p class=d-md-none><label class=sidebar-toggler data-toggle=offcanvas><i class="fa fa-sign-out-alt"></i></label></p><main aria-labelledby=title><div class=pagenav><p><a href=/v1.0/blog/2019/ title="Blog posts for 2019."><i style=transform:scaleX(-1) class="fa fa-level-up-alt"></i> 2019 Posts</a></p></div><h1 id=title>Sidestepping Dependency Ordering with AppSwitch</h1><p class=byline>By <span class=attribution>Dinesh Subhraveti (AppOrbit and Columbia University)</span>
|
||
/
|
||
<span class=publish_date>January 14, 2019</span></p><nav class="toc-inlined d-xl-none d-print-none"><hr><div class=directory role=directory><nav id=InlinedTableOfContents><ul><li><a href=#dependency-ordering-problem>Dependency ordering problem</a></li><ul><li><a href=#example-scenario-ibm-websphere-nd>Example scenario: IBM WebSphere ND</a></li><li><a href=#sidecar-dependency-in-istio>Sidecar dependency in Istio</a></li></ul><li><a href=#dependency-ordering-with-appswitch>Dependency ordering with AppSwitch</a></li><ul><li><a href=#appswitch-model-and-constructs>AppSwitch model and constructs</a></li><li><a href=#decoupling-services-from-their-references>Decoupling services from their references</a></li><li><a href=#non-blocking-requests>Non-blocking requests</a></li><li><a href=#application-timeouts>Application timeouts</a></li><li><a href=#wildcard-service-references-for-sidecar-dependency>Wildcard service references for sidecar dependency</a></li></ul><li><a href=#summary>Summary</a></li><li><a href=#acknowledgements>Acknowledgements</a></li><li><a href=#see-also>See also</a></li></ul></nav></div><hr></nav><p>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.</p><h2 id=dependency-ordering-problem>Dependency ordering problem</h2><p>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.</p><p>Dependency ordering is deceptively nuanced with a host of interrelated problems. Ordering individual services requires having the dependency graph of the services so that they can be brought up starting from leaf nodes back to the root nodes. It is not easy to construct such a graph and keep it updated over time as interdependencies evolve with the behavior of the application. Even if the dependency graph is somehow provided, enforcing the ordering itself is not easy. Simply starting the services in the specified order obviously won’t do. A service may have started but not be ready to accept connections yet. This is the problem with docker-compose's <code>depends-on</code> tag, for example.</p><p>Apart from introducing sufficiently long sleeps between service startups, a common pattern that is often used is to check for readiness of dependencies before starting a service. In Kubernetes, this could be done with a wait script as part of the init container of the pod. However that means that the entire application would be held up until all its dependencies come alive. Sometimes applications spend several minutes initializing themselves on startup before making their first outbound connection. Not allowing a service to start at all adds substantial overhead to overall startup time of the application. Also, the strategy of waiting on the init container won't work for the case of multiple interdependent services within the same pod.</p><h3 id=example-scenario-ibm-websphere-nd>Example scenario: IBM WebSphere ND</h3><p>Let us consider IBM WebSphere ND – a widely deployed application middleware – to grok these problems more closely. It is a fairly complex framework in itself and consists of a central component called deployment manager (<code>dmgr</code>) that manages a set of node instances. It uses UDP to negotiate cluster membership among the nodes and requires that deployment manager is up and operational before any of the node instances can come up and join the cluster.</p><p>Why are we talking about a traditional application in the modern cloud-native context? It turns out that there are significant gains to be had by enabling them to run on the Kubernetes and Istio platforms. Essentially it's a part of the modernization journey that allows running traditional apps alongside green-field apps on the same modern platform to facilitate interoperation between the two. In fact, WebSphere ND is a demanding application. It expects a consistent network environment with specific network interface attributes etc. AppSwitch is equipped to take care of those requirements. For the purpose of this blog however, I'll focus on the dependency ordering requirement and how AppSwitch addresses it.</p><p>Simply deploying <code>dmgr</code> and node instances as pods on a Kubernetes cluster does not work. <code>dmgr</code> and the node instances happen to have a lengthy initialization process that can take several minutes. If they are all co-scheduled, the application typically ends up in a funny state. When a node instance comes up and finds that <code>dmgr</code> is missing, it would take an alternate startup path. Instead, if it had exited immediately, Kubernetes crash-loop would have taken over and perhaps the application would have come up. But even in that case, it turns out that a timely startup is not guaranteed.</p><p>One <code>dmgr</code> along with its node instances is a basic deployment configuration for WebSphere ND. Applications like IBM Business Process Manager that are built on top of WebSphere ND running in production environments include several other services. In those configurations, there could be a chain of interdependencies. Depending on the applications hosted by the node instances, there may be an ordering requirement among them as well. With long service initialization times and crash-loop restarts, there is little chance for the application to start in any reasonable length of time.</p><h3 id=sidecar-dependency-in-istio>Sidecar dependency in Istio</h3><p>Istio itself is affected by a version of the dependency ordering problem. Since connections into and out of a service running under Istio are redirected through its sidecar proxy, an implicit dependency is created between the application service and its sidecar. Unless the sidecar is fully operational, all requests from and to the service get dropped.</p><h2 id=dependency-ordering-with-appswitch>Dependency ordering with AppSwitch</h2><p>So how do we go about addressing these issues? One way is to defer it to the applications and say that they are supposed to be “well behaved” and implement appropriate logic to make themselves immune to startup order issues. However, many applications (especially traditional ones) either timeout or deadlock if misordered. Even for new applications, implementing one off logic for each service is substantial additional burden that is best avoided. Service mesh needs to provide adequate support around these problems. After all, factoring out common patterns into an underlying framework is really the point of service mesh.</p><p><a href=http://appswitch.io>AppSwitch</a> explicitly addresses dependency ordering. It sits on the control path of the application’s network interactions between clients and services in a cluster and knows precisely when a service becomes a client by making the <code>connect</code> call and when a particular service becomes ready to accept connections by making the <code>listen</code> call. It's <em>service router</em> component disseminates information about these events across the cluster and arbitrates interactions among clients and servers. That is how AppSwitch implements functionality such as load balancing and isolation in a simple and efficient manner. Leveraging the same strategic location of the application's network control path, it is conceivable that the <code>connect</code> and <code>listen</code> calls made by those services can be lined up at a finer granularity rather than coarsely sequencing entire services as per a dependency graph. That would effectively solve the multilevel dependency problem and speedup application startup.</p><p>But that still requires a dependency graph. A number of products and tools exist to help with discovering service dependencies. But they are typically based on passive monitoring of network traffic and cannot provide the information beforehand for any arbitrary application. Network level obfuscation due to encryption and tunneling also makes them unreliable. The burden of discovering and specifying the dependencies ultimately falls to the developer or the operator of the application. As it is, even consistency checking a dependency specification is itself quite complex and any way to avoid requiring a dependency graph would be most desirable.</p><p>The point of a dependency graph is to know which clients depend on a particular service so that those clients can then be made to wait for the respective service to become live. But does it really matter which specific clients? Ultimately one tautology that always holds is that all clients of a service have an implicit dependency on the service. That’s what AppSwitch leverages to get around the requirement. In fact, that sidesteps dependency ordering altogether. All services of the application can be co-scheduled without regard to any startup order. Interdependencies among them automatically work themselves out at the granularity of individual requests and responses, resulting in quick and correct application startups.</p><h3 id=appswitch-model-and-constructs>AppSwitch model and constructs</h3><p>Now that we have a conceptual understanding of AppSwitch’s high-level approach, let’s look at the constructs involved. But first a quick summary of the usage model is in order. Even though it is written for a different context, reviewing my earlier <a href=/v1.0/blog/2018/delayering-istio/delayering-istio>blog</a> on this topic would be useful as well. For completeness, let me also note AppSwitch doesn’t bother with non-network dependencies. For example it may be possible for two services to interact using IPC mechanisms or through the shared file system. Processes with deep ties like that are typically part of the same service anyway and don’t require framework’s intervention for ordering.</p><p>At its core, AppSwitch is built on a mechanism that allows instrumenting the BSD socket API and other related calls like <code>fcntl</code> and <code>ioctl</code> that deal with sockets. As interesting as the details of its implementation are, it’s going to distract us from the main topic, so I’d just summarize the key properties that distinguish it from other implementations. (1) It’s fast. It uses a combination of <code>seccomp</code> filtering and binary instrumentation to aggressively limit intervening with application’s normal execution. AppSwitch is particularly suited for service mesh and application networking use cases given that it implements those features without ever having to actually touch the data. In contrast, network level approaches incur per-packet cost. Take a look at this <a href=/v1.0/blog/2018/delayering-istio/delayering-istio>blog</a> for some of the performance measurements. (2) It doesn’t require any kernel support, kernel module or a patch and works on standard distro kernels (3) It can run as regular user (no root). In fact, the mechanism can even make it possible to run <a href=https://linuxpiter.com/en/materials/2478>Docker daemon without root</a> by removing root requirement to network containers (4) It doesn’t require any changes to the applications whatsoever and works for any type of application – from WebSphere ND and SAP to custom C apps to statically linked Golang apps. Only requirement at this point is Linux/x86.</p><h3 id=decoupling-services-from-their-references>Decoupling services from their references</h3><p>AppSwitch is built on the fundamental premise that applications should be decoupled from their references. The identity of applications is traditionally derived from the identity of the host on which they run. However, applications and hosts are very different objects that need to be referenced independently. Detailed discussion around this topic along with a conceptual foundation of AppSwitch is presented in this <a href=https://arxiv.org/abs/1711.02294>research paper</a>.</p><p>The central AppSwitch construct that achieves the decoupling between services objects and their identities is <em>service reference</em> (<em>reference</em>, for short). AppSwitch implements service references based on the API instrumentation mechanism outlined above. A service reference consists of an IP:port pair (and optionally a DNS name) and a label-selector that selects the service represented by the reference and the clients to which this reference applies. A reference supports a few key properties. (1) It can be named independently of the name of the object it refers to. That is, a service may be listening on an IP and port but a reference allows that service to be reached on any other IP and port chosen by the user. This is what allows AppSwitch to run traditional applications captured from their source environments with static IP configurations to run on Kubernetes by providing them with necessary IP addresses and ports regardless of the target network environment. (2) It remains unchanged even if the location of the target service changes. A reference automatically redirects itself as its label-selector now resolves to the new instance of the service (3) Most important for this discussion, a reference remains valid even as the target service is coming up.</p><p>To facilitate discovering services that can be accessed through service references, AppSwitch provides an <em>auto-curated service registry</em>. The registry is automatically kept up to date as services come and go across the cluster based on the network API that AppSwitch tracks. Each entry in the registry consists of the IP and port where the respective service is bound. Along with that, it includes a set of labels indicating the application to which this service belongs, the IP and port that the application passed through the socket API when creating the service, the IP and port where AppSwitch actually bound the service on the underlying host on behalf of the application etc. In addition, applications created under AppSwitch carry a set of labels passed by the user that describe the application together with a few default system labels indicating the user that created the application and the host where the application is running etc. These labels are all available to be expressed in the label-selector carried by a service reference. A service in the registry can be made accessible to clients by creating a service reference. A client would then be able to reach the service at the reference’s name (IP:port). Now let’s look at how AppSwitch guarantees that the reference remains valid even when the target service has not yet come up.</p><h3 id=non-blocking-requests>Non-blocking requests</h3><p>AppSwitch leverages the semantics of the BSD socket API to ensure that service references appear valid from the perspective of clients as corresponding services come up. When a client makes a blocking connect call to another service that has not yet come up, AppSwitch blocks the call for a certain time waiting for the target service to become live. Since it is known that the target service is a part of the application and is expected to come up shortly, making the client block rather than returning an error such as <code>ECONNREFUSED</code> prevents the application from failing to start. If the service doesn’t come up within time, an error is returned to the application so that framework-level mechanisms like Kubernetes crash-loop can kick in.</p><p>If the client request is marked as non-blocking, AppSwitch handles that by returning <code>EAGAIN</code> to inform the application to retry rather than give up. Once again, that is in-line with the semantics of socket API and prevents failures due to startup races. AppSwitch essentially enables the retry logic already built into applications in support of the BSD socket API to be transparently repurposed for dependency ordering.</p><h3 id=application-timeouts>Application timeouts</h3><p>What if the application times out based on its own internal timer? Truth be told, AppSwitch can also fake application’s perception of time if wanted but that would be overstepping and actually unnecessary. Application decides and knows best how long it should wait and it’s not appropriate for AppSwitch to mess with that. Application timeouts are conservatively long and if the target service still hasn’t come up in time, it is unlikely to be a dependency ordering issue. There must be something else going on that should not be masked.</p><h3 id=wildcard-service-references-for-sidecar-dependency>Wildcard service references for sidecar dependency</h3><p>Service references can be used to address the Istio sidecar dependency issue mentioned earlier. AppSwitch allows the IP:port specified as part of a service reference to be a wildcard. That is, the service reference IP address can be a netmask indicating the IP address range to be captured. If the label selector of the service reference points to the sidecar service, then all outgoing connections of any application for which this service reference is applied, will be transparently redirected to the sidecar. And of course, the service reference remains valid while sidecar is still coming up and the race is removed.</p><p>Using service references for sidecar dependency ordering also implicitly redirects application’s connections to the sidecar without requiring iptables and attendant privilege issues. Essentially it works as if the application is directly making connections to the sidecar rather than the target destination, leaving the sidecar in charge of what to do. AppSwitch would interject metadata about the original destination etc. into the data stream of the connection using the proxy protocol that the sidecar could decode before passing the connection through to the application. Some of these details were discussed <a href=/v1.0/blog/2018/delayering-istio/delayering-istio>here</a>. That takes care of outbound connections but what about incoming connections? With all services and their sidecars running under AppSwitch, any incoming connections that would have come from remote nodes would be redirected to their respective remote sidecars. So nothing special to do about incoming connections.</p><h2 id=summary>Summary</h2><p>Dependency ordering is a pesky problem. This is mostly due to lack of access to fine-grain application-level events around inter-service interactions. Addressing this problem would have normally required applications to implement their own internal logic. But AppSwitch makes those internal application events to be instrumented without requiring application changes. AppSwitch then leverages the ubiquitous support for the BSD socket API to sidestep the requirement of ordering dependencies.</p><h2 id=acknowledgements>Acknowledgements</h2><p>Thanks to Eric Herness and team for their insights and support with IBM WebSphere and BPM products as we modernized them onto the Kubernetes platform and to Mandar Jog, Martin Taillefer and Shriram Rajagopalan for reviewing early drafts of this blog.</p><h2 id=see-also>See also</h2><div class=see-also><div class=container-fluid><div class=row><div class="col-xs-12 col-sm-6 col-xl-4"><p class=link><a href=/v1.0/blog/2018/delayering-istio/delayering-istio/>Delayering Istio with AppSwitch</a></p><p class=desc>Automatic application onboarding and latency optimizations using AppSwitch.</p></div><div class="col-xs-12 col-sm-6 col-xl-4"><p class=link><a href=/v1.0/docs/concepts/performance-and-scalability/>Performance and Scalability</a></p><p class=desc>Introduces Performance and Scalability methodology, results and best practices for Istio components.</p></div></div></div></div></main><div class="container-fluid d-print-none"><br><div class=row><div class="col-6 pagenav"><p><a title="Istio 1.0.6 patch release." href=/v1.0/blog/2019/announcing-1.0.6/><i class="fa fa-long-arrow-alt-left"></i>Announcing Istio 1.0.6</a></p></div><div class="col-6 pagenav" style=text-align:right><p><a title="Describes how to deploy a custom ingress gateway using cert-manager manually." href=/v1.0/blog/2019/custom-ingress-gateway/>Deploy a custom ingress gateway using cert-manager
|
||
<i class="fa fa-long-arrow-alt-right"></i></a></p></div></div></div><div class="d-none d-print-block" aria-hidden=true><h2>Links</h2><ol id=endnotes></ol></div></div><div class="col-12 col-md-2 d-none d-xl-block d-print-none"><nav class=toc><div class=spacer></div><div id=toc class=directory role=directory><nav id=TableOfContents><ul><li><a href=#dependency-ordering-problem>Dependency ordering problem</a></li><ul><li><a href=#example-scenario-ibm-websphere-nd>Example scenario: IBM WebSphere ND</a></li><li><a href=#sidecar-dependency-in-istio>Sidecar dependency in Istio</a></li></ul><li><a href=#dependency-ordering-with-appswitch>Dependency ordering with AppSwitch</a></li><ul><li><a href=#appswitch-model-and-constructs>AppSwitch model and constructs</a></li><li><a href=#decoupling-services-from-their-references>Decoupling services from their references</a></li><li><a href=#non-blocking-requests>Non-blocking requests</a></li><li><a href=#application-timeouts>Application timeouts</a></li><li><a href=#wildcard-service-references-for-sidecar-dependency>Wildcard service references for sidecar dependency</a></li></ul><li><a href=#summary>Summary</a></li><li><a href=#acknowledgements>Acknowledgements</a></li><li><a href=#see-also>See also</a></li></ul></nav></div></nav></div></div></div></div><footer class="d-print-none container-fluid"><div class=row><div class="col-5 col-lg-4" role=navigation><div class=container-fluid><div class=row><div class=icon><span>discuss</span>
|
||
<a title="Join the Istio discussion board to participate in discussions and get help troubleshooting problems" href=https://discuss.istio.io aria-label="Istio discussion board"><svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 448 512"><path d="M225.9 32C103.3 32 0 130.5.0 252.1.0 256 .1 480 .1 480l225.8-.2c122.7.0 222.1-102.3 222.1-223.9S348.6 32 225.9 32zM224 384c-19.4.0-37.9-4.3-54.4-12.1L88.5 392l22.9-75c-9.8-18.1-15.4-38.9-15.4-61 0-70.7 57.3-128 128-128s128 57.3 128 128-57.3 128-128 128z" /></svg></a></div><div class=icon><span>slack</span>
|
||
<a title="Interactively discuss issues with the Istio community on Slack" href=https://istio.slack.com aria-label=slack><svg viewBox="0 0 31.444 31.443"><path d="M31.202 16.369c-.62-1.388-2.249-2.011-3.637-1.391l-1.325.594-3.396-7.591 1.325-.592c1.388-.622 2.01-2.25 1.389-3.637-.62-1.389-2.248-2.012-3.637-1.39l-1.324.593-.593-1.326c-.621-1.388-2.249-2.009-3.637-1.388-1.388.62-2.009 2.247-1.389 3.637l.593 1.325L7.98 8.598 7.388 7.273c-.621-1.39-2.249-2.009-3.637-1.39C2.363 6.504 1.742 8.132 2.362 9.52l.592 1.324L1.63 11.438c-1.388.621-2.01 2.247-1.389 3.636.62 1.388 2.249 2.01 3.637 1.39l1.325-.594 3.394 7.592-1.325.592c-1.388.621-2.009 2.25-1.389 3.637.621 1.389 2.249 2.011 3.637 1.391l1.324-.593.593 1.325c.621 1.389 2.249 2.01 3.637 1.389 1.387-.62 2.009-2.248 1.388-3.636l-.591-1.326 7.591-3.394.592 1.321c.621 1.391 2.248 2.013 3.637 1.392 1.388-.619 2.01-2.248 1.389-3.637l-.592-1.324 1.323-.594C31.201 19.384 31.823 17.757 31.202 16.369zM13.623 21.215l-3.395-7.593 7.591-3.394 3.395 7.591L13.623 21.215z"/></svg></a></div><div class=icon><span>twitter</span>
|
||
<a title="Follow us on Twitter to get the latest news" href=https://twitter.com/IstioMesh aria-label=Twitter><svg viewBox="0 0 310 310"><path d="M302.973 57.388c-4.87 2.16-9.877 3.983-14.993 5.463 6.057-6.85 10.675-14.91 13.494-23.73.632-1.977-.023-4.141-1.648-5.434-1.623-1.294-3.878-1.449-5.665-.39-10.865 6.444-22.587 11.075-34.878 13.783-12.381-12.098-29.197-18.983-46.581-18.983-36.695.0-66.549 29.853-66.549 66.547.0 2.89.183 5.764.545 8.598C101.163 99.244 58.83 76.863 29.76 41.204c-1.036-1.271-2.632-1.956-4.266-1.825-1.635.128-3.104 1.05-3.93 2.467-5.896 10.117-9.013 21.688-9.013 33.461.0 16.035 5.725 31.249 15.838 43.137-3.075-1.065-6.059-2.396-8.907-3.977-1.529-.851-3.395-.838-4.914.033-1.52.871-2.473 2.473-2.513 4.224-.007.295-.007.59-.007.889.0 23.935 12.882 45.484 32.577 57.229-1.692-.169-3.383-.414-5.063-.735-1.732-.331-3.513.276-4.681 1.597-1.17 1.32-1.557 3.16-1.018 4.84 7.29 22.76 26.059 39.501 48.749 44.605-18.819 11.787-40.34 17.961-62.932 17.961-4.714.0-9.455-.277-14.095-.826-2.305-.274-4.509 1.087-5.294 3.279-.785 2.193.047 4.638 2.008 5.895 29.023 18.609 62.582 28.445 97.047 28.445 67.754.0 110.139-31.95 133.764-58.753 29.46-33.421 46.356-77.658 46.356-121.367.0-1.826-.028-3.67-.084-5.508 11.623-8.757 21.63-19.355 29.773-31.536 1.237-1.85 1.103-4.295-.33-5.998C307.394 57.037 305.009 56.486 302.973 57.388z"/></svg></a></div><div class=icon><span>stack overflow</span>
|
||
<a title="Stack Overflow is where you can ask questions and find curated answers on deploying, configuring, and using Istio" href=https://stackoverflow.com/questions/tagged/istio aria-label="Stack Overflow"><svg viewBox="0 0 120 120"><polygon points="84.4,93.8 84.4,70.6 92.1,70.6 92.1,101.5 22.6,101.5 22.6,70.6 30.3,70.6 30.3,93.8"/><path d="M38.8 68.4l37.8 7.9 1.6-7.6-37.8-7.9L38.8 68.4zM43.8 50.4l35 16.3 3.2-7-35-16.4L43.8 50.4zM53.5 33.2l29.7 24.7 4.9-5.9L58.4 27.3 53.5 33.2zM72.7 14.9l-6.2 4.6 23 31 6.2-4.6-23-31zM38 86h38.6v-7.7H38V86z"/></svg></a></div></div><div class="tag row d-none d-lg-flex">for everyone</div></div></div><div class="col-7 col-lg-4"><p class="text-center copyright" role=contentinfo>Istio
|
||
Archive
|
||
1.0<br>© 2019 Istio Authors, <a href=https://policies.google.com/privacy>Privacy Policy</a><br>Archived on March 19, 2019</p></div><div class="col-6 col-lg-4 d-none d-lg-flex" role=navigation><div class=container-fluid><div class="row justify-content-end"><div class=icon><span>github</span>
|
||
<a title="GitHub is where development takes place on Istio code" href=https://github.com/istio/community aria-label=GitHub><svg viewBox="0 0 478.165 478.165"><path d="M349.22 55.768c6.136 14.046 10.241 37.556 4.224 54.69 24.426 20.999 33.073 71.904 21.079 113.704 35.006 2.73 76.666-1.235 103.642 9.484-25.183-3.248-59.651-9.563-91.987-7.431-6.136.458-15.361-.239-14.903 8.408 37.735 3.008 75.092 6.117 105.894 15.779-30.702-4.981-67.74-12.552-105.894-13.668-15.54 30.921-47.239 46.262-90.991 49.49 4.682 10.261 13.847 14.066 15.879 30.702 3.267 24.406-4.881 60.328 3.208 76.686 4.064 7.89 10.579 8.009 14.863 14.604-10.699 12.871-37.257-1.395-40.186-14.604-5.14-22.852 7.89-58.256-6.415-73.737.996 24.865-5.718 59.85.996 82.145 2.789 8.806 10.659 12.113 8.647 20.063-49.809 5.08-28.989-64.373-37.177-105.356-7.471.697-4.204 11.197-4.224 15.76-.199 40.106 8.189 94.836-34.846 89.556-1.315-8.348 5.838-11.217 8.467-19.007 7.91-22.434-1.454-56.045 2.112-83.161-16.417 12.512 1.793 55.666-8.428 77.961-5.838 12.671-24.785 18.27-39.19 12.651 1.873-9.464 11.695-7.989 15.879-16.875 5.818-12.452.02-30.244 2.092-48.494-30.423 6.097-53.993-.877-65.608-20.023-5.12-8.507-6.356-18.708-12.632-26.219-6.117-7.551-16.098-8.507-19.087-18.808 37.755-9.185 39.17 38.771 73.06 39.807 10.44.418 15.799-2.909 25.402-5.16 2.749-12.113 8.428-21.039 16.875-27.494-42.078-5.658-76.865-18.788-93.023-50.466-38.293 1.893-73.339 7.013-105.894 14.843 29.547-10.679 65.807-14.604 104.778-15.819-2.351-13.807-22.434-10.022-34.866-9.543C47.677 227.17 18.449 230.138.0 233.645c26.817-9.543 64.233-8.348 100.454-8.428-11.038-34.767-7.232-90.014 17.015-110.615-6.854-17.254-4.722-45.346 4.184-58.834 27.036 1.175 43.374 12.891 60.388 24.247 21.019-6.017 43.035-9.045 71.904-7.451 12.133.677 24.705 6.097 33.731 5.32 8.906-.877 18.728-10.898 27.534-14.843C326.507 58.099 336.17 56.206 349.22 55.768z"/></svg></a></div><div class=icon><span>drive</span>
|
||
<a title="Access our team drive if you'd like to take a look at the Istio technical design documents" href=https://groups.google.com/forum/#!forum/istio-team-drive-access aria-label="team drive"><svg viewBox="0 0 207.027 207.027"><path d="M69.866 15.557.0 138.919l28.732 52.552 143.288-.029 35.008-59.588L136.39 15.735 69.866 15.557zM17.166 139.046 74.268 38.205 91.21 67.783 33.24 168.447 17.166 139.046zM99.841 82.851l23.805 41.558-47.732-.006L99.841 82.851zM163.434 176.443l-117.332.024 21.53-37.065 64.606.008.067.119 52.865-.085L163.434 176.443zM140.932 124.411 90.157 35.767l-2.966-5.178 40.751.121 57.003 93.706L140.932 124.411z"/></svg></a></div><div class=icon><span>working groups</span>
|
||
<a title="If you'd like to contribute to the Istio project, consider participating in our working groups" href=https://github.com/istio/community/blob/master/WORKING-GROUPS.md aria-label="working groups"><svg viewBox="0 -45 439.833 439.833"><polygon points="246.048,195.833 299.966,235.085 319.497,227.296 276.278,195.833"/><polygon points="193.786,195.833 163.556,195.833 120.33,227.3 139.862,235.089"/><path d="M219.927 11.558c-23.854.0-37.057 12.362-36.814 36.182.348 32.623 14.211 52.414 36.814 52.068.0.0 36.802 1.492 36.802-52.068C256.729 23.918 244.294 11.558 219.927 11.558z"/><path d="M285.017 124.567l-36.77-14.659-8.608-7.256c-2.274-1.922-5.636-1.78-7.741.317l-11.973 11.904-12.008-11.907c-2.109-2.094-5.465-2.229-7.736-.313l-8.611 7.256-36.77 14.661c-11.842 4.715-11.83 46.647-12.848 50.497h155.93C296.866 171.228 296.862 129.28 285.017 124.567z"/><path d="M77.976 228.568s36.801 1.492 36.801-52.068c0-23.82-12.434-36.182-36.801-36.182-23.854.0-37.057 12.362-36.814 36.182C41.509 209.124 55.372 228.915 77.976 228.568z"/><path d="M143.065 253.329l-36.77-14.658-8.609-7.256c-2.275-1.923-5.635-1.781-7.742.315l-11.971 11.904-12.008-11.908c-2.109-2.094-5.465-2.229-7.736-.312l-8.611 7.256-36.77 14.66C1.006 258.045 1.018 299.977.0 303.827h155.93C154.915 299.988 154.911 258.042 143.065 253.329z"/><path d="M361.878 228.568s36.801 1.492 36.801-52.068c0-23.82-12.434-36.182-36.801-36.182-23.854.0-37.057 12.362-36.812 36.182C325.411 209.124 339.274 228.915 361.878 228.568z"/><path d="M426.968 253.329l-36.77-14.658-8.609-7.256c-2.273-1.923-5.635-1.781-7.742.315l-11.971 11.904-12.008-11.908c-2.109-2.094-5.465-2.229-7.736-.312l-8.61 7.256-36.771 14.66c-11.842 4.715-11.83 46.646-12.848 50.497h155.93C438.817 299.988 438.812 258.042 426.968 253.329z"/></svg></a></div></div><div class="tag row justify-content-end text-right">for developers</div></div></div></div></footer><div class="d-xl-none d-print-none"><button id=scroll-to-top aria-hidden=true onclick=scrollToTop() title="Back to top"><i class="fa fa-lg fa-arrow-up"></i></button></div><script src=https://code.jquery.com/jquery-3.2.1.slim.min.js integrity=sha384-KJ3o2DKtIkvYIK3UENzmM7KCkRr/rE9/Qpg6aAZGJwFDMVNA/GpGFF93hXpG5KkN crossorigin=anonymous></script><script src=https://maxcdn.bootstrapcdn.com/bootstrap/4.0.0/js/bootstrap.min.js integrity=sha384-JZR6Spejh4U02d8jOt6vLEHfe/JQGiRRSQQxSfFWpi1MquVdAyjUar5+76PVCmYl crossorigin=anonymous></script><script src=https://cdnjs.cloudflare.com/ajax/libs/clipboard.js/1.7.1/clipboard.min.js></script><script src="https://www.google.com/cse/brand?form=search_form"></script><script src=/v1.0/js/all.min.js data-manual></script></body></html> |