Readit NewsIn other words, do you have to be more careful when integrating these wide operators to preserve some resources for other operations?
This is crucial. Many bootstrapped companies don't offer much stock ownership from employees. Yes, they can pay a good salary, but these employees are laying down the business brick by brick, but never see a dime of the upside. Mailchimp comes to mind. I'm sure there are others.
This basically leaves stock ownership in VC-backed startups as a way to get rich quick (albeit with low odds): https://topstartups.io/startup-salary-equity-database/
In fact, Mittelstands will probably perform even better if they can figure out how to attract the kinds of talent well-funded startups do. And from there, it'll be a virtuous cycle.
You may have posted a photo 7 years ago, and statistics show that basically nobody ever revisits it. However, in case you do, it needs to be there. So these enormous buildings do basically nothing, but still need to be there.
It makes me wonder how it can go on like this. Users only keep adding content and never remove it. The income per user cannot grow forever, storage cannot get infinitely cheap, the model has to break one day?
So if you're designing capacity for exponential growth, the future point at which you stop experiencing exponential growth and only have to worry about roughly linear growth is a much easier problem to solve.
Sending in-product feedback certainly could work because it's more likely to be seen by product management as it continues to roll in.
Support-driven product change requests are well intentioned but generally break down as a process internally. The working knowledge base and incentives are not properly aligned.
In order to see spec sheet read/write speeds you can/should bypass the filesystem and the buffer cache. On Linux you can write directly to the device node (make sure to enable O_DIRECT and make your write sizes big enough).
EDIT: added a quote to clarify context
The point in time where you're splitting your codebase up in modules (or maybe are a proponent of hexagonal architecture and have designed it that way from the beginning), leading to being able to put functionality behind feature flags. That way, you can still run it either as a single instance monolith, or a set of horizontally scaled instances with a few particular feature flags enabled (e.g. multiple web API instances) and maybe some others as vertically scaled monoliths (e.g. scheduled report instance).
I wrote more about that approach on my blog, as one of the first articles, "Moduliths: because we need to scale, but we also cannot afford microservices": https://blog.kronis.dev/articles/modulith-because-we-need-to...
In my eyes, the good part is that you can work with one codebase and do refactoring easily across all of it, have better scalability than just a monolith without all of the ops complexity from the outset, while also not having to worry as much about shared code, or perhaps approach the issue gently, by being able to extract code packages at first.
The only serious negatives is that this approach is still more limited than microservices, for example, compilation times in static languages would suffer and depending on how big your project is, there will just be a bit of overhead everywhere, and not every framework supports that approach easily.
In practice, modularization raises uncomfortable questions about ownership which means many critical modules become somewhat abandoned and easily turn into Frankensteins. Can you really change the spec of that module without impacting the unknown use cases it supports? Tooling is not in a position to help you answer that question without high discipline across the team, and we all know what happens if we raise the question on Slack: crickets.
Because services offer clear ownership boundaries and effective tooling across SDLC, even though the overheads of maintenance are higher versus modules, the questions are easier and teams can move forward with their work with fewer stakeholders involved.
I'm left with the feeling that opening a restaurant is hard, but there is nothing to chew on in terms of improving the situation as a citizen or interested party.