Accelerating the Journey to the Public Cloud
I attended the 2015 Velocity Conference and sat in Intuit’s session “10 Essential Tips for Your Journey to the Public Cloud.” Intuit runs its Mint application on the AWS public cloud. As with any financial application, security and performance are paramount to passing the security gates to production with these apps.
The learnings and discoveries presented were immense.
Here is a summary of the 10 observations:
1. Understand Your Requirements and ELB Limitations
Intuit’s applications required encryption for data in flight and data at rest, timestamps for audit purposes and routing logic to redirect packets according to the fields in the header information. As these features are not present in Amazon’s Elastic Load Balancer (ELB), they developed their own proxy layer to meet these needs. The Amazon cloud addresses a lot of infrastructure requirements, but Intuit engineered supplementary infrastructure technology to address its broader needs.
2. Secure Sensitive Data
Application data needs to be secure both in flight and at rest. Integration with Amazon’s Key Management System helps protect sensitive data. Identify fields in applications also need to be secure.
3. Plan for Performance
Data encryption leads to latency. Plan for 20 to 30 percent degradation of performance. Intuit assumed that autoscale would solve the problem, but that was not always the case. When autoscale triggers, there is a 10-minute delay before the new server comes up. Once the server is up, all traffic is sent to the new server and it seems almost like a distributed denial of service (DDoS) pattern. It’s wise to establish SLA patterns that suit your application.
4. Treat Infrastructure as Code
Continuous deployment is a norm in development, but continuous operations is not a well established norm in operations. Development and operations need to work hand-in-hand to roll out the next version at rapid pace. Having joint code and operations infrastructure reviews helped each team understand the other’s perspective. Reviewing the operations infrastructure changes with development teams helped application developers gain valuable insight, so they could keep that perspective in mind while coding.
5. Prepare for Migrating and Managing Large Volumes of Data
Migrating large volumes of data can take several days. Sometimes you have to physically ship the data to AWS. However, once you have the data tier in AWS, you should immediately start data replication. Don’t wait for your application tier to be built and then start the data replication, otherwise you’ll end up shipping the data volumes again. Data can quickly get out of sync.
6. Plan for Multi-Availability Zones
Amazon’s cloud is built for high availability (HA) in multi-availability zones. If you starts small with HA in one availability zone and then try to adapt to multi-availability zones you’ll encounter obstacles. The best way to plan for HA is to plan for multi-availability zones from the get-go.
7. Plan for Self-Healing Infrastructure
AWS instances are dynamic. When there are issues with an instance, the instance is blown away and a new instance comes up. Building alerts that rely on IP address doesn’t work well because by the time you receive the notification, the instance is no longer there. Also, the infrastructure can heal itself. So allow time for the next instance to come up and for the system to stabilize. Design the system for alerts in a way that also sends system healing messages. If system alerts are only sent when an instance goes down, the ops team gets pages/texts at midnight only to realize the instance auto-healed. Plan for resilient and self-healing infrastructure.
8. Always Perform End-To-End Testing No Matter How Small the Code Change Is!
It’s no longer sufficient to test just the delta functionality between releases. End-to-end testing of code, config, deployment, monitoring, alerts and autoscaling is important. Every time you build a piece of software, end-to-end testing of code and infrastructure is mandatory.
9. Manage Costs by Making Smart Choices
Contain the costs when infrastructure is running on AWS. Some of strategies that Intuit used included moving to reserved instances when possible and using reaper scripts to shut down unused instances. Storage is cheap but IOPS is expensive, so focus on optimizing IOPS. Intuit also used EBS snapshots to copy incremental blocks of volume that were changed since the previous snapshot.
10. Deploy Independent Components of the Architecture that Can Be Rolled-Back
Each component of the infrastructure and application must be independently run and independently controlled so rolling back one version of the component is relatively easy instead of rolling back the whole infrastructure and the application version.
Journey to the Public Cloud: the 5-Minute Approach
When Intuit started this effort a few years back, there wasn’t a vendor in space that was solving these problems. The market and industry have since evolved.
A10 Lightning Application Delivery Service (ADS) addresses the problems mentioned above. Even for a company like Intuit, with seemingly infinite resources, skilled engineers and deep understanding of how to secure an application successfully in AWS, it took years to build out the secure, scalable and resilient Mint architecture.
For the rest of us who are starting now or struggling to achieve the same results, a faster path is to leverage A10 Lightning ADS. In a matter of 5 minutes, a reverse-proxy front-ends your application and has all the characteristics required to make your application secure and high performing. It serves as an SSL proxy, can auto-scale according to the infrastructure needs and has a built-in blue-green deployment option to slowly roll the next application version (N+1) or retract to previous application version (N-1).