.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
In 2016 pretty much every commercial software system built with modern tech is a distributed system. Yes, we all build distributed systems these days. Obviously, the term "distributed" is very spacious - I'm not saying we're all creating stuff like eventually consisted, sharded data stores (should be left to specialists who excel in these), but having 2+ layers of independently scaled, communicating processes in
It usually looks like this: there's already a decision about new product / project, people are extremely happy & eager to start straight away, silently expecting to "do it all perfectly" this time, avoiding all the mistakes from the past. But before they get into actual work, there's the sweetest & the most pleasant work to be done ... Visiting the armoury to pick the optimal
Few days ago I've run into this article on InfoQ:
I found it amusing enough to dive deeper here (link taken from the article):
I won't keep you guessing any longer - my amusement isn't about the overall idea of IODA or this horizontal to vertical
The concept of Microservices, even if a bit ephemeral, gets a lot of love nowadays. Reasons are quite straightforward, so I'm not going through that once again - what bothers me is some kind of misconception / overinterpretation I've already encountered few times.
- YES, encapsulate service business logic for coherent & compact slice of (sub-)domain
- YES, encapsulate persistent data that business logic
The struggle against coupling doesn't just seem eternal. It IS eternal. Multi-dimensionality (compile-time, deploy-time, run-time, ...) of the problem, easiness of breaking the state that was achieved with the great effort, complexity of validation / monitoring (try to quantify coupling in a way that makes sense ;>) - all of these don't make things easier. Especially when you realize that sometimes you've got snakes in place you've
Have you heard about Lambda Architecture (LA)? It's an interesting concept introduced by Nathan Marz ("the father" of Apache Storm) and it's basically about processing massive quantitive of data using two parallel streams:
- batch stream - this one is able to do pretty much anything with unlimited quantity of data, but it has its latency, stored data has its inertia & crunching (even distributed)
I hate starting a blog post without a clear statement or a question to be answered. But sometimes it's just the best way - hopefully things will clear out for you during the reading.
No more "free lunch"
Technology is advancing like crazy since I can remember. Until quite recently, I was buying a new computer every 2-2.5 years. CPU frequencies, RAM, disk
It all starts with the book
While I was reading Sam Newman's "Building Microservices", I've found a very interesting paragraph - let me quote it here for easier reference (I've bolded what I want to put an emphasis on):
"My general rule of thumb: don't violate DRY within a microservice, but be relaxed about violating DRY across all services. The evils of too much
Microservices (as a topic) are alive & wiggling. I assume you know what they are about & you've got some clue about the substance of criticism that has hit them. I'm not really that much interested in MS as such, but I'm far more concerned with the general issue of building complex, integrated solutions in a maintainable (long-term) way:
- modular - to distinguish
... or rather the stuff that is "OPEN". Not just because of Open Source Software, but also:
I'll tell you why ...
"Open" means "for everyone"
As usually, I'll try to set some context up first:
This is part III of coupling consideration topic. If you want to check my past coupling-related posts, you can find them here:
- Part I - the theory of coupling
- Part II - practical examples of coupling and how does it really affect your apps (& services!)
Now it's time for Part III - let's bring up some ideas about how to fight the coupling