Micromonoliths: scaling via sharding - part II

Micromonoliths: scaling via sharding - part II

In this post you'll find: how sharding can work (well) together with CQRS, what tricks can be used for re-partitiong data in live instances (w/o downtime) and why it's OK to use domain-related data in routing on API gateway This is the 2nd post in the series. The first post can be found here. Real life, hello? Let's consider 4 sample scenarios: SaaS HR system - used by various client-companies for their internal operations On-line marketplace - hundreds of vendors, hundreds of thousands of buyers Live-traffic map - geospatial data is collected from vehicles, anyone can watch (regardless of…

Read More

Micromonoliths: scaling via sharding - part I

Micromonoliths: scaling via sharding - part I

In this post you'll find: micro-monolith neo-evangelism :), great (video) example of premature system distribution hitting the fan ..., demystifying of microservice independence myth and what are X-centric systems. I hate blog posts, books or conf talks that focus on criticising only - it's far easier to b*tch on something than propose an actual solution to non-trivial problems. That's why after my recent post (on why microservices may not be an optimal answer to all of your growth problems), I'd like to re-visit an architectural pattern almost as old as Computer Science in general, in fact, a very under-appreciated one ... Sharding.…

Read More

This orchestra plays out of tune - microservice reality

This orchestra plays out of tune - microservice reality

By reading this article you'll learn that ... orchestra (like Emperor) is naked, easy problems sometimes get far more sexy solutions than the hard ones (so screw those), SOA is not dead, microservices in the wild tend to be grotesque & out-scaling can be achieved in several different ways. First of all, thanks for reading this :) I'm quite sure that at least 3/4 of potential readers have dropped off after seeing the word "microservice". And ... I don't blame them at all, I'm fed up as well. That's one of the reasons why I've written this article. Hello (microservice)…

Read More

How important is (really) Technical Excellence?

How important is (really) Technical Excellence?

TL;DR In majority of scenarios real technical mastery has a tertiary degree of importance - being just solid, playing it safe & avoiding accidental complexity is just enough until market gets very dense, interest reaches viral levels or competitive factor is about pure tech (very rare). Very few companies (excluding some unicorns) compete with just tech as their primary weapon - it's usually all about the product, idea behind it & how fast it has been delivered (before the competitors ...). Disclaimer: keep your seatbelt buckled up, we're going to get a bit controversial here & you may not like…

Read More

Looking for Code Forester(s)

Looking for Code Forester(s)

TL;DR This is a job ad. Not a typical one, but still. I'm looking for 1-2 .NET software engineers with an insatiate apetite for serious challenges. Job itself is about methodical tending to brownfield codebase, but not by firefighting, but applying mature development practices: convention tests, continuous inspection & feedback, re-modeling according to DDD principles, applying SOLID principles at small & larger scale. This is NOT about typical maintenance, but long-term, iterative transformation (conducted by several teams in parallel) & elevating whole (existing) platform to the next level - also in terms of technical excellence. This IS about being…

Read More

The awesomeness of Modular Monolith

The awesomeness of Modular Monolith

TL;DR Deploying 100 times per day is impressive, so is having 5k devs working in parallel on the same codebase, serving hundreds of thousands different API consumers around whole globe or handling fluently interest spike of several millions of new users due to world-scale news event. But there's a huge chance that these achievements are not really applicable to your problem / domain / enterprise, so don't mindlessly copy'n'paste approaches that have served the purpose of solving different issue with a silly hope that they can solve your local problems as well ... Our whole industry suffers from being totally mesmerized by…

Read More

Running with scissors - Dependency Injection

Running with scissors - Dependency Injection

TL;DR Good engineering requires high awareness even in cases that may appear basic & straightforward. So-called good practice, if overdone or applied incorrectly can be very detrimental & in the same time may appear completely innocent & harmless, making us look for problems' root cause elsewhere. Using DI/IoC containers is a great example here - when misused, instead of reducing the coupling & increasing the testability, they can over-bloat code, make it far more brittle & harder to grok through. Some time ago I've already committed a post about cargo cult in software delivery. It was mainly about…

Read More

Architecture in the Wild: Business Process Orchestration - part I

Architecture in the Wild: Business Process Orchestration - part I

.Disclaimer: by "architecture in the wild" I mean situations (I've personally encountered) where sheer reality surpasses known (& somehow theoretical) standards / patterns :) in a way that does not impose any obvious solution. It doesn't mean (usually) that everything is so utterly broken, in majority of cases these are completely valid scenarios. With a twist ;D. TL;DR - microservices, low coupling, cross-functional teams, continuous delivery: we hear these terms repeated like some kind of mantra. While in fact, many companies accesses their domain functionality via BPMs & their alikes - that seem quite perpendicular to these concepts. This…

Read More