srvaroa

I don’t fully agree with all points but there are many words of caution to be spoken about the expectation that by moving to a manager role you get more agency on the things that frustrate you as a sw eng. “The managers path” is a good resource to expand on that. https://www.amazon.com/Managers-Path-Leaders-Navigating-Grow...

Maybe professional bias but I prefer to follow a cattle vs pets approach here and treat them as disposable, meaning: let the sd card break and optimize for quick replacement.

Good thing. It shows that a % of your tests were actually not targeted at the most important areas of the code base

I hear this point as a counter argument to “never decrease coverage helps maintain quality”.

It is technically correct. But, it is only meaningful if you assume a bad actor in the team who knowingly games the system, and a team who tolerates it.

At that point, your problem has nothing to to with code quality, nor is coverage meant to be a solution for it.

Thanks for posting. I keep a log of these for every time I have one of those “mocks and synthetic loads are useless to test this piece of software, we absolutely need to clone production” conversations.

There are usages outside of the browser too. We are using wasm as a runtime for applications and modules deployed in small IoT device. Wasm helps overcome the typical limitations of those devices giving platform independence, sandboxed environments, ability to verify and sign modules ahead of deployment, allows developers to program in dominant languages and compile to wasm, and still retain a low footprint which is critical in this context.

There is a more detailed overview here: https://www.midokura.com/why-webassembly-is-perfect-for-tiny...

This.

Most of the articles about working around code reviews give the same vibes as naive crypto enthusiasts towards financial regulation.

I can agree that interests of companies and individuals are not necessarily aligned and it's good advice to take this into consideration. I'm not sure it's necessary to add actual bad intentions from the part of all tech companies. In fact, I think it spoils most of what's good about the advice.

“The investigation” by Stanisław Lem

“Neuromancer” by William Gibson

“A fire on the moon” by Norman Mailer

This comment shows IMO that the real issue here is not really microservices or not microservices, but what the article calls "The apostles of the Church of Complexity".

Neither microservices or monolith are a golden hammer, silver bullet or whatever (nor the opposite). They are tools each with their tradeoffs, which combine with the many context-dependent tradeoffs of each organization. They are not the problem.

The problem is a) engineer's fascination with complexity, and confusing "simple" with "hack", b) how organizations keep cargo-culting tools, architectural patterns, and so forth. Applying architectures, design patterns, whatever naively, based on the belief that usage alone will deliver benefits. It doesn't.

The implicit assumption behind this statement is that using production for testing increases the risk of production outages.

Even if we consider it correct, I think it is a mistake to believe that the only way to handle that risk is to open the environment proliferation can of worms, and jump inside. It isn’t.

Each system is different, but in the vast majority of software systems I have found, concerns with testing on production environments aren’t actually good reasons to use non-prod environments. They are instead signals of more fundamental flaws in the system itself (or in the dev practises).

To use an example. If we are talking about a multi tenant system and we worry that tests ran against the testing tenant can break other tenants, what we have is a system that is inherently broken. We don’t prevent this problem by doing tests elsewhere (and inflating the maintenance burden, creating the risk of divergence between test/non-test envs, etc.) We prevent this by implementing multi tenancy correctly.

A good way for getting a deeper insight of JVM memory usage beyond heap is -XX:NativeMemoryTracking=detail

I send links to getpocket.com from $device. I like to save the best ones, so I made a dumb tool to download them as rendered text files (glorified w3m -dump) which I organize in 3 folders that my tool syncs back upstream to GetPocket: favourites (which I keep locally and backed up), archived (local copy is deleted, but link kept in GetPocket), and deleted (sync deletes from local and GetPocket). The tool is http://github.com/srvaroa/repocket

They are on their own. The team doing managed Kafka does offer some tools for data / schema migrations, but there is nothing for other storages.

Generally they actually don't raise this as a pain point, teams tend to be quite self sufficient in this regard and rely on things like https://flywaydb.org/ to deal with it.

From our PoV, at this point this type of feature would be in the high cost / low impact quadrant. Not because it doesn't make sense, on the contrary. It's just that it falls at a later stage of maturity than we're at organisationally. As I mentioned, Adevinta is an extreme case of sprawl. To invest productively in "a fully managed relational db with data/schema migrations" we'd need a certain degree of consensus on which db should we support. We don't have that luxury. Even more: we'd also need some form of consensus on "this is how you deploy and release software" which there isn't either (do you do proper CD? is there a manual judgement? are there deployments to a PRE/Staging env? ..). This heterogeneity greatly limits our impact (sprawl reduces the potential surface of impact for any decision we make) so we focus on areas where we can avoid this problem (e.g. everyone buys cloud, containers...). But also, as I said above, data/schema migrations is actually not a pain point teams complain about frequently.

AWS takes care for most of them. All teams generally use cfn / terraform / to define that kind of infra (e.g. I need a DB with these properties) and they get applied as part of the standard deployment pipelines. We constributed support for cfn in Spinnaker to enable this.

A team in a different area to mine does offer Kafka as a service, but this pattern is an exception, and the org is actively moving away from it in most other cases. For example, a while back a team took care of offering "Cassandra's as a service", managed and operated for N product teams. They don't anymore, for reasons I explained in the article: - AWS catches up (e.g. they recently announced Cass as a service) - $commercial company has a Good Enough alternative (e.g. several teams are dropping Cass in favour of Dynamo) - It's operationally very expensive to maintain a team that does $storage as a service. - The cost/benefit ratio for doing our own managed storage only adds up when the managed solution is too immature, or lacks too many features that you need. The team offering managed Cassandras actually did this and moved to offering a managed Kafka clusters ~1y earlier than AWS released the first version.

Does that make sense?

Hi, author here. That was exactly the intent of the title, reflecting the reaction we (almost always) get from developers: "k8s is at fault", the result of most investigations is "not really". I try to make that evident at the conclusions, but I agree without realizing that intent the title is misleading.