Sector

Banking

Company

Creditas

Service

Cloud

Offering

Serverless Computing

One of the simplest benefits of cloud is that it reduces the amount of planning required. Gone are the days of 6 month purchase cycles of servers or one week lead time in case of urgency. Cloud has made procurement of servers a real time task. The response time of servers or computer capability can not only be real time but also in response to load.

While such capabilities are available in a traditional VM based approach, highly customized solutions that can respond to load on a per request basis are available as cloud native solutions.

There are two technologies available to provide compute on demand on cloud. The cloud native solution functions as a service (AWS Lambda or Azure Functions) and cloud agnostic solution (Docker / Kubernetes).

This article discussed the benefits, cautions of the first approach which we shall call the Lambda approach.

The Lambda approach essentially is a mechanism in which both code to be executed and the data are available to the compute engine. This is an extension of the functional programming concept usually seen in Lambda expressions (calculus) , a field or formal grammar.

This provides a very powerful, simple and computable framework. We define a lambda with its code and end point and consume it by invocation.

This makes Lambda

  • Stateless
  • Scalable
  • And an out of the box microservice architecture
  • Pay per use

This is different from a traditional solution where the state is in the hands of the developer. Microservices is an architectural consideration and scale requires planning. Cost of traditional virtual machine based solutions require costing based on uptime.

These systems can overwhelm underlying systems such as cache or databases and need proxy or throttling to ensure underlying systems are not overwhelmed. Vendors of such platforms provide essentially services to tackle such problems.

CreditAs a customer of Thotnr has a huge investment in AWS infrastructure. As a startup they had been cost conscious  and pragmatic about technology selection. This led to a traditional java application with cache and a DB.

Containers and Functions are two leading practices that enable serverless architecture. Each has merits. Both are mature techniques for architecting and deploying applications. If we are planning to be cloud agnostic, containers are a choice. With containers we get the additional benefit of packaging all dependencies. Containers however do not force you towards microservice architecture. Functions or Lambdas make consumer cloud dependent. They however lower cost of operations as the usage is per hit. However Functions need to be kept warm and have a cold start problem.

As the application’s grew the appetite to experiment also increased. Opportunities were discovered to build the next set of applications as spring boot microservices. While the logical architecture applications were microservices, hosting and physical application structure was out for debate. 

Pros and cons of Docker vs AWS Lambda were discussed. A critical architecture decision was agreed upon that whatever technique be used it must be deployable on traditional EC2 machines in case the solution fails.

The customer also wanted to reap the benefit of pay per request. This led to AWS Lambda being the choice of execution engine, however there remained one challenge: code should be deployable on standard EC2 instances and Lambda assuming we had an underlying JVM.

This meant we needed a mechanism by which we could host a spring boot application with the JVM of AWS Lambda. During the time of development of this solution the Spring bot Lambda adapter was not available (AWS Lambda – Spring Boot)

However there existed a solution called lambada. This allowed writing a traditional spring boot application and hosting it in an AWS lambda.

We had to still come up with solutions for cold start, throttling of requests but this had immense benefits, such as we would only open a write connection to the database if the request was not GET. GET requests would be routed to one of the read replicas of the DB providing us performance gain.

This was the first attempt the customer had with Lambda, costs were dramatically down and there was no vendor lock in. As the confidence in this technology increased, we made it a point to always use adapters to AWS lambda in other programming languages as we moved forward.

Cloud native technologies are lucrative but can lead to vendor lock in’s which can be more expensive than traditional vendor lock in for products because your entire infrastructure is controlled.

Containers and Functions are two leading practices that enable serverless architecture. Each has merits. Both are mature techniques for architecting and deploying applications. 

If we are planning to be cloud agnostic, containers are a choice. With containers we get the additional benefit of packaging all dependencies. Containers however do not force you towards microservice architecture. 

Functions or Lambdas make consumer cloud dependent. They however lower cost of operations as the usage is per hit. However Functions need to be kept warm and have a cold start problem.

Cloud native solution designs should always be done with this lockin possibility in mind to exploit the full benefit of the solution.

WORK WITH US

What’s Next for Your Business? We’re Here to Help you Achieve It.