To continue where we left off with the last blog, this time we are trying to understand cost. When we start considering cloud, the primary driver seems to be economic (cost), thus we need to make sure we address any cost-related barriers associated with adoption of cloud as well as ensure that our expectations are honest and appropriate.
Given that we are talking about HPC, this implies that compute is important to the business in some significant way. So whether your business is in media, EDA, oil & gas, biosciences, pharmaceuticals, financial analysis, or some other computationally intensive field, figuring out how to provide HPC services more efficiently will have an impact on the delivery of the core business product and the bottom line. Because cloud is a combination of people, process, and technology , we should hold off talking about reducing the cost of hardware until later in the blog, and focus on having the appropriate amount of hardware and increasing the efficiency of usage, provisioning, management, etc. We should also focus on linking into the core business, using EDA as an example, the cost of EDA Licenses are a higher order driver that is facilitated by the infrastructure. And finally, what are the consumers of the infrastructure sacrificing because they don’t have enough capacity, resources or lack access to a specific technology or capability?
In the big picture, cloud computing is outsourcing significant portions of what was once IT functions and resources. Some companies have been able to very successfully outsource, and have been happy with their decision and relationship. Others however, have not had such good experiences, and we want to address those negative legacy perception. For any people who survived a bad outsource experience, those bad memories become hurdles that we as an industry must navigate if we intend cloud computing to be successful. Those perceptions come in the form of additional complexity, higher costs, and a disconnect in responsibility.
When we talk about additional complexity, we are commonly referring to inserted complexity from contract structures. One of the smartest people I know once said that managing anything through contracts is no way to run a business. It needs to be about developing relationships, and if we resort to debating points in the contract, the relationship has already broken down, and we should look to mutually vacate that relationship. That is not to say that a contract serves no purpose. It is a statement of intent, and a testimony to the seriousness of the risk one or both of the parties is placing his or her business, reputation, and livelihood in. Contracts are like tactical nukes – it is very important to have them as a mutual deterrent for bad behavior, but using it means we have all lost. Many times in outsource scenarios, the provider wants to charge for any effort not specifically defined in the contract. Technology is a fast paced, evolving world. Things are going to change. In this scenario, focus turns to the contract, or the “rules” and policy, and gets in the way of what it should be about – delivering value and results to the end user.
When we talk about higher costs, we are really talking about additional cost, reduced control, and little or no benefit. In an outsource model, many times the resources are the same or similar to what was in-house originally, only there is less direct control over those resources, and we now have to pay for an additional layer of management from the outsource provider. One of the benefits of using an outsource model is that the provider is part of a larger eco-system, and can deliver a larger variety of resources or different skillsets than what the consumer company could normally provide on their own. If this dynamic is not met by the provider, then are we really gaining anything in exchange for what we gave up. The outsource supplier needs to BE a larger ecosystem. And always the filter of “could this be done better, cheaper, or faster in-house” needs to be passed. We will discuss this point more in the blog on “changes to organizational structure”. Being part of a larger eco-system allows benefits that would be difficult for an isolated entity to achieve:
- Consuming top tier processors for all workloads, trading them for the next generation processor when they are available.
- Access to domain experts at fractional cost in non-dedicated fashion
- Access to very large capacity, paying based on use
- Ability to share cost burden of special resources across multiple customers at different times
The final element is the disconnect in responsibility, where the outsourcer is focused on the business of outsourcing, or the responsibilities of IT, and losing sight of the core business of the customer. Responsibility to the business is lost in translation. For the customer to feel comfortable relinquishing control of their infrastructure, they need to know that the service provider feels responsible for the success of the customer business and knows the intimate details of how the business works well enough to properly determine how technology could help, and then proactively drive technology to the benefit of the customer. This is an important point. It is not sufficient for the provider to know technology and IT really well, assuming applications and implementations are less relevant. If the customer needs to know his business AND drive the service provider for what he/she needs from technology to help the business, then the customer will continue to own IT in-house, because that cheaper, easier, and faster for the customer. In this new world order (cloud), the service provider needs to be a trusted domain expert advisor to the customer about the customer’s business, which means not just IT. Service providers should not bring in additional distractions, and need to have responsibility as part of the equation
- Maintenance is a series of constant upgrades. Design for change.
- Infrastructure cost should be established as a run rate, not a series of one time buys
- The Infrastructure needs to have an equal seat at the company table (see future blog on control)
- A proper implementation of cloud computing implies changes to organizational structure for control purposes (see future blog on control)
Once we have addressed historical barriers to adoption based on cost, we also need to make sure we appropriately represent the cost benefits that cloud computing promises. Cost savings associated with cloud computing may not be what you think. Cloud is an opportunity to change people, process, and technology. If you are not open to changes on all three fronts, we will not be able to achieve the best value proposition. Just changing technology will result in the same results we have seen in the past (a large source of frustration with IT). We do not expect to get what we use for less money, but the process of getting and using the resource can be made more efficient and therefore the overall solution would be less expensive.
There is a long term opportunity for cost reduction, but it entails some re-education. The hardware industry has been delivering to the Moore’s Law equation (“2X more every 2 years for the same price” or “1/2 the price every 2 years for the same thing”) for the last 30 years, so the customer’s expectations is that solutions related to hardware fall on that curve as well. As software becomes a larger part of the solution, we have some correcting to do to match the expectations of the customers (and probably not in the direction to make the software industry happy).
Given that we are talking about HPC implies that we are working with a growth oriented workload, so our goal would be to get more value for the same money as the infrastructure grows and evolves out of necessity. In addition, there are lots of things that we are not getting to today that we would like to / should do. Having access to more capacity and different resources would go a long way to correcting the need. Leveraging cloud can eliminate operational activities, making time for design activities. And if we standardize those designs, we improve our negotiating position. The focus should be on differentiating the business, address customer issues and customer of customer issues. More efficient execution in any portion of the process frees up resources to do more in other areas.
Delivery on cloud computing will generate another long term cost benefit. Cost reductions will not be immediate though. Costs will reduce over time as consumption process matures and based on evolution. There will also be a “smushing” effect, much like what happened with the hardware industry, where components at one time were allowed to be priced individually, but then they became component parts of a single system, and the component vendors had to compete for their piece of the pie that was the total system cost. Cloud consumption will also drive commoditization of component resources in a similar way. Over time, cloud will have the effect of cost reduction of solutions, but not in a simplistic equation. With cloud, we will see costs abstracted to a requirements level, with consumers agreeing to pay for an expected result, and service providers absorbing the responsibility of delivering that expected result, or paying pre-negotiated indemnity. The service provider will then be in the position to provide that service with any combination of technologies they choose, and will be held accountable for meeting the agreed to performance metrics (what, not how). Things like the OS, virtualization technologies, monitoring, provisioning, will become part of the end solution. Customers will be buying services, not products, so name brands start to mean less. Features and capabilities are up to the cloud supplier to provide however they like, as long as the service level (requirement) is met. Customers will want a service and a price appropriate to the service level. This will take a little time because it is essentially building competitors to what exists today, and existing vendors will also begin competing at these new price points.
We will eventually achieve the cost benefit that is envisioned as the advantage of cloudd computing. But we will need to make that a reality by creating the market through demand, and then holding the suppliers accountable for delivering the solutions necessary at prices that are appropriate.
Original blog post found at HPC in the Cloud.