March 4, 2021
TABLE OF CONTENTS
In this new video series from Levvel, our industry experts discuss why some organizations struggle to adopt the cloud, ways to determine which cloud strategy is the right path for your business, and industry best practices when embarking on a cloud migration journey. We share relevant stories from the field and how we’ve helped businesses overcome their biggest challenges.
For more videos from our cloud experts, check out Levvel’s The Enterprise Value of Cloud Migration and The Cloud Migration Journey series.
This report highlights the main issues organizations face when deploying cloud environments, offers solutions to overcome these technological challenges, and serves as an educational guide to determine your migration and cloud management plan.
Samantha Rafalowski: A lot of organizations struggle to adopt the cloud for many reasons. I think we are all familiar with resource constraints being one of the bigger reasons. A lot of times people don’t have the staff with the proper knowledge to deal with these migrations. On the other hand, budget and time constraints, end up being synonymous a lot of times with these big organizations. This is because people might tend to view migrations as a sunk cost, which is a bit of a logical fallacy.
Once you invest in all of these resources and can fill in those gaps with the budget constraints, then you’re going to be able to save a lot more money and have a much easier time developing your software applications and updating your business to meet changing requirements. That’s probably one of the bigger issues that is most commonly talked about. Those are obviously very viable reasons, but it’s my belief that it’s one of those things where you have to bite the bullet. And once you’re able to get the resources that you need, that issue falls by the wayside.
CJ Coimbatore: You can think of many different challenges in identifying, attracting, and retaining talent. For example, what is a good way for you who’s had little to no experience in operating on the cloud at scale, how are you going to determine if an individual has the appropriate amount of experience? What are the right questions you’re going to ask this individual?
How are you going to evaluate this individual through the hiring process? The challenge is also that today you find a significant amount of individuals who are certified in that space. Maybe you have a candidate that you’re talking to who is certified in a certain public cloud provider’s architecture or solutioning, any number of those areas.
Now is that sufficient for the challenges that you’re trying to solve? Does this individual have the appropriate experience? There are a lot of questions and while you try to eliminate the possibility of hiring right, you are now getting into a situation where you are also trying to deliver because you’ve already made promises to business.
And there are outcomes that have been committed to. As you’re trying to work through your resourcing gaps, you’re also trying to understand an environment that you’re not familiar with and hiring for that environment. And you still have a business that you need to deliver to.
Anna Barnett: When you’re looking at talent, it takes a special skill set and knowledge to be able to manage public cloud environments. To understand and manage the security and compliance factors that come with managing all your workloads and data in the cloud. And a lot of times the fear of that, of not having that, keeps companies from migrating or they’ll start migrating certain workloads and realize they don’t have the people in-house to manage that.
Especially if you’re coming from a less modern organization and you have a lot of legacy systems, maybe you have legacy tech stacks, a lot of your talent resources are going towards maintaining those maybe outdated technology stacks, that the number of developers who understand that language is small and expensive.
So you’ve put your resources in that bucket and maybe not focused on building your talent pool that understands more of the modern technologies and understands true cloud optimization and how to run that sustainably. So when a company says we started moving our workloads, but we stopped because of security concerns.
That doesn’t always mean, and it actually rarely means, we had a security breach or something. It often means we don’t know what we’re doing, or we don’t know what these cloud solutions can do for us. We don’t have people in-house that can help us there. One of the best things that you can do is to see that pitfall coming, and to invest in the talent and the knowledge beforehand.
Sometimes that can be outsourcing certain functions to specialized groups. Sometimes that can be hiring, a lot of times that’s bringing in a third party consultancy to help you with migration and help you set up tech shops that truly understand the cloud environment that you’re moving into.
And working closely with a cloud provider that can communicate how their solution works for you. The security and compliance, for example, the services available in public cloud providers are really advanced, they are much stronger than if you tried to continue operating on-premise, but you do have to know what you are doing, and find a partner that will help you grow your talent pool.
Samantha Rafalowski: A lot of organizations are really hesitant to retire some of their legacy applications and that results in them staying in the hybrid sector of cloud a little bit longer than necessary. And longer than would actually benefit their business
CJ Coimbatore: In addition to that they are any number of other challenges, for example, another area that companies have either struggled with their cloud adoption strategies, or even had to roll back their plans to adopt the cloud has been in their inability to identify workloads that can be moved to the cloud. So think of it this way.
You have a lot of applications, a lot of a system systems of record that exists within your infrastructure that predominantly is on-premise. And now you’re trying to identify an application that you can move to the cloud, maybe as your first workload. And one of the criteria that you chose was to find a workload that has as few dependencies as possible on systems of record or solutions and systems that exist within your on-premise environment.
And so what we found is that initially when they started the journey they thought either the application had no dependencies so very few dependencies. But come to find out as they get further along in that journey and they either want to enhance the application or scale the application, they are unable to because of the number of dependencies on on-premises systems increases. And that puts a significant amount of strain on any data bridge that you’ve built between your on-premise, compute and storage. And all of your infrastructure with what you have in the cloud.
So these are obviously some of the challenges that we’ve encountered. There are any number of others that you can highlight. For example, security and compliance teams are unable to translate with the level of detail that they’ve been able to on-premise in the cloud. Because, one, they probably don’t understand or completely comprehend the environment as much. And then of course, is the mind shift which is, think of how you looked at compute, you looked at storage, you looked at software solutions. You have a procurement process. You evaluate your competitive options, and then you come up and operationalize whatever choice you’ve made.
However, there’s a completely different option that is available when you go to the cloud, which is there are any number of services either available within that cloud provider as a native service, which you can consume. And in the same fashion pay as you go model. Or you can consume any SaaS offerings or acquire your own license and provision the necessary infrastructure, and also operationalize that stack. People who are either not aware or don’t have the requisite experience in this space and are often challenged. I think these are some of the reasons why organizations struggle in their cloud adoption journeys.
Srinivas Coimbatore: As the cloud started to become more pervasive in terms of what it could provide, at least in terms of elastic infrastructure, your ability to get into an OPEX model instead of a CAPEX model and all of the benefits you can kind of think of when it comes to the cloud. The challenge really has been what is that sweet spot. How much of the workloads do you leave on-premises? And how much of it do you put on the cloud? Do you abandon on-premises over a period of time? What are your short-term and long-term goals?
Anna Barnett: One thing that I get asked a lot by clients and people that I’m doing research with is, what’s the best way to migrate to the cloud? Is it the hybrid approach or the fully cloud-native approach? And is it okay for us to keep some workloads on-premises and hybrid in that hybrid scenario? I think, and Levvel’s position is that the best-case scenario for almost every company, in the long run, is a fully native public cloud environment.
That’s going to be sustainable, that’s going to be cost-efficient, and as the world becomes more technologically dependent and advanced, you’re going to need to be in the cloud. However, we do also acknowledge that this isn’t just a flip the switch kind of thing. A lot of companies have unique business models or resource constraints and hybrid models or part private, part public cloud environments, that’s going to have to be the reality for them.
When you’re looking at resource constraints, totally understand that you realize that moving to the public cloud is going to be an expensive investment, not necessarily because of the solution provider costs, but because of all of the reorg, the talent investment, the re-optimization that you’re going to need to do, the time. But you do want to start that journey because, in the long run, it’s going to be best for your business. So one of the things you can do there is reevaluate which workloads are going to move and make sure that you’re doing the most strategic first.
There’s a difference between intentionally hybrid and interim hybrid. Of course, when you’re moving from mostly on-premises to the public cloud, you’re going to be a hybrid for a while. And you’re going to see a big increase in costs during that time as any technology investment is expensive. Our data shows that across the board when companies fit in that hybrid bucket, they’re spending much more than if they stayed on-premises.
But the question is, are you going to stay in that hybrid environment or are you moving on? Because as you keep moving on, data shows that the costs go way down. There’s a big dip. So for organizations that are moving towards the public, keep going, you’re going to see huge savings. Organizations that we surveyed, we ask them if they’ve seen a cost reduction since moving to the cloud.
Companies who chose public environments were, I think over 40% more likely to say yes than companies who chose hybrid environments. We asked organizations about their unplanned outages, companies who chose hybrid environments reported slightly more unplanned outages than companies who were in public. I know there’s a lot of factors that go into unplanned outages, but there’s definitely less control over that than you have when your workloads are in different systems.
Samatha Rafalowski: Determining the right path for your business really requires you to fully understand business needs, what your operational spend is looking like, your long-term goals, and consider even your vendor usage. So when you are thinking about what your final stage of hosting should look like, you need to think about all of these things. You need to have a budget front of mind. If the budget is the most important thing, more likely than not public cloud is probably going to be the answer for you. Of course, there are exceptions to that.
I actually had a client of mine who had a really good working relationship with vSphere Cloud, which is a newer private cloud. And I have not worked a lot with them, but because this client had so much business that they were going to be bringing to vSphere, vSphere was able to cut them a deal so that they were actually going to be saving just as much, maybe a little bit more in the private cloud.
This is a little rare because that would require you to have a working relationship with some of these vendors. But again, it is something to keep in mind when you’re making this decision, because those are the exceptions to the rule that I’m talking about when I say public cloud isn’t for everyone. But mostly it is.
Srinivas Coimbatore: So when you look at all of these challenges, the most important thing that you have to do is understand that this strategy that you’re going to start your journey with may not be the strategy you retain as you mature. Maybe a year down the road you know a lot more than you did when you started and you make the necessary adjustments. Then you realize this is not something that I can set in stone, but I am going to understand how best to translate the business intent into a strategy that evolves over time.
Samantha Rafalowski: When embarking on a cloud adoption strategy, some big-picture industry best practices to keep in mind are first and foremost, continuously analyzing your workloads. It’s really important to know where you should put your energy, and make sure that focal point doesn’t change. I’ve seen a lot of companies struggle with their cloud migration because they don’t have a specific plan laid out.
And the focused workload that they choose to be the pilot for their migration effort could change halfway through, or they could say, “Just kidding, this is actually too business-critical of an application, so we don’t want to migrate at first because we need it to be up and running 24/7.” Things like that.
Obviously, if you have a business-critical application that does not mean that it’s not able to be migrated to the cloud. You just have to take things like that into consideration and develop a strategy so that you can avoid outages and downtime in your applications.
That being said, I just can’t stress enough how important it is to be analyzing what services you’re using, how these services are interacting together, what are your current pain points, and how do those current pain points affect daily operations? And then what is the business criticality of it? Whatever you are going to be migrating.
So, first and foremost, definitely analyzing your workloads and not having this be a last-minute thought. Your workloads should always be analyzed on a regular basis, especially if they’re changing. Otherwise, your migration plan is really not going to go anywhere if you don’t have those workload analyses as the foundation of it.
Anna Barnett: What are some of the industry best practices that you want to follow when you’re moving towards a cloud migration strategy? That question depends on another question. And that’s where are you in the cloud migration journey? What migration archetype do you fit in? If you’re just starting your migration journey, then you’re probably going to want to look at different things.
One of the first things that you should make sure you do is educate yourself and all the stakeholders. Educate yourself on the impact of migration from an environment standpoint, platform management, and then educate yourself on the solutions. Understand that there’s not a one-size-fits-all for cloud migration, but you do need to go in knowing what’s before you. Educating yourself also prevents you from falling into that lift and shift trap. This isn’t just moving data to a place that now sits on the internet.
This is reorganizing the way that you use data to improve your business. So, that’s the difference between fully informed cloud migration. Another thing if you’re just starting out is to make sure you create a migration plan and that depends heavily on the education.
You could potentially do one step of that migration plan, decide that you’re going to center on one area of workloads for your business and we’ll get to the rest later. You don’t want to get to the rest later. You want to understand where you’re going to go today, in the next 12 months, the next 24 months, and understand how all the different pieces work together.
When we asked organizations in our survey, most companies do a security analysis first when they’re planning for their cloud migration, and then they may do a cloud environment and selection design. Only 40% of companies actually do budgeting when they’re starting out on their cloud migration initiative, which I think is a big reason that money issue comes in and stops people from migrating, or causes it to only migrate a few.
Do that budgeting ahead of time. Do that risk assessment ahead of time. Don’t wait until you get to those workloads that were deemed most risky. Or don’t wait until you do the higher priority or the lower priority workloads. Do all of these things ahead of time. Get your cloud migration plan straight.
Samantha Rafalowski: Secondly, I think that it’s super important to use spare time to reduce your tech debt. I have seen a lot of companies continue to sink costs into legacy applications that are super expensive and don’t work well. These are really important to keep in mind. Aside from that, I think that other big-picture industry best practices that are super important are decentralized cloud management, and just having some sort of continuous integration, continuous delivery pipeline.
So the decentralized cloud management piece means not having a cloud team who is exclusively responsible for all of your deployments. And no one else understands how the cloud infrastructure is working. When you get this centralized cloud management, it often leads to a lot of confusion with your other teams. Anyone who’s touching the applications that are hosted in the cloud should have some idea of how they’re hosted and how their code changes could impact the infrastructure.
It avoids confusion and allows for you to deliver new products a lot quicker. Plus if you are sinking all of your costs and cloud management into one team, and then one team member leaves, it’s going to be a much harder loss for your organization than if there’s a de-centralized cloud management throughout the company. Because, hopefully at that point, that means that you have some well-documented infrastructure.
And when someone has a question, it’s not just going to be funneled down to one person who may or may not have the time to answer it, or God forbid, something goes down and you have to fix something. You definitely don’t want one person to be responsible for that. That’s a big piece of the big-picture cloud best practices.
And lastly, as I said, continuous integration and continuous delivery. This speaks for itself, but obviously when you are making changes to any sort of applications, deploying it should not take a long time. This, to me, seems very obvious, but in our survey, I believe I saw many organizations, probably upwards of 25% of organizations that have over two weeks of a deployment time. Which is really long time for businesses, especially in our hyper-connected world.
Your customers can get tired of that. Get tired of things not being updated appropriately, or if you have a bug fix that needs to go out and they need to wait two weeks, that can be a big deal. And that can be the difference between having a client and not having a client who’s paying you. So having some sort of CICD in place so your continuous integration is automated with your continuous delivery.
There’s not somebody who is a blocker, just waiting to press the button before anything can be approved. There’s no need for that in this day and age. We have automated testing. So, take advantage of it and make sure that you’re using the CICD that clouds provide these days.
Anna Barnett: There’s another archetype, the “we got stuck” archetype, that comes a lot of times when companies don’t properly assess their workloads and create a migration plan, according to the different priority or security aspect of the workloads. And what I can say to that is it’s never too late to reassess. You can pause, and with fresh eyes and more knowledge you can reassess your cloud migration and strategy.
I think that a lot of more mature tech teams know the value of an iterative approach when it comes to almost anything technology related. And this is also true for migration strategy and plan. Adopting that iterative, sort of, agile approach to your migration journey will help you readjust course, save in the long run, and improve efficiency. It’s never too late to stop and look again and change your plan.
Also, make sure you consider security. Some companies again, they’ll wait till that higher risk workload timeframe to start looking at security. But you want to map out your security concerns ahead of time, and also make sure that you’ve shared those plans with your cloud migration provider, so that you’re all on the same page.
And as you’re creating a migration plan, and as you’re starting to do the budgeting, make sure that everyone understands how the cost life cycle will go. Our data shows that organizations, as they move from few workloads migrated to many workloads migrated, their costs go like this. There’s going to be a spike when you get to that interim stage, that intentional hybrid cloud environment.
Make sure that your stakeholders have seen maybe that curve and understand that’s going to happen when you’re planning out your budgeting. If you don’t do that, and you just look at the cost value that’s on the contract or the sheet or what your people have calculated based on a few factors, you’re probably going to come up short and be surprised by costs. So understand the natural cycle of that cost.
Samantha Rafalowski: To improve your probability of succeeding in a cloud adoption journey, there are a few best practices that translate more into implementation strategies. For example, as I mentioned earlier, continuous integration, continuous delivery, that’s super important. When it comes to actually implementing that, this just means having services for integration and delivery. Integrate seamlessly, and furthermore, you can automate your testing.
When you have CI/CD, the reason it’s so important is because if something fails, it’s easy enough to introduce the changes and fix it, whatever the failure is. A lot of people struggling with cloud adoption, if you don’t have something like CI/CD and your application doesn’t work, it’s going to be a lot harder to redeploy it and figure out where the issue went wrong. That’s why I like mentioning it, specifically in implementation.
Secondly, fewer manual processes just in general. This relates to CI/CD, but I understand how nice it is to click buttons. It’s very satisfying. Personally, I’m a visual person so I extra like consoles. But it’s a habit that we as DevOps and cloud engineers all collectively need to learn to break. It really introduces human error into a fully computed process. When you are using automated infrastructure like infrastructure as code, automated deployment systems, things like that, it’s so much easier to revert back to the previous version of whatever your application was.
Even if you are storing something and you turn on bucket versioning. So in Amazon S3, if you have storage, you can turn on bucket versioning and make sure that nobody can delete anything and then you lost something forever. Basically, all the human error that we have introduced into technology, a lot of it can be taken out when you are using automated processes.
That’s super important to keep in mind when you are choosing how you’re deploying your infrastructure too. I know that infrastructure as code can a lot of times have a little bit of a learning curve, but it’s totally worth it to be able to revert back to your previous version and have all of these automated tests. Also, be able to just spin up a duplicate environment to do testing for something else.
Let’s say your application, you want to introduce a new feature, but you’re not sure how it will impact the rest of your functionality. No problem. You already have your environment coded in infrastructure as code. You can just spin up a quick, new, exact environment of your production to see what that feature would do. That’s something that’s totally invaluable and otherwise would have taken so many hours. It makes POCs way easier.
It makes it a lot easier to be able to technically prove your points to management or anyone else who may need to see for themselves. Infrastructure as code definitely helps you from a POC perspective, from an auditing perspective and just in general, from a mistakes perspective.
A lot of people talk about how the software development lifecycle changes from on-prem to hybrid to the cloud. What I think is really important to note is that the software development lifecycle was first introduced as a cost-efficiency way to still meet business needs. And a lot of times the complete opposite results occurred for people. When you’re using on-site infrastructure deployments, it’s really important to be able to update these cycles that could take years otherwise with an overall low software performance as output.
Best practices from an implementation standpoint to improve your probability of succeeding in the cloud adoption journey are understanding how cloud affects your software development lifecycle, making sure that you’re using your software development lifecycle to your advantage instead of to your demise, and ensuring you are getting rid of as many manual processes as you can. Manual processes just introduce human error.
Lastly, think big picture the whole time throughout your migration process. Disaster recovery, security, scalability, elasticity, none of these things are afterthoughts. They need to be considered in the very beginning of your plan and you need to make sure that you are also adding these features into your infrastructure as code so that your environment can be resilient and self healing as much as possible.
CloudOps Capability Lead
Associate Architecture Consultant
Research Senior Manager, Levvel
Meet our Experts
CloudOps Capability Lead
Srinivas "CJ" Coimbatore has over two decades of experience in diverse disciplines such as sales, marketing, software development, architecture and delivery, and has worked with teams in all of the major geographies. He is an effective change agent and is very interested in collaborating with teams that are involved in transforming their process through DevOps. In his spare time, he follows Formula 1 racing teams, rides his motorcycle, and—along with his friends—helps raise money for children with health challenges and for the Pediatric Brain Tumor Foundation, Make-a-Wish Foundation, and Angels Among Us. He hopes to eventually spend more time teaching math and science to children.
Associate Architecture Consultant
Samantha is an experienced, AWS-certified cloud architect at Levvel, where she has worked with application development, cloud enablement, and architecture assessment efforts for a variety of clients. She has over five years of experience in technical strategy and delivery for clients ranging from startup to Fortune 500 companies. Samantha specializes in serverless machine intelligence and virtualized resources, and enjoys writing (technical and otherwise) in her free time. She has a B.S. in Computer Science and a B.A. in Spanish from the University of Virginia.
Research Senior Manager, Levvel
Anna Barnett is a Research Senior Manager for Levvel Research. She manages Levvel's team of analysts and all research content delivery, and helps lead research development strategy for the firm's many technology focus areas. Anna joined Levvel through the acquisition of PayStream Advisors, and for the past several years has served as an expert in several facets of business process automation software. She also covers digital transformation trends and technology, including around DevOps strategy, design systems, application development, and cloud migration. Anna has extensive experience in research-based analytical writing and editing, as well as sales and marketing content creation.
You're doing big things, and big things come with big challenges. We're here to help.