Hacker News Reader

Comment by makestuff | Hacker News Reader

I think the cloud is great; however, most people go way overboard for what they need. You don't need 15 lambdas, 4 micro-services, dynamoDB, API Gateway, etc. to build your internal app that gets 10 TPS. Most engineers over build things because it is how you show "complexity" to get promoted. When in reality a monolith running on some bare metal will work just fine.

I agree with others that the cloud vendors make it complex just to setup a simple service and push you to have these complex architectures. While they are beneficial for availability reasons, I question how often it is really needed.

View on HN

I remember running apps on shared servers that were far weaker than any micro instance you see now. Many services were quick side projects by one or two employees. They didn’t have the same quality as pro teams of 250k / year employees but the business moved forward and rarely got pwnd by some internet exposed endpoint running unpatched Django.

> You don't need 15 lambdas, 4 micro-services, dynamoDB, API Gateway, etc. to build your internal app that gets 10 TPS

I keep trying and failing to make this argument at work. The majority of the team are primarily PHP developers and if you want their best and quickest work they can write you a perfectly good internal service in PHP.

But someone several levels above me drank the kool-aid and now everything takes four times as long and turns out crappy because half the team is spinning wheels learning new proprietary cloud tech and reimplementing the base-level tooling we already had. I am yet to hear any explanation why this cost is worth it beyond vague mutterings of “scalability” and “enterprise”.

We had a “monolithic” on-prem application that was forced to rewrite for cloud.

The original system was blazingly fast — it was actually a set of composable TCP workers and coordinators, but repeatedly called dirty names like monolith, legacy, synchronous by ambitious managers trying to demonstrate the need to migrate. Proceed to bring on legions of contractors and offshore teams to move everything to HTTP and AMQP, fully coupled to the cloud vendor’s mechanisms for these with all of the goodies.

Today they are paying a fortune for a slower system, full vendor lock-in, real customers dismayed and prospective customers aghast at the prices.

Recently they came back to the original engineering teams to “make it a real-time system” and panicked at the realization that this capability was unceremoniously sacrificed in the name of microservices, the cloud for the sake of hot-shot aspiring upper management to make their name in “modernizing” the tech. Yikes

You gotta remember that the optimal career choices of an engineering manager in medium to large enterprise are technically highly destructive to the health of the company and productivity of the people they're managing.

They need to balloon the amount of people they manage and be involved in as many projects as possible for bullet points on their CV when they're applying for the next position.

The cloud is absurdly overpriced. The margins are huge for cloud companies, especially on bandwidth. The gains brought by Moore’s law are pocketed by could providers and barely passed on because once you go “cloud native” they have fairly strong lock in. Even if you can move your work load doing so is painful and usually requires downtime.

It’s also designed to encourage and then monetize a certain style of complex, over-architected, high resource load development: microservices, use of single-cloud-proprietary services, tons of loosely coupled systems, etc. Cloud native is the J2EE of the present era.

This is an anti pattern that keeps happening over and over in our industry. It’s partly a result of the middlebrow meme— that mid developers love complexity— and partly something that is pushed because someone (consultants, cloud providers) are profiting.

Edit: I don’t mean to blast mid developers too much. One must often journey through the middlebrow meme to make it to the hooded dude on the right. The meme describes a learning trajectory. But we should try not to let the complexity explosion of mid developers become industry norm.

I think it's another case of a company's organizational structure being reflected in the code. Conway's Law.

Modern businesses are full of outsourcing, temporary contracts and overdone management structures. This the shape of the software they produce.

Do you count VPSes from Vultr or the like as "the cloud" for this purpose? And, incidentally, are there any VPS providers that you would recommend over Vultr when one doesn't need a whole dedicated machine in a given location?

Haven't seen that middlebrow meme. Perhaps a link?

The gains aren't even "barely passed on". When new generation chips are released, they'll oftentimes release a new instance type at roughly the same price, then re-allocate the older generation chips to power internal services which don't promise a chip family. That internal service might be e.g. S3, so who cares, but it might also be Fargate or Lambda, where you're paying per second of wall time and thus slower chips actively cost you more money.

Tbh, the flexibility can make up for it if you know how to use it right. Sure, the servers might cost 3x as much as what you would pay at a VPS, but you can spin them up and down by the minute.

For one of the projects where the demand appeared during working hours in my timezone, I did the math, and found this to be the case.

>This is an anti pattern that keeps happening over and over in our industry. It’s partly a result of the middlebrow meme— that mid developers love complexity— and partly something that is pushed because someone (consultants, cloud providers) are profiting.

Pretty un-fixable without better stewardship over the software industry. That won't come for decades, so you may as well join the dark side and make the money and practice the way you want with hobbies or start your own company to enforce it.

I guess the stewardship can happen on a team level, but someone who's being restrained can always go find another job where they'll build the complexity they desire that ultimately gets maintained by someone else.

I would add that a huge selling point is the on-demand aspect. You can get VMs/containers/functions running in a few seconds. This is great for experiments, bursting, etc but if you are using compute capacity for a year, it should be understood that you should rent a box instead.

Like, you wouldn't rent a dozen ZipCars every day. If your business required a fleet of cars, you would quickly look for a better arrangement than pay-by-the-minute "convenient" app services.

That's why people here love HetznerCloud. You can create a VM in seconds and be absolutely sure that you will pay no more than €4/month for it, something that AWS can never guarantee.

Exactly. You can run almost for free on Google if you use things like cloudrun and you don't have a lot of traffic. We developed against that for over a year without ever hitting their freemium threshold. This was just a simple development server of course. We transitioned that to a bit more flexible traditional setup with some vms and a load balancer. You can just start a vm with a docker container in Google cloud so it's stupidly easy to deploy dockerized software and do things like rolling updates. With AWS you need things like ECS and some other cruft. Also not the end of the world. But more work.

The mistake most companies and developers make is mapping their organization structure to their deployment architecture. And then over provisioning everything. Kubernetes is the goto solution for companies like that. We spend less on our cloud bills than it costs to spin up even a simple Kubernetes cluster that does basically nothing. It doesn't solve a problem we have because we have a monolith. All I need is two cheap vms and a loadbalancer. If it gets busy, I'll add vms.

There's some other stuff we need, of course. The most expensive thing is actually managed search and databases clusters. They are nice but also pricey.

But from a cost perspective the whole point for me is actually minimizing my time investment. A managed database means I don't need to obsess about uptime, backups, and other things you would normally pay some team to obsess about 24x7. I don't have that and I can actually go on vacation and it's fine.

Of course all this stuff is way overpriced. You get the equivalent of a raspberry pi worth of compute for a monthly price that would allow you to buy several of those. Cloud providers actually put multiple customers on their hardware for the cheaper vms. So, these things are basically paying for their own cost pretty much instantly. When you use a managed database, it runs on shared infrastructure that minimizes resource usage. So why is that more expensive than a non managed one that has more idle resource use? Convenience. It doesn't actually cost them more to manage it. But it's more convenient for you. So they just charge you more for less.

Cloud pricing bears no relationship to actual cost. Which is weird. There should be way more competition on price. But it seems that there just isn't. Of course, people just mindlessly buy AWS because they heard it's good. That's why Amazon is so rich. The retail business is a side hustle for them at this point. And you can get some amazing deals from smaller providers. Hetzner gets mentioned a lot and they are pretty aggressive with their pricing. But it's less convenient.

Reply on news.ycombinator.com