Scalability for Small Teams: FinTech Startup Guide
Interview with Alan Illing, CTO at Bridge Financial Technology
Does it seem real for a small development team to benefit from implementing microservices? Universally, microservices are applied to projects with big or heavily distributed teams. It allows them to parallelize processes and establish a smooth workflow. In small teams, however, monolithic architecture is used more often as it allows to go faster.
Alan Illing, CTO at Bridge Financial Technology, rules the project with microservices architecture and only 11 employees in a team. I was invited to Bridge FT’s office, which overlooks Lake Michigan, for a chat with Alan. He shared what it took him to scale the product and team ‘on wheels’.
Bridge Portfolio was primarily a consulting company, effectively the back office operations for some very large RIAs. The owner essentially wanted to get out of—he got to the point where he couldn’t really see the business growing any more. Alan with his friends bought this company in 2016 and completely revamped it from the inside out, taking the 15 onboard clients to over 200.
As CTO, Alan is oriented towards optimizing and improving the software. His focus is transitioning from monolithic software to microservices. This is advantageous for managing and updating software, and some microservices may end up being separate enterprise products in and of themselves.
Bridge FT’s back-end is written in Python, with the front-end in Angular, and it runs on AWS. Alan decided to transfer everything onto the cloud in Docker containers, and the platform runs on ECS behind an elastic load balancer. In the future, Alan says, they have adopted Go for their API.
Alan chose PostgreSQL for database management, with plans to migrate to Amazon’s new Aurora database system. Amazon Aurora is a MySQL- and PostgreSQL- compatible relational cloud database that combines the performance and availability of high-end commercial databases with the simplicity and cost-effectiveness of open source databases.
“Aurora coupled with stream processing will be game-changers for Bridge’s ability to scale and ingest data at any time from any source.”
Managing and enlarging team
Bridge FT is in a startup-esque mode at the moment, with 11 employees based in Chicago. Absent a product department at this stage in their upward trajectory, they only have three departments: sales and marketing, engineering, and operations. At the end of every two-week sprint the engineering team holds a tech meeting, and halfway through each sprint the entire company holds a product meeting.
“During the product meetings, everybody chips in with notes and feedback. We’re always trying to find a balance between what our existing customers are saying and what prospects are saying. Why are we losing a deal? What are clients saying? Where are the biggest opportunities?”
A question I’ve always been interested in is how (or whether) FinTech companies educate their developers about finance. Alan is working hard to make sure their in-house knowledge is top notch. Bridge FT’s staff includes CPAs, CFAs, and former financial advisors.
In order to keep everything running smoothly, the entire team has access to Guru, a knowledge-base platform. Guru has a concept called “stale knowledge,” where a person can create a card, put some content in it, and mark that card if the knowledge is likely to change or needs updates.
“If one were to look at Bridge FT’s Slack channels, one would see people asking each other questions and other people linking articles and information seamlessly through Guru.”
Depending on the settings in Guru, the platform will notify the card owner either through email or Slack, which is integrated with Guru.