Just like last year, we headed off to London for the QCon software conference again in 2020. QCon targets software architects, team leaders and senior developers. In addition to the technology and talks, an undeniable attraction is the venue in the Westminster area, located just across the street from Westminster Abbey.
The conference lasts three days and has one great feature—it is basically several smaller conferences all in one. The whole event is divided into a number of day-long tracks, which are series of talks on the same topic. Each track has its own track host who takes part in the organization and accompanies those following the track throughout the whole day. Individual speakers often complement each other, sometimes even off the track (for example, the topic of microservice architecture got attention on several tracks). As a result, it is possible to delve into a selected area in great detail, or on the contrary, to choose only the most interesting of the various tracks. As the organizers themselves said: “Try to randomly visit at least one talk outside your preferred topic every day and learn something completely new”.
Every day, there were plenty of options to choose from—there were six editorial tracks, two sponsored tracks and, last but not least, an Ask Me Anything (AMA) track. One of the talks on each track was a typical panel discussion, where the speakers discussed a specific topic such as “Microservices—Are They Still Worth It?” The subject range was wide—from microservices, real-time streaming, the evolution of Java, machine learning, team leadership and interesting architecture to Kubernetes and much more.
The first day at QCon London 2020 was already really charged. In addition to the standard six editorial tracks, most of the day was carried out in the spirit of increased hygiene measures and we also tested (unplanned) the fire alarm (caused by a broken smoke detector on the second floor of the Queen Elizabeth II Centre).
But getting back to the editorial tracks, the main common denominator was microservices. Especially the practical examples were really interesting.
In the first talk “Monolith Decomposition Patterns”, Sam Newman, an expert in the field, emphasized that “Microservices should not be your default choice”, “Monolith is not your enemy” and especially “You won’t appreciate the true horror, pain and suffering of microservices until you’re running them in production”. He showed that microservices, in addition to their indisputable advantages, also have definite disadvantages that must not be ignored. However, as the author of a book on microservices, Sam did not only criticize them but also showed the advantages of the approach and most importantly many recipes, how with the help of well-thought-out incremental steps we can move from monolith to well-designed microservice architecture. It is also good to be aware of release trains that are too long, a situation where the final delivery packs more and more (reminiscent of a very long train that someone keeps adding more cars to) until a distributed monolith has been created instead of microservice architecture. What is a distributed monolith? To put it simply, it is architecture that looks like a microservice, but in fact is not— the application is distributed, but some or even most of the principles of microservice architecture haven’t been met at all. Some examples are poorly designed service distribution, deployment services that aren’t independent, services that are too interrelated, etc. In marginal cases, it is necessary to deploy all this architecture like this at the same time (which suppresses one of the primary advantages of microservices).
On a similar note, in her talk “To Microservices and Back Again”, Alexandra Noonan spoke about how they switched to microservice architecture in their system but gradually encountered difficult problems that led them back to the monolith. Some of the main reasons were operational overheads and problems with shared libraries.
In short, distributed systems are complex, even though they are sometimes underestimated and overlooked in the enthusiasm for microservice architecture. GitHub developer Denise Yu brilliantly and amusingly described this in her cat talk “Why Distributed Systems Are Hard”. Why cats? Denise is a great painter and a cat person, so all the slides featured wonderful cat illustrations. They confirmed that a picture says more than a thousand words. Look at how she illustrated the well-known eight fallacies of distributed computing.
It has also been confirmed that for microservices it is necessary to be aware of all the pros and cons, to have a strong and stable team, sufficiently mature infrastructure and leadership support. Then you can have 1500 microservices, as Matt and Suhail demonstrated in their talk “Modern Banking in 1500 Microservices”, or you can program an extensive sports betting system that places 25K bets per minute.
In the following days, we were most impressed by the tracks The Future of API and Building High Performing Teams. The opening talk “A Brief History of the Future of the API” already showed that an excellent speaker can present even an ordinary topic in an interesting and entertaining way, so almost every moment of the history discussed was accompanied by a pearl of wisdom. It is interesting how development often takes a step back. In its time, Corba was the mainstream standard with binary messages, then over time it became text messages, and then SOAP and REST became mainstream because it is important that humans can understand these messages, not just machines. Now, for efficiency’s sake, it often goes back to binary messages via gRPC and the like. Of course, this is just a funny detail, because each standard has its place and justification. On this track, most of the attention was directed towards gRPC, which is often recommended for high-performance inter-service or inter-application communication, and GraphQL, which, like REST, is often recommended for public web APIs.
Also the talk on smart API can definitely be recommended. It summarized in a nutshell how to write reliable and user-friendly APIs. To put it simply: what do you think the user would prefer to see in case of an error when booking a flight ticket—“We are sorry, an error has occurred. Close your browser, wait five minutes and try again (and if that doesn’t work, repeat).” or “We are sorry, an error has occurred, but don’t worry, your reservation has been accepted and you will soon receive your flight ticket via email.”?
Another interesting topic was “Deploy Does Not Equal Release”, which was about how deploying a system to production does not necessarily mean that we have already delivered the distribution, and why and how it is good to do testing in production such as A/B testing or feature toggling.
In addition to the main topics, we were also intrigued by an introduction to Kafka, which was an unconventional presentation. With the help of volunteers from the audience, the speaker demonstrated several basic algorithms that Kafka uses. And we liked Evolving Java and the tracks about Kubernetes.
Overall, we would give the conference an extremely high rating and would recommend it to anyone who is currently addressing any of the areas covered by the talks. The organizers and speakers did a huge amount of work, so we definitely recommend that you look at the individual topics and watch at least a few videos or check out the slides. (The public release will be within the next few months on the InfoQ website.)
Author: Štěpán Poljak
Consultant