Google Summer of Code 2020 and Layer5

      What is Layer5?
      While small, the Layer5 community represents the largest collection of service mesh projects and their maintainers in the world. We build projects to provide learning environments, deployment and operational best practices, performance benchmarks, create documentation, share networking opportunities, and more. Our shared commitment to the open source spirit pushes Layer5 projects forward. New members are always welcome.
      Is it Open Source?
      Layer5 projects are open source software. Anyone can download, use, work on, and share it with others. It's built on principles like collaboration, globalism, and innovation. Layer5 projects are distributed under the terms of Apache v2.
      Google Summer of Code Participation?
      The key component of these projects is our Community. This community, which you will join as an participant in Google Summer of Code, is improving the world of diverse cloud native systems. Your contributions will affect people you've never met. The Layer5 community includes software engineers, researchers, students, artists, system administrators, operators and web designers -- all of whom will be happy to help you get started.
      We believe that all contributors should expect and be part of a safe and friendly environment for constructive contribution. We can more effectively and successfully compare and challenge different ideas to find the best solutions for advancement, while building the size, diversity, and strength of our community.
2020 Program Timeline
  • January 14 - Organization applications open
  • February 20 - Accepted GSoC Organizations announced
  • March 16-March 31 - Students submit their proposals
  • April 27 - Accepted students are announced
  • April 27-May 18 - Community bonding period with orgs
  • May 18-Aug 17 - Students code the summer away
  • August 25 - Successful student projects are announced
Statistics
  • In 15 years 15,926 students from 109 countries have been accepted into GSoC
  • Countries with the most students: India (4,065), United States (2,552), and Germany (870 )
  • Approximately 36+ million lines of code have been produced
Project Ideas
Benchmarks for Network Service Mesh, Istio, Citrix
  • Description: Network Service Mesh, like other service meshes are plagued by the question of adopters asking the question: "what's the performance overhead of the service mesh?". Network Service Mesh, Linkerd, Istio, Envoy and the list of other service meshes don't have a consistent set of performance benchmarks between them. So, even if Envoy were to publish performance results, users still wouldn't be able to compare overhead between Linkerd and Envoy. The project idea here is to build a multi-mesh performance benchmark tool.
  • Recommended Skills: Golang, React, Kubernetes
  • Mentor(s): Lee Calcote (@lcalcote), Sagar Utekar (@hnamed_uttu)
SMI Conformance Testing
Distributed Load Testing of Service Meshes
  • Description: Many performance benchmarks are limited to single instance load generation (single pod load generator). This limits the amount of traffic that can be generated to output of the single machine that the benchmark tool runs on in or out of a cluster. Overcoming this limitation would allow for more flexible and robust testing. Distributed load testing in parallel poses a challenge when merging results without losing the precision we need to gain insight into the high tail percentiles. Use Meshery’s interface for supporting different load generators (a point of extensibility) to place support for Vegeta. Workloads running on service meshes are hit in various ways and generally not from the same source. Use of a distributed load generator will aid in the testing of service mesh behavior.
  • Recommended Skills: Golang, Kubernetes
  • Mentor(s): Prateek Sahu (@PrateekSahu22), Kanishkar J (@_kanishkarj_)
  • Issue(s): https://github.com/envoyproxy/envoy-perf/issues/72
Service Mesh Performance Specification and Index
  • Description: A formal specification for capturing the details of a performance test, it’s results, environment and workload details. Design an algorithm for calculating a MeshDex value - an easy-to-comprehend number identifying the overhead to value ratio a given service mesh deployment is operating at.
  • Recommended Skills: Golang, Kubernetes
  • Mentor(s): Prateek Sahu (@PrateekSahu22), , Shivay Lamba, Lee Calcote (@lcalcote)
Kubernetes controller for Meshery
  • Description: A Kubernetes controller that provides Meshery Custom Resource Definitions like perf wherein a user could manage scheduled performance jobs like this: kubectl get meshperfand see a list of scheduled performance tests. In this, they would have a Kubernetes-native experience for leveraging Meshery’s functionality. Other functionality like kubectl get meshevents, which should give them a list of outstanding recommendations on best practice violations in a format similar to kubectl get events. Example
  • Recommended Skills:
  • Mentor(s): Vinayak Shinde, Lee Calcote (@lcalcote)
A Kubernetes Operator for Meshery
  • Description: Lifecycle management of Meshery as an application. Operators are often written for this purpose - to care and feed for the application under management. This could be activities that mesheryctl does today about start/status/stop/update/logs/cleanup.
  • Recommended Skills:
  • Mentor(s): Vinayak Shinde, Lee Calcote (@lcalcote)
Meshery Monkey
  • Description: Bring chaos engineering to the service mesh. Service meshes are quite capable of facilitating fine-grained network chaos in the form of latency, jitter, packet loss, mangled packets, and so on. Provide a tool for defining, executing, scheduling service mesh experiments. Leverage and incorporate Chaos Mesh.
  • Recommended Skills: Golang
  • Mentor(s): Sagar Utekar (@named_uttu), Lee Calcote (@lcalcote)