At QCon New York 2017, Andrew Hart talked about the architectural, organisational and operational aspects of evolving microservice architecture, drawing on many real world examples during his work at SeatGeek.
At QCon New York 2017, Andrew Hart talked about the architectural, organizational and operational aspects of evolving microservice architectures, drawing on many real world examples during his work at SeatGeek.
Hart made the point that all software systems are interconnected in some form or another and that in reality: ” You probably already have a microservice architecture, whether you want one or not “. He also reasoned that software will always be about change, driven by different factors such as technology, scale, and organizations. Microservices help aid that change by being an evolutionary architecture. Some key takeaways are:
Hart believes that microservices should be atomic in the sense that each one maps to a single capability. He explains that this is notoriously difficult to get right, but it’s thinking about these capabilities that help deliver a maintainable microservice architecture.
As a real world use case, Hart explained the problem of ticket normalization at SeatGeek, which involved providing a unified view of ticketing codes across markets. Multiple microservices needed to access this logic, and due to time constraints, the code ended up being duplicated across them. Having this code in multiple places impacted on the maintainability of the system, requiring code changes to be repeated, and introducing more scope for errors. When the normalization was thought as a capability, as it should have been, it was then pulled out into its own microservice and given a clearly defined interface, removing the technical debt.
Hart pointed out another misconception of microservices, is that adding or integrating new components into the system will be simple or straightforward. In fact, capacity planning is important, and microservices won’ t necessarily absorb anything thrown at them.
An example at SeatGeek was trying to integrate a newly acquired primary ticketing system. This was challenging to do as it was written in an unfamiliar language, and provided a clunky SOAP API which was difficult to use. To work around this, the team build a new SG Public API, which essentially acted as a proxy between this new SOAP system and their existing services, doing data transformation and provided a simplified interface. This also allowed them to open the API up to third parties, by abstracting away the complexity of the original API. Ultimately, it was capacity planning for this that was key.
Hart also stressed the imports of DevOps in microservice architectures. When systems are distributed in this way, there are extra operational concerns that you wouldn’ t get with a traditional monolith. This is why microservices work very well in a PaaS, simplifying infrastructure and evolving the architecture.
He also pointed out that one of the most important operational concerns is monitoring. An example of this with SeatGeek, was when a graph spike pointed out too many PDF tickets were being download before an event. These metrics allowed the company to identify a bug in their mobile app, something that would otherwise not have been discovered.
From an organizational point of view, Hart believes how teams are split can impact on delivery. As new requirements come in, and architecture evolves, teams may need to be restructured and modeled around capabilities as opposed to technical concerns. If a capability is partitioned across teams, then it becomes much harder for it to be delivered. Hart explains how these principles are proven in Conway’s Law.
To conclude, Hart explains that whilst evolving microservices is challenging, he believes that considering these architectural, organizational and operational concerns will make doing so more straightforward. Ultimately, he believes the gain of microservices is vast, and in their particular use case, they are what made SeatGeek be able to be delivered in such a short period of time.
