With any given monolith framework (rails, django, etc...) that runs on docker, you'll be fine on cloudrun for most apps. Try fargate if you prefer aws (way harder than cloudrun, but same paradigm). You assets can surely be moved to any cdn easily.
You don't need to split your apps to see hundreds of endpoint. You don't need serverless.com to run a ruby based framework, neither lamby, neither jets. You can move away from sidekiq and use shoryuken, or cloudtasker. You now have serverless postgres at aws, gcloud might follow sometimes soon.
A class is a microservice, and your monolith is the best way to manage thousands of those (let's just laugh about what's called "service discovery", it sounds so painful).
imho monolith devs have been fooled by the hype around tools that were actually lacking of so many functionalities. They already had everything in hands. Redwoodjs or Blitz are a solution for js devs that struggled so much that they ended up creating their monolith-capable solution.
Give your old app a go. Don't loose time believing that you NEED to spend hundreds of hours learning a new framework that did not even prove a fraction compared to your framework.
I run technology at Ingenious, an agency specializing in building products for the healthcare industry. 💛 remote work ‧ sometimes 🔨 are the best tool for the job.
I agree with most of what you say, I still believe running Docker containers is far more complex than being provided with a platform, either a serverless platform or a serverfull (?) one (rendr, Heroku).
Other than that I fully embrace the monolith model myself, and I make the conscious decision of what problems I want to deal with. I understand I'll need to deal with some infrastructure problems and probably incur in more costs, but I gain productivity and traceability of my code and program behaviors, and that for me is far more important.
Well it boils down to saying "Running a monolith is painful, and if you dare using docker, you'll loose productivity"
Things can alway get better, and there are always improvements to find anywhere
Most failed at serverless. It has been created by cloud providers to increase lock-in, that's all. Not to really help anyone's productivity. Going serverless does not mean that you have to stick to the advertised schema
Once you read between the lines, it'll maybe cost you an hour or so to learn those ten lines of docker maybe, and probably way less to find out where your stdout should go. This can be seen as a productivity loss of course..
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
With any given monolith framework (rails, django, etc...) that runs on docker, you'll be fine on cloudrun for most apps. Try fargate if you prefer aws (way harder than cloudrun, but same paradigm). You assets can surely be moved to any cdn easily.
You don't need to split your apps to see hundreds of endpoint. You don't need serverless.com to run a ruby based framework, neither lamby, neither jets. You can move away from sidekiq and use shoryuken, or cloudtasker. You now have serverless postgres at aws, gcloud might follow sometimes soon.
A class is a microservice, and your monolith is the best way to manage thousands of those (let's just laugh about what's called "service discovery", it sounds so painful).
imho monolith devs have been fooled by the hype around tools that were actually lacking of so many functionalities. They already had everything in hands. Redwoodjs or Blitz are a solution for js devs that struggled so much that they ended up creating their monolith-capable solution.
Give your old app a go. Don't loose time believing that you NEED to spend hundreds of hours learning a new framework that did not even prove a fraction compared to your framework.
With little efforts, it'll work, serverlessly.
Thanks for your comment Ben!
I agree with most of what you say, I still believe running Docker containers is far more complex than being provided with a platform, either a serverless platform or a serverfull (?) one (rendr, Heroku).
Other than that I fully embrace the monolith model myself, and I make the conscious decision of what problems I want to deal with. I understand I'll need to deal with some infrastructure problems and probably incur in more costs, but I gain productivity and traceability of my code and program behaviors, and that for me is far more important.
Well it boils down to saying "Running a monolith is painful, and if you dare using docker, you'll loose productivity"
Things can alway get better, and there are always improvements to find anywhere
Most failed at serverless. It has been created by cloud providers to increase lock-in, that's all. Not to really help anyone's productivity. Going serverless does not mean that you have to stick to the advertised schema
Once you read between the lines, it'll maybe cost you an hour or so to learn those ten lines of docker maybe, and probably way less to find out where your stdout should go. This can be seen as a productivity loss of course..