Request a demo

CliQr's groundbreaking technology makes it fast and efficient for businesses to move, manage and secure applications onto any private, public or hybrid cloud environment.

CliQr is now part of Cisco Learn More About Cisco
Request a Demo

Tag Archive: cloud migration

  1. Top-down vs. Bottom-up Approaches to Moving to Cloud

    Leave a Comment

    Many companies and government agencies adopt a “top-down” approach in setting IT policy, making sure technology is secure before approving it for organization-wide use. Some, conversely, employ a “bottom-up” approach, allowing individuals and offices to innovate, and then adopting those experiments that have successful results to improve the organization-wide technology infrastructure.

    Which is better? Or are both needed? How do you choose an approach to moving to cloud?


    In the early 2000s, in the wake of the Internet Bubble bursting, the influence of the CIO skyrocketed as they took steps to control costs. Using strategies that were sometimes called “ruthless standardization,” edicts would come from the C-suite about what combinations of technologies could be used in IT. We heard pronouncements like “Thou shalt not use LAMP stacks but instead Java Web applications with Oracle (NewsAlert) databases.”

    The good news about top-down driven technology decisions is that they tend to be cost-effective. With the CIO behind them, pricing from the major technology vendors, cloud Infrastructure-as-a-Service companies here, is usually excellent. The bad news is that they are typically limiting when it comes to innovation. If the CIO decrees that you can only use Oracle databases, for example, you may miss out on the NoSQL trend that opened up a completely new way of thinking about data management. At the beginning of the 21st century, that happened more frequently than people tend to remember.

    What lessons can we learn from the top-down technology decisions of the past when examining cloud adoption? The key to a good top-down approach is flexibility. Technology changes too quickly to rely completely on five-year licensing agreements, but without them costs can spiral out of control. A Cloud First strategy doesn’t mean Cloud Only strategy. Rather, it gives development teams a starting point they can argue out of if they can prove alternatives are more beneficial.


    On the flip side of the coin is a bottom-up approach, where executives rely exclusively on developers to push innovations up the chain of command. In the late 1990s, agile development methodologies were a good example of this. Frustrated with waterfall methods that were standard at the time, and which relied on long release cycles with all requirements being specified before any code was written, developers flocked to a very different paradigm where minimum viable products were built and then iterated over many, much shorter releases. This eventually led to the DevOps and Continuous Integration/Continuous Delivery approaches that are commonplace today.

    Innovation can spring more easily from a bottom-up approach, but it often takes time for what can be competing alternatives to emerge with a winner. And what works for one part of a business may not for another, given contextual differences. For example, should a particular team use Amazon Web Services (NewsAlert) or Microsoft Azure for its public cloud hosting? Ask 10 different development teams this question and you’ll likely get a split vote, with teams basing their opinions on specific features they need that only one vendor provides, or a geographically more advantageous data center that one development team needs but others do not.

    Why Both Are Needed

    In reality, a little bit of both approaches is needed. An executive might make a declaration like what the U.S. CIO did in 2014 for federal agencies with the Cloud First strategy. In other words, having a default position set by upper management but setting criteria under which another technology choice can be made by development teams is the way to go.

    That might mean that the CIO selects (and gets great pricing on) one private cloud and one to two public clouds on which development teams are allowed to deploy workloads as the top-down portion of an approach. But within those clouds, let development teams use whatever derivative services each cloud vendor might provide, along with whatever open source they would like, including making use of more cutting edge technologies like containers or Function-as-a-Service. This gives the bottom-up approach some room to grow innovation, but with some guiderails set by the top-down edict that controls costs without stifling creativity.

    This blog originally appeared on The Cloud Computing Magazine


  2. Portability on the Cloud: What it Really Means for Apps

    Comments Off

    The cloud market is moving fast, starting with huge buzz around a bunch of web apps moving to one or two clouds to where we are today, with companies looking at cloud computing as a means to implement efficient business processes and support a productive work environment. With this maturation in the market, businesses now realize that the early migration vendors and approaches of hardwiring applications to a single cloud did little more than trade the constraints of their physical datacenter to being constrained on one cloud.

    Enter the era of cloud portability, which addresses this very real pain point businesses are facing. With seemingly a flip of a switch, incumbent “hard wire” script-based migration vendors, and a whole host of new cloud migration and management vendors, launched products and messaging promising cloud portability and multi-cloud solutions. But what does cloud portability really mean, and what are the differences in the various approaches?

    Hub & Spoke
    With unlimited time, resources, and money, anyone can make an application portable across multiple heterogeneous cloud infrastructures. This is the approach that incumbent migration solution vendors have taken. After all, if you write enough scripts, create cloud-specific VM images and make necessary code alterations/additions to the application, any app can run on any cloud. After the application is migrated to one cloud, moving it to another cloud involves understanding the next target cloud’s APIs representing its unique rules and behaviors around compute, network, storage and security. Regrettably, most of these primitives are significantly different between various clouds, allowing only the most basic web apps the ability to repurpose the migration activities involved in getting to the first cloud. Some vendors are trying to simplify this process by providing pre-packaged VM images with accompanying deployment scripts. This does arguably cut down the time to complete the migration as one does not have to start from scratch. However these images/scripts and customizations have to be separately maintained on every cloud and does not represent true cloud portability.

    VM to VM
    More recently to the scene are a bunch of newer VM migration vendors with cloud portability as a major positioning point and product focus. Many of these solutions provide enhanced portability, especially in contrast to the older migration solutions attempting to repackage their messaging. With the VM migration vendors, the general proposition is that an intact VM from an on-premises deployment including operating system, database and applications, can be forklifted to any cloud. While these solutions do enhance portability, their drawbacks assume an existing virtualized source infrastructure, have very large and unnecessary VM stacks to move to, and then between clouds, and in many cases, offer performance overhead involved with coordinating a VM on a VM and a loss of visibility into the application.

    The lack of visibility into the application makes it impossible to efficiently monitor the app and its performance, making it difficult to auto scale, tune the application or performance-based bursting to other private or public cloud environments. Furthermore, because of the lack of application visibility, most VM migration solutions make comprehensive app and data security very difficult, and typically lack utilities that support active connectivity and coordination of cloud resources with those remaining in on-premises environments—an absolute requirement for hybrid clouds and enterprise-class cloud computing.

    The good news is for these VM migrations solutions—many of the drawbacks outlined above can be addressed. Once on the cloud, scripting along with integration into one or more of many of the cloud-provider’s management tools can be accomplished. But, doing so effectively hardwires the app and VM to that cloud—eliminating portability.

    Cloud to Cloud—It’s all About the App
    Lift, shift and transform. Another approach to cloud portability is a migration and management approach that de-couples the application from requiring awareness of any underlying cloud infrastructure. With this approach the knowledge of the application and its rules and behaviors around primitives such as cluster, storage, network and security can be described in an interactive migration tool environment. Once described, an active meta-data workflow is produced and presented to the cloud. The supported clouds also host a multi-tenant orchestration virtual appliance that represents its behavior around these same primitives. The coordination of these two (application and cloud) orchestration layers creates, in essence, a software defined datacenter environment that allows the application to be deployed from any physical or virtual infrastructure, natively and optimally on any supported private, public, or hybrid cloud. Using this approach, applications remain visible and accessible, they can be tuned; auto-scaled based on user-defined schedule or application performance based policies and secured.

    Another advantage of the application-based approach to cloud migration and management is that beyond a lift and shift application deployments can undergo an optional transformation, supporting the real world diversity within/between datacenter environments and disparate clouds. The application-centric approach allows many source components, such as operating systems and databases to be transformed “in-flight” to perform natively on different target cloud environments. A transformation example can be moving a Java-web application that uses a database such as MySQL on the source side, but can be ported to a cloud environment to use a different database such as SAP Hana or the cloud’s database service such s Amazon’s RDS.

    This application centric approach to cloud migration and management allows any application that can be supported by some cloud infrastructure to be moved from any physical or virtualized environment to any private, public, or combined hybrid clouds. On-board once, run anywhere—cloud-to-cloud portability allows applications to fluidly and transparently move to, and across, any federation of clouds optimally while requiring no additional migration.

    CliQr provides this cloud to cloud migration.

CliQr Technologies, CliQr CloudCenter and CloudBlades are trademarks of CliQr Technologies, Inc. All other registered or unregistered trademarks are the sole property of their respective owners.