Zero downtime deployment
with Kubernetes, Spring Boot and Flyway
Securing the JVM, neither
for fun nor for profit but do you have a choice?
1. 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
2. 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
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
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
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.