Chatops for the modern developer, courtesy of Spring’s founder

Java Spring Framework creator Rod Johnson sees chatops as the next step for Slack-ensconced developers to make life cycle management much easier

Rod Johnson

Yesterday, I was in San Francisco for a work meeting. By coincidence, one of the people I respect, Rod Johnson, the creator of the Java Spring Framework, was in town. I met him for Indian food and to talk about his new startup Atomist.

Atomist is a set of things for enabling chatops. It consists of an agent, a CLI, Git integration, tools to make event-driven automation possible, a programming model to develop "rugs" to automate tasks, and an API to generate "seeds" to create new projects.

You might say "what about my continuous integration tool?" like Jenkins or Travis CI. There are integrations for those as well. What Atomist ultimately does is tie these things into a life cycle of events and actions. The idea is that all of this will be driven from a chat tool such as Slack.

What is chatops?

If you're in Slack or HipChat anyhow chatting about a build and deploying something, and you have notifications coming from build tools and GitHub and issue trackers, why not go the distance and just drive action from that chat client? This is one of those simple tricks that could be brilliant or could just be another one of those fly-by-night IT fads.

Already, Google Docs let people collaborate on content in real-time and see each other’s changes and even communicate. Similarly chatops tools like Atomist in combination with tools like Slack let developers and devops people collaborate on the software life cycle, including build, release, and deployment.

According to Johnson,

Today if software is eating the world, code is eating software. Once upon a time, we had code and we pushed it over the wall, and somebody used a whole bunch of tools that developers didn't know anything about and didn't respect version control or anything like that to get the stuff released.
Now increasingly we're seeing those kind of things migrating into configuration where code is configuration basically and developers are taking a large role in terms of how things get into production with AWS, Kubernetes, or Docker. It seems to us that there really is an important role to play in being able to comprehend code and work with code in an automated way across potentially many, many projects.

The brave new world of microservices is complex and is a suck on developer productivity. Johnson hopes chatops can help address this problem:

It's good in many ways that the monolith is gone. But we'd actually figured out how to tool the monolith at least if you write it, say, in Java where the tooling is really pretty amazing. But now if you've got 50 services not necessary written in the same language; they may be very inconsistent. You are not going to have them in your single IDE.
Yes, you've gained a lot of the benefits—the ability to deploy parts of your system independently is obviously good—but there is a cost to that and that was something that didn't seem to us was well served.

It became clear to me during our conversation that Johnson is a developer's developer. I asked what motivates him. After all, he made a truckload of money selling his company to VMware. He could have retired and used his music degree to play piano in Paris. But Johnson says, "I was semi-retired and it didn’t really work for me that much. I really love writing code, and I love solving problems. It’s about trying to produce something that is useful and helpful to people to do what they need to do, it’s not predominantly about money."

Is Atomist ready to use?

Atomist is in alpha release and is starting from a Pivotal stack basis due to Johnson's deep ties to the Spring/Java community. If you're using Slack, Spring Boot, and Cloud Foundry then this will probably be natural for you. Johnson wants "to use the Spring support to showcase the life cycle and Atomist benefits to you in terms of less context switching and more efficient automation, and then look at what other languages and frameworks make sense."

Most of the Spring developers I know are well into their 30s. To me, Atomist needs to clearly move to support the "millennial languages" like JavaScript. Johnson says the Atomist team is looking at this. "In the JavaScript space, we're really interested in TypeScript. Personally, I love Typescript; it's a damn good language." In fact, Atomist's "rugs" are based on it. However, despite Johnson’s interest, Atomist hasn’t released TypeScript support yet.

The Atomist team plans to make extension easy and create a marketplace for functionality. It is possible to add support for other languages and technologies to the platform. This means that ultimately it will depend on the community that emerges. It's possible that Atomist becomes the chatops tool for the Spring/CloudFoundry community. It is also possible that it atomizes the entire development world.

At the moment, you can start using Atomist for free. In the long term, Johnson says, "There will be things we will charge for. Maybe we might want to charge for certain features for large companies. It make sense for this to be a premium module. We want to create a market for this to be useful to people; you can’t create a market if you are charging for every service."

What if Slack and such are just a fad?

Maybe chatops will be all it is cracked up to be. Maybe also chatops is just one of those fads like databases that don't support SQL at all (nearly all NoSQL databases now support SQL) or the thousand VC-funded key-value store database companies. However, Atomist has a CLI and the basic concepts of life cycle and events, and recipes for devops aren't new. So Atomist has uses outside of Slack — and could outlive it.

Of course I work for LucidWorks, a company that has to be reminded to use email for the things that we're supposed to use email for. The developers collaborate on Slack. The CEO mostly communicates with us via Slack. The person most interested in chatops is our ops guy, in part to make developers self-service more. It is hard to imagine the Slack thing going away anytime soon even if it ultimately gets replaced by some other thing.

Why you should consider Atomist?

Ultimately, I think Atomist warrants a good look if your company is heavily invested in microservices and already uses Slack. If you're also on Spring and CloudFoundry, this is a clear choice. If you're using a lot more JavaScript and Node.js these days and deploying to Amazon Web Services, it still might be worth the investment.

Automating away some tasks and making the rest more collaborative and simpler — not requiring, say, clicking your way to Jenkins and then Jira and then GitHub and then AWS when you want to spin up some test instances of your latest release — might be worth helping add a few plugins.

If you're in some hellish basement communicating using Outlook, Microsoft Skype for Business, ClearCase, and Make, and deploying to VMware or some mainframe, well then a chatops tool like Atomist (like most new things) is not for you.