Up 2.0 — feature requests

[tj]

I'm contemplating a 2.0, I have some features in mind of course, but I'd love to hear what people would like to see if you could have anything at all — or if you tried Up and decided it won't work for you, let me know what was blocking you :D

So far the biggest changes would be:

• Global by default (with tunable regions)
• Wider range of runtime support (not locked into Lambda's runtimes)
• Dockerfile support
• More cost-effective for larger scale apps
• Faster provisioning

Which would you prefer:

Does the cloud provider matter to you?

Which price range seems fair?

[chrismalek]

I am curious what is on your 2.0 short list. I have been using up for my website and some other play projects. I use golang primarily. I have some hugo and docsify sites up and the workflow is so simple and basically free other than my premium Up fee. I may soon start using it for some client projects for some integration endpoints. I am a consultant that does a lot of integration work between corporate backend systems. For what I am using UP for right now it, it has the features I need. It is software so it is never done. I have been doing pretty basic stuff so far.

I saw a comment on another thread/issue that your revenue may not be high enough to support this project. Or maybe that was in reference to a major provider addition. I am hoping this stays around.

[kaihendry]

Besides the bugs I've murmured in, I think 2.0 should probably leverage the proxy design and promise, by supporting another Cloud provider? Proof of concept more than anything else.

I personally advocate Up since it makes it painless to run your code locally. The clincher is to prove this is the case on another cloud platform. Or perhaps show how it can be bundled up & deployed with docker/podman.

As a Go user, would be nice for demos to fit neatly with https://github.com/google/go-cloud

[tj]

@chrismalek thanks! I'll definitely keep it maintained regardless of income, I can't say I'm making a lot but the maintenance side of things is pretty easy.

@kaihendry if I do a 2.0 it'll probably be on GCP actually, it's kind of tricky to make something truly portable until the featureset of each cloud provider is comparable, maybe that'll eventually happen but for now AWS has some limitations

[berzniz]

Just wanted to comment because I enjoy using Up and it is working well for me in a different number of projects. Up is almost feature complete for me, so it's hard coming up with future features.

A few things that come in mind are:

1. Spawn background jobs (lambdas) that are all configured on the same project.
2. Ability to interact with the Serverless Framework / Apex, so a project will be self contained.
3. Node v10 support (hopefully will be in Up 1.0 as well)

One thing that is always difficult and is probably out of the scope for Up (but worth mentioning) is:

• Packing the project in the most optimized way (regarding Node at least). I've actually written a lot of code to optimize the package (automatically create a .upignore file that only takes the needed files from node_modules)

[tj]

@berzniz appreciate the feedback! I totally agree, I'd love to be able to handle everything in the same project, or at very least have nearly identical UX. Dockerfiles and wider language support is something I'd like, but at the moment that's only doable on GCP. FaaS is fantastic for event processing but I never thought it was a good fit for HTTP, which is sort of why I created Up in the first place, to try and hide that aspect

[asavoy]

We love Apex Up. We found it great for:

• short-lived prototypes
• microsites, pure static sites or sites that rely on an external API
• microservice APIs
• lightweight analytics service

We've had to fallback to Lambda deployed with Terraform when:

• integrating with other AWS infrastructure, such as VPCs, databases, cron-scheduling, custom alarms, custom IAM roles
• setting maximum concurrency
• needed to use the python-3.7 runtime

It would be even more valuable to us with these features:

• easier integration with a data store; DynamoDB, Elasticache, RDS, etc.
• support for Dockerfile
  • or perhaps some examples where Docker is used to build?
• support different AWS accounts per stage
• easier Github CI integration
  • we need to setup a custom IAM role & policies to deploy
• upgrade to ECS Fargate tasks (probably more useful for Apex)
• easier, more complete experience like Heroku
  • (at least that's the feedback from our website team who uses Heroku for several static Next.JS apps)
• example auth integration with Google Auth or AWS Cognito
• support for Google Cloud Functions

Also, we'd pay more than $20/mo for Pro, perhaps another tier with some of these features?

[cloudkite]

Love UP and would be excited for a UP 2.0 even if it cost bit more than current PRO to stay sustainable

Heres my wishlist :)

• websockets
• support using ALB instead of API gateway
• at a certain point alert emails get very noisy. some kind of aggregation ie daily/weekly email which displays errors grouped by message with a count. Or easy integration with other error reporting services which do this

[tj]

Thanks for the feedback guys! Super helpful

[bfelbo]

We're using up for our main API and quite happy with it. It sounds amazing that you're considering an 2.0.

Generally, we'd love it if up 2.0 focuses on improving the core rather than the peripheral functions (logs, env, alerting, etc.). For us at least, the current peripheral functions are perfect for simple APIs/sites. We then slowly migrate to dedicated services as needed, which provide much more functionality than up could possibly do for a single use case (e.g. log analysis).

What would make up 2.0 a game-changer for us is if it supported:

• seamless multi-region deployments (important as AWS ramps up their Global DB capabilities)
• continuing background processing after response (e.g. by calling another lambda seamlessly)

I know that up recently added some multi-region deployment features, but it still seems a bit rough on the edges. We'd be happy to pay more if up had these features :)

[bfelbo]

@berzniz We're using webpack with up and it's working quite well. Perhaps worth checking out for your use case. Happy to share our webpack.config.js and .upignore if that's helpful.

[tj]

Just to set expectations it would coming after my next product, which is a few months away, so it could still be a while but I'm a huge fan serverless stuff so I'd love to try and "perfect" this stuff as much as possible!

[tj]

Any opinions about PaaS? I prefer self-hosting things personally, but it'd be pretty easy to compete with existing PaaS stuff, and could allow for nicer UX. I have a hard time imaging larger companies using any kind of PaaS though that isn't well-established like Heroku.

The other possibility is that it's sort of semi-PaaS, where I host some of the deployment pipeline components but your accounts contain the applications and billing etc. This would make global deployments easy since I can host the infrastructure to fan-out your deploys to many regions.

Up 2.0 to start would basically be global serverless (completely on-demand) Heroku w/ Dockerfile support & buildpacks etc, with more or less the same experience you get with Up currently.

[chrismalek]

just my 2 cents so take this with a grain of salt.

The thing I really like about UP is that I have very good visibility, control, and ownership of the pieces in my own AWS account. I am not granting some vendor access to a bunch of my stack and data. I work in ERP for large and mid sized corporations. The data and applications I work with are extremely sensitive. So I generally come from a paranoid perspective around giving any vendor access to the data or having any visibility into the data. With everything in my own AWS account, I can audit and even de-provision and know it is secure or deleted.

So if there is some PAAS component:

• It needs to be very clear about what it has access to and maybe have granular permissions what I want it to have access to.
• Should maybe be "opt-in" so the paranoid can choose not to adopt it or adopt pieces selectively.

[tj]

Understandable, that's my general impression of more series companies as well, even personally I really prefer to know everything I build is going to be around long-term without trouble.

The downside of this semi-PaaS would be that I'd require access to a zip of your app upon deploy— but I can look into making this fan-out portion self-hosted as well, it's probably worth it, I don't want to be responsible for anyone's code.

Does the cloud provider matter for your use-cases? Or are you locked to AWS?

[berzniz]

My scattered thoughts:

I think that the success of Netlify shows that people are willing to pay for:

1. Great developer experience and a wow effect
2. CI / CD flows
3. Hosted not on their cloud
4. Very reliable hosting

While Netlify focuses on static website (although they added functions in the past), up could focus on API servers.

Added benefits of hosted up could be:

1. Automatic build and deploy following GitHub/GitLab webhooks
2. Preview deploys of every build to a new URL
3. Deploy to your own AWS account for companies who needs/wants it

This set of requirements might not fit a one person operation (Zeit are doing something similar, but from my experience, they have a lot of downtimes).

[Siilwyn]

To add to the previous reply about Netlify's great developer experience, for me the biggest starting hurdle is the absence of vanity urls (#179). The added stage area forced me to dig through Nuxt configuration and finding out there is no way to solve it without a custom domain.

[tj]

The problem I see with the vanity urls is that it's unlikely side projects without a domain would produce any income, so I'm assuming it's not something people would be willing to pay an Up subscription for.

[Siilwyn]

That is definitely true but it is also a hurdle for users when investigating if using Up is a good option which can cause them to choose something else. In the long run, if users know Up through side projects there is a higher chance they'll evaluate it as an option for 'money making' projects.

[tj]

True true, so far I haven't seen much of a return when free things are offered but I'll still keep that in mind, the overhead shouldn't be bad in this case. I need to either attract a ton more $10-20/mo customers with something like the vanity stuff, or focus on features for business and charge more to make it viable.

[sudhirj]

I'd say add another tier and charge for cryptography.

The $10 to $20 are indies and hobbyists, or personal or small business folks. Don't abandon us/them.

I also work for a company that spends six figures a month on AWS, though - the bill differentiator will be encryption (secure parameter store), and any other IAM specialties you might think of, and maybe the multi-user setup - do you charge per team or per user? It should be per user.

[tj]

@sudhirj yea I totally agree, going forward I want to try and have all my billing scale with the company, either metered use (when it makes sense) or by team members like you mentioned, I'll make sure to keep that in mind for v2 😄

[loganpowell]

My recommendation: Charge per seat instead of a flat fee for unlimited seats. You'll have a price model that reflects the support model.

~Also, a nice-to-have: make an optional API that mimics Zeit Now, so people can easily migrate!~ (strike that, Up has a better API!)

Finally, the primary reason I went with Up is because it's self-hosted. I like that the product as just that, a product, not a platform I become locked-in to or something that will add to my utility pricing. Also, coming from government, the fact that it's self-hosted is crucial for security review processes. It's far easier to security check a CLI than it is to check a platform. We're locked to AWS (GovCloud), they've already spent $millions (and millions) on security reviews.

[tj]

@loganpowell thanks for the feedback! I definitely feel better with self-hosted as well, seems like most people prefer it which is good to know.

If I do a 2.0 the per-seat model would be great, the only problem I suppose is that say you're deploying in CI, then you effectively have one user/seat, so I'm not sure if it would work in practice or not, better than what I have now in any case haha.

[loganpowell]

suppose is that say you're deploying in CI, then you effectively have one user/seat

Perhaps - in this case - you would charge per container

[kennetpostigo]

I'm just going to post some of my little startups experience and usage of now.

Usage:

Now v1: auto scaling, long running process, and realtime

• We have a sophisticated piece time scheduler and it needs to be long running process
• We had our api gateway with some real-time functionality using now v1
• We have a live event tracker that would be talked to via websockets

Now v2: FaaS, ephemeral, short running

• Good for services that don't need to hold state or be long running
• Most services and endpoints tend to fall into v2

The Pain

Since now v1 got shut down we had to build a lot of tooling around polling. However this made 2 of our services particularly Waaaayyyy more expensive. These were the realtime portions of our gateway and event tracker that used to happen via sockets and were pretty cheap in now v1. To the point where those 2 portions of our services account for 97% of our bill. Which pretty much sucks since our bill has gone up 3 digits.

Solution

We moved the real time portions of our stack into Digital Ocean and use a project we found on github called exoframe to manage and host our realtime code. The downsides are, there are no scaling capabilities built into the project, and the work on the scaling functionality is To be determined. Exoframe is awesome tho:

• Automatic domain aliasing, subdomains
• Lets Encrypt
• Easy deploys

Once we moved to Digital Ocean + Exoframe our bill shrunk from a couple hundred dollars(depending on the events we chose to track) a month to ~$50.

However we lost a lot of things in doing so:

• Logging became harder
• Tracing became harder
• Observability of uptime

Perfect world

In a perfect world we would be able to use one service that offers both to us with a simple cli to create deployments, dev environment to simulate production (now dev is painfully slow), and tools to monitor our services (Apex Log/Ping) within a unified platform.

A couple more things I wish would be available:

1. Metric reporting per lambda or long running services

   • How long a function ran
   • How much memory was used
   • number of serverless invocations
   • bandwidth
   • serverless execution

2. Billing receipts with break down of costs per lambda and running service. now is probably the worst at this. Their billing receipts don't do cost breakdowns and if you want to see which function incurred the highest cost you have to download a csv and find uuids and try to figure out how to map them to a function. It is time consuming and agonizing to do this every month 😔.

Secrets

It would be pretty dope to create a dynamic secrets api. That wouldn't require a redeployment everytime a secret changed. Not sure if possible, but lifting the limit on the size of secrets would be chef kiss amazing

Pricing

now recently moved over to per seat billing and it's been pretty sad for us, we have 6 members and our bill went from ~$50/mo for now + digital ocean to $155/mo. For little teams that are self funded. This kind of sucked a lot. All the time we went into optimizing our services went out the door and we got hit with a larger bill.

If you do go with per seat billing please make it per seat in Up and not github committer. Also if possible, please don't make the per seat billing as high as now, it's $25 per unique committer.

[tj]

@kennetpostigo awesome thanks a lot for the feedback!

Support for stuff like WebSockets will likely just come down to platform support, but I'll see what I can do to offer it in the ones which can utilize it.

When it comes to local development I'll definitely keep that in mind, for the most part you'd just write your app(s) as normal HTTP servers and then choose a platform (GCP, AWS, *). I'm still brainstorming how I want to support FaaS related features for background work / cron jobs etc, those will definitely have to be simulated locally.

I remember you mentioning the cost breakdown issue, I'll keep that in mind! It might be cool to have some daily/weekly/monthly digests of general usage, like hey your API is receiving 200% traffic this week, cost is up to XXX.

Figuring out the billing model is a bit tricky, I want individuals to be able to afford it but also scale for larger companies. It might not be possible anyway, since a huge team could use Up in CI only and I'd just get the $5 or whatever it is haha, definitely won't be as high as $25 per seat though

It would be pretty dope to create a dynamic secrets api. That wouldn't require a redeployment everytime a secret changed. Not sure if possible, but lifting the limit on the size of secrets would be chef kiss amazing

I'll give it some thought, I kind of like how it is at the moment because it's like a transaction, you can change 3 or 4 secrets and then commit them, rather than each one triggering a new deploy and some secrets might be out of sync then (say DB_HOST / DB_PASS for example)

[kc-dot-io]

I would love to have web socket support @tj!

[tj]

@slajax me too haha, it mighttt not be possible just due to platform limitations, but I'll keep an eye on any updates

[einkoro]

For 2.0 I’d love to see up become extensible. Being able to use plugins to add provisioning of different services (aws or otherwise) you don’t plan to support directly would be a huge boon in flexibility.

For example I have some projects where it would have been great to have aurora or dynamo serverless in the stack and provision along with lambda keeping the infrastructure all neat and tidy in the project repo and avoiding terraform entirely. Another big plus would be being able to put together a CloudFlare API plugin and have it setup records and certificates automatically instead of manually adding CloudFlare certs in aws and adding the cloudfront cnames in CloudFlare after up provisions the stack the first time.

Edit: It looks like you are already ahead of me thinking about plugins with #453 ;)

[RickCogley]

Echoing what others said, I like up because I can run it on an AWS account I control, or, on that of a client. For whatever reason, some people are really anti-Google (irrational to pick Amazon over Google, I think, but there you go).

I would like it if Up could automatically integrate with Apex logs in a seamless way.

Edit:
It would also be cool if Up could configure an authorizer for the AWS API Gateway, to make it less complicated to protect a route in your app. The idea being more specifically, if you have a static set of files being served, and you want to put that behind a login (think private documentation), it appears to be possible to do so via this method. But it's complicated with quite a number of steps, so I think automation to the extent that's possible would be really helpful.