Few weeks ago, my employer, CN Group, sent me to one of the major Java conferences out there: Devoxx Poland. It was my first purely software engineering conference I’ve been to (I am not counting my presence at Prague’s Oracle Code, as it was rather a selling event and my attendance at Mining Software Repositories conference in Florence in 2015 was rather academia related) and most of the talks I’ve seen were actually quite interesting for me.
In this post, I am going to try to summarise the most interesting presentations I’ve heard, including some of their main takeaways. The order I wrote them down respects the order on the original schedule.
Welcome to Devoxx
SPEED WITHOUT DISCIPLINE: A RECIPE FOR DISASTER (VENKAT SUBRAMANIAM)
The whole conference started with an opening keynote by Venkat Subramaniam. As is the case of the most of the similar keynotes, even the topic of this one was rather general and from my point of view, most of the talk was not actually really relevant to the keynote title. Venkat stated, that current programming world is moving from imperative programming (writing everything ourselves) to declarative programming (relying on frameworks and libraries) and from that, using some very nice methaphores, he moved to automated testing.
Main takeaway: Rely on automated tests, they will really save you from hidden bugs and spare you a lot of time.
Consumer Driven Contracts and Your Microservice Architecture (Marcin Grzejszczak, Josh Long)
You can expect a lot of talks about Spring framework at a Java conference, right? Well this was one of the best of them, with famous Spring enthusiast Josh Long and Marcin Grzejszczak. The whole talk was about a tool called Spring Cloud Contract, which actually enables you to specify API interfaces between two services. Of course, there are already technologies like this out there (hello, WDSL?), but these contracts also try to address an issue with testing. If you ever wrote an application consisting of two, let’s say, “microservices”, you probably ended up with mocking one of them to unit test the other. Spring Cloud Contract can solve this issue, because these contracts (written in Groovy) not only specify how the API looks like, but it also creates a stub for the API and you can unit test your application directly against this stub.
Main takeway: Spring Cloud Contracts might be a very convenient way how to specify APIs and test integrations.
Four Distributed Systems Architectural Patterns (Tim Berglund)
I would describe this talk as a very good introduction to distributed systems, Tim Berglund talked about four basic patterns and evaluated all of them in terms of scalability, hippness (or coolness) and difficulty to understand and master. First pattern was modern 3 tier, which is basically classical 3-tier pattern, but each of the tiers is scallable (e.g. Cassandra as a database…). Second pattern was sharding, which is e.g. quite common solution to data centers and which basically shards and replicates your application into chunks and a router leads every request to your app to the right chunk. Third and fourth patterns were Lambda and Streaming. I decided to put them here together as they both follow similar principles like functional or reactive programming and they both leverage tools like Kafka.
Main takeaway: None of the architectures is the silver bullet, for each use case one could be better than another. Generally, streaming architecture was perceived as the best, but also as almost the most complicated.
Cracking the Code to Secure Software (Daniel Sawano, Daniel Deogun)
Securing a software is always a hard thing and Daniel Sawano and Daniel Deogun in this talk recommend some “security design patterns” which can make an application more secure from the beginning. They suggest using domain primitives, which are immutable types in your domain – e.g. you should never use just int or String to represent some value of your object, you should always wrap it in an immutable domain type. Another related pattern are entity snapshots, which basically allow you to immutably represent a mutable entity. The authors then recommend few ways of dealing with legacy code, e.g. adding a new layer between new and legacy system, which will translate all types into domain primitives. They also recommend to tackle security issues with testing, and stress out not to forget on boundary testing and extreme testing. In the end of the talk, they also warn us about upcoming threat: Domain DoS attacks, which are basically attacks which follow the terms of service of your application. An example of such an attack might be an Uber competitor reserving and then cancelling all available Uber cars in a city.
Main takeaway: Use immutable domain primitives wherever possible. (Too bad for all of us Jackson users out there). Test.
Topics summary
I would describe this talk as a good introduction to how GIT version control system actually works, with some really nice do’s and don’ts. If you are not familiar with the architecture behind the GIT, you should definitely check out this talk. Lemi also presents several anti-patterns of GIT usage, starting with infamous “If you use GIT as Dropbox, then just use Dropbox” and following with branch highways, long living branches, etc. For me, the most important takeaway (which you see below) could be summarised like this: commit often to your feature branches and don’t worry, if the code is not working (or even compiling). Once your work is done, perfect it by squashing it to single or several commits and when all your tests are passing and everything is working, you can push your work to others.
Main takeaway: Commit early, commit often, perfect later, publish once.
Fostering an evolving architecture in the agile world (Roy van Rijn)
This talk belongs to the category of “lessons learned” presentations and I found it very amusing. In the talk, Roy van Rijn is introducing a system for Dutch government company, which is managing the port of Rotterdam, one of the largest ports in the world. I’ve spent more then a half a year just 30 kilometres from Rotterdam, so I was especially interested in this one. The story of the system starts in the beginning, where dozen of system architects were hired to design a perfect system, only to have all their work thrown out month later. The talk is a good advocate of using agile methodologies, as those worked much better than a waterfall solution failed to be delivered by these architects. The team working on the system also adopted the microservices architecture lately, so you can hear some lessons learned from this tech area as well.
Main takeaway: Do not blindly follow SCRUM rules, architecture standards, adjust to needs of your own system and team.
Spring Framework 5: Themes and Trends (Juergen Hoeller)
Another Spring Framework talk was given by its project lead himself, Juergen Hoeller and was aimed on the new version, which should be airing “soon” (but was again delayed, even though mostly because of the delay of JDK9 — however, RC3 is already available). The talk introduced the most important new features in the framework, starting with Spring Webflux, which enables you to program your application in a reactive functional way, bringing better performance under high load (you have to use reactive-enabled datastore, e.g. MongoDB or Cassandra). Spring 5 also brings support of Kotlin language from guys at JetBrains, which is getting a lot of popularity these days. There are also some improvements in the Spring core, such as @Nullable annotations on all method parameters, which can be null, which should increase your ability to understand the framework code. Last, but not least, the whole framework is now written in Java 8 internally, which makes mostly the framework developers especially happy. Spring 5 is compatible with JDK 9 as well, though.
Main takeway: Spring WebFlux might be the next big thing in the Spring world?
Betting on performance: a note on hypothesis-driven performance testing (James Lewis)
This extraordinary talk introduced a scientific approach to develop software, which is based directly on generally known scientific method. It can be summarised into the following principle: when you are developing software, sooner or later you get to a point where you have to make a choice how are you going to proceed next. It can be a decision about which technology to choose or which algorithm to use. That’s where the scientific method comes in, you can actually make hypothesis about these different options, basically bet on some of them and later compare their performance. In nature, you would perform an experiment and compare it with your hypothesis, in software, you can actually implement both (or all of the ) options and compare their performance. If you have time and resources for such an approach, that is of course completely different question…
Main takeaway: When dealing with performance, you can implement multiple options, measure performance and decide what’s better.
WebAssembly (Brian Sletten)
I was quite curious about this talk, because WebAssembly is getting quite an interest from tech guys these days. WebAssembly is basically a portable format for running compiled apps in the web, and so far, most of these apps are in C++. That’s right, C++ apps right in your browser. And they seem to be blazing fast. You can find some really nice 3D games using this technology on the internet. As I wrote, the technology so far is closely related to C++, which is not really my area of expertise, but in the talk, you can find the nice introduction to how it works, what are its basic formats, etc.
Main takeaway: WebAssemly: the next big thing for the web or just a hype?
Microservices – The Naked Truth Of The Maintainability (Jakub Kubryński)
Speaking of hypes, let’s finish with a talk about microservices. Microservice architecture is also quite popular these days, because all of the big players like Netflix are doing it, but of course as everything, such an architecture has its pros and cons, which are nicely summarised in this talk. It actually made me realise, that micro does not necessarily need to mean small. A properly designed microservices can still have e.g. 50k LOC. In the talk, Jakub also emphasises, that when you are using microservices, you also need to take advantage of proper tools, like circuit breakers, monitoring and automation and infrastructure as code.
Main takeaway: When using microservices, use circuit breakers, monitoring and automation and infrastructure as code and other tools.
That’s it, see you at Devoxx next year?
For our Java Competence group in CN group, I prepared this summary in form of slides, which you are free to check out or use as well.
Comments are closed