Nicolae Rusan

The through-line

Rusan's argument starts from a complaint about the daily experience of writing software rather than from a technology trend. His message to new developers at the Flatiron school was that "programming is this beautiful thing conceptually" but "the day-to-day experience of programming is often just completely miserable," and that what programming really demands is grit: "you're not really a programmer until you've like wasted a week of your life or days of your life looking for like a missing missing semicolon" [1]. Environment setup that breaks, APIs with no documentation, bugs with no googleable answer, getting random things to work together, all of it drains the potential pleasure out of building and, more importantly to him, "keep[s] a lot of people out of the practice of creating software" [1].

From that complaint follows the strategy. One response to bad tooling is stoicism, to "be like really cool headed" and grind through it. The response he prefers is "to revisit some of like our assumptions around what the tools that we have available to us to program are" [1]. Serverless is interesting to him mainly because it opens that door: it is a new abstraction level that removes a whole category of busywork, and it makes previously fixed assumptions about how code is shared, hosted and tried out newly negotiable. The long-term vision he states for Clay is "to make programming a lot more enjoyable," with the near-term product being "the fastest way to build share and remix microservices to make awesome software" [1].

On what serverless actually changes

He frames serverless as an increase in abstraction rather than a new category of infrastructure: "I don't need to think about the machine I don't need to SSH into a server somewhere I can actually just write a function of code and have it run" [1], with scaling handled invisibly underneath. He traces the lineage from AWS Lambda in 2014, where you shipped a single Node function and Amazon ran it on demand, through Google Cloud Functions and Microsoft Azure Functions, judging the platforms broadly comparable with Amazon holding a functionality lead from its head start, and reading Amazon's reinvent programming as evidence of where mind share is going [1].

Beyond the "just write a function" promise, he singles out three properties. The first is that the model is event-driven, with a central event hub you hook into: a new record in a database or a file uploaded to s3 triggers a Lambda, so programming becomes "rule based event driven" work in which pipelines of functions act on events and the data passed with them [1]. The second is the billing model, where you pay nothing until the function is invoked and then only for the milliseconds it runs, which he likes not just as a cost saving for idle workloads but as a behavioural incentive: it makes you "very aware of how long each of these little functions you write take" and shows you precisely which functions in a pipeline are costing money [1]. The third is seamless scaling for workloads that sit idle and then spike, where more instances spin up without you spinning up or tearing down servers [1].

On modularity and the tooling debt it creates

Serverless, in his reading, is "an enabling technology" for a practice large companies were already following: break the problem into small pieces, agree on interfaces, and let each team assume the others' services behave as agreed [1]. The benefits are that problems become easier to reason about and that a useful piece may end up reused everywhere. But he is explicit that this creates its own difficulties. Once a function is the main building block and an organisation like Uber has thousands of internal services, the questions become how you keep track of the relationships between them and, "when there's a bug where in this like slow of function blocks are the issues" [1]. His conclusion is that "there's a whole new tool set that we're going to need for this world of micro services," and that building those tools is what he sees Clay doing [1].

On why GitHub and npm are the wrong model for this world

His sharpest criticism is of how code is shared today. GitHub, he says, is "pretty much just drop box for your code," a hosted folder with some merge functionality, and what you get on a repo page is "a bunch of static files a bunch of dead files" plus a readme you have to scan to work out how to install it and what it returns [1]. He grounds this in his own experience building Clay: wanting a whois microservice, he went through three separate whois packages on GitHub, downloading and installing each before discovering it did not do what he expected or returned data in an unexpected format [1]. The failure is a lack of feedback. You cannot try a package before installing it, you may not be able to get it running locally at all, the package you want may not exist in your language, and packages "can't really be backed by a database in any meaningful way" [1].

That last point produces what he calls a dichotomy: a world of packages on GitHub and a separate world of data-backed APIs like Clearbit, coexisting but disconnected [1]. Serverless dissolves the split, because there is no reason a hosted function cannot sit ready and spin up a Lambda when someone needs it. In the Clay paradigm "every function actually becomes a living microservice," and "every repo now becomes an API" [1].

On what a living microservice buys you

The concrete gains he demonstrates all follow from turning a repo into a callable endpoint. Metadata declares what inputs a service expects, so the equivalent of a repo page becomes a place where you run the function against a real domain, see the returned JSON, check whether it handles your case, and read the logs [1]. The same service is available as a URL endpoint you can curl, so it can be consumed publicly "essentially the same way you would use an API" [1]. And because it is an API, the implementation language stops mattering to the consumer: write it in Node, Python or Go, and it becomes usable from any other language through a client library or plain post calls [1].

The workflow he shows is deliberately short: install the CLI, run `clay new` with a name, and within seconds there is a scaffolded microservice living at an endpoint with local code and an auto-generated repo page [1]. Inputs are declared in a simple JSON configuration file, with a name, a type such as text and a description, and are available in the handler through an event vars variable; a code change goes live with `clay deploy` [1]. Consumption is equally compressed, with a client library reducing an invocation to `clay.run` plus the function name and its argument [1]. Repos start private and can be made public, mirroring GitHub, and his bet is that as teams split their own applications into small services, more of those pieces become public building blocks [1]. He illustrates the endpoint with wrappers around existing APIs, including a Twitter user search that takes a name and returns matching users, and a Google Maps wrapper with more interesting input types [1].

On the real goal of developer tooling

Underneath the product demo sits a plain statement of purpose: "the big thing that really we all want to do as software developers is get useful stuff up and running," and instead we spend our time on configuration and on researching whether a good library exists for this or that, cobbling pieces together and then trying to make the result run and scale [1]. Everything he wants Clay to remove is a tax on that. His picture of the end state is code that is "really simple" because it consists of invoking little functional building blocks and combining them into more compelling software, with the platform making deployment, scaling and discovery cheap enough that the interesting work is the composition [1].

Takeaways

• Rusan's motivation for better tooling is emotional and social as much as technical: bad developer experience drains the beauty out of programming and "keep[s] a lot of people out of the practice of creating software" [1].
• He treats serverless as an abstraction shift, not just infrastructure, defined by three properties: an event-driven model, pay-only-when-invoked billing, and invisible scaling [1].
• Per-millisecond billing is valuable to him partly as an incentive, because it shows exactly which functions in a pipeline cost money and pushes developers toward more performant code [1].
• He sees serverless as an enabler of microservices that also creates a tooling debt: with thousands of services, tracking relationships and locating bugs demands "a whole new tool set" [1].
• His critique of GitHub is that it is "pretty much just drop box for your code," offering "dead files" and a readme where a developer needs feedback, trial and real returned data [1].
• Clay's core move is turning every repo into an API so that a service can be tried in the browser, curled at an endpoint, and called from any language regardless of what it was written in [1].
• The intended workflow is `clay new` to scaffold a service at a live endpoint, a JSON config to declare typed inputs, and `clay deploy` to ship, with `clay.run` for consumption [1].