Would you trust your cloud provider to provide anti-malware protection?

July 4, 2010

The popularity of cloud services continues to grow.  The key players are companies like Google, Amazon, and Microsoft who are each spending a ton of money improving and promoting their services.

For companies who do not have the ability (or desire) to build and support their own web-based applications, a cloud-based architecture offers many advantages, including:

  • Scalability
  • Integrated database services
  • User authorization and permission services
  • Pay for what you need

However, there are a number of risks with a cloud-based application, including:

  • Large, visible, popular systems can attract malware attacks from bad guys.
  • Proprietary services make it difficult to change cloud providers.
  • Little visibility into how the internal services actually work and even less control.

And now there are a number of advocates for anti-malware capabilities in the cloud, including Phil Wainewright’s recent column and John Viega’s latest book  “The Myths of Security: What the Computer Security Industry Doesn’t Want You to Know“.   Their argument is pretty simple — the threats are in the cloud, so that is where the threat protection should be.  Frankly, I think their argument makes a lot of sense.

However, if your company has acquired cloud services from one of the key players — THEY decide what services are available to you.  And given the history of these companies and their propensity to build their own capabilities, it is very likely that they would develop their own anti-malware tooling and integrate it into their cloud platforms.

Thus the key question — Would you trust your valuable data and the future potential of your company to a cloud platform provider who has little, if any, history in successfully protecting its users from malware attacks?

I think that this issue has the potential to severely impact the growth of cloud-based computing, but will probably be ignored until the first major breach of a cloud — then the lid will come off and the finger-pointing will begin.

What do you think?

Evolving from service-oriented s/w products to a common product platform

June 16, 2010

A potential client wanted advice on evolving their service-oriented software products to a common product platform. Their plan was to revise their application using a popular cloud computing toolkit, migrate all of their customers to this new product version, and retire their current offerings.  So, with all of the attention that cloud computing is getting these days, I thought I would share some of what we talked about and see what your thoughts are…

First, two quick definitions so that we can start on the same page:

Service-oriented products — You host customized versions of your software for each of your customers, typically using a single instance for each customer.  As a result, you may even have situations where different customers are using different versions of your software.   Since each customer’s data resides on a different system, the risk of co-mingling data between customers is low.

Common product platform — You host a single generic (or common) version of your software that is shared among multiple customers and configured to provide them with individualized capabilities and user interfaces.  You use enhanced security mechanisms to ensure that data from your customers is not co-mingled.  Once a user logs into your system, you use their login credentials to present them with a customer-specific user experience.

The key advantages of a service-oriented product approach are that (a) each customer gets exactly what they need, (b) data co-mingling between customers is nearly impossible, and (c) you can roll-out additional capabilities to selected customers very easily — which makes it easy to do specialized testing and to write contracts for individualized capabilities.

However, service-oriented products also have (a) increased maintenance, development, and upgrade requirements because everything must be applied to each implementation individually, (b) severe scalability issues as you get more and more customers — each with their own implementation, and (c) escalating cost issues because each new customer is a new installation without any of the economies of scale that normally come with commercial software.

Thus, it’s easy to see why many software companies start by offering their products as a service and then want to evolve to a common product platform over time.

However, this “evolution” also brings a number of key challenges, as follows:

  • Product Capabilities and Complexity — It is pretty easy to create a software product that can be customized.  The Development team removes the standard routine and plugs in the new, highly customized routine and Voila!, the product now does something significantly different.  “Plug-Ins” like this have been used for years in a wide variety of applications.  However, creating a framework that allows multiple plug-ins to be executed, based upon the user’s profile is much more challenging to architect, develop, test, and deploy.  And you also have to identify all of the places in the framework where a plug-in is necessary.   Lastly, since multiple customers will be sharing the same software instance, your framework has to be sufficiently robust to allow a plug-in for one user to fail gracefully without impacting any of the other users on the system.
  • Company Culture — If your company has been selling highly customized product versions for a while, you have an entire culture devoted to this concept.  So just imagine the conversation when a key sales rep wants “just one more” highly customized product version so that they can bring in a huge order near the end of your fiscal year.  And of course, how will your company handle a number of “just one more” situations?
  • Customer Migration — Even if the capabilities of your common product platform encompass all of the capabilities from all of your customer-specific product versions AND you have migrated all of your customers’ data into the new system, migration will still be an issue for your customers.  At the very least, they will have to retrain all of their users and their system administrators will have to understand how the platform has been configured for them.
  • Product Development Process — Every software product fails at some point in its life.  With a service-oriented product, the failure is normally limited to a single customer implementation.   With a common product platform, a failure will most likely affect multiple customers.  Thus, you may need to re-evaluate a number of aspects of your product development process to ensure that failures of this type are caught during the design, development, and testing of the system.  In some cases, you may need personnel who have different skills / experiences than your current staff so that you can prevent problems before they occur.
  • Product Architecture — Every “technology stack” that is used to develop and deploy a software application has a certain amount of capabilities and a number of limitations.  This is especially true with cloud computing platforms where many of the architecture elements of the system are provided by others and cannot be changed by you.   Thus, you need to verify that your common product platform can be implemented using the technology stack that you have selected (or your cloud computing partner is provided).  You should also cross-check your planned product roadmap against the technical limitations.  You don’t want to spend a ton of money (and time) building a common product platform using a new technology stack only to find out that you will reach a dead-end in 3 years — or just about the time you get all of your current customers happily (you hope) using your new platform.

In summary, evolving from a service-oriented software product to a common product platform can be very challenging.  However, the rewards are worthwhile and you can reduce much of your pain if you (a) take the time to create good quality plans, (b) consistently execute your plans, and (c) clearly communicate among all of the internal participants.

Finally, your customers are your most important asset.  So while you are developing your common product platform, you MUST continue to aggressively support their customized versions and help them see the benefits they will derive from the common product platform once it is available.  You don’t want to EVER announce that you are getting out of the customized software business in favor of a not-yet-available product platform and hope that your customers (and your competitors) will wait patiently for your to execute on your vision — because they won’t.

Just ask all of those customers who used to buy Prime minicomputers how “patient” they were when Prime announced they were going to minimize their hardware efforts in favor of software…

%d bloggers like this: