I bet this is happening because in many enterprise applications you do not need high performance. Requirements to a service doing 1000 transactions a day are very different from requirements to a service doing HFT. Service per bounded context may be reasonable choice and Spring Boot/Spring Cloud may be adequate solution for it.

▲

tracker1 a day ago | parent | next [-]

I think this is probably a large part of it... I remember working on an app a few years ago, where it was explicit that it likely wouldn't see more than 15-20 active users at any given deployment... and with the level of normalization at the database layer, and literally 95% of the logic INSIDE the database (sprocs), it was just about falling over on a modest server trying to handle a dozen users.

Worse still, is the variance and onboarding for each customer was taking roughly twice as long as the previous one... I left during the dev cycle to bring in the 4th client. These were state/county agencies, each with slightly differing requirements. I was in charge of the UI and the API for the UI... putting all the logic inside the DB itself was emphatically NOT my decision.

▲

re-thc a day ago | parent | prev [-]

> because in many enterprise applications you do not need high performance

Looking at and having looked at some of their cloud spend etc, nah.

To be more specific there's a lot of fat. Whether that's HFT style high performance is a different story.

	▲	ivan_gammel a day ago \| parent [-]
		You can drop cloud spending by 10x factor and still use Spring Boot comfortably. In startup world exist infra costs benchmarks and they are very generous. That fat does not come from frameworks, it comes from not spending an extra hour on solution design.