You Don't Need the Cloud
80daystartup.com
80daystartup.com
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.
It takes us some time to set up dedicated machines, but less than a day. Ansible helps a bunch.
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.
Most startups are not hard tech problems, despite the very strong desire to make them so by a technical founder.
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.
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.
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.
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?
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.
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.
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.
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.
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.)
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.
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.)
Running under QEMU doesn't mean a server is managed.
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.
Disclaimer: I work at Cloudflare.
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.
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.
I've seen enough 500 line YAML files to disagree with you.
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.
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.
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.
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.
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.
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.
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?
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.
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.
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.
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
Wow, I guess this is why so much software is so slow and fragile these days.
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
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.
- https://www.digitalocean.com/community/tutorials
- https://community.hetzner.com/tutorials
For example:
https://www.digitalocean.com/community/tutorials/ufw-essenti...
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.
"UNIX and Linux System Administration Handbook"
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.
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.
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.
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.
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.
Honestly, this seems like an ill-attempt at garnering views to their startup-in-80-days endeavor with a clickbait article.
Aka perfect HN bait
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
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.
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.
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.
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.
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.
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.
How about that the major ones, from Amazon, Microsoft, and Google, all have a track record of horrible corporate ethics?
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.
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.
That is the subtitle of this article I wrote last month - https://medium.com/@rykrk/everything-is-just-build-vs-buy-d7...
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?
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.
How about lock-in?
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.
> 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.
Yes, if the business is an enterprise, unscheduled downtime can result in significant losses. It's why disaster recovery is a serious business.
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.
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.
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.
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.
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"
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.
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.
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.
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.
> 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.
Managing your own database server is orders of magnitude more costly than using RDS because it is a waste of time.
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.
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.
At least that's my take ;) have a nice day.
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.
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?.
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.
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.
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.
Could you point out how much the overhead of virtualization nowadays?
What is the downside of networked block storage? In what use cases does it matter?
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.
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.
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.
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.
IAM role alone is worth it to be on the cloud. Haphazard iptable rules aren’t helping anyone.
S3 bucket alone is worth it to be on the cloud. Your deployment/app will inevitably have artifacts and putting them in NFS is just asking for trouble.
Cloudflare? Clue's in the name.
Use Linux tools for backups? Great. Where to? Cloud storage?
Sounds a bit click-baity to me.
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)
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 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.
Sounds about right but that contradicts the premise of the article.
Really all that needs to be said. Self-defeating post.
Let me know if they still think they don't need cloud services once they get to that day.
Self-hosted 'cloud-like' infrastructure is a better future.
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.
Just use virtual machines or colocated servers.
To be not the cloud is has to be your own hardware that you are managing directly.
Hosting providers exist for a long time. Way before this hype word 'cloud' was introduced.
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!