Writes simple and then drops GraphQL and K8s.
GraphQL is less complicated than querying dozens of interdependent REST queries.
In Defense of Simple Architectures (2022)
61–70 of 447 posts
Re: In Defense of Simple Architectures (2022)
#62I agree with the general sentiment that simple architectures are better and monoliths are mostly fine. But. I've dealt with way too many teams whose shit is falling over due to synchronous IO even at laughably low volumes. Don't do that if you can avoid it. "Subtle data-integrity bugs" are not something we should be discussing in a system of financial record. Avoiding them should have been designed in from the start.
> shit is falling over due to synchronous IO even at laughably low volumes.
Like? I ask because even synchronous IO let's you serve millions of requests per month on a cheap VPS.
That's enough in the b2b space to keep a company of 1000 employees in business.
Re: In Defense of Simple Architectures (2022)
#63I think these kinds of articles are a bit glib. Developers implement architecture to solve problems confronting them. Sometimes a new problem then arises which must be dealt with, and so on, until the architecture in hindsight is quite complex. But you can only know this in hindsight. A few companies didn't run into the "piling on" of issues to be fixed, and so look back in hindsight, see their simple architecture, and think, "we know something that everybody else doesn't," when in fact they're simply experiencing some form of survivorship bias.
Re: In Defense of Simple Architectures (2022)
#64Monolith is fine if you have a fairly simple process for manipulating your data. Like posting an article, then a comment, with some moderation thrown in. But when you start adding business rules, and start transforming your data and moving it around, then your monolith will become too complex and often too expensive to run. Lots of moving parts tightly coupled together, long-running transaction wrapping multiple join…
A few comments point out that replacing a monolith with micro services doesn't reduce complexity. I agree 100%.
That's why I mentioned Event Sourcing pattern, not "microservices". Think of a single event log as a source of truth where all the data goes, and many consumer processes working in parallel alongside, picking only those events (and the embedded data) that concern them, reacting to them, then passing it on not knowing what happens later. Low coupled small self-sufficient components that you can keep on adding one next to another, without increasing the complexity of the overall system.
Maybe Event Sourcing/CQRS can be called "microservices done right", but that's definitely not those microservices (micro-monoliths?) everyone is talking about.
Re: In Defense of Simple Architectures (2022)
#65I really think Clojure should be recognised as boring tech more than it is. It seems to have drifted out of public discourse in the last couple of years, which is a shame because it's a rock solid, simple, predictable language that would make an excellent choice for many use cases. It's just a shame that the syntax will forever be a barrier to widespread adoption.
IMO: Part of boring tech is that it's easy to learn and therefore, usually, easy to hire for.
Clojure ticks neither of those boxes, unfortunately.
Re: In Defense of Simple Architectures (2022)
#66This is what I tell engineers. Microservices aren't a performance strategy. They are a POTENTIAL cost saving strategy against performance. And an engineering coordination strategy. Theoretically If you have a monolith that can be scaled horizontally there isn't any difference between having 10 replicas of your monolith and having 5 replicas of two microservices with the same codebase. UNLESS you are trying to undersc…
Services, or even microservices, are more of a strategy to allow teams to scale than services or products to scale. I think thats one of the biggest misconceptions for engineers. On the other end you have the monorepo crew, who are doing it for the same reasons.
On your note about resiliency and scale - its always a waste of money until shit hits the fan. Then you really pay for it.
Re: In Defense of Simple Architectures (2022)
#67Early in my career one of the IT guys told me that one of the people on staff was "a technical magpie". I looked at him with a raised eyebrow and he said "He has to grab every shiny piece of tech that shows up and add it to the pile". This is where we are. I can't tell you how many times I have seen projects get done just to pad a PM or developers resume. Just because it was the lastest and greatest hot shit thing to…
When has a decision that’s bad for the decision maker ever been popular? We see it in the C-suite; we see it with engineers. I think the travesty of so-called “principal engineers” and “engineering leaders” is their adamant refusal to make doing the Right Thing (TM) sexy. Your employees are monkeys: act like it.
>I think the value of so-called “principal engineers” and “engineering leaders” is their adamant refusal to unconditionally jump on all the latest bandwagons and instead make judicious selections of technology appropriate to the problem at hand.
FTFY.
Re: In Defense of Simple Architectures (2022)
#68Earlier quoted context omitted.
In what way does "moving towards microservices" relate to solving "data-integrity bugs"? I would argue the opposite - the more distributed you make the system, the more subtle consistency bugs tend to creep in.
For a financial services company they should be using a compiled language. Something like C# or Java or Rust or Go with Postgres.
Why? What inherent advantage do those languages have with financial logic?
Re: In Defense of Simple Architectures (2022)
#69I'd argue that this article could be read more like "start as a monolith, and then move towards microservices when sensible", except the penny hasn't fully dropped for the author that the sensible time for their organisation is right now. The company appears dogmatically locked into their idling python code, their SQL making unpredictable commits, and their SQL framework making it difficult to make schema migrations.…
Where does the "idling python code" come from? If it blocks, it blocks, that's not "idling". And I doubt they are running a process per core.
Re: In Defense of Simple Architectures (2022)
#70I am very glad of the architecture we use at my current company.
This is a monolith, BUT with the capacity to be deployed as microservices if needed.
The code is structured in such a way that you only start the sub services you need. We have node that launch almost all services, some only a few.
If we need to scale just a particular part of the system we can easily just scale the same node but configuring it just for the sub services we need.