DEV Community

Cover image for When starting a new project, when wouldn't you want to build in a cloud?

When starting a new project, when wouldn't you want to build in a cloud?

Dakota Lewallen on May 26, 2020

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...
Collapse
 
ben profile image
Ben Halpern

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.

Collapse
 
salhernandez profile image
Salvador Hernandez

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!

Collapse
 
therealdakotal profile image
Dakota Lewallen

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?

Collapse
 
dragosnedelcu profile image
Dragos Nedelcu

same here

Collapse
 
whittington profile image
Whittington

Same TBH

Collapse
 
simonhaisz profile image
simonhaisz

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.

  1. Start it from the beginning as a cloud solution
  2. Start it as a "normal solution" and then at some point in the future migrate it to a cloud solution.

The vast majority of the time option 2 is the correct way to go. Why? Two reasons:

  1. Get to market. You will get a usable solution much faster and get feedback earlier to improve it...or maybe cancel it because you learn your solution was based upon incorrect assumptions.
  2. You original assumptions around how much you needed a cloud solution were wrong. What if running a single VM is actually sufficient for your solution's needs? What if you only needed to optimize one part of your solution, rather than make everything horizontally scalable? Cloud solutions are all about optimization and unless you know a LOT about a problem you should almost always get a simple solution first and then optimize as needed.

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.

Collapse
 
therealdakotal profile image
Dakota Lewallen • Edited

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)

Collapse
 
simonhaisz profile image
simonhaisz

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.

Collapse
 
kant312 profile image
Quentin Delcourt

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.

Collapse
 
geshan profile image
Geshan Manandhar

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.

Collapse
 
therealdakotal profile image
Dakota Lewallen

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.

Collapse
 
geshan profile image
Geshan Manandhar

My 2 cents on running side projects for free : mobile.twitter.com/geshan/status/1...

Collapse
 
salhernandez profile image
Salvador Hernandez

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.

Thread Thread
 
therealdakotal profile image
Dakota Lewallen

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.

Collapse
 
alexandrudanpop profile image
Alexandru-Dan Pop

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.

Collapse
 
andrewpillar profile image
Andrew Pillar • Edited

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

Collapse
 
rhymes profile image
rhymes

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

Collapse
 
_hs_ profile image
HS • Edited

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:

  1. one client/customer can't host on AWS - some legal stuff
  2. some required hybrid solution as their data needs to be stored on their servers
  3. some required servers to be in a specific country to comply with their own laws - not all countries are offered by the cloud people, and a lot of times company from let's say USA has to give access to their government even if you thing your data should be protected by country where the servers are, too much legal stuff here I really wouldn't like to worry about but you have requirements from customers/clients
  4. cloud solutions have more and more SaaS which might be direct hit on your solution so if you host on such cloud provider there's couple of issues to consider

Hope I could broaden the business picture instead of just focusing on tech complications

Collapse
 
salhernandez profile image
Salvador Hernandez

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.