Speaking

Kubernetes allows a lot. After discovering its features, it’s easy to think it can magically transform your application deployment process into a painless no-event. For Hello World applications, that is the case. Unfortunately, not many of us do deploy such applications day-to-day. You need to think about application backward compatibility, possible rollback, database schema migration, etc. I believe the later is one of the biggest pain point. In this talk, I’ll demo how to update a Spring Boot app deployed on a Kubernetes cluster with a non-trivial database schema migration with the help of Flyway, while keeping the service up during the entire update process.

Most developers don’t write Object-Oriented code, including myself. And yet, we have learned how to do it. Why is that? One of the possible reasons, is that many frameworks (Java EE, Spring) do not favor OOP in their design. But what is OOP really? We will have a look at a super-simplified bank account model. In my demo, I’ll demo with a Java-based application how can we evolve from the traditional current approach to proper OOP. Finally, it will be time to have a look at the benefits and drawbacks of both approach.

Consider a Java application in a private banking system. A new network administrator is hired, and while going around, he notices that the app is making network calls to an unknown external endpoint. After some investigation, it’s found that this app has been sending for years confidential data to a competitor (or a state, or hackers, whatever). This is awkward. Especially since it could have been avoided. Code reviews are good to improve the hardening of an application, but what if the malicious code was planted purposely? Some code buried in a commit could extract code from binary content, compile it on the fly, and then execute the code in the same JVM run… By default, the JVM is not secured! Securing the JVM for a non-trivial application is complex and time-consuming but the risks of not securing it could be disastrous. In this talk, I’ll show some of the things you could do in an unsecured JVM. I’ll also explain the basics of securing it, and finally demo a working process on how to do it.

Consider a Java application in a private banking system. A new network administrator is hired, and while going around, he notices that the app is making network calls to an unknown external endpoint. After some investigation, it’s found that this app has been sending for years confidential data to a competitor (or a state, or hackers, whatever). This is awkward. Especially since it could have been avoided. Code reviews are good to improve the hardening of an application, but what if the malicious code was planted purposely? Some code buried in a commit could extract code from binary content, compile it on the fly, and then execute the code in the same JVM run… By default, the JVM is not secured! Securing the JVM for a non-trivial application is complex and time-consuming but the risks of not securing it could be disastrous. In this talk, I’ll show some of the things you could do in an unsecured JVM. I’ll also explain the basics of securing it, and finally demo a working process on how to do it.

Kubernetes in general, and Istio in particular, have changed a lot the way we look at Ops-related constraints: monitoring, load-balancing, health checks, etc. Before those products became available, there were already available solutions to handle those constraints. Among them are different libraries e.g. Hystrix and Resilience4J in the Java ecosystem. In particular, they both provide an implementation of the Circuit Breaker pattern, which prevents a network or service failure from cascading to other services. But now Istio also provides the same capability. In this talk, we will have a look at how Istio and one among Hystrix/Resilience4J implement the Circuit Breaker pattern, and what pros/cons each of them has. Bonus, you’ll be able to choose what library we will focus for the demo. After this talk, you’ll be able to decide which one is the best fit in your context.

Unit testing ensures your production code is relevant. But what does ensure your testing code is relevant? Come discover mutation testing and make sure your never forget another assert again. In the realm of testing, the code coverage metrics is the most often talked about. However, it doesn't mean that the test has been useful or even that an assert has been coded. Mutation testing is a strategy to make sure that the test code is relevant. In this talk, we will explain how Code Coverage is computed, what its inherent flaw is and how Mutation Testing can help us in this regard.

So, you’ve migrated your application to Reactive Microservices to get the last ounce of performance from your servers. Still want more? Perhaps you forgot about the logs: logs can be one of the few roadblocks on the road to ultimate performance. At Exoscale, we faced the same challenges as everyone: the application produces logs, and they need to be stored in our log storage – Elasticsearch, with the minimum of fuss and the fastest way possible. In this talk, I’ll show you some insider tips and tricks taken from our experience put you on the track toward fast(er) log management. Without revealing too much, it involves async loggers, JSON, Kafka and Logstash.

Kubernetes in general, and Istio in particular, have changed a lot the way we look at Ops-related constraints: monitoring, load-balancing, health checks, etc. Before those products became available, there were already available solutions to handle those constraints. Among them is Resilience4J, a Java library. From the site: "Resilience4j is a fault tolerance library designed for Java8 and functional programming." In particular, Resilience4J provides an implementation of the Circuit Breaker pattern, which prevents a network or service failure from cascading to other services. But now Istio also provides the same capability. In this talk, we will have a look at how Istio and Resilience4J implement the Circuit Breaker pattern, and what pros/cons each of them has. After this talk, you’ll be able to decide which one is the best fit in your context.

Kubernetes in general, and Istio in particular, have changed a lot the way we look at Ops-related constraints: monitoring, load-balancing, health checks, etc. Before those products became available, there were already available solutions to handle those constraints. Among them are different libraries e.g. Hystrix and Resilience4J in the Java ecosystem. In particular, they both provide an implementation of the Circuit Breaker pattern, which prevents a network or service failure from cascading to other services. But now Istio also provides the same capability. In this talk, we will have a look at how Istio and one among Hystrix/Resilience4J implement the Circuit Breaker pattern, and what pros/cons each of them has. Bonus, you'll be able to choose what library we will focus for the demo. After this talk, you’ll be able to decide which one is the best fit in your context.

Kubernetes in general, and Istio in particular, have changed a lot the way we look at Ops-related constraints: monitoring, load-balancing, health checks, etc. Before those products became available, there were already available solutions to handle those constraints. Among them is Hystrix, a Java library provided by Netflix. From the site: 'Hystrix is a latency and fault tolerance library designed to isolate points of access to remote systems, services and 3rd party libraries, stop cascading failure and enable resilience in complex distributed systems where failure is inevitable.' In particular, Hystrix provides an implementation of the Circuit Breaker pattern, which prevents a network or service failure from cascading to other services. But now Istio also provides the same capability. In this talk, we will have a look at how Istio and Hystrix implement the Circuit Breaker pattern, and what pros/cons each of them has. After this talk, you’ll be able to decide which one is the best fit in your context.

While a microservices architecture is more scalable than a monolith, it has a direct hit on performance. To cope with that, one performance improvement is to set up a cache. It can be configured for database access, for REST calls or just to store session state across a cluster. In this demo-based talk, I’ll show how Hazelcast In-Memory Data Grid can help you in each one of those areas and how to configure it. Hint: it’s much easier than one would expect.

Docker images are supposed to (and should be) immutable. Given that the same image should be promoted from the development environment to the production environment, it needs to be parameterized in each environment. Kubernetes provides different ways to do that. On the other hand, the Spring Boot platform allows a wide range of configuration options. In this talk, I’ll go through (and demo!) what common options are available, and what pro(s)/con(s) each of them have.

Consider a Java application in a private banking system A new network administrator is hired, and while going around, he notices that the app is making network calls to a unknown external endpoint After some investigation, it’s found that this app has been sending for years confidential data to a competitor (or a state, or hackers, whatever) This is awkward Especially since it could have been avoided. Code reviews are good to improve the hardening of an application, but what if the malicious code was planted purposely? Some code buried in a commit could extract code from binary content, compile it on the fly, and then execute the code in the same JVM run… By default, the JVM is not secured! Securing the JVM for a non-trivial application is complex and time-consuming but the risks of not securing it could be disastrous In this talk, I’ll show some of the things you could do in an unsecured JVM I’ll also explain the basics of securing it, and finally demo a working process on how to do it.

Kubernetes allows a lot. After discovering its features, it’s easy to think it can magically transform your application deployment process into a painless no-event. For Hello World applications, that is the case. Unfortunately, not many of us do deploy such applications day-to-day. You need to think about application backward compatibility, possible rollback, database schema migration, etc. I believe the later is one of the biggest pain point. In this talk, I’ll demo how to update a Spring Boot app deployed on a Kubernetes cluster with a non-trivial database schema migration with the help of Flyway, while keeping the service up during the entire update process.

The Java API allows a lot: sending packets over the network, compiling code, etc. If you put an application in an production environment, you need to make sure it doesn’t do more than it’s supposed to do. Consider a Java application in a private banking system. A new network administrator is hired, and while going around, he notices that the app is making network calls to a unknown external endpoint. After some investigation, it’s found that this app has been sending for years confidential data to a competitor (or a state, or hackers, whatever). This is awkward. Especially since it could have been avoided. Code reviews are good to improve the hardening of an application, but what if the malicious code was planted purposely? Some code buried in a commit could extract code from binary content, compile it on the fly, and then execute the code in the same JVM run... By default, the JVM is not secured! Securing the JVM for a non-trivial application is complex and time-consuming but the risks of not securing it could be disastrous. In this talk, I’ll show some of the things you could do in an unsecured JVM. I’ll also explain the basics of securing it, and finally demo a working process on how to do it.

In the latest years, there has been some push-back against frameworks, and more specifically annotations: some call them magic. Obviously, they make understanding the flow of the application harder. Spring and Spring Boot latest versions go along this trend, by offering an additional way to configure beans with explicit code instead of annotations. It’s declarative in the sense it looks like configuration, though it’s based on Domain-Specific Language(s). This talk aims to demo a step-by-step process to achieve that.

Beyond Hello World applications, zero-downtime deployments are not trivial. In this talk, I’ll demo how to achieve that on a Spring Boot application using Kubernetes and Flyway.

Kubernetes in general, and Istio in particular, have changed a lot the way we look at Ops-related constraints: monitoring, load-balancing, health checks, etc. Before those products became available, there were already available solutions to handle those constraints. Among them is Hystrix, a Java library provided by Netflix. From the site: 'Hystrix is a latency and fault tolerance library designed to isolate points of access to remote systems, services and 3rd party libraries, stop cascading failure and enable resilience in complex distributed systems where failure is inevitable.' In particular, Hystrix provides an implementation of the Circuit Breaker pattern, which prevents a network or service failure from cascading to other services. But now Istio also provides the same capability. In this talk, we will have a look at how Istio and Hystrix implement the Circuit Breaker pattern, and what pros/cons each of them has. After this talk, you’ll be able to decide which one is the best fit in your context.

In the realm of testing, the code coverage metrics is the most often talked about. However, it doesn't mean that the test has been useful or even that an assert has been coded. Mutation testing is a strategy to make sure that the test code is relevant. In this talk, I will explain how Code Coverage is computed and what its inherent flaw is. Afterwards, I will describe how Mutation Testing work and how it helps pointing out code that is tested but leave out corner cases.

In the latest years, there has been some push-back against frameworks, and more specifically annotations: some call them magic. Obviously, they make understanding the flow of the application harder. Spring and Spring Boot latest versions go along this trend, by offering an additional way to configure beans with explicit code instead of annotations. It's declarative in the sense it looks like configuration, though it's based on Domain-Specific Language(s). This talk aims to demo a step-by-step process to achieve that.

In the latest years, there has been some push-back against frameworks, and more specifically annotations: some call them magic. Obviously, they make understanding the flow of the application harder. Spring and Spring Boot latest versions go along this trend, by offering an additional way to configure beans with explicit code instead of annotations. It's declarative in the sense it looks like configuration, though it's based on Domain-Specific Language(s). This talk aims to demo a step-by-step process to achieve that.

Kubernetes allows a lot. After discovering its features, it’s easy to think it can magically transform your application deployment process into a painless no-event. For Hello World applications, that is the case. Unfortunately, not many of us do deploy such applications day-to-day. You need to think about application backward compatibility, possible rollback, database schema migration, etc. I believe the later is one of the biggest pain point. In this talk, I’ll demo how to update a Spring Boot app deployed on a Kubernetes cluster with a non-trivial database schema migration with the help of Flyway, while keeping the service up during the entire update process.

Kubernetes in general, and Istio in particular, have changed a lot the way we look at Ops-related constraints: monitoring, load-balancing, health checks, etc. Before those products became available, there were already available solutions to handle those constraints. Among them is Hystrix, a Java library provided by Netflix. From the site: 'Hystrix is a latency and fault tolerance library designed to isolate points of access to remote systems, services and 3rd party libraries, stop cascading failure and enable resilience in complex distributed systems where failure is inevitable.' In particular, Hystrix provides an implementation of the Circuit Breaker pattern, which prevents a network or service failure from cascading to other services. But now Istio also provides the same capability. In this talk, we will have a look at how Istio and Hystrix implement the Circuit Breaker pattern, and what pros/cons each of them has. After this talk, you’ll be able to decide which one is the best fit in your context.

In the realm of testing, the code coverage metrics is the most often talked about. However, it doesn't mean that the test has been useful or even that an assert has been coded. Mutation testing is a strategy to make sure that the test code is relevant. In this talk, I will explain how Code Coverage is computed and what its inherent flaw is. Afterwards, I will describe how Mutation Testing work and how it helps pointing out code that is tested but leave out corner cases.

Docker images are supposed to (and should be) immutable. Given that the same image should be promoted from the development environment to the production environment, it needs to be parameterized in each environment. Kubernetes provides different ways to do that. On the other, the Spring Boot platform allows a wide range of configuration options. In this talk, I’ll go through (and demo!) what common options are available, and what pro(s)/con(s) each of them have.

Kubernetes allows a lot. After discovering its features, it’s easy to think it can magically transform your application deployment process into a painless no-event. For Hello World applications, that is the case. Unfortunately, not many of us do deploy such applications day-to-day. You need to think about application backward compatibility, possible rollback, database schema migration, etc. I believe the later is one of the biggest pain point. In this talk, I’ll demo how to update a Spring Boot app deployed on a Kubernetes cluster with a non-trivial database schema migration with the help of Flyway, while keeping the service up during the entire update process.

Docker images are supposed to (and should be) immutable. Given that the same image should be promoted from the development environment to the production environment, it needs to be parameterized in each environment. Kubernetes provides different ways to do that. On the other, the Spring Boot platform allows a wide range of configuration options. In this talk, I’ll go through (and demo!) what common options are available, and what pro(s)/con(s) each of them have.

Kubernetes allows a lot. After discovering its features, it’s easy to think it can magically transform your application deployment process into a painless no-event. For Hello World applications, that is the case. Unfortunately, not many of us do deploy such applications day-to-day. You need to think about application backward compatibility, possible rollback, database schema migration, etc. I believe the later is one of the biggest pain point. In this talk, I’ll demo how to update a Spring Boot app deployed on a Kubernetes cluster with a non-trivial database schema migration with the help of Flyway, while keeping the service up during the entire update process.

Docker images are supposed to (and should be) immutable. Given that the same image should be promoted from the development environment to the production environment, it needs to be parameterized in each environment. Kubernetes provides different ways to do that. On the other, the Spring Boot platform allows a wide range of configuration options. In this talk, I’ll go through (and demo!) what common options are available, and what pro(s)/con(s) each of them have.

Consider a Java application in a private banking system. A new network administrator is hired, and while going around, he notices that the app is making network calls to an unknown external endpoint. After some investigation, it’s found that this app has been sending for years confidential data to a competitor (or a state, or hackers, whatever). This is awkward. Especially since it could have been avoided. Code reviews are good to improve the hardening of an application, but what if the malicious code was planted purposely? Some code buried in a commit could extract code from binary content, compile it on the fly, and then execute the code in the same JVM run... By default, the JVM is not secured! Securing the JVM for a non-trivial application is complex and time-consuming but the risks of not securing it could be disastrous. In this talk, I’ll show some of the things you could do in an unsecured JVM. I’ll also explain the basics of securing it, and finally demo a working process on how to do it.

Kubernetes in general, and Istio in particular, have changed a lot the way we look at Ops-related constraints: monitoring, load-balancing, health checks, etc. Before those products became available, there were already available solutions to handle those constraints. Among them is Hystrix, a Java library provided by Netflix. From the site: 'Hystrix is a latency and fault tolerance library designed to isolate points of access to remote systems, services and 3rd party libraries, stop cascading failure and enable resilience in complex distributed systems where failure is inevitable.' In particular, Hystrix provides an implementation of the Circuit Breaker pattern, which prevents a network or service failure from cascading to other services. But now Istio also provides the same capability. In this talk, we will have a look at how Istio and Hystrix implement the Circuit Breaker pattern, and what pros/cons each of them has. After this talk, you'll be able to decide which one is the best fit in your context.

Kubernetes in general, and Istio in particular, have changed a lot the way we look at Ops-related constraints: monitoring, load-balancing, health checks, etc. Before those products became available, there were already available solutions to handle those constraints. Among them is Hystrix, a Java library provided by Netflix. From the site: 'Hystrix is a latency and fault tolerance library designed to isolate points of access to remote systems, services and 3rd party libraries, stop cascading failure and enable resilience in complex distributed systems where failure is inevitable.' In particular, Hystrix provides an implementation of the Circuit Breaker pattern, which prevents a network or service failure from cascading to other services. But now Istio also provides the same capability. In this talk, we will have a look at how Istio and Hystrix implement the Circuit Breaker pattern, and what pros/cons each of them has. After this talk, you'll be able to decide which one is the best fit in your context.

Kubernetes in general, and Istio in particular, have changed a lot the way we look at Ops-related constraints: monitoring, load-balancing, health checks, etc. Before those products became available, there were already available solutions to handle those constraints. Among them is Hystrix, a Java library provided by Netflix. From the site: 'Hystrix is a latency and fault tolerance library designed to isolate points of access to remote systems, services and 3rd party libraries, stop cascading failure and enable resilience in complex distributed systems where failure is inevitable.' In particular, Hystrix provides an implementation of the Circuit Breaker pattern, which prevents a network or service failure from cascading to other services. But now Istio also provides the same capability. In this talk, we will have a look at how Istio and Hystrix implement the Circuit Breaker pattern, and what pros/cons each of them has. After this talk, you'll be able to decide which one is the best fit in your context.

Kubernetes in general, and Istio in particular, have changed a lot the way we look at Ops-related constraints: monitoring, load-balancing, health checks, etc. Before those products became available, there were already available solutions to handle those constraints. Among them is Hystrix, a Java library provided by Netflix. From the site: 'Hystrix is a latency and fault tolerance library designed to isolate points of access to remote systems, services and 3rd party libraries, stop cascading failure and enable resilience in complex distributed systems where failure is inevitable.' In particular, Hystrix provides an implementation of the Circuit Breaker pattern, which prevents a network or service failure from cascading to other services. But now Istio also provides the same capability. In this talk, we will have a look at how Istio and Hystrix implement the Circuit Breaker pattern, and what pros/cons each of them has. After this talk, you'll be able to decide which one is the best fit in your context.

Coming from a mainstream language programming background (Java), learning a language like Clojure is like hitting your head on the wall... repeatedly. After a time, however, pieces seem to fall into place, and the magic happens: I started to reason in terms of data processing, and not in terms of objects anymore. If you want to come with me on my journey of learning Clojure as an OOP guy, I'll be happy to show you strange beasts such as Dynamic Dispatch, Threading, Contract-Based Programming, and much much more.

Docker images are supposed to (and should be) immutable. Given that the same image should be promoted from the development environment to the production environment, it needs to be parameterized in each environment. Kubernetes provides different ways to do that. On the other, the Spring Boot platform allows a wide range of configuration options. In this talk, I’ll go through (and demo!) what common options are available, and what pro(s)/con(s) each of them have.

The Java API allows a lot: sending packets over the network, compiling code, etc. If you put an application in an production environment, you need to make sure it doesn’t do more than it’s supposed to do.

In the latest years, there has been some push-back against frameworks, and more specifically annotations: some call them magic. Obviously, they make understanding the flow of the application harder. Spring and Spring Boot latest versions go along this trend, by offering an additional way to configure beans with explicit code instead of annotations. It's declarative in the sense it looks like configuration, though it's based on Domain-Specific Language(s). This talk aims to demo a step-by-step process to achieve that.

In the latest years, there has been some push-back against frameworks, and more specifically annotations: some call them magic. Obviously, they make understanding the flow of the application harder. Spring and Spring Boot latest versions go along this trend, by offering an additional way to configure beans with explicit code instead of annotations. It's declarative in the sense it looks like configuration, though it's based on Domain-Specific Language(s). This talk aims to demo a step-by-step process to achieve that.

Kubernetes allows a lot. After discovering its features, it’s easy to think it can magically transform your application deployment process into a painless no-event. For Hello World applications, that is the case. Unfortunately, not many of us do deploy such applications day-to-day. You need to think about application backward compatibility, possible rollback, database schema migration, etc. I believe the later is one of the biggest pain point. In this talk, I’ll demo how to update a Spring Boot app deployed on a Kubernetes cluster with a non-trivial database schema migration with the help of Flyway, while keeping the service up during the entire update process.

The Java API allows a lot: sending packets over the network, compiling code, etc. If you put an application in an production environment, you need to make sure it doesn’t do more than it’s supposed to do. Consider a Java application in a private banking system. A new network administrator is hired, and while going around, he notices that the app is making network calls to a unknown external endpoint. After some investigation, it’s found that this app has been sending for years confidential data to a competitor (or a state, or hackers, whatever). This is awkward. Especially since it could have been avoided. Code reviews are good to improve the hardening of an application, but what if the malicious code was planted purposely? Some code buried in a commit could extract code from binary content, compile it on the fly, and then execute the code in the same JVM run... By default, the JVM is not secured! Securing the JVM for a non-trivial application is complex and time-consuming but the risks of not securing it could be disastrous. In this talk, I’ll show some of the things you could do in an unsecured JVM. I’ll also explain the basics of securing it, and finally demo a working process on how to do it.

The Java API allows a lot: sending packets over the network, compiling code, etc. If you put an application in an production environment, you need to make sure it doesn’t do more than it’s supposed to do. Consider a Java application in a private banking system. A new network administrator is hired, and while going around, he notices that the app is making network calls to a unknown external endpoint. After some investigation, it’s found that this app has been sending for years confidential data to a competitor (or a state, or hackers, whatever). This is awkward. Especially since it could have been avoided. Code reviews are good to improve the hardening of an application, but what if the malicious code was planted purposely? Some code buried in a commit could extract code from binary content, compile it on the fly, and then execute the code in the same JVM run... By default, the JVM is not secured! Securing the JVM for a non-trivial application is complex and time-consuming but the risks of not securing it could be disastrous.

Kubernetes in general, and Istio in particular, have changed a lot the way we look at Ops-related constraints: monitoring, load-balancing, health checks, etc. Before those products became available, there were already available solutions to handle those constraints. Among them is Hystrix, a Java library provided by Netflix. From the site: 'Hystrix is a latency and fault tolerance library designed to isolate points of access to remote systems, services and 3rd party libraries, stop cascading failure and enable resilience in complex distributed systems where failure is inevitable.' In particular, Hystrix provides an implementation of the Circuit Breaker pattern, which prevents a network or service failure from cascading to other services. But now Istio also provides the same capability. In this talk, we will have a look at how Istio and Hystrix implement the Circuit Breaker pattern, and what pros/cons each of them has. After this talk, you’ll be able to decide which one is the best fit in your context.

The Java API allows a lot: sending packets over the network, compiling code, etc. If you put an application in an production environment, you need to make sure it doesn’t do more than it’s supposed to do. Consider a Java application in a private banking system. A new network administrator is hired, and while going around, he notices that the app is making network calls to a unknown external endpoint. After some investigation, it’s found that this app has been sending for years confidential data to a competitor (or a state, or hackers, whatever). This is awkward. Especially since it could have been avoided. Code reviews are good to improve the hardening of an application, but what if the malicious code was planted purposely? Some code buried in a commit could extract code from binary content, compile it on the fly, and then execute the code in the same JVM run... By default, the JVM is not secured! Securing the JVM for a non-trivial application is complex and time-consuming but the risks of not securing it could be disastrous. In this talk, I’ll show some of the things you could do in an unsecured JVM. I’ll also explain the basics of securing it, and finally demo a working process on how to do it.

Kubernetes allows a lot. After discovering its features, it’s easy to think it can magically transform your application deployment process into a painless no-event. For Hello World applications, that is the case. Unfortunately, not many of us do deploy such applications day-to-day. You need to think about application backward compatibility, possible rollback, database schema migration, etc. I believe the later is one of the biggest pain point. In this talk, I’ll demo how to update a Spring Boot app deployed on a Kubernetes cluster with a non-trivial database schema migration with the help of Flyway, while keeping the service up during the entire update process.