Time is precious when running a small business. Jobmate's vision is to help their clients become more profitable and efficient by automating the administrative and operational tasks every small business has. The UK startup aims to launch its flagship product in the 4th quarter of 2020, enabling clients to easily manage their diary, tasks, resources, quotes, expenses and all the other requirements of running a business.
Any new product brings with it a number of unknowns. In terms of infrastructure, the unknowns include the daily connection rate, the maximum connection rate per second, the number of nanoservices that will be launched, will the system be read-heavy or write-heavy, the caching ratio on the CDN, etc, etc. There is very little chance of accurately predicting any of the metrics associated with such products, since no previous data exists. Let's also not forget that over provisioning is not an option as hosting costs need to be kept at a minimum.
Jobmate and 56Bit, decided to solve this issue by eliminating the need to do any significant predictions in the first place. By using AWS's very mature, and ever growing portfolio of Serverless products we were able to provide a highly redundant, scalable and secure system whilst fully controlling costs.
After evaluating various options, AWS was chosen as the public cloud provider of choice. The reason was not just based on costs, which were considerably less when compared like with like, but also the maturity, scalability potential and unparalleled feature set provided by the AWS service portfolio.
56Bit provides peace of mind to technology-driven business through best-in- class cloud solutions. Jobmate, whose core business is totally dependent on the underlying technology required an experienced partner with profound knowledge on serverless technologies that could deliver a high-quality service on time and within budget. Jobmate teamed up with 56Bit to consult, design, build and maintain this platform, working hand-in-hand with the software development team.
The solution is based on the AWS Well-Architected Framework and includes the following components:
Amazon Cognito serves as the Authentication as a Service (AaaS) of choice for user administration, and complex authentication flows.
Multiple REST and Websocket Amazon API Gateways, with multiple regional and global (i.e. using a CDN) endpoints, as well as multiple custom domain names. Integration with Amazon Cognito ensures users can only access the endpoints they should be accessing whilst having a secure unique user identifier as part of the authentication token.
AWS Lambda, using .Net Core 3.1 is used to build the backend logic. All functions, connected to VPCs, are run on multiple AZs to ensure high availability and maximum scalability. Multiple lambda functions are also used for internal tasks such as Development and Staging environment switch on and off which is key to reducing costs.
Amazon DocumentDB (with MongoDB compatibility) was chosen to host a fully managed cluster of MongoDB servers on multiple availability zones.
Amazon S3 is used as a static file storage system. Considering it was designed with 99.99% availability and 99.999999999% (that's 11 x 9s!) durability, the decision was easy. Multiple buckets, some fronted by the Amazon Cloudfront CDN are used for front-end hosting (React.js), as well as private user storage, logging and code archiving.
The system uses multiple AWS accounts, one for each of the Development, Staging and Production environments. Another account acts as the master account with centralized billing, DNS, Single-Sign On, etc. Finally 2 accounts are used for security logging, with one account acting as a black hole (i.e. an immutable highly secure dump of security logs) and another acting as a single pane of glass for everything security related. Security logging is handled using AWS Config, AWS Cloudwatch and AWS Cloudtrail.
The above accounts are provisioned using AWS Control Tower, which creates the AWS Organization, an SSO entry point, an AWS Account factory (using AWS Service Catalog), as well as a number of Guardrails to protect the accounts from unintended changes. All management users are assigned MFA-backed credentials onto the SSO endpoint which in turn provides role-based temporary access to the different accounts.
All system components are deployed in private VPCs
Non-public S3 buckets are encrypted with strong cryptographic keys (AES256) managed by AWS KMS. All data is encrypted at rest and in transit with TLS-enabled network protocols. Even the backups and its transfer to a second physical location are encrypted. All secrets like database passwords are stored in a highly available and secure secrets vault provided by AWS Secrets Manager. PKI Certificates are provisioned using AWS Certificate Manager.
The infrastructure was fully built using CloudFormation, which is released using a CI/CD pipeline built on top of the AWS Code family of products (Codecommit, Codebuild, Codepipeline).
This Infrastructure as Code passes through the full commit-build-test-deploy lifecycle, incorporating the development, staging and production environments. The backend and frontend code bases also pass through multiple CI/CD pipelines, built using similar infrastructure.
Environment separation is implemented by using completely independent VPCs in different AWS accounts. New releases can always be tested in a staging environment, where unit and integration tests along with load and stress tests can be conducted by the same testing suite. This mitigates the risk of unexpected functional changes and performance degradation. The master account serves as a CI/CD single pane of glass for the teams working on the project, whilst cross-account IAM roles enable the pipelines to test, build and deploy code in different AWS accounts.
Whilst the system is already highly-available, since everything runs in multiple AZs, this can be improved further with a cross-region solution. It will not be very hard to move to another region, since everything is implemented using IaC.
At the moment we do not envisage the need for database caching, but a database caching layer can easily be spun up using AWS Elasticache (Redis) to add a very fast caching layer between the Lambda compute and the DocumentDB database. This will increase performance, reduce database hosting costs and decouple the architecture even further.
Whilst lambda is very scalable, the soft limits related to concurrency need to be taken into consideration when building such a system. Same with the instance sizes for the DocumentDB cluster. Metrics and alarms are set up for all of these so we can action them accordingly well before the system's performance is affected.