> You often can't just go off dev because other people use it while you're testing.
Why do you think that other people using a cloud environment prevents you from using the environment?
1,739 karma · joined March 20, 2024
Why do you think that other people using a cloud environment prevents you from using the environment?
No one does microservices for resume chasing anymore, because everyone is already doing it for practical reasons. I never came across a monolith that wasn't in the process of peeling responsibilities to either microservices or function-as-a-service. For project managers to open their eyes, all that's needed is something like a deployment going wrong due to a single bad commit, or things scaling weird because a background process caused a brownout, or even external teams screwing up a deployment after pushing bad code.
No, not really. The size of your teams have zero to do with whether your services can corrupt data. That's on you. Don't pin the blame on a service architecture for the design errors you introduced. Everyone else does not have that problem. Why are you having it and blaming the same system architecture used by everyone else?
> Making schema changes to the shared cloud services.
What are you talking about? There is absolute zero system architectures where you can change schemas willy nilly without consequences. Why are you trying to pin the blame on microservices for not knowing the basics of how to work with databases?
In all the times I had to work on schema changes, the development was done with a db deployed in a sandbox environment, and when work was done we had to go with a full database migration with blue-green deployments along with gradual rollout. Why on earth are you expecting you can just drop by and change a schema?
> Cleaning up dev/test/etc data that has accumulated, etc.
Isn't this a non-issue to anyone who works with databases? I mean, in extreme scenarios you can spin up a fake database with your local service, but don't even try to argue this is the justification you need to launch dozens of services.
The truth of the matter is that this is extremely simple: if you want to work on a service, launch that service locally configuring it to consume all dependencies running in a non-prod environment. That's what they are for. If you have extremely specialized needs, stub specific dependencies locally. That's it.
Yes. That's the point.
> How does that solve the problem of a mess of interconnected services (...)
I don't think you got the point.
The whole point is that you only need to connect your local deployment to services that are up and running. There is absolutely no need to launch a set of ad-hoc self-contained services to run a service locally and work on it. That is the whole point.
I'm talking about how Microsoft added support for connected services to Visual Studio. It's literally a tool that anyone in the world can use. They added the feature to address existing customer needs.
Every single man page out there leads to a user experience that is at best subpar.
> One of the reasons Stack Overflow is so popular is that people who can't/won't read docs can use it to have answers spoonfed to them (...)
Pause and look at what you're saying. Your only criticism of SO is how it improves the task of providing meaningful information to users.
The way you opt to spin improvements to user experience as "spoonfed" speaks volumes of your inability to understand the problem and the value you place on gratuitous ladder-pulling. You even contradict your remarks on man pages.
> Reading isn't a singular skill— each genre requires its own skills (...)
No. Writing is a skill. Producing content that the target audience is able to consume and brings value is a skill. The moment you, as a end-user, feel the need to hunker down and decipher arcane texts is the moment you should realize the documentation is bad.
Again, Stack overflow is widely used as ad-hoc crowd-sourced documentation for a reason. Some project maintainers even go as far as to make it their own channel to provide technical support. Why so? Do you honestly believe its because the whole world is not smart enough to read man pages?
Again, those who do not waste their time on man pages are the smart ones who put their own time to better use.
I don't think you know what you're talking about. Just because you know people who do not want to waste their time on a set of unproductive chores you arbitrarily singled out, that does not mean they are against learning.
Your take is particularly absurd considering the topic: engineers working on distributed services.
Do you actually believe that you build up enough knowledge on this topic to become a professional in the field if you "straight-up don't want to learn"? There is not a single developer in the field who, at least to some degree, is not self-taught.
> They want to do their job, and get paid.
Everyone wants to get paid. Do you know anyone who works non-profit?
What you're failing to understand is the "do their job" part. Software developers are trained to solve the problems they face, and not waste time with the problems they do not have. Time is precious, and they invest it where it has the largest return on investment.
> Reading man pages is sadly not in that list.
Man pages are notoriously a colossal waste of time. In general they are poorly thought out, they are incomplete, they were written with complete disregard for user experience, and more often than not they are way out of date.
Why do you think sites like Stack overflow is so popular? Because all those "incurious" people in tech feels the need to ask questions and dig through answers on how to solve problems?
I think you're just picking a very personal definition of competence which conveniently boils down to "do the things I do, and do not do the things I don't". Except the bulk of the people in the field is smart, and some have already solved problems that you aren't aware exist, such as wasting precious time deciphering unreadable documents that are systematically out of date.
No, this does indeed match reality. At least for those who work with microservices. This is microservices 101. It's baffling how this is even being argued.
We have industry behemoths building their whole development experience around this fact. Look at Microsoft. They even went to the extents of supporting Connected Services in Visual Studio 2022. Why on earth do you believe one of the most basic traits of backend development is unreal?
> I work at ~50 ish employee company and we have layers of dependencies between at least 6 or 7 various microservices.
Irrelevant. Each service has dependencies and consumers. When you need to run an instance of one of those services locally, you point it to it's dependencies and you unplug it from it's consumers. Done. This is not rocket science.
This is certainly one of the critical mistakes you did.
No developer needs to launch half of the company's services to work on a local deployment. That's crazy, and awfully short-sighted.
The only services a developer ever needs to launch locally are the ones that are being changed. Anything else they can consume straight out of a non-prod development environment. That's what non-prod environments are for. You launch your local service locally, you consume whatever you need to consume straight from a cloud environment, you test the contract with a local test set, and you deploy the service. That's it.
> I guess one can grumble about bad architecture all day but this had to be solved.
Yes, it needs to be solved. You need to launch your service locally while consuming dependencies deployed to any cloud environment. That's not a company problem. That's a problem plaguing that particular service, and one which is trivial to solve.
> Both FAANG companies I’ve worked at had remote dev environments that were built in house.
All FANG companies I personally know had indeed remote dev environments. They also had their own custom tool sets to deploy services locally, either in isolation or consuming dependencies deployed to the cloud.
This is not a FANG cargo cult problem. This is a problem you created for yourself out of short-sightedness and for thinking you're too smart for your own good. Newbies know very well they need to launch one service instance alone because that's what they are changing. Veterans know that too well. Why on earth would anyone believe it's reasonable to launch 50 services to do anything at all? Just launch the one service you're working on. That's it. If you believe something prevents you from doing that, that's the problem you need to fix. Simple. Crazy.
It's not about being "easy". It's about being objective, verifiable, and demonstratably unbiased. It's about justifying how you rank the performance in a way that's impossible to refute.
> But the situation you describe is a classic sign of a shit manager:
It's not, and frankly this "shit manager" accusation is an infantile remark that screams a failure to understand what it means to perform well.
This is not a "sort of people" problem. This is a metrics problem.
It's not only developers who are evaluated by using useless metrics that don't track the value you add to an organization. Low-level managers are too.
Low-level managers need to evaluate the people assigned to them, they need to evaluate them objectively, and they need to give an unbiased and objectively verifiable score. This means something they can measure, such as metrics or verifiable goals.
If low-level managers cannot do this, they will need to answer why they gave X and Y this score whereas poor little Z who outworked them both was scored lower. Not being able to objectively justify a score is a problem that no manager wants to have, as this is a major liability.
Hence the bullshit metrics and absurd goals. They need something on paper to back up their decisions. A manager might be fully aware that you unblocked half your team members throughout the year with critical help, and that you are the go-to guy to solve critical issues. But if your team members close twice the tickets you did, they will have trouble justifying you are contributing as much as them.
That's perfectly fine. You can compare Redis to other specialized tools just like you can compare it with Postgres and SQLite.
That's fine. If what you want is a single-node deployment combined with in-memory purism them SQLite has your back.
Is that relevant though? Some benchmarks on the web show Postgres outperforming Redis in reads as well as low-volume writes (less than 1k key-value pairs), and Redis only beating Postgres for high volume key-value writes.
I don't think this is a realistic scenario at all.
If you need a KV store, you want it to be the fastest by keeping it in-memory, you want it to run on each node, and you don't care how much it cost to scale vertically, then you do not run a separate process on the same node. You just keep a plain old dictionary data structure. You do not waste cycles deserializing and serializing queries.
You only adopt something like Redis when you need far more than that, namely you need to have more than one process access shared data. That's at the core of all Redis usecases.
https://redis.io/docs/latest/develop/interact/search-and-que...
FEM at it's core ends up being just a technique to find approximate solutions to problems expressed with partial differential equations.
Finding solutions to practical problems that meet both boundary conditions and domain is practically impossible to have with analytical methods. FEM trades off correctness with an approximation that can be exact in prescribed boundary conditions but is an approximation in both how domains are expressed and the solution,and has nice properties such as the approximation errors converging to the exact solution by refining the approximation. This means exponentially larger computational budgets.
Isn't IGA's shtick just replacing classical shape functions with the splines used to specify the geometry?
If I recall correctly convergence rates are exactly the same, but the whole approach fails to realize that, other than boundaries, geometry and the fields of quantities of interest do not have the same spatial distributions.
IGA has been around for ages, and never materialized beyond the "let's reuse the CAD functions" trick, which ends up making the problem more complex without any tangible return when compared with plain old P-refinent. What is left in terms of potential?
> Tom Hughes, who is mentioned several times, is now the de facto leader of the IGA research community.
I recall the name Tom Hughes. I have his FEM book and he's been for years (decades) the only one pushing the concept. The reason being that the whole computational mechanics community looked at it,found it interesting, but ultimately wasn't worth the trouble. There are far more interesting and promising ideas in FEM than using splines to build elements.
Not really. Messages vs events is a foundational design trait whose discussion involves topics such as adopting distinct messaging patterns such as message queues or pub-sub. They have completely different responsibilities and solve completely different problems.
So the entity was updated. What's the problem?
Which distributed transaction scenario have you ever dealt with that wasn't correctly handled by a two-phase commit or at worst a three-phase commit?
Events and messages are entirely different things. They might look similar, but their responsibilities are completely different. The scenario you're describing matches the usecases for messages, not events.
I know iOS developers who recently upgraded their MacBooks and they claim they now feel more sluggish. I wouldn't be surprised if it was due to RAM constraints instead of CPU though.
So, take those artificial bencmarks with a grain of salt. They are so optimized that they are optimized out of the real world.
The last Intel macbook pros were released 4 years ago. Their owners are starting to shop around for replacements. Their question will be "will the expense be worth it?"
The whole point is that these highly specialized scenarios are only featured in very specialized usecases, and don't reflect in overall performance.
We've been dealing with the regular release of specialized processor operations for a couple of decades. This story is not new. You see cherry-picked microbenchmarks used to plot impressive bar charts, immediately followed by the realization that a) in general this sort of operator is rarely invoked with enough frequency to be noticeable, b) you need to build code with specialized flags to get software to actually leverage this feature, c) even then it's only noticeable in very specialized workloads that already run on the background.
I still recall when fused multiply-add was such a game changer because everyone used polynomials and these operations would triple performance. Not the case.
And more to the point, do you believe that matrix multiplication is a breakthrough discovery that is only now surfacing? Computers were being designed around matrix operations way before they were even considered to be in a household.
I think the whole point is that microbenchmarks provide no data in overall performance. They just test very specific and by no means common use case.
I know a couple of iOS developers who recently switched to a M4 MacBook pro and they swear that in some frequent workloads it feels sluggish and slower than the old Intel MacBook pros. Being RAM-starved might have something to do with it though.
> but there's loads of mini PCs with decent CPUs, 32GB RAM and a 1TB of SSD storage for under $600.
I also add that, unlike Apple hardware, these miniPCs are built with extensibility in mind. For example, most NUCs from the likes of minisforum and Beelink ship with a single SSD but support multiple SSDs, with their cases also having room for SATA drives. They even go as far as selling barebones versions of their NUCs, where customers can then pick and choose which RAM and SSDs to add.
I agree. Just stop using it already. What's the value of subscribing to a Kremlin bot sandbox? Sometimes these complaints just sound like attempts to keep people engaged after clearly identifying the elephant in the room.
For starters, cross-referencing it with popular propaganda talking points. Smear campaigns are a dead giveaway, and adding two or three topics should be enough to cover the majority of propaganda posts.
I'd argue that just having an effective anti-bot policy is enough to render this a non-issue, but apparently Elon Musk prefers Twitter to be a Kremlin bot sandbox.