[discussion] Roadmap for the second half of 2022

[seeflood]

Recently we've been talking with different potential users. During the communication, I often found that we do not have features (or demos) they want to use, and they don't want to use the features we set as goals for the year.

I believe that a good roadmap should be based on users' voice instead of just YY by maintainers :)

So I put the information and problems to solve here for discussion. Hope these problems can help us decide a good roadmap.

Collection of user requirements

I highlight the "unsupported features or demos"

User	How do you deploy apps	Existing Service Mesh data plane	Existing Control plane	How do you want to deploy layotto	How do you want to "control" layotto	Do you want to use Istio	Do you want to use Layotto-on-envoy	Which Layotto API you might use	More details
@kevinten10	Kubernetes, e.g. ACK on alibaba cloud	Service Mesh hosted by cloud providers, e.g. ASM	Service Mesh control plane hosted by cloud providers	as a sidecar container,using K8s yaml or helm chart (no demos yet)	configuration centers such as AWS Appconfig (not supported yet)	NO	NO	configuration,pubsub,lock,oss,secret	https://github.com/mosn/layotto/issues/713#issuecomment-1189931691
@unionhu	Kubernetes	Introducing MOSN	PolarisMesh	replace the existing MOSN image with layotto	Prefer XDS, so that they can deliver configuration from polaris dynamically (not supported yet)	NO	Depends on the performance	Not quite sure. Maybe SMS API and pubsub	https://github.com/mosn/layotto/issues/500#issuecomment-1190379194
X	Kubernetes	NO	Use K8s service to do service discovery	a sidecar container in the pod (no demos yet)	?	NO	NO	oss,secret,elastic search	They want to deploy their apps on multiple clouds while keeping things simple. Simplicity is really important and I believe they won't like service mesh
Y	VM, and their own docker scheduler	NO	Service registry	?	?	NO	NO	?	They are doing research on sidecar because they have the pain of pushing the business side to upgrade their sdk. They use dubbo techstack for RPC. Introducing Service mesh is almost impossible for them because it's hard to persuade all the business department

Bottlenecks

Based on info above, I suppose that the current bottlenecks are not data plane, but:

• Deployment and operation
• Integration with different Control planes (I didn't see anyone using Istio)
• Coexist with the existing service registry& discovery system and be lightweight. Asking users to "replace your K8s service or dubbo with my Service mesh" is not practical.

Roadmap?

I propose that the P1 features are:

• Contol plane

  • 500

  • integrate with different control planes including XDS servers and traditional configuration centers.
• Deployment and operation
  • a demo to inject as sidecar container
  • an admission controller to do sidecar injection
  • helm chart? I'm not sure if users want it
• OSS API
• Coexist with existing micro-service RPC systems

[kevinten10]

wonderful!

[seeflood]

Layotto-on-Envoy advantages:

• high performance
• reuse c++ network filter

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity in the last 30 days. It will be closed in the next 7 days unless it is tagged (pinned, good first issue or help wanted) or other activity occurs. Thank you for your contributions.

[github-actions[bot]]

This issue has been automatically closed because it has not had activity in the last 37 days. If this issue is still valid, please ping a maintainer and ask them to label it as pinned, good first issue or help wanted. Thank you for your contributions.