With lots of progress being made on the Plone API and the general best practice being to build against the API, how crazy would it be to look at a serverless implementation of Plone?
What would be the blockers that would prevent Plone 6 from being implemented as serverless deployment?
To me it seems that the reliance on the ZODB would be the biggest blocker, unless there was some kind of ZODB as a service. I suppose it would also require the Plone API as a service in some way.
Perhaps it's still too early in the morning here, but just my thoughts.
I think the best place to start for something like that is the work done on headless plone.
With the architecture of guillotina, I imagine a db connection can be created to work with a serverless implementation. @ramon is working on a cassandra db implementation for it for example.
That being said, I'm still not sold on serverless. I kind of think it's hyped up so we can all depend on the cloud providers for everything...
Yeah.. I get that, but I already rely on some provider now, whether that be Linode, Digital Ocean, AWS, Google Cloud, so it is somewhat moot for me.
I'm enamoured by the pay-only-for-what-you-use promise of serverless. I'd want to be careful about lock-in though, watching the space and looking for a serverless implementation that can easily work across different cloud providers would be worthwhile.
I may have misunderstood your question @pigeonflight but one of the things we've been discussing for headless is the potential to build a service that developers could subscribe to and use without having to do any of their own installation.
The major "problem" with Cassandra is that you need to know about your (future) queries in order to choose the cluster key properly. Later you will have almost no chance for changing the cluster key without major migration work. In particular in the context of Plone you need to be able to perform arbitrary queries against your data...there are better solutions than Cassandra in this context. As Timo wrote: Lucene based solutions like Solr or Elastic are better solutions as secondary storages, for enterprise fulltext searches etc. He is also correct about the quality of the Postgres fulltext search compared to Solr or ES.
The idea is definitely more about making Plone (or the spirit of Plone) able to run in a serverless way. For persistence there would be need for something like S3 and a DB but apart from that, everything else would be serverless, Google cloud functions, AWS lambda or something like that.
The difference between serverless and cloud is just per second billing vs per hour billing. And serverless you don't pay if you don't use it, and cloud you pay even if the cpu is idle. Both serverless and cloud can offer rapid autoscaling so thats not really a difference.
So then you question really is, is there a market for a cms which runs in a way that doesn't cost anything when its not used. That means low traffic sites. The $5 LAMP hosting type market.
or is there another reason why serverless would be attractive that I'm missing?
So let's say I am paying $5/month for my mostly idle site... is serverless interesting only to drop my cost down to $1/month or less? Just wondering what the real life use cases are.
To be clear... these are crazy musings... there may be persons who think this worth their while. At least it will be out there as a direction to explore.
I can't answer that confidently. But based on the little I know and a hunch, I'd say maybe. The tricky part is an economical solution for a distributed ZODB (again a guess).
If it's just to make it cheaper to host a Plone site I don't see why we'd put so much energy into saving someone $4/month I do understand that it's an exciting thing to tackle from a developer's point of view... But that's just me playing devil's advocate.
Here's the scenario. You are a hosting provider and want to be able to scale cost effectively.
It starts to make an impact as you approach 200 installations. If you are really successful and get to 20,000 installations you also want a simple way to manage the whole operation. Hunch again... I think serverless might help with that.
At the moment... these are public musings, nothing more.
I do understand that it's an exciting thing to tackle from a developer's point of view... But that's just me playing devil's advocate.
.