Trading System @ Cloud : The Migration
Last couple of years, staring from 2018, it was all about migrating applications to cloud. On year 2020, it got special focus. I have seen various approach to move Trading Systems to cloud. It mainly depends on few factors like, how much deep is your pocket, maturity of the platform, and last but not the least, correct direction from the Technology Leadership.
In this article I’ll discuss about some of the common cloud migration approach for Trading / Financial applications, and their pros and cons.
Lift and Shift
Take your whole landscape, and start recreating it in cloud. Standing up VM instances, installing required software, deploy your application, and here you go. One of the common practice is to move DR site to cloud through this approach, that gives direct cost benefits. Maintaining a Cold DR environment on cloud is “normally” cheaper.
Pros :
- Very little intervention from existing application team.
- If application is designed well, and can scale horizontally with very little to no effort, VM based environment provides good scalability. Through proper auto scaling strategy in place, overall hardware cost can be reduced.
- Can be started as parallel, infrastructure / new DR site work.
- If it is a new DR site, and it is cold, using smart resource optimization technics of any standard cloud environment, drastic cost reduction is possible comparing to standard data centers.
- Once your application moved into cloud, you have a new horizon to explore, any new changes / refactoring can be done using cloud native technologies.
- Testing effort is minimal.
Cons :
- As no code change involved in this approach, most of the time, middleware and DB need to be hosted through VM, which leads to extra licensing cost.
- Support team need to be familiar with Cloud Monitoring methodologies.
In my experience, this is one of the quickest approach to cloud. Organization will start seeing the cost benefit, and application / development team will get time to adopt cloud based resources.
Ship them in Container
This approach, needs little bit of thorough planning. It also depends on existing Technology stack as well. If applications are running on container friendly tech stack e.g. Java, Python, .Net Core, Go, C++ etc, containerize your application and push them to cloud. Organization can build a central team, which can standardize approach and define methodologies to containerize applications. Then this central team can take ownership of the application code, containerize it and give it back to application team. Application team will start owning the containerize code at on prem, when cloud is ready with other dependencies, app team will push those containers to cloud.
Pros :
- This approach will make applications Cloud Native, and you are not binding yourself to any particular cloud provider.
- With very low cost, huge amount of horizontal scaling can be achieved.
- Application will achieve next level of maturity through this process.
Cons :
- Normally Trading systems are middleware heavy, those need to be moved as is, hence extra license cost. Changing middleware will lead to bigger code change.
- Considerable amount of testing effort, maturity of regression testing is must before taking this approach.
Not a feasible approach if application is DB heavy.
Made in Cloud
Most pure approach, if timeline and effort are not a problem. If you get a liberty of green field development, where you can start building your Trading Application from scratch, this should be your approach. Picking up all sort of serverless technologies, and choosing most cost effective and scalable set of compute and storage resources one can achieve the future proof architecture.
Pros :
- Best of the breed architecture can be achieved.
- Most cost effective implementation.
- Availability and Scalability of the system will be at its best.
Cons :
- This is almost rewriting all of your application, multi year planning and funding is required.
- Complete regression testing of entire application could be a nightmare.
If you are writing a new integration, or onboarding a new product, then this approach can be taken for fresh development. Your new application will be future ready and can be integrated easily once all other pieces start getting migrated to cloud.
