 |
VOOZH | about |
|
VOOZH | about |
We’re so glad you’re here. You can expect all the best TNS content to arrive Monday through Friday to keep you on top of the news and at the top of your game.
Check your inbox for a confirmation email where you can adjust your preferences and even join additional groups.
Follow TNS on your favorite social media networks.
Become a TNS follower on LinkedIn.
Check out the latest featured and trending stories while you wait for your first TNS newsletter.
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.
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:
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.
👁 ports_and_adapters_architecture
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.”
Once you decide if microservices architecture is the right direction to steer your team, here are some ways to help ease them in:
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.
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:
Let’s briefly review the Agile Manifesto:
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?
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.
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.
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 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:
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.
