Developing in a Microservice Environment: Part 3
September 16th, 2015
In the first and second posts of this series on helpful guidelines to help you get started in the creation of effective microservice architectures, I described the importance of effective documentation when developing microservices, as well as the challenge of maintaining consistency in an environment with distributed development teams. In this post, I will look at some strategies for effective communication.
- Lack of documentation will kill your team’s productivity, but selecting the correct way to document is just as important.
- Consistent use of best practices are necessary to maintain developers’ sanity.
- Effective communication is extremely important, but too much communication is a detriment.
- Setting up a good development environment is as important as (or even more important than) the development itself.
Communication Strategy
The success or failure of a microservice project is largely determined by the team’s communication strategy. This includes communication across the various teams involved, as well as within each specific service team.
Internal team communication is a big part of the agile development process—which is used in most microservice deployments—and typically includes daily standups, sprint retrospectives, and sprint planning meetings. These are all helpful mechanisms for keeping your team on track, however they can also lead to over-communication, as I’ll discuss in a moment.
Unfortunately, the agile process does not include a mechanism for inter-team communication. There are also no guidelines on how to bring a new member of the team up to speed. In this post, I will summarize the communication strategy we developed during our year-long engagement in an enterprise microservice environment for both intra- and inter- team communication.
Intra-Team Communication
Agile methodology lends itself very well to microservice development. They’re both ways to make a team flexible, and involve constantly iterating over every part of the project. Neither an agile development project nor a microservice architecture engagement is ever really “completed.” They’re constantly evolving, adding more features or improving on previous functionality. I’m a big proponent of agile, with a few caveats:
Keep Standups Short
The daily standup is a great way to maintain a good rhythm. It keeps all of the commitments by individual developers in check, and makes sure that nobody is stuck on any specific task. However, it’s very easy for the daily standup to get out of hand. Once your standups grow longer than 10–15 minutes, it’s time to reevaluate the way they are being run. Bear in mind that an extra five minutes in a 10-person meeting is nearly an hour of wasted developer productivity. Consider breaking up the stand-ups once the team grows to more than about 8–10 people. Another way to mitigate distraction is to consider switching to a virtual report-out. We use a designated channel in our Slack instance where each person writes their daily update.
Keep Meetings to a Minimum
Every eliminated meeting is a victory for productivity. Basecamp’s DHH and Jason Fried have an interesting take on this: Meetings Are Toxic. One can look at open source projects and find highly-effective teams that have never had an in-person meeting. They value written communication over face-to-face meetings. Since agile development teams (just like the software they create) have become a lot more distributed in nature, and more and more developers are working remotely, there is something to learn from this approach.
Use Agile as a Template Instead of a Recipe
A lot of teams take agile too literally. The agile methodology is meant as a set of guidelines or a template, instead of a specific description of how every team needs to operate. If you feel as though it’s difficult to shoehorn your current part of the project, such as a design phase, into the agile process, it’s because you’re overfitting the methodology to the problem at hand. Andy Hunt, one of the authors of the Agile Manifesto, describes this flexible approach in his book “Practices of an Agile Developer,” and summarizes the downfalls of rigid adherence to the methodology in his recent blog post, The Failure of Agile.
Inter-Team Communication
Since by definition microservices are independent services, one may think that each service team can work in a silo, publish their blueprint, and leave the rest to fate. This is entirely the wrong approach. A microservice architecture still comprises a coherent system, which has to perform according to the functionality and SLAs set by the business. Microservice teams have to be highly-coordinated, therefore, in order to achieve this coherent structure.
One way to achieve this is by having the technical architecture teams coordinate among each other on a semi-regular basis. Things that need to be communicated include best practices—which may evolve throughout the project, though hopefully not too much—approaching deadlines, and each team’s ability to meet those deadlines. We held a technical leadership meeting every three weeks in order to discuss all of these topics, as well as to develop common approaches to the universal challenges faced by each team. This cross-pollination among teams saved a lot of developer time. The outcomes of these meetings were documented in a common place accessible to all the members in every team.
In the next post, we will delve into the actual development process of microservices. We will discuss some of the techniques and tools that SVDS found to be useful during such an undertaking.
