AWS Evolution At Enova
Enova has a long history of hosting our own infrastructure in our own datacenters. Five years ago, we started thinking about how we would approach cloud technologies, specifically how the cloud would benefit Enova. After deciding that Amazon Web Services (AWS) was the cloud we wanted to use, the challenge became “how”. One path of cloud adoption is the lift-and-shift approach of moving data centers fully to the cloud as-is. For reasons including our datacenter refresh timeline, application design, data patterns, we decided the lift-and-shift approach was not the right approach for Enova. Instead we approached the cloud with an evolutionary mindset – we would leverage the cloud to fill in gaps in existing application platforms, move resources closer to our customers; and focus on building new services as cloud-native services. This post gives an overview of this evolutionary approach that Enova is taking with AWS.
Development and Testing
The first environment we built out in AWS focused on providing developer and testing instances. The primary reason for this move was the ability to scale to meet the growth of our engineering team and allow experimentation. All the infrastructure used to perform tests and checks on every pull-request runs fully in AWS, auto-scaling based upon the demand and number of tests in the backlog. We also provide our developers the option to launch ephemeral developer machines to develop, test, and demonstrate features to stakeholders.
Filling in the Gaps
Another common AWS usage pattern at Enova is replacing datacenter infrastructure with AWS-provided services. The first service we replaced was BLOB object and file storage. Replacing a RiakCS cluster with AWS S3 removed the overhead of managing our own object store infrastructure and reduced the cost of storing those objects/files in our on-prem storage platform. We then proceeded to replace a prototype rabbitmq messaging platform with AWS SNS/SQS, which allowed us to provide a scalable messaging service to all of our internal applications. This tactic of moving on-prem services to AWS highlighted our need for more-robust network connectivity to AWS, so we invested in direct connect network links to AWS, which provided the network redundancy, capacity, and stability that we needed to leverage cloud services for on-prem applications.
New Product, New Land
Enova launched a new product, EnovaDecisions, which is a business-to-business decisioning-as-a-service offering. Since this would be a self-contained product offered to customers outside of Enova – customers of unknown size and scale as well – we decided to launch the entire product in AWS. This was the first attempt of Enova at running a full production stack in AWS, and we have learned a lot of lessons we will use in future migrations. We also started rolling out Aurora Postgres for this EnovaDecisions, which signaled the start of Enova’s enthusiasm for Aurora Postgres and our migration from RDS Postgres to Aurora Postgres.
Serverless
The current phase of our cloud strategy also leverages serverless options by-way-of AWS Lambda. This is Enova’s fastest adoption of any AWS service, and its usage spans operational tasks, data transformation, and replacing microservices where appropriate. Enova develops Lambdas in Go (our preferred language for services) and Python (our preferred language for decision models).
In the future
Many exciting changes are in store for the future of AWS at Enova. Enova’s Data Services team is redesigning our current data warehousing solution with a fully AWS-native solution built using AWS S3 and Snowflake. Our Analytics team is leveraging SageMaker to improve the training of our models for fraud detection, product offerings, and other decisioning flows we have within the lending process. The EnovaDecisions team is starting to leverage AWS container offerings, ECR and ECS, to improve their infrastructure. As a whole, Enova will continue to move workloads from our data center to AWS in order to provide AWS-provided services to our applications or improve customer experience by moving closer to the customer. As a whole, Enova is looking towards Athena, Glue, and Quicksight to improve our internal operational needs for AWS data.
Infrastructure as Code
As AWS usage has evolved at Enova, so has the means for managing this infrastructure. We initially built resources by hand, either through AWS console or APIs. That method was not scalable, so we began to leverage infrastructure-as-code with CloudFormation and abstractions built on top of CloudFormation. We now use Hashicorp Terraform for all new resources going into AWS. Terraform adoption across the company is growing as more engineering teams contribute pull-requests to create AWS resources and improve our cloud platform.
Life Is Short, Work Someplace Awesome
This post exhibits some of the interesting work that Enova is doing in AWS today and some of the strategies we follow to evolve our AWS usage.
As a decade-old finance company working in a highly regulated environment, we are not afraid to leverage the cloud when it solves an appropriate problem. There are other cloud adoption strategies than the commonly-discussed “lift-and-shift” method, and taking an evolutionary approach to cloud-migration effectively fills gaps with cloud services.
If this evolutionary journey of building AWS infrastructure sounds interesting to you, Enova is hiring AWS Systems Engineers.