Three questions for ...

Q: Tell us about the approach you are taking to evolve a monolithic mission-critical trading platform into a modern distributed microservices architecture?

Microservices as an architectural paradigm is relatively new so there is lots to learn conceptually on how it all works in practice. Our team had minimal exposure developing microservices so the first step was to start reading and learning.

When looking at the various development frameworks available in the marketplace, we ultimately decided the best options for us were Spring Cloud and a newer framework called Micronaut started by the same team that developed the popular Grails open source web framework. For several reasons, we decided the Micronaut framework was the better option and we hired the developer OCI to come onsite for one week of training in early 2019. One year later, we have five services live in production which are working really well.

As we turn on new services, we decommission a piece of the legacy monolithic platform and that will be the approach going forward. As the platform evolves and we learn, there will be refactorings needed along the way to get it right as we anticipate some choices will not pan out as expected. Adopters of this approach have to keep in mind there is a bit of an art to scoping the granularity of a microservice – you have to take into account bounded business domains using best practices such as Domain Driven Development (DDD) and the Single Responsibility Principle.

The second step in the evolution is the consideration of how to manage and run your services. You have to think about API gateways, service discovery, horizontal scaling, load balancing, message brokers, centralized configuration, distributed tracing and logging, containerization, etc. There is a lot to consider and it can be overwhelming. We are approaching this incrementally.

To start, we are using a service discovery along with support for distributed configuration, Docker, and several message brokers for interservice event communication. In addition, we had to implement a brand new build and release toolset developed by our global DevOps team. As we add new services, it’s pretty straightforward to add them to our platform from a release perspective.

Later this year we are looking to add a service orchestrator tool with support for dynamic horizontal scaling. We are also currently augmenting our platform with centralized logging, metrics, and monitoring alerts. An additional piece of the puzzle is taking local development teams focused on bespoke applications for a single investment manager and incorporating them into a global development team building a single-purpose platform for the entire firm.

By utilising mircoservices with a common operating infrastructure, we envision a suite of services running in several tech platforms communicating over tech-agnostic APIs such as REST, Google Protobuf, and asynchronous interservice event communication.

Q: What technologies or techniques are you deploying at Man?

At Man we are not afraid to use open source libraries and tools. Micronaut has been on the scene only about 1.5 years now and we took a bit of a risk being one of the early adopters of the technology but it has worked out well so far. In terms of techniques, there are many aspects of our legacy platform that are highly proprietary and sophisticated which have been successful.

We will have some engineering challenges moving this functionality to a microservice. We also have a component built out in Python that needs to handle a fair amount of time-intensive requests from our main web application. Since Python does not natively support multithreading, we used the Celery protocol to run application requests in parallel to get the throughput we needed. Results from the service invocations are communicated back over a message queue.

Q: What tangible benefits have been realised since beginning to modernise the trading platform?

Since moving our new services into production, we can see the following tangible benefits coming to fruition:

• Removing technical debt – two of the services replaced legacy components running on an outdated scripting language which is a technology we no longer want to use or support;
• Service decoupling – if done correctly, each service should be designed such that it’s decoupled from other services and the monolith as much as possible. We have seen flexibility in our new Stock Locate service in that it can be easily adapted to communicate with other services even if those end up having major redesigns or refactorings;
• Deployment flexibility – Since each microservice has its own source code repository and back-end datastore, we can easily build and deploy just one service at almost anytime with no disruption to the production system. The monolith requires a full redeploy of the entire application each time along with an outage of the server for a few minutes, thereby disrupting end users. The monolith build also takes a long time to compile and run the automated test suite for the entire platform;
• Scalability – we can see that some of the legacy back end transaction contention has been reduced due to the fact each service does not have transactions spanning across service boundaries;
• Back end Datastore Flexibility – as a firm we support several RDBMS platforms and also a No SQL database with dedicated DBAs. As we build each service, we have the flexibility to choose the optimal back end;
• Service State Monitoring – each service registers itself to our service discovery engine and communicates its internal operational state such as UP / DOWN status, database connections, message broker connections, etc. so you have a full profile of the internal operational state of each service.

Back