Comment by contingencies | Hacker News Reader

Comment by contingencies | Hacker News Reader

Lots of problems can benefit from well defined interfaces: security, complexity, maintenance, HR/project matching, need for parallelized or decoupled development (eg. multi-team/timezone), use of existing codebases, etc. As always the devil is in the details.

It is an old maxim in programming that correctly modeling the data is a huge percentage of the design. For example:

Pike's 5th Rule: Data dominates. If you've chosen the right data structures and organized things well, the algorithms will almost always be self-evident. Data structures, not algorithms, are central to programming. - Rob Pike, Notes on C Programming (1989)

In that sense, in nontrivial problem spaces, if forced to generalize, then I am generally more for spending time carefully developing interfaces (ie. a paradigm potentially more closely aligned (in a network services context) with the microservices model = older coders with maintenance chops) than immediately writing actual code (ie. approach of the keyboard-happy iterative tweaker = young coder with fire-and-forget habit).

Any real world project lies somewhere between these extremes.

But if you make a modeling mistake in a monolith it's a little painful, but if you make a modeling mistake with microservices it's excruciating.

What is central to a program is not the data structure or the algorithm but the thing it intends to accomplish for human beings. If you start with a data structure and say "what can we let people do with this?" you're going to write bad software.

I don't feel they are saying start with the data, before you even have an idea. More, "What data do we need, and how do we structure it for this problem?".

I agree with your first point, but I find microservices (which almost always means JSON in practice) tend to lead to less well designed interfaces than monoliths in a well-typed (i.e. ML-family) language.

So, should we all root for grpc or an equivalent?

Edit: grammar.

I use Thrift when my systems have to be distributed, but it and GRPC's type systems are still a long way behind what you can do in Haskell/Scala/Idris. So I still say build your system to be deployed monolithically at first (of course split it up into modules and libraries), and move to distributed only when it becomes too large to deploy monolithically (or rather, when you have so many developers that you can't deploy a monolith frequently enough).

This only works as long as you can pass transaction objects around across module boundaries.

Because otherwise, how do you guarantee atomicity across module boundaries?

how do you guarantee atomicity across module boundaries?

The more fundamental answer is: It depends upon questions such as whether the system seeks to exhibit parallel processing properties or not, and the application-specific data generation/processing/storage/retrieval/consistency goals.

The short answer is: Ideally you don't, because architecturally you are likely creating a monster.

The longer answer is that in the case that it is justified (and such cases do exist) you would generally either use a reference to a transaction (potentially knowing that it may be out of date and having a planned strategy for eventual consistency carefully limiting the effect of such to a non-critical scope), or eat the latency overheads and use an established algorithm - see https://en.wikipedia.org/wiki/Atomic_operation https://en.wikipedia.org/wiki/Consensus_(computer_science) and https://en.wikipedia.org/wiki/Consistency_model - which for most of us simply means 'choose your database/network replication layer carefully'.

Reply on news.ycombinator.com