[AlchemistCamp]

I would strongly encourage you not to dive into learning React or AWS. Both are very good to learn about if your goal is to become an employee at a tech company, but not so much for a solo founder.

React itself is fine and relatively straight-forward, but its ecosystem is massive and there are many competing options for several accompanying libraries. AWS includes a powerful array of services, but it's considerably more time-consuming to learn than other hosting options such as Render.com.

I'd say your best bet is to just use an MVC-ish back-end framework and sprinkles of JavaScript. Once you've done well enough to hire a few engineers, then maybe start thinking about React, AWS, more complex devops, etc.

At the beginning, the most important thing is speed.

[whoknew1122]

Strong disagree on not learning AWS (or another cloud provider). I was partial to AWS even before I worked for them, but chances are you're going to run your startup in the cloud. For that, you should know at least the basics of the cloud you're going to use.

I'm not saying learn CloudFormation, CodeDeploy, or any of the hardcore DevOps stuff you'll be interested in once you start to scale.

But you need to know how security works (i.e. IAM), how to build networking infrastructure (i.e. VPC), how to deploy servers and databases (i.e. EC2 and RDS/DynamoDB). And, of course, how to do things cost-effectively.

If you don't take the time to learn the cloud, you're going to be stuck when it's time to push your project into production. So you're going to need to:

1.) Hire a cloud architect. This isn't cheap nor is it a good solution. If you ever part ways with your cloud architect, you're going to be starting step one all over again. Except now you have to learn how the cloud works and how your environment was architected. And that's assuming your architect doesn't maliciously make a mess of things on the way out (which happens -- A LOT).

2.) Open a support ticket for every little issue you run across. This can easily become a blocker with deployment. Not to mention you're likely going to have a developer support plan. Which means you get email-only support and the replying support engineer may not even be in your timezone.

So not only do you have to deal with the inefficiency of back-and-forth email conversations, you may have to deal with the time lag based on the engineer who works on your case.

[coffeefirst]

Alternatively, if I were starting a business tomorrow, I'd start out with Heroku or a normal VPS (Linode) depending on the budget and requirements, and only switch to AWS when it made economic sense to invest in that setup.

[whoknew1122]

This is a fair way to go about it. Really, my point is that you're likely to use the cloud.

And if you're running a small/solo shop, you really need to learn the basics of that cloud vendor before rolling out on the cloud platform. I see too many people roll things out on AWS without any knowledge of the platform whatsoever.

[mattcdrake]

Do you have advice on learning AWS/cloud for people that don't know anything about it? I have a Django/React project I'm hacking on where everything runs locally, but I don't understand how to put this thing on the real internet.

[whoknew1122]

I suggest getting a subscription to ACloudGuru or Cloud Academy. I'm more partial to Cloud Academy these days. They're both about $50 a month.

Then go through the Certified Cloud Practitioner course. That will give you the very basics.

Once you're done with the CCP, you can move to the Solutions Architect Associate course. You don't have to get the certs (although they are useful). But the courses will give you a good understanding of AWS.

Just to be clear, that's about 50 hours of content. But I suggest being over-prepared rather than under-prepared.

acloudguru.com cloudacademy.com

[mattcdrake]

Very cool, I will check this out. Thanks!

[ryanbrunner]

If you're solo or intending to stay small, I'd strongly recommend just using a PaaS that works at a higher level of abstraction than AWS. Heroku is still around, will give you sane defaults without really knowing much about the devops world at all, and will scale well enough that you'll almost certainly have a much bigger team prior to needing to move to something more complex.

[ramraj07]

Disagree on AWS. It's not that hard, and if you're gonna spend any amount of time figuring some vendor locked cloud system (which they all are), AWS is the best bet. And you obviously need to be careful with using every service that company throws at you, but barring that they provide the most solid reliable suite of services you can hope for so you spend more time on logic and business after some initial time investment.

[thinkingkong]

No AWS _is_ hard. It's hard. They're all hard. They require tons and tons of knowledge before understanding what to look at, how to use it, when to use it, etc. Everyone who thinks these systems are simple completely take for granted the years and years of knowledge they've acquired. Even in the form of shared vocabulary, AWS is insane. IAM is a whole other nightmare of complexity that is insanely powerful, but I wouldn't dare point anyone in that direction if they were just starting out.

[porknubbins]

I’ve found AWS services individually to be straightforward but the UI is full of unintuitive menus so you always end up having to google “how to x on AWS”. Also understanding how to make the services interact takes a fairly high level of networking knowledge.

[yowlingcat]

I dunno about that. AWS is useful at a certain point, but I must say, if I want to spin up a prototype that I need to get into production ASAP with no pre-existing infra, the first tool I reach for is Heroku. It's hard to beat how clean the UX is. Why? It's opinionated. I get an instance of an RDBMS and my service. It's really easy to install Heroku apps. It doesn't make me learn unrelated abstractions to do that, or fill my life with pointless noise and bullshit.

I will always appreciate AWS for how I can rely on it in production, but it definitely require a lot more verbosity and configuration than it needs to. I wish we would remember the product design lessons DHH taught us. Convention is preferable to configuration when possible for a reason. It reduces unnecessary complexity. It makes it easier for your brain to work with.

[AlchemistCamp]

The option I suggested, Render, is essentially the new Heroku. It's focused on dev experience, run by ex-Stripe people who worked on their infra and it's much less expensive than Heroku has been post-acquisition.

If you want something managed that requires minimal time worrying about infra, they're a great choice. For something that truly requires low costs per user, I wouldn't use them but they make a ton of sense for many projects.

And to be fair, AWS also has some serious limitations in terms of price scalability compared to a VPS like Digital Ocean or Linode: https://questinglog.com/costs-are-part-of-scalability/#just-...

[yowlingcat]

I think you are comparing apples and oranges. Heroku is great not just because of its DX, but 1) because it's a subsidiary of Salesforce and I know it won't disappear tomorrow and 2) it has a thriving app ecosystem. It's a real stretch to compare a recent $2.25M seed funded upstart with it and borderline malpractice to suggest running your production workloads on it.

With AWS although you have to pay the premium on egress, you don't pay that until you leave their sandbox; what's more, you can add links into your VPC that sidestep it. If you're just running open source software or a kubes cluster on commodity boxes and you're fine owning all of your operational burden, sure. Use whatever you like. But if you want reliability and good DX, your options get narrower.

Personally, I think that AWS Code Suite and VS/Azure spaces (and GitHub spaces by proxy) are going to be the real challengers in this space. There is a real UX problem to solve but it doesn't mean I want to necessarily use a different platform.

[AlchemistCamp]

We have almost exactly opposite opinions. I would have recommended Heroku back in 2012 without question. I would not now.

If Render is good enough for Stripe's production workloads, then it's good enough for mine.

[yowlingcat]

Look, I'm not saying I doubt that. If the tool fits your needs, more power to you. But that won't be the case for everyone. Eventually, some firms need to reach for the power tools that AWS has, or simply the reach in terms of reliability. Things like SQS, Aurora, Sagemaker, CloudWatch, CloudFormation, Redshift, S3, Glacier, Lambda, Fargate, availability zone reach, raw EC2 + EBS.

It's about ecosystems. Heroku has a decent ecosystem, but nowhere near AWS or Azure. I find it far more likely that AWS and/or Azure will improve their ecosystems to attain parity with the gold standard Heroku (or Render for you) DX in the small but which can scale all the way up. But you may find that a tall tale, and if so I would understand. The track record on the AWS/Azure side isn't great. But the latter did acquire GitHub, and I fully expect them to exploit that. I would be surprised if AWS lets them 1-up their incumbency through that vector without neutralizing it.

[mr-ron]

> At the beginning, the most important thing is speed.

Specifically, speed of development

[mraza007]

Do you suggest investing time in frameworks like Django or Rails