Cloud Hosting

Software-driven IT organizations generally rely on a tool chain made up of commercial and home-grown solutions to develop, deploy, maintain and manage the applications and OSes that their business depends on. Most IT shops have preferred tools for needs like application monitoring, data protection, release management or provisioning and deprovisioning resources. But are those tools always the best options?

While tool chains do evolve over time, its rare for IT organizations to conduct a full, top-to-bottom review of the tools they are comfortable using with an eye toward optimization or new capabilities. One motivator is when companies are considering moving workloads from the data center to the cloud. The inherent differences in how applications are developed and managed for on-premise vs. cloud environments is a strong reason to reassess whether the current tools in your arsenal are the best alternatives available or, just as important, whether theyre well-suited to a more cloud-centric software lifecycle.

When it comes to reevaluating your tool chain, it helps to have a process. Heres one approach:

Its important to start with a full audit of your current stack, including areas such as:

Obviously, its important to assess how well each product meets your current needs as they stand today. (Are there capabilities you wish it had or weaknesses youve become accustomed to working around?) Then consider how those needs will change as workloads move to the cloud. A good first question to ask is whether the tool is still supported by the vendor. Given how infrequently IT teams switch tools, theres a not insignificant likelihood that one or more of your tools has become an orphan. Second, does the license agreement for the tool accommodate or restrict its use in the cloud? For instance, some tools are licensed to a specific physical server and some vendors require their hardware to be owned by the same entity that holds the license. Both of these scenarios are problematic for cloud-based deployments. Third, does moving to a cloud base tool open up new possibilities that you want to take advantage of? Removing the constraints of on-premise solutions and gaining capabilities like nearly unlimited compute and storage, dynamic workloads and multiple regions around the world can provide much needed flexibility. But the advantage of moving to a cloud-based tool (replacing, say, an on-premise application log reporting solution with Azure Log Manager), needs to be balanced against the added management required solution as well as the need to retrain teams.

There are also non-technical factors to consider when looking at new tools. Do teams enjoy using the tool? Does it make them more productive (or conversely, slow them down)? Does it meet the business needs of the organization? How much work will adopting a new tool take and will it be worth it in the long run? While these may not be the most important considerations, they shouldnt be overlooked.

There is almost always going to be an alternative to any individual tool and, potentially, one tool that can do the work of several, making it possible to consolidate. One way to get a sense of whats available is to start by asking other teams in your organization what they use in the destination cloud. There are often cloud-based tools (offered by cloud vendors or sold as separate SaaS products) that offer pay-as-you-go licensing, can be easier to scale up or down, move workloads around, and can expand to other regions. Today, some legacy vendors even offer consumption-based options to better match up against cloud-based competitors, while others stick with more traditional perpetual licenses. Last, consider if a new tool will give IT teams the opportunity and motivation to expand their skill set. Offering the chance to learn and use new products could actually increase job satisfaction and improve your organizations ability to retain engineering talent.

Before you pull the trigger on a new solution it often pays to check in with the existing vendor. To keep your business they may offer more generous or flexible terms. Of course, vendors that see the cloud as a threat are probably going to be less inclined to give you a break on licensing. But the conversation doesnt lead to new or better terms, talking to your vendors on a regular basis can provide insights into how they see their customers and the market.

Once youve completed the previous steps, youll have a good idea of the tools youre likely to keep and those youd like to upgrade. At that point, its important to create a plan for adopting each new tool. Start by separating products that need to be replaced soon from those where more research is required; it also helps to compile any other useful information learned during the process so that the larger IT team can access it. Youll want to assess whether teams will need training, whether internal documentation or playbooks need to be updated, and how new tools will plug into existing authorization/authentication solutions. Finally, you will also need a migration plan for each tool that details how and when the organization will move from the old product to the new one, what scripts will need to be rewritten, and what to do with historical data like log files from the old product.

While cloud-based tools offer meaningful benefits in terms of flexibility, cost savings and ease of scalability, they may not be the best solution for every organization. The only way to be sure is to do the kind of analysis outlined above. For companies that have already made the decision to move workloads to the cloud, the potential long-term benefits of adopting new solutions is worth the effort.

Skytap

More:
Rethinking Your Tool Chain When Moving Workloads to the Cloud - Virtual-Strategy Magazine