Customized Solutions in the Cloud

This entry is part of a series of postings that consider the challenges of deploying enterprise software into the cloud. Specifically, how to customers can solve their unique business problems in the cloud. Normally customers will customize their environment to suit but the cloud is an environment that typically does not tolerate customer-specific customizations.

As usual this is a balancing act. If you can take the cloud solution “as-is” and just configure it then you are in the best place from a technology and risk perspective. If you can isolate your custom processes outside of the core cloud offering then you can still leverage the benefits of the cloud but still have your custom processes. If you have to customize the core solution then you may have to stop calling it a “cloud” solution and call it an “managed service” or “hosted” model; not as sexy on your resume but a more accurate representation IMHO.

Why does the cloud create a customization issue?

Technically it isn’t the “cloud” or even multi-tenant models that cause the issue. It is the fact that the cloud provider wants to manage a large number of systems ‘en masse’. Specifically, they want to be able to push out updates, patches and performance enhancements to all of the systems without any risk of something in a specific instance breaking.

This does not just increase the hosting company’s profit margin it also gives you a much higher quality end product. How? If hundreds customers are all using exactly the same stack of software, at the same patch level and on the same hardware configuration then the chance that you will find an environmental bug is much lower. Also, the software developers will typically develop the code, do QA and benchmark on that exact stack so you have the most optimal environment possible.

So, we have established that the cloud provider wants you to run on a predictable platform. What does that mean from a practical perspective?

Customization vs. Configuration

People a lot smarter and more eloquent than I am have explained the difference between configuration and customization, usually around "writing code" vs. "using an admin client or changing XML files". However, in this case the difference is a little more specific. For the cloud, a configuration change is something that will not change the service provider's ability to manage the environment in a predictable way. However, a customization is something that removes that predictability.

The Problem with Customizations in the Cloud

An example of a customization might be custom code that writes to a non-standard database table or bypasses the standard APIs to perform operations using direct service calls.

• Writing to non-standard database tables: As the cloud service provider I have standard processes that backup the database tables...at least all of the standard ones. If my scripts don’t back up your tables and you need them to be recovered then you’ll be mighty upset. Even you adding a non-standard index to a table could be enough for one of my performance updates to take down your system.
• Bypassing supported APIs: The cloud provider’s contract with you is probably that they will document all API changes, give you fair warning before they start to deprecate functions etc. That contract only relates to the supported API set, they can change other private API calls without telling you.

Remember that in a multi-tenant model if you take down your system by bypassing these controls then you could also be taking hundreds of other systems down at the same time so the service provider is unlikely to make exceptions.

Your options: configure, customize or try something else.

Configuration:

By far the best model is to move to a configuration-driven solution. This should include configuration components for clients, server services and admin tasks. Vendors moving their solutions to the cloud cannot continue to rely on the model where they “are an open, fully extensible, platform for your custom applications”. To survive, vendors need to wake up and to start to support complex, business driven and predictable configuration-only models.

Customization:

I think that vendors need to make a call here.

1. Don’t support customizations – this restricts what your customers can do in the cloud but supports a low cost model.
2. Allow customizations but know that your cost to manage the services just increased exponentially and involves a lot of professional services work.

The latter model is closer to a managed service than a typical cloud deployment.

Something else:

This is the area where there’s the most latitude and opportunities for some creative thinking, maybe just until the configuration models mature.

Ideally, we are looking for a model where the customer gets his/her customizations but the cloud service provider still gets the predicable, uniform environment to manage.

Isolation:

The core cloud offering runs without any custom components/services but it communicates with a custom environment that includes all of the customer’s specialty code. The cloud provider can manage the core environment en masse and then someone (the cloud provider, partner or customer) is responsible for ensuring that the isolated custom pieces survive any changes to the core system. This model can work well in many cases but is predicated on the custom code not needing to run on the same servers as the actual core systems. This can work especially well for custom clients and interoperability with 3^rd party systems where the delineation is clear.

Certified Customizations:

This sounds good in principal but the reality is a little less clear. In this model the cloud service provider will publish a guide to the operations and behavior that can be tolerated in a customization. A 3^rd party (e.g. the customer or a partner) will build the custom code to that specification. An audit of the source code will be carried out which will ensure that only supported actions are being taken.

In theory, this means that the code will support the en masse management while also giving the customer the custom behavior that they need. So why isn’t this a clear winner?

1. It is expensive to carry out the certification process.

2. The process is not always 100% reliable at finding potential trouble spots.

3. Partners/customers may not be comfortable handing over the source code to the service provider for the audit.

4. In many cases the custom code will make calls to third partner components that are not available to be certified.

OEM the Cloud:

In this model the cloud service provider makes available the core product offering to a partner who then builds their solution on top of that. The partner is then responsible for delivering the end solution to their customers. They take the updates from the cloud service provider and certify that they will not do any harm to their end product before implementing them.

Conclusion

As I said at the start, this is a balancing act. If you can take the cloud solution “as-is” and just configure it then you are in the best place from a technology and risk perspective. If you can isolate your custom processes outside of the core cloud offering then you can still leverage the benefits of the cloud but still have your custom processes. If you have to customize the core solution then you may have to stop calling it a “cloud” solution and call it an “managed service” or “hosted” model; not as sexy on your resume but a more accurate representation IMHO.

Comments

[douq millar]

Perhaps a hybrid approach is to provide standard customization options in a controlled manner. In particular, your example of a custom database could be tied to a configuration file (controlling backup, mirror, performance, etc. options). So the custom database is added, but handled by cloud provider in the same standardized ways as the builtin databases. Identifying the most common requirements for customization might yield a 80-20 situation, where a few customizations, via the configurable approach, can accomplish most of the cloud clients' requirements.

[douq millar]

Another approach might follow the example of add-ons in complex software, especially also following the patterns of sandboxing. Photoshop, Firefox, Visual Studio, and others define highly restricted add-on code modules, dynamically load with only a few well-defined APIs, that allow fully customized code (the sandboxing would have to restrict I/O access, so only a few component library (like Java libraries available in browsers). Again just a few touch points in the standard system might easily handle the majority of customization requirements.