Microsoft Draft Offers Kubernetes Support for Developers

Containers make it easier to deploy applications with all their libraries and dependencies, though in many cases organizations do have to change their workflow to accommodate the new technology. That can cause adoption of container technology to stall inside organizations when the change is driven by operations, noted Gabe Monroy, the Microsoft’s lead program manager for containers on Azure.

This is a problem Monroy believes a new open-source Kubernetes deployment tool called Draft can fix. Monroy is the former chief technology officer for Deis, a company that Microsoft is in the process of acquiring. The company unveiled this technology at the CoreOS user conference, being held this week in San Francisco.

“Draft is solving what I think is the number one problem facing organizations that are trying to adopt containers at scale. When the operations and IT teams in a company have bought into the idea of containers and they stand up Kubernetes clusters and have some initial wins, they turn around ready to unleash this to a team of a thousand Java developers — and the reaction they get is like deer in the headlights. It’s too complicated, it’s too much conceptual overhead; this is just too hard for us.

In other words, operations teams need to make Kubernetes easier and more palatable for software teams.

Draft reduces that conceptual overhead by taking away most of the requirements for using Kubernetes; developers don’t even need to have Docker or Kubernetes on their laptop — just the Draft binary.

“You start writing your app in any language, like Node.js, you start scaffolding it and when you’re ready to see if it can run in the Kubernetes environment, in the sandbox, you just type ‘draft create’ and the tool detects what the language is and it writes out the Dockerfile and the Helm chart into the source tree. So it scaffolds out and containerizes the app for you.”

Helm is the Kubernetes package manager developed and supported by Deis.

That language detection is based on configurable Draft “packs,” which contain a detection script, a Dockerfile and a Helm Chart. By default, Draft comes with packs for Python, Node.js, Java, Ruby, PHP and Go. Microsoft is likely to come out with more packs — TypeScript is under consideration — but Monroy expects the community to build more packs to support different languages, frameworks and runtimes.

“One of the benefits of microservices is allowing teams to pick the right language and framework for the job. Packs are extremely simple, so teams can and will customize them for their environment. Large customers want the ability to say ‘here is our Java 7 environment and our node environment that are blessed by the operations team and we don’t want developers to do anything else.’ Draft packs allow that kind of customization and control.”

The container can be a Windows or Linux Docker container; “we’re targeting all the platforms,” Monroy confirmed, and in time that will include Linux Docker containers running on Windows 10 and Windows Server 2016 directly through Hyper-V (rather than in a virtual machine).

The second new command for developers is “draft up.” This command ships the source code — including the new bits that containerize the app — to Kubernetes, remotely builds the Docker images, and deploys it into a developer sandbox using the Helm chart,” Monroy said.  The developer gets a URL to visit their app and see it live.”

The Docker registry details needed for that will have been set up by the operations team as part of providing Draft to developers.

“Now you go into to your IDE, whatever IDE that is, make a change and save your code. The minute that save happens, Draft detects it and redeploys up to the Kubernetes cluster and it’s available in seconds,’ Monroy said. Those commands could easily be integrated into an IDE directly, but either way, it’s a much smaller change to a developer workflow than targeting Docker or Kubernetes directly.

Build and Test

For a developer, Monroy says this will feel rather like using platform services. “With PaaS, a developer just writes code and that code goes to the cloud. This is almost like a client-side PaaS that writes your deployment and configuration info to the repo. But because Kubernetes can model anything, you could use this to stand up Cassandra or WordPress or something that PaaS systems have a lot of trouble with. Things with stateful components can be written with Draft; it can model volumes as easily as cloud applications.”

Draft is aimed at the “innerloop” of developer workflow, said Monroy; “While developers are writing code but before they commit changes to version control. Once they’re happy with their changes, they can commit those to source control.”

Writing build and deployment configuration to the source tree makes Draft a better fit for the kind of continuous integration and development pipelines that drive DevOps than PaaS, especially when it comes to build testing.

Typically, PaaS systems have not integrated well with continuous integration and deployment pipelines where developers check code into source control and then the continuous integration system pulls it out and builds it, and tests it and stages it and then it gets rolled to production.

“Draft solves this because it drops the configuration into the source control repo and the continuous integration pipeline can pick it up from there,” Monroy said.

There are few other tools aimed at helping fit Docker into the developer workflow the way Draft does. “We see a lot of people use Docker Compose but the problem is that requires Docker on a laptop, which not every organization is willing to roll out across their entire fleet,” he noted. Docker Compose and tools like Bitnami Kompose use the Docker data model; Draft uses the Kubernetes data model, which Monroy called “much richer and much higher fidelity”.

Draft ships the entire source tree to the Kubernetes cluster and builds the containers there, which is how it gets around the need to have Docker on the developer’s system. “If you have a massive repo there could be some latency there,” warned Monroy. If that’s an issue, Draft can work equally well with a Kubernetes cluster on a laptop though, and for some organizations, it will replace even slower processes.

One large company wanting to move its 10,000-plus Java developers to Kubernetes has been using Cloud Foundry and cf push; they’re very keen to use Draft instead.

Developer Productivity

Draft takes one step towards solving an issue Azure Container Service architect Brendan Burns calls “empty orchestrator syndrome; ‘we’re totally deploying Kubernetes, we’ve deployed Kubernetes — now what?’”

“The real problem I think, is that it’s still too hard to build applications. We have a lot of the pieces but we haven’t started to actually show a way things could come together,” Burns said. Draft fits in neatly with developments like service brokers and managing secrets for applications in containers and improving developer productivity with features like remote debugging in the cloud.

Draft is only intended to be one building block in a composable system, though. “We wanted to build a tool that did one thing, one workflow, and did it well,” Monroy told us. “It does help facilitate the pipeline view of the universe, and we have other things in mind for the other parts of the workflow where a CI system picks up code.”

The Cloud Native Computing Foundation is a sponsor of The New Stack.

Feature image: CoreOS’ Alex Polvi and Microsoft’s Gabe Monroy (partially hidden) demonstrate Draft at CoreOS Fest. Photo by Alex Williams.