Close

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 application management

  1. 10 ways Cisco CloudCenter simplifies AWS

    Leave a Comment

    AWS2

    Since CloudCenter makes it easy to add AWS to your data center-based hybrid cloud service offerings, and automate deploy and manage of applications, I thought a “Top 10” list was in order.

    Register for the Dec 15th live demo webinar that will highlight these features.

    CloudCenter is an application-centric hybrid cloud management solution. It lets you build on your Cisco infrastructure foundation, and extend application deployment and management capabilities to include public clouds like AWS.  Most enterprise IT organizations I work with already have experience with a public cloud like AWS. And, are now looking to broker multiple public cloud services to IT consumers. CloudCenter has a significant TCO advantage over hybrid-cloud or multi-cloud solutions that are environment specific or use hard-wired automation.

    CloudCenter integrates seamlessly with AWS and “Abstracts the cloud” so developers and users get the power of automated application deployment and management, without having to understand AWS API calls.

    1. Deploy a virtual machine on demand. Easily integrate with service catalogs such as ServiceNow or Cisco Prime Service Catalog, a custom IT front end, or use the out-of-the-box enterprise marketplace. Give your IT consumer self-service on demand “One click” deploy an OS image with CPU and memory to user’s choice of regions, Virtual Private Cloud (VPC), and availability zone. The IT organization centrally controls who, what, where, when and for how long OS images are deployed. You can track costs and usage with roll-up or drill down reporting by application, cloud account, user group, and more.
    2. Manage images in multiple regions. Automate management of OS images across multiple AWS regions. Whether you build cloud specific images, check out and harden an Amazon provided AMI, or rent vendor updated images, a simple CloudCenter API call updates logical to physical OS image mapping to simplify maintenance, and make sure users are always consuming the latest IT approved OS images.
    3. Deploy any application stack on demand. Users can self-service deploy a fully configured infrastructure and application stack, including databases, middleware, application and web servers, and load balancers. CloudCenter automates deployment of existing enterprise applications or cloud-native micro service architectures. You get cloud-scale features with traditional applications without refactoring or changing application code. And you get full flexibility with composite topologies including a mix of OS images, application services, containers, configuration tools, and unique AWS services.
    4. Automate Continuous Deployment. Did you know you can deploy from Jenkins to any data center or cloud with one CloudCenter plugin? A code change can trigger a build which then triggers a deploy of a full stack environment including the latest build. CloudCenter makes it easy with a Jenkins plugin, and simple API call integration with other popular build automation tools. And CloudCenter abstracts the cloud so your developers don’t have to spend time learning cloud specific API calls, or writing hard-coded scripts for different AWS regions and availability zones.
    5. Auto scale across availability zones. You need to deploy applications in multiple AWS availability zones in order to get AWS 99.995% uptime guarantee. You can deploy master and slave components in different availability zones and autoscale across them both. You don’t need complex scripting in a cloud formation template. You don’t need deep knowledge about security groups or network Access Control Lists (ACL). CloudCenter makes it easy.
    6. Migrate across regions. You can use powerful migration features to move an application from one AWS region to another. Once an application is deployed, users can select an application, pick target region, and “one click” migrate the application and optionally the data if needed.
    7. Automate micro-segmentation. When a cloud agnostic Application Profile is deployed in AWS, CloudCenter automates creation of Security Groups and Access Control Lists that deliver micro-segmentation with white list communication. You can easily deploy and manage a large number of applications without using shared segmentation that opens security risk of East-West traffic.
    8. Including AWS specific services. In general, we recommend you use cloud-agnostic services to model Application Profiles to a single profile that can be deployed to data center, AWS, and other clouds. That is key to lower hybrid cloud TCO. But you also have the choice to model AWS-specific services as part of an application profile, or use call outs to call unique AWS services when needed.
    9. Benchmark price and performance. Compare price performance metrics to determine when AWS is the most cost effective choice. Or determine price differences between AWS regions. Performance across regions shouldn’t vary. But, price in different regions can. Also, use benchmarking to find out when multiple small instances are more cost effective than one large.
    10. Stay in control. CloudCenter is an enterprise-class solution that includes governance and security features that meet the needs of the most demanding and complex IT organizations. Multiple AWS accounts? Multiple groups using a single AWS account? No problem. Control usage and get complete cost and usage visibility with policy-base guardrails that give users self-service on demand deployment, with IT oversight that help users make the right choices every time.

    Register for the webinar to see CloudCenter and AWS in action!

    Read the Datasheet – CloudCenter with Amazon Web Servies

    Watch AWS re:Invent session Dev211: Automated DevOps and Continuous Delivery

  2. How to Manage a Successful Multi-cloud Strategy

    Leave a Comment

    This piece originally appeared on Sand Hill.

    Cloud computing, by its very nature, does not limit choices nearly to the same degree that previous data center revolutions have. It used to be that you had to choose between A and B; but with a multi-cloud strategy, you can have both. The trick, then, becomes how to manage multiple clouds over time. How do you decide which applications should go where and who gets access to various resources? When is it time to move off one cloud to another, and what are the odds that you’ll have the same answer for every one of your applications? Start by asking yourself these questions.

    Where are you now?

    Just about every company has some cloud deployments, whether IT knows about them or not, and the first step is to get an inventory of what is being used by whom and why. More than likely what you’ll find is that there is demand for self-service, on-demand access to application deployments and that the specific benefits of a particular cloud pale in comparison. Speed kills in today’s business environment; and for any team, especially those in the line of business, the ability to iterate stands above all else.

    What clouds do you want to consider?

    That inventory you collected will act as a guide here, as will your current data center capabilities. Public clouds are easy to try before utilizing them heavily. Private clouds are more difficult due to your being responsible for the setup yourself, unless you go with a managed option of some sort where a trusted third party comes in and maintains that layer on your behalf.

    Which applications should go where?

    With your application inventory in hand, make a rough sketch of which ones should go on your private cloud targets and which are more appropriate for public.

    Data Privacy Sensitivity chart (Cisco)

    One way to think about this is to plot the workload demand along a Y-axis with the data privacy sensitivity along the X-axis. Applications that have high data privacy sensitivity and/or constant workload demands fit best on a private cloud, where the data can be protected behind a firewall and capital-expensed in-house equipment can be highly utilized. For applications without data sensitivity issues or ones that have wide variances in demand, a public cloud target is best.

    Who gets to do what, where?

    No multi-cloud strategy is complete without considering the people who will be using it, and that means well beyond the traditional IT administrator. End users of all skill levels are desperate for self-service, on-demand resources; and if you don’t offer it as part of your multi-cloud strategy, your user community will go elsewhere. Figure out who needs to deploy what and where you want to let them do so under different circumstances.

    Putting it together with a Cloud Management Platform

    With your application inventory collected, initial deployment targets decided, and who needs to deploy what in place, it is time to put together the whole picture with a Cloud Management Platform (CMP). This emerging class of software enables an IT department to model applications in a format that reuses existing assets and is portable across different cloud targets while enabling the IT administrator to put some limitations on that with governance and metering/billing.

    Ideally, the CMP should enable you to benchmark applications on different cloud platforms so you can make informed choices on what applications should go where for those versatile enough to go in either public or private clouds. It should give you a view of your current world of Virtual Machine (VM) management to ease the transitional period in a way that lets you assign quotas of VM or dollar usage that will work for your current state of loosely deployed VMs and the future state of VMs deployed within the context of the application inventory. Your CMP ought to provide role-based access control so you can flexibly implement who is allowed to deploy what, where.

    Selling your multi-cloud strategy to your internal stakeholders

    Finally, none of the components of a multi-cloud strategy matter if others don’t buy into it. Fortunately, there is plenty here for a wide variety of roles to get excited about.

    • IT admins – Maintain control of a multi-cloud environment unobtrusively
    • LOB users – Get self-service, on-demand resources whenever they want
    • Developers – Deploy new builds as needed without a lengthy ticketing process
    • Security architects – Codify knowledge into every application deployment, automatically
    • CFOs – Highly utilize capital investment in the data center, drive better ROI calculations on the public cloud

    With the help of a CMP, any organization can implement a sound multi-cloud strategy that satisfies the needs of all these constituents, and more.

    Pete Johnson is the technical solutions architect for cloud in the global partner organization at Cisco Systems Inc. He is a 20+-year tech industry veteran and can be found on Twitter at @nerdguru.

     

  3. Cloud Strategy Brief: CliQr CEO Gaurav Manglik

    1 Comment

    To be a strategic partner with the business, IT needs to focus their cloud strategy on the applications that deliver the business value; not the infrastructure. Easier said than done. Or is it? Lets talk to the experts and find out…
    (more…)

  4. Why I Joined CliQr

    Leave a Comment

    I recently joined CliQr as Vice President of Product Marketing. I will be using this blog to share my perspective on industry trends, CliQr product details, and our customer’s success.

    So why, with my experience at multiple technology vendors and time served as industry analyst, did I decide to join CliQr?

    Its all about the app (more…)

  5. The Inconvenient TRUTH About Image-based Cloud Migration Tools

    Comments Off

    INTRODUCTION
    Creating application images, using entire virtual machines or otherwise such as container-based, is a convenient way of “snapshotting” applications, allowing them to be able to seamlessly move such images from one infrastructure to another—including virtualized clouds. Today, there are a growing number of various image-based tools available that do, in fact, make it easy to “convert” from one virtualization format to another, offering the efficient portability of images across different infrastructures – including clouds. Regrettably however, most are quickly finding that moving an image is only part of the challenge in enabling an application on a cloud environment. Getting these images to actually work optimally, connect with each other and other resources while maintaining portability once on the target environment/cloud…is a real problem and one that is not addressed by this class of solution.

    WHY IMAGES ARE CONSIDERED USEFUL – THEY SEEM TO HELP BYPASS COMPLICATED APPLICATION DISCOVERY
    Due to the complicated nature of real-world enterprise applications and their deployments on existing IT environments, it is often considered difficult to discover such an application environment in its entirety for the purposes of cloud migration. While Image-based tools try to make this easier, they take an overly simple approach of “discovering” such existing IT environments. This is especially true for use cases that run legacy workloads, those that may have gone through a series of changes, upgrades and maintenance over their lifetime and, even those that have evolved through a series of changes of IT personnel. It is because of these real-world complexities that discovering such environments along with their custom settings such as dependencies on networking and storage infrastructure and operating environments can be an extremely tedious exercise to “get it right”. It is in fact this challenge that has created the allure of many image-based solutions as a part, or in some cases a replacement for, discovery

    The sad truth however, is that even though these solutions have a place, IMAGES ARE NOT SUFFICIENT as, or as a replacement for, discovery. True discovery is needed in order to adequately orchestrate the provisioning, operations and management of applications on clouds and required for enterprise-class cloud computing.

    DEPLOYMENT ORCHESTRATION NEEDS DISCOVERY
    While creating application or VM images may be a simple task, if the goal is to enable such applications to be deployable, manageable, and scalable on a target cloud, creating images alone is simply insufficient. Despite a push for standards such as OpenStack, the reality is that target private and public target cloud environments have very different underlying compute, storage, and networking infrastructure and very different methods to provision and configure these environments. This invariably requires discovering the application footprint within the images and then reconfiguring the application with custom environment settings, networking interdependencies, etc. in order to provision the application appropriately on the target cloud infrastructure, – an exercise that is cloud specific and most often cannot be leveraged on more than the one unique target environment.

    RUNTIME ORCHESTRATION NEEDS DISCOVERY
    If one-time provisioning of created images followed by scripted orchestration is not difficult enough, what about auto-scaling, VM tear-down, sprawl control, management, governance policies, policy automation for processes such as disaster recovery (DR) and making changes to the virtual machines based on price/performance, etc. All this requires, not only cloud know-how, but deep down application semantics in order to implement and take full benefit of cloud computing for the given application.

    ORCHESTRATION IS APPLICATION DEPENDENT
    And, to make things more complicated, these categorical application requirements can vary greatly by various application types. For example, take a complex N-tier application that may require the discovery of all of its tiers, its interdependencies, and where such configuration data may be kept (such as the database IP address in an application configuration file). To provision this application on the cloud, not only would a script need to be created to provision the entire stack in the correct sequence (the database tier configured with the appropriate persistent storage followed by the application server, followed by the load balancer, etc.), the script would also need to configure the application tier with the right database IP address. For a different application such as an MPI based cluster-computing application, or a batch processing cluster, yet again, a very different script-based orchestration will be required for the application to be launched on a target cloud.

    HENCE APPLICATION DISCOVERY IS NEEDED FOR ORCHESTRATION
    Therefore, an important step in orchestrating the provisioning of an application on a target cloud environment is to be able to perform some type of application level discovery. Discovery is needed to understand the required and optimal infrastructure needed by the application to be provisioned, coordinate with infrastructure, application, data source and service interdependencies and custom settings that are dependent on environment, and application semantics for scaling, DR and general runtime management.

    SOME DETAILS ABOUT ORCHESTRATION
    Looking at orchestration a bit deeper, it’s not limited to laying and configuring an application on cloud resources, but it’s also provisioning and configuring both the required and the optimal underlying infrastructure as needed by the application to function and perform at its best.

    Examples of what such a complete orchestration should do includes:

    • Infrastructure Orchestration
      • Configuring the right storage (examples: provisioning a shared storage similar to an NFS mounted shared storage, configuring the right drive letters on windows VMs, etc.)
      • Configuring the cluster (examples: working with the cloud APIs to launch the right cluster with the minimum required CPU and memory resources, scaling the cluster as needed)
      • Configuring the network (examples: vLAN settings, firewall settings, communication protocols, etc.)
      • Injecting VMs with the right initialization/configuration data
    • Application Orchestration
      • Provisioning the application with the underlying infrastructure in the correct sequence
      • Configuring the application along the way (such as IP addresses, relative paths)
      • Customizing settings and environment
      • Configuring security settings
    • Runtime Orchestration
      • Auto-scaling
      • Policy driven tear-down of resources
      • Disaster recovery
      • Governance controls

    CONCLUSION
    No wonder cloud migration has been hard—it’s not just about seamlessly dragging and dropping virtual machines from one environment to another. And since every cloud is different, creating hard-wired orchestration creates lock-in to a particular cloud, eliminating portability that was provided by the images and eliminating the flexibility sought after with the cloud.

    The question really is not whether image-based migration can help – IT CAN. It’s just not sufficient. The perceived value it provides can quickly get muted by the required orchestration really needed to get applications to perform optimally on new environments, such as clouds. And, since these new environments vary greatly, having to hardwire images and orchestration to each environment eliminates most of its promise

    Being able to create additional layers of virtualization, networking overlays, etc. may be able to potentially avoid some of these mentioned challenges, but often come with significant performance overhead in return. After all, if the whole point of virtualization is to abstract away infrastructure, why would you want to virtualize on top of existing virtualization?

    What’s needed is a migration and management platform that provides true cloud-agnostic orchestration on one or more private, public or hybrid cloud environments along with complete visibility and control for fine-grain management and scaling that is not lost when moving between environments.

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.