If
“Dev Ops had a baby” wrote
Elad Ben-Israel, CEO of
Wing Cloud, it would be a combination of infrastructure and runtime code in one language.
Wing was a “programming language for the cloud.” I used the past tense here, because Wing shutdown a week ago. As it was an open source project, the ideas will hopefully live on, just not as a business concern.
I talked a bit about
developer experience last week and how it is viewed through the corporate Panopticon. Making developers happy may not always be something you can afford to pay for, so tooling sometimes has an uphill struggle to be taken on board.
The same group of people who develop an idea may also successfully work out the right business case, but a close look at startups over the decades will reveal that the forerunner to success is often many rounds of failure. In this post, I’ll look at Wing as a language and product, reflecting on what the shutdown might mean.
Between Kubernetes and Serverless
So where was Wing positioned? I normally look at languages as they appear, not as they retreat, but we should be able to learn something as we use it. Working in the cloud is either a case of container manipulation with
Kubernetes, or the very exposed world of serverless functions. I can understand that neither of these two extremes may feel like the best place to work, or express business concerns.
To express both infrastructure and application logic in a type-safe model, Wing has two execution phases: “preflight” for infrastructure definitions and “inflight” for runtime code. We’ll see these in action shortly.
I think modeling the platform is an interesting direction, and can be contrasted with
System Initiative, which also encompasses the architecture of the cloud, but visually. In fact, the comparison with System Initiative is unavoidable when looking at the Wing Console
.
Taking Off
I’m going to try starting a project in what I hope will be more than just archaeology. (There was a playground option, but that does appear to be down at the moment), I installed the npm and confirmed the version:
👁 Image
Then I started a new empty project:
👁 Image
This gives us a nice bit of how-to with further links. We have only three files to consider in the project:
👁 Image
And we start by placing the example code into the
main.w file:
bring cloud;
// define a queue, a bucket and a counter
let bucket = new cloud.Bucket();
let counter = new cloud.Counter(initial: 1);
let queue = new cloud.Queue();
// When a message is received in the queue it should be consumed
// by the following closure
queue.setConsumer(inflight (message: str) => {
// Increment the distributed counter, the index variable will
// store the value prior to the increment
let index = counter.inc();
// Once two messages are pushed to the queue, e.g. "Wing" and "Queue".
// Two files will be created:
// - wing-1.txt with "Hello Wing"
// - wing-2.txt with "Hello Queue"
bucket.put("wing-{index}.txt", "Hello, {message}");
log("file wing-{index}.txt created");
});
So we are introduced more directly with the “preflight” code, which creates a bucket, a queue and a counter in whichever cloud fabric we are in; then “inflight” code is used to increment the counter and fill the bucket.
At this point, some developers will hear alarm bells ringing. When writing code that will be run at different times, we know we will have the issue of objects that are not alive simultaneously attempting to interact with each other in code. Then again, there have been various parallel paradigms in software for some considerable time now.
Now, Wing doesn’t ignore this; it refers to “lifted” when an inflight object attempts to communicate with preflight. In this example, the compiler is clearly happy about the continuing use of the string
preflight_str:
let preflight_str = "hello from preflight";
inflight () => {
log(preflight_str); // `preflight_str` is "lifted" into inflight.
};
In fact in
main.w,
bucket has been lifted via that
put method.
Well, I’m already ready to run that Wing Console. It starts up at port 3001:
👁 Image
Before starting, we do need to log in with Google or, inevitably, GitHub. Then the console is loaded:
👁 Image
This is actually a bit nicer than the diagram of the console in the docs. This is nice live and hot-loading page.
We can operate the functions using the diagram. First, we can push a message. By hitting the queue, we get some UI to enter text and push:
👁 Image
We can now click the bucket, and check the message file was created, with the greetings content, which it was:
👁 Image
And yes, the counter is incremented too:
👁 Image
The idea is that you can then deploy this to the cloud. Just like with System Initiative, this means
AWS at the moment. A message tells us that Azure and
Google were to follow:
👁 Image
But I guess this will fall by the wayside unless the community picks up the work. I looked on the Discord, but the news of the business having closed down is still fresh, and no evidence of any recovery was visible.
Conclusion
“Choosing between Kubernetes and serverless isn’t the future,” as Ben-Israel wrote in The New Stack a year ago, but it clearly will be for a bit longer. The current cloud native concepts remain hard to grasp and tame, even though Wing had a good try.
The Final words go to
Adam Jacob, the CEO of System Initiative: “Wing had many promising aspects and was a truly original take. They should be proud of what they built. I’m proud of them for being in the game, for being original, and being really lovely people at every step.
Wing was filled with good ideas. Cool technology. Sometimes this is just how it goes.”
