Note: In this blog, the term “technology” is interchangeable with “framework” as the same principles apply.

I am currently working at Ticketmaster helping in a large scale Agile transformation and Platform migration.  About seven or eight months ago we started looking at new and improved ways of creating services instead of the tried and tested Spring framework based approaches common in the organisation. The Spring framework certainly has its merits and we have used it with much success, however, the service we were about to write, called Gateway, was to route millions of requests to other services further down in our architecture layers:

We knew that the service had to run efficiently (thereby saving on hardware) and scale effectively. The event driven, reactive approach was one that we were looking to embrace. After much research we had some concerns. Not only is that space full of different frameworks at different levels of maturity, but we also had to consider our current skill set, which is predominantly Java with a small amount of Scala, Ruby, Clojure (which our data science guys use) and a handful of other languages we’ve picked up through company acquisitions. How could we adopt this new paradigm in the easiest possible way?

What this blog post will detail is the approach used to select the chosen framework. It’s a tried and tested approach I’ve used before before and will continue to use and improve upon in the future.

How we did it

Before we describe the stages of what we did, suffice to say that there is no point in doing a technology selection without a business context and an idea of the service(s) that technology will be used to build.

The technology selection was broken up into the following steps:

• Identify principles – these are the rules that the technology must adhere to. They are properties that a technology can meet in different ways and contain a degree of flexibility.
• Identify constraints – these are rules that cannot be broken or deviated from in any way. If any are broken, the technology is no longer a candidate.
• Create a short list of 5 – 10 candidate technologies.
• Determine high-level requirements and rank using MoSCoW prioritisation
  • Read the documentation, Google groups and other relevant articles and trend data to determine conformance to the requirements, including all options and workarounds if applicable.
  • If any of the Musts are broken by a candidate then it is dropped.
  • Create a short list of, ideally, at least three candidates (I’ve found three is generally a good balance between variety and available time to go into depth, though you can modify this depending on the criticality in your stack of the technology being chosen).
• Create a second set of more detailed requirements, rank using MoSCoW and weight in terms of importance
• Determine the architecturally significant business stories and error scenarios that the service to be built from the technology needs to implement:
  • Write the end-to-end acceptance tests for these stories. The primary scenario with one or two error scenarios is sufficient.
  • Implement these end to end acceptance tests in all three technologies – this will give an idea of how well the technology meets the service’s paradigm(s), how easy it is to work with in the develop/test cycle and also make sure to post on the message boards or mailing lists to see how quickly a response arrives from the maintainers.
  • Update the second set of more detailed requirements with the results of this experience

Our results are pretty detailed so have been added into a separate PDF that you can download here. We have left this in raw format and hope that they will be a good reference for others.

Outcome and experiences to date

As you can see from the PDF of results, we chose Vertx. It won out not only because of its raw power, but because of it’s fantastic architecture, implementation, ease of use, Google Groups support and the fact that Red Hat employs a small team to develop and maintain it. Indeed, a few weeks after we selected it, it was announced that Red Hat hired two more engineers to work on Vertx.

So overall we have been very happy with our selection of Vertx. We had version 2.1.5 running in production for several months and recently upgrade to Vertx 3. The maintainers’ swift response on the Vertx Google Group definitely helped during our initial development phase and during the upgrade to version 3. Performance wise, the framework is extremely fast and we know that any slow down is most likely due to what we have implemented. Adoption has been a success. From a team of two developers, we scaled to four and now eight.  It is also starting to be used for other services.  Choosing a Java based framework has been a boon as the only additional complexity that needed to be learned by the developers joining the team was the event driven nature of Vertx (i.e. the framework itself). Had we chosen Scala/Play it would have been much harder. Indeed, with the success of Vertx, our decision to standardise on the JVM as a platform and our embracing of the reactive approach, we have a couple of services being built using Scala and at least one using Scala/Play. It would be great to hear of your experiences using reactive frameworks. Which ones did you choose? How easy were they to adopt? Please leave a comment, below.

Note: This is a slightly modified cross post of a blog that originally appeared here.