Hi guys, I need some advise regarding the infrastructure side of things related to a SaaS system. Is for a project I have in mind for a very specific market.
I haven't partnered with any other developers, just with someone else that will help with the marketing, because I know for a fact that it doesn't matter if you build the coolest app ever, without a plan and the correct mindset to reach out to potential customers, it won't matter.
Coming back from experience, in terms of selling anything computer related to a non-technical person, the best way to get their attention is by showing them something tangible, which is why I want to develop a prototype which I will iterate into a product that is worth paying for.
Now, I want to set the grounds for the appropriate infrastructure technology stack required by a SaaS cloud application. Being the only developer, I need automated tools to abstract DevOps tasks for me, though I know it requires money investment.
If everything goes well, as the saying goes... "Don't be a victim of your own success". For example, if an important amount of customers want to try/rent the system, my other partner (the investor) would come in to tackle on the expected rise in prices of those third party technologies, whilst hopefully still providing a nice user experience. And who knows what happens from there. Or I might just miserably fail x.x, but hey, I least I tried :)
In terms of price I know Heroku is more expensive, but I like their add-on market (i.e I can easily set a deployment pipeline with Codeship, also offers a free tier) and how it enforces good practices, leaving me with less room to screw things up. On the other hand I know is more limited than Elastic Beanstalk and I read cases where they ended up migrating to it from Heroku. Is it worth to start right off with Elastic Bean? taking into consideration I will have to learn it and for what I understand, it will require more work to handle.
It's pricey but it seems so straightforward, plus they offer auto-scale and automatic backups. Any other option in terms of DbaaS?
I have zero experience working with this and I know is a tricky one. I've been looking into Payza, don't have a lot to add at this moment.
pd. I have not commented on the technologies I want to use to build the actual app to keep it short, but are [NodeJS + ExpressJS + Socket.io] + [React + Redux].
Thank you for reading and please leave a comment, even if it is to tell me that everything I think I know is wrong :P
You're at a very exciting time in your project. Unfortunately, it's tough to answer a lot of the specific questions without knowing what the application will do. An e-commerce stack will look very different than a realtime multiplayer platform (not really SaaS, but my point remains).
For general advice, I'd say use what you're familiar with. Unless you have very specific requirements, it's not worth sacrificing productivity. The reality is, as it is with all startups, you're resource constrained, so spend your limited resources where they'll have the most impact: building something unique and innovative from parts you understand. Time is the enemy.
Abstract what you can. You mentioned a particular payment gateway. I'd say find a good abstraction library that can act as a layer between your application and any number of payment gateways (stripe, paypal api, etc). Same for transactional email service providers. If you wrap your application in a container (e.g. docker), that improves your ability to deploy to any number of hosting providers, if you outgrow one option. If you're not satisfied with some service or provider, you might get away with just changing configuration.
Of course, there are inherent contradictions above. I said abstract, but I also said time is the enemy: maybe committing to Heroku and it's ecosystem has time saving benefits. That's a tradeoff you'll have to assess, as it's difficult to know your needs and your skill set.
Pick your database for your purpose. If you need well-defined transactions, RDBMSs are the ticket (PostgreSQL, MySQL, CloudSQL..., and use an ORM). Document DBs are nice and flexible. MongoDB is a well known quantity. RethinkDB is geared towards realtime, and if it suits your goals, use it. Of course, you can use multiple DBs and match each to their task (probably the most dubious statement I make; it's true, but if data in one DB relates to data in another, it means more logic at the application layer to connect them and possibly performance implications, so there can be a cost).
Don't look too far forward. Yes, you should adopt generally good design principles (preparing for horizontal scaling, leaving room for caching), but at this stage, you don't know for sure if your product has a market, or even if it's the product you'll end up with (you'll iterate). I'd rather be a victim of success and have a problem to solve, than have put a lot of time and energy into optimizing a product that doesn't have an audience.
Good luck!