Architectural analysis of Andrew Hart presentation, Take Two: Evolving Microservice Architectures
This presentation describes the architectural evolution that occurred at SeatGeek, when it moved from doing secondary ticketing, essentially as an aggregator that integrates different markets and brokers that sell tickets which provides a user friendly interface, to a primarily responsible ticketing for US sports events.
The relevant stakeholders are the users, that intend to have a good user experience when using the system and which require acceptable performance and availability, the developers, that want to reduce the cost of change when adding new functionalities and integrating with other systems, the business people that want to grow the business by buying other software ticket vendors and integrate them with the main SeatGeek software as well as to allow third parts to integrate in the SeatGeek ecosystem. Therefore, the main qualities are usability, modifiability and interoperability. Additionally, deployability and availability are also important because of the DevOps characteristics of the development process that SeatGeek embraces. Note, however, that the first set of qualities is specific of SeatGeek business whereas the second set is more general and may apply to all systems that provide services through the internet, that may be subject to period of heavy load, and where time to market is such an important goal that the development team is in charge of providing and monitoring the service. It is, actually, the second set of qualities that justifies the need for a microservices architecture.
Concerning the first set of qualities, the ones that are SeatGeek-specific, we start with a usability scenario that is
- Source of Stimulus: End user
- Stimulus: Use the system to buy a ticket and choose a seat
- Environment: Runtime
- Artifacts: SeatGeek
- Response: It buys the ticket and choose the available seat that considers more convenient given the set of seats offered
- Response Measure: User satisfaction because she is able to compare the location of the different offers
- Tactic: System initiative by maintaining a system model that standardizes identification of seats location sold by different ticket sellers
To implement this tactic they add to write normalization code which, with small variations, started to be copied to different of the architecture the architecture. After while they realized that the cost of copying and maintaining the normalization code in different contexts was higher than the effort to integrate it in the architecture as a reusable part. The follow modifiability scenario explicits this requirement.
- Source of Stimulus: Developer
- Stimulus: Intends to add a new feature that requires the normalization functionality
- Environment: Design time
- Artifacts: SeatGeek
- Response: The feature is added and tested integrating the normalization functionality with a small number of errors and effort
- Response Measure: Integration of the normalization functionality takes less than 2 hours (value not explicit in the presentation)
- Tactic: The tactics used are refactor, because it is necessary to remove the duplicate code, and abstract common services, because the normalization functionality is implemented as a microservices using an API that should support the different contexts where the normalization functionality is required
Note that the decision to reuse the normalization functionality as a microservice, instead of a module, results from requirements that were not made explicit in the presentation, but that way is possible to take advantage as its independent deployment as a service.
Interestingly, the reason for the normalization functionality may also have been raised by an interoperability scenario, in order to have semantic interoperability between the external data models and SeatGeek internal data model. Nevertheless, another interoperability quality is required to define a performance level quality of service in the interaction between the SeatGeek and external systems. In particular, SeatGeek is implemented in Python which is slow to parse a large XML file and some external systems, like TopTix, which uses a SOAP protocol resulting in reduced quality of service when SeatGeek interacts with it. This is an example of semantic interoperability where the data structure returned by TopTix was not adequate.
- Source of Stimulus: SeatGeek
- Stimulus: Receives a large amount of information about seats using an XML format
- Environment: Known prior to runtime
- Artifacts: SeatGeek
- Response: The information is exchanged according to the required quality of service
- Response Measure: The information is exchange in the correct time
- Tactic: Taylor interface, because it was defined a conversor from XML to JSON which is written in a statically typed language, .NET Core
The interface, SGOpen, became a standard that allows other distribution partners to integrate with SeatGeek.
Concerning the second set of qualities that are at the core of the qualities provided by the microservices architecture, we will consider two, as an illustration, but their scenarios are generic because they are support for an infrastructure that is used in several microservices projects. Let us start with an availability scenario.
- Source of Stimulus: Developer
- Stimulus: An error in the code of a microservice which results on a non-performant behaviour which require extra resources
- Environment: Normal operation
- Artifacts: Microservice
- Response: The fault is detected and an alert is sent
- Response Measure: The time to detect the fault
- Tactic: Condition monitoring through the Kapacitor component
The Kapacitor component is integrated in an architecture that collects logging data from several sources, which is an architecture external to the SeatGeek architecture. The scenario for deployability stresses the easiness with which the development team can deploy instances of their microservices.
- Source of Stimulus: Developer team
- Stimulus: Intends to deploy an instance of a microservice
- Environment: Normal operation
- Artifacts: Microservice and execution infrastructure
- Response: An instance of the microservice is deployed and executes integrated with the other microservices instances
- Response Measure: The process is done without errors and in a short time
- Tactic: A scripting language is used to write an application manifest