Cloud computing challenges today: Planning, process and people

Source – searchcio.techtarget.com

With its promises of lowering costs and fostering a more agile IT, cloud computing holds an almost magical allure for many companies today: They think moving an application or two to the cloud will solve all their problems, said Ed Featherston, vice president and principal architect at Cloud Technology Partners.

“Then they get the bill at the end of the month and go, ‘Oh my God, what happened?'” Featherston said at the recent Cloud Expo in New York. “The magic doesn’t happen by itself. You actually need to plan.”

In this SearchCIO video, filmed on the concourse of the Jacob K. Javits Convention Center, Featherston and two other cloud watchers discuss the biggest cloud computing challenges IT execs are dealing with today.

Sumit Sarkar sees another type of struggle. He’s a data evangelist at Progress, a vendor of data integration and data interoperability services. As organizations build cloud architecture, plugging in new technologies and services, “data is getting somewhat more abstracted,” or not immediately and easily available to analytics professionals, who need to slice and dice it.

“If I build these microservices, my data is behind these different APIs. What if I have a data science practice team? How do I make sure they have access to data to really bring business value?” Sarkar says. IT executives and their business counterparts have to keep that in mind as they’re “rearchitecting and refactoring all of their systems.”

Greg Bledsoe, managing consultant at Accenture, says companies moving to the cloud need to adopt new ways of working. Bledsoe helps companies make the transition to DevOps, the software development process that emphasizes frequent interaction and communication between development and operations teams.

Cloud computing, he says, makes experimenting cheap. “If it doesn’t work, throw it away. But companies are still managing their cloud infrastructure as if it were physical infrastructure.”

So someone on the business side might request a new tech project from IT, gets it, tries it out, but then it’s not quite right.

“Throw something back over the wall and have somebody hoist it back over the wall to you. This makes no sense for cloud,” Bledsoe says. “It’s totally a legacy artifact of our past management strategies that is completely unnecessary.”

What cloud computing challenges plague IT execs today?

Ed Featherston: The biggest struggle I’ve seen with clients in cloud is fully understanding what it is and what it isn’t for them — and what it’s going to provide them. The classic of, ‘If I go to the cloud, it’s going to solve all my problems.’

One of my favorite mantras is ‘No technology negates the need for good design and planning.’ Cloud is no exception. And the biggest challenge I see people having with cloud is if they don’t do that first. If they just say, ‘Oh, I’m just going to take this workload, I’m going to drop it in AWS [Amazon Web Services], I just log into the console, fire up a couple instances — boom, I’m off to the races.’ Then they get the bill at the end of the month and go, ‘Oh my God, what happened?’

The magic doesn’t happen by itself. You actually need to plan. You need to understand ‘What am I going to get out of it? Am I going to the cloud for cost savings?’ Then you better look really closely at it when you do that.

I was talking with somebody earlier about the fact that — you move your first application over and you say, ‘OK, why am I not saving any money?’ Well, because the servers that application was on still have five other applications on them. I still have to maintain them. I still have to pay for them. So, I’m paying for those servers still. Plus, now I’m paying Amazon or [Microsoft] Azure for that cloud instance that I just created, so I’m actually spending more money. You actually have to think that out if you’re going for the agility and being able to move faster. Do your development processes and operations processes support that capability?

Yes, cloud can make you very agile — if you have the processes in place to do it. If you’re still a standard, Waterfall development type of shop that has no concept of what development and operations are and tying them together, the cloud’s not going to make it go faster for you. If anything, it’s probably going to make it go slower if you’re not ready for that.

So those are the kinds of challenges I see clients having out there. It’s getting those expectations set. It’s part of why I enjoy being where I am at our company, because it’s one of the things we push really hard with the clients — of No, we’re not going to start with, Go to the cloud. We’re going to start with, What do you want from it? Let’s look at what you’ve got, let’s understand how we’re going to get there and what the stumbling blocks are — then, we start moving to the cloud.

Sumit Sarkar: What we’re seeing is there’s a lot of people who start — I don’t know if they’re buzzwords, but at the show in the morning we had a kickoff about cloud-native architectures, and there’s 12 attributes of them. And then there’s something — I think I heard the term cloud washed: You take an application, you stick it in the cloud, and you rebrand it as cloud.

But the thing is, in between, there’s a big mix of different levels. I think with the innovation that’s happening is that between a cloud-native architecture and something that’s cloud-washed, for example, there’s a whole lot of things happening in innovation.

So I’ve heard different people who are taking maybe some NoSQLtechnologies to supplement an ERP system. Some people are building out some microservices on top of existing databases if you have a distributed data architecture.

So, what’s happening is data is getting somewhat more abstracted as we have this spectrum of cloud-native and, let’s say, untraditional or the monoliths. So they decompose these things, data gets moved around, make it scalable. So, what’s happening is it’s causing a challenge for the analytics professionals. So, if you think about the people doing operations intelligence, that is the last thing sometimes people think about.

I encourage folks, the CxO people, to think about analytics as they’re rearchitecting and refactoring all of their systems. Think about it: If I build these microservices, my data is behind these different APIs. What if I have a data science practice team? How do I make sure they have access to data to really bring business value? Or I have this data engineering team who can really build these nice data repositories to get 360-degree intelligence. How do I make it easy for them to get the data?

So that’s what we’re seeing in the connectivity space is, How do you provide connectivity for those professionals to still access data as you’re refactoring these things in that big spectrum? So the CxO folks, they have these initiatives, and that’s something to really think about is, Don’t forget the data integration for analytics.

Greg Bledsoe: Because we’ve come from this legacy of managing physical infrastructure, and we’re used to managing physical infrastructure in a very tightly controlled way to protect our investment and control cost, we bring that same mindset to cloud.

This mindset does not really apply to cloud. You don’t have to pay for things when you’re not using them. The whole power of cloud and the reason that cloud empowers DevOps is because you’ve cheapened experimentation. It has become dirt-cheap to try something, and if it doesn’t work, throw it away.

But companies are still managing their cloud infrastructure as if it were physical infrastructure. And you have a DevOps team or someone that sets up cloud infrastructure for you, you put in a request, you put in ticket, and someone builds something, and a few days later you get a response with some things that are built. And then you start trying to use those and it’s not quite right; you do this again. Throw something back over the wall and have somebody hoist it back over the wall to you. This makes no sense for cloud. It’s totally a legacy artifact of our past management strategies that is completely unnecessary.

So there are mechanisms that you can use to protect your cost and investment without having to centrally manage these architectures — which is essentially the exact opposite of DevOps. It’s a DevOps team that’s another silo that doesn’t really collaborate to solve the problem. It just becomes another source of wait time, another source of wheel spinning and another source of invisibility to the other teams.

This is exactly how to do DevOps wrong. And a lot of people are trying to implement it this way because it fits in with what they understand. It fits in with what they know. Because they haven’t really understood yet that DevOps is a completely different way to manage everything from the infrastructure to the people.