GreenBackBoogie

Stay there, do nothing, take the paycheck and work on yourself: - brush up on your skills - start / contribute to a few projects, create a portfolio (I don't know what's your work experience) - start applying for jobs <- maybe I should have started with this.

You owe nothing to that company, at the end of the day you're just one name in someone's Excel file, the whole "family at work" trend is something awful that should not have been born, so you better get out of that.

Good luck!

https://excalidraw.com/ -> This one is cool, it makes something look like it's hand drawn.

https://app.diagrams.net/ -> this one has a big shapes library, so it can go from UML to cloud diagrams, it's also easy to use and a lot of export options

I fully agree with you, but it's still a PC, although not envisioned for the power users, but for the people who just need to do the most basic of stuff (e-mails, maybe a few documents, etc.), that's what a ~6W CPU can deliver.

Again, you tend to overlook things that are already on the market, like https://www.raspberrypi.com/products/raspberry-pi-400/

or the myriad of SBC-based computers like this. The only thing you should do is to install an OS, which is something everybody tends to do and succeed nowadays.

He's probably referring to other products, but it seems he overlooked the SBC, which come in all forms and sizes and, generally, being low power devices, can't really do much besides hosting some not so demanding apps (looking at containers).

Not trying to sound condescending, but do you have any working knowledge of containers?

That's why I said you need to go revamp the design of your app first, going from a "monolithic design" to a close-knitted, loosely-coupled "microservice-based design":

- split the functions of your app into pieces, do that on paper - draw the interaction between all of those components with arrows, to see the inter-dependencies, see what functions need to read/write from a database and which need to poll another function for checking the state. - read a bit about sharding (both app and database). - start "breaking" the above functions into separate entities, containerize them (see what runtime you need, what extra libs, what OS would you prefer in case you need to troubleshoot, make sure you won't have a multi-gigabyte image, optimize as much as you can, you can do it later but you won't, let's be honest, that's how technical debt comes into play) and try to have them play nice with each other.

When you managed to do that, try to use docker-compose and do some testing, to see how the performance is doing, bugfix, do some more testing, then some more bugfixing afterwards and then, when you're happy with what you have, read about Kubernetes / Openshift / EKS / AKS and do an analysis on what you need from a container orchestration system, have some requirements then compare those with all the above examples I've wrote and get the right mix of cost per functionality.

I can't really recommend any reading for it, there are a lot of resources on Google for the theoretical stuff, but to put them in practice, either bring in someone experienced from outside your organization (if that person doesn't exist inside of it) or try to put together an innovation team that'll do this, but with a lot of "trial and error" sprinkled all over it.

What would be your final purpose with this? Slim the image down? Hoping to have a better CI/CD strategy if split it in multiple images? Anyways, I have a hunch that this will be solved only by having an architectural revamp of the app, try to design it in such a way that it will work as multiple smaller services interacting together as a whole (micro-services).

Also, Docker Compose doesn't really help you with this. It only helps you with "syncing" the components of your app together, but since you don't have the components of it yet running as separate images / containers, it's pointless, at least at this time.