Application Modernization allows for an organization to implement a new paradigm bringing in more flexibility, agility, and in many cases, higher ROIs compared to traditional approaches. However, this is a very hard problem to solve and it’s difficult to estimate the investment effort to perform such a change. Application Modernization requires a holistic approach.
Making a decision about upgrading an application from monolithic to modern architecture (such as serverless) requires a thorough understanding of the TCO, before and after modernizationn. The idea is that as the TCO after the migration is significantly lower, there will be a breakeven point to amortize the investment of the changes.
These are the most common components of TCO that impacts application modernization:
- Software complexity
- Ongoing Support
- Productivity Changes
Future infrastructure costs depend on the technology you select, e.g. choosing between Kubernetes, Lambda, Fargate, etc impacts not only the infrastructure costs, but also software development, migration, training, and ongoing support.
Start by estimating the TCO for infrastructure by dividing it into layers and finding the most optimal solution for each layer individually for a given business application. The application can be split by layers such as Frontend UI, Compute, Storage, DB, Data Flow, Messaging.
- For Frontend UI, if the application is using any JS framework such as Angular, VueJS, or React, calculate the costs of moving static files (not requiring processors in the server-side) of storing and serving them from a solution such as a combination of Cloudfront + S3 that’s highly performant and cost-efficient (much better than serving them from a set of distributed EC2 instances).
- For Compute, perform dynamic simulations on what-if the workload is moved to serverless (Lambda, Step Functions, EKS, Fargate, Spot instances, etc) to calculate the new infrastructure requirements and its costs. Calculate the used compute power and estimate using translation models to compare with other technologies.
- For Databases, analyze the contents at the table level to check for the optimal solution. For instance, if we detect a table with Audit log entries, probably S3 + 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 certain size. We can do this because, in monolithic applications, the ORM constrains the variability of DB backend solutions. 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 DB Engine level, we are also detecting the variability on the usage pattern: Aurora Serverless offers a very interesting model to dynamically grow and shrink its sizes.
- For Storage, leverage tiering and rightsizing to choose the right solution (S3 IA, S3… ), with the best parameters (adjusting IOPS and throughput).
The Bigger Picture
Knowing where to start can be incredibly daunting, but this approach has worked the best for our customers:
- Identify various options for infrastructure costs for each application layer using Cloudwiry’s Modernization Hub.
- Identify the first tranche of high priority apps to migrate with the simplest current Software Complexity (Web-based apps).
- Size the TCO for this tranche & expected ROI for the app’s lifecycle.
- Identify, build & train a Special Mission Unit to build organization capabilities in various departments.
- Modernize the highest ROI app first.
- Learn, Automate, Rinse & Repeat.