In the webcast entitled “What's Better Than Microservices? Serverless Microservices,” Alan Williams (Autodesk), Asha Chakrabarty (Amazon) and Alan Ho (Apigee) discuss the architecture of a serverless microservice built with lambda functions with Apigee end-points running on AWS.
Serverless is a relatively novel architectural style in which the computing unit is not the virtual machine but rather a function encapsulating the code to be executed when an event takes place, said Chakrabarty. Williams noted the main attributes of the serverless computing model are: code focused, no server to manage, no EC2 instance to provision and administer, no manual scaling, no idle resources, no SSH or RDP.
The following graphic depicts the simplified architecture of a serverless microservice implemented by Autodesk (click on image to enlarge it):
The microservice has multiple entry points exposed as HTTP end-points managed by Apigee. The user makes an HTTP call, not knowing that the request is served by a serverless microservice. The microservice is composed from a number of lambda functions written in Python and communicating with each other through AWS SNS asynchronous notifications. The lambda functions are independent of each other and can be developed in different languages and maintained by different teams.
Since lambda functions are short-lived, they need to persist state somewhere, one of the options being DynamoDB tables. The access to these tables is controlled through IAM roles and restricted to only those functions that need read/write access to them. This avoids unneeded data exposure to certain lambda functions and lowers the attack surface of the microservice in case there is a security breach. Autodesk chose to store state in DynamoDB due to its simplicity, passing data as JSON, not having to administer a server instance and supporting automated scaling up.
The DynamoDB table at the bottom of the diagram (talr-taskstatus) persists the state from multiple lambda functions and generates streamed events when the table is modified. These events are monitored by another lambda function (talr-validator) which acts as necessary.
Regarding the benefits of implementing a serverless architecture on AWS, Williams mentioned:
- Agility. The implementation took only a few weeks
- No infrastructure to administer. No EC2 or ELB instances. No security patches
- Developers need to focus only on the code they write
- The ability to manage the code with the Serverless Framework
- The cost. In their experience, running the lambda solution costs a small fraction (~1%) of the traditional cloud approach. The costs are further reduced by not having to pay operational staff to set up and overview the EC2 and ELB instances.
Williams also mentioned that the serverless architecture is not good for running long-lived workloads or third party applications. In such a case, he said a container is more appropriate.
The session includes a demo on organizing the code, deploying and running it on AWS through the Serverless framework.