My background
As a newer face when it comes to software development, from the onset AWS was pretty much what I learned and has been my g...
For further actions, you may consider blocking this person and/or reporting abuse
For me sometimes the cloud is a pain in the ass when the script can run locally. If I were doing a project which largely involved data scraping for personal use or as a stepping stone to something else, good chance I'm running it on my own machine.
It's interesting that you'd prefer to run data scrapers locally. I think that's one of the strong-points of AWS. I've been running a data scraping lambda daily off a cloudwatch alarm since December. It's great that it just does it automatically!
I definitely share a lot of the same sentiment. Follow up for you, do rails projects follow the same line of thought? If I remember correctly, this site is built with it. Are those project still local first?
same here
Same TBH
The cloud is ultimately just about hardware. You are running your code on someone else's hardware because either you don't want to run it on your or you don't have enough of your own hardware to do so.
Now, lets assume the answer is that you don't want to use your own hardware, for whatever reason, and will be running your code on someone else's hardware. In addition to the money cost ($-cost) you will be paying for that hardware there is also the time cost (T-cost) and complexity cost (C-cost).
T-cost represents the effort it will take to get your solution running on someone else's hardware. This can be as simple as a few config changes and deploy scripts but can also involve custom code. Depending on your architecture the T-cost could be a one-time constant or could scale with your entire solution.
C-cost represents the effort it will take to make any changes to your solution because it's running on someone else's hardware. You want to add a new feature and if your solution was a single program running on your desktop it would take X time, but because it's a distributed system running on an unknown number of someone else's hardware it takes twice as long to do.
T-cost mostly comes from optimization. You can take a solution that runs on your dev box, put that in a single VM and run it on someone else's hardware and it will work. But it doesn't scale much and you are paying a constant $-cost regardless of how much it is used. Making your solution scale generally requires breaking it up into smaller components that can be scaled separately. There are other optimizations you can make, often vendor specific, that can improve your solution's performance but are only available because (and were probably caused from) you are running on someone else's hardware.
C-cost scales with T-cost. If you do little-to-no optimization for running on someone else's hardware then there is no real impact to your solution and you will be just as productive as when everything was running on localhost. So all the effort you put into T-cost to improve your scalability/performance/$-cost comes with an additional cost of C-cost.
Now there are two processes you can follow to get to a cloud solution.
The vast majority of the time option 2 is the correct way to go. Why? Two reasons:
One of the great things about modern software tools is that with containers you can easily deploy your dev environment to run on someone else's hardware. So even for the cases where you could run on your own hardware but choose not to (aka almost every personal project that needs to be internet accessible) you can still have your cake and eat it too.
TLDR: You won't know how much cloud vendor features you need you have a working solution running in the cloud, so get a working solution first and then worry about the cloud.
I wish I could give you a gold star 😂. This is the kind of comparison I was looking for. Do you have any recommendations for "normal" providers (i.e. linode, bare-metal)
Unfortunately I cannot help you there - at work we use our own data centers and 95% of my personal projects are just for me so just run on my desktop.
What I will say is that there is nothing wrong with using a cloud providers from the beginning - what I would stay away from is all of their special tools and apis that they offer. Most providers have ways to easily run popular platforms (NodeJS, .NET, Java, Python, Ruby, etc) in such a way that none of your code cares that its running in their cloud.
As an example, I've recently been working on a personal project that's for 5 people rather than just me so I needed some way to host it. After about 20-30 minutes of comparisons I went with Heroku because the project involves a NodeJS app that uses a Postgres and they offered seamless hosting of those tools. While working on the app and with the DB locally 0% of my code referred to Heroku. The only special stuff was deploy scripts and different environment variables.
This deserves to be a blog post 😄
I think the reasoning is very good. Going to the cloud directly is a kind of premature optimization.
If you are doing a company project, I don't assume you would have many choices. If it is a personal/side project I would recommend not going cloud unless you use something so easy and seamless to get started like Google Cloud Run (your app will need to be dockerized). Another quick getting started would be to do a personal account on Vercel (formerly Zeit). If you get some traction and users then think of scaling up to a cloud.
This has been my struggle. Being newer, I know larger cloud infrastructure well enough. But getting personal projects off the ground effectively has been difficult. I definitely need to get familiar with Vercel or Google cloud run.
My 2 cents on running side projects for free : mobile.twitter.com/geshan/status/1...
You could try Elastic Beanstalk or AWS Amplify. They have a lot of recipes, and some that allow you to "just upload your code" and they do the rest.
From my experience, Amplify is great for UIs in general, but the GraphQL section has made me miserable more than once. And Beanstalk feels like CloudFormation "lite" for webapps. I do appreciate that Beanstalk leaves its architecture out in the open for you, but I've never found it to be much of a time saver.
When targeting clients that will only trust you if they have everything on-premise.
Maybe the number for those are shrinking but you would be surprised to see how many still do it.
Also, some people just want you to distribute them code or an executable and they can use it, or deploy it on their on machines or clouds when they need it.
When you need lots of compute power. Typically most cloud providers will burn a massive hole in your account if you're doing something intensive, video processing for example, at which point it would be cheaper in the long run to either use dedicated servers, or co-locate your own build. Jeff Atwood has written an article about this [1]. He basically comes to the conclusion that in the long run BYOH (Bring your own hardware) is cheaper than relying on cloud providers. Of course, the trade off being that you would then need to be responsible for managing said hardware.
[1] - blog.codinghorror.com/the-cloud-is...
Cloud is a bit of a PITA for testing (though Google App Engine had a local server already way back in the day) so I tend to use cloud for deployment, not for development. I'm fully aware people might not share my view and I welcome tools like GitPod, Cloud9 and the future GitHub Codespaces to bring back some of that "local development" feeling in a cloud setting
If you consider cloud just as a hosting provider than I don't think there's a place where I personally worked and it wouldn't fit in the cloud. However couple of things regarding companies that mostly dominate the "cloud" and this is not technical but rather legal:
Hope I could broaden the business picture instead of just focusing on tech complications
The main thing to be aware of is to not use an AWS service just because it is "shiny". But its also nice to be able to spin up something quickly that otherwise you would need to spend hours or make real monetary commitment like hosting your on box in a server farm with a fixed contract.