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.
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.
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.)
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.
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.
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 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.
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.
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.
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.
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.
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.
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 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.
> RDS. It’s slow and super expensive. I don’t want to worry about one-off queries or migrations. If you use only 5% of your server capacity you can afford to do inefficient things at times.
The author has clearly not had to do a database migration at 3AM. AWS is more expensive but so is my time, so it works out better all the time.
Isn’t computer science all about building on abstractions? Where do you draw the line? Should I write a kernel every time because Red Hat /MSFT charges me $100?
Not every web app is high-scale, constant load. Many are ultra-low load and can do DB migrations by simply warning users about anticipated downtime.
I've worked in both environments. It's about understanding your business needs; "cloud" can quickly turn into premature optimization and burn time/money if you don't need it.
I'm not entirely convinced the cloud magically makes all these things low maintenance? A lot of the work seems to depend on how simple your architecture is, cloud or no. I also read about plenty of things that go wrong on the cloud: misconfigurations, huge bills, having to do premature optimization work because you pay for every CPU cycle and each GB of RAM.
I'm not saying the cloud doesn't have a place, but I think 99% of the long tail of services don't even need to do migrations at 3am. And running a MySQL instance on a dedicated server with humongous amounts of RAM and speedy NVME drives for $100/month or so is not a bad deal.
But wait until your master worker falls over and you have to promote your read replica. RDS handles everything for me, I just have to monitor it and be ready for any alerts from Promthesus.
I mean I’d say cloud providers measuring everything is a pro. I’ve been at companies in the past that have lost track of all their physical tin. One machine had been doing nothing for 5 years
RDS is amazing, we upgraded our postgres DBs from 8.something to 11.something with one click/db and 5 minutes downtime a few weeks ago. Bigger/smaller instances and read replicas are also one click away in case you need to scale up or down. The builtin snapshot and backup capabilities are working out of the box, set it up and forget about it till you need to restore. Easily managable via terraform or your choice of infrastructure as code tools.
Serverless RDS has been a dream so far, zero complaints.
And +1 to Terraform. I really do think these problems are related to experience, with some folks favoring complaints over getting their hands dirty and figuring things out for themselves.
This may have better named "you don't need the cloud for high performance". Hetzner is awesome (I'm a huge fan) but what they're offering you is relatively low level and you need to know how to use it properly. As with most things it's a balance -- maybe you don't need the latest 5-10 AWS services that have been launched, but it's pretty reasonable to want to use them if the pricing was reasonable.
What people need is the reasonable set of well-managed services, and competition on the provider side to drive down price and produce better solutions (not just complicated ones). There's truth to the fact that AWS is "too much" in many ways, but having every single dev that exists know how to properly configure NGINX, properly lock down a server, or run postgres is a mis-allocation of skills.
The cloud landscape needs ubiquitous lower level managed cloud services for prices that don't make people tear their hair out and write articles like this. 99% of profitable CRUD-y apps out there would be fine with the usual app + redis + postgres stack and they'd be able to move faster if they didn't have to run it themselves.
Shameless plug for something I'm working on -- Nimbus Web Services[0]. I'm trying to run the managed service layer on providers like Hetzner so others can keep their focus elsewhere.
> but having every single dev that exists know how to properly configure NGINX, properly lock down a server, or run postgres is a mis-allocation of skills.
1. Why would "every single dev that exists" need to know this? You need a handful of people per company, depending on size maybe as few as one sysadmin and a backup guy, and you're set.
2. The alternative is that every single dev that exists needs to know about whatever the cloud-solution-du-jour may be, because suddenly the product has to be written with the architecture in mind (eg. to not get surprised by huge bills)
3. As a dev who learned all how to configure apache and nginx, manage containers, setup, harden and supervise systems (aka. "sysadmin stuff") I can say its doable, and even fun to learn.
Sorry I should have explained that statement more -- that's the extreme case of the you-must-be-your-own-sysadmin, basically it represents an increase in ramp up time/time cost for everyone who is NOT in an organization. I was going with a bit of a universalist stance there, but it's overblown, you're right.
That said, even having everyone on the ops team (let's say it's 1 or 2 people) be good sysadmins is still non-trivial effort. It takes time and more likely some misconfigurations and mistakes -- and that talent must be paid for (people are usually more expensive than servers).
I do want to make it clear that I agree with all your points, I immensely enjoy learning it as well! For many companies it seems like it's still reasonable to pay $xxxx a month early on while finding product market fit (often offset by free credits), and lean in to all the dev talent that already knows how to do simple stuff on AWS. Much more a VC style playbook, but it'll probably be what people do till it gets prohibitively expensive.
Learning how all these things fit together, when to use what, etc is much harder of course. Wisdom like that often requires time, effort and persistence.
Depends a lot on where you currently are in your knowledge about Systems administration and what kind of learning materials you prefer. For me, as someone who started learning about it from the ground up (zero prior experience as a sysadmin", and learns best from books
> Lambda? Beanstalk? Glacier? EBS? What even is all this stuff.
Yeah, well, if you don't understand something, you're not gonna recommend it. I'm glad they've found a solution, but to make a blanket statement that no one needs cloud is just dumb.
I had the same "This is just ridiculous" thought when I saw that.
The other thing I'd bet is that this person has never had to make sure their infrastructure can pass any kind of security questionnaire or compliance audit. My guess is they would fail in a heartbeat.
> The other thing I'd bet is that this person has never had to make sure their infrastructure can pass any kind of security questionnaire or compliance audit.
Security audits are a big security theater more often than not, though.
At my current workplace, I have to jump through several hoops to do certain things, but it doesn't change the fact that I (or some privileged service) am still the entity that is allowed to jump through all these hoops.
I don't want to imply that IAM is necessarily bad, but it is complicated to understand and security is often negatively affected when there is friction involved. Then, processes are implemented that look secure, but they don't necessarily guarantee security and people find workarounds like sharing tokens, defeating the whole point of auditability.
Agree 100%. I often get frustrated by things in GCP IAM that seem overly complicated (i.e. it's not at all easy to get a simple view of "show me all the resources this identity has access to").
But that said, at the end of the day you WILL need the concept of users, roles, permissions, and restricted access to resources based on those permissions. That's a ton of work if you're doing by yourself, and you're likely to get it wrong.
My takeaway from "Identity management. You don’t need it." was talking about AWS Cognito and not identity management as a whole. At least that is what I hope they meant.
It's really disappointing to see the author fall victim to the thinking that whatever works well for their tiny use-case can be applied across the board.
Honestly, this seems like an ill-attempt at garnering views to their startup-in-80-days endeavor with a clickbait article.
I have a slightly parallel hypothesis as to why companies are paying fortunes as AWS and Azure bills.
I call it Kubernetes Driven DevOps. While kubernetes is a really great solution to a wide range of problems, often those problems are only faced by large companies with massive scale.
But what is really happening in the industry is that, the new age DevOps engineers start their learning with containers and kubernetes as the base truth - and then are hired based on their experience around that ecosystem.
This inadvertantly leads to an industry full of kubernetes experts who nail every service with k8s hammer and then drive insane amount of cloud infra bills.
I miss the old era cloud where the offerings and the ecosystem were friendly to indie devs as much as they were for BigCorps.
Yes, tell me about not needing the cloud (aka a managed provisioning and scaling service) when your poorly configured database breaks, or when you need a 3 hours downtime on prod because you need to reboot and reconfigure your services, or your release breaks production because you're using a diff tool to run deployments, or you simply have no option to scale horizontally past your single vps once traffic comes in.
Very clickbait article, please don't blindly follow recommendations by someone which obviously doesn't get services even like Elastic Beanstalk, Lambda and Identity management (:shrugh:).
Sure, a VPS is fine for a low risk pet project like your portfolio, a blog, some marketing websites, the project I built over the weekend and a few other things. For anything else, there's literally not a single reason for not wanting to use a cloud service / a managed provider.
> Yes, tell me about not needing the cloud (aka a managed provisioning and scaling service) when your poorly configured database breaks
I mean cloud is no panacea here either. We had a multi day outage of our SQL Data Warehouse in Azure when something broke on their end, and we were stuck sitting powerless waiting for them to fix it. Fourtaunetly for us it was used for offline processing, so the outage just meant we were late delivering fresh data, not fully down.
For those wondering, yes we had backups, yes they were tested so we knew they'd "only" take about 6 hours to restore, but we also had support telling us it was their highest priority and would be back up "soon".
I'm not even saying we could necessarily do better, but I certainly understand why someone might prefer to trust themselves to resolve a situation like this instead of having to rely on a 3rd party that frankly isn't feeling your pain.
I note that the grandparent's premise for a catastrophe is that everything in a datacenter must necessarily be poorly configured. To that, I ask: how many corporate cloud footprints have they looked at?
Don't rely on one article to design your tech stack, rely on one comment to know that the cloud is "literally" perfect for everything larger than a blog.
Nowadays there's such an abundance of PaaS that in my opinion it doesn't make any sense anymore to get a VPS and manage it yourself, unless you're willing to potentially spending numerous hours in DevOps yourself in both initial setup and maintenance, but more importantly you're aware of the implications when you go past the traffic it can physically serve.
Furthermore, managing your own server potentially leaves more room open for misconfigurations (including backups) and definitely won't get you past any information security questionnaire.
I'm a "DevOps" working in a company 100% on AWS and know what? There are hundred. thousand of men-hours per year of "DevOps" work, even in the cloud, even when using managed services. You don't need to manage a VPS maintenance but you do need to spend time refactoring Terraform code, you need to check for the best EKS workers to not shell out a fortune, now you have to migrate things to ARM/Graviton because Finance is telling you that we are throwing money away. Heck, you need to have 1 full-time people to control the bill and the spending!
You might say these problems come more from the scale of the business rather than the bare-metal/cloud dichotomy, but if you are a in startup like the linked article is about, well, you still have to do all the work and it doesn't change too much if you have to know how AWS/Azure/GCP work and bills you or which command-line backup tool you want to use. There will always be more than just pure code.
> you need to check for the best EKS workers to not shell out a fortune, now you have to migrate things to ARM/Graviton because Finance is telling you that we are throwing money away
A lot of software projects I've been involved in had some extra complexity (asynchronous processing, etc) because the cloud is expensive and the hardware they ran on was underpowered as a result. This introduces more moving parts and you have less margin of error. These moving parts (as opposed to the underlying hardware) can fail and cause an outage and this may happen more frequently than if you were operating on a single, hardware point of failure, defeating the entire purpose.
In my own project running mostly on bare-metal it is much simpler because a lot of worry about cost or performance goes away. Yes I could put this in a queue and maybe it's the right solution down the line, but in the meantime I have so much CPU that I can afford to do the task on the main thread and not worry about any of this. I also have much more margin for error in terms of resources (CPU/RAM/disk) so that if a process does go haywire it'll take much more time for it to cause an issue, buying you time to notice and fix the problem before it takes the whole system down.
There is this whole level of complexity in enterprises where enabling groups package or wrap cloud services that should be used by their devops teams, such that the result is compliant to the company's standards for security and monitoring etc.
Even though the product of the vendor doesn't change, there is a constant maintenance load on the devops teams to keep the internal packages/pipelines up to date with whatever the enablement teams cook up every time.
When doing new things, most time is lost in navigating the landscape and setup of these pipelines and products, firewall rules, network rules, which live in another documentation universe from the cloud as the world knows it.
No matter what you do, IaaS or SaaS: the enterprise is going to keep you busy.
> Furthermore, managing your own server potentially leaves more room open for misconfigurations (including backups) and definitely won't get you past any information security questionnaire.
If you believe that cloud magically removes this as a hurdle then you surely should not be dumping your infrastructure into a cloud provider. Misconfigurations in cloud are real, happen often and are often times much harder to validate without 3rd party tools or spending a lot of time building tooling to extrapolate if your footprint is doing what you think it is.
Misconfigurations in the cloud are much more dangerous as well as you can quickly accumulate charges and there is no way to implement a spending cap. With bare-metal hardware the costs are typically fixed and agreed in advance.
Is downtime an actual, business-killing problem in practice? In my experience, very rarely so, and clouds also have downtime (over which you have much less control) and seems like we live with it just fine.
> when you need a 3 hours downtime on prod because you need to reboot and reconfigure your services
What about when your RDS instance fails and is then stuck on "modifying" for an indefinite period of time (ended up being 12 hours, and I suspect an AWS engineer eventually did a manual operation to fix it) and you have to restore from a backup and rebuild the missing data manually from other sources such as logs in the meantime just to get back online? I've seen it happen and would've much preferred having the option to SSH in and recover it manually.
Scaling is less of a problem when bare-metal is so cheap that you can significantly overprovision and never have to worry about autoscaling. This also means you need much less moving parts that can break and take your service down.
I'm not saying that the cloud is always bad, but a hybrid approach would be the most pragmatic choice. For raw compute and bandwidth, bare-metal is orders of magnitude cheaper. You can still use the cloud's managed services from those if you need them, though given how cheap bare-metal is you may realize that you no longer need a lot of them.
When it comes to management/sysadmin work, every shop that uses the cloud beyond very small projects that are fully on a PaaS such as Heroku has a dedicated DevOps person (or more), no different from bare-metal in terms of effort. I'd argue it's more effort than bare-metal because clouds and their associated services, APIs and tooling (Terraform, etc) change much more frequently than old-school Linux and hardware.
> Is downtime an actual, business-killing problem in practice? In my experience, very rarely so
Of course it is. If you make a service that other people use as part of their workflows or business, they will be switching providers if you’re the only one that routinely goes down.
This is also a slippery slope. If your engineering team is in the habit of shrugging off downtime as no big deal, it tends to get worse and worse as time goes on, staff turns over, systems scale up, and load increases. If you can’t manage to keep downtime to a minimum when you’re small, it’s going to be much worse when you’re bigger.
Of course, there are businesses where uptime is absolutely critical, though I'd argue a lot of those already operate their own hardware for that reason (and would benefit little from moving to the cloud) or already have a cloud-based, distributed (multi AZs or multi-cloud even) system in place.
But is this actually the case of most companies? The AWS outages always have major ripple effects across the internet, suggesting that a lot of companies don't actually do what is needed to guarantee uptime and manage to survive and succeed despite that.
I worked at a company that had Target and other Fortune 500 retailers as clients, and we had very strict SLAs with financial penalties if we broke them. There was absolutely the possibility that we could have ended up our clients more than they paid us.
I don’t know. We used a managed kubernetes cluster at my previous work and it was a shit show. The support was worse than useless and we couldn’t do much about our issues.
I now manage kubernetes myself and it’s much better. If there is a problem I can fix it myself and not have to deal with oversea support who barely understand the issue half of the time.
System-wide? Not really since AWS has hundreds of services. Some services or some regions fail sometimes, but in 99% of cases good architecture can avoid that.
Sure, I'll warm my home and feed my family on good vibes, then.
I'm trying to build something awesome, not work for Peace Corps, I already accept a certain amount of third or fourth degree Evil, just by using Apple products, or even using this website (can you be certain not a single byte of this data touches material that was made under duressing work conditions?).
It's the whole The Good Place problem, all over again; it's impossible to live a moral life in a globalized society, if you think any use whatsoever of anything that could have in some way contributed to an amount of unhappiness is a Thing Worth Avoiding.
Well to clarify, I'm not necessarily saying that the ethics reason clearly outweighs all other tradeoffs. I was responding to the very specific assertion that "no reason exists". My greater point would be that the comment I'm responding to was being a little hyperbolic. There are definitely reasons not to use cloud. Your ultimate decision, especially in the context of project-specific requirements, is a different, bigger discussion.
Why do you need to use a major service though? There's a ton of cloud providers you can use that offer pretty much a similar range of services and are certified, e.g. ISO27001, SoC2.
Major services have major pay outs when majorly bad things happen to their enterprise customers. Finance will not approve a level of risk that would bankrupt your cloud provider for any critical service. I suppose this is mostly immaterial for startups given they don't have the weight or value.
I had a managed database go completely haywire. If I'd been able to SSH in or connect as an admin, the problem would have been found and resolved quickly (indices had outgrown the RAM by a significant factor). As it was, I ended up with around 4 hours of down time while waiting for support to do their thing. Now, this was all with a crappy provider (RackSpace) for a legacy app, but still, outsourcing competence is no panacea.
Elastic beanstalk is nice, but it’s autoscaling is kinda crap sometimes. It’s temperamental for shared load balancers. Logging of docker stacks sometimes works, sometimes auto detect fails and cloudwatch doesn’t get anything any more.
RDS is great, but sometimes there aren’t t3 instances for a month in your region. You can never make a disk smaller.
Bare metal instances are nice, especially when they cost 1/10 an equivalent vm. 10x on bare metal gets you a looong way. Biggest issues I have with hetzner are the lack of 10g enet on most instance types and the funky open vswitch overlay network.
I downvoted your comment because it doesn't engage with the author's argument. Instead you simply write dismissively "a VPS is fine for a low risk pet project like your portfolio, a blog, some marketing websites, the project I built over the weekend and a few other things. For anything else, there's literally not a single reason for not wanting to use a cloud service / a managed provider."
Everything you wrote in your first paragraph is obviously something that factors into the decision, but nothing more. You're just a random person on the internet, so your appeal to yourself as an authority does not lead to a useful conversation.
That's interesting. I help my clients to migrate away from the cloud and they never had the problems you mention. Their financial department appreciates the stability of expenses, though - and the fact that in some cases they are an order of magnitude lower.
"a VPS is fine for a low risk pet project like your portfolio, a blog, some marketing websites, the project I built over the weekend"
You are making the same mistake the article did. VPS is a great option for lot of production applications and not just low risk or pet projects. Not every production application needs Elastic Beanstalk or Lambda.
The answer is always "It depends but all options are on the table"
I agree, I deliberately generalised with those examples to make a little clear that as the required traffic, capacity and risk increases there's a lot of benefits with using services that automatically configure and provisions load balancers, network routers, machines, clusters, etc for you.
This is not to say that it's a "one click configuration+deploy with no security issues whatsoever" , but depending on the clients you work with you may be rightfully forced into using a cloud provider and hire DevOps engineer to manage the infrastructure.
> there's literally not a single reason for not wanting to use a cloud service / a managed provider.
How did we get to this point of learned helplessness. Some people are in fact capable and do run there own software stacks, configure and manage their own databases, and are self-sufficient in providing their own service to their customers and users.
Depending on how you provision the services (e.g. infrastructure as code) you may not be locked in at all and switching to a new provider is relatively straight forward. This comes up quite often in infosec questionnaires for DRP, so if you're hosting mission critical applications you must be read for a backup plan and switch to a new vendor if required.
Terraform configuration for AWS is AWS-specific. It cannot be ported to other stacks. Of course, you could design your terraform code such that you only use modules that abstract away the cloud provider (presumably you'd have to write them yourself), but I'm not sure if anybody does that, and if so, it probably suffers from the same downside as "database-agnostic code", i.e. lots of potential for optimising for a specific hoster and/or for using specific features exclusive to them goes to waste.
For many companies, 3 hours of downtime per month are no problem at all. So they can pocket the cost savings because they don't need the reliability that you pay for with a cloud.
There is a thing called TCO - total cost of ownership. If you don't calculate all of the costs associated with cloud vs vps vs bare metal then you're doing the analysis WRONG.
Absolutely, but there's a frequent misconception that the cloud has less management overhead even though most shops will still end up with one or more DevOps engineers on payroll.
for a startup, I suspect that this is mostly wrong advice.
Yes, don't yak shave and re-invent things, be cost sensitive, but to exclude the cloud is silly.
> RDS. It’s slow and super expensive. I don’t want to worry about one-off queries or migrations. If you use only 5% of your server capacity you can afford to do inefficient things at times.
It is expensive. But so is a shitty database thats not backed up, and cant be recovered. The inbuilt security that can come from RDS is a really really good thing, and is worth its weight in not having a DBA.
> Identity management. You don’t need it.
total bullshit. But its better to use a google domain for that. SSO for all the things.
> S3. Unless you store a massive amount of data you don’t need it.
No. even as a reformed storage admin, S3 has its place. Yes its shit, yes its slow, but it works for a lot of web based things. The crucial thing is for small amounts of data accessed by lots of things, S3 is actually reasonable. coupled with decent access controls and ephemeral keys, its a goodish build artifact store. And don't overestimate the value of an S3 website.
It is utterly shit for fast read/writes of large files. Or if you are editing a file in place. Its also fucking expensive for large amounts of data. but it has its place.
> Lambda? Beanstalk? Glacier? EBS? What even is all this stuff.
Lambda: CGI-BIN but with a docker twist.
Beanstalk: dont ever touch it, its shit
Glacier: an expensive way to ignore your data, but cheaper than ignoring it on S3
EBS: Hard drives on demand.
For anything that is experimental, or subject to change, or development, the cloud is a good fit. If you are doing stuff that involves non burstable CPU/disk heavy stuff, then its less of a good fit. However I don't think now I'd ever go entirely one way or the other. I'd always have some physical kit I own, or services I'd buy from the cloud.
Yes, it's a waste of time iff it does not improve your product / get you closer to achieve the goals your organization has (profitability, whatever).
If understanding every detail of your stack makes your product better, go for it! If it doesn't then learning every detail of it is not business, it's an academic exercise.
> understanding your app and stack is a waste of time
Yes. It's bikeshedding.
How far do you go? Should people create their own Linux distro? Clearly they don't "understand" their app or stack if they aren't creating the distro, right?
And don't even get me started on libraries. If you use any libraries and haven't read 100% of the code and documentation, you couldn't possibly understand your app or stack. It must be best to do all of that before launching your product, right?
Once all that is done, you should be able to launch within 5-10 years, which is only ~$2.5M in funding for a dev team of two.
> Ignore learning efficiency in the name of padding cloud provider pockets, it's the only way!
RDS has nothing to do with "learning efficiency" or understanding a stack. It's software. You remember software, don't you? It automates mundane tasks so that you don't have to do them.
Upgrades, migrations, horizontal scaling, vertical scaling, backups... RDS does all of those things. And it costs, perhaps, $15/mo. more than a VPS.
Hell, write everything in assembly, you'll never get optimal performance using higher level languages. Plus, have you actually read all of the code in the python standard library?
That is a stupid straw man and you know it. Knowing what your software stack does it not impossible, people are just lazy and want to pump out resume enhancing features.
> Knowing what your software stack does it not impossible
No. It's literally impossible.
There is no one working at a startup today who understands their entire stack, from hardware all the way up to web code. Not even the highest-paid people at Facebook could claim to know that.
Even the knowledge required to understand the Linux kernel, which almost every software developer works with today, is beyond almost all developers. And guess what? The world keeps turning. People build cutting-edge technical startups without knowing how every part of their stack works.
There are millions of person-years of work that go into even a basic web stack. It's insane to think someone can know all of it. And the whole point of the Linux philosophy is so that you don't have to know it -- you have simple building blocks where you can understand the I/O and use them to compose something much more complex.
I don't understand this article at all, if you're a startup and you're not worried about tech, you'd probably lean more towards fully managed solutions like Firebase.
Whying God's name would you have to run your own postgres instance on a server when you can take 30 seconds and create one in AWS?.
Anyways, for the cloud hating crowd there, please try to make arguments multi dimensional and try to get away from single nodes. Many companies need more than a single node and there are other things than single node performance when talking about purchasing computation of storage resources.
I get the appeal of being able to rent an inexpensive dedicated server, have a whole computer to oneself, and have so much spare computing capacity that one doesn't have to really think about it. It does feel liberating, compared to being nickled and dimed by one of the cloud providers, and having to put up with the overhead of virtualization and networked block storage.
But what feels better still is knowing that I can put my phone in airplane mode and trust that the cloud provider will keep my application running, including automatically restarting it on a different physical machine, switching the database over to a hot spare, etc. I could hypothetically script all of that myself in a bare metal setup, but when the shit hits the fan, my home-made solution would be much more likely to fail than AWS auto scaling and RDS.
It’s interesting how words evolve. Maybe this was different for others, but when I saw the headline, my expectation was that this would be an article about going back to desktop apps with built in updaters, or something like that. Because I’ve always felt the cloud got used as a business-speak version of internet 2.0. So by TPE, my brain saw that and thought “someone’s writing about dieting from the internet as we know it”.
In this case they’re using “cloud” as a drop in for software-infrastructure-as-service. Or “be your own best little cloud”.
Which is not wrong. Maybe I’m the one late to the slang party here. Either way, i still find it an interesting example of how these buzzwords morph over time.
I had similar thoughts when reading it. They're using servers that are hosted by someone else; you don't even know where they are exactly. That is still the cloud.
Finally, someone talking clear in one point, you don't need amazon with all the flavors for your startup... Most of the time, for the start of the project, you only need one instance with one or max two cores of CPU and a basic installation of some services (Nginx, MySQL, Postgres, node, etc.)... you only need to start your idea and make it profitable, then begin to scale and add some extra service try first on your own and then with some dedicated service (s3, rds, etc.)...
I once hosted a side project with a Raspberry Pi at home. One week later I got lots of unknown IPs from China trying to access php admin / other admin URLs I don't remember with default usernames and presumably password. Luckily I didn't set up an admin console. No I don't want the risk of someone trying to enter my network. Even if I have a firewall and the best security practices I may worry about that at night, like strangers trying to break your lock.
> If you’re a startup you want to focus on your product, and all this cloud tech is just a distraction. AWS is for big companies with a lot of turnover that can’t run their own machines.
Can't emphasize how wrong this is, and how for our company the exact opposite was true.
I don't manage any servers, our infrastructure runs on a mix of serverless technologies. Yes, at some point we may move things around because of cost, but that was planned up front and will be straightforward (our instances are just Docker containers running on Cloud Run and/or App Engine Flexible).
The reason this is such bad advice is because there is a ton of shit you need to do on your own (or, more likely, doesn't get done at all in some cases) if you run your own infrastructure:
1. You need to setup all of your own logging aggregation and monitoring systems. That's really a few clicks in a cloud.
2. You need to constantly update your images for security reasons. In a cloud, that is done for me.
3. All the systems I use are autoscaling. If I have a spike in traffic for some reason, probably the time when I most want my servers to be up, I don't have to scramble.
If you're a a startup and want to just focus on your product, you should build in the cloud. If you want to focus on your infrastructure, by all means build it yourself.
A common defense of using the cloud is that it saves you the cost of employing a dedicated sysadmin team and is hence cheaper in total, even once you factor in the higher runtime costs.
However, in my experience, as soon as you scale beyond anything from a "hand deployed" MVP, you will need to build tooling around deployment management. And guess what? This tooling is most often developed by a dedicated infrastructure team. So, all-in-all, you don't really save on labor but still pay for the more expensive runtime costs. Oh, and you have vendor lock-in.
EDIT (addendum): I'm not advocating to run your own datacenter as soon as your organization grows, because that requires yet another team and has immense initial overhead. The most portable and cost-effective method is to rent servers as you scale or use VPS providers. If you are already using a cloud, stick to the products that have equivalents in non-cloud situations. E.g. managed postgres / your own postgres, virtual machines, kubernetes, kafka. Stay away from special-purpose proprietary systems such as pub/sub systems, "lambdas", cloud configuration, etc.
"There's no cloud. There's only someone else's computer." said someone here on HN.
Cannot agree more. I want control. I want RAID, FDE, IPMI/KVM, etc. etc. That's why I use colocation service.
Surely, there are disadvantages: you are responsible for all the maintenance, upgrades, logistics, etc.
But my users enjoy fast latencies and no BloatFlare puzzles.
A lot of the comments here are about difficulty cloud tech navigation/adoption. I create a framework built on top of AWS to try to alleviate a great deal of the infra management aspects of running web applications. It sets you up with all the basics out of the box in about 10 minutes (db, api, ui, users, groups, roles).
Along the same vein as other posts in this thread, startups and contractors need instantaneous test bed environments that support a lot out of the gate, and which can be the basis to scale from. I've been a contractor off and on for a few years and have seen this need first hand. So my tool is meant to fill in the foundations of great ideas, so those ideas can grow faster. I think that's an essential trait of cloud services that you will be hard-pressed to find elsewhere.
This article sounds like a strawman. He is saying that you don't need the cloud but is hosting a VM on a cloud provider, which is probably what most "cloud" users do.
Cloudflare? Clue's in the name.
Use Linux tools for backups? Great. Where to? Cloud storage?
Lambda? Beanstalk? Glacier? EBS? What even is all this stuff.
This says it all to me. The OP is making a classic mistake in thinking that the cloud just means moving your on-prem servers to a data provider. That is not what Azure/AWS is about. I made the same mistake and cloud made no sense to me whatsoever for years.
In the past year, I've learned that cloud means the minimum required resources popping in and out of existence for the exact amount of time required to do a job.
That is where most software is headed. It is inevitable in my opinion.
If you don't know what an SQS queue is or Lambda or Step Functions or SNS messaging I would really really recommend learning. (Or whatever the equivalent on Azure is)
> If you’re a startup you want to focus on your product, and all this cloud tech is just a distraction.
All technology is a distraction...
> AWS is for big companies with a lot of turnover that can’t run their own machines.
Or for start-ups that want to pay somebody to manage their machines. I thought you were just complaining about distractions? Isn't running your own machines a distraction?
> Unless your startup needs so much compute or storage that running your own dedicated machines becomes unmanageable I think you should just say “no” to all of it.
An extremely reasonable decision. I'll just run everything myself until it all falls apart and then struggle to move to the cloud while my business flounders.
I can agree with most of the article but consider that not every startup has a sys-admin or can afford one. We are also a startup and we use AWS + heroku because we don't want to focus on setting up a ruby server and handle deployment pipelines and all that. This is the BIG advantage of cloud.
Yes we don't use a lot of AWS tools but S3 is "pay as you go" exactly for that reason.
The only reason we might need to switch to a Hetzner-like architecture is because our customers want the data to be in Germany. No other reason could move us there tbh.
I'd say it's a matter of what you try to optimize when you start a business.
I am starting a business now (not related to IT per se, but we need servers/infra). My limiting factors right now are time and money.
I optimize my time by doing boring stuff that I already know: no new tech to learn, and no new techniques to learn. I optimize my expenses by using some free or almost free services, which may involve the "Cloud".
Those are the only things I care about at this stage.
Agreed. It's honestly a luxury to get to decide to be anti-cloud, a luxury paid for by someone else's idea not finding product/market fit for that much longer while you fiddle with nginx settings for another four hours.
Came here to say exactly this. When you're sprinting to get to market first, you can't not afford to leverage the cloud. Later on (but preferably before you IPO for billions), you should seek to migrate away from the cloud to a platform you have tighter control over.
Was exactly my reasoning: no new tech, do it with the skills I already acquired. But I do try some new techniques or new methods once in a while, just to keep stuff enjoyable.
From a resources (CPU/RAM/disk/bandwidth) per buck, the difference is extreme. ~50 bucks a month on Hetzner will give you 8 cores (real ones, not vCPUs), 32-64 GB of RAM, several hundred gigs of SSD and 1Gbps unmetered bandwidth. The same on AWS will probably be ~150 bucks just for CPU & RAM alone, excluding storage and bandwidth.
For a simple web server? sure you don't need the cloud (still you'll have to do a lot of things manually and hard to reproduce, maintain your own database etc but yes, makes sense in many cases, esp on a budget).
"[1] This blog runs on the cloud but that’s because WordPress is a security nightmare and a cloud VM is the easiest way to sandbox it. Ironic, I know."
Really all that needs to be said. Self-defeating post.
i have the feeling this article is missing completely the point on the reason why you go for the cloud, or better saying, it's not enough to have everything into a single server (you don't want to have all your eggs in a single basket), unless you are just prototyping a service without real paying customers.
Hetzner has a presence in the US (for their Cloud offerings) but not for Dedicated or Colo.
The Colo looks cheap because it does not include any power usage. But by German standards (and at this time) the price Hetzner charges for power consumption can be considered economical.
Here’s the thing: we actually do need the cloud, not just one but actually many clouds. It has been well proven that clouds are a major contributor to the world’s rainfall, and this is extremely useful and convenient. Without a cloud, there are many more hoops you must jump through to get what is necessary.
This is fine for the indie hacker / build-100-startups-in -3-days folks.
It’s about not scaling prematurely.
But once your product sticks, you will suddenly need to explain to your customer where your dev, test, acc, staging environments are. How redundant they are. How they are separated. How you assure a million other identity, logging etc. requirements. And yes, you will need identity mgmt then.
And — who would have thought— AWS e.a. gives you that. Congrats, you now need the cloud!
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.