Clouds have become the standard for many online services. Now we are really moving to serverless services that offer many benefits over the traditional cloud server models. Serverless architecture can offer better use of resources, more cost-effective pricing and also better security against some threats.
There are, of course, still servers in serverless solutions. Serverless means dynamic allocation of server resources, i.e. we don’t need to pay or rent dedicated servers, but we buy computing capacity and we can use it based on our needs. These solutions are also called Function-as-a-Service, FaaS. Most leading cloud providers already offer serveless services, for example, AWS Lambda, Google Cloud Functions, IBM OpenWhisk, and Microsoft Azure Functions.
Serverless models also change software architecture. The microservices model means that each small task or job is a separate function that works independently. For example, in a finance service a KYC process (know-your-customer) can have an independent ID check, sanction list and anti-money laundering checks, so that all of them are independent functions that can run in parallel too (see an implementation example in the picture). This model enables the development of more independent functions by different developers and also makes it easier to debug smaller functions - and the same functionality can be then used for different services. Of course, starting and running many functions also creates some overhead, but it is quite small compared to the benefits. This doesn’t mean that all services need to become microservices, it is possible to also create functions that handle bigger tasks.
Serverless means that a service provider needs to pay only for the capacity actually used. This is especially valuable for services where capacity needs vary. Earlier a service needed capacity based on peak demand, but with serverless models the service pays for the functions executed in the cloud service. These solutions neither take resources for traditional server setup or management work.
The concept also makes it easier to implement API services that can process in the background and an API call doesn’t lock any other services. For example, a user can ask his / her investment portfolio details. The back office API replies immediately that it will be processed. The actual data then comes in several patches through webhooks to the front end. This can help also with blockchain implementations, when blockchain functions often don’t guarantee any latency time.
The serverless model works very well for many digital services, but of course, there are still some services where the traditional server model is faster and more cost-effective. For example, services that constantly require a lot of computing capacity are probably better to run in the traditional environment to avoid the overhead required to constantly start tasks when capacity is needed. When the load is easy to predict, it is also cost-effective to rent an optimal server capacity.
Most internet and mobile services have off-peak and on-peak periods. FinTech services are one example of those. If we think for example about payments, finance back office functions, and banking services, load needs vary a lot. They are also often critical services, i.e. they must work properly also during a peak demand.
Serverless solutions can also offer better security against some threats. For example, a serverless solution is more immune against denial of service (DoS) attacks, when the service is not dependent on certain servers. An attack can create additional costs, if it means a lot of capacity is used for in-coming requests, and attackers with massive capacity can target a whole cloud. Some serverless clouds (at least AWS Lambda) offer tools to require API key or authentication for a function. This means a DoS creates only API calls to the API gateway, but don’t start more processing - this eliminates the load and cost effects of DoS. The model also helps against attacks that compromise individual servers that are then used to attack further. Serverless also eliminates problems caused by unpatched server software.
This doesn’t mean all of this comes without any potential issues and security risks. Vulnerabilities in software and applications are still a risk. Serverless can also make traditional security monitoring more complex. As a whole we can conclude that serverless can help with security risks, but it also needs competence to manage vulnerabilities and a new kind of software and data architecture.
FinTech is a fast-growing service area that is also moving to clouds. This is a good timing also consider serverless solutions for finance applications, especially when they can also help with security. You can already develop a serverless payment solutions with Stripe. Crowd Valley is piloting serverless version of its finance back office as a service. US bank Capital One has been reported to be an AWS Lambda customer. Thomson Reuters and US finance industry self-regulator Finra also already use serverless solutions.
Serverless solutions will most probably come to dominate all event-based services. It fits well to financial services too, and timing with many other new things in finance is now good to make the transition. For example, the PSD2 regulation will open APIs to banking services and will significantly change finance services and their structures (read about old banking APIs). Serverless can offer a lot of value to create more cost effective and stable services, but of course they also need their own competencies to do it right.
This post originally appeared on Telecom Asia.
Est. 2009 Grow VC Group is the global leader of fintech innovations, digital and distributed finance services. Our mission is to make the finance services more effective, transparent and democratic. The Group includes leading fintech companies in their own areas.
Research Report 1/2017: Machines, Asia And Fintech:
Rise of Globalization and
Protectionism as a
Fintech Hybrid Finance Whitepaper
Fintech And Digital Finance Insight & Vision Whitepaper
Learn More About Our Companies: