Accelerate Adoption of Microservices with Serverless

In this video Kai Nofkem, Software Architect at Carana Software Solutions, explains Cloud Native messaging utilizing Amazon SNS (Simple Notification Service) and Amazon SQS (Simple Queue Service).

At 0:27 Kai begins by stating that Carano is a building based company with about 25 years of experience in fleet management like instant car-sharing, adding that today their customers manage around 200,000 vehicles using Carona’s application.

At 0:47 he explains that most of their business applications currently run on-premise and Carona Cloud is their first venture adopting Cloud Native software development practices, with the reasoning that time to market was the driving force as increasing competition required a faster release cycle.

Microservices architecture

At 1:18 Kai begins to explain their microservices-based architecture. The primary application that users interact with is hosted on S3 and all requests are handled through the API gateway.

At 1:39 he elaborates that behind the gateway, there are two major types of services namely the Kotlin based services with the world text toolkit which run inside the docker containers on ECS.

At 1:48 he explains the second type, Lambda serverless functions which are written in typescript. Their goal was greater developer flexibility, not being tied to one particular language or method, and also through the API gateway decoupling the services.

At 2:37 he briefs that due to the decoupling of the client’s form services, a great level of flexibility was achieved. He elaborates that now it is possible to choose a technology-specific solution for the problem at hand.

From 2:45 they explore the use of JMS (Java Message Service) and problems they had with its implementation, notably that they started with ActiveMQ but being JVM (Java Virtual Machine) based only this conflicted with their goal of flexibility, and there was a need to manage the broker ourselves, having to spin up an EC2 instance, provision all the required infrastructure and they also ran into scaling issues.

SNS and SQS services

At 3:40 he concludes that due to these drawbacks the solution opted for was AWS SNS and SQS and begins to explain their implementation.

Kai explains that the messages are sent to the SNS topics to fan out the message and that the subscribers of these topics aren’t services, instead, they are the SQS queues.

At 4:30 he puts forward the idea that only the first instance which receives the message would process it which eventually ensures that the messages are processed only once.per service type, adding on that the messages can still be delivered to the different types of services. At 4:56, he states that before the messages were switched to the SQS and SNS, the Lambda functions used to be hooked to the API gateway directly.

At 5.10 Kai states that the concept of SNS and SQS in their microservices architecture enables the software developers to write more Lambda functions.

In this video Kai clearly emphasizes how the change to the SNS and SQS enabled the team to embrace the microservice architecture and also helped in integrating the serverless functions with the already existing container-based solutions.