I recently sat down with the cofounders of Atomist Rod Johnson and Ryan Day to discuss the state of software development today and how their platform meets the needs of companies undertaking digital transformation and replatforming projects. Organisations are being told to break down monoliths into hundreds, if not thousands, of services but they generally don’t have the infrastructure or processes in places to actually manage them. Not only are we breaking monoliths down, but we’re also creating multiple versions of each of these services with distributed version control systems and trunk-based development.
How can an enterprise apply policy consistently across this sprawl of microservices? Would you rather fight 100 duck sized horses or one horse sized duck? We’re now expected to tackle the former, but don’t have the right tools in place to do so.
But what if you ask a question of your code base and processes? What’s in that version, where is it deployed, who should be notified if it breaks? Atomist is about Observable software development. Not just observable, but also programmable. Not just observable, but also programmable, and social.
The social aspect is really key to Atomist, which began life as a code-aware enterprise chatops platform. Today chatops is only a small part of the the overall story, but it’s interesting, because it means that conversations about code become part of what can be configured, managed and augmented. These events are correlated with those generated in GitHub.
The creator of the Spring framework, Johnson is as well placed as anyone to address the issue of software delivery sprawl and convention over configuration in continuous delivery. He’s on a mission to get folks to stop using YAML and Bash scripts, and to get rid of UIs for creating pipelines – in Johnson’s view pipelines should only by created and managed in code.
He calls the Atomist Software Delivery Machine (SDM) the “Spring Boot for software delivery”.
“We’re rethinking the business of continuous delivery. Our belief is that CD shouldn’t be based on a massive pipeline, but you should tackle it with an event hub.
Every software development action – pushes, commits, questions to a colleague in Slack – generates an event. If these events are managed consistently you can apply policies at any stage of the software development process. These policies might be for example – adding a software license to all code written by a particular team, or testing using Black Duck before any code is deployed to production.
The SDM model is embodied in a GraphQL API. It’s not a model like the old world ALM of unified modelling language (UML). Rather it’s a hosted software as a service API you can code against. Atomist also gets cool points for adopting Typescript as its core language for automation and building extensions.
While Atomist is hosted, it also supports automation clients for on premises, behind the firewall development. Like Spring Boot, with Atomist when the developer creates a project – it’s driven by seed projects that get transformed. There is no template code. A seed project, when cloned create a channel, and the events in that channel can be subscribed to with listeners for things like pull requests, new builds or issues. Events are sent over WebSockets to GraphQL. It uses the Neo4j graph database as a datastore.
Atomist wants to be the system of record – making it amenable to audit for compliance purposes. The platform is “enterprise ready” in that it supports enterprise programming languages and frameworks, notably Java and Spring. Given Johnson wrote the original Spring framework the integration with Spring is unsurprisingly, delightful.
Johnson showed a couple of neat demos. For example, simply adding a policy for whether checked in code has a readme file. If not a Slack notification was triggered with a crying cat face. This readme function could be applied with policy for example to just Node.js projects, or only Bitbucket repos.
Johnson gets excited when he talks about the potential of the Atomist approach, as his fervour about developer expressiveness and code kicks in.
“The API for software, the API for your delivery process, the API for development. Grab it and hack it without needing to ask somebody else for permission or waiting it. Let’s enable self service, with guardrails. So now we have that API for delivery flow. I have a violent bias towards code rather than pretty pictures. You’re going to see amazing things happening with people and their ingenuity”
full disclosure: this post was not sponsored, but Atomist is a RedMonk client.
No Comments