|
|
|
|
|
by OriPekelman
2075 days ago
|
|
I'd agree with the part of maintaining your own server. like personal one. I promised myself like 5 years ago I'll never be my own (and family and friends..) sysadmin ever again. ... but serverless needless mean tiny programs in nodejs. serverless is basically a super category for what we used to call PaaS simply saying the granularity of what you deploy can be smaller. it doesn't mean it has to be smaller. as far as I am concerned it can also be way bigger than what heroku represents. This is what composability on infrastructure means. It means you have the same interface to deploy a single line of JS... and a service that is itself composed of a couple of monoliths each with its own data backend. The "form of the program" should be dominated by the problem it solves not its deployment target.
That is the thing we are trying to achieve at platform.sh where I run product. A uniform interface to a composable infrastructure. We are not quite yet there... this is not a trivial problem. And I don't think that "just ship your machine" Docker style solves this. To be really composable you need both finer grain and higher abstractions. What I mean is that at every level you compose you need to be able to define dependencies (my function requires this version of nodejs and this system lib) my already composed monolith that includes a dependency on MySql and Redis) is a dependency of this static site builder.. at each layer the semantics are very close. But not the same. Just shipping a container eludes these issues and basically reproduces the model of "good old servers" in a way this is contrary to what true serverless has to offer. Which is absolutely not caring at all about the runtime. And caring only about the design of your system such as that it espouses best the form of your problem. |
|