Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I'd recommend reading more thoroughly about Dokku (or PaaS in general) since it is somewhat clear you don't understand the value prop. Just grepping for certain terms isn't gonna get you very far.

Dokku is Docker + Buildpacks + Orchestration. You give it a buildpack (developed/popularized by Heroku) to specify your application, which is the main "serverless" part. Then you tell Dokku that you want datastores or queues or whatever, via plugins[1]. Dokku handles pulling the relevant docker images, running them, and linking it all together. In other words, Dokku is open-source Heroku, where you can add databases and such with a single command, specify your app with a buildpack, and you're off to the races.

If Dokku only did the application via buildpack part, people would not find it nearly as useful and PHP on a webhost somewhere would indeed be a good alternative.

But Dokku is not that, it is a PaaS, so it can also run your PHP application just as easily. And if you're self-hosting Postgres and RabbitMQ via Dokku, why would you run your PHP on Dreamhost? You probably wouldn't, you'd throw a PHP buildpack up there and call it a day.

[1] https://dokku.com/docs/community/plugins/?h=plugins#official...



ok, but "pulling the relevant docker images" does not scale, bro. There's a gazillion of parameters to fine tune a Postgres alone, and trust me, running db inside a container is bad, as stateful containers are terrible in general.

And I really do hope scaling should be as easy as "pulling docker images"


So, how is PHP + queue library different than Dokku(or PAAS as you call it) + queue plugin? Other than the fact that you write it all in yaml/json/gui instead of code?

> "I'd recommend reading more thoroughly about Dokku (or PaaS in general) since it is somewhat clear you don't understand the value prop."

My cynical and uncharitable translation of this and the rest of your post for the GP: We've invented platform or PAAS or devops so that we can carve-away work from devs that used to traditionally do this kind of stuff in partnership with infrastructure, and you're just not understanding it because you're coming from a dev perspective.

It's all just evangelism/marketing-push to gather the online webosphere mindshare and capture the development process so that all that's left for the downstream individuals (developers) is nothing but config/yaml/plugin-ecosystem and even that stuff only the ordained priests of DevOps understand (or are allowed to touch), again leaving developers with even less, making them glorified code-monkeys that need to spit out CRUD screens. It's either that, or put "DevOps" on your resume or title, almost like a mafia-style shake-down.

It works, sure, provides immense value sometimes and gets you to market quickly sometimes, sure, etc. But damn is it toxic and detrimental for our community in the long run. In an alternate universe or timeline we could have gone some other direction, but this is what we have for now, so we have to live with it. DevOps and UX will many years from now be known as two very bad paths that we allowed our industry to be dragged down into.


To answer your question with another question: what exactly is the PHP queue library interacting with? Where is the queue being persisted? How is that persistence layer being deployed/run?

I am a dev, so your translation is indeed cynical and uncharitable (and inaccurate).

I also don't understand what you have against DevOps or UX. DevOps is just how you actually run the applications/services/etc (that you've written with code) in production. DevOps can be done by a developer or by people dedicated solely to that task. UX is just caring about how end users actually interact with the application/services/platform. This can also be done by developers, or by designers, or by UX specialists, or whomever.

These concepts exist regardless. Sure, you can choose not to care about how your application and its required dependencies are run. Sure, you can choose not to care about how your users interact with the things you are building. But not caring about those things doesn't mean they go away.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: