rabbah

Hello... I work on the Flows product at Postman. Love this question.

I believe wholly that the definition of a developer is rapidly changing (arguably has already changed). It's clear that it won't mean people who are "classically" trained in software development. I particularly like the view point that we're evolving from developers to conductors (SpecStory did a nice write up on this [1]) where we are more focused on orchestrating Agents.

I also think that APIs will either need to be ready for AI (trusted, solve for authentication, have clear specification, lots of examples) or will be AI dependent to fix them up and put a new layer on top. Discovering the right API to solve the problem is central to the dynamic logic agents introduce to workflows.

I've been building agents for both personal use and for automating internal processes within my team/across the company, and the DX has not felt all the foreign from typical development... an idea, a quick prototype, a tight inner loop for rapid feedback, then a graduation to a deployed asset. While not foreign, doesn't mean there isn't plenty of room for innovation. The DX is where we're really focused today, particularly with Flows.

[1] https://newsletter.specstory.com/p/getting-started-with-soft...

or use Postman Flows https://learning.postman.com/docs/postman-flows/gs/flows-ove...

data is encrypted in motion and at rest https://www.postman.com/trust/security/

Serverless computing is the future of cloud computing with more and more infrastructure management shifted to the provider rather than internal infra and ops teams. It isn't to say it's all or nothing, and it is a long enduring transition which is why the DigitalOcean integration between Functions and App Platform is differentiated related to some of the other vendors you mention. You don't have to choose between serverfull (containers, servers, kubernetes even) and serverless -- functions, and entirely managed services like CDNs, load balancers, containers that scale from 0 to N, SSL cert management, automatic build and deploys, rollbacks, API gateways, object storage ... and managed serverless key-value stores and databases.

So functions is really table stakes for a cloud, as are events, scheduled and background functions. You've seen this play out with every cloud provider since the arrival of AWS Lambda. Our goal is to make it scale, make it cheap, and make it secure with DigitalOcean developer simplicity and so you are right, a corner stone of this endeavor is the developer experience and integration with cloud services because a cloud application consumes all of these services. As these become core competencies for a cloud, the integrations between all the services only get better and deliver more value to the customer.

I shared a few details above - with the implementation backed by a mature open source project, there are lots of details available already. Thanks for bringing this up though so we can focus on the parts of interest to the community as we roll out more technical documents on the product.

Finer grained IAM like permissions but without the AWS complexity is of great interest. I will see what else I can share.

OpenWhisk functions are vendor agnostic and have a generic signature of JSON in and JSON out and no other dependencies. Functions on DigitalOcean may also run functions from Netlify and AWS Lambda (and vice versa). You can run the same functions on IBM Cloud Functions and Adobe I/O runtime. This article from 2020 runs the same code on multiple clouds included self hosted for the curious https://openwhisk.blog/post/advocate/openwhisk-portable-serv....

yep - it's coming.

The foundation is Apache OpenWhisk https://github.com/apache/openwhisk with DO specific customization to work with App Platform, managed databases, trusted sources, log shipping, and other DO specific capabilities. The closest programming model is AWS Lambda in terms of the semantics and execution model.

Sorry to hear that, I welcome a chance to understand this feedback further.

Yep and yep, also more runtimes.

The code for the functions is vendor agnostic. Vendor lock-in comes from the integrations the code that runs in the cloud ends up consuming, and the developer experience one acquires. The nature of cloud development is that one invariably becomes an expert in a cloud or stack, and that's the real lock in / why it's expensive to move in practice.

Functions through app platform are fully managed and deployed with zero downtime and offer roll backs as well. Deployments from the CLI are fast enough you can enable watch-mode and continuously deploy as you code in your IDE.

Cold starts depend on runtime and size of the function and an area of continuous improvement (for all cloud providers).

I watched the youtube videos of all the battles so far and I was really surprised to see that a very simple strategy (in retrospect) was sufficient to win the competitions.

I've been waiting to see if someone implements an AI bot that's trained on all the bots in the competition but maybe you just don't need to.

Kudos.

I'd agree, old ideas, new contexts. The twists matter.

Contribute on GitHub https://github.com/apache/incubator-openwhisk

You can except more commitment to Kube from OpenWhisk.

An emerging market for functions is also in IoT and edge use cases. See https://aws.amazon.com/greengrass/ if interested.

Indeed, the original founders of Iron.io are at Oracle. They are up to some good stuff. See https://medium.com/fnproject/8-reasons-why-we-built-the-fn-p...

It's great to see so many functions platform - in some ways it shows there's increasing interest, awareness, and adoption. The field is still quite young and there will be a lot of experimentation and exploration.

There's also a difference between deploying rapidly for local development (less is better) and actually running a functions platform at scale. AWS lambda reportedly handles over 2B lambdas a day (this was a year ago).

Not every platform needs that kind of scale, but it does put things in perspectives.

Also Adobe I/O runtime https://www.adobe.io/apis/cloudplatform/runtime.html.

OpenWhisk started entirely from IBM Research. It was open sourced in Feb 2016. Adobe came on board as part of the induction to Apache Incubator.

It remains to be seen if the abstraction that Kubernetes adds to manager containers will have performance characteristics that serverless demands - considering the need for container reuse, reclamation, pause/unpause, and elastic scaling.

Should you need help with OpenWhisk please reach out to us on http://slack.openwhisk.org/ or GitHub.

OpenWhisk actions (equivalent to functions in other frameworks) have two life cycle events: initialization and execution. The very first activation of an action (a cold start), will initiate both events. Future activations of the action, if they're contemporaneous, will only generate execution events. This is the warm execution, which can take advantage of previous activations. To provide scaling, it is necessary to sometimes create new execution environments for the repeated actions, and so that means new initialization events.

While one cannot rely that all executions after a cold start are warm, it's possible to for the action code to check if it's warm and forgo internal initialization as needed. This is a convenient trick that's common to avoid expensive setup.

For Java actions running in OpenWhisk, this can be done with static fields.

A nice flow of the lifecycle can be seen on slide 24 here http://www.slideshare.net/psuter/openwhisk-deep-dive-the-act....

we didn't look specifically at libreoffice, but we considered a number of other free or online spreadsheet offerings. excel is attractive because there's a widely installed user base. we are however considering integrations with other spreadsheet offerings. we hope to have a free activesheets service available for trial.