My view on it is that companies build cargo ships when most just need a normal boat. For the particular orchestration I am thinking of, it scales to massive use with billions of transactions. The problem is, the idle infrastructure is so big and the bulk of deployments don’t need that potential. I agree with you. For much of what I have done for myself I have learned to love sqlite3. I love the simplicity of one process and one file.
The projects I’m working with are big enough to rule out one process/one file, but I agree. Part of all of this is why things like Heroku, Google App Engine, and fly.io all appeal to me (especially the early Guido-era App Engine). They had all this infrastructure, but using it was no more complex than just using a normal project.
Right now at work I’m banging my head against SQS.
You do need a message queue sometimes. Though I’ve often found that just inserting into a table works well enough if you plan your indexes right.
My view on it is that companies build cargo ships when most just need a normal boat. For the particular orchestration I am thinking of, it scales to massive use with billions of transactions. The problem is, the idle infrastructure is so big and the bulk of deployments don’t need that potential. I agree with you. For much of what I have done for myself I have learned to love sqlite3. I love the simplicity of one process and one file.
The projects I’m working with are big enough to rule out one process/one file, but I agree. Part of all of this is why things like Heroku, Google App Engine, and fly.io all appeal to me (especially the early Guido-era App Engine). They had all this infrastructure, but using it was no more complex than just using a normal project.
Right now at work I’m banging my head against SQS.