Optimizing Performance, Moving Beyond Servers
As one of the largest publicly traded organizations in the Netherlands, it is essential that PostNL controls its IT processes in a demonstrable and transparent manner. Their Compliance and Audit departments establish internal rules to ensure policies regarding privacy and permission are applied and followed. Many of these controls facilitate Identity and Access Management (IAM) of applications used internally at PostNL, in order to prevent unauthorized access to any application.
PostNL – Improving TIAMA Performance
A few years ago, an application ‘TIAMA’ was developed to enable other applications to make sure and demonstrate that the IAM is standard procedure. TIAMA consists of a ‘back end’, where data about users and roles from other applications enters and is processed, and a ‘front end’: a website where application administrators can perform actions and download reports. The application runs on EC2 servers in an AWS environment managed by an external party. Furthermore, it uses the Elastic stack, with Elasticsearch as the document database and Kibana for visualizations.
This assignment focused on two problems faced by TIAMA. The first problem was that TIAMA’s website sometimes underperformed when downloading reports. Some reports require a large amount of data processing to generate a report. At peak times, the website would slow, freeze, or crash when a report was generated.
The second issue was that TIAMA did not meet PostNL’s preferred architecture for running serverless services. TIAMA required AWS EC2 servers, using IAAS, which involved permanently renting a (semi-)managed server. This meant extra cost for those servers, even when no one was using the website and no ETL processes were running. The major cloud providers also offer serverless services, where the provider manages all the servers and only requires a fee whenever the services are actually used. PostNL has a clear preference for using serverless solutions with flexible costs instead of fixed prices.
The goal of this project was to solve the performance problems by using serverless services and pave the way towards a serverless architecture within AWS.
The Road to a Proof of Concept
The following roadmap was formulated as an approach:
1. Identify the exact cause of the performance problems.
2. Review AWS services to select services with the potential to solve the performance problem.
3. Create an architectural design using the selected service(s) that describes the integration between the existing application and the selected service(s).
4. Discuss the design with the TIAMA team, the architecture department at PostNL and within Aurai.
5. Create a Proof of Concept starting with the agreed-upon design choices.
6. Evaluate Proof of Concept and make the final decision on implementation in consultation with stakeholders.
7. Engineer the solution and integrate it into the existing application.
Technology to Enable ‘Serverless’ Service
After a number of tests in the initial phase, it was determined that the high CPU load on the EC2 server was creating the problem when retrieving reports. We could have quickly and easily scaled up the old EC2 server, but apart from the relatively high cost, this option did not satisfy the preference for serverless services. When oriented to other AWS services, AWS Lambda proved to be a better candidate. This serverless service could execute a segment of proprietary code on demand, while only paying for the code’s execution time. With an Amazon API Gateway interface, The service is also easy to use and simple to integrate with other AWS services. Furthermore, the service is highly scalable; with the capacity to process simultaneous requests, the code can be executed multiple times in parallel.
After weighing the pros and cons with the team, an architectural design was made based on AWS Lambda. We built a Proof of Concept demonstrating that the report generation could be carried out successfully in AWS Lambda and that the CPU load on the EC2 would no longer show spikes or crashes when creating reports. After approval, the Proof of Concept was built out into a full solution and integrated into the existing application.
Instant Report Delivery
The new solution migrated the report generation to an AWS Lambda function which eliminated this task from the overburdened EC2 server. When a report request is made on the website, the web application forwards this request to an API endpoint from the Amazon API Gateway. This API triggers the Lambda function and forwards the input so that it will generate the report with data using Elasticsearch. When the report is ready, it is placed in an S3 bucket and the end user can download this file from the website. The solution solves the performance problem and uses a scalable, easily managed serverless service at very little additional cost. With the project goal achieved, PostNL can consider moving more tasks to serverless services