Architectural analysis of Franklin Angulo presentation on Building Microservices @Squarespace
The Squarespace Developer Platform enables developers to create fully custom websites and integrate them with 3rd party tools. Therefore, since Squarespace clients can write their own code, it triggers concerns about the impact that local problems may have on the complete platform. In order to avoid this undesirable behaviour, the Squarespace software architecture needs to fulfill the following availability scenario.
- Source of Stimulus: Customized website
- Stimulus: A fault in the code or operation of the website
- Environment: Normal operation
- Artifacts: Squarespace
- Response: The impact is controled and managed in the shortest amount of time
- Response Measure: Short time to detect faults and reduced impact on other websites
- Tactic: Migrate from a monolith architecture to a microservices architecture
The migration to a microservices architecture actually requires a revisit to this coarse grained scenario and look in detail at how to design a software architecture on top of which developers can customize their websites, taking advantage of the qualities provide by a microservices architecture while reducing and controling the inter-service impacts. The presentation by Franklin Angulo is about the architecture of a platform to develop microservices applications. Therefore, the main stakeholders are the developers of the microservices applications, which want to have a friendly environment where they can develop, test and run their applications, and the administrators of the Squarespace platform, which want to have the tools that help them to manage and control the interferences between the different microservices that are running in the platform. Note that the end users of the applications that run in the Squarespace platform are not direct stakeholders because the focus of the presentation is on the platform and not on the applications using it. On the other hand, due to the DevOps approach that is fostered by the microservices architecture, the developers are also administrators of their own applications once they are deployed, which means that some of the qualities the microservice cross-functional team require are the same as the required by the platform administrators, though in the scope of their own application. Anyway, for clarity, the stakeholders were divided by their role, administrators and developers, instead of by their organizational responsibilities, Squarespace platform and Squarespace applications.
Starting by focusing on the qualities required by the Squarespace platform administrators, which are a refinement of the initial scenario, described above, the following scenario describes how a fault in a microservice should not compromise the entire platform due to the continuous allocation of resources without deallocating them.
- Source of Stimulus: Microservice
- Stimulus: A microservice does not respond to a request from another microservice
- Environment: Normal operation
- Artifacts: Squarespace platform
- Response: The execution is not hold indefinitely, it either fails fast, fails silent or fallbacks, and it does not impact on the resources required by other requests that are being executed in the same server
- Response Measure: No impact on the processing of other requests
- Tactic: A set of tactics, from detect faults to preparation and repair, depending whether the solution is fail fast, fail silent or fallback.
Another quality that is supported by the architecture is the possibility to dynamically redefine the sampling rate of logging, which can be expressed by the following modifiability scenario.
- Source of Stimulus: Administrator
- Stimulus: Change the tracing sample rate of a service per environment
- Environment: Runtime
- Artifacts: Distributed Tracing
- Response: The sampling rate is changed
- Response Measure: Immediately, without cost
- Tactic: Defer binding
From the perspective of the development of Squarespace applications, the architecture provides a set of software elements for the qualities of performance and testability. In what concerns performance, if a microservice requests services from several other microservices and there is not any data dependency between them, then this is a good candidate to use asynchronous invocations. The following performance scenario describes this quality.
- Source of Stimulus: Microservice
- Stimulus: Multiple data independent requests to other microservices
- Environment: Normal operation
- Artifacts: Squarespace application
- Response: The processing of the requests occurs in less time than their sequential execution
- Response Measure: The max of the latencies of each one of the requests plus an overhead
- Tactic: Introduce concurrency by making the request invocations asynchronous
Note that, although the scenario is expressed from the perspective of the Squarespace application, it actually could be described as the quality provided the Squarespace platform to support the design time modifiability that a Squarespace application has to change its performance capability by using the Asynchronous Request Execution connector of the platform. In general, the Squarespace platform can be seen as a middleware with a set of connectors that simplify the development of Squarespace applications.
Another performance quality that it is provided by the platform to the application developers, is the possibility to split the load of a request between several instances of a microservice. The following performance scenario describes this quality.
- Source of Stimulus: Microservice
- Stimulus: A large number simultaneous requests are sent to a particular microservice type
- Environment: Normal operation
- Artifacts: Squarespace application
- Response: The request are processed in uniform time
- Response Measure: The latency should be constant, independently of the number of requests
- Tactic: Maintain multiple copies of computation, by having several instances of a microservice and dividing the requests between them
The use of several microservices instances and the use of a load balancer are the architectural solutions for the above scenario. Similarly to the previous scenario, it also represents a quality that is provided by the platform and that can be used by the application developers as a connector, the Client-Side Load Balancing.
A known problem of the microservices architecture is its testability due to the distributed and asynchronous execution of the requests. To support their developers, the architecture of Squarespace platform has to fulfill the following testability scenario.
- Source of Stimulus: Integration testers
- Stimulus: Test a user request which requires the invocation of several microservices
- Environment: Integration time
- Artifacts: Squarespace application
- Response: The request is executed and the trace of the request execution between the different microservices is captured
- Response Measure: Reduced effort to capture the trace of the request execution and perform integration testing
- Tactic: A specialized interface to log the invocations between microservices
The Squarespace platform provides structured logging and distributed tracing capabilities that can be used by the application developers, which is based on the contextual information about a request that is passed during microservices invocation. Note that this same solution also fulfills an availability scenario for the platform administrators, which can use logging to detect faults in the Squarespace servers during operation.