One of the intriguing things about IT is just how much success is driven by nontechnical factors. For me, another fun part is looking at how the technical parts can shape the nontechnical parts. The decision to develop applications in a microservices architecture is a technical decision. There are a number of nontechnical results that can lead to better software development and greater business value. I wrote about how the pace of business change is the cause of microservices architectures. While I was thinking that through, it occurred to me that microservices lend themselves to more productive teams. They also deliver greater developer satisfaction. Even if we didn’t want microservices-based applications for agility, we might want them for productivity.
The idea of small teams being more productive is well established. As the number of people on the team grows, we end up spending more time managing and coordinating the team than in producing anything. The usual measure of optimal team size is two pizzas or one duck. A project team that can be fed with two pizzas or one duck is likely to have the most productive team size. This is a very unscientific measure and only the roughest of guides, yet it does seem to make a lot of sense. This is a pretty small team: under a dozen people. Depending on the rate of change and the complexity of the code, this team is likely to look after a few tens of thousands of lines of code: nowhere near the millions of lines of code that make up an operating system or a server application. To maintain a piece of software with such a small team, the piece of software needs to be small.
Microservices essentially break large applications into smaller, autonomous units that can be developed and maintained independently. Each microservice has its own API for other services to access. The API simply defines what the inputs and outputs are for the microservice. Only changes to the API need to be coordinated with other teams. Any changes inside the microservice that don’t alter the API can be completed within the team. These changes could be performance improvements, rewriting the microservice in a new language, or simply resolving a fault in which the microservice does not deliver on the API. Since the microservice is smaller, hundreds or maybe thousands of lines of code, a small team can support the code. This ability to take complete ownership of a small piece of code is what leads to both productivity and developer satisfaction.
In a large software development project, it’s easy to spend more time making all the different bits of software work together than building new features. Often this comes down to not having tight definitions of what each part must do. In a microservices architecture, the API is that tight definition. The APIs on each microservice make it easier to identify where faults reside and who must resolve them. When new functionality is required, either new microservices are built or additions are made to the API on existing microservices. Once the API definitions are created, the developer team can build out the software required to deliver the API. Defining the API is the only coordination required outside the team. There should be more time for the team to write code. Once the code is written, the unit testing of the microservice is simpler. The API defines how the microservice should work, and the unit test should confirm that the API is delivered. Once the unit testing is complete, there is a far greater probability that the system test, of the complete application, will also pass.
Another nontechnical component is job satisfaction. Software developers are generally proud of the work they do, the code they write. In a large software project, it can be hard for an individual developer to feel that they had a significant impact on the project. Their ten-thousand lines of code may be spread all over a large project. With a microservices architecture, each developer’s code is likely to be in identifiable locations in the finished application. Owning a feature completely enables pride in the feature. Pride in the code that is produced leads to better code and yet more pride, a virtuous cycle of software development.
Microservices are essential to enable agility in the development of software products. They are an enabler for developer productivity and job satisfaction. Using microservices architecture helps applications to scale out for better performance. It also helps with scaling out the software development process and application change rate. Both types of scaling lead to better agility and service delivery to the business.
Excellent synopsis – well thought out and well communicated. I have been in Embedded Systems Development for over 40 years and every word in this well laid out article rang true and all I could think of is “Why hasn’t this concept been articulated before?” Why didn’t I ever articulate it? Because the brilliance of this article is tied to the highly focused binding of an API to the developed micro-services architecture – a powerful concept unto itself. THANK YOU ALASTAIR COOKE.