San Francisco's SOMA district, where InfoWorld moved its offices 15 years ago, is ground zero for startups. Many if not most rely on Amazon Web Services for their infrastructure and the 20-something developers who work there take agile and devops and Docker for granted.
The world of enterprise developers couldn't be more different. As InfoWorld's Lucas Carlson recently noted, most enterprises remain mired in legacy applications and only "a tiny fraction of them know how to do agile-style, cool-kid development."
Part of the reason for that, along with good old institutional inertia, is simply scale. When you have a dozen developers or less working on a social media app, it's easy to be agile. When you have hundreds or thousands of developers, many of whom may be responsible for legacy software embodying mission-critical processes, governance and control have a tendency to trump agility.
Zubin Irani, CEO of the agile project management consulting company cPrime, recently offered InfoWorld insight into how enterprises are trying to learn the agile tap dance -- and what sort of tools they're using. He echoed Carlson in observing that most enterprise dev shops were just starting to learn how to do agile right, let alone implementing some sort of seamless CICD pipeline.
When I asked Irani about enterprise app dev tooling, he cited a few interesting trends. At the front end of the process, he's seeing a whole lot of Atlassian software: Confluence for organizing requirements and Jira Software for agile planning and project management. What they're using for code repositories and versioning shouldn't surprise you: It's a pitched battle between GitHub and Bitbucket (see the InfoWorld comparative review). For continuous integration, to the degree that enterprises are actually doing it, Jenkins is the leader.
Further down the pipeline, things get fuzzier. QA testing remains largely a manual affair, although open source test automation tools like Selenium (for web apps) and Appium (for mobile apps) are growing in popularity. On the deployment side, Irani says everyone is talking about Docker -- and without doubt individual developers are using it -- but most organizations still rely on VMware "way too much."
How, then, do we reconcile this with recent stats pointing to huge spikes in container adoption? New Relic, for example, recently released a report saying that over the last year the average number of containers had increased by 192 percent among the companies profiled. Likewise, in the latest Future of Open Source Survey by North Bridge and Black Duck, 76 percent of respondents had plans to use containers and 37 percent were already using them for dev and test.
I have a feeling that data was tainted by a few too many cool kids at internet companies. But there's also a "greenfield tier" at enterprises, where they hire (or rent) cool kids who build public-facing apps in the cloud. They may be developing on behalf of the enterprise using all the latest techniques, but they're not enterprise developers in a conventional sense, working on core enterprise applications.
So is there any sort of bridge you can build between old and new? In a recent conversation with Microsoft Azure CTO Mark Russinovich, he offered an intriguing response to that question:
Actually, I think there is a bridge, and that's the compatibility of containers… So those enterprise applications that are built on existing enterprise products, you can take advantage of containers without having to rearchitect your application… When customers come and talk about container strategy, one of the things they talk about is to containerize everything, including those legacy applications, with minimal changes.
Now, I've been schooled to think about containers in the context of "cloud-native" applications, where you break monolithic applications down into microservices. But Russinovich, who incidentally is one of the highest-profile advocates of microservices around, corrected me:
A monolith today is typically on a server or in a virtual machine. You take that and you put that monolithic chunk inside of a container. And now you can at least deploy it and manage it much more easily. It becomes portable… One of the advantages of putting it in a container is that, as you're breaking down the monolith in the container, you've already got the agile lifecycle around the containerization of it. Which is going to help you more quickly evolve it than if you left it in a virtual machine or on a server.
That's one way of easing the migration of legacy to cloud native. But it doesn't address the cultural disconnect. As Sasha Labourey, CEO of Jenkins-as-a-service provider CloudBees, told me: "It's not like if you don't do CD [continuous delivery] you're stupid. If you're a startup, it's easier. You don't have any legacy so it's cool. If you're a ‘real' company, it's going to take time."
Tools are important, but people get accustomed to doing things a certain way. Plus, as Labourey says, new methodologies and technologies come along all the time and people get jaded. To convince them a new paradigm is going to make things better, the usual advice applies: Start small with your best developers on a project that has a very good chance of succeeding. If it all works out, you'll have the best internal marketing you could wish for.
So take those stats about widespread enterprise adoption of agile, devops, CICD, containers, and the like with a grain of salt. Sure, enterprises are spending more on greenfield, cloud-native development, but this looks like a big leap only from a distance. Shifts at the core happen one step at a time.