negus

Sounds dystopian. I hope projects like OsmocomBB and Purism Librem will shape the future

In Russia ECH is already banned by the state censorship. Even before RFC is published

Not surprised, considering UK's ridiculous key disclosure law (United Kingdom The Regulation of Investigatory Powers Act 2000 (RIPA), Part III, activated by ministerial order in October 2007, requires persons to decrypt information and/or supply keys to government representatives to decrypt information without a court order.) that makes anyone with high-entropy random data (which is undistinguishable from the crypto-container) a criminal for "not providing the keys to decrypt"

Are you proposing to drown mercy and forgiveness in bureaucracy?

Corruption is a valid point generally. And this question can be raised when discussing pardon for president's family. But is this point valid for this specific case, for the man who already spent 11 years in prison and has no relation to the president?

Yes. And this is the reason ScyllaDB exists

I would like to work with you. Asking searchable things may be considered disrespectful to one's time

seems like a subtle ad for a company mentioned in the first paragraph. would be funny to know if the whole post is written by a LLM

What you mean here is actually deps pinning + vendoring. It's way out of scope of basic CI concept.

Thank you for the hint about the business phone registered in a call redirect service.

Do you think that this risk is bigger than you business being hit by the market?

Cmon, will you complain to a composer that there is a song about love already?

> It's not adding anything helpful -- it's quibbling over words.

That depends on the context. If I come to the paint store I would be surprised if I'm offered either black OR white paint. As If I can not buy and use both, depending on my scenario. Black and white are generally not the same thing, but they are not mutually exclusive in your practice.

(and by the way comparing sizes to color is a bad analogy. the better one would be comparing a big ship with a set of ships. So I state that I can have a fleet of ships, some of which are also big. And one big ship is also can be considered a temporily outnumbered fleet: if it has means to cooperate I can easily add more smaller ships when needed, instead of builidng yet another deck on the main ship).

My point is: microservices vs monolith is a false dichotomy. You can use both approaches at the same time, since each one of them has its own advantages.

If your infrastructure is ready and you know how to manage microservices, than you can just start building monolith unless you decide that some particular part is better be separated due to some reasons like context isolation, separate deployment, separate scaling etc. It will take you a day for the first time. And an hour for the second time and further.

However if your "infrastructure" is just local files with logrotate on a bare-metal machine, if you don't know how to reuse the common code base for different deployment units or if you do not know how to do backward compatible protocol schema evolution, then bad luck -- you just do not have a choice when it comes to designing a new functionality. You'll have to add the new feature to your monolith despite all the benefits you could reap by separating it.

Microservice-ready infrastructure is all about having the capability to separate parts of logic easily when you want to. It neither dictates you to break your monolith right away nor to build only 30 lines of code services from now on

In my opinion it is too literal understanding of the concept and there is no universal borderline in size or scope. It is common in practice to find quite fat microservices because their maintaners decided it doesn't worth to have yet another network communication latency for a specific case.

The main problem here is to be able to effectively debug and maintain several communicating services: to have a distributed tracing facility like Jaeger, centralized logs collection, schema registry and so on.

It may seem compex to set up and maintain at first, but once you have some experience it does not add much toil and cognitive load. But having the infrastracture in place to effectively work with microservices gives you the freedom of system design choices. It does not force you to make microservices very small.

I mostly use statically linked monorepos with microservices. The services use the common utils from the repo. What's the difference except for not having dead code and unused dependencies in the artifacts in my case?