Does this sound familiar? “You will move to the cloud, for right or wrong, because of a business imperative to get out of your data center, not tomorrow, but yesterday.” Or, “You’re sold on the idea that by migrating to the cloud, you’d be able to reduce your total cost of ownership (TCO), increase flexibility, and accelerate innovation projects.” The cloud practically sells itself, and as a result, you plan to ditch your legacy, on-premises technology and begin your cloud migration journey.
However, suppose you hop into the cloud without a defined strategy and approach. In that case, you’ll experience cloud sprawl, and spiraling cloud costs will negate the touted benefits of the cloud. This sort of “blind faith” in all the cloud offers is a common mistake many business leaders make. It has prevented you from considering cloud management and economics as part of your cloud migration strategy.
Enter Innovation Scoring by 2nd Watch. Our data-driven scoring system will help you assess your applications running in the cloud environment and identify where you are overprovisioning and overspending. Innovation Scoring is the first step to establishing cloud economics and maximizing the value of cloud computing to your business in the long run.
The Importance of Cloud Economics
If O2 is how you define your cloud environment, you’ve learned the hard way about the need for cloud economics. While cost savings is a component of cloud economics, the ultimate goal of the practice is tomaximize the value of cloud computing for your organization. Implementing cloud economics will give your business insights into which departments are utilizing the cloud, what applications and workloads are using the cloud, and how these moving parts contribute to more impactful and cost effective business goals.
Without cloud economics, your business will deal with overrun cloud budgets, which are usually due to one or more of the following:
Ungoverned costs: your organization has no idea what it is spending on.
Unforecasted usage: you see more cloud projects than you had anticipated.
Uncommitted mindset: you don’t want to commit to a cloud contract (because you can’t predict its usage), so you miss out on contractual discounts.
Wasted dev/test resources: your dev team is overprovisioning their infrastructure.
Overestimated production headroom: you are not auto-scaling or have not set proper parameters for autoscaling for your applications.
Wrongsized production: your production environment is overprovisioned, and pay for the excess resources monthly.
Poor design and implementation: your architects make suboptimal design choices for cloud solutions because they are unaware of the costs to the business.
For cloud economics to work, there must be a company-wide commitment to the practice beyond simply calculating cloud costs. Just likeimplementing a DevOps practice, impactful cloud economics requires promoting a cross-functional and collaborative culture. Business leaders must encourage transparency and trackability to enable teams to work together harmoniously to manage their cloud infrastructure and prove the true business benefits of the cloud.
2nd Watch’s Innovation Scoring
Cloud economics is critical for your business to reap the maximum benefits of cloud computing. However, cloud economics is a pervasive cultural practice, so it won’t happen at the snap of your fingers. It will require time and effort for your business to establish cloud economics.
The first step in controlling your cloud budget and governing your cloud platform is to identify areas of improvement. 2nd Watch created the Innovation Scoring system, our proprietary scoring methodology, to help you identify opportunities for optimization and modernization in a data-driven way.
Our Innovation Scoring methodology will reveal the underlying problem with your cloud management. We’ll be able to identify the application needing improvement and determine why it is suboptimal. Did you set it up incorrectly and need to move to PaaS with autoscaling capabilities? Or did someone write your application in 2005, and you are in dire need of application modernization? Or is it a combination of both? 2nd Watch designed its Innovation Scoring to pinpoint areas for improvement in your database, infrastructure, and/or application. When we ascertain the source of inefficiency, we can address issues contributing to cloud sprawl and skyrocketing cloud costs.
To calculate your Innovation Score, we analyze several different dynamics related to your cloud applications. The ratings from each category are then cross-tabulated to generate a total view of your entire cloud environment. Your Innovation Score will not only reveal inefficiencies but also allow us to compare your efforts against other similarly sized companies and make sure you are up to industry standards.
2nd Watch understands that cloud economics is a cultural undertaking; therefore, when we assign Innovation Scores to our clients, we do so in a way that encourages company-wide participation. To promote engagement and commitment, we’ve gamified our Innovation Scoring: we split our clients’ technical leadership into teams and calculate each team’s score. When we check in with our clients, we reveal each team’s score to showcase which ones are being innovative and taking advantage of the cloud and which ones have room for improvement.
Sample Innovation Scoring Output
Our approach to Innovation Scoring promotes friendly competition, which fosters collaboration between teams and a transparent high-level overview of how each team is leveraging the cloud. When our clients are a part of our Innovation Scoring system, it jumpstarts a culture of innovation, transparency, and accountability within their business.
Consider the importance of cloud economics when planning to run your applications in a cloud environment. It is easy to overspend, get overwhelmed, and have no sense of direction. Therefore, cloud economics is beneficial whether you implement it proactively or reactively.
2nd Watch’s Innovation Scoring is a practical first step to getting your cloud budget in order and establishing cloud economics as a standard cultural practice in your organization. Through data and analysis, our Innovation Scoring will help you identify how you can optimize your cloud instance so that you are receiving maximum cloud value for your business. Moreover, Innovation Scoring trains your teams to be communicative and cross-collaborative, which are the traits your company culture needs to succeed in cloud economics.
You made a decision and a plan. You selected a migration partner. And you exited your traditional datacenter successfully by migrating thousands of virtual machines to the public cloud. You breathed a huge sigh of relief because it wasn’t easy, but you and your team pulled through.
While you and your teams were preparing to return to focusing on business value-driven tasks and features, the newly minted cloud estate was ticking away like a taxi meter 24 hours a day, seven days a week. The first invoice came, and it seemed a little higher than your forecast. The second monthly invoice was even higher than the first! Your business units (BUs) are now all-in on the cloud, just like you asked, and deploying resources and new environments at will like kids in a candy store. The invoices keep coming, and eventually, Finance takes notice. “What happened here? I thought moving to the cloud would reduce costs?”If this sounds familiar, you’re not alone.
As with many new technologies and strategies, moving to the public cloud comes with risks and rewards. The cloud value proposition is multi-faceted and, according to AWS, includes:
Total Cost of Ownership (TCO) Reduction
For many enterprises, the last three pillars of productivity, resilience, and agility have gotten overshadowed by the promise of a lower TCO. It’s not hard to understand why. Measuring cloud usage costs is easy. The cloud service provider (CSP) does this for you every month. The idea that migrating to the cloud is a cost-driven exercise excludes three-fourths of the potential business value – especially when migrating with a lift-and-shift approach.
The Lift-and-Shift Approach
When you consider workloads like black boxes, you start your journey without complete visibility into the public cloud’s opportunities. Maybe you had an expiring datacenter contract and had to evacuate under time pressure. That’s understandable. But were you educated and prepared for the tradeoffs of that approach? Or were you shocked by the first invoice and the speed at which the invoices are growing? Did you prepare the CFO in advance and share the next steps? So, what did you miss?
When you took a black-box lift-and-shift (BBLAS) approach, the focus was on moving virtual machines in groups based on dependency mapping. Your teams or your cloud partner, usually with the help of automation, defined the groups and then worked with you to plan the movement of those groups – typically referred to as “wave planning.” What you ended up with is a mirror image of your datacenter in the public cloud.
You have now migrated to someone else’s datacenter.
The old datacenter was predictable where fixed hardware investments dictated capacity, and efforts towards efficiency only occurred when available resources started to dwindle from new and existing services and applications being deployed or scaled. This new datacenter charges by the millisecond, has unlimited capacity, and the investment in additional capacity bypasses procurement and is in the hands of the engineers. Controlling costs in this new datacenter is a whole new world for most enterprises. Enter the FinOps movement.
“FinOps is an evolving cloud financial management discipline and cultural practice that enables organizations to get maximum business value by helping engineering, finance, technology and business teams to collaborate on data-driven spending decisions.” – finops.org
FinOps is to finance and engineering, as DevOps is to development and operations. The FinOps philosophy and approach is how you regain cost control in a BBLAS environment. Before diving into how FinOps can help, let’s look at the Cloud Cost Optimization Cycle (CCOC). The CCOC is a precursor to the FinOps framework and another black-box approach to cost efficiency in the cloud.
A black-box approach is when virtual machines are viewed as a fixed infrastructure without regard to the applications and services running on them. Seasoned professionals have lived through this traditional IT view for years, and it is what separates operations and development concerns. DevOps philosophy is making inroads, of course, but many enterprises have only begun to introduce this philosophy at scale.
The Cloud Cost Optimization Cycle goes like this. Every month your CSP makes cost and usage data available. An in-house resource or a consultant analyzes the massive amount of data and prepares recommendations for potential savings. The consultant presents these recommendations to the operations team, which then reconfigures the deployed infrastructure to achieve cloud savings.
This cycle can produce significant savings at scale and is the traditional starting point for gaining visibility and control over runaway cloud costs. The process follows the FinOps recommended progression of crawl, walk run toward a mature practice. This approach has both benefits and limitations:
Infrastructure-focused cost savings
Cost savings are limited to infrastructure and cloud configuration changes
Brings financial accountability and cloud spend awareness to the enterprise
Application architecture remains unchanged
Sets a trajectory towards FinOps best practices (crawl, walk, run)
Can create friction between Operations and AppDev teams
Accomplished primarily by the Operations team
App refactoring focused on patching instead of business value or modernization
The Black-Box Dilemma
In an ideal state, operations teams can iteratively reconfigure public cloud infrastructure based on cost and usage data until the fleet of virtual machines and associated storage are fully optimized. In this ideal state, interactions with the application teams are minimal and driven by the operation team’s needs. The approach ignores the side effects that right-sizing infrastructure can have on somewhat brittle monolithic legacy applications. What usually happens in a BBLAS environment is that the lift-and-shift migration and the subsequent CCOC reveal unforeseen shortcomings in the application architecture, and runtime defects surface.
A lack of necessary cloud skills and experience on the operations side can exacerbate the issues. For example, if the operations team chooses the incorrect cloud instance type for the workload, applications can become bound by resource constraints. When cloud skill and experience are missing from the application development side, this can cause long delays where defects are difficult for the team to triage and patch. So now, instead of cost optimization efforts gloriously precipitating savings, they are producing a mixture of saving money and addressing issues.
This combination creates an environment where engineering and operations teams begin to collide. The applications were stable in the old datacenter due to factors like:
Extremely low network latency between services
Applications and databases tuned for the hardware they were running on
Debugging and quality processes tuned over the years for efficiency
Now application teams have a new stream of issues entering their backlogs driven by fundamental changes in infrastructure introduced by the noble pursuit of tuning for cost savings. Business value, architectural improvements, and elimination of technical debt are slowed to the point that Application Development leaders start to push back on the CCOC. Operations teams don’t understand why the application is falling apart because the metrics and the cloud cost data they collect support the reduction or reconfiguration of cloud resources. Additional factors are now in play from an application development perspective with a black-box cloud cost optimization strategy:
Users are constantly communicating new feature requests to the business
Enterprise and Application Architects are pushing teams for modernization
Software Team leads are insisting on dedicating capacity to technical debt reduction
Enterprises are struggling to retain developers and are more resource-constrained than ever, causing a general slowdown in time to market for features and architectural improvements when flaws in legacy applications need patching.
Going Beyond the Lift-and-Shift
You need a different strategy to overcome these challenges. You must look inside the black boxes to move forward. The CCOC, at its best, will produce a finely tuned version of a legacy application running in the public cloud. You can address the cost pillar of the cloud value framework from an operations perspective, but additional opportunities abound in the form of Application Modernization.
Enterprises in situations like the one described here need to do two things to move forward on their cloud journeys.
Mature cloud cost optimization towards FinOps
Invest in Application Modernization
These two strategies are complementary and, combined, what 2nd Watch has dubbed “FinOps Driven Modernization.”
The amount of cost and usage data available to enterprises operating in the cloud reveals an opportunity to use that data to drive application modernization strategy at scale across all business units. The biggest challenges in approaching application modernization at scale are:
Cloud skills and experience
Analysis paralysis – where do we start
Calculating Return on Investment
Modernization efforts will be slow and costly without the resource capacity having the necessary cloud architecture and operations skills. They will not produce further buy-in through the socialization of success stories. Getting started seems impossible when an enterprise consists of multiple business units and thousands of virtual machines across hundreds of accounts and development teams. Modernization costs rise dramatically when cloud cost optimization requires changes to the software running on the virtual machines. It can add a significantly higher risk than changing instance families and reconfiguring storage tiers.
How Can FinOps Help Drive Modernization?
Let’s look at how maturing FinOps drives modernization opportunities and capacity. We discussed how an infrastructure-focused CCOC could slow down features, business value, and modernization efforts.
A potentially significant percentage of the savings realized from this approach will be diverted to triaging and patching application issues.
Do the additional development efforts overshadow the infrastructure savings?
Is the time to market for new features slowed to the point that the enterprise’s competitive advantage suffers?
Most enterprises don’t have the processes in place to answer these questions. FinOps Driven Modernization is the answer. With the data from the CSP, the FinOps team can work with the operations and development teams to determine if an optimization recommendation is feasible and valuable to the business.
How does this work at scale among all business units? When you combine cost and usage data with information like:
Process information from inside each virtual machine
Service ticket and bug metrics
Nature of the cloud service
IaaS, PaaS, FaaS
More on this in the next installment of this series
Revenue – unit economics
You begin to see a more holistic view of the cloud estate and can derive insights that include cost and much deeper business intelligence.
Sample FinOps Output from 2nd Watch
Consider being able to visualize where to focus cost optimization and modernization efforts across multiple business units, thousands of virtual machines, and hundreds of applications in a single pane of glass dashboard. The least innovative, noisiest, and most costly areas in your enterprise will begin glowing like hot coals. You can then focus the expenditure of resources, time, and money on high-impact optimization and modernization investments. This reallocation of spending is the power of FinOps Driven Modernization. Finance, operations, engineering, product, and executives are all working together to ensure that the enterprise realizes the actual value of the cloud.
Let’s dig into a hypothetical business unit struggling with cloud costs. The FinOps team has identified that their per-unit costs exceed the recommended range for their cloud cost-to-revenue ratio. The power of FinOps-Driven Modernization has revealed that the BBLAS approach has resulted in a fleet of virtual machines running commonly modernized workloads like web servers, database servers, file, or image servers, etc. In addition to this IaaS-heavy approach, the BU heavily leverages licensed software and operating systems. This revelation triggers a series of interviews with the BU leadership and application owners to investigate the potential and level of effort to introduce application modernization approaches. The teams within the BU know there is room for improvement but lack the skills and available resources to act.
They learn through the interview process that they can move licensed databases from virtual machines to a managed cloud platform. Additionally, they discover they could migrate most of the databases to open-source alternatives. Further, they can decommission the cluster of file servers and migrate the data to cloud-native storage with minimal application refactoring. By leveraging the CSP and operational data, a business case for investing in helping the BU make improvements writes itself.
Without leveraging the FinOps philosophy and extending it with a focus on application modernization, this business unit would have operated for years in a BBLAS state, costing the enterprise orders of magnitude more in cloud spend than the investment in modernization. Extending this approach across the enterprise takes cloud cost management to the next level, resulting in purpose-driven, high-impact progress towards realizing the value of the public cloud.
FinOps is the practice that every enterprise should be adopting to help drive financial awareness throughout the organization. FinOps enables an inclusive and virtuous cycle of continuously improving when leveraged as a driver for application modernization.
Schedule a whiteboard session with our FinOps and Application Modernization experts to discover how 2nd Watch’s approach can help you and your team meet your transformation objectives.
Jesse Samm, Application Modernization Practice Director at 2nd Watch
Most businesses today have evaluated their options for application modernization. Planned movement to the cloud happened ahead of schedule, driven by the need for rapid scalability and agility in the wake of COVID-19.
Legacy applications already rehosted or replatformed in the cloud saw increased load, highlighting painful inefficiencies in scalability and sometimes even causing outages. Your business has likely already taken some first steps in app modernization and updating legacy systems.
Of the seven options to modernize with legacy systems outlined by Gartner, 2nd Watch commonly works with clients who have already successfully rehosted and replatformed applications. To a lesser extent, we see mainframe applications encapsulated in a modern RESTful API or replaced altogether. Businesses frequently take those first steps in their digital transformation but find themselves stuck crossing the gap to a fully modern application.
What are common issues and solutions businesses face as they move away from outdated technologies and progress towards fully modern applications?
Keeping the Goal in Mind
Overcoming the inertia to begin a modernization project is often a lengthy process, requiring several months or as much as a year or more to complete the first phases. Development teams require training, thorough and careful planning must occur, and unforeseen challenges are encountered and overcome. Through it all, the needs of the business never slow down, and the temptation to halt or dramatically slow legacy modernization efforts after the initial phases of modernization can be substantial.
No matter what the end state of the modernization journey looks like, it can be helpful to keep it at the forefront of the development team’s minds. In today’s remote and hybrid working environment, that’s not as easy as keeping a whiteboard or poster in a room. Sprint ceremonies should include a brief reminder of long-term business goals, especially for backlog or sprint reviews. Keep the team invested in the business and technical reasons and the question “why modernize legacy applications” at the forefront of their minds. Most importantly, solicit their feedback on the process required to accomplish the long-term strategic goals of the business.
With the goal firmly in your development team’s minds, it’s time to tackle tactics in migrating from legacy apps to newer systems. What are some of these common stumbling blocks on the road to refactoring and rearchitecting legacy software?
Refactoring an application can encompass a broad set of areas. Refactoring is sometimes as straightforward as reducing technical debt, or it can be as complex as breaking apart a monolithic application into smaller services. In 2nd Watch’s experience, some common issues when refactoring running applications include:
Limited knowledge of cloud-based architectural patterns. Even common architectures like 2- and 3-tier applications require some legacy code changes when an application has moved from a data center to a cloud service provider or among cloud service providers. Where an older application may have hardcoded IP addresses or DNS, a modern approach to accessing application tiers would use environment variables configured at runtime, pointing at load balancers.
Lack of telemetry and observability. Development teams are frequently hesitant to make changes quickly because there are too many unknowns in their application. Proper monitoring of known unknowns (metrics) and unknown unknowns (observability) can demystify the impact of refactoring. For more context around the types of unknowns and how to work with them in an application, Charity Majors frequently writes on the topic.
Lack of thorough automated tests. A lack of automated tests also slows the ability to make changes because developers cannot anticipate what their changes might break. Improved telemetry and observability can help, but automated testing is the other side of the equation. Tools like Codecovcan initially help improve test coverage, but unless carefully attended, incentivizing a percentage of test coverage across the codebase can lead to tests that do not thoroughly cover all common use cases. Good unit tests and integration testing can halt problems before they even start.
No blueprint for optimal refactoring. Without a clear blueprint for understanding what an optimally refactored app looks like, development and information technology teams can become frustrated or unclear about their end goals. Heroku’s Twelve-Factor App methodology is one commonly used framework for crafting or refactoring modern applications. It has the added benefit of being applicable to many deployment models – single- or multiple-server, containers, or serverless.
Rearchitecting an application to leverage better capabilities, such as those found in a cloud service provider’s Platform-as-a-Service (PaaS) or Software-as-a-Service (SaaS) options, may present some challenges. The most common challenge 2nd Watch encounters with clients is not fully understanding the options available in modern environments. Older applications are the product of their time and typically were built optimally for the available technology and needs. However, when rearchitecting those applications, sometimes development teams either don’t know or don’t have details about better options that may be available.
Running a MySQL database on the same machine as the rest of the monolithic application may have made sense when initially writing the application. Today, many applications can run more cheaply, more securely, and with the same or better performance using a combination of cloud storage buckets, managed caches like Redis or Memcached, and secrets managers. These consumption-based cloud options tend to be significantly cheaper than managed databases or databases running on cloud virtual machines. Scaling automatically with end-user demand and reduced management overhead are additional benefits of software modernization.
Rearchitecting an application can also be frustrating for experienced systems administrators tasked with maintaining and troubleshooting production applications. For example, moving from VMs to containers introduces an entirely different way of dealing with logs. Sysadmins must forward them to a log aggregator instead of storing them on disk. Autoscaling a service can mean the difference between identifying which instances – of potentially dozens or hundreds – had an issue instead of a small handful of them. Application modernization impacts every person involved with the long-term success of that application, not just developers and end-users.
Application Modernization is a long-term strategic activity, not a short-term tactical activity. Over time, you will realize the benefits of the lower total cost of ownership (TCO), increased agility, and faster time to market. Recognizing and committing to the future of your business will help you overcome the short- and mid-term challenges of app modernization.
Engaging a trusted partner to accelerate your app modernization journey and lead the charge across that gap is a powerful strategy to overcome some of the highlighted problems. It can be difficult to overcome a challenge with the same mindset that led to creating that challenge. An influx of different ideas and experiences can be the push development teams need to reach the next level for a business.
If you’re wondering how to modernize legacy applications and are ready to work with a trusted advisor that can help you cross that gap, 2nd Watch will meet you wherever you are in your journey. Contact us to schedule a discussion of your goals, challenges, and how we can help you reach the end game of modern business applications.
If the global pandemic taught us anything, it’s that digital transformation isa must-have for businesses to keep up with customer demands and remain competitive. To do this, organizations are moving their workloads to and modernizing their applications for the cloud faster than ever.
In fact, according to a recent survey, 91% of respondents agree or strongly agree that application modernization plays a critical role in their organization’s adaptability to rapidly changing business conditions. But there are so many cloud service providers to choose from! How do you know which one is best for your application modernization objectives? Keep reading to find out!
What is a Cloud Services Provider (CSP)?
A cloud services provider is a cloud computing company that provides public clouds, managed private clouds, or on-demand cloud infrastructures, platforms, and services. Many CSPs are available worldwide, including Alibaba Cloud, Amazon Web Services (AWS), Google Cloud Platform (GCP), IBM Cloud, Oracle Cloud, and Microsoft Azure. However, three industry giants are noteworthy because of their services and global footprint: Amazon Web Services (AWS), Google Cloud Platform (GCP), and Microsoft Azure.
What is Application Modernization?
Application modernization is the process of revamping an application to take advantage of breakthrough technical innovations to improve the overall efficiency of the application remarkably. This efficiency typically involves high availability, increased fault tolerance, high scalability, improved security, eliminating a single point of failure, disaster recovery, contemporary and simplified tools, new coding language, and reduced resource requirements, among other benefits. Many companies running legacy applications are now looking at how they can best modernize their monolith applications.
Application Rationalization: The First Step to Modernization
The best way to start any application modernization journey is with application rationalization. In this process, you identify company-wide business applications and strategically determine which ones you should keep, replace, retire, or consolidate. Once you identify those applications, you can list each one’s ease or difficulty level, total cost of ownership (TCO), and business value, enabling you to decide and prioritize which action to take. (Hint: Start with high value and minimal effort apps!) Doing this will also help you eliminate redundancies, lower costs, and maximize efficiency.
The high-value apps that are difficult to move to the cloud will likely cause the most grief in your decision-making process. But, like Rome, your modernization strategy doesn’t need to be built in a day.
You can develop an approach to application modernization over time and still reduce costs and risks while moving your portfolio forward.
It is crucial to evaluate your current application stack and determine the most suitable application modernization strategy to migrate to the cloud when it comes to application modernization in the cloud. Many on-premises applications are legacy monoliths that may benefit more from refactoring than a rehosting (“lift and shift”) approach. (Check out Rehost, Refactor, Replatform – What, When, & Why? | AppMod Essentials)
Refactoring may require overhauling your application code, which takes some high-level effort but offers the most benefits. However, not all applications are ideal candidates for refactoring. Rearchitecting will become necessary for some obsolete applications that are not compatible with the cloud due to architectural designs made while building the app. In this scenario, the value proposition considers rearchitecting, dividing the application into several functional components that can be individually adapted and further developed. These small, independent pieces—or “microservices”—can then be migrated to the cloud quickly and efficiently.
Determining the Best Cloud Services Provider for Your Application Modernization
Each application modernization journey is unique, as is the process of choosing the best cloud service provider that meets your demands. What works for one business’ application may not be the best for yours, even if they are in the same industry. And just because a competitor has chosen one CSP over another does not mean you should.
When evaluating the CSP that is best for you, consider the following:
Service Level Agreements (SLAs): Determine if the CSP’s service level agreements suit your production workloads, whether the cloud service is generally available yet, and they retain satisfactory levels of support knowledge. Managing workloads in the cloud can sometimes be tedious. The managed services department may not have the required expertise to efficiently manage and monitor the cloud environment. It is critical to your business to do your due diligence to ensure your preferred CSP can administer their managed offerings with as close to zero downtime as possible.
Vendor Lock-in: It is important to have alternatives to any single CSP and that you retain the flexibility to substitute for a better value proposition.
Enterprise Adoption: Consider the likelihood of scalability of your use of the CSP across your organization.
Economic Impact: Consider the positive business or financial impacts that result from the service usage at the individual, department, and company-wide levels.
Automation and Deployment: Verify the CSP’s integration capabilities with your organization’s preferred automation tooling and availability of automated and local testing frameworks.
When modernizing existing applications to take the best advantage of the cloud, cloud technologies like serverless and containers are good options to consider. Serverless computing and containers are cloud-native tools that automate code deployment into isolated environments. Developers can build highly scalable applications with fewer resources within a short time. They both also reduce overhead for cloud-hosted web applications but differ in many ways. Private cloud, hybrid cloud, and multi-cloud approaches to application modernization are worth considering too.
Serverless Computing and Containers
Serverless computing is an exaction model where the CSP executes a piece of code by dynamically allocating the resources and can only charge for the services used to run the code. Code is typically run in stateless containers. Various events such as HTTP requests, monitoring alerts, database events, queuing services, file uploads, scheduled events (cron jobs), and more can trigger them.
The cloud service provider then receives the code in a function to execute, which is why serverless computing is sometimes referred to as a Function-as-a-Service (FaaS) platform. Add that to your list of as-a-Service acronyms: IaaS, PaaS, SaaS, FaaS!
Containersprovidea discrete environment set up within an operating system. They can run one or more applications, typically assigned only those resources necessary for the application to function correctly. Because containers are smaller and faster than virtual machines, they allow applications to run quickly and reliably among various computing environments. Container images become containers at runtime and include everything needed to run an application: code, runtime, system tools, system libraries, and settings.
Private, Hybrid, and Multi-Cloud
The public cloud is a vital part of any modernization strategy. However, some organizations may not be ready to go directly to the public cloud from the datacenter. Cloud architects should consider private, hybrid, and multi-cloud strategies in those cases. These models can help resolve any architectural, security, or latency concerns. They will also reduce the complexity associated with the policies for specific workloads based on their unique characteristics.
Migration to the cloud is ideal for investing in application modernization as it can lower your overall operational costs and increase your application’s resiliency. But not all use cases—nor cloud service providers—are the same. You need to do your homework before choosing the best-suited one for your business.
2nd Watch offers a comprehensive consulting methodology and proven tools to accelerate your cloud-native and app modernization objectives. Our modernization process begins with a complete assessment of your existing application portfolio to identify which you should keep, replace, retire, or consolidate. We then develop and implement a modernization strategy that best meets your business needs.
From application rationalization to application modernization and beyond, 2nd Watch is your go-to trusted advisor throughout your entire modernization journey.
Contact us to schedule a brief meeting with our specialists to discuss your current modernization objectives.
Migrating workloads or an application to the cloud can seem daunting for any organization. The cloud is synonymous with industry buzzwords such as DevOps, digital transformation, opensource, and more. As of 2021, AWS has over 200 products and services.
Nowadays, every other LinkedIn post is somehow related to the cloud. Sound familiar? Maybe a bit intimidating? If so, you are not alone! Organizations often hope that operating in the cloud will help them become more agile, enhance business continuity, or reduce technical debt. All of which are achievable in a cloud environment with proper planning.
Benjamin Franklin once said, “By failing to prepare, you are preparing to fail.” This sentiment is true not only in life but also in technology. Any successful IT project has a strategy and tangible business outcomes. Project managers must establish these before any “actual work” begins. Without this, leadership teams may not know if the project is on task and on schedule. Technical teams may struggle to determine where to start or what to prioritize. Here we’ll explore industry-standard strategies that organizations can deploy to begin their cloud journey and help technical leaders decide which path to take.
What is Cloud Migration?
Cloud migration is when an organization decides to move its data, applications, or other IT capabilities into a cloud service provider (CSP) such as Amazon Web Services (AWS), Google Cloud Platform (GCP), or Microsoft Azure. Some organizations may decide to migrate all IT assets into the cloud; however, most organizations keep some services on-premises in a hybrid environment for various reasons. Performing a migration to the cloud may consist of multiple CSPs or even a private cloud.
What Are the Different Strategies for Cloud Migration?
Gartner recognizes five cloud migration strategies, nicknamed “The 5Rs.” Individually they are called rehost, refactor, revise (a.k.a. replatform), rebuild, and replace, each with benefits and drawbacks. This blog focuses on three of those five migration approaches—rehost, refactor, and replatform—as they play a significant role in application modernization.
What is Rehost in the Cloud?
Rehost, or “lift and shift,” is the process of migrating a workload into the cloud as-is without any modifications. Rehosting usually involves infrastructure-as-a-service (IaaS) technologies in a cloud provider such as AWS EC2 or Azure VM’s. Organizations with little cloud experience may consider this strategy because it is an easy start to their cloud journey. Cloud service providers are constantly creating new services for rehosting to make the process even easier. This strategy is less complex, so the timeline to complete a rehost migration can be significantly shorter than other strategies. Organizations often rehost workloads and then modernize after gaining more cloud knowledge and experience.
No architecture changes – Organizations can migrate workloads as-is, which benefits those with little cloud experience.
Fastest migration method – Rehosting is often the quickest path to the cloud. This method is an excellent advantage for organizations that need to vacate an on-premises data center or colocation.
Organizational changes are not necessary – Organizational processes and strategies to manage workloads can remain the same since architectures are not changing. Organizations will need to learn new tools for the selected cloud provider, but the day-to-day tasks will not change.
High costs – Monthly spending will quickly add up in the cloud without modernizing applications. Organizations must budget appropriately for rehosting migrations.
Lack of innovation – Rehosting does not take advantage of the variety of innovative and modern technologies available in the cloud.
Does not improve the customer experience – Without change, applications cannot improve, which means customers will have a similar experience in the cloud.
What Refactor Means?
Use the refactoring technique to update and optimize applications for the cloud. Refactoring often involves “app modernization” or updating the application’s existing code to take full advantage of cloud features and flexibility. This strategy can be complex because it requires source code changes and introduces modern technologies to the organization. These changes will need to be thoroughly tested and optimized, leading to possible delays. Therefore, organizations should take small steps by refactoring one or two modules at a time to correct issues and gaps at a smaller scale. Although refactoring may be the most time-consuming, it can provide the best return on investment (ROI) once complete.
Cost reduction – Since applications are being optimized for the cloud, refactoring can provide the highest ROI and reduce the total cost of ownership (TCO).
More flexible application architectures – Refactoring allows application owners the opportunity to explore the landscape of services available in the cloud and decide which ones fit best.
Increased resiliency – technologies and concepts like auto-scaling, immutable infrastructure, and automation can increase application resiliency and reliability. Organizations should consider all of these when refactoring.
A lot of change – Technology and cultural changes can be brutally painful. Cloud migrations often combine both, which compounds the pain. Add the complexity of refactoring, and you may have full-blown mutiny without careful planning and strong leadership. Refactoring migrations are not for the faint of heart, so tread lightly.
Advanced cloud knowledge and experience are needed – Organizations lacking cloud experience may find it challenging to refactor applications by themselves. Organizations may consider using a consulting firm to address skillset gaps.
Lengthy project timelines – Refactoring hundreds of applications doesn’t happen overnight. Organizations need to establish realistic timelines before starting a refactor migration.
What is Replatform in Cloud?
Replatforming is a happy medium between refactoring and rehosting and applies a series of changes to the application to fit the cloud better without rearchitecting the whole thing versus completely overhauling the application as you would expect from refactoring. Replatforming projects often involve rearchitecting the database to a more cloud-native solution, adding scaling mechanisms, or containerizing applications.
Reduces cost – If organizations take cost-savings measures during replatforming, they will see a reduction in technical operating expenses.
Acceptable compromise – Replatforming is considered a happy medium of adding features and technical capabilities without jeopardizing migration timelines.
Adds cloud-native features – Replatforming can add cloud technologies like auto-scaling, managed storage services, infrastructure as code (IaC), and more. These capabilities can reduce costs and improve customer experience.
Scope creep may occur – Organizations may struggle to draw a line in the sand when replatforming. It can be challenging to decide which cloud technologies to prioritize.
Limits the amount of change that can occur – Everything cannot be accomplished at once when replatforming. Technical leaders must decide what can be done given the migration timeline then add the remaining items to a backlog.
Cloud and automation skills needed – Organizations lacking cloud experience may struggle replatforming workloads by themselves.
Which cloud migration strategy is best for your organization?
As stated above, it is essential to have clear business objectives for your organization’s cloud migration. Just as important is establishing a timeline for the migration. Both will help technical leaders and application owners decide which strategy is best. Below are some common goals organizations have for migrating to the cloud.
Common business goals for cloud migrations:
Reduce technical debt
Improve customer’s digital experience
Become more agile to respond to change faster
Ensure business continuity
Evacuate on-premises data centers and colocations
Create a culture of automation
Determining the best migration strategy is key to getting the most out of the cloud and meeting your business objectives. It is common for organizations to use all three of these strategies in tandem and often work with trusted advisors like 2nd Watch to determine and implement the best. When planning your cloud migration strategy, consider these questions:
Cloud Migration Strategy Considerations:
Is there a hard date for migrating the application?
How long will it take to modernize?
What are the costs for “lift and shift,” refactoring, and/or replatforming?
When is the application being retired?
Can the operational team(s) support modern architectures?
In today’s world, the cloud is where the most innovation in technology occurs. Companies that want to be a part of modern technology advancements should seriously consider migrating to the cloud. Organizations can achieve successful cloud migrations with the right strategy, clear business goals, and proper skillsets.
2nd Watch is an AWS Premier Partner, Google Cloud Partner, and Microsoft Gold partner, providing professional and managed cloud services to enterprises. Our subject matter experts and software-enabled services provide you with tested, proven, and trusted solutions in all aspects of cloud migration and application modernization.
Contact us to schedule a discussion on how we can help you achieve your 2022 cloud modernization objectives.
To be successful in today’s landscape, organizations must deliver memorable customer experiences, demonstrate innovation, and be adaptable to the constant shifts of the marketplace. Embracing cloud technology is imperative to achieve these high levels of scalability and agility while minimizing current and future technical debt. However, moving to the cloud is only one (albeit significant) component of modernizing a business’s applications. Application modernization is a must.
Application modernization is when you take existing legacy applications and digitally transform their platform infrastructure, internal architecture, and/or features. It’s going from tightly-coupled systems with various dependencies to loosely-coupled ones that improve application scalability, resilience, and extensibility. The goal of application modernization is to create a more agile, flexible, and highly available application environment.
However, simply lifting and shifting complex monolithic applications to a public cloud service provider is not equivalent to becoming a modern enterprise. Migrating to the cloud can help speed up innovation, but if businesses do not build cloud-native applications, they are simply moving workloads. To maximize the benefits of the cloud and become a modern business, organizations must strive to be cloud-native.
Why is migration to the cloud necessary for application modernization?
One of the top reasons to migrate to the cloud is to increase business agility, velocity, and scalability. Companies also enjoy increased productivity and efficiency of their workforce when they utilize cloud infrastructure. The cloud enables organizations to digitally transform their business with modern technologies and reestablish their applications within a modern framework.
When a business migrates to the cloud, that shouldn’t be considered the “finish line” in its modernization journey. The cloud is a means to an enterprise’s modernization efforts. An organization also has to update its culture and processes to enable high-performing software development if it is truly looking to modernize its application environment.
Why is application modernization necessary?
The bottom line is that modernizing applications will generate more business. Refusing to update infrastructure, technology, applications, and approaches to software development will place a company significantly behind in a race where there are very responsive and innovative competitors. Enterprises that were not born digital must evolve quickly to stay afloat in today’s ultra-demanding landscape.
Application modernization is not simply a survival tactic, but it is also a crucial method to achieve business agility. Digital transformation offers some of the following measurable outcomes and benefits to a company:
Optimize costs and resources
Modernizing applications utilizing cloud service providers can save businesses money. Planning a cloud migration can significantly reduce the total cost of ownership (TCO), allowing organizations to focus on their core business and missions rather than expending energy on managing servers and on-premise infrastructures.
Additionally, by using cloud platforms, enterprises have access to a variety of robust services and automation tools that will eventually result in noticeable savings and cost optimization both of time and money. Deploying enterprise solutions via a cloud service provider allows organizations to retire expensive legacy infrastructure, reduce time and fiduciary costs, experience agility through automation, and reallocate resources towards other imperative business needs.
The migration process to the cloud requires working with a provider who has experience in retiring legacy systems and emerging technologies to migrate databases, servers, and data. Working with a cloud service provider and/or a cloud advisory firm enables businesses to modernize their applications smoothly. Cloud partners provide access to the vital tools and knowledge needed to digitally transform a business. Harnessing the power of cloud-native firms can improve operational efficiency, increase scalability, and improve the overall performance of an organization.
What are the steps of application modernization?
For most enterprises, app modernization is the clear path forward. The question is not whether to modernize but “what” and “how” to modernize. To answer these crucial questions about their legacy applications, organizations need to understand their modernization options and have a deep insight into their applications.
Application modernization is much more than simply migrating to cloud-based workloads. It is the total transformation of an organization’s culture, tools, and processes. Below is a step-by-step strategy for continuous application modernization:
#1: Create Goals for Modernization
Goals will always be the foundation of any strong strategy. Without goals, measuring the success of modernization efforts will be incredibly difficult, if not impossible. You have to detail your goals for app modernization and link modernization efforts to measurable business outcomes. For example, greater agility and faster time-to-market with new features can show progress and success as a business embarks on its modernization journey.
Organizations should identify the highest priority and most critical applications to kick off the goal-setting process. From there, they should analyze how the company would benefit from increased reliability, scalability, and performance by leveraging their cloud service provider. Areas of impact can include revenue, market share churn, profitability, and more.
After an enterprise has clearly defined how current applications will impact their business success, they can then tie modernization objectives and priorities back to business outcomes.
#2: Understand Your Applications
Before a business can transform its applications, it must recognize its starting point. An organization should take a baseline measurement to understand how its applications are performing. This baseline allows businesses to identify and prioritize the best approach to application modernization for each app and will serve as the foundation for creating the road map for application modernization.
Companies must invest in an observability platform to aggregate, correlate and analyze performance data. Without this, they cannot make data-driven decisions because there is no true understanding of how an application is currently functioning and if modernization is improving it. Observability allows enterprises to capture data about each application to help understand their specific characteristics. This objective and holistic view of applications empowers organizations to decide how to best modernize an application.
#3: Determine the Optimal Modernization Approach for Each Application
After setting goals and collecting data, companies are ready to make data-driven decisions on modernizing their applications. There are three approaches to app modernization: rehosting, replatforming, and refactoring.
Rehosting entails shifting an application to a more modern environment, such as the cloud, to reap cost savings, performance improvements, and ease of operations. The changes only pertain to rehosting; therefore, this approach’s risk and impact are low.
Replatforming is when companies move an application and modify some infrastructure elements for time and resource-saving purposes. Replatforming requires taking an existing component of an application and moving it to a managed service with no changes to business logic. The risk is still low because of infrastructure modifications, but the impact is medium.
Refactoring requires businesses to re-architect an application to optimize and realize the full benefits of cloud services, architectures, and technologies. It allows for improved quality, performance, and the rapid delivery of innovative new features. Re-architecting applications require making code-level changes, so the risk of refactoring is high but ultimately yields a more significant impact.
#4: Observe and Optimize
Taking a baseline measurement in step two gives companies the data to make informed decisions and serves as a comparison during and after modernization efforts. Once the first modernization iteration is complete, organizations can track their goals and demonstrate success by comparing the previous baseline against current performance and other KPIs, such as business outcome data and customer experience. The hope is to see improvements and identify additional modernization opportunities to achieve peak cloud optimization.
Modernization is continuous
The strategy, as mentioned above, is a never-ending process and should be repeated. There will always be new tools and capabilities for companies to discover, incorporate, and support throughout app modernization.
Each iteration of modernization is an opportunity for enterprises to embrace digital transformation holistically. An application modernization strategy is not simply lifting and shifting platforms; it also reshapes an organization’s culture and processes necessary for truly modernizing a business.
2nd Watch offers a comprehensive consulting methodology and proven tools to accelerate your cloud-native and app modernization objectives. Our modernization process begins with a complete assessment of your existing application portfolio to identify which you should keep, replace, retire, or consolidate. We then develop and implement a modernization strategy that best meets your business needs. From application rationalization to application modernization to DevOps transformation and beyond, 2nd Watch is your go-to partner throughout your entire modernization journey.
Contact us to schedule a brief meeting with our specialists to discuss your current modernization objectives.
The cloud market is maturing, and organizations worldwide are well into implementing their cloud strategies. In fact, a recent McKinsey survey estimates that, by 2022, 75% all workloads will be running in either public or private clouds. Additionally, according to VMWare, 72% of businesses are looking for a path forward for their existing applications, and it is important to consider an app modernization strategy as part of these migration efforts.
Whether it be a desire to containerize, utilize cloud-native services, increase agility, or realize cost savings, the overall goal should be to deliver business value faster in the rapidly changing cloud environment.
Application modernization has a focus on legacy or “incumbent” line of business applications, and approaches range anywhere between re-hosting from the datacenter to cloud, to full cloud native application rewrites. We prefer to take a pragmatic approach, which is to address issues with legacy applications that hinder organizations from realizing the benefits of modern software and cloud native approaches, while retaining as much of the intellectual property that has been built into incumbent applications over the years as possible. Additionally, we find ways of augmenting existing code bases to make use of modern paradigms.
Application Modernization Strategies
When approaching legacy software architecture, people often discuss breaking apart monolithic applications and microservices. However, the most important architectural decisions should be centered around how to best allow the application to function well in the cloud, with scalability, fault-tolerance, and observability all being important aspects. A popular approach is to consider the tenants of the 12-Factor App to help guide these decisions.
Architecture discussions go hand in hand with considering platforms. Containerization and serverless functions are popular approaches, but equally valid is traditional VM clustering or even self-hosting. Additionally, we start to think about utilizing cloud services to offload some application complexity, such as AWS S3 for document storage or AWS KMS for key management. This leads us to consider different cloud providers themselves for best fit for the organization and the applications overall, whether it be AWS, Azure, GCP (Google cloud platform), or hybrid-cloud solutions.
Another very important aspect of application modernization, especially in the cloud, is ensuring that applications have proper automation.
Strong continuous integration and continuous deployment (CI/CD) pipelines should be implemented or enhanced for legacy applications. Additionally, we apply CD/CI automation for deploying database migrations and performing infrastructure-as-code (IaaC) updates, and ensure paradigms like immutable infrastructure (i.e. pre-packaging machine images or utilizing containerization) are utilized.
Last, there is an important cultural aspect to modernization from an organizational to team level. Organizations must consider modernization a part of their overall cloud strategy and support their development teams in this area. Development teams must adapt to new paradigms to understand and best utilize the cloud – adopting strong DevOps practices and reorganizing teams along business objectives instead of technology objectives is key.
Modernizing software architecture is often described as splitting a monolithic codebase but can imply any improvements to the software itself, such as decoupling of components or addressing tech debt in the codebase. Other examples might be finding new design patters that allow for scale, addressing resiliency within an application or improving observability through logs and tracing.
What is Meant by App Modernization?
Application modernization is the process of migrating an incumbent or legacy software application to modern development patterns, paradigms and platforms with the explicit purpose of improving business value. It’s a part of your entire application modernization strategy and implies improving the software architecture, application infrastructure, development techniques and business strategy using a cloud native approach. Essentially, it allows you to derive increased business value from your existing application code.
We often think of application modernization in the context of cloud, and when planning a migration to cloud or modernizing an application already in the cloud, we look at what services and platforms are beneficial to the effort. Utilizing a service such as Amazon S3 for serving documents instead of a network share or utilizing ElasticSearch instead of the database for search are examples of infrastructure improvements. Containerization and other serverless platforms are also considered.
Development techniques also need to be addressed in the context of modernization. Developers should focus on the parts of the application that deliver value to customers and provide competitive advantage.
If developers are focused on maintenance, long manual deployments, bugs, and log investigation, they are unable to deliver value quickly.
When working with modern distributed cloud applications, teams need to follow strong DevOps practices in order to be successful. CI/CD, unit testing, diagnostics and alerting are all areas that development teams can focus on modernizing.
Legacy Application and Legacy Systems
In this context, legacy software refers to an incumbent application or system that blocks or slows an organization’s ability to accomplish its business goals. These systems still provide value and are great candidates for modernization.
Legacy can imply many things, but some common characteristics of legacy apps are:
Applications that run older libraries, outdated frameworks, or development platforms or operating systems that are no longer supported.
Architectural issues – monolithic or tightly coupled systems can lead to difficulties in deployment, long release cycles and high defect rates.
Large amounts of technical debt, dead or unused code, teams who no longer understand how older parts of the application work, etc.
Security issues caused by technical debt, outdated security paradigms, unpatched operating systems, and improper secret management.
Lack instrumentation with no way to observe the application.
Maintain session state on the client (require sticky sessions, etc.).
Manually deployed or must be deployed in specific ways due to tight coupling.
Pillars of Application Modernization
When approaching a modernization project, we specifically look to ensure the following:
The modernization initiative should follow a distributed computing approach, meaning it should take advantage of concepts such as elasticity, resiliency, and containerization. Converting applications to adhere to the principals of the “12-factor app” in order to take advantage of containerization is a prime example.
The application must be built, tested and deployed using modern CI/CD processes. Older source control paradigms such as RCS or SVN should be replaced with distributed version control systems (git). Infrastructure as code should be included as part of the CI/CD system.
Holistically integrate logs, metrics, and events enabling “the power to ask new questions of your system, without having to ship new code or gather new data in order to ask those new questions” (Charity Majors https://www.honeycomb.io/blog/observability-a-manifesto). Observability is key to understanding performance, error rates, and communication patterns and enables the ability to measure your system and establish baselines.
Application teams should be aligned along business function, not technology, meaning multi-disciplinary teams that can handle operations (DevOps), database, testing (QA) and development. A culture of ownership is important in a cloud-native application.
App Modernization Examples
Application Modernization is not:
Just containerization – To take full advantage of containerization, applications must be properly architected (12-factor), instrumented for observability and deployed using CI/CD.
Just technical solutions adapting the latest framework or technology – The technology might be “modern” in a sense but doesn’t necessarily address cultural or legacy architectural issues.
Just addressing TCO – Addressing cost savings without addressing legacy issues does not constitute modernization.
Just running a workload in the cloud
Just changing database platforms – Licensing issues or the desire to move to open source clustered cloud databases does not equate to modernization.
Limited to a specific programming languages or specific cloud providers as a hybrid cloud approach can be deployed.
Application modernization includes, among others, combinations of:
Moving a SaaS application from a single to multi-tenant environment.
Breaking up a monolithic application into microservices.
Applying event driven architecture to decouple and separate concerns.
Utilizing cloud services such as S3 to replace in-house solutions.
Refactoring to use NoSQL technologies such as MongoDB, ElasticSearch, or Redis.
Containerization and utilization of PaaS technologies such as Kubernetes or Nomad.
Utilization of Serverless (FaaS) technologies such as AWS Lambda, Azure Functions, OpenFaas, or Kubeless.
Creating strong API abstractions like REST or gRPC and utilizing API Gateways.
Transitioning to client-side rendering frameworks (React, Vue.js, etc.) and serverless edge deployment of UI assets, removing the webserver.
Moving long running synchronous tasks to asynchronous batch processes.
Utilizing saga patterns or business process workflows.
Will ultimately focus on enhancing business applications, improving customer experience, and enable rapid digital transformation for the organization.