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.
Withoutcloud cost governance, your organization will suffer O2: Overprovisioning and Overspending. You’re left confused because this is theexact opposite result you thought cloud migration would have. Additionally, if you find yourself in this predicament, you have difficulty pinpointing areas for improvement to initiate corrective action.
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.
Conclusion
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
Staff Productivity
Operational Resilience
Business Agility
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:
Benefits
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.
CCOC – Mixed Results
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:
Resource constraints
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
SLA metrics
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
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.
Conclusion
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 you moved to the cloud to take advantage of rapid infrastructure deployment and development support, you understand the power of quickly bringing applications to market. Gaining a competitive edge is all about driving customer value fast. Immersing a company in a DevOps transformation is one of the best ways to achieve speed and performance.
In this blog post, we’re building on the insights of Harish Jayakumar, Senior Manager of Application Modernization and Solutions Engineering at Google, and Joey Yore, Manager, and Principal Consultant at 2nd Watch. See how the highest performing teams in the DevOps space are achieving strong availability, agility, and profitability with application development according to key four metrics. Understand the challenges, solutions, and potential outcomes before starting your own DevOps approach to accelerating app development.
Beyond the fact that DevOps combines software development (Dev) and IT operations (Ops), DevOps is pretty hard to define. Harish thinks the lack of a clinical, agreed-upon definition is by design. “I think everyone is still learning how to get better at building and operating software.” With that said, he describes his definition of DevOps as, “your software delivery velocity, and the reliability of it. It’s basically a cultural and organizational moment that aims to increase software reliability and velocity.”
The most important thing to remember about a DevOps transformation and the practices and principles that make it possible is culture. At its core, DevOps is a cultural shift. Without embracing, adopting, and fostering a DevOps culture, none of the intended outcomes are possible.
Within DevOps there are five key principles to keep top of mind:
Reduce organizational silos
Accept failure as the norm
Implement gradual changes
Leverage tooling and automation
Measure
Measuring DevOps: DORA and CALMS
Google acquired DevOps Research and Assessment (DORA) in 2018 and relies on the methodology developed from DORA’s annual research to measure DevOps performance. “DORA follows a very strong data-driven approach that helps teams leverage their automation process, cultural changes, and everything around it,” explains Harish. Fundamental to DORA are four key metrics that offer a valid and reliable way to measure the research and analysis of any kind of software delivery performance. These metrics gauge the success of DevOps transformations from ‘low performers’ to ‘elite performers’.
Deployment frequency: How often is the organization successfully released to production
Lead time for changes: The amount of time it takes a commit to get into production
Change failure rate: The percentage of deployments causing a failure in production
Time to restore service: How long it takes to recover from a failure in production
DORA is similar to the CALMS model which addresses the five fundamental elements of DevOps starting with where the enterprise is today and continuing throughout the transformation. CALMS also uses the four key metrics identified by DORA to evaluate DevOps performance and delivery. The acronym stands for:
Culture: Is there a collaborative and customer-centered culture across all functions?
Automation: Is automation being used to remove toil or wasted work?
Lean: Is the team agile and scrappy with a focus on continuous improvement?
Measurement: What, how, and against what benchmarks is data being measured?
Sharing: To what degree are teams teaching, sharing, and contributing to cross-team collaboration?
DevOps Goals: Elite Performance for Meaningful Business Impacts
Based on the metrics above, organizations fall into one of four levels: low, medium, high, or elite performers. The aspiration to achieve elite performance is driven by the significant business impact these teams have on their overall organization. According to Harish, and based on research by the DORA team at Google, “It’s proven that elite performers in the four key metrics are 3.56 times more likely to have a stronger availability practice. There’s a strong correlation between these elite performers and the business impact of the organization that they’re a part of. ”
He goes on to say, “High performers are more agile. We’ve seen 46 times more frequent deployments from them. And it’s more reliable. They are five times more likely to exceed any profitability, market share, or productivity goals on it.” Being able to move quickly enables these organizations to deliver features faster, and thus increase their edge or advantage over competitors.
Focusing on the five key principles of DevOps is critical for going from ideation to implementation at a speed that yields results. High and elite performers are particularly agile with their use of technology. When a new technology is available, DevOps teams need to be able to test, apply, and utilize it quickly. With the right tools, teams are alerted immediately to code breaks and where that code resides. Using continuous testing, the team can patch code before it affects other systems. The results are improved code quality and accelerated, efficient recovery. You can see how each pillar of DevOps – from culture and agility to technology and measurement, feeds into one another to deliver high levels of performance, solid availability, and uninterrupted continuity.
Overcoming Common DevOps Challenges
Because culture is so central to a DevOps transformation, most challenges can be solved through cultural interventions. Like any cultural change, there must first be buy-in and adoption from the top down. Leadership plays a huge role in setting the tone for the cultural shift and continuously supporting an environment that embraces and reinforces the culture at every level. Here are some ways to influence an organization’s cultural transformation for DevOps success.
Build lean teams: Small teams are better enabled to deliver the speed, innovation, and agility necessary to achieve across DevOps metrics.
Enable and encourage transparency: Joey says, “Having those big siloed teams, where there’s a database team, the development team, the ops team – it’s really, anti-DevOps. What you want to start doing is making cross-functional teams to better aid in knocking down those silos to improve deployment metrics.”
Create continuous feedback loops: Among lean, transparent teams there should be a constant feedback loop of information sharing to influence smarter decision making, decrease redundancy, and build on potential business outcomes.
Reexamine accepted protocols: Always be questioning the organizational and structural processes, procedures, and systems that the organization grows used to. For example, how long does it take to deploy one line of change? Do you do it repeatedly? How long does it take to patch and deploy after discovering a security vulnerability? If it’s five days, why is it five days? How can you shorten that time? What technology, automation, or tooling can increase efficiency?
Measure, measure, measure: Utilize DORAs research to establish elite performance benchmarks and realistic upward goals. Organizations should always be identifying barriers to achievement and continuously improving on measurements toward improvement.
Aim for total performance improvements: Organizations often think they need to choose between performance metrics. For example, in order to influence speed, stability may be negatively affected. Harish says, “Elite performers don’t see trade-offs,” and points to best practices like CICD, agile development, and tests, built-in automation, standardized platform and processes, and automated environment provisioning for comprehensive DevOps wins.
Work small: Joey says, “In order to move faster, be more agile, and accelerate deployment, you’re naturally going to be working with smaller pieces with more automated testing. Whenever you’re making changes on these smaller pieces, you’re actually lowering your risk for anyone’s deployment to cause some sort of catastrophic failure. And if there is a failure, it’s easy to recover. Minimizing risk per change is a very important component of DevOps.”
Both Harish and Joey agree that the best approach to starting your own DevOps transformation is one based on DevOps – start small. The first step is to compile a small team to work on a small project as an experiment. Not only will it help you understand the organization’s current state, but it helps minimize risk to the organization as a whole. Step two is to identify what your organization and your DevOps team are missing. Whether it’s technology and tooling or internal expertise, you need to know what you don’t know to avoid regularly running into the same issues.
Finally, you need to build those missing pieces to set the organization up for success. Utilize training and available technology to fill in the blanks, and partner with a trusted DevOps expert who can guide you toward continuous optimization.
2nd Watch provides Application Modernization and DevOps Services to customize digital transformations. Start with our free online assessment to see how your application modernization maturity compares to other enterprises. Then let 2nd Watch complete a DevOps Transformation Assessment to help develop a strategy for the application and implementation of DevOps practices. The assessment includes analysis using the CALMS model, identification of software development and level of DevOps maturity, and delivering tools and processes for developing and embracing DevOps strategies.
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.
Conclusion
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.
Rehosting Pros:
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.
Rehosting Cons:
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.
Refactoring Pros:
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.
Refactoring Cons:
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.
Replatorming Pros:
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.
Replatforming Cons:
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?
Conclusion
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.
