This Anexinet Client is a provider of corporate tax software and services, offering cloud-based and on-premises solutions that can be tailored to specific industries for every major line of corporate tax. Their services enable companies to automate and integrate strategic tax processes while leveraging advanced, predictive analytics of tax data.
The client’s operational model provides technology that simplifies complex taxes. They built an extremely successful suite of software applications and offerings, with a large percentage of clients hosting the software in their own data centers. This meant the client was responsible for keeping software patches current with the latest monthly updates and backing-up all data. Additionally, the on-premises (i.e. private cloud) locations would not scale as efficiently as they would in the public cloud.
The company felt they needed to expand their offerings to a sub-based model so the software could be consumed by a larger audience. They expected that a subscription-based SaaS model would be a better fit for developing and delivering web-based application services. But the client’s talented IT staff lacked the in-house expertise necessary to migrate applications into a cloud-based service capable of ensuring the high availability (99.999% uptime) necessary to support their service.
The AWS public cloud would bring a scriptable infrastructure, resilient with AWS Regions and Availability Zones, to build redundancy into the new tax calculation service engine. But lifting and shifting an application to the AWS public cloud and building robust services required an entirely new mindset. Furthermore, AWS’s serverless public cloud technologies called for a unique set of application development processes. To ensure the success of their SaaS-based, tax calculation service, the client partnered with Anexinet to devise a strategy for migrating the SaaS offering from a private cloud to an AWS public cloud.
Anexinet first built the SaaS application in a private cloud, then migrated the application once the business decision was made to move the workload to AWS. Naturally, the application required optimization for the public cloud. Once in the public cloud, new features were added to take full advantage of the AWS services.
Route 53 geolocation to ensure routing to the closest AWS region. Geolocation routing would also failover in the event a region became unavailable.
API Gateway, defined as service layer of health checks—implemented by Lambda functions—into each region. This service layer monitors the availability and health of internal services, in addition to monitoring external load-balancer endpoints.
Application Load Balancers (ALB) are utilized in front of all application components to provide Availability Zone redundancy within the regions.
To support authentication, we setup an OAuth2 solution with a Multi-AZ RDS hosted SQL Server database. We implemented cross-region replication to keep access tokens in sync.
We defined and built (via code) an Amazon Machine Image (AMI) to host the tax calculation engine. Implemented via a Step Function invoking a series of Lambda functions, the AMI can be easily rebuilt whenever the tax calculation engine software is updated, or when operating system patches are needed.
A Launch Configuration template referencing the AMI was defined for an Auto Scaling group in each region to host the calculation engine. The Auto Scaling group provides the needed scalability and fault tolerance to maintain the desired throughput.
Utilizing the Amazon Trace ID, the ALB logs stored in S3, and Athena queries each request so that the tax calculation engine can be tracked through each region. This tracking data supports system round trip time per client, ensuring service level agreements are met.
CloudWatch alerts are set on all infrastructure and forwarded to an internal monitoring system to notify Production Support staff of any issues in the AWS environment.
With Anexinet’s guidance in implementing the new AWS-based SaaS offering, the client was able to shift budget portions from the private cloud model (capital expenses)—where they had to procure all the hardware and “stand it up”—to an environment where they could provision new resources such as servers, storage, and services on the fly.
By enabling multiple environments (e.g. running a production environment along with subsequent environments for testing quality of service), the new AWS environment lets the client develop software more quickly. In addition, workloads can be sped up through the use of a scriptable infrastructure and automated deployment—resulting in significant overall cost savings.