0 cost architecture

Static pages generated with pre-rendering can be hosted on any cdn. Also do includes GitHub for organizational websites that don’t violate terms of service. Guthub has some strict and highly left winged restrictions. Any sites that are in that realm can be easily hosted else where.

The simplest Druid site is made up of panel pages that don’t use databases of any type. An experience that fits this model is a blog or portfolio website. Every physical blog post can be deployed as a physical page. Same is true for pages on a portfolio website or small business informational site. Like a static menu for a restaurant.

The above experiences can be deployed as a GitHub organizational pages site. So long as they don’t violate terms of service of GitHub. This architecture runs at no cost at all.

The next level would be sites that could violate GitHub and Ernst of service. In that case an alternate cdn will be needed using a company with less strict / left wing content censorship mentality.

Alternatives:

• aws s3 + cloudfront
• azure
• gitlab?
• others

The above area needs a bit more research about what type of content is restricted by vendors providing these services.

An important price of this is being able to retain panel pages without cloud. Therefore, a adaptor for the file system, mongodb, or way to persist idb will be necessary.

The next level uses a database. In theory any database can be used. However, Druid takes an opinionated approach to support. Options outside Druid core support will need to have adaptors created. Possibly reintegrated back into core. As a one man team I can only focus on support of technology that I believe in and isn’t outdated. However, the platform is flexible enough to create adaptors for any database. The database is the most difficult thing to change. Do I tons understandable in many cases to migrate applications front-end without changing the database. Like in the of relational. In that case a graph adaptor would be perfect. I’m actually talking myself into the importance of adding that to core.

Either way databases cost money. That cost can be distributed by sharing the same infrastructure across multiple sites and/or orgs. A database that supports that model very well is open search. Open search can auto scale and implement fine grained access control. Therefore, a single domain can be shared across multiple sites and organizations with compromise of performance. In this model the cost is effectively split taking advantage of open search scalability and access control. Not to mention open search is significantly less expensive than relational cloud databases. While not the complete picture open search can be combined with s3 storage to cheaply manage data in the cloud.

The opinionated search faculty of Druid is open search. The opinionated master object storage is s3. Storing master objects on s3 in natural form as json is nearly at no cost especially when it comes to the free tier. Druid has adaptors to persist and fetch objects from s3. Search adaptor unimplented because searching is one thing that s3 is not good for and when done at scale is expensive. So instead that task is relegated to open search domain.

S3 + open search are a low latency, high availability, scalable, efficient low cust alternative to a whole mammoth expensive, convoluted relational database. Therefore, druid does not support that option at the moment in core although graph adaptors could be created to do so.

Future alternative open search is Athena. Athena could be used in place of open search to support any search capabilities of sql but for s3 objects. Athena is a pure serverless option that is appealing for cost reduction.