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…
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:
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.
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…
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.
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…
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.
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…
Senior software engineer at Deloitte. Microservice specialist. Builds for the cloud. Deploys containers. Loves elegant and scalable code. And good architecture.