I would start by writing down the answers for a few questions, for example:
what does the app do?
What is its current architecture? You mention it's an API app, but where does it run now? Do you have a DB? Third party services? What parts is it comprised of?
what are the constraints right now? Do you have plenty of RAM, CPU or are you already at the limit?
do you have any static data that can be served by a CDN?
have you tried load testing to have a generic idea of such limits?
can you make anything in the software faster?
what's your scaling goal?
how the increase in traffic looks like week by week or month by month?
what sort of app is it? Do people have to subscribe to use the app or you're just going to exceed your resources if Hacker News sends traffic your way?
@miniscruff
gives you a good general set of ideas but if you can write down your baseline, your issues and your "goals" it's going to be easier to scale. As said, definitely don't run Flask in production with the development server, see Flask's deployment options to change that.
In general: you should measure. Yes you can throw money at the problem but where should that money go?
The answers you found all make sense:
Gunicorn (or similar) => running with a production grade server
Celery (or similar) => use a queue to distribute the load of async tasks, but do you need a queue?
Load balancer => well you know why, most cloud vendors already have one
For simplicity let's assume that there is no binding to specific cloud vendor.
Actually that would be a good information to know :D
Thank you for your insight. It all makes sense. Regarding the last point, there are scaling capabilities from the cloud vendor of course, but I want to rely as little as possible to vendor specific stuff (at least for now)
I would start by writing down the answers for a few questions, for example:
@miniscruff gives you a good general set of ideas but if you can write down your baseline, your issues and your "goals" it's going to be easier to scale. As said, definitely don't run Flask in production with the development server, see Flask's deployment options to change that.
In general: you should measure. Yes you can throw money at the problem but where should that money go?
The answers you found all make sense:
Actually that would be a good information to know :D
Thank you for your insight. It all makes sense. Regarding the last point, there are scaling capabilities from the cloud vendor of course, but I want to rely as little as possible to vendor specific stuff (at least for now)
Let me know if you need more pointers, it really depends on what you're trying to accomplish.
I understand the need to not be locked in too much but compare it to the possible amount of time you have to spend on DIY vs managed services.