Comment by icebraining | Hacker News Reader

Comment by icebraining | Hacker News Reader

I find this article lacking, since it paints a too simplified brush over monoliths. Some missing points:

"Monolith", at least if you define it as a single process rather than a network of (micro)services, can still be modular in nature. Using a flexible core, you can build your application as a combination of modules, rather than as a single large codebase.

They also don't have to be a SPOF: in our architecture, we deploy monoliths, one for each client (ie, company, not user), while keeping them isolated from each other. This allows us to scale pretty much indefinitely using a simple architecture. We don't have a huge sharded database, but small bundles of databases. We don't have datacenter-wide load balancers, rather we allocate clients to certain groups of nodes and use DNS to point them there.

This works because our clients don't really need to interact with each other, unlike say, social network users. Do yours? If not, why are you building a huge and complex mesh of services?

Use caution. The multi-instance monolith approach can run into a nasty obstacle at a certain point when you want the business a very, very large customer who does need all that interaction within their own service. If you've been doing your scaling on shared resources the whole time, then you'll be far better equipped to handle it and the code is less likely to be broken.

(Also, even short of complete scalability failure, things like maintaining proper redundancy on a per-customer basis can be a major pain point.)

Of course the only real way to get these tradeoffs right is a very good understanding of your problem space.

Largest installation we were involved with (though not me personally) was a 250k user base, for the Ministry of Education in my country.

The monolith is stateless, so it's pretty easy to scale. The painpoint is Postgres, but I think people underestimate what real hardware in a small cluster can handle.

I think GP's point is more along the lines of When the Ministry of Education and the Ministry of Whatever are both customers (separate instances) and want cross instance reporting.

We had this at one of my previous places, exactly the same setup. Identical monoliths * shopping malls, the issue is that Companies own more than one shopping mall and they really want cross mall data, something that was extremely painful to add in at a later date.

Except that in real world you can't automagically create cross report from separately defined data structures.

If you want cross report you will define a super-data structure able to talk to both monoliths. They incidentally become "microservices" but at a higher level.

I agree with Twisell. The solution is to create a super data-structure so this really is an architecture and abstraction issue - ie. design things in a way such that these structures can be added in an incremental and painless way when the need appears.

Only a minority of people are good at that. I'd also note that there is a correlation between the importance of such needs and the ability to anticipate them at the initial design stage. (ie. is it reasonable to be surprised by the fact that a holding owning several supermarkets asks for consolidated reporting at some point ?).

If you're good at abstraction, modularity and composability, there really isn't any gotcha to fear. Stuff don't just come out of the blue.

What exactly is a super data structure?

How do you create a data structure for a requirement that doesn't exist at the beginning of the product?

Most of the time when I've seen someone design data structures in a way that attempts to design for unknown or predicted future requirements, the design ultimately becomes over engineered and a nightmare to maintain or expand in ways the actual product requires down the road.

I'll always pick the concrete implementation as long as future requirements are unsure.

I don't know how you get good at magically guessing how your product needs to evolve, e.g., what new industries is your sales team going to crack into, what direction does marketing want to take your product, etc - the only way you could be "good" at that is when the direction is extremely obvious or you have unilateral decision making on every point of your road map.

> cross instance reporting

Isn't a DWH the best solution for this?

I evaluated another system where we needed something similar. Adding cross data reporting was not hard. Combining whole installations was a bit harder but it was probably not harder to solve it when needed instead of solving it early

We have the same architecture. It's really versatile, simple to administer, and with the help of scripts and automation a new client can me mounted in less than 3 minutes.

Isn't it hard to maintain all the servers? How do you upgrade your application or your database?

This is why you use configuration management tools. We have a similar architecture, with dozens of deployments for customers; upgrades are just a single command that changes some configuration, and puppet does the rest. Until something goes wrong, 100 servers are no harder to upgrade than 1.

We automate it :) There's an "inventory" of the current instances, and then using configuration management (currently Ansible) we can deploy a new version (running migrations, starting new processes and stop old ones, etc) for all or any subset of our instances with a single command.

It does sound like upgrading all the customer servers would be a hassle, but that might be a feature in some domains - if customers have process / regulatory / training constraints and don't want to upgrade promptly, for instance.

Reply on news.ycombinator.com