If your company is doing a partial or complete cloud migration, you’ve probably reached that point when there’s something in your current infrastructure that you’re not satisfied with. There are many challenges present in environments that have mixed legacy and cloud applications, even if that state is just temporary. There are many challenges in these hybrid, mixed environments, including rationalizing the different languages, tools, schemas and formats, and databases, and the parts of the infrastructure that use these mixed pools of data and infrastructure.
Cloud migrations provide a great opportunity to do a culture shift. Devops and automation are compelling goals that become suddenly viable. You can’t just expect your devops engineers to do the whole lift, but you certainly can drive improvement by having devops involved in the process and having devops learn the requirements of the applications that are migrating from one form to the other. Even if you don’t manage to acquire devops nirvana on the way up, you possibly can acquire a lot of value out of this opportunity, especially if you’re coming from an old-fashioned enterprise environment.
A cloud migration gives an enterprise the opportunity to make the cultural shift because operations will need to interface more with developers, and they will be working intimately with them to move applications that are highly customized. In fact, they are probably a big part of the company’s intellectual property.
Tool chain changes
You need to understand what you’re moving and how you’re going to do it, and it gets tricky because you are likely moving something that previously wasn’t in a container into a container. For example, you may be moving something that previously wasn’t in Kubernetes into Kubernetes. You may also be trying to create a hybrid cloud environment with multiple public cloud providers and a private cloud. The devops tool chain plays a big role there.
You may never stop your tool juggling. There are many orchestration tools out there that can help you avoid having to custom-craft deployments. A lot of companies that are building custom software may be at the beginning of their life cycle, so they don’t know what resources are needed to scale. Devops has to work with them to set up orchestration and monitoring so that scaling is successful.
You want to basically automate these applications in such a way that, as you move them from one environment to the next, you make them better and more resilient, and maybe make them more cloud-aware by making them more capable of being moved without turning the place upside down every time you do it. A good migration is where the life cycle is already planned for including the exit. If you already know what you’re going to do if you need to end a business relationship or end the life cycle of your application, you probably did enough planning ahead to at least know what to do when technology moves, and you didn’t see it coming. Devops-driven automation helps with this.
Automation’s basic goal is to delivery consistency. Engineers want to get their hands off the keyboard, and get the alerts produced at 2 a.m. out of the system. A business stakeholder wants things to work, so what needs to be delivered after the migration is more automation when it comes to monitors, infrastructure, and deployment process. It should be the metric that you should be able to measure when you finish the migration.
Monitoring after the migration
One of the main problems from a monitoring and reporting perspective after migration is that one size doesn’t fit all. If you try to standardize on a specific tool set, that’s not going to work for everything. You may need two different sets of tools for different layers of functionality. One goal should be to capture data from all the different layers, so the tool set has to reflect that.
Another problem is that thresholding isn’t consistent. Regarding systems, thresholding for containerized applications or systems running in the cloud, you really want the CPU usage to be high, because that means you’re effectively leveraging that investment and not spending too much money on extra instances. But when it’s more of a legacy, physical machine, you’d want that lower so in case you were to get increased traffic you’d be able to handle that additional load.
You’ll want to try to figure out the best way to do this. Often, we group types of applications into their own type of monitoring concept and then marry them all together. Ultimately, taking all this and putting that into that central devops dashboard that leverages all the different metrics is one end goal that cloud migration provides.
It’s not always easy. A lot of times, an organization may not even have a tool that’s going to work with this system. Or maybe the existing tool is so old you can’t even install some of the new open source tools to use with it.
Make sure all the cloud layers are covered, and whatever tools you’re going to use have right threshold and alerts set. Following that, make sure it’s all rolled up into a decent presentation layer.
Also make sure that the actual visual presentation on a centralized dashboard is consistent. There may be a lot of consumers of this dashboard. There may be people from the devops side, the SRE side, and maybe the command center, or a NOC. The NOC may want less details. They don’t need as much information, but they need to be able to react to something and engage the right people. Maybe someone else would want it more detailed, may be able to dive into those different views and get the information that they want and compare metrics over metrics.
If an enterprise is changing the way that developers work, that means there’s a culture shift required, so an organization may own some tools for a very long time. Sometimes an organization may think that the cloud migration tools will go away eventually. However, most of the time they are permanent addition to the tool chain, so if they are part of the current devops tool most commonly used, that would be an upgrade. Once the culture shifts, if things were successful, people don’t want to abandon some of the things that were running through the migration process, so they better be appropriate to the devops process and culture.
Cloud migrations are a great opportunity for an organization to improve processes, tool chains and culture and head towards devops. It’s a great opportunity to change something that’s become stagnant, and maybe not so beneficial. If the goal and lifecycle of your intellectual property revolves around your collaborative efforts, this is a great opportunity for you to open those doors and have these conversations because you’ll be more successful if you do.
This article is published as part of the IDG Contributor Network. Want to Join?
