The cloud is an organic system that evolves, and possibilities are endless — you can essentially build what you want. At the same time, it’s a hostile and intimidating place.
When I talk to new developers or folks migrating to the cloud, they say they struggle with the amount of complexity involved in deploying to AWS, Google Cloud Platform or Azure, setting up IAM roles, configuring networks, and having to understand how to use dozens of different services.
To deal with all of this, many teams just “shove” cloud applications into containers. This creates a small, isolated world for developers — but the truth is that it is very limiting because developers can no longer leverage the full potential of the cloud if their entire universe is a single container.
Another option is to use a platform like Vercel or Render or Heroku — which offers a great experience delivering code to the cloud. The problem is that you inevitably reach the boundary of this beautiful cliff, and you have to jump back to the jungle.
These vertically integrated platforms are able to optimize their experience around a particular type of application (such as frontend apps or containerized workloads), and eventually systems grow out of these vertical solutions. And as anyone who’s ever tried to migrate off of one of these platforms knows … it’s a nightmare.
We Can’t Keep Using the Cloud the Same Way
It’s just too difficult. We need to build better solutions for developers. The way I see it: We need to turn this jungle into a park. What that means is we need to remove a lot of the hostilities, while retaining the richness and utility.
In order to accomplish this, we have to provide developers with better abstractions. I’ll be the first to admit that abstractions have their own issues. One of my favorite quotes from Joel Spolsky states that “all nontrivial abstractions to some degree are leaky” — and that certainly rings true. But that doesn’t mean the abstraction isn’t useful and valuable.
When you click a button with your mouse, you are using layers and layers of abstractions — but these are very solid abstractions. Sometimes these abstractions break if you run out of CPU or if there’s a bug, but the majority of the time these abstractions are very powerful and make your life much easier than what it would be like to accomplish the same task without them.
Another important thing about abstractions is that they democratize technology. The most recent example everyone is talking about is ChatGPT. We can all see that it’s leaky and it hallucinates. But it’s still incredibly powerful. Originally, this kind of technology was only accessible by machine-learning experts. Today my mother can leverage this abstraction and its potential.
Choosing between Kubernetes and Serverless Isn’t the Future
Neither paradigm gives developers what they want. Kubernetes developers are “containerized” and are therefore very limited in how much of “the cloud” they can leverage. On the other hand, serverless developers have too many options and end up with too many responsibilities; they essentially need to also be DevOps experts in order to be able to deliver.
I think we need to respect that there are two separate engineering problem domains when we are delivering applications to the cloud. We have the problem domain of the platform, where platform engineers are operating, and then we have the problem domain of the business, where developers are focused. To address this, I believe we need a new programming model, which decouples these problem domains and offers a way for each discipline to apply its concerns.
This is where Winglang comes in.
A Unified Programming Language to Tame Cloud Complexity
Winglang is an open source programming language and a standard library that connects the platform and the application in a better model. It will feel familiar to developers because it’s a standard, object-oriented language, and there’s an awesome community starting to build around the project.
Winglang takes a batteries-included approach, which means that the toolchain is shipped with everything a developer would need, such as a testing framework, an IDE extension, a compiler and a cloud simulator. It’s a one-stop shop. Wing interoperates naturally with any NPM module and with JavaScript and TypeScript code; we decided to have Winglang compile to JavaScript because it’s the biggest ecosystem on the planet and is very popular in cloud development.
Abstraction layers and high-level programming languages have been instrumental in democratizing software development since the dawn of computing.
The language was designed from the ground up for developers who are building distributed systems that leverage cloud infrastructure as first-class citizens. The Winglang compiler produces a ready-to-deploy package that includes both Infrastructure as Code definitions for Terraform, CloudFormation, or other cloud-provisioning engines, as well as Node.js bundled code designed to run on compute platforms such as AWS Lambda, Kubernetes or edge platforms.
Why Is Wing a Language and Not Another Library or Framework?
Cloud applications are fundamentally different from applications that run on a single machine. They are distributed systems that rely on cloud infrastructure to achieve their goals. To express both infrastructure and application logic in a type-safe and unified programming model, Winglang has two execution phases: “preflight” for infrastructure definitions and “inflight” for runtime code.
Preflight code is executed during compilation and produces the infrastructure configuration for your app (e.g., Terraform, CloudFormation). You can think of Wing preflight code as a desired state configuration language (similar to HashiCorp Configuration Language that’s used in Terraform, the AWS CDK or Pulumi). Inflight code is compiled to JavaScript and bundled so it can be executed within cloud compute platforms such as serverless functions, containers or even VMs within a Node.js runtime.
Let’s look at a simple example:
Here, cloud.Queue, cloud.Counter, and cloud.Bucket are preflight objects. They represent cloud infrastructure resources. When compiled to a specific cloud provider, such as AWS, a Terraform file will be produced with the provider’s implementation of these resources (in this case an SQS queue, an S3 bucket and a DynamoDB table with an atomic counter). The queue.setConsumer() method is a preflight method that configures the infrastructure to invoke a particular inflight function for each message in the queue.
Now comes the cool part: The code that runs inside the inflight function interacts with the counter and the bucket objects through their inflight methods (counter.inc() and bucket.put()). These methods can only be called from inflight scopes.
This interaction between inflight and preflight is called lifting. The compiler lifts the objects from the preflight space so that the inflight code can interact with it after the system is deployed. One of the things users are most excited about with lifting is that the Wing compiler can also tell what operations are performed on the object, and this information is used by the platform provider to automatically wire up things like least-privilege IAM policies.
Sometimes when we show Wing to customers, they tell us they think they just saw the future. I think they saw the past. They saw how we could take an approach that enabled us to simplify and abstract programming in “traditional computers” and simply apply it to this new kind of computer we call “the cloud.”