3 ms·

From my years of experience with the industry, ideas like microservices were used way before zero interest rates, and will continue to be used, because they sol

From my years of experience with the industry, ideas like microservices were used way before zero interest rates, and will continue to be used, because they solve actual real problems many people have. Not saying it's always the best approach - as I mentioned, where I worked it was always under heavy scrutiny and chosen only if it was the best approach, which wasn't always.

financltravsty 2y ago
Yes, but it is now impossible to separate them from the hype (same as functional programming languages, cloud providers, etc.). They will continue to be used, but their proliferation into contexts where they are not the best tool (MongoDB as a shining example) was very much a part of the ZIRP environment (the underlying reasons are numerous).
rvz 2y ago
> From my years of experience with the industry, ideas like microservices were used way before zero interest rates, and will continue to be used, because they solve actual real problems many people have. It is one of the many ways for a VC funded company to quickly run out of money. Given that companies such as Uber and Monzo proudly report that they have thousands upon thousands of micro-services with other startups copying that due to the micro-services hype, I can only see that as a way to introduce more problems such as more operational costs and significant complexity to engineers. Microservices was indeed a ZIRP idea taken to the extreme in many startups believing they could scale like Google, except that they could not afford to and most of them either bankrupted themselves or are still losing hundreds of thousands a month on this idea and are cutting down on the micro-services fad to save money.
- throwaway11460 2y ago
  Hmm... I know we're on a startup site, but that's really only a very small part of the business world. Microservice architecture/SOA as we used to call it is successfuly employed at many more traditional small, middle and large enterprises and it has nothing to do with interest rates at these places.
mike_hearn 2y ago
Hmm how many years are you going back? ZIRP in the USA began around 2008 and "microservices" as a word didn't really start being used until several years after that: https://books.google.com/ngrams/graph?content=microservices&year_start=2000&year_end=2019&corpus=en-2019&smoothing=3 https://books.google.com/ngrams/graph?content=microservices&... We can debate what DHH really means when he says microservices. Distributed systems are obviously a lot older than the term microservices. But I think he's talking about systems that compromise many services that don't obviously map to hardware or organizational boundaries, which was the original reason you'd split a program up across multiple independent servers. I have to admit I don't recall encountering that trend before 2011 or so. If you take an app written in the 2000-2010 era e.g. Jira, they're all going to be either monoliths or apps loaded into Java app servers.
- throwaway11460 2y ago
  It was called service oriented architecture before microservices, and the concept itself is way older in the mainframe world; not sure if it actually had a name because it was simply the way it needs to be done. Unix is basically microservices - and back in the 80s and early 90s even network services were built with the Unix philosophy, remember CGI? The Microsoft/Windows world was no stranger to it too - Corba (1991), D-COM (1996), SOAP (1998), WCF (2006) and now it's REST. Software systems on mainframes were comparable to what we call serverless today - having more external interfaces (like HTTP servers) running on a computer would waste resources, there was one common external interface that invoked code on request based on configuration, and that code delegated heavily to specialized systems - since there wasn't even enough program memory and loading from disk was slow. Having multiple layers of backend systems was normal. Queues and batch job processing was usual too, and frontend systems usually provided precalculated data only, transactions were processed through the night. Monoliths were actually the "cool new thing" started in late 90s and perpetuated by Java, PHP, Python and Ruby devs later on, they claimed it's easier to develop and deploy. Many people saw it as a conflict between corporate and startup software development practices - the boring engineers in suits always talking about service specifications and requirements for months VS the cool hackers that don't care and develop directly on prod server FTP to deliver a feature over the weekend. JIRA was one of these cool hacker startups. I don't think the hackers were completely wrong and delivering quickly has value, but it's much more nuanced than "ZIRP bad because ZIRP made microservices", see also my other comment there: https://news.ycombinator.com/item?id=40334281 https://news.ycombinator.com/item?id=40334281

financltravsty 2y ago

Yes, but it is now impossible to separate them from the hype (same as functional programming languages, cloud providers, etc.). They will continue to be used, but their proliferation into contexts where they are not the best tool (MongoDB as a shining example) was very much a part of the ZIRP environment (the underlying reasons are numerous).

rvz 2y ago

> From my years of experience with the industry, ideas like microservices were used way before zero interest rates, and will continue to be used, because they solve actual real problems many people have. It is one of the many ways for a VC funded company to quickly run out of money. Given that companies such as Uber and Monzo proudly report that they have thousands upon thousands of micro-services with other startups copying that due to the micro-services hype, I can only see that as a way to introduce more problems such as more operational costs and significant complexity to engineers. Microservices was indeed a ZIRP idea taken to the extreme in many startups believing they could scale like Google, except that they could not afford to and most of them either bankrupted themselves or are still losing hundreds of thousands a month on this idea and are cutting down on the micro-services fad to save money.

throwaway11460 2y ago
Hmm... I know we're on a startup site, but that's really only a very small part of the business world. Microservice architecture/SOA as we used to call it is successfuly employed at many more traditional small, middle and large enterprises and it has nothing to do with interest rates at these places.

mike_hearn 2y ago

Hmm how many years are you going back? ZIRP in the USA began around 2008 and "microservices" as a word didn't really start being used until several years after that: https://books.google.com/ngrams/graph?content=microservices&year_start=2000&year_end=2019&corpus=en-2019&smoothing=3 https://books.google.com/ngrams/graph?content=microservices&... We can debate what DHH really means when he says microservices. Distributed systems are obviously a lot older than the term microservices. But I think he's talking about systems that compromise many services that don't obviously map to hardware or organizational boundaries, which was the original reason you'd split a program up across multiple independent servers. I have to admit I don't recall encountering that trend before 2011 or so. If you take an app written in the 2000-2010 era e.g. Jira, they're all going to be either monoliths or apps loaded into Java app servers.

throwaway11460 2y ago
It was called service oriented architecture before microservices, and the concept itself is way older in the mainframe world; not sure if it actually had a name because it was simply the way it needs to be done. Unix is basically microservices - and back in the 80s and early 90s even network services were built with the Unix philosophy, remember CGI? The Microsoft/Windows world was no stranger to it too - Corba (1991), D-COM (1996), SOAP (1998), WCF (2006) and now it's REST. Software systems on mainframes were comparable to what we call serverless today - having more external interfaces (like HTTP servers) running on a computer would waste resources, there was one common external interface that invoked code on request based on configuration, and that code delegated heavily to specialized systems - since there wasn't even enough program memory and loading from disk was slow. Having multiple layers of backend systems was normal. Queues and batch job processing was usual too, and frontend systems usually provided precalculated data only, transactions were processed through the night. Monoliths were actually the "cool new thing" started in late 90s and perpetuated by Java, PHP, Python and Ruby devs later on, they claimed it's easier to develop and deploy. Many people saw it as a conflict between corporate and startup software development practices - the boring engineers in suits always talking about service specifications and requirements for months VS the cool hackers that don't care and develop directly on prod server FTP to deliver a feature over the weekend. JIRA was one of these cool hacker startups. I don't think the hackers were completely wrong and delivering quickly has value, but it's much more nuanced than "ZIRP bad because ZIRP made microservices", see also my other comment there: https://news.ycombinator.com/item?id=40334281 https://news.ycombinator.com/item?id=40334281