Building It For Real From Day 1
Disclaimer: this is an attempt to build on Matthew Parker’s awesome post, How to talk to your friends about microservices, with a recent experience I had during an engagement.
I just wrapped up two months in D.C. working with a client who is both trying to climb out of years of technical debt by moving to a 100% microservices architecture, while simultaneously offering a radically different customer experience.
During the project’s inception (the first big meeting that kicks-off a Pivotal engagement) the team reviewed large, distributed systems diagrams that represented the desired end-state architecture. After spending several hours reviewing the documentation, it became clear that it would take months, if not years, before the first viable system could be put into the hands of customers. Separate teams would be stubbing out services until teams could integrate. That’s a long time to wait to glean feedback from customers, the market, and from the consumers of these microservices.
Starting with two questions
Rather than approaching the problem with the system diagram in hand and building out one component at a time, the discussion restarted with how could we get a compliant product in the hands of users that helped to validate our most pressing product or technical assumptions?
We answered the above question by asking two more questions:
- What is the next feature that will provide the most value to the user (the user could be the customer or perhaps another development team)?
- What is it about the existing system that limits us from accomplishing number 1?
It turns out the answer to the second question was nothing. The team reframed the problem and reused much of the existing system to build only what was needed to test our first assumption. We diverted a small portion of traffic to the new product and began testing. The results directly influenced our prioritization.
When to pay your debts
Given that we reused parts of the existing system and created an interface between the new and the old, didn’t we technically put the system in greater technical debt?
No. Technical debt is a measure of a team’s inability to deliver user value. Given that the highest priority in the organization was to validate a radical piece of customer facing functionality, the team used existing systems in order to deliver/validate that functionality.
Similarly, if the highest user priority happened to be that the CFO needed to stop paying insane hosting costs, driven by poorly architected systems, then the team would have approached the problem with the same two questions above. In this case, it happens to be that the (2) existing architecture is limiting the release of a (1) new feature, lower hosting costs. The team would have then hypothesized, built, and iterated toward a suitable solution in exactly the same way.
Tackling a large microservices architecture without a so that statement that goes beyond “because it is old” is a fruitless endeavor.
Evolving into microservices
The team planned, at a high-level, the next six releases based on a current understanding of the market, internal users, and, most importantly, customers. Each release had a central experiment and a key feature based on previous experiments. Through this exercise, it became clear at release five that the existing system would not support the desired customer feature.
This resulted in two actions:
- An experiment was added to an earlier release that helped to validate the customer need for this new, currently unsupported feature.
- Another development team was spun-up to start developing the new service with the current team consuming the service early and often. Of course, if the experiment from earlier invalidated the need, then the new team would be spun-down. This is a prime example of how teams act as best then can with current knowledge, and react quickly to new information.
So keep it real
While a microservice architecture is not bad — heck its the future — the path by which a team gets there can be. No one has a crystal ball that can outline what the state of the world will be and what every customer will need. By not stubbing anything out and building it for real on day 1, teams can learn from the market and evolve into a desired architecture.
Labs Is Hiring!
The Pivotal Labs D.C. office is hiring engineers, designers, and product managers. If you want to make world class software in the heart of the nation’s capital, check out the Pivotal Labs career page. http://pivotallabs.com/careers/
