Do I need AWS? Or am I thinking this wrong?

>I'm also enjoying staying sane avoiding IAM.

This sticks out to me. IAM isn't crazy, and having access controls in place is going to be the very first thing you want to do when you bring someone else on board. Maybe you're not there yet, but it would be a wise time investment to understand how these work, to the point where they don't feel confusing.

I would also advise to plan for your next scaling bottlenecks. Even if you don't want to implement the solutions now, have a plan. For example RDS Proxy for when you start running out of db connections.

If you find yourself constantly reinventing the wheel when AWS offers a managed service that handles that for you, it might be time to switch to AWS. Some examples might be: writing a complicated postgres backup solution instead of using RDS Automated Backups, or running your own Kubernetes control plane instead of using EKS. But if you have an infrastructure that is easy for yourself to maintain, then spend your effort generating value elsewhere.

Depending on your current provider, there may be advantages moving your existing bare metal server to EC2. EBS volume snapshotting is easy to configure, security groups are simpler to set up than configuring a Linux firewall, and it has support for automated horizontal scaling (if/when you have a need for it). But these aren't a must-have, they are conveniences, and you pay a premium cost for it.

> I'm keeping things simple, so I've got mostly Go services, pg + caching, and a svelte webapp. I deployed my Go services on a low-ish end bare metal provider, and for now it is fine. Deployments are triggered via scripts, and so far so good. Is it sexy, using all the latest and greatest tech? No, its just simple shell scripts. But it works?

Don't change a thing. This is perfect.

> Am I wrong to think that I could probably scale like crazy and avoid AWS completely with my stack? Why should I pay hundreds/thousands per month plus a premium for bandwidth? I'm also enjoying staying sane avoiding IAM.

You're not wrong at all. Check out the hardware stack for Stack Overflow as of 2016: https://nickcraver.com/blog/2016/02/17/stack-overflow-the-ar...

Don't over think it. Focus on the software and its features. Focus on getting users and ramping up your MRR.

Good luck.

You can definitely avoid the hyperscalers, but unless your ops are very simple, you'll end up paying for it with the cost of managing your infra yourself. Think about resiliency for example. What happens if the DC you're in goes down? Have you got another DC to direct traffic at? Do you need that? These sorts of questions are the ones that being in "the cloud" makes simpler to answer. I'm of the opinion that not every app needs 99.99999% uptime and not every app needs to be in the cloud though, so godspeed to you should you continue with this approach. There's no technical reason why you can't dramatically scale from this point.

Sounds like you've answered your own questions.

Changing something for the sake of changing something is meaningless. If whatever works for you works - you're fine, don't change a thing.

Though, I'd comment that you don't need to go all-in in AWS, you can use EC2 instances the same way as bare metal servers from Hetzner and get some cool benefits, if you need them (and ok with 10x+ extra costs) - easy backup/snapshots, migrations, better server access and management (I like having SSM to connect to the server with MFA).

There's nothing wrong with feeling this way, but you're comparing a very small company (your own) to a much larger corporation.

The appeal of AWS' "insane" bills are that they are not so "insane" when compared to the salaries required to maintain a home grown stack in-house, especially as complexity increases.

It's not just application complexity, it's organizational complexity. Doing everything yourself is fine until that complexity increases and you start finding out that all your dozens or hundreds of expensive employees are spending a lot of time on home grown overhead.

For example, when you use shell scripts for your deploys, you can't as easily prove things to auditors like you can with a CI/CD system that's tied in to role based access control. That sort of thing will be dealbreaker for customers who expect your company to maintain industry compliance standards.

When you use a product like RDS you can tell your customers that Amazon is the one responsible for handling backups, security patching, etc.

Also keep in mind that anyone with a significant amount of AWS infrastructure should be buying reservations and savings plans. The sticker price of AWS is not what corporations pay.

As you grow your company, I encourage you to focus on the activities that make your business profitable and deliver value to customers. Every hour you spend upgrading a database or patching an operating system is an hour you could have been spending on developing a unique feature in your product that nobody else has.

For now, I'm sure using this setup is much better than getting something too complex for your size, but that can change quickly if you're lucky enough to reach a larger scale.

If your current setup starts to feel insufficiently robust, then there are several options to consider before AWS, namely things like Heroku, Render, and Fly.io. You'll hear critical reviews about all of these, so do your research first.

Personally, I have used Heroku in production at more than one place, and plan on using it again.

What are you doing for backups and redundancy? The main reason I use RDS and so forth is I pay AWS to do that for me. I do have a script which backs up my database to an on premise host so I can put it on a tape, but that is faintly ridiculous when AWS is so good.

You can choose the middle between AWS and baremetal. Something like DO apps. They provide managed deployment, db, object storage etc

How simple are you willing to go here? One thought that occurred to me was a reverse ssh proxy into your phone or a small always-on computer at your home. Perhaps both?

Using any cloud only makes sense if a) you don't know how to setup things yourself and b) your project is so big, that salaries for ops would be higher than cloud cost.

Also, be careful with b) since you still need people that know how to do stuff, otherwise, you will experience either data breach or long downtimes.

What most people won't admit when recommending cloud is that, yes, cloud has all sorts of utility built into, like data replication, backups, scaling, etc. but things go wrong in cloud as well and if you don't have good knowledge of how things work, you will be in for a wild ride.

IMO, it is much better to learn setup things yourself, even in non-optimized way and have some knowledge on what to do when stuff begins to break.

You seem to manage fine. I do think most projects do not need AWS, and at work we run most of our infrastructure on our own servers (colo, we rent racks and buy servers).

Remember to consider more annoying points that can often become hidden costs, or hidden risks: - backups (and more importantly, restores :) ) - maintenance and security (you are in charge of the lower levels too) - decent authentication, authorization, and accounting (AAA) - SLA, both 'in theory' (what does the contract with your provider say) and 'in practice' (how much would an interruption could cost you and what happens if the provider does not respect SLA at all) - how do you handle outages (ideally you want to have a plan to know what to do when the obvious things go wrong. Then for the non-obvious things) - how do you transfer knowledge to a potential new employee. Is there only one person that know how something works. (called 'bus factor')

And yes, most of those also apply if you use AWS, but typically they would cover different parts or have different risks. And usually some associated product you can pay to manage that risk

You have it figured out.

If you are worried about redundancy, get a second server at a different company with the server in a different part of the country, and back up to it every hour (incremental backups) with a full backup every night, or whatnot.

What do you think would be more beneficial to your company in the short and medium term?

It's good, don't touch it. If you need AWS you'll know.

A low complexity org with low complexity tech stack (both good things) can serve a ton users, and don't have much benefit from huge scale, elasticity and features of AWS.

In particular network transfer fees on AWS are ridiculous, IMO.

Probably unpopular opinion here, but my policy is,

If I can choose to not pay rent, I will choose to not pay rent.

If you can do things yourself or with your staff, you probably don't need aws.

But when the cost of you doing something (either direct or opportunity cost) becomes higher than that of using aws (or another cloud provider), you should use them.

Yes, you can get really really really far without needing to scale if you spend a lot of energy and effort on optimisation, but that's time you're not doing biz dev, or building out capability.

And even now you probably are currently spending a lot of energy on things that are useless outside of saving $ you'd pay to Amazon. As you grow, the cost:value of doing these things yourselfor even in-house changes.

If you're successful and scaling, it's often waaaaay easier and cheaper to throw $$ at a problem short term than getting engineers to actually prioritise and look at it.

I’m biased, but I originally came from the sort of setup you have into AWS. And I’ve never looked back. The time I spent tinkering with bare metal servers is just wasted. AWS has figured it out. Yes, there’s a bit of premium you’ll pay for that. But that’s your own time saved. Only you can tell what’s your time worth. But as an engineer it’s probably a lot and every hour you spend tinkering can probably pay for the whole AWS monthly bill.

For me, the strength of AWS is in scalability and reproducibility. I use AWS CDK to define infra as code. Which allows me to make changes with confidence. Test changes in other environments. Use CI/CD and pipelines even on small projects.

I only needed to figure this out once. Then all of it is reused across any project from first commit to deployed infra is matter of minutes. When I’m done I can tear it down in minutes.

What you need to understand (at any given point in time) is:

- how is the complexity & scale of your system going? Make projections

- identify potential breaking points in this

- figure out roughly how long it'd take to migrate to e.g. AWS

- the cost of migration (not only the diff between your current costs and AWS costs, but the opportunity costs all the projects you won't do while you're migrating)

- now you have your "buffer" figured out, as in, when you need to start acting.

If you're not using AWS services, there is no good reason to stay with AWS.

But if you see yourself reimplementing AWS services on your own stack, you should fire up Excel and do the math which is more cost-effective.

Your business is delivering product to your customers, not building and maintaining the technology to do so.

This all depends on product requirements. But the single simplest reason for choosing a cloud provider like AWS is reliability. If a region or machine goes down, how do you handle it? AWS has the best reliability among cloud providers, so by choosing them, the odds you even need to think about it are minimized. And they have answers to multi-AZ and regions. But if a few mins of downtime every few months isn’t the end if the world, by all means save yourself the trouble until it is.

How many RPS are you serving? What about caching later for assets in the svelte app?

I also considered AWS but then decided to go with Hetzner. For me it's a learning experience as well so I enjoy figuring out stuff. AWS would have cost 3-4x although I am using RDS for now.

I have scripts but use Ansible to setup snapshots to spin new servers from. And Terraform to configure everything. The biggest downside as I see it, is that _if_ I had to scale up the stack there would be issues regarding auto-scaling and additional regions.

However, Im not worried about that and if it happens, I probably have money to move back AWS - at least in part.

So my advice is that if it works and the servers stay up - keep it. AWS is no silver bullet and moreover, if you have little to no revenue it's better to keep costs down. As a small company I think you get a little more lee-way also regarding server downtime.

37 Signals is living proof nobody needs a public cloud.