In your case, I think you're best off learning each of those things from separate courses / learning material. Mobile app development and Kubernetes are simply not related at all.
This Flask course focuses on building a classic web app using server side templates. It happens to use Postgres and Redis while also performing background jobs with Celery.
To me that's the bare minimum for building a web app with Ruby or Python. Web app + DB + background worker + sprinkles of JS on the front-end. We use Docker Compose to get it all running because the alternative is rolling your own Python environment from scratch which is IMO more time consuming than using Docker.
That's also a good article you linked and I agree with pretty much everything they wrote.
I think it's more important to ship your app than try to incorporate every buzz word for the sake of doing it. I'll admit, sometimes learning new things is highly motivating but at the end of the day, the tech wins REALLY need to be there for it to make sense.
For example I choose not to use Kubernetes in production because 1 server deploys with Docker Compose is very easy to reason about and it works well, even for decently high traffic. I treat ops like I do code refactoring. It's important to get something working, and if you ever get to the point where it becomes a problem, then refactor.
The interesting thing there with ops is, if you have a SAAS app running with 800 customers and 50 of them are on concurrently, do you really need a self healing auto scaling Kubernetes cluster on multiple regions?
Probably not. Those 800 customers might be generating you $49 / month each or $39,200 per month in revenue and something like that could be running on a single $40-80 / month server with a Flask set up (or even Rails for that matter).
In my mind, I'd rather spend my time figuring out how to grow from 800 customers to 8,000 and even then you could probably vertically scale your server, but at this point you're rolling in so much cash that it's all irrelevant. You could just pay someone $100,000 to fix your scaling problems over the course of a few months (without outages) and continue growing your business.
Basically, front load your time in making your product really cool and successful, then invest the time (or money) into scaling when you need it.
I understand your points and somewhat agree with them, and it's great advice for people who want to build a product on the side.
However what I meant is, what if building and iterating is the goal, not the means to the product? When you're building a SaaS app you have to worry about market fit, sales(as the article talks a lot about), if you're not concerned about finding users and growing, a side project app can be a great way to learn and show knowledge.
Perhaps the classic web app with server-side templates is the quickest way to launch an MVP, but what I want is a way to build something integrating as many different things as possible, a lot of companies will want to see your GitHub, if you can present a largely-complex yet well-designed application where you can showcase front-end development, backend APIs, containers and what not you're one step ahead.
I want a sort of sandbox to play with, not an actual product, would be interesting as a multi-part series course(start with simple web app, keep iterating, separate web app from server code, remove bootstrap or other UI kits in favor of self created styles, incorporate mobile, watch app, whatever you can think of. This could be a good exercise in writing maintainable applications.
In your case, I think you're best off learning each of those things from separate courses / learning material. Mobile app development and Kubernetes are simply not related at all.
This Flask course focuses on building a classic web app using server side templates. It happens to use Postgres and Redis while also performing background jobs with Celery.
To me that's the bare minimum for building a web app with Ruby or Python. Web app + DB + background worker + sprinkles of JS on the front-end. We use Docker Compose to get it all running because the alternative is rolling your own Python environment from scratch which is IMO more time consuming than using Docker.
That's also a good article you linked and I agree with pretty much everything they wrote.
I think it's more important to ship your app than try to incorporate every buzz word for the sake of doing it. I'll admit, sometimes learning new things is highly motivating but at the end of the day, the tech wins REALLY need to be there for it to make sense.
For example I choose not to use Kubernetes in production because 1 server deploys with Docker Compose is very easy to reason about and it works well, even for decently high traffic. I treat ops like I do code refactoring. It's important to get something working, and if you ever get to the point where it becomes a problem, then refactor.
The interesting thing there with ops is, if you have a SAAS app running with 800 customers and 50 of them are on concurrently, do you really need a self healing auto scaling Kubernetes cluster on multiple regions?
Probably not. Those 800 customers might be generating you $49 / month each or $39,200 per month in revenue and something like that could be running on a single $40-80 / month server with a Flask set up (or even Rails for that matter).
In my mind, I'd rather spend my time figuring out how to grow from 800 customers to 8,000 and even then you could probably vertically scale your server, but at this point you're rolling in so much cash that it's all irrelevant. You could just pay someone $100,000 to fix your scaling problems over the course of a few months (without outages) and continue growing your business.
Basically, front load your time in making your product really cool and successful, then invest the time (or money) into scaling when you need it.