Challenge Overview
Project overview
Currently, the client's micro-services run on EC2 instances. This is working, but the performance and scaling is tough to manage, especially at certain times of the year when demand spikes. What the client is requesting is that we convert the APIs to run as AWS lambda functions, instead of APIs deployed to EC2 instances.This challenge will convert a group of client APIs to Lambdas. The approach is to run express in the lambda, meaning that this effort is mostly deployment related - just ensuring that we get the setup right. The actual code won't have to change much.
Technology
- All APIs will target Node 12+. NOTE: The enrollment-api project has only been tested up to Node 8, so we'll want to validate that it runs properly in Node 12.
- MySQL
Project goal
The goal is that the APIs will remain the same, working the same, but as AWS lambdas running express. This will allow the client to better scale the APIs up and down for demand.Requirements
Documentation
You should look at each of the APIs and convert it to an AWS lambda, ensuring that the API works the same before and after the conversion.Database connection
The APIs current use a shared connection pool for multiple DB requests. The client has stated that anything declared outside the event handler is shared accross the instances. Short term, we would like to put the connection pooling code outside of the handler, which should share across the lambda instances.Database credentials
Currently, the database credential retrieval logic lies the source code. The client has stated that it's not coding best practice, but they would like to leave this as-is as it should still function the way it's currently codedPort
Currently, the services tend to use port 3000. This can be changed to work with AWS Lambda, if required. Please just make sure to document this change in your README.Authentication / Authorization
In the previous analysis, we mentioned that all api services are tightly coupled with jwtLib for api authentication and authorization. The client has stated that changing this can be out of scopePerformance
In the previous analysis, we mentioned that booting up express server on demand could have performance hit to api calls. The client has stated that they are going to use logic to keep a number of lambda instances "warm", so that performance won't suffer greatly.Deployment and configuration
Cloud formation will be used. A template will be provided in the forum, but we need to look this over and document any specific requirements for future challenges to ensure consistency between the APIsThe client will be using an API gateway, which routes to the lambda running a full express application which handles the request(s)
CORS
CORS was earmarked as a potential issue with converting to AWS lambdas. Please outline any specfic CORS changes that may be needed, in the README.md, so that the code functions the same, keeping in mind the deployment through the API gateway detailed above.Unit tests
The client has stated that unit tests are out of scope for this conversionRequired services
These 3 services are in scope for this challenge (links will be provided in the forum):- Event API
- Producer API
- Product API
- Consumer API
Tech stack and information from the client
This was provided by the client about the tech stack and potential items to look at:- MYSQL Aurora 5.7 (current size TBs they think- over 100 tables- MASSIVE)
- https://docs.aws.amazon.com/lambda/latest/dg/gettingstarted-limits.html
- For Lambda the client is wanting the max number of instances to be 30-40
- If we get 1000 requests we have to have correct concurrency to avoid overloading the backend- want to avoid overloading the DB
Submission requirements:
Submit these files:
- Converted code
- Filled in cloud formation template for deployment and configuration
- README.md for deployment of the code *before* and *after* the conversion, to allow for comparison
- Validation.md for testing the code *before* and *after* the conversion to ensure it works the same