Hacker News Reader

Comment by PragmaticPulp | Hacker News Reader

Actually, rapidly developing a startup (as is the context of this website) is one of the best use cases of cloud services.

It’s true: You can set up and maintain all of your own services, create a backup system for them, test it all, and handle your own redundancy. If you have an engineering background, this probably feels natural and will feel like a lot of progress and accomplishment. But in the time it takes to do all of that (usually distributed and interwoven into other activities) you could have been prototyping out your startup. That’s the value of cloud.

You can always invest the effort into setting up your own services later as a cost reduction move. Doing the cost-reduction activities before you’ve even prototyped a business isn’t a great use of precious time in a startup’s early days.

View on HN

This is why I think we need a 'simple cloud' where people can spin up a single server nearly instantly, with sane defaults which are configurable if needed, and a super simple flow to connect it to GitHub (maybe even "Go to your repo and `curl foo.sh/setup?id=ZnVjayB0ZXJyYWZvcm0K | sh`, then commit the result").

There's so much you could do from a UX point of view. Nobody wants to be fiddling around with IAM roles, trying to add the right ingress rules so their server can actually connect to the internet, configuring TCP_NODELAY, etc - and then constantly wondering if their server is secure. Just to run some CRUD React app whose requirements are the same as the other 99.99% of developers.

You pretty much just described Render. https://render.com

It's not perfect, and there is probably a point in time for a project where you'll need to evaluate other options, but I haven't found much that's better for small-scale stuff if you don't want to think too hard.

(Render founder) thanks for the mention. We have 50+ person companies running entirely on Render with zero devops engineers. The point at which you need to evaluate options is a lot further out than you'd expect (and continues to disappear into the distance).

Hey dude. I've been very happy with the day-job stuff we run in Render, that's why I mentioned it. ;)

If (devops hat on) you want baseline compute/storage, I think I could see running on Render long-term. Where I (speaking personally) get off the ride is when I start needing external stuff, and that's usually pronounced "AWS services". Stuff like SQS and SNS are still The Killer App for AWS for me, and while I was poking at Render for my most recent personal project, it was easier to put compute and data storage into Fargate/RDS and not have to think about multiple control planes.

A seamless, please-not-Terraform way to cross-manage Render resources with other cloud options would be pretty killer. (Which is directly in tension with the discussions of simplicity here. Turns out cloud stuff is hard.)

Completely agreed on building/offering higher-level services like SQS, SNS, S3. We're only at ~10% of where I want the platform to be, which is also why we're hiring quite aggressively!

Heya, sorry for the delayed response (naturally, this being HN, I didn't catch your reply, and you probably won't catch mine, haha).

Thanks very much for the personal message. I'll set up a personal account and give it a spin. My company is a bit more nonchalant about vendor lock-in than I am, and so we're relying on certain AWS services for certain things, but we're also flexible and I'd be very keen to move some stuff onto a service like this.

On a more general note, I really hope you succeed. I believe 95% of developers just want to be able to:

- sign up

- get a machine with an IP(v4) addr

- [wanted/needed but not expected] have some help setting up / hooking up DNS + TLS

- get their application onto it somehow (in order of sophistication: 1: drag-a-folder, 2: shell access to use scp/rsync, 3: GitOps w/ a helpful flow)

- get it running and keep it running

- have some basic monitoring and alerting capacities

- have a sense of assurance that it's 'secure' (I know, this word is as meaningless as 'performant' without further qualification, but that doesn't matter)

I think you could get so far with a "sane defaults, maximally configurable if you wish" model. You may not support computational genomics or FPGA-assisted currency trading, but you can win 100x on UX by not having to play Twister trying to accommodate the long tail of niche users.

The only other bit of vague and cloudy fortune cookie advice I have to offer is: an escape hatch is so important. It's somehow reassuring to know that, if I want to do [thing I can do on AWS but not on Render], that there's some way - however fiddly - for me to connect the two, or replicate that thing. (Being necessarily vague here because I don't have anything particular in mind.)

Anyway - really appreciate your reply, and really appreciate your serving this market. (And please don't offer any credits or anything like that - I know it's common in these threads, but I'm really not fishing for that. We have a fuck ton of VC cash to spend, and I believe in sampling the pricing in the exact same way that I'd be sampling the functionality.)

Hi Founder,

I've been wanting to use render for a long time now at our startup, but last time I looked at your GDPR info it was lacking. We sell to public education institutes in the EU, so it is a make or break for us. We might not be your target customer in that case, but otherwise I would love to hear what is possible.

We already sign DPAs, but expect to see more public information on GDPR later this year.

That's fantastic! I'll have to take a look. Thanks for showing me. I was aware of Heroku, but this seems like the modern equivalent which I had in mind. (I do think you could likely go even simpler, though - there's a whole spectrum of complexity which could accommodate different services at each point.)

Edit: Apropos of "there's a point in time where you'll need to evaluate other options": I think a good selling point would be a well-designed flow for 'ejecting' to a self-hosted or AWS/GCP environment. Yeah, yeah, it's not good for lock-in, but by the exact same token it would be a strong selling point. Done well, you could assuage the "we may as well get it out of the way now" concerns by saying that you'll make it easier to set up shop on AWS.

I've been running a SaaS on Render for about a year now. In past lives, I managed ~$50k/mo of AWS spend for one company and $1k/mo of Heroku spend for another.

Render's great for letting us just focus on the app. There are things I want them to improve, but I'm confident they'll get there eventually.

Lots of improvements and additions planned for the coming months. Thank you for sticking with us.

You could go simpler than Render, and some folks do--but you go simpler at the cost of drastically reducing the value of a thing for whole categories of non-toy projects. For example, if you want to host a static thing there are a lot of pretty easy options, but the second you need something as foreign to the "JAMstack ideal" as "a datastore" like "for a blog with comments" now you're in multiple control panels and you're shuttling secrets around and you're confronted with paying multiple companies just to launch a blog and the whole thing physically hurts.

Some mild complexity in deploy (and it is mild, a render.yaml file in your repo's super easy) comes from having the options to actually do things, I think.

Once you understand how to deploy into AWS, it really is quite simple, and honestly not that expensive. It takes... a day or so of work to get those "IAM roles" and "ingress rules" right, and then you never have to mess with them again, and if you're using a tool like Terraform, you have a blueprint for yourself around how to riff on that concept as well, so future permissions changes are even easier.

In other words, nearly every complaint in this thread about the cloud is solved with some experience in the cloud. There's a reason it's so ubiquitous, and that's because it really is pretty damn simple once you get the hang of it.

Our current CloudFormation pipeline template is over 5,000 lines of yaml. That's probably on the high-end, but based on your statements, it sounds like you haven't seen a corporate cloud footprint.

I recommend using a tool that lets you break that up, something like Terraform.

> Once you understand how to deploy into AWS, it really is quite simple

I've seen enough 500 line YAML files to disagree with you.

Yeah, I've avoided CloudFormation like the plague, Terraform is really so much better.

I thought that's Heroku?

In that case, the cloud is already simple.

I use it to spin a Windows server, then connect to Steam, download a game server, download some mods from S3 and start the service.

The rules are in security groups. I add one Steam security group, and then another group for each game, and the machine has both of them at the same time.

When the machine is running, everything is one PowerShell script.

Using a Linux dev instance can only be even more simple.

Have you tried Cloudflare pages + functions? Curious what you see as the big pieces that are missing from your ideal world?

Disclaimer: I work at Cloudflare.

I’m not the same person, but for me to consider cloudfare functions I would need a standard solution that is not a vendor lock but something that I can run on developers machines and any server. I would also need a nice development environment. Right now I would rather develop using fastcgi than faas.

That’s fair. For what it’s worth you can run everything locally and on any server via miniflare. This is all integrated into Wrangler 2.0 which lets you trivially switch between running things locally and in prod.

The concept itself is generally portable with several services offering largely compatible implementations although there is more porting work than would be ideal.

As for standards/vendor lock-in concerns, I’m sure that will get resolved sooner rather than later.

Hetzner has its Cloud offering which is simple and configurable over API and cloud-init.

"Hetzner Cloud" is a VPS service, this entire conversation is about managed services vs unmanaged.

Running under QEMU doesn't mean a server is managed.

Er... There are different levels of managed services. I am totally OK with the cloud that manages storage, backup and networking as well as provisioning.

Every usage of RDS or Dynamo I saw until now did not need scaling nor DBA outsourcing that AWS provides.

For me, Hetzner Cloud hits the sweet spot for side projects. And I use their bare metal servers to run high-volume websites.

P.S. Surprisingly, non-tech businesses are often offset by Hetzner rather than by crooks with registered office in Suntec Tower, Singapore that run their "managed" services on Aquia that runs on AWS.

Heroku?

On the other extreme end, I can setup a server in half an hour and deploy my code to it directly. No moving parts to get messed up or poorly configured or compromised. There are a lot of cloud devops things I don't get, but if it is just me, then it is dead simple and cheap, and I can add those later when/if they become important.

But a single server doesn’t substitute for the cloud services. Yes, your code is running, but even this article acknowledges that you now need to roll your own backup solution, test that it’s working, and so on. You also need to set up monitoring and alerting, metrics collection, and all of the other things that come with cloud services.

It’s easy to ignore those because we add them piecemeal over time with custom servers, but it is a huge drag on productivity when you add it all up.

> It’s easy to ignore those because we add them piecemeal over time with custom servers, but it is a huge drag on productivity when you add it all up.

Not only that, but you now own these services. If they break, you have to stop working on your product to fix them. Moreover, when your DIY cloud runs into problems, you won't have the benefit of a wealth of knowledge on the issue (internet forums, chat rooms, hiring people, etc) and of course you won't have anyone you can pay for support.

I agree that you eventually want to have those things, but we moved to a major cloud provider when we were ready and got all of those; that transition was very easy because the original setup was so simple. We got a strict superset of features, but the original setup worked to validate the idea and get the original customers.

Before long you also need CI/CD pipelines (to test and deploy your application), log exfiltration, monitoring, TLS, DNS, database backups (and ideally replication), database migrations, secrets management, and so on. In reality you probably need redundancy of your application and databases as well, with load balancing, etc.

You'll also want a couple of additional environments, and things are probably complex enough that it justifies some infrastructure as code so you can (more or less) stamp out these environments and keep them in sync with your production environment (and also so you can rebuild prod in case of catastrophic failure).

You can definitely get there if you're using your own machines, but a PaaS or cloud provider will get you there a lot faster.

Plus everyone you hire will need to learn all of this rather than using their existing cloud knowledge.

TLS in clouds is not much easier than a local setup.

thing is - you don't want to have a single server for your application, even the most simple one. Even having some simple redundancy in place means having 2 webservers, 2 database servers (separated from the webservers). And even for storage, S3 is not evaluated under the only metrics of storage size, but availability and durability too.

As a small startup you don't really need redundancy. Regular backups is likely good enough.

24/7 operations is the norm these days and I'd be surprised if the client doesn't want redundancy.

I don't work in a small startup (large non-profit), and our SLAs are best-effort only outside M-F 8am-5pm. Not everyone is trying to build a global-scale stack.

As a small startup you need to be focusing on iterating with your (potential) customers, not on how to securely set up a web server.

Most startups are not hard tech problems, despite the very strong desire to make them so by a technical founder.

I'm not convinced that cloud providers like AWS/GCloud/Azure are any simpler to manage. If you're talking about something like Heroku or Render then sure.

they are not necessarily easier to manage but you can easily setup a redundant infrastructure with a very low effort.

You can even have manually provisioned instances, but you easily spin servers in multiple availability zones and have a load balancer in front of them. Similarly you can easily setup and maintain a database in multiple availability zones without much effort.

But you are comparing your own level of knowledge of those two different technologies. Not their individual merits per se.

Have you really spent a similar amount of time learning your way around deploying applications on the cloud as you have administrating your own server?

That's fair, and I'm not dogmatically opposed to the cloud. But when you have underpowered cloud machines you end up having different machines for email, for web workers, for caching, and so on. The complexity you introduce by making your app scalable in that way you just don't have when you stick everything on 1 dedicated server. With dedicated machines I don't need to create a distributed architecture prematurely.

It takes us some time to set up dedicated machines, but less than a day. Ansible helps a bunch.

Email sending, web workers, etc. can all feed off of the same repository, running on different hardware, and have functions subdivided by DNS. "Monolith as services" is a super common pattern.

The closest thing I can tease out of this claim that seems like a significant practical criticism is that you need a resilient communications channel for talking from, say, core logic to an email sender--but you need that on one node too, if you aren't using a the right datastore for the job you're asking to staple your hand to your face no matter how many nodes your application runs on.

And these days it's pretty trivial to use a lot of AWS free tier stuff--or other clouds, but let's be real, AWS gives you A Lot--for much of what you describe. CloudFront is not my favorite CDN but they give you a bonkers amount of free transfer these days. DynamoDB as an object cache, if you don't want to pay for Redis. SQS is free to like a million API request a month and you can stick a lambda on the other end of it to handle offline/async tasks. And SES turns email sending into an API call.

If your concern is velocity, then cloud stuff is almost unassailable. If your concern is price, better cloud stuff is hard to beat, too. If your concern is portability, I hope you're already profitable and that it's worth your time to worry about it.

I find the costs and use cases take up time to try and figure out. I wanted to prototype a IOT device pushing data to the cloud. I used Google IOT Core. After reading a bunch of tutorials I streamed the data to Big Query. I used a device to send about 1000 readings and it cost me around $150 USD. I have no idea why it cost so much. It used 1000 hours of cpu time. I find that so confusing. Why was that much CPU required for so little data? It was 5 JSON fields into a table. Did I choose the wrong thing to ingest the data? Should I use functions?

So I am going back and seeing what else is possible. I tried setting up a PostgreSQL Compute VM but then I needed another specialized instance to act as a go between for allowing access for serverless vpc access. I get charged a bit for everything. I just want to build a product and see if people want it. I have no idea what to charge because I don't understand the costs. Do I spend time figuring out the costs of every little thing that is touched or do I install something on a hosted server?

I feel like there should be out of the box setups for this stuff in Google cloud. They have so much to offer, I think tying it together in easy to use and price packages would get a lot of people using it who need to rapidly get something made.

It takes time to learn your way and navigate through the maze that is AWS or GCP cloud as well though. And you never get rid of sys admins, they just get renamed AWS specialists.

But AWS specialists get paid more, and if as a sysadmin you push these technologies in your business, you will become a highly paid AWS specialist.

This is a big driver for the adoption of any tech - internal teams want to gain specific skills and job titles in order to get paid more somewhere else. I know that sounds cynical but as an engineer this has often been at the back of my mind when choosing technologies - either personally, or as a sweetener to get buy in from other engineers on some architectural choice I know they would otherwise object to.

Cynical? I thought that this is what companies wanted me to do when they have me set career development goals.

After all, the director of engineering also wants to put "moved operations to the cloud" on their resume so they can get a better paying job somewhere else or a better title.

The fact that there are AWS pricing specialists tells you everything.

"The cloud" also includes massive time sinks like Kubernetes or lambdas with a million of AWS services that can also become a huge distraction to building the product.

It's perfectly possible to build a MVP using a single VM and rsynched PHP code. The iteration speed (when solo) and amount of control is probably higher than anything you're referencing to.

In the end what matters the most if what technologies you're already familiar with.

I recently switched all my hosting to k8s and I think it is pretty nice for a bunch of small heterogeneous web services. It is a bit of a time sink initially but at least it seems like pretty portable knowledge

> But in the time it takes to do all of that (usually distributed and interwoven into other activities) you could have been prototyping out your startup. That’s the value of cloud.

Honestly reinventing the wheel like that to cut costs points to a management/vision issue. The founders should simply raise more money. The cloud is an incredible value proposition when you understand the amount of momentum and time it affords to an organization.

And, for larger companies, it also bypasses internal IT when the team just needs resources right now to innovate.

Or, its the one choice you made that prevents your small business from collapsing under surprise charges from Azure.

exactly. not everyone can afford a sys-admin or has the background OP has

Reply on news.ycombinator.com