As the infrastructure market settles down, more attention is being paid to what happens after you have your cloud up and running. This week we saw the announcement of not one, but two frameworks aimed at developers of Kubernetes-based applications. Microsoft announced Draft, which provides an easy way for developers to build and deploy Kubernetes and other cloud-based applications, and Istio, announced by Google, IBM, and Lyft, provides a service mesh framework for running, monitoring, and controlling the multiple microservices that make up a cloud-native application.
The industry’s focus is starting to move up the stack; things are getting serious.
Draft: Simplifying development and deployment of cloud-native apps
When you think of Kubernetes, the first name to come to mind probably isn’t “Microsoft”, but Redmond’s been trying to catch up lately. One of the ways they’ve been doing that is with the acquisition in April of Deis, the container platform developed by Engine Yard.
Although there was concern — Microsoft hasn’t exactly been a bastion of open source championship — the Deis team, which is also behind the Helm deployment tool, this week announced Draft, an open source tool for developing and deploying cloud-native applications.
Draft simplifies the job of developers who want to write containerized applications by building the appropriate scaffolding for them so they don’t have to worry about anything but the application itself. Brendan Burns, Director of Engineering at Microsoft Azure and Kubernetes co-founder, wrote, “When you first run the draft tool, it automatically discovers the code that you are working on and builds out the scaffolding to support containerizing your application. Using heuristics and a variety of pre-defined project templates draft will create an initial Dockerfile to containerize your application, as well as a Helm Chart to enable your application to be deployed and maintained in a Kubernetes cluster. Teams can even bring their own draft project templates to customize the scaffolding that is built by the tool.”
Techcrunch reports that Draft automatically detects whether code is written in Python, Node.js, Java, Ruby, PHP or Go. “It should be pretty easy to integrate this code with existing continuous integration pipelines,” they add.
The software can also code synchronized with Kubernetes, enabling developers to edit code locally but still have it run on the server.
Istio: A service mesh framework enhancing microservices
Istio (Greek for “sailing”, to keep with the Kubernetes theme) provides a way for developers to monitor, secure, and control microservices-based applications. It works on the Kubernetes Service construct, proxying network transactions with the Lyft-created Envy proxy, so it can even be used with existing applications — no rewriting required.
The idea is that developers create their application as usual, then run its deployment through Istio, which takes care of setting up all of the pieces. Once that’s done, you can see what’s going on with the application by simply looking at the Grafana dashboard.
Istio currently works with Kubernetes, and can be installed locally or on a public or private cloud. The eventual goal, however, is to make it work with non-Kubernetes-related clouds, including those running on Mesos, as well as Google’s Cloud Endpoints.
TechCrunch points out that “It’s worth noting that this isn’t all that different from linkerd, a similar project that is now part of the Cloud Native Computing Foundation, the home of the Kubernetes project.” Linkerd supports Kubernetes, Docker, and Mesosphere’s DC/OS.
Reading between the lines
For the past several years, we’ve been focused on getting infrastructure up and running, but industry has now reached the point where that infrastructure is simply assumed; now the attention is on outcomes.
In the case of Draft and Istio, it’s about making development easier, enabling companies to get to those outcomes faster, but it’s about more than that: it’s about disaggregation.
In a move that echoes a greater emphasis on managed open cloud, both of these tools separate the developer from the worry of dealing with the fine points of architecture that aren’t directly related to what they’re doing. In this way, developers can more easily create applications that are not just more cloud-native, but also more cloud-independant, opening the door for hybrid cloud applications and a further emphasis on what needs to be done, rather than how to do it.