sagichmal

> In other words, organizations adopt microservices for an operational benefit at the expense of performance.

...no, not at all. There are a couple of operational benefits, but vastly more drawbacks, and on balance microservices are phenomenally harder to operate than monoliths.

Organizations adopt microservices when the logistical overhead of coordinating teams against a monolith becomes so large that it starts affecting product velocity. Microservices are a way to release that organizational/logistical friction, at great technical cost.

With that said, the domain-oriented bounded context is indeed the right way to think about service delineation.

On the contrary, it's the best strategy for reducing risk in modern web service architectures.

Same network rules and configuration? Same CDN settings? Same DNS? Same data in the databases? Same volume of traffic on the queues?

(Rhetorical questions. Of course the answer is no.)

All of these things have huge impact on the actual similarity of the systems, and consequently how they behave.

It's not possible to replicate the CDN, or DNS, or the message queue if it's hosted, or the database of it's big enough, or etc. etc. The differences between what you're able to create in a staging environment and what exists in prod are significant enough that testing against the staging environment doesn't build much more confidence than testing with mocks.

Testing in prod means accepting this reality, avoiding the largely unproductive toil of building and maintaining a staging env, and making the production system observable, resilient, and operationally agile enough that you can deploy changes that can trigger unpredictable and emergent system behaviors while managing risk appropriately.

Modern architectures look like this: https://github.com/donnemartin/system-design-primer

Building this out twice is either actually impossible, or so cost prohibitive as to be practically infeasible.

Modern architectures look like this: https://github.com/donnemartin/system-design-primer

All of the pieces have complex and emergent behaviors as they interact with each other. Many (most?) are hosted, not even fully in control of the team using them. Recreating this environment in a hermetic way for testing is either actually impossible, or so cost prohibitive as to be practically infeasible.

The size of the codebase is orthogonal to the size/complexity of the production environment.

Modern architectures look like this: https://github.com/donnemartin/system-design-primer

It is generally not feasible to recreate all of the elements of this design in a totally separate testing environment.

The author originated the meme. It is not meant to be interpreted as sarcastic.

> The first scenario is they have never set up a test environment in the first place. They're either too lazy to do so, or too lazy to look into how to do it. Often confused with being 'too busy to do it'.

One lesson of modern architectures (i.e. anything more recent than the LiveJournal-style Web/App/DB 3-tier stack) is that it is literally impossible to create and maintain a test environment that has enough similarity to prod to be useful.

No, it isn't.

No, CRDTs and Operational Transforms are not the same at all.

I don't think I agree. Identifying an abstraction as leaky and breaking it apart is substantially more difficult and riskier than identifying duplication and creating an abstraction for it.

> In my view you should make it a habit to write optimized code.

It depends on your domain.

If you're writing for embedded, or games, or other things where performance is table stakes, then sure.

If you're writing code to meet (always changing) business requirements in a team with other people, writing optimized code first is actively harmful. It inhibits understandability and maintainability, which are the most important virtues of this type of programming. And this is true even if performance is important: optimizations, i.e. any implementation other than the most obvious and idiomatic, must always be justified with profiling.

> it is really easy to un-share code by copying it into multiple places but it is very hard to unify duplicated code

Code that already exists has a gravity, a presumption of correctness. That presumption is very difficult to overcome, especially for programmers new to the codebase. An abstraction you think of as temporary will be, to those who come after you, simply the way things are done; breaking it apart and re-forming it is, for them, fraught with risk. It's good to keep this in mind as you make commits.

I have had exactly and overwhelmingly the opposite experience. I wonder if it's a function of our fields, or what...

It is almost always better to copy/paste a function to accommodate "that one optional parameter" that breaks the original abstraction, than to add the parameter to the function signature. The "cost" of a broken/leaky abstraction is at least an order of magnitude higher than that of duplicated code.

> Cannot agree with that. If one does that or not, would depend on things like Service Level Agreements (SLA) — and one can have a pretty high SLA uptime %, without sharding, e.g. if there's an underlying pretty stable hosting provider that live migrates if there's a hardware failure.

Sorry, no. A single instance is never acceptable from any risk perspective, no matter what guarantees the hosting provider claims.

> When did you start sharding? How many GB memory did your previously single-machine-Redis-instance use . . .

Sharding is always something you do on day 1 for every project, because a single-machine-Redis-instance is a SPOF and won't pass even the most basic operational readiness checklist.

> (capacity planning questions)

The answers to these questions don't generalize, they depend on your workload. You should figure out some approximation of your data types and request profiles, and use those to get a rough understanding of what one Redis server on a given machine class is capable of delivering. This usually means applying a few different classes of read/write loads against a small cluster at steadily increasing RPS, and documenting how CPU, memory, and latency characteristics change. From these numbers it's possible to derive a capacity plan.

The last time I did this, for my workload and machine class, one Redis instance (one core) delivered 250-500k RPS, invariant to memory used. We'd use the conservative end of that range, combined with the RPS and data set growth rates we predicted, to provision for ~12 months of growth. Operationally, we would deploy (cores-1) or (cores-2) instances per host (I forget exactly) on 32- and 64-core machines. I think they had like 64-128G of RAM, and we made sure to leave enough memory overhead so the AOF or whatever persistence option wouldn't lock up the box. But even the choices of what class of machines to use is a function of your use case, if you have really large dataset with relatively non-costly (CPU) operations, you want a totally different machine profile than a relatively small dataset with complex operations. Availability SLOs also factor in.

All of this is basic operational stuff, and with Redis the answers are pretty well-understood and highly predictable. Completely opposite to systems like Elasticsearch, which was a total nightmare to predict, provision for, and operate.

This is a valid but narrow definition of racism. It's not really useful when speaking at a cultural level.

Redis is extremely simple to scale. Treat each instance in a cluster as wholly independent from other instances, and build a thin layer on top to implement whatever sharding and availability requirements your use case requires. I've done it many times and it's always been simple and worked brilliantly. Redis's predictability makes it a joy to operate.

Ironically, this example is evidence against your point, not for it. All of these uses of the word "port" share a root semantic etymology, which is the point where two entities interface to exchange goods or information. Exactly the same way that all of the uses of the word "master" to describe a hierarchical relationship share a root semantic etymology, which is someone who owns or controls other human beings.

> What is it that offends you about the terms, and why?

Sorry for being unclear. I'm not offended, either. But (see my reply to sibling comment) I find the arguments that the term can be seen as offensive, and that it perpetuates a (small! subtle! but real!) form of systemic racism, essentially plausible, and I'm sympathetic to them.

> I do not support this change since it has nothing - and I mean absolutely nothing - to do with race, racism, insensitivity or otherwise abusive behaviour.

It's fine that you believe this, but other people don't agree. Other people believe that the historically racist connotation of "master" in the context of establishing a hierarchical relationship is real, acute, and powerful, especially in the zeitgeist. Other people experience the term "master" in this context as a reminder of that historical (and sometimes not so historical!) racism, which can be painful. Or they experience it as an example of how systemic, institutional racism can persist in extremely small and subtle ways. Or both!

I don't think that people who believe these things are believing them in bad faith, or that they're claiming these things for ulterior motives. I think they're being honest when they say they're pained, and I find the arguments about perpetuating systemic racism plausible. So I think it's completely reasonable to use a different word where we can. I think it reduces suffering in the world, and I think that's the best goal that there is.

Hi, I support this change and I don't consider myself a spineless sunflower, nor am I offended on behalf of anyone else.

The super early Java prototype of Kubernetes lived for about a week or two and never saw a public repository. It's kind of misleading to say it "started out in Java".

They're inextricably woven into the fabric of the internet, and unfortunately can't be wished away.

A protocol separate to UDP and TCP altogether would suffer from middlebox interference problems.

> There is no objective "ethically correct" anything.

That's correct. Luckily, objectivity is not necessary.

> Really interesting.

Is it "really interesting" that Twitter is paying extra attention to the President of the United States' Twitter account? I don't think so.

> The issue is that the rules are being enforced selectively.

It's not only acceptable but actually ethically correct to hold those with more power to higher standards of responsibility.

It's therefore not only acceptable but actually ethically correct to enforce these rules more proactively against the President of the United States than some Russian bot account.