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.
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.
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.