Live data from Hacker News

Leaving serverless led to performance improvement and a simplified architecture

unkey.com

261–270 of 272 posts

Re: Leaving serverless led to performance improvement and a simplified architecture

#261
post #109
post #10

Somewhere in Denmark, DHH is smiling

I often don't know what to make of DHH. He's a living contradiction. On one hand he will continually rant about how bad the overhead and waste of cloud services is, and on the other hand he will staunchly defend the most inefficient programming language that is regularly used for backend development, as well as defend the enourmous overfetching that active record leads to. Really I think DHH just likes to tell others…

In all fairness, the performance penalty for virtualization is 4x and the penalty for interpreted code is 1.5x. So he comes out ahead, but its more in a broken watch is right twice a day sort of way.

Re: Leaving serverless led to performance improvement and a simplified architecture

#262

Earlier quoted context omitted.

Hard disagree. I've used Docker predominantly in monoliths, and it has served me well. Before that I used VMs (via Vagrant). Docker certainly makes microservices more tenable because of the lower overhead, but the core tenets of reproducibility and isolation are useful regardless of architecture.

What are you isolating it from? Everything runs on it's own box these days anyway.

Yeah that's becoming increasingly true. I guess it really depends on what your setup is.

Re: Leaving serverless led to performance improvement and a simplified architecture

#263

Earlier quoted context omitted.

Hard disagree. I've used Docker predominantly in monoliths, and it has served me well. Before that I used VMs (via Vagrant). Docker certainly makes microservices more tenable because of the lower overhead, but the core tenets of reproducibility and isolation are useful regardless of architecture.

Depends on the language. Java or Go you really don't need docker.

There's some truth to this too honestly. At $JOB we prototyped one of our projects in Rust to evaluate the language for use, and only started using Docker once we chose to move to .NET, since the Rust deployment story was so seamless.

Re: Leaving serverless led to performance improvement and a simplified architecture

#264

Earlier quoted context omitted.

ECS is good, just expensive and still requires more devops than it should. Docker Swarm is an easy way to run production container services on VMs. I built a free golang tool called Rove that provisions fresh Ubuntu VMs in one command and diffs updates. It's also easy-enough to use Swarm directly.

I’ve used a modified version of this for 8 years - I didn’t write it. Updating your ECS Docker image is just passing in the parameter of your new image and updating the cloudformation stack. https://github.com/1Strategy/fargate-cloudformation-example/...

Thanks for sharing! I'll bookmark that.

Re: Leaving serverless led to performance improvement and a simplified architecture

#265

Earlier quoted context omitted.

ECS is good, just expensive and still requires more devops than it should. Docker Swarm is an easy way to run production container services on VMs. I built a free golang tool called Rove that provisions fresh Ubuntu VMs in one command and diffs updates. It's also easy-enough to use Swarm directly.

Honestly I didn't have a good experience with ECS (Fargate) - I remember I had to write a ton of CF deployment scripts+bash scripts, setting up a private AWS docker registry, having a terrible time debugging while my CF deployment always failed, deploys taking forever, finding out that AWS is too miserly to pay Docker to use the official repo so they are stuck on the free tier, meaning sometimes deploys would fail du…

I posted a link to a CloudFormation template I’ve used to deploy to ECS off an on for 8 years in a sibling reply. It’s stupid simple.

But the easy solution is just to use AWS’s own Docker registry and copy the images to it. Fargate has allowed you to attach EFS volumes for years.

Re: Leaving serverless led to performance improvement and a simplified architecture

#266
post #111

I think developers are drowning in tools to make things "easy", when in truth many problems are already easy with the most basic stuff in our tool belt (a compiler, some bash scripts, and some libraries). You can always build up from there. This tooling fetish hurts both companies and developers.

Yeah; IMO Docker was our last universal improvement to productivity, in 2013, and very little we've invented since then can be said to have had such a wide-ranging positive impact, with such few drawbacks. Some systems are helpful for some companies, but then try to get applied to other companies where they don't make sense and things fall apart or productivity suffers. Cloudflare and others are trying to make v8 iso…

Even better than docker: just run some scripts on the machine.

Re: Leaving serverless led to performance improvement and a simplified architecture

#267
post #163

Earlier quoted context omitted.

The fact is most developers in most companies have very little choice. Many medium to large companies (1k-50k employees) the CTO gets wined and dined by AWS/Azure/Oracle and they decide to move to that cloud. They bring in their solutions architects and do the training. The corporate architects for the divisions set the goals. So the rank and file developers get told that they have to make this work in AWS using RDS…

It doesn't even have to be in companies that big. The AWS salespeople took the CTO and a couple of directors of engineering for diner in a fancy restaurant. That was in a fintech that had around 200 employees. AWS also paid for the mandatory marketing... sorry, mandatory training sessions we tech managers had to do. This is how much it takes for a CTO to demand the next week that "everything should be done with AWS c…

If the wined and dined CTO doesn't care about the costs, then the team shouldn't care either.

Re: Leaving serverless led to performance improvement and a simplified architecture

#268

Earlier quoted context omitted.

Hard disagree. I've used Docker predominantly in monoliths, and it has served me well. Before that I used VMs (via Vagrant). Docker certainly makes microservices more tenable because of the lower overhead, but the core tenets of reproducibility and isolation are useful regardless of architecture.

What are you isolating it from? Everything runs on it's own box these days anyway.

Even when running things in their own box, I likely want to isolate things from one another.

For example, different Python apps using different Python versions. venvs are nice but incomplete; you may end up using libraries with system dependencies.

Re: Leaving serverless led to performance improvement and a simplified architecture

#269

Earlier quoted context omitted.

Hard disagree. I've used Docker predominantly in monoliths, and it has served me well. Before that I used VMs (via Vagrant). Docker certainly makes microservices more tenable because of the lower overhead, but the core tenets of reproducibility and isolation are useful regardless of architecture.

Depends on the language. Java or Go you really don't need docker.

Haven't deployed production Java in years, so I won't speak to it. However, even with Go's static binaries, I'd like to leverage the same build and deploy process as other stacks. With Docker a Go service is no different than a Python service. With Docker, I use the same build tool, instrument health checks similarly, etc.

Standardization is major. Every major cloud has one (and often several) container orchestration services, so standardization naturally leads to portability. No lock-in. From my local to the cloud.

Re: Leaving serverless led to performance improvement and a simplified architecture

#270
post #232

Seems like serverless is ideal for that <10$/mo budget sweetspot when you can't yet afford a VPS.

That mythical sweetspot where you can afford extra development work, but cannot afford 10$/month?

Not only is this the case for solo devs, tech partnerships, and spend-averse people who don't do money to time conversions.

But if you have low cash on a company and have excess workforce, you might not necessarily get to a point where you have to fire, but you can spend those, already paid for, man-hours, in migrations and infrastructure to save some cash.

As an added bonus you have tasks to give your otherwise idle workforce to keep them warmed up

Post reply on HN