6 ms·

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 mainta

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.

jdvh 5y ago
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.
- eropple 5y ago
  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.
brobdingnagians 5y ago
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.
- thinkindie 5y ago
  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.
  - nicoburns 5y ago
    As a small startup you don't really need redundancy. Regular backups is likely good enough.
    - comprev 5y ago
      24/7 operations is the norm these days and I'd be surprised if the client doesn't want redundancy.
      - secabeen 5y ago
        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.
    - TameAntelope 5y ago
      As a small startup you need to be focusing on iterating with your (potential) customers, not on how to securely set up a web server. Most startups are not hard tech problems, despite the very strong desire to make them so by a technical founder.
samhw 5y ago
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.
- eropple 5y ago
  You pretty much just described Render. https://render.com https://render.com It's not perfect, and there is probably a point in time for a project where you'll need to evaluate other options, but I haven't found much that's better for small-scale stuff if you don't want to think too hard.
  - samhw 5y ago
    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.
    - eropple 5y ago
      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.
fartcannon 5y ago
Or, its the one choice you made that prevents your small business from collapsing under surprise charges from Azure.
donmb 5y ago
exactly. not everyone can afford a sys-admin or has the background OP has
mythrwy 5y ago
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.
- shubb 5y ago
  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.
  - 99_00 5y ago
    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.
- tonyedgecombe 5y ago
  The fact that there are AWS pricing specialists tells you everything.
zimbatm 5y ago
"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.
- nasmorn 5y ago
  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
alzoid 5y ago
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.
908B64B197 5y ago
> 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.

jdvh 5y ago

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.

eropple 5y ago
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.

brobdingnagians 5y ago

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.

thinkindie 5y ago
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.
- nicoburns 5y ago
  As a small startup you don't really need redundancy. Regular backups is likely good enough.
  - comprev 5y ago
    24/7 operations is the norm these days and I'd be surprised if the client doesn't want redundancy.
    - secabeen 5y ago
      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.
  - TameAntelope 5y ago
    As a small startup you need to be focusing on iterating with your (potential) customers, not on how to securely set up a web server. Most startups are not hard tech problems, despite the very strong desire to make them so by a technical founder.

samhw 5y ago

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.

eropple 5y ago
You pretty much just described Render. https://render.com https://render.com It's not perfect, and there is probably a point in time for a project where you'll need to evaluate other options, but I haven't found much that's better for small-scale stuff if you don't want to think too hard.
- samhw 5y ago
  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.
  - eropple 5y ago
    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.

fartcannon 5y ago

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

donmb 5y ago

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

mythrwy 5y ago

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.

shubb 5y ago
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.
- 99_00 5y ago
  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.
tonyedgecombe 5y ago
The fact that there are AWS pricing specialists tells you everything.

zimbatm 5y ago

"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.

nasmorn 5y ago
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

alzoid 5y ago

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.

908B64B197 5y ago

> 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.