Agile Management: How to Manage Microservices With Your Team
The term microservice has been around for maybe five years now, referring to independently deployable services that come together to form a suite of services that you can choose to connect or not. Only in the last year or two have companies been actively using it as a more flexible, scalable alternative to the monolithic architecture. We could debate the advantages and drawbacks of microservices, but today we are looking to talk less about the software architecture and more about its implication on your organizational structure.
This post will walk you through the traps and triumphs of your team on microservices, and we will even go into how, when done correctly, microservices architecture fits right in with the rules driving quality software design, dating all the way back to the 1960s.
This is Your Team on Microservices
The business benefit to microservices is strong — you become more competitive because you are able to respond more quickly to client needs. And, according to Agile Alliance head and CTO of Printchomp Declan Whelan, when implemented correctly, microservices architecture is a way to improve your quality of design, delivery and collaboration as a whole.
Of course, with every upside, there’s a downside. Domain-driven design thought leader Jan Stenberg succinctly sums up the common struggles in his piece “Experiences from Failing with Microservices.”
Microservices architecture is often served up with a side of:
- Disagreements among developers: Not everyone will jump on Team Microservice right away, and not all your team members will have the technical capabilities to do so anyway.
- Service boundaries cause barriers: When you divvy up the work, you create a sense of ownership, which can lead to blame. “This led to developers complaining of their service being blocked by tasks on other services and refusing to help out by working with these blocking tasks,” Stenberg said. He also found that the often single-minded microservices distracted from overarching goals.
- Independent services: Allowing programmers to work independently can create further language barriers, which pop up when attempting to connect the pieces. “Failing to specify an API for each service, particularly the model passed between each service, led to regular issues especially for the frontend developers,” Stenberg also said.
- Service Granularity: Doing too much too fast. Again, microservices can forget to focus on the bigger picture of how these pieces come together, with each microteam racing to deliver its own.
Deciding If Microservices Suit Your Needs
Every team comes to the decision of what works best for them. Here’s one story:
Printchomp is an 11-person team, including four on-site and two off-site coders, who also perform all the quality assurance and testing. Whelan says they chose to go the microservices route not because they were looking for it, but rather they were simply looking for a change and microservices arose as part of the solution to their needs. Their objective was to simplify the sharing of the core capabilities from both a private API and their domain — allowing clients to print goods easily — allowing them to share that capability without duplication.
This was the team’s first web API, and they wanted it to be a RESTful hypermedia API.
Whelan said they wanted an architectural solution that allowed them to migrate forward while still being backwards compatible, with an ability to roll out new changes without breaking existing interfaces. They wanted it to be simple to use and readily consumable by clients, “so certainly a restful JSON API made sense,” he said.
“We had built a relatively monolithic Rails application, and we saw the need or desire for an API access to what Printchomp does, and microservices were the obvious answer.”
Actually, Whelan found that the three-way combination of microservices, domain-driven design, and the ports-and-adapter or hexagonal architecture was the solution for them.
In fact, he thinks this can be a game changer for the entire software industry. “There was a strong correlation between resources and domain objects that sort of got me thinking about this ports and adaptive architecture style. We could have different adapters from the API,” he said. “There’s the triumvirate and this triangle between domain-driven design, ports and adapters, and microservices that really seem to overlap and self-support. Each one is a really powerful idea and the combination of those three is really powerful.”
How to Help Your Team Cope with Microservices
Once you decide if microservices architecture is the right direction to steer your team, here are some ways to help ease them in:
How to Reorganize Your Team Around Microservices
In 1968, programmer Melvin Conway stated:
“organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations.”
Basically, if you have three teams building a compiler, they’ll likely build a three-pass compiler, while if you only have two teams, you’ll get a two-pass compiler. Your architecture reflects your organizational structure, and if you want a certain technical architecture, you need to realign your organizational structure.
Since dubbed Conway’s Law, it rings especially true with microservices architecture today, which often aggravates communication problems.
Of course, if you take Whelan’s recommendation, while the team’s structure may change, “If a company wants to be successful in microservices, since microservices are small, they need to be handled by a single team, as they are in Netflix and Amazon. Then that team needs to be responsible for concept to cash.” If the entire team is responsible from start to finish, this would certainly diminish the problem of ownership.
“Microservices will drive team boundaries in a different way because it’s going to be hard to have three teams working on the microservices. If you are looking at continuous delivery, you need a single team, and then Conway’s Law kicks in and your team has to mirror your product-slash-microstructure.” Of course Whelan admits this is impossible to coordinate across large-scale organizations.
One agile management game that helps you do this is called Meddlers by Management 3.0. Introduce microservices as a way for your team to self-organize, forcing them to grow their organization on a flat surface, focusing on the organization’s fractal value network, not hierarchy. Players place cards to design organization based on functional and cross-functional dependencies for each project.
Bring Back Extreme Programming
Extreme programming is all about delivering specific products and services as you need them, which is, in essence, microservices to a T. It focuses on creating a flat, collaborative team, where all team members are constantly communicating with each other and their customers. Dating back to 1996, this idea aligns comfortably with today’s trends of lean, agile and scrum.
Extreme programming’s values can easily be applied to microservices:
- Simplicity: Do what you gotta do.
- Communication: Like daily stand-ups, it requires daily face-to-face check-ins.
- Feedback: A predecessor to scrum’s short iteration followed by demo and retrospective.
- Respect: As ownership changes with microservices, this can fall wayside. “Everyone contributes value, even if it’s simply enthusiasm.”
- Truth: Manage expectations and take responsibility as a group.
Revisit Agile Engineering Practices
Let’s briefly review the Agile Manifesto:
- Individuals and interactions over processes and tools.
- Working software over comprehensive documentation.
- Customer collaboration over contract negotiation.
- Responding to change over following a plan.
It’s about being adaptive and responsive to change — certainly a principle behind microservices. But, as Whelan said, it’s also about finding the “right balance between people and process and products,” a part which is less considered when companies often cross their arms, blink their eyes and magically declare themselves “Agile!”
So what sorts of agile engineering practices should your team be trying?
- Pair Programming: Break down cubicle walls and find someone to work with for a few hours a day. (Or try Pair Spooning.)
- Refactoring: Aka cleaning up along the way to monitor how the domain is shifting.
- Test-driven Design: Before going through the whole design process, test your hypothesis first to check if it is safe to introduce.
Whelan pointed out that “If you’re going to be building microservices, then you need to be doing continuous delivery and then you need to be doing all the technical practice,” including test-driven development and refactoring.
Be Wary of Scrum Ignoring Analysis and Design
Whelan warns against using solely scrum because he feels it can actually do damage to your technical assets. “There has been a steady decline in technical focus with agile transformations. As a really technical agile coach, that disturbs me because I think that organizations need a multifaceted approach to agility. Scrum doesn’t provide any guidance on technical practice by design,” he said. “Many organizations that adopt scrum get really good at building technical debt quickly.”
Whelan warns that the popular scrum framework comes with intentional holes that, if not well planned for, leave holes in your microservices architecture.
“If you had a traditional waterfall, if you used to do analysis and design and take care of the technical details, you need to be doing it in another way, but scrum doesn’t allow” for that. “If you aren’t replacing that with anything else, you’re really just having feature after feature after feature,” Whelan said, “and, after awhile, your technical core will be a huge waste and you’ll just have to rewrite and rewrite and rewrite.”
His team uses a product owner with microservices, but otherwise follows kanban with weekly ceremonies.
It’s essential to remember that while microservices is all about scaling independently, you can’t lose track of broader objectives and how everything connects.
Microservices Nine Months Down the Road
Before summarizing, let’s shine some disinfectant sunlight on the Printchomp microservices experience.
“We started to build the microservices separately, but coexisting. We started to build new services, but as the services stabilized, we slowly refactored our web applications.”
He said that, after nine months, it isn’t a finished work, but rather they are still going through that transition.
“One thing I believe and I learned is that having a clear understanding of your domain is a really valuable thing, because your code domain doesn’t change as much as adaptive services that change around it, and if you can separate things that change a lot from things that change a little, that really helps because then you can really build a stable core and that’s really what we’re after.”
Now, this all doesn’t mean that Whelan and Printchomp’s last nine months of microservices have been easy. In particular he said “refactoring across microservice boundaries is more challenging than in a self-contained.”
He also admitted that it wasn’t an easy sell. “I think there was skepticism at the start because domain-driven design and this hexagonal architecture and microservices were really new to the team,” but once they understood the value, they could move forward with the change.
Microservices Management Reviewed
Microservices architecture has a strong, agile business proposition over monolithic architecture because it allows you to scale your business rapidly in response to client needs. However, like scrum and other methodologies and frameworks often forced upon programming teams, if it’s not implemented correctly, it can instead break down communication and team collaboration.
Let’s review some tricks to avoid that from happening:
- Following Conway’s Law, your software will reflect your organizational structure, but also your organizational structure can be influenced by your software goals.
- Whenever possible, microservices work best with one team. Too big for that? Try a game like Meddlers to help you restructure.
- Concentrate on the simplicity, communication, feedback, respect and trust of Extreme Programming.
- Try Agile Engineering like pair programming, refactoring and test-driven design.
- Don’t get so caught up in scrum that you forget the big picture.
As Whelan said, “I think microservices is forcing us to make better technical decisions.” But you need to work to make that happen.
In the end, remember that microservices architecture is an answer to some problems, but, as always, do what’s best for you and your team and consider mixing it with other complementary architecture, like hexagonal or domain-driven design.
