Converting to AWS Serverless Architecture
We’re converting some of our internal apps to AWS’s Serverless architecture.
The application we use for recording flexitime accruals and claims is a simple .Net Core 2.x Web API application with a SQL Server database abstracted through Entity Framework. The lightweight user interface is written in React and Redux so we have a well-structured, clean front end. Design elements are enhanced by Google’s Material.io (a fantastic product in its own right!). All deployed into AWS Elastic Beanstalk.
On the whole, the app is more than fit for purpose – we especially like the UI- but we thought those simple REST Web APIs were a great match for converting to AWS lambda functions. In addition, the data requirements are really simple – so maybe a NoSQL backend would be a better match.
So, in our new world, the REST API Microservices are implemented using Amazon API Gateway and AWS Lambda functions. The Gateway provides the façade design pattern to the architecture - separating out the REST calls (represented by HTTP verb entities in the Gateway – for our Flexitime system think items like ‘TimeEntry’ and ‘TimeRequest’) to the underlying methods written as Lambda functions. This separation gives us a much more flexible architecture for future changes. In addition, AWS will automatically scale the lambda functions based on the number of requests. Previously entire instances of the web server needed to be created and load balanced, but with Lambda functions we have the flexibility to independently scale parts of the application that demand the most resources as well as being able to monitor and manage cost using the wealth of features in Amazon CloudWatch.
We found that the NoSQL approach of DynamoDB was a much better fit for our simple data set than the relational trappings of SQL Server. DynamoDB was easy to set up and has seamless integration with our Lambda methods.