In the first part of this series, we discussed the basic collection of cloud offerings and what type of value they provide to IT, Developers, and Customers. The second part explained some of the Business Issues when leveraging the cloud from with your Enterprise environment. In this post, we’ll focus more on the various services models that are associated with the Cloud.
Even within an ASP, there will be a range of providers. Let’s take Accelrys Pipeline Pilot (PP) for example. It’s a product that provides rich data-flow capabilities and has a specialty in science computing. Today, most customers deploy PP on-premise by either the Research & Development (R&D) Information Technology (IT) department or by a group of scientists. PP makes using and managing the platform in either of these scenarios extremely easy, yet powerfully scalable. Regardless of how easy it is to manage PP, there are other concerns one must have when managing any platform or application. This includes maintenance, backup and recovery, security, data management, etc. Not to mention supporting an ever growing user base also looking to leverage Pipeline Pilot. This could result in time being taken away from your main business driver: Science!
Taking the step to move your basic deployment into the “Cloud,” such as Amazon Web Service (AWS), is an interesting first start. Now you don’t have to worry about the Operation System and everything underneath it (e.g. hardware, cooling, power, etc.), but you’re still left with everything else. This is where Application Service Providers (ASP) comes into play. An ASP can come in different packages. For one, the ASP could actually be a group internally to your business. OK, so they’re not “really” an ASP, but they could function as one as they provide the service for a given cost and they’re not directly tied to your organization. Hey, could this be Corporate IT? Sure, or perhaps another scientific group within your business offering their investment to another team and doing cross charging to offset the costs. And by the way, doing this in the cloud to remove the burden and cost from IT to manage it. Perhaps this scenario has too many moving parts for your fancy. I’ll move on.
A more traditional ASP manages the application and perhaps even provides application level support. Taking Pipeline Pilot as an example again, providing application support really comes in two flavors. The first is supporting the application platform and tools themselves; for instance, if you’re writing a protocol (a set of tasks in a data pipeline) or running an application built on PP. The other is more focused on the science itself and relating it to the product. While there may be many that could help with the PP Platform, Infrastructure, and even the tools, it’s a big leap to also support the science. The key here for you is, when shopping for a cloud vendor or ASP take a look at the breath of services you’ll get from them and anticipate your need for science, application, and infrastructure support. Not to mention the difference in cloud infrastructure that requires a Message Passing Interface (MPI) infrastructure (more on that later).
If you’re in any stage of interest, planning, evaluating, or deploying Accelrys products or other scientific applications in the Cloud, we’d love to hear from you! As the leading provider of Scientific Informatics Solutions, we’re interested in supporting our customers no matter where there environment is – at home or in the cloud. Visit our forums to continue the discussion: [accelrys.org]
To view all Conrad’s Cloud Series posts, please visit: http://blog.accelrys.com/author/conrad/






