monolith vs microservices for app idea

Question

I have decided to start building a SAAS app. I wish to keep hosting costs low initially, whilst still providing a good user experience. Here are the components that will make up my app:

• Front End
• Reverse Proxy (Nginx)
• Auth Service
• Web API
• Worker Service A (processes data imports)
• Worker Service B (makes batches of external API calls)

All requests will go through the proxy, and auth will be handled via JWT.

I initially thought I would have all of these components on separate servers, but looking at hosting providers and pricing, that seems like an expensive option starting out (especially with 0 paying customers).

So it seems a cost effective way to do this would be to use a single server. Essentially each component would just be a separate piece of isolated code. Using this approach, I would still use the reverse proxy, and still use JWTs for auth - I feel like that way everything can be moved to separate servers more easily in the future.

What are the drawbacks of a single server approach like this (aside from the obvious monolithic negatives)?

Assuming this is an acceptable approach starting out, is using a service like Elastic Beanstalk enough in terms of handling High Availability?

Answer 1

Never over architect from the get-go. You will spend most of your time on the architecture and not the actual business case you are implementing. (This is especially true if you are trying out a new architecture approach, like micro services)

When I start out with something new and especially something that I have no idea if anyone will ever use, I always go simple and quick. This does not mean you have to write crappy spaghetti code. As you said you still want to modularize your code and separate your concerns within your monolith so it is easy to factor out later if needed.

Answer 2

Certainly it makes some sense to modularise as you see fit for future expansion and management needs regardless of whether you end up deploying on one server buy as c_maker says, strike a useful and economic balance as far as your time is concerned.

That said I'd have at least 2 servers in there. You need a public facing one for the front end and anything else directly open to the clients. Everything else should be on a separate server preferably not in the DMZ, secured in a different (i.e. more appropriate) way and accessed by the front-end via service accounts. Minimise the code that goes on servers accessible to the outside world.