This year’s Devoxx was my first remote conference. I got my ticket back in December when that was the only option. A lot of people from Evojam went to Kraków instead. For me, FOMO kicked in at the moment they posted the first pictures. Here I was, sitting in front of my laptop all day, 300 km away from all the excitement.

To make the most of my situation, I set out to pay undivided attention to any talk I would go to. Back in uni, the best way for me to do that was to make a lot of notes. And so I did.

This way, I ended up attending the most tech talks I have ever listened to over three consecutive days. Looking back, there are three recurring themes that I found most appealing. 

In this text, I want to discuss three talks on the topic of software architecture.

Event-Driven Architectures Done Right by Tim Berglund

Tim made a brilliant remark about the state of ‘event-driven’ at the start of this talk:

‘We all agree that it is a good idea, but it seems everyone is building their first.’

Personally, I am in the process of building my second and soon I might be starting my third. Still, I am not 100% comfortable calling the outcomes ‘event-driven.’ All my attempts will surely look like my first to seasoned architects in the future. Simply because event-driven is a difficult architecture style to get right.

Tim discussed five sets of traps that burgeoning architects can fall into:

1. Failing to recognize situations in which events are not a good fit, like simple applications built by inexperienced teams.

2. Avoiding databases, mostly by favoring caches and even more elaborate constructs, like Kafka’s KTable.

3. Underestimating the importance of schemas because events on topics still need a known schema.

4. Tailoring events for consumers, which leads to messages that are too custom for multiple consumers.

5. Assuming that scaling will be easy, not recognizing the differences between storage and compute scaling, or scaling and elasticity.

Definitely a must-watch for anyone facing architectural decisions outlined above. Including developers working on distributed systems because having designated ‘architects’ should never be the only team members involved in architectural thinking.

The State of NoSQL in 2021 by Denis Rosa

Denis works as a Developer Advocate for Couchbase, which started as a fork of CouchDB. He knows a thing or two about the current database landscape. His talk was about a couple of myths about NoSQL database technologies.

In the first couple of years of my so-called career, I was also working only with relational databases. For my master’s thesis, I used a relational database to persist and query a graph structure. Writing SQL for combinations of possible triads of nodes was a tedious task that I remember to this day. I was too afraid to try anything other than relational databases and, at this point, I am not sure why.

Now I have worked with graphs as well as document databases in the past couple of years. I cannot imagine defaulting to relational anymore. I liked Denis’s point that there are many developers treating databases like black boxes. With JPA and Hibernate, it is possible to distance yourself from databases and not write much SQL by hand.

Some common myths that Denis discussed included:

‘JOINs are slow.’ 

‘No ACID transactions.’

‘NoSQL will replace relational databases.’ 

He talked about the interdependence between your model and possible technology-specific issues. If you embed objects in documents, you can reduce the number of JOINs. At some point, you will need some, and many NoSQL databases allow JOINs. If relationships are the core of your model, I would also consider graph databases. These store relationships instead of relying on foreign keys. Reliance on ACID guarantees also depends on your model. If you manage to only update one document in a transaction, the operation can be atomic in itself.

Denis mentioned certain risks with NoSQL that you should be mindful of. First, these technologies can be challenging to DBAs. Which is part of the reason for the growth in the popularity of DBaaS solutions. Second, migrating between NoSQL databases means rewriting the whole persistence layer. At Evojam, we had a situation where a move from Elasticsearch to MongoDB was necessary. I led the effort myself, and I agree with Denis that it can cause a considerable delay in project timelines.

My advice would be to look for inherent problems that database technology is causing early on. Don’t delay the decision to exchange it. Getting rid of such technological debts will pay significant dividends.

Discerning Granularity and Communication Tradeoffs in Microservice Architectures by Neal Ford

I looked up ‘discerning’ before joining the talk. According to Cambridge Dictionary, it means ‘showing good judgment, especially about style and quality.’ It is definitely a feeling I would like my own architectural decisions to evoke!

I read the first book from Neal and Mark earlier this year. I loved the number of topics it covers and the clarity of delivery. I then read ‘Building Evolutionary Architectures,’ which I also recommend. At the start of this talk, Neal mentioned another book coming. The subtitle is ‘The Hard Parts.’ This talk was about two ‘hard parts’: granularity and communication.

As always, Neal offered examples of many trade-offs to consider for architectural decisions. It was the first time I heard about the distinction between static and dynamic coupling. Static means how you wire things together, e.g. integration points or the libraries that you use. Dynamic means runtime calls, be it over HTTP or one method calling another.

In the spirit of architectural trade-offs, Neal spoke of two forces at play in granularity. ‘Disintegrators’ like rate of change or fault tolerance are reasons for finer granularity. ‘Integrators’ like database transactions or workflow choreography are why you want larger modules.

Neal’s classification of coupling characteristics seems very thorough and thus quite useful. He talked about three dimensions to consider: communication (sync/async), consistency (atomic/eventual), and coordination (choreography/orchestration). This gives us 8 possible combinations, each suited for different architectural drivers. Such diligence in architectural decision making seems exactly what many teams lack. I can’t wait to get my hands on Neal’s and Mark’s next book!

Coming up

Devoxx 2021 was an amazing event. I have many more talks that I want to discuss. In the next post, I am going to talk about three presentations on hard-learned lessons from three seasoned professionals:

Event Sourcing - what could possibly go wrong?

by Andrzej Ludwikowski

What I wish I knew when I started designing systems years ago

by Jakub Nabrdalik

The Effective Developer - Work Smarter, Not Harder

by Sven Peters

Stay tuned!