The developers have instrumented the applications with OpenTelemetry — great! But that doesn't mean you're ready to roll it out in production yet. What do you need to keep in mind for your instrumentation infrastructure?

* Quick OpenTelemetry overview.
* Tradeoffs between the three architectures you use with OTel (depending on your vendor): vendor exporter vs OTel Collector vs OTel protocol support
* Sampling, including head vs tail based, and how to keep it representative and / or useful.

Target Audience: Architects, Developers
Prerequisites: Software development knowledge and some monitoring experience is also helpful
Level: Advanced

Extended Abstract:
The developers have instrumented the applications with OpenTelemetry — great! But that doesn't mean you're ready to roll it out in production. What do you need to keep in mind for your instrumentation infrastructure? OpenTelemetry is THE emerging standard for monitoring and creating more observable systems. Starting with an overview, this talk then dives into two areas that make a big difference in cost, flexibility, and insights:

Firstly, the three possible integration architectures with vendor exporter, OpenTelemetry Collector, and native protocol support; and why a combination of Collector and native protocol are the most common choice today.
Secondly, sampling or how to get the big picture from a subset of the data (and cost). Here the tradeoffs evolve around head- vs tail-based sampling and how to keep the collected data representative and / or useful. It generally comes down to simpler and cheaper with the head-based approach, while the tail-based one is potentially more useful with higher overhead. And now it's time to roll it out in production!

I will share our hands-on experience with a cloud native (container) transformation that is currently unfolding. Technically, implementing an Open Shift Container Platform (bare metal) is pretty challenging. Doing this in a way that we will have pretty stuff in our data centers and at the same time making sure that our technical possibilities are actually being used effectively by product developers ... is a different challenge all together.

Join this session if you'd like to hear what we figured out about the people side of this kind of change!

Target Audience: Architects, Management, Developers, Operational Heroes, Product Owners, Agile Coaches, Scrum Masters
Prerequisites: Basic knowledge of DevOps concepts
Level: Advanced

Extended Abstract:
In this session I will share our hands-on experiences implementing a container-based architecture in our organisation. Choosing to implement Open Shift (bare metal) as your container platform is pretty difficult and challenging technically. It is also rather exciting and not too difficult to find smart people willing to help you build and run this new platform. However, it turns out that there is far more to this challenge than just the technology. Therefore, we are adopting an evolutionary implementation approach - stringing together small experiments - towards a flexible, more experimental and proactive culture that will allow us to actually benefit from the technical possibilities our new platform offers. This session is our story of our evolutionary and experimental approach and what we discovered along the way that works in this kind of transformation. Our main "discovery" is that even though at first it seemed mostly a technical transformation, it actually is far more of a human challenge.

We are right in the middle of this transformation so in this talk, I will bring you the latest and most valuable insights and experiences regarding this organisational and cultural transformation that is needed to turn the potential of our container platform into actual value for our organisation. We will summarise our ideas in a practical "this might work" list (bear in mind however there are no best practices, just patterns that might work in your specific situation).

An example of an experiment that turned out useful in our situation is: "create a small separate team that will drive this change". In our organisation we strive to build end-to-end teams, so at first we tried to get this new platform started from within the regular Infra DevOps team (as a huge Epic on the backlog). But people however got swamped in work and annoyed by all the context switching this required. Team members got tired and frustrated with the huge amounts of work, sky high ambitions and lack of progress. So, in the end we did a small experiment by creating a separate, dedicated, core team to get things going. This experiment turned out to be successful (and was thus extended) because it allowed team members to focus on the development of the platform and to build, document and share their experiences along the way, so that this team is also able to incrementally onboard the other teams along the way. Busy OPS-teams and product teams can't just develop the new platform on the side, next to all their other ongoing work. Building a container platform is epic and needs dedicated time and focus, also to keep people in their best energy.

I will share some of our most useful experiments and experiences, all having to do with the human side of this container transformation.

This session is not meant for decision making on going cloud native or not. If you do go cloud native, please bear in mind it is still about people, most of all!