Using Cloudwiry to Optimize Costs and Modernize Your Stack By Leveraging AWS

By Kinnar Sen, Sr. EC2 Spot Specialist SA – AWS
By Aditya Datta, CEO – Cloudwiry
By Francisco Gimeno, Product Manager – Cloudwiry
By Dan Kelly, Sr. GTM Specialist, EC2 Spot – AWS

Application modernization allows an organization to implement a new paradigm that brings in more flexibility, agility, and in many cases higher return on investment (ROI) compared to traditional approaches.

However, this is a hard problem to solve and is difficult to estimate the investment effort to perform such a change. Application modernization requires a holistic approach, and Cloudwiry enables optimization and modernization of cloud deployments by evaluating AWS services involved.

In this post, we will walk through how the Cloudwiry Enterprise platform can help your organization make informed decisions about application modernization. We will also take a deeper look into specific examples of how Cloudwiry has helped customers optimize their cloud usage on AWS.

Cloudwiry is an AWS ISV Partner with the Cloud Management Tools Competency.

Making the Case for Modernization

Deciding on upgrading an application from monolithic to modern architecture (such as serverless) requires a thorough understanding of the total cost of ownership (TCO) before and after modernization, and involves investment in the modernization effort.

The idea of modernization is that TCO after migration is lower, leading to a break-even point even after amortizing the investment in the modernization cost.

These are the most common components of TCO that impact application modernization:

• Infrastructure
• Software complexity
• Ongoing support
• Migration
• Training
• Productivity changes

Future infrastructure costs depend on the technology selected. Trade-offs between technologies and services impact not only the infrastructure costs, but also software development, migration, training, and ongoing support.

Evaluation

Cloudwiry’s approach consists of a layer-by-layer study. For the compute layer, we evaluate AWS services, Amazon Elastic Compute Cloud (Amazon EC2) pricing models, and best practices in workloads and architectures, including:

• AWS Lambda: A serverless compute service that lets you run code without provisioning or managing servers.
  .
• AWS Fargate: A serverless compute engine for containers that works with both Amazon Elastic Container Service (Amazon ECS) and Amazon Elastic Kubernetes Service (Amazon EKS).
  .
• Amazon EC2 Spot Instances: Spot instances allow you to request spare EC2 compute capacity for up to 90 percent off the On-Demand price.
  .
• Amazon EKS: This gives you the flexibility to start, run, and scale Kubernetes applications in the AWS Cloud or on-premises.
  .
• Right-sizing: This is the process of matching instance types and sizes to your workload performance and capacity requirements at the lowest possible cost.

To estimate the TCO for infrastructure, divide it into layers and find the most optimal solution for each layer individually for a given business application. The application can be split into layers such as frontend user interface (UI), compute, storage, database, data flow, and messaging augmented with data from application performance monitoring for increased confidence.

• For the frontend UI layer, if the application is using any JavaScript framework such as Angular, VueJS, or React, Cloudwiry calculates the costs of moving static files (not requiring processors in the server-side). Then, it calculates the cost of storing and serving the files in a solution.
  .
  For example, Cloudwiry can recommend a combination of Amazon CloudFront and Amazon Simple Storage Service (Amazon S3) that is highly performant and more cost effective than serving them from a set of distributed EC2 instances.
  .
  To calculate the costs, Cloudwiry uses HTTP metrics such as the number of requests, traffic served, and storage used by the assets, and estimates the equivalence using the pricing for CloudFront for traffic and S3 for storage.
  .
• For the compute layer, Cloudwiry performs dynamic simulations on what-if the workload is moved to other compute options (AWS Lambda, AWS Step Functions, Amazon EKS, AWS Fargate, Spot Instances, AWS Graviton2, etc.) to calculate the new infrastructure requirements and costs. It calculates the used compute power and estimates using translation models to compare with other technologies.
  .
  A CPU translation model can be used to estimate the required horsepower in each of the technologies. These models can include assumptions (such as the number of API calls, average duration, and used memory in the case of Lambda), or a study of the peaks of CPU and memory consumption in the case of a consolidation into an EKS cluster.
  .
• For the database layer, Cloudwiry analyzes the contents at the table level to check for the optimal solution. For instance, if it detects a table with Audit log entries, probably S3 and Amazon Athena would be a better option. Or, if the data is time series, perhaps it’s better to go with AWS Timestream.
  .
  The same happens for blob fields, where storing S3 objects could be the best approach if they are larger than a specific size. This can be done because, in monolithic applications, the ORM constrains database backend solutions’ variability. However, that’s not a problem anymore when using a microservices approach. Each component can choose the best solution for its purpose.
  .
  Also, at a database engine level, Cloudwiry detects the variability on the usage pattern: Amazon Aurora Serverless offers a model to grow and shrink its sizes dynamically, meaning customers can scale seamlessly and only pay for the capacity consumed.
  .
• For the storage layer, leverage tiering and right-sizing to choose the right solution (such as S3 IA or S3) with the best parameters (adjusting IOPS and throughput).
  .
• For all of the other layers, when a software solution is detected where an AWS managed service version exists, the system recommends the appropriate service such as Amazon Elasticsearch Service, Amazon EMR, Amazon Simple Queue Service (SQS), and AWS Glue.

Implementation

Knowing where to start on your modernization journey can be a challenge, but Cloudwiry’s four-phase approach has worked best for our customers and partners.

Figure 1 – Cloudwiry’s four-phase approach to modernization.

Phase 1: Automated discovery of apps and modernization sizing through details available in the AWS Cost and Usage Report, Amazon CloudWatch metrics, and modern cloud observability platforms such as Dynatrace. Cloudwiry’s Modernization Hub leverages machine learning (ML) to auto-identify tiers of the applications, interconnectivity, and their complexities:

• Auto-discovers assets belonging to each application in the application cluster.
• Identifies each tier of the app (web, compute, database).
• Sizes each tier of each application for future state architecture options.
• Recommends technology or solution providing the best ROI for each application.

Phase 2: Customers get complexity score and modernization TCO:

• Customer provides input on application business priority and expected lifetime.
• Customer provides additional tooling for each tier, such as static source code analysis, Application Performance Monitoring metrics, and database inspection.
• Cloudwiry’s Modernization Hub calculates a complexity score for each tier, recommends architecture, and calculates TCO for both legacy and recommended architecture.

Phase 3: Automated initial setup and migration kick-off:

• Cloudwiry’s Modernization Hub generates the next steps for migration activities.
• Customer provides selection of architecture, policies, and security considerations.
• Cloudwiry’s Modernization Hub generates initial source-code, including infrastructure as code (IaC), such as AWS CloudFormation or Terraform, for the selected architecture, incorporating best practices from the AWS Well-Architected Framework.

Phase 4: Implementation and tracking:

• Customer identifies, builds, and trains an internal team to implement recommended changes in various departments.
• Prioritize the modernization of the highest ROI applications first.
• Learn, automate, rinse, and repeat.

Customer Use Case for App Modernization

Cloudwiry’s Fortune 500 client with over 400 legacy apps undertook modernization migration and needed to identify the lowest TCO option for each application with a detailed analysis of all choices.

They had a number of legacy applications with interdependencies, and had a multi-tier architecture using web, compute, and database.

Customer requirements included cost sizing future state hosting costs, complexity and effort-sizing the migration, and automated process to prioritize apps to migrate.

To support the customer’s needs, Cloudwiry’s Modernization Hub systematically:

• Auto-identified and categorized current assets and costs for each application.
• Sized the current infrastructure costs for each application.
• Integrated with Dynatrace to import run-time analysis and metrics for application components, entity topology, and dependencies mapping of user experience data, components, services, and infrastructure.
• Sized migration complexity and infrastructure costs for compute options such as AWS Lambda, Amazon EC2 instances (right-sizing), EKS and ECS (Fargate or Graviton2), and pricing strategy (Spot).
• Sized complexity and infrastructure savings for managed database options such as Amazon Aurora, Amazon Redshift, and Amazon Athena. Identified blob and audit log tables that represent the highest ROI for migration to modern technologies such as S3 and Athena.
• Enabled template-based quick start with CloudFormation and Terraform, incorporating Well-Architected best practices for the selected architecture.

After the initial phase, Cloudwiry Modernization Hub identified the top 10 applications, their potential savings, and the overall complexity score for the effort. The lower the complexity, the easier it is to modernize.

Let’s take an in-depth look at the application “APP00806905” for compute and database options. Cloudwiry App Modernization Hub calculated current and future state costs for both compute and database.

Compute

Amazon EKS running on a Graviton2 with Spot nodes was the lowest TCO option based on elasticity, the cheapest option, and had a low complexity for migration. Also, based on Cloudwiry Elasticity Score calculation, Spot provided the lowest TCO for modernization with high savings.

Figure 2 – Compute cost breakdown.

Database

This application contained multiple instances of SQL Server, Aurora MySQL, and Aurora Postgres (63 instances in total). Cloudwiry App Modernization Hub simulated several options like moving from SQL Server to Babelfish and all the flavors of Aurora, including the growing or shrinking Aurora Serverless based on the performance metrics.

In this case, Aurora right-sized was the lowest TCO approach.

Figure 3 – Storage cost breakdown.

Customer Use Case for Spot Instances

Cloudwiry’s client was running more than 20,000 Amazon EC2 instances monthly, and they were looking for ways to optimize compute costs. They had Auto Scaling Groups, but they were not leveraging the Spot instances, only On-Demand.

The customer was using 200+ Auto Scaling Groups and frequently scaling in and out, which leads to high instance churn and raised elasticity index. These factors made them an ideal candidate for Spot, as their instances were generally short-lived. Cloudwiry followed the four-phase approach to solve the problem.

Cloudwiry’s Enterprise Spot automatically categorized the different workload types in the customer’s portfolio and estimated the Spot savings as follows:

Cloudwiry’s artificial intelligence (AI) algorithms minimize risk with the following approach:

• Spot best practices: Combining multiple instance types that are fully compatible with workload requirements (CPU, memory, NICs, IOPS, processor architecture) results in higher resilience.
  .
• Multi-AZ support: Cloudwiry selected Multi-Availability Zone (AZ) Spot instances after analyzing data transfer cost across AZs against the additional resilience of multi-AZ Spot implementation.
  .
• Instance type selection: Cloudwiry recommended only fully-compatible EC2 instance types (CPU, memory, NICs, IOPS, processor architecture) with the lowest cost and most reliable instance types for the AZ.
  .
• On-Demand to Spot ratio: The customer was using all On-Demand instances within their clusters, and could use 100 percent Spot instances to capture the most savings. However, as not all workloads are ideal for Spot (such as Stateful or long-running), Cloudwiry suggested using a mix of both On-Demand and Spot instances.
  .
  This ensured workloads that required guaranteed capacity could use On-Demand, while other Spot-friendly workloads could run on Spot. Cloudwiry also suggested cluster scaling events be handled using Spot to further optimize on cost.
  .
• Instance sizing: Even if this isn’t the primary goal of the process, there’s an opportunity to optimize the parameters for elasticity. However, this is treated in another process called ASG RightSizing.

This analysis resulted in Cloudwiry-generated CloudFormation and Terraform templates that follow Spot best practices, and customized to the customer’s use case.

For long-term support of the solution, Cloudwiry will track all the variance on Spot instance prices and interruption rates. Alerts will be sent to resource owners, identified by rules when significant deviations are found, and suggest adjustments on the Auto Scaling Group CloudFormation templates.

Cloudwiry Enterprise Spot capabilities enabled the customer to understand the Spot savings for their workloads while avoiding disruption. Cloudwiry’s implementation of Spot instances resulted in an average savings of 39 percent on compute while meeting similar SLAs to the previous On-Demand configuration.

The customer was able to net 93 percent of their potential $73,700 of savings on Auto Scaling Groups—their largest expense.

Conclusion

Modernization and cost optimization yields flexibility, agility, and often, higher ROI. Doing this at scale is a complex undertaking where the application profile and business priorities have to be taken into consideration to identify the right approach.

Cloudwiry’s solutions provide enterprises with smart financial insights to make digital transformation decisions while ensuring tasks for cloud financial management are eliminated with automation.

The Cloudwiry platform delivers cost savings in AWS expenses with:

• Financial engineering
• Cost hygiene automation
• Chargeback and showback reporting
• Serverless modernization
• Enterprise EC2 Spot

Check out Cloudwiry on AWS Marketplace, and explore a free trial.

.

.

Cloudwiry – AWS Partner Spotlight

Cloudwiry is an AWS ISV Partner that delivers dramatic cost savings for your AWS infrastructure using a powerful automation platform and extensive knowledge from a team of experts.

Contact Cloudwiry | Partner Overview | AWS Marketplace

*Already worked with Cloudwiry? Rate the Partner

*To review an AWS Partner, you must be a customer that has worked with them directly on a project.