Posts

One line that rarely fails: Data Platform Engineers build the river and its locks; Data Engineers pilot the boats that carry business value down that river. The hospital at the edge of town Imagine a new hospital going up on the edge of town. Before a single patient walks through the doors, someone has to bring power to the site, lay the pipes, secure the networks, set up the elevators, and make sure the fire alarms can wake the building at 3 a.m. if needed. Later, when patients arrive, doctors and nurses will triage, diagnose, and treat them - using that infrastructure as if it had always been there. ...

Microservices architectures promise flexibility, scalability, and agility in software development. But with this flexibility comes significant complexity—especially when managing transactions across multiple, distributed services. Today, let’s talk about the history of distributed transactions, diving deep into two powerful yet contrasting approaches: Choreography and Orchestration. Why Distributed Transactions? In the beginning, monolithic applications reigned supreme. Transactions were straightforward—everything operated within a single database, making transaction management relatively easy. But as software applications grew in scale and complexity, a single database was no longer sufficient. Distributed systems emerged, scattering services across various databases and networks, making the once-simple transactions suddenly intricate and challenging. ...

In the early days of software development, many teams measured the health of their applications through a single lens: logs that printed cryptic messages whenever something went wrong (or occasionally when something went right). Over time, as systems grew more complex and needs broadened, engineers embraced additional approaches, like metrics that could highlight performance trends and spikes. Eventually, logs and metrics alone were no longer enough. Distributed systems, microservices, containers, and orchestrators demanded a whole new way of understanding application behavior. This is how the idea of Observability started to take shape—an effort to see right into the beating heart of the system and know exactly what’s going on, without guesswork. ...

The day I first heard about event-driven architectures, I imagined a busy marketplace where each stall (service) would broadcast its daily specials (events), waiting for eager passersby (consumers) to snap up the deals. Over time, that humble metaphor soon expanded into real-world engineering decisions: do I rely on a queue-based system like RabbitMQ, or do I step into the realm of event logs with Kafka? Let’s explore these two messaging heavyweights and see why choosing between them often comes down to more than just performance metrics. ...

TL;DR Embark on a narrative journey through distributed systems to uncover the subtle differences between messages, commands, and events. Discover how these concepts weave into the fabric of microservices architecture, illustrated through a real-world e-commerce story. Learn to make strategic decisions for your projects without getting lost in technical issues. Introduction Imagine a robust marketplace where merchants, couriers, and town criers all play pivotal roles in keeping the economy alive. In this scenario, communication is key. Messages are exchanged, commands are issued, and news of events announced. This lively marketplace is a metaphor for distributed systems, where understanding the nuances between messages, commands, and events is crucial for building effective microservices architectures. ...

Preface A friend of mine recently asked for my consultation on creating a roadmap for them on how to contribute to a big open-source project like the Linux kernel. I took the chance and tried drafting a simple blog post of what I thought would be a good general guideline to approach such a task. Contributing to the Linux kernel can feel like an overwhelming challenge. After all, it’s one of the most complex and influential pieces of software in existence, powering everything from smartphones to supercomputers. But for those with a passion for Linux and open source, becoming a contributor is not only possible, it’s incredibly rewarding. Whether you’re looking to improve your knowledge of operating systems, sharpen your coding skills, or simply give back to the community, this guide will walk you through the steps you need to take to make your first contribution to the Linux kernel. ...

Introduction In the ever-evolving landscape of software development, tracking changes to data is a fundamental requirement. Whether for auditing, debugging, compliance, or analytics, maintaining a history of changes enhances transparency and accountability within a system. Two prevalent approaches to capturing these changes are storing a change log and using event sourcing. While they share common goals, they differ significantly in implementation and suitability depending on the system’s needs. This blog post delves into the similarities and differences between change logs and event sourcing, assesses their applicability through practical examples, and provides guidance on choosing the right approach for your system. ...

If you’re anything like me, diving into a new and unfamiliar codebase can feel like being dropped into a dense forest without a map. Whether you’re joining a new team, taking over a project, or just exploring an open-source project, understanding its nature, purpose, and architecture is essential. Let me share how I tackle this challenge, while giving examples using C# and .NET projects. Lets dive into the process… Initial Assessment Before I dive headfirst into the code, I take a moment to understand the broader context. The first thing I do is find and read any available documentation.This can include README files, wikis, inline comments, and API documentation. These resources often provide invaluable insights into the project’s purpose, setup instructions, and usage. I always try to get a sense of the project’s primary objective —whether it’s a web application, a library, or a microservice— because understanding the scope helps in setting the right expectations. ...

The professional path of a Software Solutions Architect I’ve been working in software for more than 12 years now. I’ve been doing help desk stuff, database management, IT work, networking, low-level and high-level programming, hacking and penetration testing and everything in between. All these experiences and upportunities that I have had, helped me becoming me more well-rounded engineer which is a cruitial attribute to have if one wantes to embark on the mission to becoming an architect, specially a Solutions Architect. ...

It’s customary to write a Hello World! app when one starts to familiarize oneself with a new language / framework. So I’ll start my journy with the same approach in the most famous esolang, AKA brainfuck. -[------->+<]>+++.-[--->++++<]>+.[--->+<]>---.[---->+<]>+++.---[->++++<]>.------------.---.--[--->+<]>-.[->+++<]>++.++++++++++.+++.--------..++.+++++.-------.-[--->+<]>--.[->+++<]>++.+++.++.++.+++++.>++++++++++..[->+++<]>+.--[-->+++<]>.[--->++<]>++.--[-->+++++<]>.-----[-->+++<]>.--------. Oh BTW, you can find the output here.