We Make Service Mesh Easy

 

F5 NETWORKS

ASPEN MESH BETA AGREEMENT

Use of the BETA PRODUCT AND OTHER F5 PROPERTY is subject to the TERMS AND CONDITIONS of THIS ASPEN MESH BETA AGREEMENT (THIS “AGREEMENT”).

BY CLICKING ON THE “I AGREE” BUTTON IMMEDIATELY BELOW, REGISTERING FOR OR USING AN ACCOUNT (“ACCOUNT”) FOR THE BETA PRODUCT, OR BY ACCESSING THE BETA PRODUCT (THE FIRST INSTANCE OF ANY OF THE FOREGOING, AN “ACCEPTANCE”), YOU (1) agree to this “Agreement” and the BETA portal terms of use (THE “PORTAL TERMS OF USE”) on behalf of yourself and the Customer identified in the BETA PORTAL (the “Customer” or “YOU”), (2) represent and warrant that you are authorized to AGREE TO this Agreement AND THE PORTAL TERMS OF USE on behalf of the Customer, and (3) agree that such Customer will be responsible for the acts and omissions of any individuals or other users who register for, access or use f5 property through your account or under this agreement. FOR AVOIDANCE OF DOUBT, YOUR ACCEPTANCE IS ON BEHALF OF YOURSELF AND OF YOUR ORGANIZATION’S EMPLOYEES, AGENTS, CONSULTANTS OR OTHER REPRESENTATIVES (“CUSTOMER REPRESENTATIVES”).  IF YOU AND/OR CUSTOMER DOES NOT AGREE TO ALL OF THE TERMS OF THIS AGREEMENT OR THE PORTAL TERMS OF USE, DO NOT ACCEPT THIS AGREEMENT AND DO NOT ACCESS THE BETA PRODUCT.

All references to “F5” in this Agreement are references to the applicable F5 entity as follows: (i) if the Customer’s primary place of business is located in Europe, the Middle East or Africa (“EMEA”), the F5 entity is F5 Networks Ltd.; (ii) if the Customer’s primary place of business is located in the Asia-Pacific region (“APAC”), the F5 entity is F5 Networks Singapore Pte Ltd.; and (iii) if the Customer’s primary place of business is located in a region outside of EMEA or APAC, the F5 entity is F5 Networks, Inc.  As used herein, “Customer” or “you”, on the one hand, and “F5”, “we”, or “us”, on the other hand, shall each be “a Party” hereto, and may collectively be referred to as “the Parties” hereto.

You will provide accurate, current and complete information (including about Customer and Customer’s users) in all registration and other Account-related forms on the Beta Portal (“Customer Information”) and you will maintain the security of your username(s) and password(s). You will maintain and promptly update the Customer Information to keep it accurate, current and complete. YOU UNDERSTAND THAT ANY PERSON WITH YOUR USERNAME(S) AND PASSWORD(S) MAY BE ABLE TO ACCESS YOUR ACCOUNT. YOU ACCEPT ALL RISKS OF UNAUTHORIZED ACCESS TO YOUR ACCOUNT BASED ON THE SHARING OR LOSS OF A USERNAME AND PASSWORD. You will promptly notify F5 if you discover or otherwise suspect any unauthorized access related to your Account, the Beta Product, including any unauthorized use or disclosure of a username or password.

1.  Definitions.

1.1.    “Beta Period” means the period in which Customer may use the Beta Product, and if no period is specified, until F5 specifies otherwise.

1.2.    “Beta Portal” means the Aspen Mesh Beta Portal website located at https://my.aspenmesh.io/.

1.3.    “Beta Services” means the F5 beta service(s) and documentation offered through F5’s software-as-a-service platform, as such may be reasonably modified by F5 from time to time.

“Beta Software” means the F5 beta software product(s) and documentation offered through the Beta Portal for download.

1.5.    “Beta Product” means the Beta Software, the Beta Services, and the Beta Portal.

1.6.    “F5 Property” means (a) the Beta Product and all other software, hardware, technology, documentation, and information provided by F5 in connection with the Beta Product, and all enhancements, modifications and improvements thereto; (b) all internal documentation, specifications, product requirements, problem reports, analysis and performance information, benchmarks, software documents, and other technical, business, product, marketing and financial information, plans and data relating to the Beta Services; (c) all ideas, know-how, and techniques that may be developed, conceived, or invented by F5 during its performance under this Agreement; and (d) all worldwide patent, copyright, trade secret, trademark and other intellectual property rights in and to the property described in clauses (a), (b) and (c) above.

2. Use of Beta Product.

2.1.    License and Rights Grants. Subject to this Agreement, (a) F5 hereby grants Customer (i) a non-exclusive, non-transferable, non-sublicensable, revocable license, during the Beta Period to use the Beta Software, in object code form, solely for Customer’s internal evaluation and testing purposes (the “Purpose”), solely with Customer’s test data, and solely in a non-production environment, and (ii) a non-exclusive, non-transferable, revocable right, during the Beta Period, to access and use the Beta Services and Beta Portal solely for the Purpose; and (b) Customer hereby grants F5 a non-exclusive, non-transferable, worldwide right to use the electronic data that is transmitted to or through the Beta Services by Customer or on Customer’s behalf (collectively, “Customer Data”) for the purpose of providing the Beta Product.

2.2.    Ownership. Subject to this Agreement, F5 and its licensors and suppliers own and retain all right, title, and interest in and to the F5 Property.  Except for the rights granted in Section 2.1 above, no right, title or interest in and to the F5 Property is granted or conveyed to Customer by implication or otherwise.  Subject to this Agreement, Customer owns and retains all right, title, and interest in and to the Customer Data and all intellectual property rights therein.

2.3.    Restrictions.  Customer shall use the Beta Product solely as expressly permitted in Section 2 hereof and solely in accordance with any documentation or instructions supplied by F5. Customer shall not (a) demonstrate, market, reuse, copy, modify, translate or create derivative works of, or otherwise attempt to derive, analyze or use any source code of, or underlying ideas or algorithms pertaining to, the F5 Property or any portion thereof by any means whatsoever; (b) rent, sell, lease, transfer or otherwise make available the F5 Property or any portion thereof to any third party, or use it or any portion thereof for the benefit of a third party (such third parties including Customer affiliates); (c) dissemble, de-compile, reverse assemble, reverse compile or reverse engineer the F5 Property or any portion thereof, or otherwise attempt to discover any F5 Property source code or underlying proprietary information; (d) remove, obscure, or alter any intellectual property right or confidentiality notices or legends appearing in or on any aspect of any the F5 Property; or (e) use any information in any way related to or acquired by use of the Beta Services other than in connection with Customer’s evaluation of the Beta Product.  In addition to the foregoing, Customer will not introduce or permit to be submitted or received by the Beta Services: (x) any data other than Customer’s test data, (y) any Personal Data; or (z) any infringing, obscene, libelous, or otherwise unlawful data or material.  “Personal Data” shall mean information about any individual person that can be used to distinguish or trace the person’s identity, such as their name, social security number, or biometric records, whether alone or combined with other personal or identifying information that is linked or linkable to a specific individual such as date and place of birth or mother’s maiden name.  Personal Data further includes other information deemed “personal data”, “personal health information”, or “personally identifiably information” under applicable data privacy laws.  In addition to F5’s other rights and remedies hereunder, F5 may immediately (and without prior notice) suspend (including but not limited to any transmission of Customer Data to or through the Beta Services) or terminate this Agreement if Customer violates the restrictions in this subsection.

2.4.    Additional Obligations.

2.4.1.   Customer will not disclose the results of any benchmarking or other tests of the Beta Services or any portion thereof to any third party without F5’s prior written consent.

2.4.2.   Customer hereby agrees to report to F5 on the performance of the Beta Product and shall provide suggestions, comments or other feedback to F5 with respect to improving the Beta Product (collectively, “Feedback”).  F5 may freely use, disclose, reproduce, license, distribute, and otherwise commercially exploit the Feedback without obligation or restriction of any kind.

2.4.3.   Customer will promptly report to F5 any problems with the Beta Product.

3. Term and Termination.

3.1.    The term of this Agreement will commence upon Acceptance and will continue until the completion of the Beta Period or until earlier terminated in accordance with this Agreement. This Agreement may be terminated by any Party for any reason or no reason upon written notice to another Party, and in any case will expire at the end of the Beta Period. F5 may extend the Beta Period upon written notice to Customer. F5 may also, upon written notice, or earlier (with subsequent written notice) in the case of a question of the security or integrity of your Account or the Beta Product: (a) discontinue the beta program or your Account at any time, in which case this Agreement will automatically terminate at the time of such discontinuation, or (b) suspend your Account or access to any part of the Beta Product without otherwise terminating the Beta Period.

3.2.    Upon termination of this Agreement, the licenses and rights granted to Customer hereunder will terminate and F5 may terminate Customer’s access to and use of the F5 Property immediately.  Upon termination, Customer will immediately destroy and delete all F5 Property (including Beta Software and other Confidential Information) in Customer’s possession or control. Upon F5’s request, Customer agrees to certify in writing to Customer’s compliance herewith. Following termination of this Agreement, F5 may destroy Customer Data and other Customer Confidential Information that is in its possession or control. Any terms by which their nature impose an obligation after termination will survive termination or expiration of this Agreement, including but not limited to confidentiality, disclaimer of warranties, limitation of liabilities, indemnification, and governing law.

4. Confidentiality.

4.1.    Subject to the exceptions listed below, a disclosing Party’s “Confidential Information” shall be defined as information disclosed by the disclosing Party to the receiving Party under this Agreement that is either:  (a) clearly marked or otherwise clearly designated as confidential or proprietary; or (b) should be reasonably understood by the receiving Party to be the confidential or proprietary information of the disclosing Party.  For the avoidance of doubt, F5 Property and all pricing under this Agreement is the Confidential Information of F5, and Customer Data is the Confidential Information of Customer.  Confidential Information of the disclosing Party does not include information that (i) is previously rightfully known to the receiving Party without restriction on disclosure, (ii) is or becomes known to the general public, through no act or omission on the part of the receiving Party, (iii) is disclosed to the receiving Party by a third party without breach of any separate nondisclosure obligation, or (iv) is independently developed by the receiving Party without resort to the Confidential Information of the disclosing Party.

4.2.    The receiving Party will hold in confidence, using reasonable measures to protect, and not use any Confidential Information except in connection with its obligations and rights under this Agreement and shall not disclose the Confidential Information to any third party except to its employees, consultants, independent contractors and agents who have a need to know in connection with this Agreement and who have signed confidentiality agreements or are otherwise bound by confidentiality obligations at least as restrictive as those contained herein; provided, however, that F5 may use and disclose the Confidential Information of Customer as necessary for the limited purpose of performing the Beta Services hereunder.  If required by law or government order of competent jurisdiction, the receiving Party may disclose Confidential Information of the disclosing Party but will give adequate prior notice of such disclosure to the disclosing Party (unless prohibited by law or government order) to permit the disclosing Party to intervene and to request protective orders or other confidential treatment therefor.

4.3.    Money damages may not be an adequate remedy if this Section 4 is breached and, therefore, either Party shall, in addition to any other legal or equitable remedies, be entitled to seek an injunction or other equitable relief against such breach or threatened breach without the necessity of posting any bond or surety.

5. Representations and Warranties. Customer hereby warrants, represents and covenants as follows:  (a) Customer has the authority to grant the rights granted by Customer under this Agreement and to perform its obligations under this Agreement; (b) in the performance of its obligations and use of the Beta Product, Customer will not violate any applicable laws or infringe the proprietary or privacy rights of any third party; (c) the Customer Data that Customer transmits or permits to be transmitted to or through the Beta Services or Beta Portal complies and will at all times during the term of this Agreement comply with all applicable laws and does not and will not infringe the proprietary rights or privacy rights of any third parties; (d) when using the Beta Services Customer will comply with all applicable acceptable use policies for which Customer has received notice and will not cause or allow others to cause the disruption of other parties’ use or enjoyment of the Internet; (e) Customer does not currently provide services that compete with the Beta Product and will not at any time in the future use the Beta Services or any other Confidential Information for the provision of any services that compete with the Beta Services; and (f) Customer shall comply with all applicable export laws, restrictions and regulations of the U.S. Department of Commerce, and all other applicable U.S. and foreign authority.  In addition, Customer hereby represents and warrants that it is not (nor are any Customer Representatives) on the U.S. Treasury Department’s list of Specially Designated Nationals or the U.S. Department of Commerce’s Table of Denial Orders.

6. Warranty Disclaimer; Warning. Customer acknowledges that the Beta Product is provided “AS IS”. Customer understands that the Beta Product has not completed F5’s full quality assurance program and may have errors and may produce unexpected results. F5 DISCLAIMS ALL WARRANTIES RELATING TO THE BETA PRODUCT, EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, ANY WARRANTIES AS TO TITLE, NON-INFRINGEMENT, MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE (INCLUDING, WITHOUT LIMITATION, PREVENTION OF UNAUTHORIZED ACCESS), THAT THE BETA PRODUCT WILL BE FREE FROM ERROR OR INTERRUPTION OR FAILURE. F5 NEITHER ASSUMES, NOR AUTHORIZES ANY OTHER PERSON TO ASSUME FOR IT, ANY OTHER LIABILITY IN CONNECTION WITH THE BETA PRODUCT OR ANY INFORMATION PROVIDED IN CONNECTION THEREWITH, INCLUDING, WITHOUT LIMITATION, LIABILITY ARISING OUT OF THE OPERATION, SUPPORT, OR USE OF THE BETA PRODUCT. F5 DOES NOT WARRANT THE RESULTS OF THE BETA PRODUCT OR THAT ANY ERRORS IN THE BETA PRODUCT WILL BE CORRECTED, OR THAT THE BETA PRODUCT WILL MEET CUSTOMER’S REQUIREMENTS OR EXPECTATIONS. CUSTOMER SHOULD SAFEGUARD IMPORTANT DATA, USE CAUTION, AND NOT RELY IN ANY WAY ON THE CORRECT FUNCTIONING OR PERFORMANCE OF THE BETA PRODUCT AND/OR ACCOMPANYING MATERIALS.

7. Limitation of Remedies and Damages. IN NO EVENT WILL F5 OR ITS LICENSORS OR SUPPLIERS BE LIABLE FOR ANY INDIRECT, INCIDENTAL, SPECIAL, CONSEQUENTIAL OR PUNITIVE, DAMAGES INCLUDING, BUT NOT LIMITED TO LOSS OF PROFITS, REVENUE, DATA OR MACHINE USE, BUSINESS INTERRUPTION ARISING OUT OF OR IN CONNECTION WITH THIS AGREEMENT, THE USE OR THE INABILITY OF THE USE OR PERFORMANCE OF THE BETA PRODUCT, THE PROVISION OF OR FAILURE TO PROVIDE THE BETA PRODUCT, OR ANY INFORMATION PROVIDED, REGARDLESS OF THE NATURE OF THE ACTION OR UNDERLYING LEGAL THEORY (INCLUDING UNDER ANY CONTRACT, NEGLIGENCE, STRICT LIABILITY OR OTHER THEORY), EVEN IF F5 AND/OR ITS LICENSORS OR SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. F5 WILL NOT BE RESPONSIBLE FOR ANY MATTER BEYOND ITS REASONABLE CONTROL. IN NO EVENT WILL F5’S TOTAL AGGREGATE LIABILITY UNDER THIS AGREEMENT EXCEED ONE THOUSAND DOLLARS ($1,000). NO ACTION, REGARDLESS OF FORM, ARISING UNDER THIS AGREEMENT MAY BE BROUGHT BY CUSTOMER MORE THAN ONE YEAR AFTER THE END OF THE BETA PERIOD.

8. Customer Acknowledgement. CUSTOMER ACKNOWLEDGES THE NATURE OF THE BETA PRODUCT, AND THAT IT MAY CONTAIN KNOWN OR UNKNOWN BUGS, DEFECTS AND ERRORS, MAY NOT FUNCTION AS INTENDED, MAY NOT FUNCTION AT THE LEVEL OF A FINAL, GENERALLY AVAILABLE PRODUCT, MAY CREATE UNFORESEEABLE EVENTS, AND MAY BE SUBSTANTIALLY MODIFIED PRIOR TO FIRST GENERAL COMMERCIAL AVAILABILITY, OR WITHDRAWN ENTIRELY. CUSTOMER ACKNOWLEDGES THAT THE PRODUCT IS INTENDED TO BE USED ONLY IN A NON-PRODUCTION ENVIRONMENT, WITH TEST DATA, AND NOT FOR PRODUCTION PURPOSES. F5 HAS NO OBLIGATION TO CORRECT ANY BUGS, DEFECTS OR ERRORS IN THE BETA PRODUCT OR OTHERWISE SUPPORT OR MAINTAIN THE BETA PRODUCT. F5 RESERVES THE RIGHT AT ANY TIME NOT TO GENERALLY COMMERCIALLY RELEASE THE BETA PRODUCT OR, EVEN IF RELEASED, TO ALTER PRICES, FEATURES, SPECIFICATIONS, CAPABILITIES, FUNCTIONS, RELEASE DATES, GENERAL AVAILABILITY, OR OTHER CHARACTERISTICS OF THE BETA PRODUCT.

9. Indemnification. Customer will defend, indemnify and hold F5, and its affiliates and their respective officers, directors, licensors, suppliers, service providers, employees, contractors and agents harmless against any claims, liabilities or expenses incurred (including reasonable attorneys’ fees), as well as amounts finally awarded in a settlement or by a court arising from any (a) breach by Customer or any Customer Representative of any representation, warranty, covenant or other obligation of this Agreement, (b) negligence or willful misconduct of Customer or Customer Representatives, or (c) liability arising out of or relating to the use of F5 Property. F5 will provide Customer (i) prompt written notice of any such claim or allegation, provided that any delay in providing such notice shall not impact Customer’s obligations hereunder except to the extent that Customer is materially prejudiced by such delay; (ii) control of the defense and settlement thereof, provided that any settlement shall be subject to F5’s prior written approval; and (iii) reasonable assistance in such defense or settlement, at Customer’s expense.  Notwithstanding the foregoing, if Customer does not timely assume control of the defense thereof, F5 may do so on its own, after prior notice to Customer, and in turn Customer shall provide reasonable assistance in such defense or settlement, at Customer’s expense.

10. Customer Performance and Usage Data. F5 may measure and monitor Customer interaction with the Beta Product, and to generate reports relating to use of the Beta Product under this Agreement. All information and status reports derived from such use of the Product will be considered F5 Property. Customer will not disclose such information or reports. F5 may use Aggregated Data derived from the use of the Beta Product to support and improve F5 products and services, in the development of new features, products, tools, content, and for market research. “Aggregated Data” means Customer Data and usage information that has been stripped of all Personal Data and any information that identifies Customer.

11. General.

11.1.  Entire Agreement. This Agreement constitutes the entire agreement between the Parties pertaining to the subject matter hereof, and supersedes any and all prior proposals, negotiations, communications, and agreements, written or oral previously existing between the Parties pertaining to the subject matter hereof.  Without limiting the generality of the foregoing, in the event of a conflict between the terms of this Agreement and any other agreement between the Parties, this Agreement will govern with respect to any component of the Beta Product or any portion thereof to the extent used as part of the Beta Product. F5 will not be bound by the use of any standardized form or correspondence (including any order form, purchase order, acknowledgement, shrink-wrap, boxtop, or click wrap license, or other form) containing additional or different terms. f5 may, at any time and in its discretion, modify this Agreement by providing written notice, including but not limited to the posting of a notice of changes to the beta portal.  customer’s continued use of the Beta product after f5 modifies this Agreement constitutes customer’s acceptance of the changes. If cUSTOMER doES not agree to any changes, CUSTOMER must terminate this agreement and discontinue all use of the beta product.

11.2.  Governing Law, Attorneys’ Fees. This Agreement, and all matters arising out of or relating to this Agreement, will be governed by and construed in accordance with the laws of the jurisdiction set forth in the governing law column opposite the applicable undersigned F5 entity in the table below, without regard to that jurisdiction’s choice of law rules. Further, for any action arising out of or related to this Agreement, Customer consents to the exclusive jurisdiction and venue of the courts located in the venue column opposite the applicable undersigned F5 entity in the table below.

F5 Entity: Governing Law: Venue:
F5 Networks Singapore Pte Ltd The laws of Singapore Singapore
F5 Networks Ltd. The laws of England and Wales London, England
F5 Networks, Inc. The laws of the State of Washington Seattle, Washington

 

The Parties agree that the United Nations Convention on Contracts for the International Sale of Goods (CISG) and the Uniform Computer Information Transactions Act, in whatever form adopted, does not apply to this Agreement and the Parties specifically opt out of the application of such laws. If either Party engages attorneys to enforce any rights arising out of or relating to this Agreement, the prevailing Party will be entitled to recover reasonable attorneys’ fees.

11.3.  Assignment. Customer may not assign this Agreement in whole or in part, without F5’s prior written consent. F5 may assign this Agreement or any of its rights and obligations under it at any time. Any attempted assignment or transfer in violation of this Section will be void and without effect. Subject to the foregoing, this Agreement will be binding upon and shall inure to the benefit of the Parties and their respective permitted successors and assigns. F5 may subcontract parts of the Beta Services to third parties or provision of services related to management and hosting of the Beta Product to third parties (such third parties including but not limited to F5’s affiliates). F5 is responsible for breaches of this Agreement caused by its subcontractors.

11.4.  Export Control; U.S. Government Restricted Rights.  F5 Property is subject to export control laws of various countries, including the laws of the United States. Customer will not submit F5 Property to any government agency for licensing consideration or other regulatory approval and will not export F5 Property to countries, persons or entities if prohibited by export laws.  Notwithstanding, in any case, if Customer uses the Beta Product by or for any unit or agency of the United States Government, this provision applies. The Beta Product and any associated documentation are “commercial items” incorporating “commercial computer software” and “commercial computer software documentation” as such terms are defined in the Federal Acquisition Regulations (48 C.F.R.) (the “FAR”) 2.101 and its supplements. The Parties agree that the Beta Product was developed entirely at private expense, that no part of the Beta Product was first produced in the performance of a Government contract. Use and/or access of the Beta Product constitutes acknowledgment of F5’s and its licensors’ and suppliers’ rights in the Beta Product.

11.5.  Notices. Any notice or other communication required or permitted under this Agreement must be in writing in English and will be deemed given three (3) business days after it is sent by registered or certified mail, return receipt requested and postage prepaid, one (1) business day after it is sent via reputable nationwide courier service, or upon personal delivery, or upon posting to or sending of a notification in the Beta Portal. F5 may also provide notice by email or other electronic delivery, which shall be deemed given immediately upon transmission to the address set forth on Customer’s Account. Notices to Customer may also be sent to the address set forth in Customer’s Account or other address provided to F5 in the registration process for the Beta Product. All notices to F5 will be sent to the address(es) of the applicable F5 entity in the table below. Either Party may change its address by giving the other Party written notice in accordance with this Section.

F5 Entity: Notice Address: With a Copy to:
F5 Networks Singapore Pte Ltd F5 Networks Singapore Pte Ltd

Attn: Legal Department

5 Temasek Boulevard

#08-01/02/05 Suntec Tower 5

Singapore 038985

Singapore

 

F5 Networks, Inc.

Attention:  Legal Department

401 Elliot Avenue West

Seattle, WA 98119

USA

F5 Networks Ltd. F5 Networks Ltd.

Attn: Legal Department

Chertsey Gate West

43-47 London Street Chertsey

Surrey KT16 8AP

United Kingdom

 

F5 Networks, Inc.

Attention:  Legal Department

401 Elliot Avenue West

Seattle, WA 98119

USA

F5 Networks, Inc. F5 Networks, Inc.

Attn: Legal Department

401 Elliott Avenue West

Seattle, WA 98119

USA

 

11.6.  Severability. Any provisions found to be invalid or unenforceable will not affect the validity or enforceability of the other provisions contained herein, but will instead be replaced with a provision as similar to the original as possible and the remainder of this Agreement shall remain valid and enforceable according to its terms.

11.7.  No Waiver. Failure of either Party to insist upon strict performance of any of the terms and conditions of this Agreement will not preclude enforcement of such provisions or the exercise of any right. No waiver of a breach of this Agreement will be valid unless in writing. Waiver by either Party in the exercise of any of its remedies shall not constitute a subsequent waiver of such terms and conditions or a waiver of any default or remedy.

11.8.  Relationship of the Parties. F5 and Customer are independent contractors and this Agreement will not establish any relationship of partnership, joint venture, employment, franchise, or agency between F5 and Customer. Customer shall not, and will have no power to, bind F5 or incur obligations on F5’s behalf.

11.9.  Interpretation. This Agreement will not be construed in favor of or against any Party by reason of the extent to which any Party participated in the preparation of this Agreement.

Submit Your Resume

Upload your resume. (5 MB max - .pdf, .doc, or .docx)

March 23, 2018

Service Mesh Architectures

 

If you are building your software and teams around microservices, you’re looking for ways to iterate faster and scale flexibly. A service mesh can help you do that while maintaining (or enhancing) visibility and control. In this blog, I’ll talk about what’s actually in a Service Mesh and what considerations you might want to make when choosing and deploying one.

So, what is a service mesh? How is it different from what’s already in your stack? A service mesh is a communication layer that rides on top of request/response unlocking some patterns essential for healthy microservices. A few of my favorites:

  • Zero-trust security that doesn’t assume a trusted perimeter
  • Tracing that shows you how and why every microservice talked to another microservice
  • Fault injection and tolerance that lets you experimentally verify the resilience of your application
  • Advanced routing that lets you do things like A/B testing, rapid versioning and deployment and request shadowing

Why a new term?

Looking at that list, you may think “I can do all of that without a Service Mesh”, and you’re correct. The same logic applies to sliding window protocols or request framing. But once there’s an emerging standard that does what you want, it’s more efficient to rely on that layer instead of implementing it yourself. Service Mesh is that emerging layer for microservices patterns.

Service mesh is still nascent enough that codified standards have yet to emerge, but there is enough experience that some best practices are beginning to become clear. As the the bleeding-edge leaders develop their own approaches, it is often useful to compare notes and distill best practices. We’ve seen Kubernetes emerge as the standard way to run containers for production web applications. My favorite standards are emergent rather than forced: It’s definitely a fine art to be neither too early nor too late to agree on common APIs, protocols and concepts.

Think about the history of computer networking. After the innovation of best-effort packet-switched networks, we found out that many of us were creating virtual circuits over them – using handshaking, retransmission and internetworking to turn a pile of packets into an ordered stream of bytes. For the sake of interoperability and simplicity, a “best practice” stream-over-packets emerged: TCP (the Introduction of RFC675 does a good job of explaining what it layers on top of). There are alternatives – I’ve used the Licklider Transmission Protocol in space networks where distributed congestion control is neither necessary nor efficient. Your browser might already be using QUIC. Standardizing on TCP, however, freed a generation of programmers from fiddling with implementations of sliding windows, retries, and congestion collapse (well, except for those packetheads that implemented it).

Next, we found a lot of request/response protocols running on top of TCP. Many of these eventually migrated to HTTP (or sequels like HTTP/2 or gRPC). If you can factor your communication into “method, metadata, body”, you should be looking at an HTTP-like protocol to manage framing, separate metadata from body, and address head-of-line blocking. This extends beyond just browser apps – databases like Mongo provide HTTP interfaces because the ubiquity of HTTP unlocks a huge amount of tooling and developer knowledge.

You can think about service mesh as being the lexicon, API and implementation around the next tier of communication patterns for microservices.

OK, so where does that layer live? You have a couple of choices:

  • In a Library that your microservices applications import and use.
  • In a Node Agent or daemon that services all of the containers on a particular node/machine.
  • In a Sidecar container that runs alongside your application container.

Library

The library approach is the original. It is simple and straightforward. In this case, each microservice application includes library code that implements service mesh features. Libraries like Hystrix and Ribbon would be examples of this approach.

This works well for apps that are exclusively written in one language by the teams that run them (so that it’s easy to insert the libraries). The library approach also doesn’t require much cooperation from the underlying infrastructure – the container runner (like Kubernetes) doesn’t need to be aware that you’re running a Hystrix-enhanced app.

There is some work on multilanguage libraries (reimplementations of the same concepts). The challenge here is the complexity and effort involved in replicating the same behavior over and over again.

We see very limited adoption of the library model in our user base because most of our users are running applications written in many different languages (polyglot), and are also running at least a few applications that aren’t written by them so injecting libraries isn’t feasible.

This model has an advantage in work accounting: the code performing work on behalf of the microservice is actually running in that microservice. The trust boundary is also small – you only have to trust calling a library in your own process, not necessarily a remote service somewhere out over the network. That code only has as many privileges as the one microservice it is performing work on behalf of. That work is also performed in the context of the microservice, so it’s easy to fairly allocate resources like CPU time or memory for that work – the OS probably does it for you.

Node Agent

The node agent model is the next alternative. In this architecture, there’s a separate agent (often a userspace process) running on every node, servicing a heterogenous mix of workloads. For purposes of our comparison, it’s the opposite of the library model: it doesn’t care about the language of your application but it serves many different microservice tenants.

Linkerd’s recommended deployment in Kubernetes works like this. As do F5’s Application Service Proxy (ASP) and the Kubernetes default kube-proxy.

Since you need one node agent on every node, this deployment requires some cooperation from the infrastructure – this model doesn’t work without a bit of coordination. By analogy, most applications can’t just choose their own TCP stack, guess an ephemeral port number, and send or receive TCP packets directly – they delegate that to the infrastructure (operating system).

Instead of good work accounting, this model emphasizes work resource sharing – if a node agent allocates some memory to buffer data for my microservice, it might turn around and use that buffer for data for your service in a few seconds. This can be very efficient, but there’s an avenue for abuse. If my microservice asks for all the buffer space, the node agent needs to make sure it gives your microservice a shot at buffer space first. You need a bit more code to manage this for each shared resource.

Another work resource that benefits from sharing is configuration information. It’s cheaper to distribute one copy of the configuration to each node, than to distribute one copy of the configuration to each pod on each node.

A lot of functionality that containerized microservices rely on are provided by a Node Agent or something topologically equivalent. Think about kubelet initializing your pod, your favorite CNI daemon like flanneld, or stretching your brain a bit, even the operating system kernel itself as following this node agent model.

Sidecar

Sidecar is the new kid on the block. This is the model used by Istio with Envoy. Conduit also uses a sidecar approach. In Sidecar deployments, you have one adjacent container deployed for every application container. For a service mesh, the sidecar handles all the network traffic in and out of the application container.

This approach is in between the library and node agent approaches for many of the tradeoffs I discussed so far. For instance, you can deploy a sidecar service mesh without having to run a new agent on every node (so you don’t need infrastructure-wide cooperation to deploy that shared agent), but you’ll be running multiple copies of an identical sidecar. Another take on this: I can install one service mesh for a group of microservices, and you could install a different one, and (with some implementation-specific caveats) we don’t have to coordinate. This is powerful in the early days of service mesh, where you and I might share the same Kubernetes cluster but have different goals, require different feature sets, or have different tolerances for bleeding-edge vs. tried-and-true.

Sidecar is advantageous for work accounting, especially in some security-related aspects. Here’s an example: suppose I’m using a service mesh to provide zero-trust style security. I want the service mesh to verify both ends (client and server) of a connection cryptographically. Let’s first consider using a node agent: When my pod wants to be the client of another server pod, the node agent is going to authenticate on behalf of my pod. The node agent is also serving other pods, so it must be careful that another pod cannot trick it into authenticating on my pod’s behalf. If we think about the sidecar case, my pod’s sidecar does not serve other pods. We can follow the principle of least privilege and give it the bare minimum it needs for the one pod it is serving in terms of authentication keys, memory and network capabilities.

So, from the outside the sidecar has the same privileges as the app it is attached to. On the other hand, the sidecar needs to intervene between the app and the outside. This creates some security tension: you want the sidecar to have as little privilege as possible, but you need to give it enough privilege to control traffic to/from the app. For example, in Istio, the init container responsible for setting up the sidecar has the NET_ADMIN permission currently (to set up the iptables rules necessary). That initialization uses good security practices – it does the minimum amount necessary and then goes away, but everything with NET_ADMIN represents attack surface. (Good news – smart people are working on enhancing thisfurther).

Once the sidecar is attached to the app, it’s very proximate from a security perspective. Not as close as a function call in your process (like library) but usually closer than calling out to a multi-tenant node agent. When using Istio in Kubernetes your app container talks to the sidecar over a loopback interface inside of the network namespace shared with your pod – so other pods and node agents generally can’t see that communication.

Most Kubernetes clusters have more than one pod per node (and therefore more than one sidecar per node). If each sidecar needs to know “the entire config” (whatever that means for your context), then you’ll need more bandwidth to distribute that config (and more memory to store copies of it). So it can be powerful to limit the scope of configuration that you have to give to each sidecar – but again there’s an opposing tension: something (in Istio’s case, Pilot) has to spend more effort computing that reduced configuration for each sidecar.

Other things that happen to be replicated across sidecars accrue a similar bill. Good news – the container runtimes will reuse things like container disk images when they’re identical and you’re using the right drivers, so the disk penalty is not especially significant in many cases, and memory like code pages can also often be shared. But each sidecar’s process-specific memory will be unique to that sidecar so it’s important to keep this under control and avoid making your sidecar “heavy weight” by doing a bunch of replicated work in each sidecar.

Service Meshes relying on sidecar provide a good balance between a full set of features, and a lightweight footprint.

Will the node agent or sidecar model prevail?

I think you’re likely to see some of both. Now seems like a perfect time for sidecar service mesh: nascent technology, fast iteration and gradual adoption. As service mesh matures and the rate-of-change decreases, we’ll see more applications of the node agent model.

Advantages of the node agent model are particularly important as service mesh implementations mature and clusters get big:

  • Less overhead (especially memory) for things that could be shared across a node
  • Easier to scale distribution of configuration information
  • A well-built node agent can efficiently shift resources from serving one application to another

Sidecar is a novel way of providing services (like a high-level communication proxy a la Service Mesh) to applications. It is especially well-adapted for containers and Kubernetes. Some of its greatest advantages include:

  • Can be gradually added to an existing cluster without central coordination
  • Work performed for an app is accounted to that app
  • App-to-sidecar communication is easier to secure than app-to-agent

What’s next?

As Shawn talked about in his post, we’ve been thinking about how microservices change the requirements from network infrastructure for a few years now. The swell of support and uptake for Istio demonstrated to us that there’s a community ready to develop and coalesce on policy specs, with a well-architected implementation to go along with it.

Istio is advancing state-of-the-art microservices communication, and we’re excited to help make that technology easy to operate, reliable, and well-suited for your team’s workflow in private cloud, public cloud or hybrid.

4 thoughts on “Service Mesh Architectures

  1. Great introduction to service mesh approaches / patterns. One thing though, you discuss both pods and applications in the text, but only use applications in the diagrams. 🙂

    So just to clarify: in the sidecar approach you’d usually (always?) implement the sidecar in it’s own container, where that container is “paired” with a given application’s container. But how does that relate to pods? I.e. to what extent are applications typically arranged into a single container vs two or more? If I have an application that is arranged across two or more containers (in the same pod) how many sidecars would you have?

    Therefore, is the notion of a sidecar specifically one that is at the application specific, container specific, or a pod specific?

    1. Hey Adrian,
      Great question and one that we could have done a better job of being clear on in the post. It is a sidecar for every pod.

  2. You can run the sidecar inside the same container as the service itself.

    It’s docker religion that you should only run one user process in a container, but there’s no practical justification for it in the context of a service and its sidecar. The recommendation refers to separate, independent processes that provide different services, and need to be allowed to fail and evolve separately. You don’t want this with a service and its sidecar. Between those two you want the closest runtime coupling that can be – they should always live and die together. Which is what putting them in the same container helps achieving for cheap. When deployed into separate containers, you need to rely on the orchestration tool to ensure this.

    Running the sidecar and the service inside the same container also reduces runtime overhead in terms of resources and latency (inter-container communication is cheap, when the containers run on the same host, but communication inside the container is even cheaper, and deploying half the number of containers, even with higher memory allocation, significantly increases deployment density).

    1. Running the sidecar in the same container as the service is an even closer coupling than as a second container in the same kubernetes pod.

      When the sidecar is a separate container in the same pod, it has at least a few defenses against bad behavior from the service. The sidecar can bring along its own filesystem, and gets its own process namespace. This allows for instance the sidecar to have certs & keys that are not available to the service. This is helpful if you want to rely on the sidecar; for example, you might trust the sidecar to apply a policy. Other services can trust that requests signed by the sidecar did have the policy enforced.

      On the other hand, if you view the sidecar as really just a friendly application enhancer and not a strong policy enforcer, then it’s convenient to run the sidecar in the same container.

      My experience with Kubernetes has been that it’s good at killing pods even if only one of the containers dies. It’s definitely possible to make or run your own container init system so you can run multiple processes and die if any die, but so far I haven’t found the need.

      I’m not sure what you mean by “communication inside the container is even cheaper.” In Kubernetes, two containers in a pod share a network namespace, so communicating over localhost is the same whether two containers in a pod or two processes in a container. Are you thinking about using shared memory or shared filesystems?

      Does deploying half the number of containers (but with each container being “twice” as big) actually increase deployment density significantly? In that case, it’s still the same amount of filesystem disk bytes, running the same processes, just with some extra namespace boundaries between them. I’d love to know more about this.

Leave a Reply

Your email address will not be published. Required fields are marked *