Now v1 / Heroku / Render Hosting

Basic CNAME and alias support for MVP
NOTE: we have to carefully consider how this is implemented alongside Saasify proxying our backend API.
I think that Saasify should only proxy our backend API and services hosted on our platform should be served via a separate DNS ingress and load balancer that doesn't have anything to do with Saasify.

can you confirm this proposed design? Yup. That's what I would think.

Purchasing domains

NOT MVP

Importing domains to our DNS

NOT MVP

GitHub integration

NOT MVP

Persistent storage

NOT MVP
Post-MVP ability to attach persistent shared disk(s) to a deployment like render allows
In either case, we recommend using an externally hosted DBaaS instead of hosting your DB with us
If using K8s: Storage can be a PITA. Consider solutions like Longhorn

CDN (sitting in front of our application load balancer)

Not important for MVP
We may get this by default via Saasify's backend proxy, depending on how we implement the application proxying

Same with rate limiting and standard caching
Using Cloudflare edge workers under the hood
Scratch that; I think we don't want Saasify to proxy hosted application traffic — we only want it to proxy our platform's backend CRUD for managing deployments

Web dashboard UI

NOT MVP
MVP webapp will use default Saasify auth and acct mgmt UI
Post-MVP webapp will include a basic UI that mirrors the CLI's CRUD functionality to list and manage your projects & deployments
Use dashboard.render.com as general UI inspiration

Architecture

MVP Roadmap Proposal

TODO: use saasify for billing, identity, and api gateway?

would be great for saasify development
might slow us down in the early stages

re-use saasify-faas-utils for project and deployment ID format

fork saasify-cli for cli

fork saasify-client for JS client api (wrapping backend crud)

fork saasify's backend crud api

encapsulate abram's k8s as a module or service used by the backend api

TODO: work with to define exactly what this interface looks like

Core Backend Resources

Project

id: string // namespace/name
name: string
user: Ref<User>
team: Ref<Team>

Deployment

id: string // namespace/name@hash
hash: string
user: Ref<User>
team: Ref<Team>
project: Ref<Project>
build: Map<string, string> // build-time env vars & secrets (post-mvp)
env: Map<string, string> // run-time env vars & secrets
adaptor: Enum // docker only for now
dockerImageUrl: string // URL to the docker image
url // auto-generated public URL for this deployment
// in the future, i'd want to store a merkle tree of the hashes for the different files that comprise the source of this deployment, so we can quickly diff deployments and cache shit
source: string // URL to a compressed blob of source data (post-mvp once we support building docker images from source)
builder: Enum // source to docker image builder (post-mvp)
config: Map<string, string | number> // things like auto-scaling preferences (post-mvp)
disks: Disk[] // config for persistent disks (post-mvp)
what, if any, additional properties would we want Deployment resources to have aside from their unique id in terms of relating them to their derived k8s resources?

I would assume that most state will be inferred from the corresponding k8s resources, but we may want to denormalize some basic state here like "did this deployment build correctly" and "is this deployment" reachable? anything that might appear in a UI listing all of your deployments and their high-level state. def tradeoffs here to consider

User

normal user metadata shit

Team

normal team metadata
creator: Ref<User>
members: Ref<User>[]

Secret

id: string
user: Ref<User>
team: Ref<Team>
key: string
// wherever we store the secret's value, key should be enough to retrieve it

Misc Questions

Is a single k8s cluster appropriate to handle all users and all deployments for MVP? What about post-MVP?

For MVP, yes. Post-MVP, probably but there could be a debate had here. Either way, I would stick to one cluster for the time being.

Post-MVP, how do k8s federation and multi-region deployments work? Are there any changes to these core resource models that would be useful to consider ahead of time?

Huge topic. Lots of unanswered questions in the industry for this. Not useful to consider ahead of time. No changes necessary to core resources would be helpful up front.

How exactly should DNS work for deployments and production aliases?

Would love to see a rough sketch here for reference.
This isn't really as hard as you may think. We don't really need to worry too much about it. I'm not sure what exactly you want in a sketch.

Publicly available app gets a subdomain (example.onrender.com)
User can CNAME/ANAME/ALIAS a domain to that subdomain. They then have to tell us about that domain. We next poll the DNS to check that it routes to example.onrender.com (and/or the IP address to support ANAME/ALIAS).
When we find that it routes, then we can use it as a host, manage TLS, etc.
There are some implementation details that are glossed over here... But it isn't really that difficult to automate.
Note: We don't actually manage any DNS here for anybody except for our own *.onrender.com domain name which should/will be managed by an actual DNS zone manager anyway.

What are Abram's thoughts on using node.js for the backend api?

I would prefer to use a language that we can both easily contribute to, and 95% of this can be forked from saasify
If it's a node backend you can count me as useless. I have also experienced major usability issues with the Node k8s library. The only k8s libraries that are really used in production in serious k8s implementations are the Go, Python, or Java libraries. I have only used the Go one in production, but the Python one has a long history of being used in production as well.
I could be convinced to use Python for the backend as well.

Do we care about differentiating ourselves from Render / Heroku at all?

I feel like v1 should be a heavy mix of now v1 and render
Maybe down the road we consider positioning
Yeah, let's focus on the rock solid UX first - differentiation will happen when we learn who is using it and why IMO.

Branding

Naming Notes

ideal name for CLI is 3-5 letters

uniqueness & SEO would be great but not a hard constraint

Naming Keyword Brainstorm

now

then

deploy

cloud

instance

container

docker

simple

easy

quick

fast

instant

auto

one command

immediate

immutable

server

serverful

backend

BaaS

host

hosting

dev

infra

devops

stack

k8s

Possible Names

(focusing on names with reasonable & available domains)

zing

zingup.dev (owned by abram)
npm package squatted ⇒ we could get it

cloudy

npm package squatted ⇒ we could get it
possibly cloudy-deployments.com - meh
deploy-with-cloudy.dev - meh
deploy-to-cloudy.com - meh
cloud.auto
cloudstack.sh

serverful

serverful.sh
serverful.io

easycloud - meh

easycloud.sh

pliable

pliable.dev
pliable.sh

peasy - meh

pea.sy
peasy.sh

vm.now (booo .now TLD isn't publicly available)

vmnow

vmnow.sh
vmnow.dev

vm-now

vm-now.sh
vm-now.dev

nowv1

nowv1.sh
nowv1.dev

now-v1

now-v1.sh
now-v1.dev
now-v1.com

Leadgen

https://twitter.com/thekitze/status/1256921786333224960