Vert.x Zero Up?

Vert.x Zero Up?

Regarding my former post, Vert.x Boot, I was told that there is actually a similar project rising:

Vert.x Zero Up is apparently flying mostly under the radar, at least I have not heard anything about it yet. So it is time to check it out, I don’t really have time to play with it right now, but maybe I can see from the docs if it is going into the direction that I want to go.

import io.vertx.up.VertxApplication;
import io.vertx.up.annotations.Up;

public class Driver {

    public static void main(final String[] args) {;


That seems close enough to what Spring Boot is doing. I’m just wondering where the @Up annotation is needed for. Also using the io.vertx package namespace is a bold choice.

In my imagination that would be more like:

public class Application {

    public static void main(final String... args) {
                 .withResources(UserResource.class, AvatarResource.class)
                 .withModules(SqlDatabaseModule.class, RedisModule.class)
                 .withModules(BusinessLayerModule.class, DaoLayerModule.class)


A clear entry point for the application, that shows you what kind of features are used and what the structure of the application is.

I definitely don’t understand everything that Vert.x Zero Up does, apparently there are multiple modes to run an application, they all look the same code wise but require differnt YAML configuration files. It comes with JSR 311 support, which seems to be a custom implementation, something that would come for free when using Vert.x Jersey. There are some nice additions though, it allows @StreamParam with Vert.x own Buffer class, it requires some custom annotations though, and does classpath scanning, something that I’d really love to avoid due to startup performance reasons, we want to have micro services after all.

There is an interesting concept in there about offloading event loop work to worker threads with annotations (@Address) via the Vert.x event bus. I’m not a huge fan of this implicit coupling, that might get out of hand quite quick. On the other hand we are talking about micro services, so there should only be some of those bridges in any given service. I’m wondering if someone could achieve something similar that is transparent but still uses one given rx2 flow that would be easier to follow.

In general I’m pretty amazed of the amount of documentation there is, that is pretty good. Though a lot of it feels somehow generated or auto-translated but it is pretty excessive.

JSR 303 is supported, but only inside the system and not for request objects as far as I understand the documentation. I think that would be an essential part.

I still need to check if all the JSR 311 and JSR 330 support is custom, because I strongly believe that one should use existing libraries for that, otherwise maintenance will be a hell. From what I see from the docs it looks like that, because there are given limitations e.g. for JSR 330 as everything is a singleton.

I will play with it for an afternoon, but from what I’ve seen so far I want to go in a different direction and thus it may be still worth to spend some time to build a prototype of the framework I imagine.

BTW, I’m still looking for a good name for Vert.x Boot that does not collide with Vert.x and Spring Boot.

Vert.x Boot first step

So, I happen to find myself with a lot of free time at my disposal. Having spent the last three years head-of-teching in a startup I also have finally the time to think about the technologies we used, the shortcomings, the pitfalls and what I would do different on the next project.

Turns out that I really fell in love with Vert.x as a technology, Java 10 and RxJava2. As you still can see on GitHub we build an awfull lot of components around that. Vert.x is just blazingly fast and easy to understand, RxJava makes for nice reactive streams and modern Java is just fun to work with.

We also had a couple of Spring Boot services, mostly for simplicity and the hype four years ago. In general Spring Boot brings a lot of features, most of them you don’t need or don’t know. It is also quite slow when it comes to startup, in a container, on a VM, in the Cloud.

Now, while I am wondering what to do next and what to do in general I started wondering what I would do knowing what I know now.

We mostly used a stack based on Vert.x, RxJava (sadly 1.x) and Vert.x Jersey. We glued it all together with a couple of abstractions over Verticle deployment and got our own nice stack this way.

Things I would (and have done with newer services) is using RxJava2 as well as replace HK2 with Guice. HK2 is nice but also slightly inferior to Guice in my opinion. For some reason HK2 is not that well maintained, as of last week there was still no support for Java 10 in a released version.

And now I am wondering if I should take this whole stack to a new level and build something like Vert.x Boot, a system that easily lets you bootstrap Vert.x microservices for a variaty of use-cases with the following features:

  • Easy to use bootstrapping process like Spring Boot has
  • Guice as CI and general application configuration approach (I strongly believe in using code for as many things as possible)
  • Vertx-Jersey as a general REST/JAX-RS abstraction
  • Metrics and Prometheus integration out of the box using Micrometer
  • Defined readiness and liveness probe patterns (health checks)
  • Very good RxJava2 integration
  • Minimal dependency footprint that is easy to upgrade in order to follow Java’s amazingly fast upgrade cycle
  • Some well defined testing and containerization patterns (we all build images now, no?) that make it easy to build “golden” images, maybe using Testcontainers

On top of that there should be some modules to integrate with commonly used data layer services and provide the infrastructure that you usally use around that, like connection pooling and schema migrations:


  • I really like GraphQL, so something that would abstract around GraphQL Java to build easy to use GraphQL endpoints would also be nice
  • I’m not so sure about my feelings about Jigsaw and the way the Java eco-system is going, but having a good way to work with modules would also be a bonus.

I used to say that Java is not a great fit for Microservices because of memory usage and startup times, but with this stack it might actually make sense. I haven’t yet figured completely out how low you can go, but with a very low old-gen baseline and requests that always run only in your young-generation you can actually run those things with a very small memory footprint.

Maybe that is something to fill my time with once the summer ends.

Berlin Buzzwords 2015 – Day 2



It’s All Fun And Games Until…: A Tale of Repetitive Stress Injury (Eric Evans)

Basically, watch out for yourself. If it hurts, you are doing something wrong. It’s good to be reminded about that from time to time. So, watch out for yourself:



A complete Tweet index on Apache Lucene (Michael Busch)

Michael Busch has given this talk in one version or the other for a couple of years now. Unfortunately it got more shallow now, not so many technical details about how they optimized Lucene for Twitter. Numbers are great, they have two billion queries per day and about 500 million tweets per day. One thing that he didn’t mention in his earlier talks is that they actually figured that Earlybird does scale to Twitter level requests due to the Earthquake in Japan when they had to emergency shutdown the caching layer in front (which was Ruby on Rails and did not scale that well). Nowadays they have all tweets in a pretty vanilla Lucene with some additions (going to be open sourced soon) and use a Mesos cluster in case they have to reindex all the data.

And BTW: Tweet IDs encode the timestamp the tweet was send at.


Automating Cassandra Repairs (Radovan Zvoncek)

First time speaker Radovan did a pretty good job. Apparently there are several ways to get to the “consistency” of the “eventual consistency” in Cassandra, which are Read Repair, Hinted Handoff and full blown anit-entropy repairs. The latter ones apparently can lead to a lot of problems if done improperly, so Spotify build something to manage that: Reaper.  The problems are usually due to disk IO limits, network saturation or just plain full disks. Spotify Reaper orchestrates anti-entropy repairs to make them reliable.

I’m still somewhat confused that one aparently has to spend a lot of time repairing Casandra clusters. I always thought that was what Cassandra was doing.


Diving into Elasticsearch Discovery (Shikhar Bhushan)

For all the people who forgot, like me, how ES clustering works this was a good reminder. Plus I learned that discovery is pluggable, so you can write your own plugin to provide the clustering part for ES. He apparently did and wrote Eskka, an Akka based clustering approach. Writing your own apparently isn’t that much fun because APIs change all the time. Just in case you forgot, Zen is the default way ES clusters.


Change Data Capture: The Magic Wand We Forgot (Martin Kleppmann)

We all know the problem Martin was describing: same data in different form, like in your database, in your cache, in your search engine. He went back to the “Change Data Capture” principle, which basically says “save once, distribute everywhere”. So in order to realize that he wrote a PostgreSQL plugin “Bottled Water” which gets the changes from Postgres and posts them to a Kafka topic. Yay for the best project name this year in the category: will never find that on google.

His implementation and idea is solid, the problem is that it is a Kafka topic per table, so you actually loose the transaction when reading from Kafka. Otherwise it is transaction save, messages are only sent when the transaction in Postgres commits. He uses Avro on the wire and transforms the Postgres DDL Schema to an Avro schema.

If you want to get your transaction back you would need a stream processor (Storm/Spark) downstream to reassemble your transactions. Might be a good idea if you already have a Postgres DB or rely on some special properties of a centralized Datastore, otherwise it is OK if your microservices write directly to Kafka.

Has someone actually coined the word “nanoservices” yet for designs that basically do just one thing? Like take the request, write it to a queue (Kafka) and all other processing taking place by consumers down the queue that do just one thing as well.


Designing Concurrent Distributed Sequence Numbers for Elasticsearch (Boaz Leskes)

Elasticsearch is rewriting the way they do distributed indexing based on the Raft Consensus Algorithm. Sounds great, they are mitigating a lot of problems they do have right now.


Apache Lucene 5 – New Features and Improvements for Apache Solr and Elasticsearch (Uwe Schindler)

Apparently, Lucene 4 broke a lot of indexes due to it’s build in backward compatibility to Lucene <=3. With two big companies actually relying on Lucene, that kind of amazes me.

Lucene 5 gets rid of all this legacy stuff and drops support for older indexes. Plus it adds a lot of data safety features when it comes to on-disk indices like checksums and sequence numbers. So, Solr and Elasticsearch should finally be production ready …. ;).

JDK seems to keep breaking Lucene (remember that the initial JDK 7 release broke Lucene?), apparently one should not use G1 GC with Lucene (es? Solr?).

And Lucene 5 uses a lot of the “new” JDK 7 APIs for IO to finally get the index safely to disk.



Real-Time Monitoring of Distributed Systems (Tobias Kuhn)

Less distributed, more of Real-Time monitoring. Apparently they build their own system for analyzing their loggs for anomaly detection, punnily named Anna Molly, which was open sourced now.

They made pretty clear that thresholds are not enough if you have a highly dynamic system that can change on multiple dimensions any time. Seasonality of your date makes it even harder to define useful thresholds. There are a couple of algorithms which can be used for anomaly detection, namely Tukey’s outlier detection and seasonal trend decomposition. And T-digest comes to the rescue of course.

For monitoring they actually use a cascade of statsd and carbon.


To sum up bbuzz 2015:





Berlin Buzzwords 2015 – Day 1


Analytics in the age of the Internet of Things (Ludwine Probst)

Basically a talk about analyzing a demo dataset from sports activity via Spark. Not so much new stuff in there, but beautifully manually illustrated slides.

Real time analytics with Apache Cassandra and Apache Spark (Christopher Batey)


Good speaker, awesome talk. Some takeaways:

  • One should read the dynamo paper
  • You can (mis)use the datacenter awareness of Cassandra for isolating workloads if you run spark on top of it.
  • 500ms is the lowest usefull microbatch length

Application performance management with open source tools (Tudor Golubenco, Monica Sarbu)


Packetbeat, which apparently just joined Elastic, is a TCP Layer application monitoring solution. So what they basically do is understand your protocol (HTTP, Redis, Postgres) and give you metrics directly from the traffic (how long did my HTTP request take?). Sound really interesting, as it doesn’t need any integration. Will be integrated into the ELK-Stack and get some more data providers. I really like the idea.

Practical t-digest Applications (Ted Dunning)


t-digest is an algorithm to get realtime quantiles/percentiles out of your data. That comes in handy if you want to have the data always at your fingertips and/or want to identify outliers. It is blazingly fast and needs constant memory, so you actually want to have it wherever you have numbers. Of course there is a Java-Library and an integration into Elasticsearch. Awesome speaker as well.

The Do’s and Don’ts of Elasticsearch Scalability and Performance (Patrick Peschlow)


Basically a long reminder to RTFM. Know what data you need, now the pitfalls, disable features you don’t need and make sure that your cluster setup fits your requirements.

Detecting Events on the Web with Java, Kafka and ZooKeeper (James Stanier)


Good speaker, I think they build quite interesting stuff at Brandwatch. It was not clear to me till the end why the built all that stuff themselves, but I think they co-evolved with Storm/Spark and just made their existing software cluster aware rather than rewriting the stuff.

Reminded me that there is Apache Curator, a set of high level abstractions for Zookeeper services (

Analyzing and Searching Streams of Social Media at Scale using Spark, Kafka and Elasticsearch (Markus Lorch)

IBM is using Spark. Basically they got a pretty standard setup to get a lot of data from Twitter and enrich/augment that with some of their proprietary tech (mood detection etc.). Nothing special here.

Predictive Insights for IT Operations (Omer Trajman)

Actually a pretty good speaker, but I didn’t really get the whole point. He basically explained that you should use the same big data techniques for analyzing the data that comes out of your operations measurements (and btw, he has a company specializing on that). But it wasn’t a sales talk. So basically, yes, analyze all the data.


code.talks 2014 – Tag 2

Machine Learning mit künstlichen Neuronalen Netzen und Clojure
Stefan Richter
Recruiting @fdc 😉

Datengetriebene Analyse und Verbesserung von Code
Andreas Dewes

Die Jungs fahren einen interessanten Ansatz, leider aktuell nur für Python.

Code und Gesellschaft – macht was draus!
Nico Lumma

Guerrilla software design: doing it wrong and getting it right
Marco Cecconi

Predictive Analytics zum Schutze der Liebe
Mario Selk

Die haben bei Parship das interessante Problem der Scammer. War ein sehr unterhaltsamer Talk.

Handgranaten für die Developer
Nils Lauk

code.talks 2014 – Tag 1


Elasticsearch Lessons Learned
Patrick Peschlow


Marvel is a management and monitoring product for Elasticsearch. Daraus das Sense UI als Elasticsearch Client.

Percolator sind gespeicherte Suchen.

Immer Aliase für Indexe benutzen.

Plugins kennen.

WebAPI – expand what the Web can do today
Carsten Sandtner

XTags (?) Mozillas Implementierung auf Web Components, wie Polymer

Contacts API
Settings API
Vibration API
Alarm API




Modern Web Application (In-)Security
Fabian Beterke, Felix Schmidt

Im Westen nichts neues. Bei PHP auch nicht.

Introduction to CoreOS
Timo Derstappen

Github ist eine Public SSH Key Registry.
etcd, flannel, fleet, locksmith for update management

Hamburg Geekettes – Lightning Talks
Diana Knodel, Uygar Gomez, Lisa Junger, Tina Egolf, Inga Halpin, Eshani Sarma, Tina Umlandt
image – Plattform for part-time entrepreneurs

Schluss mit Copy & Paste! Design Pattern automatisieren mit Xtend
Sebastian Zarnekow, Sven Efftinge

Active Annotations – write code that writes code. Nice. Ich hab echt Lust bekommen noch mal Xtend eine Chance zu geben. Ich mag halt kein Scala.

Distributed Ad hoc Real-Time Stream Processing
Christian Kreutzfeldt

OTTO hatte ein Problem dem sie mit Kafka, Storm und Stanza nicht beikommen konnten und haben sich selbst was gebaut. Das heißt wohl ASAP. Das wird wohl bald (asap) Open Source.