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.
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.
Thanks! While I've got you here... do you have any insight into the Spaces roadmap? I've been waiting for per-Space permissions for access keys to land to enable me to migrate a bunch of S3 buckets. Thanks again.
Thank you – I'm desperate to even just isolate access to a single space, to replicate what I currently have on S3, so I can multi-tenant my clients' media storage on the Spaces platform.
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.
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....
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.
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...