Ya!vaConf
Poland Warsaw

Practical introduction to OpenTelemetry tracing

Tracking a request’s flow across different components in distributed systems is essential. With the rise of microservices, their importance has risen to critical levels. Some proprietary tools for tracking have been used already: Jaeger and Zipkin naturally come to mind. Observability is built on three pillars: logging, metrics, and tracing. OpenTelemetry is a joint effort to bring an open standard to them. Jaeger and Zipkin joined the effort so that they are now OpenTelemetry compatible. In this talk, I’ll describe the above in more detail and showcase a (simple) use case to demo how you could benefit from OpenTelemetry in your distributed architecture.

Dutch Cloud-Native Day
The Netherlands Amsterdam

Practical introduction to OpenTelemetry tracing

Tracking a request’s flow across different components in distributed systems is essential. With the rise of microservices, their importance has risen to critical levels. Some proprietary tools for tracking have been used already: Jaeger and Zipkin naturally come to mind. Observability is built on three pillars: logging, metrics, and tracing. OpenTelemetry is a joint effort to bring an open standard to them. Jaeger and Zipkin joined the effort so that they are now OpenTelemetry compatible. In this talk, I’ll describe the above in more detail and showcase a (simple) use case to demo how you could benefit from OpenTelemetry in your distributed architecture.

Amsterdam JUG
The Netherlands Amsterdam

Make Your Security Policy Auditable

All mature tech stacks nowadays offer infrastructure-related capabilities, either a standard lib or in 3rd-party libraries, e.g., rate-limiting and authorization. While it’s great to have such features, it’s impossible to audit them easily. You’d need to be familiar with the stack and dive deep into the code. This approach just doesn’t scale, A well-designed system keeps the right feature at the right place. In this talk, I’ll go through all steps toward making your system more easily auditable. I’ll use the authorization of a security policy as an example and start from a regular Spring Boot project with Spring Security. I’ll then move step-by-step, introducing the Open Policy Agent (OPA) and the Apache APISIX API Gateway. The end result will have moved all authorization details buried in the code in a readable accessible place.

DevFest Dijon
Online

Introduction pratique à OpenTelemetry pour les développeurs

Il est essentiel de suivre le parcours d’une requête à travers les différents composants d’un système distribué. Avec l’essor des microservices, cette fonctionnalité a atteint un niveau de criticité comme jamais auparant. Certains outils propriétaires de suivi vous sont peut-être connus : Jaeger et Zipkin viennent naturellement à l’esprit. L’observabilité repose sur trois piliers : la journalisation, les métriques et le traçage. OpenTelemetry est un effort conjoint visant à mettre en place un standard ouvert pour ces trois piliers. Jaeger et Zipkin se sont joints à cet effort et sont maintenant compatibles avec OpenTelemetry. Dans cet exposé, je décrirai plus en détail ce qui précède et je présenterai un cas d’utilisation (simple) pour démontrer comment vous pourriez bénéficier des traces OpenTelemetry dans votre architecture distribuée.

Porto Tech Hub
Portugal Porto

Make Your Security Policy Auditable

All mature tech stacks nowadays offer infrastructure-related capabilities, either a standard lib or in 3rd-party libraries, e.g., rate-limiting and authorization. While it’s great to have such features, it’s impossible to audit them easily. You’d need to be familiar with the stack and dive deep into the code. This approach just doesn’t scale, A well-designed system keeps the right feature at the right place. In this talk, I’ll go through all steps toward making your system more easily auditable. I’ll use the authorization of a security policy as an example and start from a regular Spring Boot project with Spring Security. I’ll then move step-by-step, introducing the Open Policy Agent (OPA) and the Apache APISIX API Gateway. The end result will have moved all authorization details buried in the code in a readable accessible place.

DevOps Stage
Online

Practical introduction to OpenTelemetry tracing

Tracking a request’s flow across different components in distributed systems is essential. With the rise of microservices, their importance has risen to critical levels. Some proprietary tools for tracking have been used already: Jaeger and Zipkin naturally come to mind. Observability is built on three pillars: logging, metrics, and tracing. OpenTelemetry is a joint effort to bring an open standard to them. Jaeger and Zipkin joined the effort so that they are now OpenTelemetry compatible. In this talk, I’ll describe the above in more detail and showcase a (simple) use case to demo how you could benefit from OpenTelemetry in your distributed architecture.

Software Architecture Gathering
Germany Berlin

Make Your Security Policy Auditable

All mature tech stacks nowadays offer infrastructure-related capabilities, either a standard lib or in 3rd-party libraries, e.g., rate-limiting and authorization. While it’s great to have such features, it’s impossible to audit them easily. You’d need to be familiar with the stack and dive deep into the code. This approach just doesn’t scale, A well-designed system keeps the right feature at the right place. In this talk, I’ll go through all steps toward making your system more easily auditable. I’ll use the authorization of a security policy as an example and start from a regular Spring Boot project with Spring Security. I’ll then move step-by-step, introducing the Open Policy Agent (OPA) and the Apache APISIX API Gateway. The end result will have moved all authorization details buried in the code in a readable accessible place.

Heapcon
Serbia Belgrade

Practical introduction to OpenTelemetry tracing

Tracking a request’s flow across different components in distributed systems is essential. With the rise of microservices, their importance has risen to critical levels. Some proprietary tools for tracking have been used already: Jaeger and Zipkin naturally come to mind. Observability is built on three pillars: logging, metrics, and tracing. OpenTelemetry is a joint effort to bring an open standard to them. Jaeger and Zipkin joined the effort so that they are now OpenTelemetry compatible. In this talk, I’ll describe the above in more detail and showcase a (simple) use case to demo how you could benefit from OpenTelemetry in your distributed architecture.

Heapspace
Serbia Belgrade

Make your security policy auditable

All mature tech stacks nowadays offer infrastructure-related capabilities, either a standard lib or in 3rd-party libraries, e.g., rate-limiting and authorization. While it’s great to have such features, it’s impossible to audit them easily. You’d need to be familiar with the stack and dive deep into the code. This approach just doesn’t scale, A well-designed system keeps the right feature at the right place. In this talk, I’ll go through all steps toward making your system more easily auditable. I’ll use the authorization of a security policy as an example and start from a regular Spring Boot project with Spring Security. I’ll then move step-by-step, introducing the Open Policy Agent (OPA) and the Apache APISIX API Gateway. The end result will have moved all authorization details buried in the code in a readable accessible place.

Talk4Devs
Online

A walk-through of ways to Dockerize your JVM application

As 'the Cloud' becomes more and more widespread, now is a good time to assess how you can containerize your Java application. I assume you’re able to write a a Dockerfile around the generated JAR. However, each time the application’s code will change, the whole image will need to be rebuilt. If you’re deploying to a local Kubernetes cluster environment, this increases that much the length of the feedback loop. In this demo-based talk, I’ll present different ways to get your Java app in a container: Dockerfile, Jib, and Cloud Native Buildpacks. We will also have a look at what kind of Docker image they generate, how they layer the images, whether those images are compatible with skaffold, etc.

Testflix
Online

An always up-to-date developer's CV

It’s been said that GitHub is a developer’s CV. Just a quick look at your commit history and recruiters know all about you. There are a couple of issues with this approach. Most companies don’t even publish their source code under an Open Source license. If you work for one of them, and if you’re not a rabid Open Source developer, then it’s obviously not helpful. Recently, GitHub allowed some degree of customization of one’s profile. So, even if your commit history has more white than green, you can provide a good entry-point for potential employers. But it’s only as good as the effort you put in it, and it might decay fast. Yet, with a bit of work, and the help of automation tools (such as GitHub Actions), you can provide an always up-to-date profile. In this talk, I’ll present you how to do it, using my own setup as an example.

Voxxed Days Thessaloniki
Greece Thessaloniki

Practical introduction to OpenTelemetry tracing

Tracking a request’s flow across different components in distributed systems is essential. With the rise of microservices, their importance has risen to critical levels. Some proprietary tools for tracking have been used already: Jaeger and Zipkin naturally come to mind. Observability is built on three pillars: logging, metrics, and tracing. OpenTelemetry is a joint effort to bring an open standard to them. Jaeger and Zipkin joined the effort so that they are now OpenTelemetry compatible. In this talk, I’ll describe the above in more detail and showcase a (simple) use case to demo how you could benefit from OpenTelemetry in your distributed architecture.

DevFest Nantes
France Nantes

Introduction pratique à OpenTelemetry pour les développeurs

Il est essentiel de suivre le parcours d'une requête à travers les différents composants d'un système distribué. Avec l'essor des microservices, cette fonctionnalité a atteint un niveau de criticité comme jamais auparant. Certains outils propriétaires de suivi vous sont peut-être connus : Jaeger et Zipkin viennent naturellement à l'esprit. L'observabilité repose sur trois piliers : la journalisation, les métriques et le traçage. OpenTelemetry est un effort conjoint visant à mettre en place un standard ouvert pour ces trois piliers. Jaeger et Zipkin se sont joints à cet effort et sont maintenant compatibles avec OpenTelemetry. Dans cet exposé, je décrirai plus en détail ce qui précède et je présenterai un cas d'utilisation (simple) pour démontrer comment vous pourriez bénéficier des traces OpenTelemetry dans votre architecture distribuée.

JavaCro
Croatia Rovinj

Make Your Security Policy Auditable

All mature tech stacks nowadays offer infrastructure-related capabilities, either a standard lib or in 3rd-party libraries, e.g., rate-limiting and authorization. While it’s great to have such features, it’s impossible to audit them easily. You’d need to be familiar with the stack and dive deep into the code. This approach just doesn’t scale, A well-designed system keeps the right feature at the right place. In this talk, I’ll go through all steps toward making your system more easily auditable. I’ll use the authorization of a security policy as an example and start from a regular Spring Boot project with Spring Security. I’ll then move step-by-step, introducing the Open Policy Agent (OPA) and the Apache APISIX API Gateway. The end result will have moved all authorization details buried in the code in a readable accessible place.

JavaCro
Croatia Rovinj

Practical introduction to OpenTelemetry tracing

Tracking a request’s flow across different components in distributed systems is essential. With the rise of microservices, their importance has risen to critical levels. Some proprietary tools for tracking have been used already: Jaeger and Zipkin naturally come to mind. Observability is built on three pillars: logging, metrics, and tracing. OpenTelemetry is a joint effort to bring an open standard to them. Jaeger and Zipkin joined the effort so that they are now OpenTelemetry compatible. In this talk, I’ll describe the above in more detail and showcase a (simple) use case to demo how you could benefit from OpenTelemetry in your distributed architecture.

Dev Talks
Romania Cluj Napoca

Practical introduction to OpenTelemetry tracing

Tracking a request’s flow across different components in distributed systems is essential. With the rise of microservices, their importance has risen to critical levels. Some proprietary tools for tracking have been used already: Jaeger and Zipkin naturally come to mind. Observability is built on three pillars: logging, metrics, and tracing. OpenTelemetry is a joint effort to bring an open standard to them. Jaeger and Zipkin joined the effort so that they are now OpenTelemetry compatible. In this talk, I’ll describe the above in more detail and showcase a (simple) use case to demo how you could benefit from OpenTelemetry in your distributed architecture.

Berlin Expert Days
Germany Berlin

Evolving Your APIs, a Step-By-Step Approach

When you publish your first HTTP API, you’re more focused on short-term issues than planning for the future. However, chances are you’ll be successful, and you’ll hit the wall. How do you evolve your API without breaking the contract with your existing users? In this talk, I’ll first show you some tips and tricks to achieve that: moving your endpoints, deprecating them, monitoring who’s using them, and letting users know about the new endpoints. The talk is demo-based, and I’ll use the Apache APISIX project for it.

Softcon
Philippines Manilla

Chopping the monolith

Micro services are ubiquitous. However, most companies that implement micro services do not reap their full benefits - at best. At worst, it’s an epic failure. There are reasons for micro services: independent deployment of business capabilities. However, the unspoken assumption is that you need to deploy all capabilities all the time. My experience has shown me that it’s plain wrong. Some capabilities need frequent deployment, while some are much more stable. In "the past", we used Rule Engines to allow updating business rules without deployment. While it solved the problem, this approach had issues. Between introducing a Rule Engine and migrating your complete system to micro services, I believe that there’s a middle path, and that this path is Function-as-a-Service. In this talk, I’ll detail every point I’ve made above, and show how one can use Serverless to pragmatically design a system that allows deploying as often as you need.

DevOps Days Vilnius
Lithuania Vilnius

Practical introduction to OpenTelemetry tracing

Tracking a request’s flow across different components in distributed systems is essential. With the rise of microservices, their importance has risen to critical levels. Some proprietary tools for tracking have been used already: Jaeger and Zipkin naturally come to mind. Observability is built on three pillars: logging, metrics, and tracing. OpenTelemetry is a joint effort to bring an open standard to them. Jaeger and Zipkin joined the effort so that they are now OpenTelemetry compatible. In this talk, I’ll describe the above in more detail and showcase a (simple) use case to demo how you could benefit from OpenTelemetry in your distributed architecture.

Java Forum Nord
Germany Hannover

Evolving Your APIs, a Step-By-Step Approach

When you publish your first HTTP API, you’re more focused on short-term issues than planning for the future. However, chances are you’ll be successful, and you’ll hit the wall. How do you evolve your API without breaking the contract with your existing users? In this talk, I’ll first show you some tips and tricks to achieve that: moving your endpoints, deprecating them, monitoring who’s using them, and letting users know about the new endpoints. The talk is demo-based, and I’ll use the Apache APISIX project for it.

Berlin Spring User Group
Germany Berlin

Practical introduction to OpenTelemetry tracing

Tracking a request’s flow across different components in distributed systems is essential. With the rise of microservices, their importance has risen to critical levels. Some proprietary tools for tracking have been used already: Jaeger and Zipkin naturally come to mind. Observability is built on three pillars: logging, metrics, and tracing. OpenTelemetry is a joint effort to bring an open standard to them. Jaeger and Zipkin joined the effort so that they are now OpenTelemetry compatible. In this talk, I’ll describe the above in more detail and showcase a (simple) use case to demo how you could benefit from OpenTelemetry in your distributed architecture.

Berlin Spring User Group
Germany Berlin

Evolving Your APIs, a Step-By-Step Approach

When you publish your first HTTP API, you’re more focused on short-term issues than planning for the future. However, chances are you’ll be successful, and you’ll hit the wall. How do you evolve your API without breaking the contract with your existing users? In this talk, I’ll first show you some tips and tricks to achieve that: moving your endpoints, deprecating them, monitoring who’s using them, and letting users know about the new endpoints. The talk is demo-based, and I’ll use the Apache APISIX project for it.

Software Architecture Meetup
Germany Leipzig

Practical introduction to OpenTelemetry tracing

Tracking a request’s flow across different components in distributed systems is essential. With the rise of microservices, their importance has risen to critical levels. Some proprietary tools for tracking have been used already: Jaeger and Zipkin naturally come to mind. Observability is built on three pillars: logging, metrics, and tracing. OpenTelemetry is a joint effort to bring an open standard to them. Jaeger and Zipkin joined the effort so that they are now OpenTelemetry compatible. In this talk, I’ll describe the above in more detail and showcase a (simple) use case to demo how you could benefit from OpenTelemetry in your distributed architecture.

Software Architecture Meetup
Germany Leipzig

Evolving Your APIs, a Step-By-Step Approach

When you publish your first HTTP API, you’re more focused on short-term issues than planning for the future. However, chances are you’ll be successful, and you’ll hit the wall. How do you evolve your API without breaking the contract with your existing users? In this talk, I’ll first show you some tips and tricks to achieve that: moving your endpoints, deprecating them, monitoring who’s using them, and letting users know about the new endpoints. The talk is demo-based, and I’ll use the Apache APISIX project for it.

Java Forum Stuttgart
Germany Stuttgart

Evolving your APIs, a step-by-step approach

When you publish your first HTTP API, you’re more focused on short-term issues than planning for the future. However, chances are you’ll be successful, and you’ll hit the wall. How do you evolve your API without breaking the contract with your existing users? In this talk, I’ll first show you some tips and tricks to achieve that: moving your endpoints, deprecating them, monitoring who’s using them, and letting users know about the new endpoints. The talk is demo-based, and I’ll use the Apache APISIX project for it.

We Are Developers World Congress
Online

On-the-Fly Image Resizing, an Approach to Web Asset Management

One of the web architect’s main challenges is to tackle image optimization. The age-old approach is to deliberately create size variants of a single image to deliver the best user experience. It was a time-consuming task, which can be marginally improved with Machine Learning. In this session, I’ll offer a new approach that should both avoid this process and cut storage costs. Join me for practical insights into reducing expenses without compromising web performance.

Swiss PGDay 2024
Switzerland Rapperswil

Die API eines armen Mannes mit dem Ökosystem von PostgreSQL

Die Entwicklung einer vollwertigen API braucht Ressourcen, sowohl Zeit als auch Geld. Ihr müsst über das Modell, das Design, die REST-Grundsätze usw. nachdenken, ohne eine einzige Zeile Code zu schreiben. Meistens weiß man nicht, ob es sich lohnt: Man möchte ein Minimum Viable Product anbieten und von dort aus iterieren. In diesem Vortrag möchte ich euch zeigen, wie ihr das mit PostgreSQL, PostgREST und Apache APISIX erreichen könnt.

Java User Group CH
Online

Chopping the monolith

Micro services are ubiquitous. However, most companies that implement micro services do not reap their full benefits - at best. At worst, it’s an epic failure. There are reasons for micro services: independent deployment of business capabilities. However, the unspoken assumption is that you need to deploy all capabilities all the time. My experience has shown me that it’s plain wrong. Some capabilities need frequent deployment, while some are much more stable. In "the past", we used Rule Engines to allow updating business rules without deployment. While it solved the problem, this approach had issues. Between introducing a Rule Engine and migrating your complete system to micro services, I believe that there’s a middle path, and that this path is Function-as-a-Service. In this talk, I’ll detail every point I’ve made above, and show how one can use Serverless to pragmatically design a system that allows deploying as often as you need.

Tech & Wine
France Lyon

Atelier Apache APISIX

On dit que les données sont le nouveau pétrole. Pour connecter des systèmes hétérogènes, le standard de facto est est les APIs HTTP. Mais aucune entreprise ne se permet d'exposer directement son système d'information à l'extérieur. Vous avez besoin d'un point d'entrée central pour gérer les problématiques transversales comme l'authentification et une liste noire d'adresses IP, mais aussi la limitation du débit et le déploiement canari. Dans cet atelier, nous utiliserons Apache APISIX (sur Docker) pour montrer quelques capacités qui peuvent aider votre système d'information à faire face aux défis introduits par les APIs. * Routage de vos appels vers le bon Upstream * Les abstractions disponibles : Route, Upstream, Service * Le tableau de bord Apache APISIX * Configurer APISIX avec le tableau de bord * Configurer APISIX avec la ligne de commande * Surveillance d'APISIX * Introduction au développement de plugins en Lua

JavaDay
Ukraine Lviv

Practical introduction to OpenTelemetry tracing

Tracking a request’s flow across different components in distributed systems is essential. With the rise of microservices, their importance has risen to critical levels. Some proprietary tools for tracking have been used already: Jaeger and Zipkin naturally come to mind. Observability is built on three pillars: logging, metrics, and tracing. OpenTelemetry is a joint effort to bring an open standard to them. Jaeger and Zipkin joined the effort so that they are now OpenTelemetry compatible. In this talk, I’ll describe the above in more detail and showcase a (simple) use case to demo how you could benefit from OpenTelemetry in your distributed architecture.

JavaDay
Ukraine Lviv

An always up-to-date developer's CV

It’s been said that GitHub is a developer’s CV. Just a quick look at your commit history and recruiters know all about you. There are a couple of issues with this approach. Most companies don’t even publish their source code under an Open Source license. If you work for one of them, and if you’re not a rabid Open Source developer, then it’s obviously not helpful. Recently, GitHub allowed some degree of customization of one’s profile. So, even if your commit history has more white than green, you can provide a good entry-point for potential employers. But it’s only as good as the effort you put in it, and it might decay fast. Yet, with a bit of work, and the help of automation tools (such as GitHub Actions), you can provide an always up-to-date profile. In this talk, I’ll present you how to do it, using my own setup as an example.

DevConf CZ
Czech Republic Brno

Evolving your APIs, a step-by-step approach

When you publish your first HTTP API, you’re more focused on short-term issues than planning for the future. However, chances are you’ll be successful, and you’ll hit the wall. How do you evolve your API without breaking the contract with your existing users? In this talk, I’ll first show you some tips and tricks to achieve that: moving your endpoints, deprecating them, monitoring who’s using them, and letting users know about the new endpoints. The talk is demo-based, and I’ll use the Apache APISIX project for it.

Berlin Buzzwords
Germany Berlin

Practical introduction to OpenTelemetry tracing

Tracking a request’s flow across different components in distributed systems is essential. With the rise of microservices, their importance has risen to critical levels. Some proprietary tools for tracking have been used already: Jaeger and Zipkin naturally come to mind. Observability is built on three pillars: logging, metrics, and tracing. OpenTelemetry is a joint effort to bring an open standard to them. Jaeger and Zipkin joined the effort so that they are now OpenTelemetry compatible. In this talk, I’ll describe the above in more detail and showcase a (simple) use case to demo how you could benefit from OpenTelemetry in your distributed architecture.

DevFest Lille
France Lille

Faire évoluer vos APIs HTTP, une approche pas-à-pas

Lorsque vous publiez votre première API HTTP, vous avez tendance à vous concentrer davantage sur les problématiques à court terme que sur l'avenir. Cependant, il y a des chances que votre application rencontre du succès. La question se pose alors : comment faire évoluer votre API sans rompre le contrat avec vos utilisateurs existants ? Dans cette présentation, je vous montrerai quelques trucs et astuces pour y parvenir : déplacer vos points de terminaison, les déprécier, surveiller qui les utilise et informer les utilisateurs des nouveaux points de terminaison. La présentation est basée sur une démo et j'utiliserai le projet Apache APISIX pour cela.

Brussels Java User Group
Belgium Bruxelles

Evolving your APIs, a step-by-step approach

When you publish your first HTTP API, you’re more focused on short-term issues than planning for the future. However, chances are you’ll be successful, and you’ll hit the wall. How do you evolve your API without breaking the contract with your existing users? In this talk, I’ll first show you some tips and tricks to achieve that: moving your endpoints, deprecating them, monitoring who’s using them, and letting users know about the new endpoints. The talk is demo-based, and I’ll use the Apache APISIX project for it.

Community over Code
Slovakia Bratislava

The right feature at the right place: the example of authorization

All mature tech stacks nowadays offer infrastructure-related capabilities, either a standard lib or in 3rd-party libraries, e.g., rate-limiting and authorization. While it’s great to have such features, it’s impossible to audit them easily. You’d need to be familiar with the stack and dive deep into the code. This approach just doesn’t scale, A well-designed system keeps the right feature at the right place. In this talk, I’ll go through all steps toward making your system more easily auditable. I’ll use the authorization of a security policy as an example and start from a regular Spring Boot project with Spring Security. I’ll then move step-by-step, introducing the Open Policy Agent (OPA) and the Apache APISIX API Gateway. The end result will have moved all authorization details buried in the code in a readable accessible place.

JCON
Germany Dusseldorf

Evolving your APIs, a step-by-step approach

When you publish your first HTTP API, you’re more focused on short-term issues than planning for the future. However, chances are you’ll be successful, and you’ll hit the wall. How do you evolve your API without breaking the contract with your existing users? In this talk, I’ll first show you some tips and tricks to achieve that: moving your endpoints, deprecating them, monitoring who’s using them, and letting users know about the new endpoints. The talk is demo-based, and I’ll use the Apache APISIX project for it.

Worldwide Software Architecture Summit
Online

On-the-Fly Image Resizing, an Approach to Web Asset Management

One of the web architect’s main challenges is to tackle image optimization. The age-old approach is to deliberately create size variants of a single image to deliver the best user experience. It was a time-consuming task, which can be marginally improved with Machine Learning. In this session, I’ll offer a new approach that should both avoid this process and cut storage costs. Join me for practical insights into reducing expenses without compromising web performance.

Lambda Conf
USA Estes Park, Colorado

Make Your Security Policy Auditable

Nowadays, I believe that everybody realizes the importance of preventing undue access to one's applications. Many conceptual models are available, RBAC, ABAC, you name it. Likewise, all popular stacks have frameworks and libraries to help developers implement your chose policy access. If your organization only has a handful of apps, that's all fine and dandy, but problems appear at scale. One such problem is to keep under control access configuration across dozens or even hundreds of apps. It requires regular, if not continuous auditing: it's impossible to achieve when the configuration is code, even worse if it's a compiled language. Open Policy Agent aims to externalize such configuration in a text format with a specified semantics. In this presentation, I'll explain OPA in more details and demo how to migrate from regular Spring Boot application to an OPA-based approach in different steps.

SciFiDevCon
Online

Chopping the monolith

Micro services are ubiquitous. However, most companies that implement micro services do not reap their full benefits - at best. At worst, it’s an epic failure. There are reasons for micro services: independent deployment of business capabilities. However, the unspoken assumption is that you need to deploy all capabilities all the time. My experience has shown me that it’s plain wrong. Some capabilities need frequent deployment, while some are much more stable. In "the past", we used Rule Engines to allow updating business rules without deployment. While it solved the problem, this approach had issues. Between introducing a Rule Engine and migrating your complete system to micro services, I believe that there’s a middle path, and that this path is Function-as-a-Service. In this talk, I’ll detail every point I’ve made above, and show how one can use Serverless to pragmatically design a system that allows deploying as often as you need.

DevOps Days Istanbul
Turkey Istanbul

Practical introduction to OpenTelemetry tracing

Tracking a request’s flow across different components in distributed systems is essential. With the rise of microservices, their importance has risen to critical levels. Some proprietary tools for tracking have been used already: Jaeger and Zipkin naturally come to mind. Observability is built on three pillars: logging, metrics, and tracing. OpenTelemetry is a joint effort to bring an open standard to them. Jaeger and Zipkin joined the effort so that they are now OpenTelemetry compatible. In this talk, I’ll describe the above in more detail and showcase a (simple) use case to demo how you could benefit from OpenTelemetry in your distributed architecture.

Devoxx Greece
Greece Athens

Practical introduction to OpenTelemetry tracing

Tracking a request’s flow across different components in distributed systems is essential. With the rise of microservices, their importance has risen to critical levels. Some proprietary tools for tracking have been used already: Jaeger and Zipkin naturally come to mind. Observability is built on three pillars: logging, metrics, and tracing. OpenTelemetry is a joint effort to bring an open standard to them. Jaeger and Zipkin joined the effort so that they are now OpenTelemetry compatible. In this talk, I’ll describe the above in more detail and showcase a (simple) use case to demo how you could benefit from OpenTelemetry in your distributed architecture.

Centre Européen de Recherche Nucléaire
Switzerland Geneva

Evolving your APIs, a step-by-step approach

When you publish your first HTTP API, you’re more focused on short-term issues than planning for the future. However, chances are you’ll be successful, and you’ll hit the wall. How do you evolve your API without breaking the contract with your existing users? In this talk, I’ll first show you some tips and tricks to achieve that: moving your endpoints, deprecating them, monitoring who’s using them, and letting users know about the new endpoints. The talk is demo-based, and I’ll use the Apache APISIX project for it.

DevOpsDays Krakow
Poland Cracow

Practical introduction to OpenTelemetry tracing

Tracking a request’s flow across different components in distributed systems is essential. With the rise of microservices, their importance has risen to critical levels. Some proprietary tools for tracking have been used already: Jaeger and Zipkin naturally come to mind. Observability is built on three pillars: logging, metrics, and tracing. OpenTelemetry is a joint effort to bring an open standard to them. Jaeger and Zipkin joined the effort so that they are now OpenTelemetry compatible. In this talk, I’ll describe the above in more detail and showcase a (simple) use case to demo how you could benefit from OpenTelemetry in your distributed architecture.

Southern California Linux Expo
USA Pasadena

Back to basics, getting traffic into your Kubernetes cluster

However you're using your Kubernetes cluster, you'll sooner or later need to direct traffic into it. At this point, you're spoiled with choice. Kubernetes provides no less than three different objects: NodePort, Ingress, and LoadBalancer. Of course, each of them comes with its limitations. For example, LoadBalancer requires a dedicated implementation provided by Cloud Platforms but not with most local distributions. Moreover, Kubernetes is introducing a new Gateway API, adding one more way to direct traffic to the cluster. In this talk, I'd like to offer an overview of all four options, with their pros and cons, and a more in-depth explanation of the new Gateway API.

Denver Java User Group
USA Denver

Evolving your APIs, a step-by-step approach

When you publish your first HTTP API, you’re more focused on short-term issues than planning for the future. However, chances are you’ll be successful, and you’ll hit the wall. How do you evolve your API without breaking the contract with your existing users? In this talk, I’ll first show you some tips and tricks to achieve that: moving your endpoints, deprecating them, monitoring who’s using them, and letting users know about the new endpoints. The talk is demo-based, and I’ll use the Apache APISIX project for it.

Boulder JUG
USA Boulder

Evolving your APIs, a step-by-step approach

When you publish your first HTTP API, you’re more focused on short-term issues than planning for the future. However, chances are you’ll be successful, and you’ll hit the wall. How do you evolve your API without breaking the contract with your existing users? In this talk, I’ll first show you some tips and tricks to achieve that: moving your endpoints, deprecating them, monitoring who’s using them, and letting users know about the new endpoints. The talk is demo-based, and I’ll use the Apache APISIX project for it.

Chicago JUG
USA Chicago

Evolving your APIs, a step-by-step approach

When you publish your first HTTP API, you’re more focused on short-term issues than planning for the future. However, chances are you’ll be successful, and you’ll hit the wall. How do you evolve your API without breaking the contract with your existing users? In this talk, I’ll first show you some tips and tricks to achieve that: moving your endpoints, deprecating them, monitoring who’s using them, and letting users know about the new endpoints. The talk is demo-based, and I’ll use the Apache APISIX project for it.

Toronto JUG
Canada Toronto

Evolving your APIs, a step-by-step approach

When you publish your first HTTP API, you’re more focused on short-term issues than planning for the future. However, chances are you’ll be successful, and you’ll hit the wall. How do you evolve your API without breaking the contract with your existing users? In this talk, I’ll first show you some tips and tricks to achieve that: moving your endpoints, deprecating them, monitoring who’s using them, and letting users know about the new endpoints. The talk is demo-based, and I’ll use the Apache APISIX project for it.

Ottawa Java User Group
Canada Ottawa

Practical introduction to OpenTelemetry tracing

Tracking a request’s flow across different components in distributed systems is essential. With the rise of microservices, their importance has risen to critical levels. Some proprietary tools for tracking have been used already: Jaeger and Zipkin naturally come to mind. Observability is built on three pillars: logging, metrics, and tracing. OpenTelemetry is a joint effort to bring an open standard to them. Jaeger and Zipkin joined the effort so that they are now OpenTelemetry compatible. In this talk, I’ll describe the above in more detail and showcase a (simple) use case to demo how you could benefit from OpenTelemetry in your distributed architecture.

Software Crafters Montréal
Canada Montréal

Evolving your APIs, a step-by-step approach

When you publish your first HTTP API, you’re more focused on short-term issues than planning for the future. However, chances are you’ll be successful, and you’ll hit the wall. How do you evolve your API without breaking the contract with your existing users? In this talk, I’ll first show you some tips and tricks to achieve that: moving your endpoints, deprecating them, monitoring who’s using them, and letting users know about the new endpoints. The talk is demo-based, and I’ll use the Apache APISIX project for it.

ConFoo
Canada Montréal

Chopping the monolith

Micro services are ubiquitous. However, most companies that implement micro services do not reap their full benefits - at best. At worst, it’s an epic failure. There are reasons for micro services: independent deployment of business capabilities. However, the unspoken assumption is that you need to deploy all capabilities all the time. My experience has shown me that it’s plain wrong. Some capabilities need frequent deployment, while some are much more stable. In "the past", we used Rule Engines to allow updating business rules without deployment. While it solved the problem, this approach had issues. Between introducing a Rule Engine and migrating your complete system to micro services, I believe that there’s a middle path, and that this path is Function-as-a-Service. In this talk, I’ll detail every point I’ve made above, and show how one can use Serverless to pragmatically design a system that allows deploying as often as you need.

ConFoo
Canada Montréal

Practical introduction to OpenTelemetry tracing

Tracking a request’s flow across different components in distributed systems is essential. With the rise of microservices, their importance has risen to critical levels. Some proprietary tools for tracking have been used already: Jaeger and Zipkin naturally come to mind. Observability is built on three pillars: logging, metrics, and tracing. OpenTelemetry is a joint effort to bring an open standard to them. Jaeger and Zipkin joined the effort so that they are now OpenTelemetry compatible. In this talk, I’ll describe the above in more detail and showcase a (simple) use case to demo how you could benefit from OpenTelemetry in your distributed architecture.

Developer Week
USA San Francisco

Practical introduction to OpenTelemetry tracing

Tracking a request’s flow across different components in distributed systems is essential. With the rise of microservices, their importance has risen to critical levels. Some proprietary tools for tracking have been used already: Jaeger and Zipkin naturally come to mind. Observability is built on three pillars: logging, metrics, and tracing. OpenTelemetry is a joint effort to bring an open standard to them. Jaeger and Zipkin joined the effort so that they are now OpenTelemetry compatible. In this talk, I’ll describe the above in more detail and showcase a (simple) use case to demo how you could benefit from OpenTelemetry in your distributed architecture.

Café DevOps Lyon
France Lyon

Introduction pratique à OpenTelemetry pour les développeurs

Il est essentiel de suivre le parcours d'une requête à travers les différents composants d'un système distribué. Avec l'essor des microservices, cette fonctionnalité a atteint un niveau de criticité comme jamais auparant. Certains outils propriétaires de suivi vous sont peut-être connus : Jaeger et Zipkin viennent naturellement à l'esprit. L'observabilité repose sur trois piliers : la journalisation, les métriques et le traçage. OpenTelemetry est un effort conjoint visant à mettre en place un standard ouvert pour ces trois piliers. Jaeger et Zipkin se sont joints à cet effort et sont maintenant compatibles avec OpenTelemetry. Dans cet exposé, je décrirai plus en détail ce qui précède et je présenterai un cas d'utilisation (simple) pour démontrer comment vous pourriez bénéficier des traces OpenTelemetry dans votre architecture distribuée.

JFokus
Sweden Stockholm

Practical introduction to OpenTelemetry tracing

Tracking a request’s flow across different components in distributed systems is essential. With the rise of microservices, their importance has risen to critical levels. Some proprietary tools for tracking have been used already: Jaeger and Zipkin naturally come to mind. Observability is built on three pillars: logging, metrics, and tracing. OpenTelemetry is a joint effort to bring an open standard to them. Jaeger and Zipkin joined the effort so that they are now OpenTelemetry compatible. In this talk, I’ll describe the above in more detail and showcase a (simple) use case to demo how you could benefit from OpenTelemetry in your distributed architecture.

FOSDEM
Belgium Bruxelles

Evolving your APIs, a step-by-step approach

When you publish your first HTTP API, you’re more focused on short-term issues than planning for the future. However, chances are you’ll be successful, and you’ll hit the wall. How do you evolve your API without breaking the contract with your existing users? In this talk, I’ll first show you some tips and tricks to achieve that: moving your endpoints, deprecating them, monitoring who’s using them, and letting users know about the new endpoints. The talk is demo-based, and I’ll use the Apache APISIX project for it.

SnowCamp
France Grenoble

Practical introduction to OpenTelemetry tracing

Tracking a request’s flow across different components in distributed systems is essential. With the rise of microservices, their importance has risen to critical levels. Some proprietary tools for tracking have been used already: Jaeger and Zipkin naturally come to mind. Observability is built on three pillars: logging, metrics, and tracing. OpenTelemetry is a joint effort to bring an open standard to them. Jaeger and Zipkin joined the effort so that they are now OpenTelemetry compatible. In this talk, I’ll describe the above in more detail and showcase a (simple) use case to demo how you could benefit from OpenTelemetry in your distributed architecture.

Coffee JUG
Ukraine Lviv

Evolving your APIs, a step-by-step approach

When you publish your first HTTP API, you’re more focused on short-term issues than planning for the future. However, chances are you’ll be successful, and you’ll hit the wall. How do you evolve your API without breaking the contract with your existing users? In this talk, I’ll first show you some tips and tricks to achieve that: moving your endpoints, deprecating them, monitoring who’s using them, and letting users know about the new endpoints. The talk is demo-based, and I’ll use the Apache APISIX project for it.

90DaysOfDevOps
Online

Practical introduction to OpenTelemetry tracing

Tracking a request’s flow across different components in distributed systems is essential. With the rise of microservices, their importance has risen to critical levels. Some proprietary tools for tracking have been used already: Jaeger and Zipkin naturally come to mind. Observability is built on three pillars: logging, metrics, and tracing. OpenTelemetry is a joint effort to bring an open standard to them. Jaeger and Zipkin joined the effort so that they are now OpenTelemetry compatible. In this talk, I’ll describe the above in more detail and showcase a (simple) use case to demo how you could benefit from OpenTelemetry in your distributed architecture.