Two weeks ago I had an opportunity to participate in a Devoxx UK conference as one of the volunteers. For those who don’t know, Devoxx is a family of conferences organized around local Java User Groups. That means they have a very strong community feeling, affordable prices and great speakers from communities around the world. If you are looking for a conference which is organized with software developers in mind, then Devoxx is a place to go. Devoxx UK is closely associated with London Java Community (LJC). That means many LJC members are involved in the organization of it. For me, taking the part as a volunteer was a win-win situation. I have offered my time for free to help run the event, and in return, I could attend sessions for free. It was also great opportunity to meet with old and to make some new friends. I think that this is a beauty of Devoxx - people are open and friendly, and the majority (if not all) attendees are passionate about the technology.

Devoxx UK 2018 means 3 days packed with sessions which cover a great range of topics, given by some of the best speakers. Below paragraphs are my view on these 3 days, and I have to say that this time was very well spent.

Day 0.

1. Nathan Shutta “From Developer to Architect”

This session was 3 hours long, but I was not bored even for a minute. Nathan has provided greater and deeper insights into work of Software Architects. The session has been split into 2 parts separated by a practical exercise.

The first part was focusing on what an Architect’s job is and what skills are required for it. Many Software Developers think that becoming a Software Architect is a natural, next step in their career. But this position requires a specific set of skills and personal attributes to become successful. Software Architects are responsible for the direction of projects. It is an Architect’s responsibility to let members of their team make right choices based not only on technical requirements but - maybe even more - based on business needs as well. It means Architects are involved much more in politics, they need to influence others, and it is expected from them to attend many more meetings.

The second part was showing what the Architect’s job is not. Architect writes much less code as it is not his day to day job. Even if an Architect decides on project direction, he is not as free as it looks into this matter. There are many factors which will affect his choices and a successful Architect needs to judge what is important and what is not for the business, for the project, and for his team. So yes, Architects are decision makers, but with a greater power comes a greater responsibility as their decisions affect more people.

The practical session was about project requirements. Nathans shares approach that a practice makes perfect and the best way to practice is by small exercises known as katas. As a source of katas we have used architectural katas from nealford.com where we could pick one scenario and provide requirements for it.

I have a great time during that session. Nathan definitely is an experienced Architect and a great speaker at the same time. The talk has many great advises but my favorite is that a Software Architect career is not for everyone. Our industry needs experienced developers who are just that, very good at writing the code. If you don’t like meetings, if you are not good at office politics, then maybe this is not a career path for you?

2. Nathan Peck & Brent Langston “Kubernetes on AWS Hands-on Workshop”

I was really hyped for this workshop as kubernetes on AWS (with kops) is exactly what I’m doing now at work. I was aware that this will be an introductory workshop, but I hoped that I will learn something new, or I might find that there is a better way to do things which I’m doing already. But sadly, the session disappointed me for a couple of reasons:

1. During the presentation ReplicationController has been used to control application Pods. Using ReplicationController is “deprecated” and has been replaced by Deployments many months ago. This was a 1st warning flag for me.
2. I don’t know why, but when I attend any talk run by folks from Amazon Web Service I feel more like I’m on a sales presentation than on a technology session. I have a feeling that AWS wants to sell me something. Unfortunately, this was also the case with this workshop. To be more specific, I didn’t like pitching people to use a cloud-based IDE (Cloud9 I think). And no, I don’t think that it is superior to other editors. I’m using vim for editing k8s manifests and I’m happy with that.

Before I’d decided to leave the room (after around 40 min) I learned nothing new but I’ve seen enough that I was convinced that this is not the session for me. I was very disappointed :(.

3. James Gough, Kirk Pepperdine, Richard Warburton & Sadiq Jaffer “Performance Tuning in Production” (video).

I went to see this deep dive session instead, which had 3 talks related to the Java performance.

The first presentation from James titled “Optimizing Java: a brief tour of the JVM” was about the internals of the JVM, JIT compiler, javac, classloader and more. Historically, Java has earned the label that it executes slowly compared to languages like C or C++. But this is not the case anymore as the Java performance has been constantly improved over the years. JVM consists many mechanisms which are not visible for developers, but which make Java programs faster, often on par with C++ programs.

James has started with showing what is happening in javac compiler. And in terms of the code optimization, it doesn’t happen too much. However, a lot of clever optimization is happening inside of the JVM which has classloader, method cache, JVM interpreter. For example, JIT uses techniques like an inlining, a constant subexpression elimination, a dead code elimination or an escape analysis to make our code perform better at the runtime. Looking at the inlining, it provides one of the simplest tips how to make programs better. By writing short methods, which is generally a good practice (single responsibility). However, from the performance point of view, short methods can be optimized by the inlining. Generally, JVM is looking for common patterns which allow the optimization. Writing the code based on good practices only help to find these patterns.

Finally, James has introduced JITWatch. If you want to explore and understand what actually a JIT compiler is doing, then JITWatch makes it much easier by analyzing and visualizing JIT processes.

In the following talk “Tuning The G1GC” Kirk has focused on a “new” G1 (garbage-first) garbage collector (GC). I said “new” because G1 became a default garbage collector for Java 9+, but it is around since Java 7. The major difference between G1 and other GCs is that it’s designed to minimize GC stop-the-world pauses. With other GCs, these pauses can be very long for applications with a very large heap. This can affect business requirements. G1 tries to minimize GC pauses by performing collection along with your application (mixed collection). As a result, there is no need for a full garbage collection or their frequency are much lower. But this is not for free as it takes part of the CPU resources from the application. And we should be aware of this cost.

To make this change possible, the Java heap is now divided into segments of the same size (the sector size depends on a heap size) which can have assigned different roles (eden, survivors, old generation). This gives the advantage that each segment can be collected individually and if some segments are not collected during the recent sweeping period (-XX:MaxGCPauseMillis allows to set a target max time for the collection), their reclamation can be postponed until the next collection. This is, of course, a simplified view of the GC process, but Kirks talk dives more into details of G1GC processes. It explains what is happening during each phase of mixed collection and how G1 designers solved encountered problems.

Above two talks are about the internals of JVM on which every Java developer should have at least a basic idea. In my current position, this knowledge is very useful and these talks filled some gaps in my knowledge. And as my job requires from me to analyze a heap dumps, threads dumps or profiling JVM I get a lot from these talks. I can say the same about the last talk “Production Profiling: What, Why and How”.

In this presentation, Richard and Sadiq explained why profilers are important, and why they should be used in a production and not in a development environment. They expressed that recent profilers are suitable for use in the production. Historically profilers were expensive to use and some types of them still are. Their expensiveness means that they can have an impact on an overall system performance and as such, they can affect a result of the metric we try to measure. But there are profilers with low overhead, which can be used in the production. For Java, most known examples are Java Flight Recorder (JFR) and Java Mission Control (JMC) which, according to Oracle have a minimal (1-2%) overhead. Both have been recently open sourced by Oracle which means we won’t need a pricey license to use them in the production. Richard and Sadiq introduced also a Linux eBPF profiler. Sadiq was quite excited about it as an addition to more established and known perf profiler.

Having the tools is only a first step in measuring a performance of the system. Next, we need to measure right metrics and the right number of them. We need to be careful to not measure too little or too much. Too little and we won’t be able to hit where is the problem. Too much and profiling can have an impact on the system performance and became one of its variables. Or with too many metrics we will have too much data to analyze which again make hitting the problem difficult.

This year Day 0 has been packed with sessions which gives deep insight into topics. Very technical, but they were presented very well and in an accessible way which made them easier to consume.

Initially, I thought all 3 days would fit into this post. But covering only sessions I have attended during the Day 0 makes it much longer than I wanted. That means I will finish here and the rest will go to another post.