HSBC: Using Serverless at Scale in Banking
Building a scalable, elastic platform while maintaining bank-grade security.
In this video Mr. Srimanth Rudraraju, the lead digital solutions architect of the renowned HSBC bank explains the use of serverless schemes at scale in the banking domain.
At 0:21, Mr. Srimanth points out that HSBC is one of the world’s largest banks and stands 7th in terms of the market assets and the capitalization. At 0:30 Simon Elisha puts forward the important question of how the scalability challenges can be resolved with the architecture.
At 0:32 Mr. Srimanth begins to answer to the scaling challenge problem by stating that when the applications are deployed and busted, there is a high probability that the company runs out of the IP addresses and the infrastructures.
At 0:47 he states that to resolve this issue, at HSBC a smaller CIDR (Classless Inter-Domain Routing) block and a larger CIDR block is created in two different VPC’s (Virtual Private Connections). A simple VPC could have been possible but again the problem of scaling would have arrived, as every time the network is scaled, a lot more IP addresses are needed. At 1:17, he puts forward the idea that has been implemented by HSBC bank wherein the smaller CIDR block is arranged with a set of proxies and the larger CIDR block with a set of lambdas within the larger VPC.
At 1:30 Mr. Srimanth begins to explain the workflow of how the scaling is managed elegantly even if there are a lot of clusters, Kinesis is present. He states that at HSBC slash 16 IP addresses have been created which would provide 65,000 IP addresses. He further adds on that if any service desire to connect back to the bank, foremost connect to the private VPC Endpoint, the endpoint then connects to the proxies which are then connected through direct connections to the bank.
At 2:05 he explains that when the 65,000 IP addresses get exhausted, another VPC is created and connected to the proxies. By doing this, scaling can be done in a very efficient manner. At 2:25 Mr. Srimanth provides more details by stating that the proxies are controlled by the separate security team that whitelists all domains that can communicate to. He adds on that the reversal operation can be possible here where the entire information flows from the lambdas to the VPC endpoint to the proxies to the internet gateway which talks out.
At 2:44 he puts forward the example of the push notification where the service can communicate. He summarizes that a very distinct advantage of this approach is that in general, not very service would have a VPC endpoint within an AWS. At 3:06 he says that this pattern could be implemented in order to whitelist the AWS services required on the proxies. This approach would ensure that the connection is still private and remain not connected to the internet.
At 3:20 he tells this approach has ensured that security is maintained at the HSBC bank and the scalability issues are also resolved. He states that firstly, the network is configured, the CIDR blocks are done along with the plumbing work.
The second terraform script would build the infrastructure while the third does the deployment of the code on the built infrastructure. At 3:44 he adds on that by this approach it means the build is done once and then the code is completely promoted. This has ultimately ensured that the market demands can be reached in a rapid manner with this approach to the architecture to overcome the scaling challenge.