The second way in which to utilize both public and private resources is on a service-by-service basis. Take a large financial institution for a hypothetical example. Let's assume there were two major points that drove the institution to private cloud: regulatory worries with financial data (such as Payment Card Industry) and legacy investment in IT infrastructure. In this case, the bank has chosen to keep its core systems in-house and architect a private cloud model to deliver the services its employees and customers need.
As this hypothetical bank's core business is financial, its IT staff excels at developing and maintaining the robust and secure systems required to run the business. That being said, its staff is not particularly adept at things like building and running customer relations management (CRM) systems. Additionally, a CRM system would not fall under the same compliance rules as the financial data, and should be appropriate for public cloud deployment. In this case, using a software-as-a-service (SaaS) solution such as Salesforce.com may provide major benefits.
In this example, something like CRM can be pushed into the public cloud, removing the burden on IT to deal with systems and services that are not core to the business or their expertise. Many services can fall into this category, even in highly specialized environments. Offloading services and applications such as CRM and email can allow the IT team to focus on driving innovation and adding value to core technologies.
Neither of these methods come without challenges. Managing a set of services that lives in both a public and private cloud environment will require careful planning and coordination. In many cases, you will want to adopt tools that have visibility into both worlds, and can monitor and manage each to some extent.
Remember that cloud computing is largely about delivering services in the most cost-effective, flexible and efficient fashion available to the business. In order to properly live up to this, services and options will need to be considered on an individual basis. What applies to one deployment model, or one service, may not apply to another.
