Rod Johnson is a talented guy. Aside from being a master pianist, he is also the author of one of the most popular enterprise software frameworks ever built: the Spring Framework. Originally built as a way for enterprises to better construct large-scale applications, Spring became the de facto replacement for the bloated and slow-moving Java EE.
Fast forward to Johnson selling his company, SpringSource, to VMware for almost half a billion and Johnson effectively walked off into the board-member-and-investor sunset for a few years. Or at the very least, back to his native Australia.
On November 15, Johnson officially returned to the Valley as a CEO. This time, the company is Atomist, and it’s using its $22 million of series A funding to tackle the problems associated with automating the software development lifecycle.
Specifically, Atomist is focused on continuous deployment, juicing modern conveniences like GitHub, Docker files, and Kubernetes to glean the precious information that can be used to push and event-driven deployment process.
Ryan Day, chief operating officer of Atomist, said that “We get event streams from different development tools across the development and delivery pipeline. From that flow, we’re able to derive an understanding of what’s going on in the system. We can notify the right people at the right time to say things like, ‘Hey, this needs a code review.'”
Day comes from GitHub, where he saw these problems being solved, but in painful, time-intensive ways. “I saw a lot of engineering resources and effort there go into building software delivery pipelines that work well and efficiently. The big takeaway for me is that every company should be able to do this, but not every company can hire and justify the resourcing and get the right talent in and have engineers get this stuff out. There’s got to be a product to help teams do that,” said Day.
A big part of that product they’ve created is automation. Atomist is built around an automation client that is open source, and able to take actions based on events, making it less brittle than typical pipeline automation tools.
“The automation platform is generic,” said Johnson. “We respond to events. the context of the events could span different, frameworks different and delivery pipelines.” Those events can be triggered at the language level, at the tool level, or at the macro level, allowing for automation to be run across large numbers of repositories, for example.
“Part that is driven by the fact that, these days, things versioned in git really dictates what happens in production. Ten years ago, operations did their own mysterious things with their own mysterious tools. Today, a lot of that is driven by things like Kubernetes files and Docker files, and therefore understanding and manipulating those is incredibly important for understanding how software is created initially, continuously improved, and kept in the best state in production,” said Johnson.
Johnson said that Atomist is capable of, “Making changes across a very large number of projects,” he said. “With the move towards microservices, people have moved from a very small number of large repositories to a large number of small repositories. While there are benefits to this, there are also costs.” He said that managing all of those repositories is often manual work, and takes developers a great deal of time.
A typical use case for Atomist would be to run an automatic update across hundreds of repositories. Incrementing a single library version across those hundreds of products could be automated, and once each was done, each branch could be built, and the results of those builds could be reported to a developer.
Alternately, successful builds could generate a pull request for the library update to each relevant project. This, said Johnson, keeps developers from running around, updating dozens of projects individually by hand and testing the successes one at a time.
“When an event has occurred, such as a deployment to an environment, we send a message to Slack to notify people. When one stage of the pipeline has been completed, we can send a message to Slack so someone can press a button and have a promotion action take place from that,” said Johnson as another example.
Day said the event-driven nature of Atomist is a major point of differentiation. “That’s the fundamental philosophical difference for us. We are very event-driven, versus defining upfront a workflow, or set of prescriptive steps. As the components change, if you don’t go change your pipeline, things break. If it’s events being raised, you can define the workflow based on behavior, instead of a static definition,” said Day.
“I think in some ways, I find TypeScript as much fun as I found Java in the early days. When Java 1.1 came out, I had that feeling that this was really cool, I could work with this. TypeScript has that feeling. It’s a really good tool for its time,” said Johnson.
That being said, Johnson won’t be turning in his Java card anytime soon. “I am never going to be in the camp of Java haters. I think the JVM is one of the most important technologies out there. I think Java is a really good language. It’s relatively hard to write unreadable code in Java, and a lot of people don’t necessarily value that,” said Johnson.
While Johnson still appreciates Java, he’s always had issues with the way in which it’s evolved. Specifically, he feels that long discussions about specifications are pointless without code that can be put in people’s hands. And this is another reason he’s bullish on TypeScript.
“It’s never been any great secret I have not been an enormous fan of the Java Community Process,” said Johnson. “TypeScript is attempting to play nice. It’s not attempting to diverge at all from ECMAScript, but it’s obviously pushing things by actually shipping code people can use. I am a tremendous believer in the power of working code. You can have all the discussions you want, but there is nothing like putting code in the hands of developers.”