Image for post
Image for post
Photo by Kevin Ku on Unsplash

In the first blog of the ‘engineers guide to event-driven architectures’ series we discussed how event-driven architectures can deal with complexity, how it provides agility and that there is massive scaling potential. It is my personal belief that every solution architect and software engineer looking to solve challenging problems at the heart of businesses, should be equipped with a proper understanding of event-driven architectures.

This blog series aims to help you build that understanding and make you aware of the new challenges that arise with event-driven architectures. Based on my personal experiences, absurd amounts of reading and watching a slew of tech talks on the subject I’ve collected what I believe to be the key concepts to know and clustered them in 6 topics. …

Image for post
Image for post
Photo by Pablo García Saldaña on Unsplash

Many big technology companies like Netflix, Uber and Spotify have moved from a monolithic architecture to a microservices architecture in order to successfully build and run complex systems at a massive scale.

Event-driven architectures are becoming increasingly popular in the microservice space due to the scalability potential as well as it’s adaptability. It’s a powerful architecture, but it does come with its challenges.

In order to help you determine whether it’s an interesting architecture for your next technology endeavor I’ve decided to write an in-depth series of blogs, called ‘the engineers guide to event-driven architectures’, that will cover topics like:

  • Different types of event-driven architectures and their…

Microservices are just one example of a technology trend that has been hyped up to be the answer to everybody’s problems

Image for post
Image for post
Photo by You X Ventures on Unsplash

The hype creates a dynamic of inflated expectations and excitement with business representatives and software engineers alike. In companies and teams where decision pushing is commonplace this often leads to rushed decisions, which likely ends in frustration and disappointment.

Business representatives, software engineers and other technical specialists should be freely exchanging ideas, discussing risks and doubts as well as challenging each other with strong mutual respect. Creating this culture takes effort, a sense of personal responsibility and proactiveness from all involved. …

At the beginning of the year, before the human malware breakout, an Italian engineer joined our team straight from university. She has a superpower. Randomness. Along the way I realized just how important randomness is in learning and building a team. Unfortunately, working fully remote is killing that randomness and with it a lot of benefits.

Image for post
Image for post
While randomness may not be the first superpower you would think off, it matters!

Why randomness matters

Being in a new country, a new company and having to rapidly prove yourself as an engineer in a complex environment with established teams. I can only imagine the roller-coaster that must have been.

When it comes to onboarding and learning, we rely on structure. We have a fixed set of onboarding content about the project, ways of working and the technology. There are fixed points in the development process like refinement, story sizing and pull requests where a lot of learning takes place. …

Let’s face it. Java is an ancient language that is struggling to stay relevant but is not suited for containerized microservices due to its big resource footprint and limited concurrency. Java is trying to catch-up, but was clearly late to the party. So late in fact that everyone already left for the afterparty. Where Java wasn’t invited to. The language feels old with its terribly verbose syntax. And engineers no longer care about learning Java.

Image for post
Image for post
The timeless meme from KC Green’s 2013 webcomic “On Fire” applies well here

Big technology companies like Netflix still use Java in their system, but they also use Node, Python, Ruby and Go. It’s a similar story over at Uber. It’s common for modern distributed microservice architectures to leverage multiple languages, also called polyglot, and pick those languages based on their unique ability to address a particular challenge that the system has to deal with. In a distributed world, there is much less need for a general-purpose language like Java that tries to do everything, lacks focus and doesn’t have a clear purpose or identity. …

There is a lot of things I like about Java, but its dated implementation of threads is challenging to work with when developing high-traffic microservices. Java threads are implemented as operating system processes, which makes them heavyweight in two ways: switching between threads is slow and their memory consumption is high.

Combine those heavyweight Java threads with the thread-per-request model that servlet based microservices use, and we arrived at the performance challenge for microservices in Java that that are deployed in high-traffic scenarios. Let’s explore why this presents challenges, and what the potential solutions are.

The thread-per-request model of Tomcat

The majority of Java microservices that expose an API are built with Spring Boot in combination with the Spring Boot Starter Web. This starter uses Apache Tomcat as the default embedded servlet container to capture incoming requests and Spring MVC to route those requests and build the API endpoints. …

Software engineering, as a culture, seems determined to sell each other on solutions based purely on some benefits, without consideration of context, complexity and cost. If you are not using complicated architecture pattern X or infinitely scalable message broker Y you are doing microservices wrong. So, contrariety to popular believe, engineers are better at delivering (one-sided) sales pitches than most think. All jokes aside, it’s problematic. It leads to over-engineered microservice architectures and it completely disregards the trade-offs, which becomes problematic for engineering teams who are not prepared to deal with those trade-offs.

A good example of this is the combination of the Event Sourcing and the Command Query Responsibility Segregation (CQRS) architecture patterns. Often presented as the silver bullet for solving many robustness, performance and decentralized data challenges that microservices architectures face. Yet there is hardly any talk on the ton of hidden complexity with these patterns. So, how do these patterns handle robustness, performance and decentralized data challenges? …


Oskar uit de Bos

Senior software engineer at Deloitte. Microservice specialist. Builds for the cloud. Deploys containers. Loves elegant and scalable code. And good architecture.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store