Don't start with microservices – monoliths are your friend

As soon as the author started listing things like k8s as needed for microservices it shows they havent stopped to think out side the box. there is no reason you can't run your set of microservices as 3-4 docker containers on the same host, no load balancers, no k8s, no log aggrigation, etc etc etc.

If your application makes sence as microservices you don't need to start with all of that, so including it all in the cost of startup makes no sense at all, as your application starts to scale out and need them, add them at that time, your going to need most of it for a monolith application as well, and some of them you may NEVER need (k8s for example, there is no reason you can't run your application on just plain old compute infrastructure, you don't even need to look at the "cloud" that old box in the corner of your office might be all you need for the project)

if you stop and remember that "microservices" just means small single function services, not things like k8s you will probably find that you can actully do a lot less work if you go down that road by letting other exsisting projects so a whole bunch of the work for you and save you re-inventing the wheel to get your project finished and out the door.

Shudder...a previous team's two primary services were configured in exactly this way (since before I arrived). Trust me, it isn't (and wasn't) a good idea. I had more important battles to fight than splitting them out (and that alone should tell you something of the situation they were in!).

I made the above response with that in mind.

> And regarding the spend: one week worth of work could be USD 8k.

The original claim was that one week's worth could be 8000 USD, or let's say roughly 7094 EUR. That comes out to 28376 EUR per month.

Last month i made around 1700 EUR, so it's possible to calculate approximately how much my work cost to my employer. Let's do that with a calculator here: https://kalkulatori.lv/en/algas-kalkulators

After inputting the data that's relevant to me, i got the following:

  Gross salary                                     2654.51 EUR
  Social tax                                       278.72 EUR
  Personal income tax from income till 1667 EUR    277.66 EUR
  Personal income tax (987.51 EUR), from part ...  227.13 EUR
  Social tax, employer's part                      626.20 EUR
  Business risk fee                                0.36 EUR
  Total employer's expenses                        3281.07 EUR

Thus, per week, 7094 EUR is also a far cry from 820 EUR, which is how much my work cost to my employer.

Also, 820 is actually pretty close to my initial guess of 850 EUR.

Of course, it's possible to argue that either i'm underpaid individually, or that many of my countrymen in Latvia are underpaid in general (on which i elaborated in an adjacent comment https://news.ycombinator.com/item?id=29595158), but then the question becomes... so what?

Does that mean that if you're in a well paid country like US, then you cannot afford proper development practices due to all of the payroll expenses that would cause? While that may well be, to me that sounds weird and plain backwards - if that were really true, then US would outsource even more to countries like mine and these outsourced systems would work amazingly well, since you can supposedly afford a team of developers here for what would buy you a single developer over there. And yet, most systems are still insecure, buggy and slow.

Maybe someone else is pocketing a lot of the money they receive in these countries, and is simply charging high consulting rates? The prevalence of WITCH companies here is telling, but that's a discussion for another time.

Microservices was relly more about locality and the ability to keep data in a memory cache on a thin service. Rather than having catalog data competing with the rest of the monolithic webserver app on the front end webservers, requests went over the network, to a load balancer, they were hashed so that the same request from any of the webservers hit the same catalog server, then that catalog server usually had the right data for the response to be served out of memory.

Most of the catalog data was served from BDB files which had all the non-changing catalog data pushed out to the catalog server (initially this data had been pushed to the webserver). For updates all the catalog servers had real-time updates streamed to them and they wrote to a BDB file which was a log of new updates.

That meant that most of the time the catalog data was served out of a redis-like cache in memory (which due to the load balancer hashing on the request could use the aggregated size of the RAM on the catalog service). Rarely would requests need to hit the disk. And requests never needed to hit SQL and talk to the catalog databases.

In the monolithic world all those catalog requests are generated uniformly across all the webservers so there's no opportunity for locality, each webserver needs to have all the top 100000 items in cache, and that is competing with the whole rest of the application (and that's even after going to the world where its all predigested BDB files with an update service so that you're not talking SQL to databases).