I was talking to Adrian Cockcroft, VP Cloud Architecture Strategy at Amazon Web Services, today about the incredible pace of development and feature velocity that Kubernetes has sustained over the past couple of years when he raised an interesting point about why. What if Kubernetes is moving so fast because it’s written in Go? It’s one of those insights that is sort of obvious, but I don’t remember anyone else point out so clearly before.
There is a difference in speed in the entire Kubernetes community ecosystem. Some of that is because it’s written in Go. It’s a different pace of development, with a greater ability to collaborate and innovate than in Java. With Go you automatically more of a focus on continuous delivery focus than Java. There is the Java world, the Go world, and the serverless world which is mostly Python and Node.js.
Of course the velocity advantage is not necessarily something inherent about Go. Sure golang is designed for concurrency, and the syntax is clean. Golang doesn’t have a lot of things that other languages have – notably the focus on classes as the basis for inheritance, which puts some people off initially, but which clearly has some advantages for a certain – uh – class of application. This post by Steve Francia is fascinating on that score, not least because of the pointer [pun somewhat intended] to a James Gosling mea culpa in Javaworld magazine:
“The Gang of Four Design Patterns book discusses at length replacing implementation inheritance (extends) with interface inheritance (implements).
I once attended a Java user group meeting where James Gosling (Java’s inventor) was the featured speaker. During the memorable Q&A session, someone asked him: “If you could do Java over again, what would you change?” “I’d leave out classes,” he replied. After the laughter died down, he explained that the real problem wasn’t classes per se, but rather implementation inheritance (the extends relationship). Interface inheritance (the implements relationship) is preferable. You should avoid implementation inheritance whenever possible.”
A high performing team with a solid automated testing and collaboration culture, with an understanding of composition-based development can develop in Java and deliver new features quickly. But teams writing Go are generally writing micro-services. They’ve internalised a lot of important lessons about modern software development. They are writing code with an expectation of disposability, moving fast but definitely not breaking things, testing everything as they go along to ensure it will run with the system as a whole. Go, like all languages, is a cultural phenomenon as much as a technical one, and the culture lends itself to continuous delivery and loose coupling. Teams are writing open source code, using GitHub to underpin social coding, with forking as a given. People generally don’t write monoliths in golang. It doesn’t lend itself to dependency hell.
Some fascinating new research from New Relic shows that with AWS Lambda Java functions are still a lot bigger than other languages.
“The total code size of AWS Lambda functions—how much disk space the code and the dependencies of a function consume—tends to be small by modern software standards. Nearly half of the monitored functions could almost fit on a 3½-inch floppy disk.
Java functions were notable outliers. Their average code size was more than 20MB, indicating significantly larger function deployment sizes than Node.js or Python functions.
The bias towards smaller function code size suggests the majority of the New Relic-monitored functions running on AWS Lambda contain relatively few bundled dependencies or extensive business logic, instead pointing to potentially simpler functions. This supports the general best practice around creating small functions designed to perform a single, well-defined task.”
Small teams, loosely joined, writing Go, using containers. Which brings us back to Adrian’s point – that one of the key reasons Kubernetes is moving so fast is because of the language choice, and the people associated with that choice. If Adrian is right, and obviously his argument makes a great deal of sense, there are some rather obvious implications for companies making platform choices. When web companies grow up they tend to turn into Java shops, but that won’t always be the case. With Cloud Native now making such an impact on enterprise thinking we’re going to see a lot more Go adoption, and we’re already seeing plenty of interest.
No Comments