This article on slow build times is part of a series on How to Choose Your First Microservices.

Switching to a new software architecture style is costly. I advocate choosing where to employ microservices first by using them to solve existing problems in the team. This helps the organisation extract value from the new architecture with each step towards the new world. This series is working through a set of problems that your org may have, and how microservices might help solve them.

Slow Build Times?

Does your team have an application that takes a long time to build and run tests? Is a large portion of the development team working on it? That could be a huge amount of idle time you’re pouring down the drain. The classic XKCD ‘Compiling’ comic makes light of developers enjoying the time they spend waiting for their code to build. The truth for most devs is they would far prefer to be making fast progress on their work than sitting around waiting.

If you can identify a slice of upcoming work that (a) would typically be added in where the slow build is, and (b) could be easily cordoned off into a new artefact, it might make sense to create a new service with a fast build and do the work there.

Here’s an Example

At Tyro, we had this slow build situation with our single internal webapp. Up to a certain point, all the features of our system used by all our internal staff were clumped into a single web application. It had a lot of screens and a lot of tests. The build took ages – 30+ min. on a beefy dev desktop. And that’s with all the calls to the backend API service mocked.

We were embarking on a new project that would re-write a number of the functions used by the Finance team. While planning, we identified the webapp build time as something that would slow us down. We decided that a new, empty web application – where we would build just financial functions – would allow us to move a lot faster. We:

• copy+pasted the existing webapp;
• deleted everything except the login and home page functions and the test framework;
• find+replaced the webapp name;
• bumped all the dependencies to the latest version; and
• started iterating with our sweet, sub-1-minute build.

No sword-fighting was required. It was a successful strategy that we repeated many times. Tyro now has a suite of smaller internal webapps serving different functions and business domains.

Gotchas

There’s two things to watch out for when breaking out microservices to solve slow build times.

Firstly, you want to ensure that the domain you carve out is one that’s going to see active development in the future. In particular, you ideally want it to be a piece that will see much more active development in the medium term than the pieces that you’re choosing not to break out. If you give some functionality a really fast build, but are still doing most of your development in the domain with the slow build, you’ve lost out.

Secondly, you want to ensure you actually get rid of the cause of the build slowness when you make the new service. In the example above, it was the sheer volume of features that made the build slow, so dropping to zero features dropped the build time to near zero. For other apps, though, the build may be slow for some other reason, like dependencies being downloaded too often, long-running steps like unoptimised Docker builds, or an integration testing suite with a long setup time. You may miss out on the build time savings if you repeat the mistakes of the past.

If you want to be notified when future articles are published, sign up using the form just under my photo.

Next article in the series: Using Microservices to Solve Developers Stepping on Each Other’s Toes

Image credits:
Snail from MaxPixel.net