We’ve been living in the era of cloud computing for over a decade now. And still, most enterprises are overwhelmed with the complexity, and many have yet to migrate over some of their most business critical applications.
That’s not to say the desire isn’t there. A recent study conducted by Zippa found that 67% of enterprise infrastructure is now cloud-based and the large majority are considering multi-cloud strategies. But the fact is it’s a slow and often grueling process. Netflix notoriously took ten years to migrate over to AWS – and that’s with significant engineering resources and talent that most enterprises simply do not have.
There needs to be a better way
We need to create a golden path to production that includes much less friction for companies looking to build in the cloud. I believe that the best way to accomplish this is by establishing a better decoupling between the platform layer and the application layer.
“DevOps” has been en vogue for years, and in principle, it’s a necessary concept – we need tighter iteration cycles and more infrastructure-aware coding practices. But what we don’t need is to expect our developers to become operations or security experts. Developers should be focused on the problem domain of the business while platform teams should be focused on the problem domain of delivering and running systems. We need to build a better line that separates these two domains in order to allow each to be more successful
With better decoupling, developers can do what they do best – write code and build applications. And then a separate platform team can handle things like security controls and compliance, essentially putting in the necessary guardrails that actually unlock developer creativity and velocity more than hinder it.
Templates are evil
When I was a principal engineer at Amazon, one of the ways we imposed platform standards and best practices was through project templates. For example, a platform team publishes a beautifully crafted project template that codifies the various best practices and standards for an API-based service or a frontend service, and then developers copy from the template and are able to get started quickly.
The problem with this approach is that it optimizes for getting started instead of optimizing for the ongoing development of the system. Templates are just a fancy way to copy and paste. I’ve seen project templates that consist of thousands of lines of code that the developer didn’t write and eventually has to own in the long term. And God help us when there’s a security issue or bug in the original template… Well now go chase the hundreds of projects that copied and pasted this bug across the entire company. I was involved in some of these painful cross company ticketing campaigns at Amazon, and let me tell you, this is the last thing anybody wants to deal with…. It’s easy to see how these templates become cumbersome and difficult to maintain at scale and a massive liability for a platform organization
Libraries to the rescue
Another approach is the codification of the platform through the library. Reusing software through libraries has been a fundamental tool in software development since the dawn of computing. It’s a technique developers are already familiar with – and with Wing we are enabling that in the cloud.
If this is your first time hearing about Wing, it is a programming framework for the cloud. One of the cool things about Wing is that it enables organizations to codify their cloud platform concerns through a well defined set of APIs and libraries. This way, developers can work on top of these abstractions versus“inside of them.
The Future with Wing
We’re building a world where the gritty details of cloud infrastructure are abstracted away from the developer through a Cloud Abstraction Layer (CAL). This approach is similar to the one we’ve established for “traditional” computing (e.g. PCs, servers), but applied to the cloud. The CAL enables developers to express their intent at a high level and enables platform teams to codify their policies, compliance rules, and best practices. This allows both disciplines to operate more independently, focus on their problem domain, and dramatically reduce the friction across the layers.
A common example is migrating between serverless (e.g. AWS Lambda) and containers (e.g. Kubernetes). For example, let’s say you decide to build an application. Initially, it makes sense to deploy it on AWS Lambda, because you expect the application to initially have relatively low usage and only want to be charged when the function is triggered. At some point, as demand grows and you are seeing more traction, it might make sense to deploy this app to a container environment., so you are not charged a premium each time the function is called.
With Wing, the decision on which computing platform the application is deployed can be done without touching the code of your application. With today’s such a decision requires moving the app to a completely different programming stack, and likely requires a massive rewrite.
Simulation superpowers
Another huge benefit of the CAL is that we are now able to provide a local-host implementation of these APIs so that developers can build and test their applications using a cloud simulator. From a functional perspective, cloud primitives are simple: a bucket is a key/object store, a queue is a mere ordered list of items. The Wing Cloud Simulator is a lightweight implementation of the CAL that can execute complete end to end cloud flows on the developer’s local machine, without having to wait for deployments or pay for cloud resources and environments.
Full control and customization at the platform level
In our open-source programming environment for the cloud Wing, cloud infrastructure components are treated as first-class citizens and there’s a well established API that can be completely customized based on the organization’s cloud environment and best practices. Our 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 code designed to run on compute platforms such as AWS Lambda, Kubernetes, or edge platforms.
The future with Wing will be a powerful and customized layer where platform teams can maintain centralized control over compliance, security, networking, deployment, and operations and developers can build, test, and deploy their applications independently with minimal friction, improved quality, and maximum velocity.