5 ms·

Did the cloud made us over-engineer some systems that could have been simpler?

42 points by alexzeitler 3y ago

jsiepkes 3y ago
I wish I had a time machine, go 15 years in the past and could watch the expression on peoples faces when I tell them: "You think J2EE with EJB has gone too far? Let me show you this microservice application architecture and the accompanying tracing, observation, instrumentation, service mesh and sidecars from the future! But wait, there is more! We have a thing we call....Devops!"
- theyinwhy 3y ago
  Oh yes, the great times when root was a god. /s
  - agilob 3y ago
    ssh root@master.lan vi /var/www/index.php Bug fixed boss!
    - trog 3y ago
      I know this is a joke and an objectively terrible practice in many ways - but I still do this on many personal projects and the productivity boost feels amazing. Sure, it doesn't scale and there a a host of problems with it. But I still long for the days.
      - theyinwhy 3y ago
        Ok, let's talk about why fixing it directly on production is a bad idea. Again... deep breath
    - theyinwhy 3y ago
      Ok, let's talk about why fixing it directly on production is a bad idea. Again... sigh
- adhesive_wombat 3y ago
  ... And yet most of it still uses Jenkins in there somewhere!
- ASalazarMX 3y ago
  "It became so complex that we had to invent a use a new word: 'orchestration'"
Nextgrid 3y ago
The cloud has eaten all the hardware improvements of the last decade. It's insane that my base model Macbook routinely outperforms the (expensive!) AWS crap that most companies use as their application "servers" and yet it's the reality in many places. So to a certain extent, you are forced to over-engineer for distributed workloads because any single node has the performance of a pocket calculator. This obviously benefits the cloud provider because not only do you rent more resources from them but you now rely on their management platform to orchestrate all those workloads.
- deleted 3y ago
  [deleted]
- agilob 3y ago
  Even more crazy that single AWS server class has 30% difference in performance between instances depending on performed tasks.
- grogenaut 3y ago
  My r7g.16xl absolutely smokes my maxed out m2 max 16". I had to spin it up as I was sending my m2 into thermal shutdown. Task that takes 2.5 hours on the m2 max takes 8 minutes on the r7g. I'm crunching about 16tb of log files streamed from s3 and collating to parquet. I even ran it from the office on Ethernet on Amazon's corp net and it was still much faster on CPU and net. I even tested it with everything locally on disk. Not even close. The r7g is cranking along at 5.2ghz all cores all day.
  - Nextgrid 3y ago
    I don't doubt you can find an instance that smokes your average workstation. The question is how much more does it cost over just buying the equivalent machine outright. Is the markup reasonable, is it crazy, or is it an outright scam such as charging for egress data? Knowing AWS, it definitely won't be the first option, because why would it be if people are willing to pay more?
    - dijit 3y ago
spyke112 3y ago
Yes, I’ve been freelancing for a company making a couple of billions in revenue here in Denmark, where basically the most critical infrastructure is running on maybe 2-4 windows boxes with a big mssql database backing it. They are serving a lot of daily transactions because they among other things primarily sells gas.
- ASalazarMX 3y ago
  On-premises simplifies everything, from backups to response time. The only big advantage of the cloud is scaling on-demand, and managed applications like dedicated Wordpress instances. For stable, general-purpose computing workloads, on-premises rules.
  - spyke112 3y ago
    This case is also extremely simplified by the fact that the customer only serves users nationally in Denmark. They even got away with running their own fully redundant DC in the basement, and i suspect even with really great latency to customers, compared with running of servers in Germany for instance.
tutfbhuf 3y ago
I would like to take a stance on one aspect of this argument, namley costs. If you design it smart than your application can scale both ways not just up, but also down, even down to zero in some cases. So as soon your app is not used anymore or not used as much the costs should go down. If you buy the hardware or rent it and calucluate the costs up front for one year, then its not that easy.
davedx 3y ago
Yup. That’s the cloud working as intended: every slightly different functional component split into its own AWS (or whatever) service, with its own IAM roles and billable usage. Then we decided it wasn’t enough and we wanted kubernetes in our cloud architecture too.
- JohnMakin 3y ago
  There are plenty of AWS services that have nearly totally abstracted away complexity and work mostly out of the box for simple use cases.
Animats 3y ago
FCGI and Go connected to Postgres/MySQL can handle quite a bit of load in a very simple environment. You can run those on shared hosting very cheaply. Do you really need more? Remember Soylent boasting about their "tech stack"? It was just a shopping cart for something that sold a few items per minute. They could have run that thing on a starter account on Dreamhost or HostGator.
neonate 3y ago
https://nitter.net/dominicstpierre/status/1737069029976617420 https://nitter.net/dominicstpierre/status/173706902997661742...
preommr 3y ago
Depends: No, if the goal is job security. Yes, if the goal is to build the product.
- adhesive_wombat 3y ago
  Excuse me brother, did you forget DevOps scripture may not be uttered outside sanctified Discord churches?
stephenboyd 3y ago
“hundreds of micro-services for a web application that barely have 1k concurrent users.” That would not be appropriate in any of the mainstream cloud-native architecture styles.
- KaiserPro 3y ago
  > That would not be appropriate in any of the mainstream cloud-native architecture styles. I mean it ends up being like that. A significant number of medium sized sites bust out into micro-services at some point. Or they start off as serverless, and realise that actually its not as easy to scale as it was claimed.
- ASalazarMX 3y ago
  Unless someone convinced someone that they should prepared in case they become BIG and get millions of concurrent users. And even then, nothing is sure. During the COVID-19 pandemic, Pokémon Go, thanks to an adaptation of game mechanics, literally exploded in users. Despite being world-scale, they struggled for a couple of weeks to meet the workload. World-scale naturally degrades to normal-scale if you don't stress it regularly.
rockemsockem 3y ago
The cloud didn't make anyone over-engineer things. The same folks who overused all the patterns mentioned would have overused other patterns in other contexts if those were the dominant paradigms instead. Microservices are great when you have different workloads with vastly different performance needs. They're not great when you essentially have a single function running on an entire service. Many things will always be over-engineered because simplicity is hard.
RajT88 3y ago
Microservice architecture is not the same thing as Cloud architecture. Plenty of companies run IaaS heavy applications in the cloud at scale, and do so cost-effectively. There is some extra overhead in writing automation around it, and as well performing cost management (cloud finance roles are a new and weird job title, for example). For sure I've seen it done. It's not necessarily the easiest thing, but it's doable. Just like I've also seen Microservice architecture outside of the cloud. And monolith architecture inside the cloud.
erulabs 3y ago
Yes of course. If we could have run our own custom data centers, our software could have been simpler. What you’re not factoring in WRT the cloud is how complex maintaining an air conditioning unit is, or servicing diesel generators. (List continues for several hundreds of man hours a week of work). Your company has saved tremendous complexity. Your software has eaten some of that complexity. Yes, keep it simple when you can. No, major applications that serve millions of users globally can’t run on your laptop “because SQLite is fast!”.
- Nextgrid 3y ago
  Hosting providers have been managing uninterrupted power and airconditioning for decades at reasonable costs. There's options for every budget, from the cheapest (Hetzner, OVH) to more expensive (Equinix Metal, Deft, etc). I'm not sure why this trope keeps getting peddled again and again. Is it obtuse career-driven thinking (someone's salary depends on pretending not to understand?), or am I really getting that old that there's an entire new generation of engineers not aware how hosting was done before 1000%-markup "cloud" providers entered the industry?
  - erulabs 3y ago
    I mean, I don’t believe my resume should be required to backup my point, but I literally maintained AC units and refueled diesel generators in datacenter as a kid. Obviously there’s more to it than A/C: and yes Equinix does a lot, but it’s the same trade off: slightly more complex software to eliminate non-company-specific specialities. Yes it’s worth it, my evidence is that infrastructure engineers I’ve met aren’t stupid.
    - Nextgrid 3y ago
      I don't understand what in your mind makes overpriced cloud good while non-overpriced cloud (or "hosting" as we used to call it) bad? Both manage air conditioning, power, fire suppression, etc and ultimately live and die by their uptime, so they have an incentive to do it right.
whoomp12341 3y ago
They are complex for a reason. There was an engineer who wanted to add that thing to their resume
thinkingkong 3y ago
The problem isnt over-engineering, it’s not engineering at all. How many teams design for scale and then forget the number? The assumption that the entire system needs to scale to the population of the planet in 2050 workloads? Most developers wont even napkin math 3pp API calls. Theres no upper and lower bounds on things. Theres few constraints other than “use AWS”. Its the engineering equivalent of saying “use mcmaster-carr” then shrugging and walking off.
samsquire 3y ago
I've often thought "what is the minimum stack, with minimum moving parts that just scales endlessly?" If you reduced all the data flow of your distributed software (10,000s of machines, 100,000s of containers) to the number of positions that where each value is at to just an integer, could the position and movement of all values be traversable on a single thread on a single machine and calculated in a tiny amount of time? What's the O notation to your system's data flow? I've this intuition and feeling that logistics and movement underlies the complexity of computer systems and that it's the shipping bits and dispatching everywhere is the complex part. If we could write a formally verified state space with software similar to TLA+ and formal methods, we could generate all the plumbing. Compilers work out how to place things in a calling convention, REST APIs and event queues schemas are just the same thing except we do it manually.
- KaiserPro 3y ago
  or just buy an IBM mainframe. let the hardware and OS figure that shit out.
lijok 3y ago
> Do we really need event-driven architecture, serverless functions, hundreds of micro-services for a web application that barely have 1k concurrent users This is verbatim the thinking that led to needless overengineering - focusing on number of concurrent users as the only requirement and metric of success. You may require event-driven architectures, serverless functions, etc to meet business requirements, regardless of how many concurrent users you have.
acdha 3y ago
Betteridge’s law applies here. The underlying problem is not “the cloud” but whether your organization has a handle on managing complexity and costs. 20 years ago, the same “architects” were telling everyone you had to build clusters of enterprise Java application servers where no stack trace is less than 200 levels deep. I certainly saw plenty of apps with millions of dollars in hardware load balancers, expensive licensed Java app servers, Oracle HA databases, etc. which were comically outperformed by a Linux box or two running PHP and MySQL (which usually had better reliability, too, since there was so much less to break). Cloud applications can be simplicity wins or losses depending on your business culture. If you keep it simple, you’re running a couple of Lambda functions or something like an ECS Fargate container, S3, RDS, etc. and saving a ton of time versus both the places rolling their own Cloud-ception K8S platform _and_ the people running a fleet of full servers in their own data center. In both cases, it’s a question of whether you’re adding complexity because the business problems require it or because it’s more fun to work on / looks better on your CV.
MadVikingGod 3y ago
No. No more than anyone made Motorolla over-engineer the first cellphone. We have been over-engineering long before the cloud and will continue long after. Did it make it easy to over-engineer? Yes. Is it more common for things to be over-engineered? Probably. Does this question gloss over the actual cost of getting something running that is useable by more than a handful of people? Yes. Would I ever want to go back and write code like we did 20+ years ago? Nope.
pauljonas 3y ago
Yes. Partly because of ephemeral nature of most cloud platforms / services, and also the vagaries of proprietary specific configuration.
KaiserPro 3y ago
Yes, and no. on the one hand lambda means that you almost nothing in view between you and an HTTP endpoint. However, a lot of "cloud engineering" is based on two limitations that were inherent to AWS: 1) no machine migration (ie the ability to move a VM to a new host without downtime) 2) No large scale posix file system. this forced people for good or ill to push lots of things to s3 (a slow, inflexible but ultimately easy enough for 70% of cases). It also meant that people started to go batshit for storing state in unusual ways. Allowing for recovery when having to rebuild machines. Has EC2 had some of the features that VMware had at the time (I suspect xen had it too, but it was too hard to scale or secure) the world would look more like mainframes, rather than "cloud".
- dijit 3y ago
  Start looking at Google cloud. They have VM migration built in and it's transparent as heck. Basically seamless. You might miss a single packet (in my observed experience). This was one of the main reasons I chose them. They also have managed NFS, but I can't speak to the quality as I've never used it: https://cloud.google.com/architecture/partners/netapp-cloud-volumes/creating-nfs-volumes https://cloud.google.com/architecture/partners/netapp-cloud-...
  - KaiserPro 3y ago
    Its always been possible, its just AWS offered something good enough first. its a lesson for us in programming when AI starts to automate large parts of it. Being techincally the best is nothing when you can replace slow hard to build things with shitter but significantly faster to deploy things.
tomohawk 3y ago
Wierd that this is flagged. I was called in to fix an ETL job that took over 24 hours using all the cloud services. Wrote a go program that did it in less that 15m.
- ASalazarMX 3y ago
  Unjustified flagging in my opinion. It would be nice if flagging required to select which guideline is being broken, so others can see the weighted reasons for flagging. More anecdata: we have cloud backups that take hours, while on-premises backups of the same VM take minutes. The quirks of cloud have added complexity to our housekeeping.
  - dijit 3y ago
    My theory is that the HN audience is filled with: A) People working at cloud providers who have a financial incentive to demerit any anti-cloud sentiment B) People who do not know what life was like before cloud and think it means that developers will have to go and build datacenters C) People who don't really care about the cost because it's their employer that foots the bill, they just know that working in cloud pays more so they want the gravy train of inscrutable services and will ride the sunk cost fallacy. D) People who genuinely don't understand how servers work and it scares them that someone might have different technical knowledge than them in the company... and they might be able to say no to them. I could be wrong, but if any of the above is true then it explains why people keep bringing out the same tired arguments that show no weight (more staff/build datacenters from atoms of sand) and articles like this get flagged immediately. --- of course it could also be that the discussion becomes a tired circlejerk and lacks any intellectual curiosity, however I don't believe that.
    - BackBlast 3y ago
      Keep in mind that the number of devs that are inexperienced is very high. Growth in the industry has been explosive. So there is a large population of devs that just don't understand how one might reasonably live, and even prosper, on the literal server in the basement or closet. Doing so sounds scary and arcane. They have never experienced the old memes of tripping on server power cables and backhoes accidentally digging through your network line being among the more dangerous events in life. Among the older devs, a sizable amount of them worked in large companies with ineffectual IT departments where the cloud also meant scrapping the red tape in favor of shadow-IT and actually being able to get stuff done. They, largely, think the cloud is the greatest because it materially improved their lives in poorly run organizations. So it simply must be grand. With these motivations you can come up with any number of arguments that sound plausible to defend the cloud. There are a few people with significant experience on both sides, that advocate for cloud. I must conclude that their experience largely falls into the few buckets where it does tend to make sense. My experience is that cloud is insanely expensive - if you can run and keep a competent IT dept.
nathants 3y ago
cloud is good. it is a new option. most interesting new options come inescapably with new potentials for abuse. personally, my most interesting work is bootstrapping nights and weekends. the optionality of cloud opens entire new fields here. this is good. in day to day enterprise engineering, cloud isn’t as disruptive. i see the inefficiency in enterprise cloud as a failure of the education system. what could have been learned in throw away school projects is instead learned in throw away enterprise projects. market inefficiency aside, it’s fine. cloud isn’t the first footgun, and won’t be the last. education remains the only answer.

42 points by alexzeitler 3y ago

I wish I had a time machine, go 15 years in the past and could watch the expression on peoples faces when I tell them: "You think J2EE with EJB has gone too far? Let me show you this microservice application architecture and the accompanying tracing, observation, instrumentation, service mesh and sidecars from the future! But wait, there is more! We have a thing we call....Devops!"

theyinwhy 3y ago
Oh yes, the great times when root was a god. /s
- agilob 3y ago
  ssh root@master.lan vi /var/www/index.php Bug fixed boss!
  - trog 3y ago
    I know this is a joke and an objectively terrible practice in many ways - but I still do this on many personal projects and the productivity boost feels amazing. Sure, it doesn't scale and there a a host of problems with it. But I still long for the days.
    - theyinwhy 3y ago
      Ok, let's talk about why fixing it directly on production is a bad idea. Again... deep breath
  - theyinwhy 3y ago
    Ok, let's talk about why fixing it directly on production is a bad idea. Again... sigh
adhesive_wombat 3y ago
... And yet most of it still uses Jenkins in there somewhere!
ASalazarMX 3y ago
"It became so complex that we had to invent a use a new word: 'orchestration'"

Nextgrid 3y ago

The cloud has eaten all the hardware improvements of the last decade. It's insane that my base model Macbook routinely outperforms the (expensive!) AWS crap that most companies use as their application "servers" and yet it's the reality in many places. So to a certain extent, you are forced to over-engineer for distributed workloads because any single node has the performance of a pocket calculator. This obviously benefits the cloud provider because not only do you rent more resources from them but you now rely on their management platform to orchestrate all those workloads.

deleted 3y ago
[deleted]
agilob 3y ago
Even more crazy that single AWS server class has 30% difference in performance between instances depending on performed tasks.
grogenaut 3y ago
My r7g.16xl absolutely smokes my maxed out m2 max 16". I had to spin it up as I was sending my m2 into thermal shutdown. Task that takes 2.5 hours on the m2 max takes 8 minutes on the r7g. I'm crunching about 16tb of log files streamed from s3 and collating to parquet. I even ran it from the office on Ethernet on Amazon's corp net and it was still much faster on CPU and net. I even tested it with everything locally on disk. Not even close. The r7g is cranking along at 5.2ghz all cores all day.
- Nextgrid 3y ago
  I don't doubt you can find an instance that smokes your average workstation. The question is how much more does it cost over just buying the equivalent machine outright. Is the markup reasonable, is it crazy, or is it an outright scam such as charging for egress data? Knowing AWS, it definitely won't be the first option, because why would it be if people are willing to pay more?
  - dijit 3y ago

spyke112 3y ago

Yes, I’ve been freelancing for a company making a couple of billions in revenue here in Denmark, where basically the most critical infrastructure is running on maybe 2-4 windows boxes with a big mssql database backing it. They are serving a lot of daily transactions because they among other things primarily sells gas.

ASalazarMX 3y ago
On-premises simplifies everything, from backups to response time. The only big advantage of the cloud is scaling on-demand, and managed applications like dedicated Wordpress instances. For stable, general-purpose computing workloads, on-premises rules.
- spyke112 3y ago
  This case is also extremely simplified by the fact that the customer only serves users nationally in Denmark. They even got away with running their own fully redundant DC in the basement, and i suspect even with really great latency to customers, compared with running of servers in Germany for instance.

tutfbhuf 3y ago

I would like to take a stance on one aspect of this argument, namley costs. If you design it smart than your application can scale both ways not just up, but also down, even down to zero in some cases. So as soon your app is not used anymore or not used as much the costs should go down. If you buy the hardware or rent it and calucluate the costs up front for one year, then its not that easy.

davedx 3y ago

Yup. That’s the cloud working as intended: every slightly different functional component split into its own AWS (or whatever) service, with its own IAM roles and billable usage. Then we decided it wasn’t enough and we wanted kubernetes in our cloud architecture too.

JohnMakin 3y ago
There are plenty of AWS services that have nearly totally abstracted away complexity and work mostly out of the box for simple use cases.

Animats 3y ago

FCGI and Go connected to Postgres/MySQL can handle quite a bit of load in a very simple environment. You can run those on shared hosting very cheaply. Do you really need more? Remember Soylent boasting about their "tech stack"? It was just a shopping cart for something that sold a few items per minute. They could have run that thing on a starter account on Dreamhost or HostGator.

neonate 3y ago

https://nitter.net/dominicstpierre/status/1737069029976617420 https://nitter.net/dominicstpierre/status/173706902997661742...

preommr 3y ago

Depends: No, if the goal is job security. Yes, if the goal is to build the product.

adhesive_wombat 3y ago
Excuse me brother, did you forget DevOps scripture may not be uttered outside sanctified Discord churches?

stephenboyd 3y ago

“hundreds of micro-services for a web application that barely have 1k concurrent users.” That would not be appropriate in any of the mainstream cloud-native architecture styles.

KaiserPro 3y ago
> That would not be appropriate in any of the mainstream cloud-native architecture styles. I mean it ends up being like that. A significant number of medium sized sites bust out into micro-services at some point. Or they start off as serverless, and realise that actually its not as easy to scale as it was claimed.
ASalazarMX 3y ago
Unless someone convinced someone that they should prepared in case they become BIG and get millions of concurrent users. And even then, nothing is sure. During the COVID-19 pandemic, Pokémon Go, thanks to an adaptation of game mechanics, literally exploded in users. Despite being world-scale, they struggled for a couple of weeks to meet the workload. World-scale naturally degrades to normal-scale if you don't stress it regularly.

rockemsockem 3y ago

The cloud didn't make anyone over-engineer things. The same folks who overused all the patterns mentioned would have overused other patterns in other contexts if those were the dominant paradigms instead. Microservices are great when you have different workloads with vastly different performance needs. They're not great when you essentially have a single function running on an entire service. Many things will always be over-engineered because simplicity is hard.

RajT88 3y ago

Microservice architecture is not the same thing as Cloud architecture. Plenty of companies run IaaS heavy applications in the cloud at scale, and do so cost-effectively. There is some extra overhead in writing automation around it, and as well performing cost management (cloud finance roles are a new and weird job title, for example). For sure I've seen it done. It's not necessarily the easiest thing, but it's doable. Just like I've also seen Microservice architecture outside of the cloud. And monolith architecture inside the cloud.

erulabs 3y ago

Yes of course. If we could have run our own custom data centers, our software could have been simpler. What you’re not factoring in WRT the cloud is how complex maintaining an air conditioning unit is, or servicing diesel generators. (List continues for several hundreds of man hours a week of work). Your company has saved tremendous complexity. Your software has eaten some of that complexity. Yes, keep it simple when you can. No, major applications that serve millions of users globally can’t run on your laptop “because SQLite is fast!”.

Nextgrid 3y ago
Hosting providers have been managing uninterrupted power and airconditioning for decades at reasonable costs. There's options for every budget, from the cheapest (Hetzner, OVH) to more expensive (Equinix Metal, Deft, etc). I'm not sure why this trope keeps getting peddled again and again. Is it obtuse career-driven thinking (someone's salary depends on pretending not to understand?), or am I really getting that old that there's an entire new generation of engineers not aware how hosting was done before 1000%-markup "cloud" providers entered the industry?
- erulabs 3y ago
  I mean, I don’t believe my resume should be required to backup my point, but I literally maintained AC units and refueled diesel generators in datacenter as a kid. Obviously there’s more to it than A/C: and yes Equinix does a lot, but it’s the same trade off: slightly more complex software to eliminate non-company-specific specialities. Yes it’s worth it, my evidence is that infrastructure engineers I’ve met aren’t stupid.
  - Nextgrid 3y ago
    I don't understand what in your mind makes overpriced cloud good while non-overpriced cloud (or "hosting" as we used to call it) bad? Both manage air conditioning, power, fire suppression, etc and ultimately live and die by their uptime, so they have an incentive to do it right.

whoomp12341 3y ago

They are complex for a reason. There was an engineer who wanted to add that thing to their resume

thinkingkong 3y ago

The problem isnt over-engineering, it’s not engineering at all. How many teams design for scale and then forget the number? The assumption that the entire system needs to scale to the population of the planet in 2050 workloads? Most developers wont even napkin math 3pp API calls. Theres no upper and lower bounds on things. Theres few constraints other than “use AWS”. Its the engineering equivalent of saying “use mcmaster-carr” then shrugging and walking off.

samsquire 3y ago

I've often thought "what is the minimum stack, with minimum moving parts that just scales endlessly?" If you reduced all the data flow of your distributed software (10,000s of machines, 100,000s of containers) to the number of positions that where each value is at to just an integer, could the position and movement of all values be traversable on a single thread on a single machine and calculated in a tiny amount of time? What's the O notation to your system's data flow? I've this intuition and feeling that logistics and movement underlies the complexity of computer systems and that it's the shipping bits and dispatching everywhere is the complex part. If we could write a formally verified state space with software similar to TLA+ and formal methods, we could generate all the plumbing. Compilers work out how to place things in a calling convention, REST APIs and event queues schemas are just the same thing except we do it manually.

KaiserPro 3y ago
or just buy an IBM mainframe. let the hardware and OS figure that shit out.

lijok 3y ago

> Do we really need event-driven architecture, serverless functions, hundreds of micro-services for a web application that barely have 1k concurrent users This is verbatim the thinking that led to needless overengineering - focusing on number of concurrent users as the only requirement and metric of success. You may require event-driven architectures, serverless functions, etc to meet business requirements, regardless of how many concurrent users you have.

acdha 3y ago

Betteridge’s law applies here. The underlying problem is not “the cloud” but whether your organization has a handle on managing complexity and costs. 20 years ago, the same “architects” were telling everyone you had to build clusters of enterprise Java application servers where no stack trace is less than 200 levels deep. I certainly saw plenty of apps with millions of dollars in hardware load balancers, expensive licensed Java app servers, Oracle HA databases, etc. which were comically outperformed by a Linux box or two running PHP and MySQL (which usually had better reliability, too, since there was so much less to break). Cloud applications can be simplicity wins or losses depending on your business culture. If you keep it simple, you’re running a couple of Lambda functions or something like an ECS Fargate container, S3, RDS, etc. and saving a ton of time versus both the places rolling their own Cloud-ception K8S platform _and_ the people running a fleet of full servers in their own data center. In both cases, it’s a question of whether you’re adding complexity because the business problems require it or because it’s more fun to work on / looks better on your CV.

MadVikingGod 3y ago

No. No more than anyone made Motorolla over-engineer the first cellphone. We have been over-engineering long before the cloud and will continue long after. Did it make it easy to over-engineer? Yes. Is it more common for things to be over-engineered? Probably. Does this question gloss over the actual cost of getting something running that is useable by more than a handful of people? Yes. Would I ever want to go back and write code like we did 20+ years ago? Nope.

pauljonas 3y ago

Yes. Partly because of ephemeral nature of most cloud platforms / services, and also the vagaries of proprietary specific configuration.

KaiserPro 3y ago

Yes, and no. on the one hand lambda means that you almost nothing in view between you and an HTTP endpoint. However, a lot of "cloud engineering" is based on two limitations that were inherent to AWS: 1) no machine migration (ie the ability to move a VM to a new host without downtime) 2) No large scale posix file system. this forced people for good or ill to push lots of things to s3 (a slow, inflexible but ultimately easy enough for 70% of cases). It also meant that people started to go batshit for storing state in unusual ways. Allowing for recovery when having to rebuild machines. Has EC2 had some of the features that VMware had at the time (I suspect xen had it too, but it was too hard to scale or secure) the world would look more like mainframes, rather than "cloud".

dijit 3y ago
Start looking at Google cloud. They have VM migration built in and it's transparent as heck. Basically seamless. You might miss a single packet (in my observed experience). This was one of the main reasons I chose them. They also have managed NFS, but I can't speak to the quality as I've never used it: https://cloud.google.com/architecture/partners/netapp-cloud-volumes/creating-nfs-volumes https://cloud.google.com/architecture/partners/netapp-cloud-...
- KaiserPro 3y ago
  Its always been possible, its just AWS offered something good enough first. its a lesson for us in programming when AI starts to automate large parts of it. Being techincally the best is nothing when you can replace slow hard to build things with shitter but significantly faster to deploy things.

tomohawk 3y ago

Wierd that this is flagged. I was called in to fix an ETL job that took over 24 hours using all the cloud services. Wrote a go program that did it in less that 15m.

ASalazarMX 3y ago
Unjustified flagging in my opinion. It would be nice if flagging required to select which guideline is being broken, so others can see the weighted reasons for flagging. More anecdata: we have cloud backups that take hours, while on-premises backups of the same VM take minutes. The quirks of cloud have added complexity to our housekeeping.
- dijit 3y ago
  My theory is that the HN audience is filled with: A) People working at cloud providers who have a financial incentive to demerit any anti-cloud sentiment B) People who do not know what life was like before cloud and think it means that developers will have to go and build datacenters C) People who don't really care about the cost because it's their employer that foots the bill, they just know that working in cloud pays more so they want the gravy train of inscrutable services and will ride the sunk cost fallacy. D) People who genuinely don't understand how servers work and it scares them that someone might have different technical knowledge than them in the company... and they might be able to say no to them. I could be wrong, but if any of the above is true then it explains why people keep bringing out the same tired arguments that show no weight (more staff/build datacenters from atoms of sand) and articles like this get flagged immediately. --- of course it could also be that the discussion becomes a tired circlejerk and lacks any intellectual curiosity, however I don't believe that.
  - BackBlast 3y ago
    Keep in mind that the number of devs that are inexperienced is very high. Growth in the industry has been explosive. So there is a large population of devs that just don't understand how one might reasonably live, and even prosper, on the literal server in the basement or closet. Doing so sounds scary and arcane. They have never experienced the old memes of tripping on server power cables and backhoes accidentally digging through your network line being among the more dangerous events in life. Among the older devs, a sizable amount of them worked in large companies with ineffectual IT departments where the cloud also meant scrapping the red tape in favor of shadow-IT and actually being able to get stuff done. They, largely, think the cloud is the greatest because it materially improved their lives in poorly run organizations. So it simply must be grand. With these motivations you can come up with any number of arguments that sound plausible to defend the cloud. There are a few people with significant experience on both sides, that advocate for cloud. I must conclude that their experience largely falls into the few buckets where it does tend to make sense. My experience is that cloud is insanely expensive - if you can run and keep a competent IT dept.

nathants 3y ago

cloud is good. it is a new option. most interesting new options come inescapably with new potentials for abuse. personally, my most interesting work is bootstrapping nights and weekends. the optionality of cloud opens entire new fields here. this is good. in day to day enterprise engineering, cloud isn’t as disruptive. i see the inefficiency in enterprise cloud as a failure of the education system. what could have been learned in throw away school projects is instead learned in throw away enterprise projects. market inefficiency aside, it’s fine. cloud isn’t the first footgun, and won’t be the last. education remains the only answer.