Docker containers and microservices are appealing to DevOps teams with tight deadlines, but it's a very bad idea to use either without automated continuous integration and testing in the house, according to Jim Rose, CEO of CircleCI, a software-as-a-service continuous integration platform provider based in San Francisco.
He said he sees automating continuous integration (CI) and testing being easier for startups, but more challenging for older organizations with weighty app portfolios -- particularly those he calls "Jenkins refugees" who have been using Jenkins as an automation server.
"We see momentum growing in adoption of Docker and other containers and microservice architectures, but people should travel that path cautiously," Rose said. Both take the organization away from the IT monolith into many independent services. "This moves the testing challenge out of unit testing and into integration testing, where you have to make sure that all the dependent services work together and don't break in deployment."
In this interview, Rose explains the integration and testing challenges involved in using microservices architectures, offers advice on getting started with automated continuous integration and testing, and the disadvantages Jenkins users face in the service computing era.
What do you think explains the divide between those adopting microservices quickly and those taking a wait-and-see approach?
Jim Rose: We see the divide in a couple of situations.
On one side, for 99 out of 100 cases, if you're just getting started building a code base, a monolith is the way to go. You can basically contain all of your changes in one code base and not have to deal with all of these integrations when you need to make one change in one place. You don't have to go validate five or 15 other services. So, if you're dealing with a younger code base, being a monolith is usually pretty helpful.
On the flip side, start pulling the monolith apart if you're dealing with an older code base or just a more mature code base. Likewise, if your test suites are starting to get out of hand and your test times start to go from eight minutes to 12 minutes to 20 minutes to 30 minutes, moving into microservices makes a lot of sense. This type of organization is the one we most often see moving to microservices.
How does taking a microservices approach add complexity to continuous integration?
Rose: Microservice architectures put a tremendous amount of pressure on the testing infrastructure. You need to have a good CI strategy and automated testing harness to make sure that you can test all the edge cases and all the different integration points between the services. If all of your test pieces are not automated, do that first before even thinking of pulling the pieces apart into individual services.
Right now, the pendulum has swung from monoliths to services. Ultimately, the answer is somewhere in between. There's a Goldilocks zone in there.
What do you think are the key first steps to moving to automated continuous integration?
Rose: Continuous integration and continuous delivery require about 80% process and 20% technology. The first step is getting commitment at a team level to move fast and start iterating in smaller, bite-size chunks, as opposed to just doing sort of Big Bang releases. That usually has to be something either driven out of the product team and engineering team working together.
The second step in existing organizations is usually the consolidation of source code. And that is moving from whatever source code management system you've been using in the past -- Subversion, Perforce, ClearCase, CVS, etc. -- and moving onto Git. Once your team moves onto Git, just given its distributed nature, you actually just watch the pace of commit increase almost organically.
After that come changes in source code management. Once the right source control management platform is implemented, then the rest of the toolchain kind of naturally strings out from there.
What features are must-haves in an automated continuous integration service?
Rose: It depends on the type of project that they're building. But I would look for automatic hooks and gates into all your popular services. If you're using Git in some flavor, you can easily and quickly drop a web hook in and start building immediately.
The second thing that you want is fine-grained access control and fine-grained configuration control that you can push out to your development team. With this in place, there's not one central chokepoint for failure in your overall build process. To increase velocity, you want the ability to push the configuration and push the build control out to the edges as much as possible.
Jim RoseCEO, CircleCI
If your organization has several or dozens of projects that cross different languages and platforms, don't Balkanize out into these individual systems. Instead, opt for one system that provides a consistent view into the state of your applications and the state of your ecosystem.
What do you see as roadblocks developers face in automating all aspects of the software delivery lifecycle (SDLC)?
Rose: Well, it depends. All organizations today want all the pieces in the SDLC automated so they don't need any manual intervention. A new company can simply invest in automation at the start. To do this three years ago, you would stand up a Jenkins server. But now, there's no reason now to do that, and you should try to avoid it, because those which have existing setups in Jenkins face more hurdles in automating.
What challenges do organizations using Jenkins face in automating the SDLC?
Rose: We've seen Jenkins environments that have essentially broken under the weight of the increased velocity of software coming out of the application development teams.
This problem starts with the administration paradigm of Jenkins. Jenkins is all built on a plug-in architecture and administered at the server level. So, if, for example, as an engineer I need to test the new beta version of Chrome, I have to fill out a ticket, send it into DevOps, and ask them to install that plug-in and that version onto that server so I can test the server or test my particular commit.