3 ms·

> I can't help but feel that the cloud infrastructure and microservice movement of the 2010s was.. a scam. I think the general consensus is that the most-root

by 015a 4y ago

> I can't help but feel that the cloud infrastructure and microservice movement of the 2010s was.. a scam. I think the general consensus is that the most-root cause for why cloud infrastructure and microservice architectures matter is more People, less Technology. Its hard to hire highly experienced people, especially at the hundreds-to-thousands of engineers scale that many companies operate at. That, in isolation, is reasonable. The actually uncomfortable question that no one wants to address is: was that a scam. Put another way, how much of that was a zero-interest rate phenomena, and how much "state of art best way to engineer" things was influenced from that, and has root causes in US monetary policy. Between AI and high interest rates: if you're not ready to spend the 2020s questioning every single thing you think you know about software engineering; you won't be long for the industry.

mmmm2 4y ago
My thought on this is we've all been trained to follow the Google approach: thousands of machines, horizontally scalable, to handle any load. But this model was developed in 2004 when they wanted to hold the entire web in memory and could afford the enormous hardware outlay. Computers are so powerful now this may be the wrong instinct. You can mind boggling amounts of processing for say... $30,000 in hardware, and even with redundancy it would be much simpler to manage.
simplotek 4y ago
> I think the general consensus is that the most-root cause for why cloud infrastructure and microservice architectures matter is more People, less Technology. Indeed the main selling point of microservices is People, more specifically how to set hard boundaries on responsibilities and accountability while ensuring independent decision-making. Another important selling point of microservices is flexibility. It's trivial to put together an entirely new service from scratch, written in whatever technology crosses your mind. With microservices you don't even need access to a repo.
- margorczynski 4y ago
  > set hard boundaries on responsibilities and accountability while ensuring independent decision-making This isn't really true as most of the time the services interact heavily and need to be aligned with each other not to break and work properly. And all what you're speaking of can be achieved by properly modularizing the code of a monolithic application. And microservices if you want them can be run on a single machine, you don't need "the cloud" or multiple computers in general to run a bunch of REST apps if your single instance is powerful enough. And for most web apps it is with the currently available hardware.
  - simplotek 4y ago
    > This isn't really true as most of the time the services interact heavily and need to be aligned with each other not to break and work properly. I'm not sure you got the point. The need to provide interfaces and establish contracts and pledge SLAs is irrelevant and a non-issue. Naturally, your goal is to have a perfect uptime and never break interfaces, just like your goal when working on a monolith is to not add broken code that crashes the service. The whole point of microservices is that you are entirely free to make any decision regarding the things you own, and your only constraint is the interfaces you provide and consume, and SLAs. From those interfaces inward, you are totally free to make any decision you think is best without having to bother about anyone else's opinions and technical choices and tastes and permissions. You can run one service behind your interface or hundreds. As long as your interfaces are up, you can do whatever you like. That greatly simplifies your problem domain. > And all what you're speaking of can be achieved by properly modularizing the code of a monolithic application. No, no you can't. Think about it for a second: can you pick your software stack? Can you pick what dependencies you adopt? Can you rewrite your code in any other language? Etc etc etc. Your hands are tied left and right.
    - danjac 4y ago
      While picking any stack you want may sound wonderful to the individual developer, it's less so for the company as a whole that has to maintain different languages and frameworks, when that developer moves on and now they have to find or hire someone else to keep that service running.

by 015a 4y ago

mmmm2 4y ago

My thought on this is we've all been trained to follow the Google approach: thousands of machines, horizontally scalable, to handle any load. But this model was developed in 2004 when they wanted to hold the entire web in memory and could afford the enormous hardware outlay. Computers are so powerful now this may be the wrong instinct. You can mind boggling amounts of processing for say... $30,000 in hardware, and even with redundancy it would be much simpler to manage.

simplotek 4y ago

> I think the general consensus is that the most-root cause for why cloud infrastructure and microservice architectures matter is more People, less Technology. Indeed the main selling point of microservices is People, more specifically how to set hard boundaries on responsibilities and accountability while ensuring independent decision-making. Another important selling point of microservices is flexibility. It's trivial to put together an entirely new service from scratch, written in whatever technology crosses your mind. With microservices you don't even need access to a repo.

margorczynski 4y ago
> set hard boundaries on responsibilities and accountability while ensuring independent decision-making This isn't really true as most of the time the services interact heavily and need to be aligned with each other not to break and work properly. And all what you're speaking of can be achieved by properly modularizing the code of a monolithic application. And microservices if you want them can be run on a single machine, you don't need "the cloud" or multiple computers in general to run a bunch of REST apps if your single instance is powerful enough. And for most web apps it is with the currently available hardware.
- simplotek 4y ago
  > This isn't really true as most of the time the services interact heavily and need to be aligned with each other not to break and work properly. I'm not sure you got the point. The need to provide interfaces and establish contracts and pledge SLAs is irrelevant and a non-issue. Naturally, your goal is to have a perfect uptime and never break interfaces, just like your goal when working on a monolith is to not add broken code that crashes the service. The whole point of microservices is that you are entirely free to make any decision regarding the things you own, and your only constraint is the interfaces you provide and consume, and SLAs. From those interfaces inward, you are totally free to make any decision you think is best without having to bother about anyone else's opinions and technical choices and tastes and permissions. You can run one service behind your interface or hundreds. As long as your interfaces are up, you can do whatever you like. That greatly simplifies your problem domain. > And all what you're speaking of can be achieved by properly modularizing the code of a monolithic application. No, no you can't. Think about it for a second: can you pick your software stack? Can you pick what dependencies you adopt? Can you rewrite your code in any other language? Etc etc etc. Your hands are tied left and right.
  - danjac 4y ago
    While picking any stack you want may sound wonderful to the individual developer, it's less so for the company as a whole that has to maintain different languages and frameworks, when that developer moves on and now they have to find or hire someone else to keep that service running.