Trading Apps is known for delivering first-class frontend functionality with high-touch customer support. Historically it was an on-premise solution resulting in high internal costs to install and support the hardware which made the overall implementation an expensive option. I can recall countless times that a prospective client has said “it’s great but it’s expensive!”. It was therefore a key focus for the new management team to consider how to reduce the overall cost to the customer. The team applied their knowledge to create the optimal IT infrastructure to deliver the same quality of product but at a more competitive cost.
Like other smaller software providers and startups, Trading Apps started with a monolithic application as this was the simpler, quicker, and cheaper way to create and deploy an on-premise application. Although the application was a monolith it was well-architected with multiple tiers and those tiers had loosely coupled components and libraries. As the functionality expanded and the customer base grew, Trading Apps recognised that to improve stability and scalability, they needed to migrate to a more flexible approach. The company chose the microservices architecture as the means to achieve this. Microservices are self-contained applications that can be developed and deployed individually. Setting up a network of these services allows for agile development, shorter release cycles, and faster time-to-market.
Microservices are sexy and a hot trend right now and this model is adopted by some of the largest providers such as Amazon and Netflix, and who are we to argue with them.
Of course, Trading Apps does not have thousands and thousands of microservices like these companies as it does not have the same requirements or workload. What it does have is the correct organisational structure to succeed. Trading Apps has always adopted a cross-functional team which allows it to pull on the broad expertise of its people, which is essential when implementing microservices. What it did need to do, however, was ensure it had the right infrastructure and tools in place to orchestrate and monitor the different microservices it created, as this architecture has drawbacks given the complexity surrounding managing distributed applications.
The transition began with evaluating and choosing the most appropriate technologies for developing microservices that would enable the evolution of the monolithic architecture. For example, the interprocess communications mechanism used between services is a key part of the toolchain and Trading Apps chose gRPC. Trading Apps also decided to concentrate its development using two programming languages C++ and Java. This approach provides us with the ability to reuse stable functionality already deployed in Production but also the ability to mix that with microservices that use modern Java libraries (Microsoft Graph Java SDK is an example of this).
The monolith transition plan, which is underway, can be configured in a certain way to meet a customer need. For example, if a customer has particular highvolume reporting requirements, we can use a cluster of data aggregation microservices to meet that need. Trading Apps has already introduced microservices for additional functionality for connectivity to NGT, Bloomberg, IHS Markit, and Microsoft 365. Next, the remaining parts of the monolith will be split into separate microservices providing trade maintenance/ lifecycle and data analysis, thereby allowing us to scale the data analysis microservice containers independently from the trade lifecycle microservice. This is more cost-effective as resources are only allocated where needed.
The advantages of this approach are clear. If there is a failure of a single module the larger application is more resilient to failure. Additionally, it allows for smaller codebases and scope which translates to quicker builds and faster deployment, with a view in the longer term to transitioning to continuous deployment and serverless computer where it makes sense to do so.
This approach can present new challenges. This change in architecture will increase the complexity of communication between the services and remote calls could experience latency. Furthermore, testing becomes more intricate as, unlike a monolithic approach whereby just one application needs testing, with microservices each dependent service needs to be considered before testing can occur. Also, the system now has multiple data repositories which require more resources and finding fixes for bugs can be more cumbersome as you have multiple logs to review (mitigated by using centralised log consolidation). And, finally, the actual deployment of the system may be different depending on the services the customer has.
These challenges apply to all microservices-based architectures and can be managed with the correct tools and staff experience. But, the most efficient way to mitigate them is to employ software-as-a-service (SaaS), whereby Trading Apps provides customers access to applications that reside on a remote cloud network, accessed through a secure VPN or leased line. Our move to microservices combined with feedback from prospective customers, who were striving to transform the management of IT to maximise business value, was forefront in our minds when we debated the optimal IT deployment solution for Trading Apps.
When I first joined Trading Apps in early 2015 it only offered a traditional model of delivery, where software was installed on-premise. This approach has several drawbacks for the customer and Trading Apps. As each customer represents a separate installation it carries a high cost for us which ultimately is reflected in the cost to the customer, thereby potentially making Trading Apps appear expensive in comparison to its peers. For the customer, it lengthens the implementation process as it requires the internal IT department to be fully engaged and understand the hardware requirements, to build multiple environments for production, DR, user acceptance testing (UAT), etc, install the application and configure it.
So, in addition to licence fees customers incur ongoing internal maintenance expenses associated with onpremise hardware and software. Furthermore, the customer takes the responsibility for operating the hardware and software, rightsizing the microservice containers to the load, upgrading operating systems, patching security vulnerabilities, patching and configuration, all of which require employing a dedicated application team.
This did not sit well with us as the task of maintaining functionality and performance is transferred to the customer. Therefore, the responsibility for ensuring that timely software updates and data backups are done to prevent downtime, service interruption and any other operational issues reside with the customer.
This led us to explore SaaS, whereby Trading Apps provide customers access to applications that reside on a remote cloud network, accessed through the web. The things which were important when evaluating cloud providers were availability, compatibility, reliability, scalability, performance, and security, among other things. Previous experience of hosting our volume testing environment and discussion with providers helped us to realise our requirements were for an infrastructure provider, not simply a server hosting company.
AWS provides the breadth of services with a flexible, cost-effective charging model. Its self-service approach to the construction of virtual private clouds and all the components within was a good fit with the existing skills set within Trading Apps. The benefits of this decision are still being felt as we can make use of AWS artificial intelligence and machine learning services such as SageMaker from within our existing private cloud environments.
AWS managed services mitigate many of the complexities surrounding managing distributed applications. The Amazon Elastic Container Service, for example, allows us to manage a cluster of microservice instances. Additionally, Relational Database Service (RDS) or serverless databases reduces the management and maintenance overhead of running replicated databases. We also chose to use an infrastructure-as-code model to allow us to easily replicate environments in development and QA which mirror the structure of our customers’ production environment.
Trading Apps has always taken IT security seriously and been aware of software supply chain risk. For instance, we have been a customer of Veracode and used its security-focused static code analysis since 2013. However, with the migration to SaaS and the storage of customer production data we have redefined our cybersecurity strategy. For example, we use endpoint security products from companies to protect against malware infection and follow the principle of least privilege. Our security vulnerability and patching policy is driven by continual scans of devices from both within and outside of the network. We use an industry-leading security information and event management (SIEM) platform to monitor assets both on-premise and within the cloud (both AWS and Azure). This provides a single pane of glass visibility of indications of compromise and enables us to implement the Mitre Att&ck framework to defend against bad actors.
Besides the speed of implementation, the SaaS model provides significant advantages for our customers and results in considerable cost savings. There are no high up-front costs, and it allows our customers the ability to scale. Trading Apps monitors the applications with various metrics to enable us to increase capacity as required, so customers can add further functionality quickly and easily so the growing needs of their business can be met without having to buy new hardware or secure budget for internal IT assistance. Support is significantly improved as data is stored in an external data centre so logs and performance metric data is immediately available resulting in easier bug identification and quicker fix builds and deployment.
Furthermore, within the SaaS environment customers have at least one UAT environment which mirrors the production setup, so it is easier to test both functionality and performance. And lastly, version upgrades are managed by Trading Apps translating to lower effort and costs compared to the traditional on-premise model. Although Trading Apps does not have any comparative cost data yet, it is reported that organisations that upgrade from on-premise to cloud financials save up to 21 per cent in IT spend (Oracle Netsuite).
There are also additional advantages for Trading Apps. We can now scale the customer base by offering new products like TA Link to non-Trading Apps clients. Moreover, AWS allows the automatic flexibility to scale or shrink SaaS use based on its specific needs, which allows Trading Apps to do efficient server capacity planning and control costs. The final benefit for Trading Apps is the ability to capture data and analytics more easily as the information is found in a centralised location. It can therefore create structured or semi-structured data which can be applied to the tasks that machines execute. This creates the foundation block for developing machine learning applications, such as identifying rate anomalies in the data flowing through TA Link or our automation apps and allowing the machine to adjust rates offered in real-time. Additionally, there is increasing focus on reducing carbon footprints and being energy and resource-efficient within our customer base, and SaaS is seen as less environmentally impactful vs. on-premise solutions.
Introducing a SaaS model coupled with our microservice architecture is proving transformational for Trading Apps. We have significantly reduced the implementation costs and time to benefit our customers and real-time monitoring and automation can identify and resolve issues before they impact a customer or end-user. Our SaaS offering combined with microservices provides our customers with the ability to scale without the need for further hardware costs and ongoing maintenance costs. All these factors translate to Trading Apps being more competitive in terms of functionality and cost versus our peers. Say hello to potential!
