431–440 of 447 posts
Earlier quoted context omitted.
you can absolutely use Kubernetes to implement a dead-simple three tier with minimal ops overhead, especially if you're using a managed cluster
And if something goes wrong, is it simple to debug and understand? Can I reproduce issues locally? Happy path simplicity is easy.
Earlier quoted context omitted.
i agree that its possible. From what i've seen its probably harder though than just doing services. You are fighting against human nature, organizational incentives, etc. As soon as the discipline of the developers, or vigilance of the dictator lapses, it degenerates.
It is really hard to read this for me. How can anyone think that it is harder to write a proper monolith than implementing a distributed architecture? If you just follow the SOLID principles, you're already 90% there. If your team doesn't have the knowledge (it's not just "discipline", because every proper developer should know that they will make it harder for everyone including themselves if they don't follow prope…
You can sort of get there if you have a strong central team working on monolith tooling that enforces module seperation, lints illegal coupling, manages sophisticated multi deployments per use, allows team based resource allocation and tracking, has per-module performance regression prevention, etc. They end up having many of the organizational problems of a central DBA team, but its possible. Even then, I am not aware of many(any?) monoliths in this situation that have scaled beyond 500+ engineers that people are actually happy with the situation they've ended up in.
Earlier quoted context omitted.
Well I have seen lot of people with 20 years of experience which is actually 2 year experience repeated 10 times.
That's not what I am saying. I am saying that you cannot make 20 years of experience in 2 years. You are saying that some people with 20 years of experience are worse architects than others.
Earlier quoted context omitted.
I wish I could have that good timing, but I'm rarely hired early enough.
Hey 3 years from now the mistakes you’re making today will look like “Wow I wish I was there, that loup-vaillant guy sucked” to some new hotshot :) That is to say: You can start now. There’s always plenty of new mistakes to make.
But there's worse: most of the time they already know. The various issues I balk at were often bothering them for years, and yet fixing it was never the priority. Week after month, there always was something more pressing, generally about some deadline. Such issues often have gone long enough that the cost of keeping the current cruft have long exceeded the cost of replacing it. But this cost is gradual, so the fix keeps getting pushed further and further into the end of times.
Perhaps my biggest mistake is not seeing that such organisations are beyond helping. I keep getting fooled by promises of doing things right going forward, when I should instead extrapolate the past. Either they're already work in ways that I can approve, or at least live with, or I should seek something else on the spot.
I 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.
Earlier quoted context omitted.
That's not what I am saying. I am saying that you cannot make 20 years of experience in 2 years. You are saying that some people with 20 years of experience are worse architects than others.
No, I am trying to say inexperience is more insidious in IT industry and no of years is not giving true picture of ones' experience.
Earlier quoted context omitted.
Why? What inherent advantage do those languages have with financial logic?
Python will let you use float division on integers. Compiled type languages won't do that. This would be solved by using a double data type. But python doesn't have it.
And if you're doing that, python has the Decimal class for the same thing.
Earlier quoted context omitted.
I usually also use Cloud Run for running my containers. But I use Cloud Build instead of GH Actions. I'm curious, what's your reasoning? I prefer my repository to just hold code and run build actions close to where it's deployed.
For me, I had use GH Actions before so it was pretty quick to get up and running. I am sure it was not that much more effort to use a cloud build tool in GCP or AWS but honestly don't see that much of a pro/con.
I might be fully past the idea that what makes the difference is the architecture rather than the team. I am certainly past the idea that monoliths impose any kind of barrier to complexity. In many ways I find it to be precisely the converse. Sure, there's nothing meaningful to choose between one giant plate of spaghetti versus a dozen small plates flying in loose formation. I'd still rather have lasagna than either.
SO much yes. You may have the prettiest architecture, and the best separation of concerns, and the most modular modularity, but if you don't have the right competencies, processes and people all that would go out the window before you can even finish the power point slides showing off your nice new architecture.
It's like a garden - if you don't tend to it, it turns into a mess, and the fight against entropy never stops. If you also have to fight the team along the way you've already lost