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.
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.
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.
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.
"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.
> 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?
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.
> 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.
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.
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.
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.
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.
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"
> 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.
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.
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.
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.
[+] [-] PragmaticPulp|4 years ago|reply
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.
[+] [-] samhw|4 years ago|reply
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.
[+] [-] brobdingnagians|4 years ago|reply
[+] [-] jdvh|4 years ago|reply
It takes us some time to set up dedicated machines, but less than a day. Ansible helps a bunch.
[+] [-] alzoid|4 years ago|reply
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.
[+] [-] mythrwy|4 years ago|reply
[+] [-] zimbatm|4 years ago|reply
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.
[+] [-] 908B64B197|4 years ago|reply
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.
[+] [-] fartcannon|4 years ago|reply
[+] [-] donmb|4 years ago|reply
[+] [-] surfer7837|4 years ago|reply
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?
[+] [-] hardwaresofton|4 years ago|reply
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.
[0]: https://nimbusws.com
[+] [-] TheIronMark|4 years ago|reply
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.
also
> Identity management. You don’t need it.
Oh. Oh, no.
[+] [-] hn_throwaway_99|4 years ago|reply
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.
[+] [-] izolate|4 years ago|reply
Honestly, this seems like an ill-attempt at garnering views to their startup-in-80-days endeavor with a clickbait article.
[+] [-] jcvold|4 years ago|reply
[+] [-] lewisjoe|4 years ago|reply
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.
Here's a tweet thread where I outline WASM as a potential bet against this kubernetes inflated devops culture - https://twitter.com/vettijoe/status/1484507483788161026?s=21
[+] [-] squallstar|4 years ago|reply
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.
[+] [-] Volundr|4 years ago|reply
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.
[+] [-] smorgusofborg|4 years ago|reply
[+] [-] Nextgrid|4 years ago|reply
> 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.
[+] [-] speedgoose|4 years ago|reply
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.
[+] [-] user3939382|4 years ago|reply
How about that the major ones, from Amazon, Microsoft, and Google, all have a track record of horrible corporate ethics?
[+] [-] christophilus|4 years ago|reply
[+] [-] wiredfool|4 years ago|reply
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.
[+] [-] bachmeier|4 years ago|reply
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.
[+] [-] jdvh|4 years ago|reply
[+] [-] hdjjhhvvhga|4 years ago|reply
[+] [-] codegeek|4 years ago|reply
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"
[+] [-] VWWHFSfQ|4 years ago|reply
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.
[+] [-] Shorel|4 years ago|reply
I really don't see what using a diff tool has to do with the cloud.
This is basically the textbook definition of a straw man argument.
[+] [-] immibis|4 years ago|reply
[+] [-] mbesto|4 years ago|reply
Look, this is the bottom line - it depends.
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.
[+] [-] Nextgrid|4 years ago|reply
[+] [-] KaiserPro|4 years ago|reply
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.
[+] [-] numlock86|4 years ago|reply
> Identity management. You don’t need it.
> If you’re a startup you want to focus on your product, and all this cloud tech is just a distraction.
The whole point of the article is to create controversy, attention and traffic? This can't be serious.
[+] [-] sascha_sl|4 years ago|reply
[+] [-] smt88|4 years ago|reply
Managing your own database server is orders of magnitude more costly than using RDS because it is a waste of time.
[+] [-] bsagdiyev|4 years ago|reply
[+] [-] 999900000999|4 years ago|reply
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?.
[+] [-] vanusa|4 years ago|reply
Which takes about as long to figure out how to do as anything on your control panel. Plus, you learn how things actually work.
Not saying there aren't other perfectly good reasons to use cloud services - bu the above argument isn't one of them.
[+] [-] StreamBright|4 years ago|reply
Cloud is the next logical progression for information technology. It is similar to the progress we made in agriculture or energy production.
The article has some comedy lines like this:
>> Dedicated machines offer unparalleled performance and are rock solid.
A single node? I wonder how the packets are arriving to this single node. How about electricity? Cooling?
Oh yeah, these things are not part of the discussion.
Look at the rock solid dedicated machines:
https://www.datacenterdynamics.com/en/news/ovhcloud-wont-rev...
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.
[+] [-] mwcampbell|4 years ago|reply
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.
[+] [-] travisgriggs|4 years ago|reply
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.
[+] [-] leocarrera|4 years ago|reply
[+] [-] ipiz0618|4 years ago|reply
[+] [-] hn_throwaway_99|4 years ago|reply
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.
[+] [-] throwaway657329|4 years ago|reply
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.
[+] [-] IYasha|4 years ago|reply
[+] [-] awayto|4 years ago|reply
https://awayto.dev
https://github.com/keybittech/awayto
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.