In my last blog post I pointed out you can never actually avoid vendor or technology lock-in. This is particularly applicable to the main orchestration tool you use. You have to choose one orchestrator and will want to stay with that choice for quite some time. So, making the right choice is key.
As long as clear standards have not emerged you will have to make a choice regarding which technology you implement. Such technology can be provided by a vendor, meaning you trust the vendor, or come from a consortium building open source tools. In that case you are betting that consortium will be a winner moving forward.
Since you can’t ever be fully sure, it’s critical right from the initial choice to look at how the tools you use can interact with the external world. This will allow you down the road to integrate with other environments if your original choice does not turn out. Here are five pragmatic things you better check out early.
1. Support of heterogeneous environments (hardware, operating systems and hypervisors)
This one is particularly applicable if you choose an integrated cloud environment but should be checked in other situations also.
Which server, storage and networking infrastructures are supported by the environment you choose? How easy is it to add infrastructure from a different type?Not only does this allow you to include some of your existing infrastructure in your cloud, but it leaves you the freedom to make alternative choices moving forward.
Most applications today are built either on Windows or Linux, but some still use a variety of UNIX type operating systems or even private ones. What OS is used by the applications you are planning to move to the cloud and are those supported by your environment? This is a key question to evaluate.
The third element to this step is the hypervisor. Today the majority of the market uses VMWare’s products. But we slowly see a shift to other hypervisors such as Hyper-V and KVM. Costs and technology factors play a role here. Don’t limit yourself to one hypervisor, but make sure your environment supports multiple, giving you the possibility to choose what is best for you. Even if your existing operational systems run on VMWare, maybe you want to use KVM for the development of new applications. Some development tools currently in the market actually allow you to automate the deployment of applications on multiple cloud environments. This allows you, for example, to use KVM for development and most of testing while you run VMWare in production, hence reducing license costs.
2. The availability of APIs
How can I interact with the chosen technology? Can I trigger actions from other applications or portals without requiring manual intervention? What do the application programming interfaces (APIs) allow me to do? How well are they documented? How easy are they to set up and use? These questions are fundamental in ensuring the technology is open and gives me the flexibility to evolve as my needs change. A couple API standards are emerging (AWS and OpenStack), but they only address IaaS functionality at the moment. You’ll probably need more.
Look at APIs from two ways: incoming and outgoing APIs. Can an external environment trigger an action using the technology and can the technology initiate an action that needs to be taken by an external environment? Here are a couple specific areas to look at:
- Can I perform all functions available in the portal through programmatic interactions?
- Do I have the possibility to integrate an external identification/access management environment?
- Can I integrate with my existing LDAP/Active Directory environment and use its information?
- Can I use an external approval environment to approve for example the provisioning by a user of a service?
- Can I integrate an external service in my catalog (we’ll talk more on that a little further in this blog post)
This is a non-exhaustive list. Make sure you have yours prior making a choice.
3. Template Designs
Orchestration uses templates to define what action to take. Those are typically designed using graphical user interfaces.
Obviously, in case you decide to change orchestration tools, the last thing you want is to have to redesign the thousands of workflows or templates you designed. Hence the fact standards are emerging. The most documented one at the moment is TOSCA. However, we are still in the early days, so we cannot be sure this is going to be it. So, make sure the technology you choose is clearly intended to support a standard. Support of TOSCA is a good proof point.
4. Configuring external services
I often highlight intermediation, aggregation and bursting in this blog. All three require a programmatic interaction with external systems. This implies interactions between the two environments. We already talked about the APIs, their documentation and what they would do. But there is another aspect to look at and this is how the external service can be integrated.
Let me give an example. You want to integrate Salesforce.com in your catalog, allowing your users to request access to your CRM environment on Salesforce.com. You will need to describe the service in your catalog, define which users can request access and potentially identify an approval process and a price or chargeback for the service. But then, you will need to make sure that, when a user places the request, this request is actually transmitted to Salesforce.com. You will define an orchestration template that will trigger the transfer of the request and check whether it actually succeeded or not. But then you will have to describe how Salesforce is actually triggered. You will use some of Salesforce’s APIs to perform this task. Salesforce makes its functionality available through SOAP and RESTful APIs as described in the documentation. You will connect an action in your orchestration template with an XML string that is transferred using the API technology chosen. For each action you plan to perform, you will have to configure such action. This is how you build the integration. But obviously you only have to do that once for each external service you plan to integrate.
Before choosing a technology, make sure you understand how this can be done, and how effective and secure the communication is.
The last element to review is the level of customization that is offered. Over the years your users have become familiar with a specific vocabulary and a way of doing things. Can you adapt the portal and the other functionality exposed to the user to something familiar to them? Also remember the questions I raised earlier. You may have a specific identification and access mechanism. Can that one be integrated? You may have your own approval process mechanism; can that one be replicated or integrated? And I could go on like this.
Assess how well you can customize the environment to your specific needs. But at the same time, check whether you can keep the customization when moving from one version of the software to the next one. You don’t want to have to redo everything when you upgrade your software. And in the cloud environment, newer versions of the software are regularly released.
When choosing a specific technology you are locking yourself in, whether you want to or not. Moving to a different one will be painful. So, make sure you are taking the right bet. Chose a technology that allows you not just to address today’s needs, but to grow with them as they evolve. Keep my five rules in mind as they will help you find an environment that can grow with you. And that is probably the most important. Frankly, most often companies change technology because the existing one becomes a bottleneck. Make sure you do not have to do that.