eGlobalTech was contracted to support a federal customer with the development of a proof of concept replacement for a mission critical component that supports the alerting of the general public in times of emergency. The customer wanted to demonstrate the viability of moving this system to the cloud to achieve great availability, scalability, and reduced costs, but was also constrained by the license costs of the Oracle middleware used in the existing system. The customer engaged eGT to reengineer the solution to utilize native AWS services and open source software that eliminated the dependence upon the Oracle middleware.
Specific Business, Organizational, and Technical Challenges
The existing application architecture was driven and orchestrated by an Oracle technology stack, resulting in expensive licensing fees and reduced interoperability and flexibility for new components and microservices. eGT had no access to the Development environment and were unable to see how the various middleware components were configured. Because most of the deployment process was manual and the documentation was outdated, our team had to infer the communication between the various subsystems from analyzing the codebase. eGT had no ability to introduce changes to the existing system and this, coupled with the lack of a formal testing process significantly reduced our ability to perform side-by-side testing to ensure functional equivalence between implementations.
Given the original architecture was designed for on-premise operations, evaluating AWS cloud capabilities and services was the first step in architecting a successful proof of concept. Our team identified which cloud components required high throughput and light on computational needs and which were lighter in throughput and needed more compute power. Based on our analysis, we decided which of the system’s components were best served by EC2 instances and Lambda functions. The throughput and processing between the sub-systems also determined the method of connection (e.g. API call, SMS, etc.). Our team deployed the prototype using AWS Aurora to demonstrate a complete lift-and-shift to AWS that eliminated the dependence upon Oracle databases and services.
Our team chose compute optimized EC2 instances for the CAP Aggregator Messaging Service and the CMAC Messaging Service as the flow of traffic to and from those components is light and they perform many tasks which require a high CPU compute time. Our team leveraged Lambda for the dissemination sub-systems such as EAS, Workflow Service, Transformation Service and dispatcher interfaces. This decision was based on the high fluctuation of traffic and the small footprint of the applications themselves. Being lightweight applications, we were able to show that using Lambda fronted by API Gateway, the requests, no matter the amount, saw a consistently fast response time. Within the previous, on-premise environment, these services presented substantial issues due to the lack of scalability.
For file and object storage, our team leveraged Elastic Block Storage (EBS) and S3, respectively. We performed a hybrid implementation of the systems EAS component which provides data in RSS format for the public and any entities (other than mobile carriers and other agencies with direct interfaces) interested in alerts. EAS presents either a list of all the active alerts or the user can request specific date/time or geographic boundaries to query for specific alerts. Since most of the requests tend to be for the entire list of active alerts, we implemented a job to update this list of active alerts in S3 whenever new ones are posted so that the Lambda function did not have to be invoked for such a simple request that does not require any compute time. API Gateway is configured to route this request to either S3 or Lambda depending on the type of request is made by the user. For database and relational data storage, our team leveraged AWS Aurora. Aurora enabled us to migrate all relational and transactional data from Oracle with minimal reconfiguration and no changes to the database schemas.
The prototype was a success in proving that the customer’s mission critical system can be moved to AWS while reducing licensing and maintenance costs. The prototype also showed that the Oracle database and middleware can be safely replaced with open source alternatives and available AWS services, making the system architecture interoperable and flexible as requirements evolve over time. With the successful completion of this project we were able to demonstrate to the customer that an AWS deployment reduced cost and risk while improving fault tolerance, scalability, and throughput of all mission critical system services.
Moving an application from using an Oracle database to MySQL or PostgreSQL is achievable with minimal effort. If in use, functions will need to be renamed to their counterparts for the target database type. For geospatial use there are some differences in computation but those also translate into identical functionality in PostgreSQL/PostGIS. The functionality of Oracle BPEL or ESB components can be relegated to a different technology (as prototyped with Lambda in the case of the customer’s mission critical system).
When modernizing applications for deployment to the cloud, focus should also be given to dependencies such as libraries and dependency management. Some libraries may no longer be available in repositories, making deployment automation difficult and may present security risks which could result in delays. Monolithic applications can be made more scalable using microservices. Legacy services can be migrated to microservices in real-time using the Strangler pattern approach. Introducing dependency management (such as Maven for Java applications) into the system being transitioned provides a good way of ensuring decommissioned libraries and frameworks are upgraded, which results in more visibility into the versions used. Additionally, Maven makes it easier to use plugins to share JAR files (necessary for Lambda deployments of Java applications), generate code and perform dependency analysis. We also determined that heavyweight Inversion of Control (IoC)/Dependency Injection (DI) frameworks such as Spring in enterprise Java applications should be replaced by more lightweight libraries when in use with microservices.