For the second time (first time was in 2017, I did not take any notes on my blog though…), I’ve been attending DevNexus from February 21st to 23rd, in Atlanta, probably the biggest Java (and cloud) conference of the East Coast (2100 attendees), and here are some of my notes.

Day 1: Workshop Java Microservices Patterns & Practices with Kubernetes/OpenShift and Istio

This Istio workshop was presented by Burr Sutter (founder of DevNexus!) and Rafael Benevides from Red Hat.

The presentation slides are available online.

Introduction

Burr starting presenting us the Monolith application and its evolution into myriads of  microservices.

Monoliths don’t have to suck ( we can read the majestic monolith and it’s always good to repeat that not everybody needs them) ; and since microservices can’t really be deployed all alone, think  a network of services, as soon as you deploy those services (50, 100s), you need to be able to observe, discover, monitor them; and this is where Istio shines.

First demo : initial deployment of 3 chained services on OpenShift / Kubernetes

Those 3 services were either Vert.x or spring boot based (serviceA calls serviceB that calls serviceC).

Interestingly enough, Burr and Rafael built all their Java services images based on fabric8 images – those images include nice monitoring utilities such as jmx exporter for sharing JVM metrics with Prometheus and Jolokia to export those same JMX metrics via Rest ; plus those images have nice JAVA_OPTS to integrate the JVM correctly in a container (cpu and max heap settings)

I was happy to discover some Kubernetes pod configuration options too, check them out !

readiness and liveness probes

During this demo, Burr showed to us how he used istio to embed a sidecar container into each of his services’ pods to feed jaeger with tracing, prometheus with metrics, and apply routing rules (canary deployment, etc.)

Back to the presentation : from instrumenting the JVM to intercepting traffic in a pod

Burr reminded us with the 8 Fallacies of distributed computing .

That lead us to embrace the Reactive manifesto for elastic , responsive,  resilient, message driven systems

Istio is a service mesh  (not a service mess :-P)

Istio moves many services that used to be provided on the JVM (resiliency, fault tolerance, routing, etc. using NetFlix OSS libraries for example)

to sidecar containers :

The overall architecture is the following :

Workshop : time to experiment with Istio

No need to run things locally (but if you want to, it’s available at https://github.com/redhat-developer-demos/istio-tutorial), the speakers gave the attendees access to an OpenShift environment, via Katacoda (very similar to play with docker / play with kubernetes) –

We needed to complete 8 scenarios, allowing us to reproduce interesting isio use cases :

Most commands were using « oc »; a tool similar to kubectl but with additional verbs, such as get routes, expose service, new-project for namespaces, etc.)

Deep Dive into Dockerfiles by Raju Gandhi

Raju started explaining, through a quick demo (docker commit a container into an image), the concept of union filesystem (a pile of layers, the last one on top being writable to allow the containers to write)

There’s a maximum of 127 layers.

Raju also explained how the build cache can help and how it is sensible to even small changes in a Dockerfile instruction

A few DO’s and DONT’s were introduced :

DONT’s :

• do not use multiple FROM in a Dockerfile
• do not use the latest tag
• avoid ADD, too much magic (can download, can untar, etc.), prefer COPY

DOs :

• pin a tag version in your FROM instruction
• use LABELs : they can see ENV variables as well
• use a convention across your company for LABELs
• use the exec form in your CMD instructions (CMD [« java », « -jar », « app.jar »]), to not fork the main pid
• Always use « exec » in your entrypoint script
• consider using multi stage builds

Raju also mentioned a project that eases the pain with init : tini

Welcome to JUnit 5  by Billy Korando

Slides are available online

Billy started reminded us with the benefits of continuous delivery before presenting the goals of JUnit 5 :

• modernize (Java 8 baseline)
• modularize : several modules
  • vintage (legacy compatibility)
  • platform (test launcher)
  • jupiter (new programming model)
• extensible
• backwards compatible (you can use the JUnit 4 annotations)

Then Billy continued his presentation with a  few language changes and additions – the most visible ones using Java 8 stream API.

Rules are no longer being used, but you can use a legacy bridge (you need to have junit-jupiter-migrationsupport on your classpath) to make your existing tests pass without modification.

Instead of specifying runners, you can directly use an annotation to extend the runner, for example @SpringJUnitConfig

You can now Inject TestInfo to debug your test :

You can tag a test and choose to include or exclude such tags, with @Tag(« tagName »)

A nice feature was discussed too : extensions . For example TestContainersExtension, to start up containers (for example, start a real DB in a a container, great for Integration tests)

What about tooling support ? All major IDEs and test runners are supported, with the exception of Maven failsafe

 

Gradle Fundamentals  by Kenneth Kousen

After talking about installation steps, Kenneth explained few basic gradle command lines, such as :

So what to choose for your 3rd party java dependencies ? compile ? api ? impl ? providedCompile ? To be honest I’m not clear on that yet, but I have the feeling I’ll need to be soon

Double quotes provide interpolation, just use it if needed, otherwise it can be confusing (just use the minimum)

Kenneth talked about the Project and Task properties (doFirst() , doLast())

Making Microservices Micro with Istio Service Mesh by Ray Tsang 

Slides are available online.

I was curious to see another talk about Istio, but this time from a Google developer advocate (versus RedHad OpenShift people the day before at the workshop)

This talk was not about why we should use micro services, but rather, how to handle them since they come with their own class of problems.

For his demo, Ray used a guest book service example deployment he created, available on github.

Ray used kubectl apply, I usually use create, apply is more gentle and does not replace parts of the deployment that were not touched.

Having your JVM provide / embed its own tracing, discovery, etc. services works great but if your application is split across several different services not all being developed with the same language or frameworks, it can be complicated to manage them all.

Introducing Istio, an open platform from Google, IBM, and Lyft, designed to run in different environments, but prioritizing  Kubernetes. Istio is being deployed as a proxy per microservice instance (the side car model), using Envoy.

Ray was using Zipkin for tracing, Prometheus for monitoring ; but if you deploy on a cloud platform, well, some of them provide those services for you.

Ray then created a new meeting service, being called by another work service that would pass, x3b HTTP headers, to enable tracing of calls between the two services.

After the initial deployment, Ray then used kube-inject to instrument the deployment files for Istio

According to the Istio documentation, you have two ways to inject Istio side car container : either manually :

or simply , if you enabled a webhook during the Kubernetes cluster setup :

And then, he applied Istio rules to circuit break (prevent the service to be overloaded, setting a maximum of request ) , canary deployment of a new version of the service, etc.

Back to the slides, Ray talked about the CA (Certificate Authority) capability of Istio

Istio is 0.5 for now, should be 1.0 this year.

Introducing Amazon EKS by Arun Gupta

Arun started describing the overall architecture of Kubernetes (masters, API server, worker nodes, etc.) and how several community projects such as kops help people set up a Kubernetes cluster on AWS.

Acknowledging the effort is usually high to set up a Kubernetes cluster, Arun described how a native AWS integration with Kubernetes would ease things; introducing EKS.

But default, aws eks will spin up 3 masters  and 3 etcds (6 instances on your behalf) on different availability zones. You cannot manage the masters – it’s all handled for you; so to provide visibility, logs are sent to AWS CloudTrail and AWS CloudWatch.

Metrics are gathered from the nodes, pods and the applications using Prometheus / Heapster; on top of that alerting is using Kapacitor or AlertManager, and visualization is using Graphana.

Can I run Kubernetes Add-ons ? Kube DNS, Dashboard, etc.  ? Yes as long as they are integrated by EKS – so popular add-ons will be available on EKS, but custom ones, won’t be able to run.

EKS Worker Nodes : you can use an AMI to provision a new worker node (based on AWS Linux), but you can attach any worker nodes you like to your EKS cluster.

A CNI provider is also available, and can use a VPC aware CNI implementation from AWS.

IAM for the user authentication, authorization using RBAC from Kubernetes itself; based on the IAM roles, RBAC will accept or deny the requests.

In the limited preview, only Kubernetes 1.7 is available. After GA, scheduled for Q2, 3 major versions of Kubernetes will be available.

For auto scaling, a tight integration with Fargate is going to be used : say how many instances you need, it will take care of autoscaling for you automatically.

 

Bootiful Kotlin by joshlong 

Code is available on Github

It’s interesting to use a JVM based language such as Kotlin, since it has the possibility to evolve quicker than the JVM itself.

Josh of course starting his demo loading start.spring.io and chosing a Maven project with Kotlin support and Spring Boot 2.0.0 RC2 (GA is coming in the next few weeks) – he then added H2, JDBC, Web as dependencies

Interestingly enough, the pom file will include a dependency to the kotlin-maven-allopen plugin : if you write a class in Kotlin, it’s final by default (you need open if you want it to not be final) – and that’s an issue for the Spring framework; so this plugin makes classes open by default.

Using a simple CustomerService application, he created an ApplicationRunner (similar to CommandLineRunner) that would insert customers at startup.

After a first « regular » usage of JdbcTemplate, Josh then used org.jetbrains.exposed:exposed:0.8.7 to get rid of the boiler plate SQL code  using a Table object.

Microservice Networking in Anger by Bob Paulin 

Slides and demos are  available are online

Bob used a simple Java application (using Apache Camel) sending packets in different network protocols (ping, UDP, TCP), and started monitoring traffic using Wireshark.

Then using tc qdisc, he started provoking havoc on the network (dropping packets) – UDP did not care, TCP re sent packets, so far, so good.

Sending way more packets using Apache Bench (ab), he showed the audience that just a 10% drop of packets would cause a huge slow down in transmission rate.

Bob then moved to examples involving timeouts (connection, read and execution timeouts) :should we timeout and give up quickly (faster responses but more failures) or rather re try on failures ? (slower responses, but less failures)

Moving on to websockets (using HAProxy in the middle) : by default websocket connections got closed because HAProxy was timing out them; Bob then needed to tweak a tunnel timeout.

Then, a TLS example : Bob debugged a TLS version mismatch using Wireshark (JDK 1.7 does not use TLSv1.2, but the server required this version)

For his last example, Bob tried to connect to Hazelcast nodes together, using their default multicast discovery mechanism. Everything worked fine when he deployed them as 2 containers to a single Docker node. But that did not work anymore when each container was deployed on a separate Docker node : that’s because the Docker overlay network plugin does not support multicast ! Using the Weave network plugin, he could make it work, since it supports multicast.

Keynotes

On Thursday we got a keynote about  Designing and Visualizing Deep Space Manned Missions by Diane Davis and Sean M Phillips that was very interesting and entertaining too !

On Friday, the second ans last note keynote was The Future of the Cloud will be Containerized by Kelsey Hightower (the famous author of « Kubernetes the hard way« )

Wrapping up !

I have also attended Attackers have the first mover advantage. Let’s close that gap.  by Brian Fox from Sonatype (the people behind Maven central) where I’ve learned that Maven central was serving 87 billions downloads in 2017 compared to 12 Billions pulls from DockerHub in 2017 !

Also, worth mentioning is the performance from my SoftwareAG / Terracotta colleague Henri Tremblay who presented Learn Java 8: Lambdas and Functional Programming in front of a large audience

DevNexus is definitely a conference worth attending : it’s not only a very good Java conference, it’s also a great Containerization conference as well : the Docker and Kubernetes talks were really insightful (Istio is all the rage !)

What I preferred during this conference is the workshop on Wednesday : it’s a great opportunity to ask questions, dig deeper into a topic, and I usually learn better while trying things out myself ! And the organizers (Pratik and Vincent) are really great hosts, the conference is very welcoming !