Roadmap: 1.3, 1.4, and Beyond

[austinlparker]

Heya gang -- this thread is intended to summarize a discussion from today's SIG call, discuss what's coming in 1.3 (this week), and the big rocks that we'd like to tackle for 1.4.

v1.3

1.3 will contain currently open PRs (as of today, 1/23) and will include several new additions, bug fixes, etc.

• Resource detection in more services
• Improved metrics coverage
• Improvements to build time and other optimizations
• Metric exemplars support
• New failure scenarios for Ad Service

v1.4

While overall the demo has been performing well, there are many rough edges that we've seen and heard about from our end users. The overall maintainability, architecture, and performance of the application is suffering. In order to support future development, 1.4 will be dedicated solely to application improvements in two areas:

Code Quality
In this area, we'll be focusing on ensuring that each application's code and logic is of uniformly high quality, and that applications properly and gracefully handle failure. Objectives include:

• Ensure that no inadvertent OpenTelemetry SDK dependencies exist (applications should only rely on the API, the SDK should be able to be enabled/disabled without breaking the app)
• Ensure that services are resilient to dependency failure (if a dependent service is down or slow, the app should not enter an unrecoverable state)
• Ensure that OpenTelemetry API calls follow recommendations (for example, pre-allocation of metric attributes, etc.)
• Consistent naming, linting, etc. across code base.

Architecture Quality
In this area, we'll focus on the deployability of the application itself and its operation. Objectives include:

• Separation of concerns between instrumentation and observability components.
• Reduction in complexity of environment variables required for deployment.
• Reduction in complexity of deployment artifacts, improve severability of observability components from deployment manifests
• Standardize on k8s for "production" deployment
• Right-size and validate memory and CPU limits across multiple deployment targets (single-node, 3-node, n-node)
• Distribute arm64 native container images

Overall, the goal at the end of the 1.4 release cycle is to have a demo that builds faster, runs better, and is easier to maintain going forward.

vFuture

Per our earlier discussions on what features we'd like to see moving forward, we'll start a new process to more clearly define focus areas for subsequent releases.

If you've got any questions or comments, or discussion points, feel free to raise them here. Thanks!

[TylerHelmuth]

@austinlparker do the architecture goals in 1.4 encompass official arm64 images?

[austinlparker]

Yeah, I forgot to call that out explicitly but I'll add it.

[svrnm]

Ensure that services are resilient to dependency failure (if a dependent service is down or slow, the app should not enter an unrecoverable state)

A thing related to that: It would be great if it would be possible to only run a subset of the demo so having them work even without dependencies would be great and enable that as well!

[cartersocha]

I’d definitely like the focus of the releases through 2.0 being quality focused along with minor feature additions like metrics or resource detectors. We’ve built so much over the last year there’s a lot of fat to trim and bugs to clean up

Im nervous about adding logging too soon. I think we need to spend more time planning our approach there. We’ve mostly hand waved it away today

[mviitane]

• Deprecate docker desktop deployment in favor of local k8s/k3s

I wouldn't include this one, at least before we have a well working local Kubernetes solution. #635

[cartersocha]

Big +1. I missed that point.

The GitHub discussion consensus was to keep docker.

If there is a desire to re-open the conversation, the k8s folks should make a POC and provide customer data showing it’s not disruptive / is an equivalent experience

[cartersocha]

2.0 + maybe but 1.4 seems premature

[austinlparker]

I see this more as standardizing on k8s as the deployment target, not removing docker as a development option. By ensuring that services can be run independently of each other, and separating out the observability infrastructure, we should still be able to have a compose file option to run the demo locally for debugging or development while ensuring that the "full" deployment targets k8s

[austinlparker]

I updated the OP to reflect this