Integration and Extensibility for Hybrid Cloud Strategies

There’s been an uptick in enterprise public cloud offerings from providers like Google Cloud Platform (GCP) and Microsoft Azure. Amazon Web Services (AWS) still dominates the market but GCP and Azure are catching up. GCP recently announced an offering for Kubernetes on-premises called GKE On-Prem, and Microsoft just announced new support for billions of internet of things (IoT) devices with Azure IoT Hub.

Public Clouds for Enterprises

These enterprise-focused public cloud offerings continue to allure IT leaders, many of whom have been reluctant to use them in the past. They are now rethinking their strategies to adopt a more hybrid cloud approach. They want the benefits of scalable, on-demand resources instead of going through a more traditional procurement process of scoping out and investing in the physical infrastructure.

This is great for new resources but what about everything else IT leaders manage?

Legacy Infrastructure

Enterprises typically have a significant footprint of on-premises resources scattered in data centers and remote offices as part of their “legacy” infrastructure. Some of the old or legacy stuff works just fine. For example, mainframes that run batch jobs overnight might not be worth messing with, especially if they can be easily integrated with newer resources. For an investment application, retirement funds don’t need to be updated in real-time; just one batch job at night will do the trick. Moving this processing to the cloud would probably not be beneficial.

On the other hand, application architectures that need to interact with mobile and IoT devices require newer, real-time scalable resources to accommodate user demand. Digital businesses like Uber and Lyft have very responsive mobile applications to meet fluctuating demands.

What does this mean for IT leaders?

Interoperable and Extensible

IT leaders must advocate for digital components that integrate with their complex digital ecosystems both legacy and new from public cloud providers. At a minimum, these components and solutions must be interoperable to share information easily, like the nightly updated information from a data center batch job to a mobile app that has computer processing in a public cloud. They must have the ability to be “networked” together on-premises, in the cloud, or from an IoT sensor. For example, Microsoft’s new Azure IoT hub mentioned at the beginning of this post provides this interoperability for new application initiatives and IoT devices.

In other cases, digital components and solutions must be extensible so that key features can be customized for specific technologies or use-cases. This typically means having an API defined so that specific actions can be scheduled or event-based. For example, a solution can publish a REST API so that another solution can trigger a specific task over the internet. A ticketing system will typically have a REST API so that they can open a new service request from another system. A monitoring system might use this ticketing system’s REST API to alert the IT department when memory usage goes above a threshold.   

A hybrid cloud strategy includes integrations for interoperability and benefits when components can also be extensible. The idea is that a one-size-fits-all approach becomes outdated quickly with emerging technologies. Hybrid cloud means right-fitting the digital components across on-premises, private cloud, and public cloud environments. The components must connect and interact efficiently.

Checklist for Hybrid Cloud Initiatives

Solutions that are part of a hybrid cloud initiative should meet these integration and extensibility requirements.

• Built-in Integrations — Quickly access public or private cloud resources from the top public and private cloud providers like VMware vCenter, OpenStack, GCP, Azure, and AWS as well as the most commonly used configuration and orchestration tools, such as Ansible, Chef, Puppet, and Kubernetes.
• Published API — Expose an easily accessible API for other systems to interact with through REST API calls or scripting so that any other system can trigger a workflow within the system such as opening a ticket or kicking off a job process.
• Plugin Architecture — Ability to extend beyond any built-in solutions with a “plugin” architecture that provides a customizable way to access other systems through API calls, webhooks, or executing a command such as sending an email message.
• Command Line SSH Access  — Provide a way to remotely manage any system by shell access or console that can make configuration changes and retrieve logging or system information such as settings files

How CloudBolt Helps with Extensibility

CloudBolt meets all aspects of this checklist by supporting all major private and public cloud providers with built-in resource handlers to set up any hybrid cloud environment.

Here’s a list of the out-of-the-box resource handlers in CloudBolt:

CloudBolt also has an extensible plugin architecture that allows users to create plugins in the form of Python scripts, remote shell scripts, webhooks, and email notifications. Plugins can be triggered in response to job events, rules, and user actions on services.

The published API provides a way for other systems to run CloudBolt jobs without interacting with the graphical user interface (GUI) and CloudBolt can be managed remotely with command line utilities in Python.

To see CloudBolt’s extensibility in action sign up for a free demo of our software