Hey all! So, we've got some clients who are keen on using our SaaS solution on-premises to help avoid the risk of service interruption. I'm currently looking into the costs of switching to on-premise setups and possibly moving away from AWS entirely.
Right now, our stack includes EC2, Lambda, SQS, SNS, Aurora, and S3, all deployed using Serverless V3 with our codebase in Node.js and routing managed by NGINX.
A couple of things I'm trying to figure out: 1. Is going on-premises actually the best approach for risk mitigation? 2. If we do switch, should we also consider simplifying our stack by moving away from Lambda, SNS, SQS, and Aurora to make a more sustainable, long-term investment?
Just to clarify, this is not about improving our immediate reliability but more about assuring our clients that their business operations won't be affected if something happens to us. If anyone has gone through a similar transition, I'd love to hear your thoughts and experiences!
5 Answers
Honestly, I think going on-premises to handle risk might be a bit of a stretch. The cloud actually has a lot more resources to maintain high availability compared to what you might be able to achieve on your own. Besides, ramping up your own infrastructure comes with its own set of headaches. You’ll likely face higher maintenance costs and issues that AWS already takes care of at scale. If service continuity is your goal, you might consider a multi-region approach instead.
And remember, AWS has a whole team of engineers dedicated to keeping everything running smoothly. That's a hard thing to replicate.
Be careful with on-prem! While it might seem cheaper at first, you’re responsible for everything—from maintenance to compliance. Plus, you need skilled people who can handle both cloud and on-prem setups. If you can afford good staff, great, but if not, prepare for a lot of headaches! Also, think about licensing your solution—how will you prevent users from spinning up multiple instances?
I’ve seen migrations go both ways. A well-defined plan is essential. While you might save money on costs, can your existing stack match AWS reliability? Also, make sure every member of your team is lucid about the risks involved in a complete service overhaul—it's not just a simple cut-over!
From my perspective, the main advantages of leaving AWS are vendor lock-in elimination and potential cost savings. But think hard about the trade-offs, like the effort it takes to migrate and maintain similar functionality as AWS managed services. Features like SQS or Lambda are not trivial to replace without a lot of planning.
If you do go this route, definitely consider Kubernetes for deployment. It’s a big lift, but it'll help you manage your stack more efficiently. Just be prepared for a challenging build-out process. And for what it's worth, moving away from AWS doesn’t guarantee better uptime.
Totally agree! It seems like self-hosting may just add more complexity and potential downtime rather than solving the problem.