TEST to main content First level navigation Menu
group_working

What do you do when your IT deployment fails?

by ​George Dearing
 
Even the best-laid plans sometimes don’t work out. What can you do to make the best of a bad situation?

In the new world of work, you’re always updating or implementing something. But how do you know when an IT deployment has failed? And what do you do when things go wrong?

While issues can often be traced back to a vendor or a specific configuration, there are also personnel and organizational challenges which can affect IT deployments. Let’s look at ways to minimize the risks. For this installment, we’ll focus on cloud deployments.

If you can’t measure it, you can’t manage it. Pinpointing where the failure originated often comes down to monitoring and management. The goal is to understand exactly when a system starts to falter.

Spot where performance breaks down

As you’ve probably heard before, “If you can’t measure it, you can’t manage it.” Pinpointing where the failure originated often comes down to monitoring and management. The goal is to understand exactly when a system starts to falter.

Cloud vendors try to standardize where they can, but they still have proprietary tools and services due to platform differences. One of the biggest things to remember is consistency. In order to pinpoint where breakdowns occur, it’s best to identify issues using the same tools you built before your migration.

And if your applications were built onsite, make sure your documentation is thorough enough to describe any in-house architectures that were used. There could be an older set of code in use prior to the cloud rush that is negatively impacting things.
 

Pay attention to APIs

Whether you’re trying to move back to on-premises or migrate into the cloud, a lot of your IT deployment work will depend on proprietary application programming interfaces (APIs).

IT groups shouldn’t look past vendor tools just because they’re proprietary. Vendors have to write and port applications from the data center to the cloud all the time. And odds are, their tools are fairly portable, especially if network computing and storage are being used.

But when applications are native to the cloud, migration can be tougher. Your cloud vendor will surely tout its APIs as a way to cut costs and improve cycle times, but keep in mind that these tools are often proprietary. If you’re looking to get to a more open environment — not so closely tied to a vendor’s proprietary services — some companies have opted to use vendors or libraries that support multiple cloud platforms.
 
In that case, custom workflows can be written that separate these libraries from proprietary APIs. If that’s your strategy, make sure your workflows are built for both the cloud and on-premises. A consistent architecture should allow for portability, should you need to migrate away from one or the other.

The good news is that open APIs now have some momentum, thanks to the adoption of RESTful APIs, which aim to simplify how services can connect to each other. But developers and administrators still have to put the pieces together. Don’t underestimate what it takes to build out APIs. This can often be a source of headaches in any IT deployment.

Get back on track

Find out the steps you can take to get a deployment moving again.
 

Planning the redo

Now that you have some visibility into the issue, how do you get things moving forward again?

  • Have a blueprint: Before you built out your applications, you created requirements and some metrics to measure performance. You need to have a similar blueprint for how to deploy in the cloud. Get as granular as you can, right down to each individual process, so you can migrate workloads and perform tests to gauge performance and scale.
  • Review key metrics and understand limits and workloads: From that blueprint, make sure you anticipate growth rates and map out capacity and storage needs. Your software or cloud vendor should be able to help with some benchmarks.
  • Use the best-of-breed tools from cloud or app vendors: As we mentioned, proprietary tools have some limitations. But most cloud providers have the IT infrastructure and staff to maintain enterprise tools. Take the time to investigate their offerings and decide what you can take on from a development and configuration perspective.
  • Weigh the migration risks before making a decision: Cloud vendors are well known for changing their products and services from time to time. So while migration is very doable, get familiar with your vendor’s operating environment. It’ll save you a ton of headaches as your needs change.

IT professionals need to be constantly vigilant to a changing landscape. Regardless of your industry, follow trends in IT across sectors and stay informed.

 
George Dearing
George Dearing has more than 15 years of experience helping organizations understand how information, technology and the internet impact business. As founder of the Dearing Group, he advises clients on strategy, business development and communications. After working for one of the first internet consulting firms (USWeb) in North America, he’s run marketing groups at software companies, directed strategic alliances at professional services firms, and helped early-stage companies deliver software-based business solutions.