locustmostest

We're all-in on serverless / cloud-native for our platform (document management); it works really well for our model, as we deploy into the customer's AWS account.

The initial development learning curve was higher, but the end result is a system that runs with high reliability in customer clouds that doesn't require customers (or us) to manage servers. There are also benefits for data sovereignty and compliance from running in the customer's cloud account.

But another upside to serverless is the flexibility we've found when orchestrating the components. Deploying certain modules in specific configurations has been more manageable for us with this serverless / cloud-native architecture vs. past projects with EC2s and other servers.

The only downside that we see is possible vendor lock-in, but having worked across the major cloud providers, I don't think it's an impossible task to eventually offer Azure and GCP versions of our platform.

Exactly. We'd love it if more people did that with our document management system. (https://github.com/formkiq/formkiq-core)

We use what might be called a microlith pattern with Lambda for our "infra meets code" document handling project (https://github.com/formkiq/formkiq-core).

There's nothing stopping someone from taking what we have and porting to an EC2, but for most use cases, this pattern seems to work best.

We break our Lambdas up by how they are used, to keep sizes down, with the option to break up further if we need to.

Growth is slower than we'd like, for sure. But since we're firm believers in pg's maxim, "don't die", we've become cockroaches who can't be killed off.

I couldn't find any explanation of where the data would be found. Are they splitting data across clouds, and constantly "porting" that data from cloud to cloud as part of their portability?

Orchestrating the application layer across clouds is interesting, but how does their data layer work?

We may want to get in touch with each other. We have an Open Core document management platform that runs in AWS; I'm not sure about your roadmap, but there may be something there that's of use: https://github.com/formkiq/formkiq-core

I've enjoyed all of the episodes so far, but this one was definitely the stand-out.

I believe the next wave of SaaS is products that provide custom deployment, operational support, and cost optimization, where specialist software orgs can provide standard efficiencies and engage AWS for deeper looks.

One possibility is to use our open-core document management API build to deploy in your AWS account: https://github.com/formkiq/formkiq-core

The files are stored in S3, with customizable metadata storage in DynamoDB. As the system is designed to run on AWS Serverless and Managed Services, the majority of the cost will come from S3 storage fees.

Yes. I agree with that.

I'm not a huge fan of atmospheric manipulation vs. orbital engineering. I think there's a weird mental block for many people where a massive earth-based project seems more feasible than doing something that is probably no more resource intensive off-planet.

Space-based solar is probably still years away because we would need to assemble in-situ on Earth trojans or other asteroids, and then propel the materials to the lagrange point. But backing off the global temperature ten to twenty years from now and gaining control over solar input to our planet seems like a better idea than messing with the atmosphere.

I'm one of the co-founders of FormKiQ. We had originally expected startups to work with Core (the free version), but based on feedback we're looking at some changes, including a startup program. Let me know if you'd like to discuss how this could work. Thanks!

Do you mean document control, or diff on text contents?

For plain text, diff is do-able, but I don't know if comparing two PDFs can involve a detailed "diff" vs. a checksum, since the text could be the same but there's a change in layout, an image, etc.