Technology and service provider perspective

Customer orientation

Base value proposition on target customer’ needs and benefits, not on technical aspects: Grid computing is still a technology that is not easy to understand. It’s key not to focus on technology but on the benefits to each target customer. Don’t sell Grid, sell solutions.

A user interface that suits the users need has to be part of the solution: The end users are very sensitive to the way an application is accessible. Very often the Grid has to be hidden behind a web portal to access the Grid infrastructure.

The end-user must be consulted all along the project, in order to check if the solution is suitable and usable: Users involvement during the project is a must to assure that there is an understanding of their needs, alignment of the solution objectives and the final customer satisfaction and acceptance, with help of customer experiences (surveys, tests…)

• Rule nº 1: Market your product focusing on the resultant benefits (added value) of your customer not on the technical advantages it offers.
• Rule nº2: Provide a user interface tailored to the profile of the end-user. Hide the Grid details if needed.
• Rule nº 3: Interact with your end-user all along the project to assure that the solution matches the expectations.

Grid solution definition and implementation

Technology providers transforming their offerings into Grid-enabled applications have to carefully change licensing models from per user or per CPU models to pay-per-use pricing models that include licensing costs: It is a challenge to set the prices and to diminish cannibalization of the same application that is not Grid-enabled. Multiple schemes targeted to the customer profile should be chosen if possible. A cautious strategy is necessary, in order to keep existing customers that do not want or cannot use the Grid-enabled application and to meet the requirements of new customers.

A new application designed from the beginning to run on the Grid might be a better choice than Grid-enabling existing applications. This application could be later easily integrated as part of cloud computing solutions as it is built on the same architectural principles: Many providers were faced from the beginning with the following dilemma: should they Grid-enable an existing application or should they develop it from scratch (based on the same requirements) in order to be provided over a Grid infrastructure? Even though Grid-enabling might look a more attractive option in terms of investment and time-consumption we believe that designing a new Grid application can offer several advantages such easier integration to service architectural paradigms like Cloud Computing and SOA and less compatibility and integration issues with existing Grid resource provisioning architectures. Nevertheless, whatever choice is made it is important that these choices are evaluated carefully from the early start.

Remember that offering a Grid enabled application is not a competitive advantage or a USP just by the fact that it is Grid-enabled: Grid enabled solutions won’t be bought just because they are based on Grid technology. Most customers, especially in the business sectors, don’t buy technology, most of the decision making people don’t understand technology, they search solutions that help them to solve problems or gain an advantage over their competitors.

It is not necessary to sell Grid in order to implement Grid: A Grid infrastructure can be used as the internal part of the provider’s solution, while this is not explicitly stated. The end-user is looking for the most efficient, cheapest, easiest solution to its problem and Grid-based solution is a key-enabler but might remain in the backstage.

Delivery of a Grid solution requires to have the whole value chain in-place: Technology providers offering only one part of the solution should position in and build up the whole value chain in order to complete the product and distribute it. The value network for Grid based services is different from traditional service provisioning and very complex in terms of contractual agreements, licensing models, definition of SLAs, accounting and billing aspects. Careful planning has to be made and a clear distribution strategy defined.

• Rule nº 4: Evaluate from the early start the choice of a new application designed to run on the Grid or Grid-enabling old applications taking into account later implications and benefits.
• Rule nº 5: When you Grid-enable an application and change the licensing model, chose, if possible, multiple schemes targeted to your customer profile to diminish cannibalization of the not Grid-enabled application.
• Rule nº 6: Don’t support your USP and value proposition exclusively on the Grid implementation but on how you provide value to your customers.
• Rule nº 7: You don’t need to say that you use Grid as underlying technology in order to sell a Grid-based solution.
• Rule nº 8: Build up the whole value chain of the solution and define the distribution strategy from the start.

Target market

Targeting the correct segment of market is a real challenge. First target the market you are most familiar with and then, once established there, move to new markets: Customers are concerned because many providers are new entrants or not IT-trusted and they prefer to purchase from a company known within their industry. Customers frequently will to pay more for a niche-oriented solution from a small company with a personalized experience. Here you can have an advantage if case you have a reputation. Once established in this market, you can move to unknown and most risky territories.

Utility computing seems to be accepted on the market but the Grid market, which is part of it, still needs to be developed, either solely or as part of another larger market such us Cloud Computing. For the next 5-7 years, Grid based business will be a business for niche applications.

• Rule nº 9: Take into account that Grid market still needs to be developed and, in the short term, Grid business will consist of niche applications.
• Rule nº 10: Target the market you are most familiar with first and once established then expand to other markets.
• Rule nº 11: Monitor continuously the market and your competitors thoroughly.
• Rule nº 12: Success and fail stories should always be investigated as well as lessons learnt.

Technology

Grid based services rely on premises which are not realistic, which have to be confirmed to be true or which have to be considered more deeply: There are technical and business premises associated with distributed computing that normally are assumed to be true and must be analysed properly case by case to make sure than none of these well known fallacies can and/or will undermine a Grid based project.  Grid computing will only be best for applications where the advantages out weigh the disadvantages based on verifiable facts not wishful thinking.

The reason for choosing Grid must be objective: It’s important that the provider sells the technology that suits best with customer’s needs and not especially the one he knows the best. It must be considered that a Grid solution might be the right solution, though not always.

In order for Grid computing to take-off investments are needed on two fronts: on infrastructures and on software/applications i.e. in complete solutions: According to our view, the maturity and market readiness of Grid technologies and applications have been both proved separately. However what is missing are the complete business models.

• Rule nº 13: Analyse the suitability of a Grid solution for each case, if it’s really the best solution according to the project strategy.
• Rule nº 14: Assess the technical issues and associated business implications in a case by case basis. Don’t base your proposal on general assumptions.
• Rule nº 15: Grid deployment relays on complete solutions that require a Grid-enabled application. You need it to attract customers.

Legal issues

Contractual issues have to be carefully tackled. Legal restrictions can be crucial barriers for Grid based solutions and services. Data security issues and reliability are crucial topics for providers of Grid based services.
The analysis of the project’s cases shows that in addition to business aspects, major legal issues have to be addressed as well. The BEinGRID project has provided an extensive analysis of such issues and specific advices to be followed that helped the BEs to diminish their legal concerns and protect themselves towards possible future implications. Some examples : contractual freedom and duties of the parties, confidentiality obligations…

The technology providers should be aware of the tax issues linked to the provision of their service.
As regards Value Added Tax (VAT), they have to verify whether any VAT is due and, if so, where. In B2B transactions the principle, for European providers, is that no VAT is due if the service is effectively directed to a customer established out of the European Union while, if the client is located in a Member State, the VAT rate of the customer’s country will be levied. For what concerns income taxation, every sever, node, cluster (in general terms, Grid component) of a Grid infrastructure is deemed to be considered as a permanent establishment of the company and therefore the profits generated by it will be taxed. This principle, accepted in many countries in the world, is not followed by the tax authorities in several jurisdictions, including, for instance, the UK.

• Rule nº 16: parties should use their contractual freedom in order to make contracts that are as complete as possible. An incomplete contract will give rise to problems and potentially litigation, i.e. loss of time and money. This is especially true in the field of Grid computing, as in many circumstances the adoption of dispersed computing resources makes legal provisions impossible to implement. Such gaps therefore shall be filled by the parties in their contracts.
• Rule nº 17: confidentiality is very important, and technology and service providers shall address it within a comprehensive security policy. Confidentiality, in particular, shall be protected through effective and clear contractual clauses.

User perspective

What is Grid? What is Grid used for?

‘Grid’ is not just cluster computing or resource sharing! Grid is a complex and heterogeneous technology, and the understanding of the term ‘Grid’ is unambiguous. Grid is related to many IT concepts, e.g. Cloud, SaaS and SOA:  Often Grid is linked to concepts like cluster computing, resource sharing, i.e. a virtualisation technique. However, Grid covers a much wider scope of aspects. Grid facilitates a lot of SOA and Cloud computing characteristics such as the use of middleware, open standardised protocols, scalability and elasticity, flexibility etc.,

Grid technology is well suited for computationally intense tasks (HPC or High Performance Computing) but its usage is not limited to it: Grid computing enables efficient usage of existing computing resources in an organization and can result in cost savings. However, it requires as a prerequisite a Grid enabled application, i.e. applications that can be deployed in a Grid environment.
In the perception of potential Grid users, Grid may be strongly linked to High Performance Computing (HPC). Through the utilization of heterogeneous and distributed computing resources Grid is suitable for tasks that are computationally intense and can thereby very well address HPC needs. However, Grid is not the only way to address such HPC needs. Moreover, Grid can address many more aspects than just HPC.
Finally, Grid computing can enable the flexible and secure creation and control of both inter- and intra-organisational Virtual Organisations (VO) across multi-disciplinary and geographically distributed domains. This collaborative nature of Grid is relevant for SMEs as well as for larger international companies.

• Rule nº 18: Consider Grid as a technology that can be applied in many areas beyond just cluster computing or resource sharing. Grid also facilitates a lot of SOA and Cloud computing characteristics.
• Rule nº 19: Grid based services can be used within or obtained from outside your organization.
• Rule nº 20: Using Grid within your organization requires a Grid middleware as well as Grid-enabled applications.
• Rule nº 21: Obtaining Grid based services externally can range from infrastructure to actual applications, and is thereby linked to utility computing and Software as a Service (SaaS).
• Rule nº 22: Beside Grid’s suitability for computationally intense tasks, also consider the collaborative characteristics of Grid if you want to establish a Virtual Organization.

Which changes does Grid come along with?

The deployment and usage of a state-of-the-art technology like Grid requires changes for customers – regarding their: technical infrastructure, organization and IT governance as well as the culture that comes along with modern IT services.

The introduction and deployment of Grid computing requires complex transition processes within the customers’ organizations. The changes that come with these transition processes are of technical, organizational and cultural nature.

On the technical side, the adoption of Grid based services goes hand in hand with the adoption of modern software and hardware architectures. In fact there is an obvious correlation between the knowledge and adoption of Grid based technologies and familiarity with and use of SOA (Service Oriented Architecture). Customers, who plan to use Grid based services, will have to adapt their IT strategy to service based technology in order to integrate Grid based services with the rest of their IT infrastructure and legacy applications.

On the organizational side, the introduction of Grid based services breaks departmental borders as it goes along with a new quality of contractual agreements (for example SLAs, SaaS etc). This applies to the definition of service levels between the customers’ organization and providers of Grid based services as well as to the definition of service levels between different departments within the customers’ organization.

This leads to the cultural changes that come with the introduction of Grid based services. The simple fact, that external IT services might be part of the customers’ Service Oriented Architecture, is a big cultural change for many customers, in particular those, who are used to develop their applications in-house.
On top of that, Grid based services require a change in the way how the users work with the applications. The tools are different, the processes are different, the “mode of operation” is different. Search for:

Grid Classification

The term Grid is not clearly defined as such and is hence applied to a wide variety of different things. Commonly they are distinguished as cluster grids , science grids and business grids . Alternatively, we may categorize Computational Grids or Data Grids according to their focus on provision of computing cycles or data solutions. They also occasionally are grouped according to the user community they address, such as Health Grids, Earth Observation Grids, Finance Grids.

Common to all these approaches is that they have a high overlap and a very blurred boundary. For the anticipated classification of a wide range of different solutions as needed for BEinGRID a new approach is required. This holds true in particular, when the categorization not only aims at grouping the experiments, but also at providing an assessment about which reference components are required for which type of Grids.

The basic assumption was that it is impossible to find one particular term or group to categorize the type of Grid. Similar properties for Grids can be found in different existing categorizations such as eScience and Business but also in different application domains from Health, Finance or Engineering.

Six major domains have been chosen organised into categories. In all domains the categories had been chosen to allow a clear allocation of an experiment to one of them. The drawback of not allowing a continuum might result in choosing a best fit category. Some domains do intentionally allow one experiment to be placed in multiple categories as for example end user might be integrated in several ways in the frame of one single experiment. The chosen domains are as follows:

1. Conglomeration based: The term conglomeration refers here to the resources or services provided by the participant in a virtual organisation. While in some cases the conglomeration is simply data or compute resources, in other cases the provided service is a complex conglomeration realised by using a large number of local or remote resources that are actively managed.
2. End­ User integration based: In this domain a Grid solution might apply to more than one category as different end users might access resources in different ways: An experiment developer might use a generic interface to design a set of standard workflows and parameter studies. A scientist might then use the pre defined workflows or experiments using a portal or application integration solution.
3. Collaboration type based: This classification looks at the nature of the collaboration of different Grid nodes. As the dynamicity of the changes in partnership have a high impact on the nature of the underlying middleware and the complexity of many aspects, it is expected that this category will be able to act as a clear differentiator between technologies. Solutions specifically designed for long term collaboration Grids will not be able to meet the requirements for ad hoc collaboration Grids and vice versa.
4. Hierarchy based: The relationship between nodes in a Grid depends directly upon how interaction between these nodes takes place and how responsibility for service provisioning is distributed. This may be regarded as the hierarchy of a Grid infrastructure, where higher nodes contain more structure related information than lower nodes, comparable to the hierarchy of a tree diagram.
5. Grid Management based: Depending on the goals pursued by the infrastructure, most Grids will require some kind of management of the participating nodes. Management as understood here involves (1) maintaining membership information, (2) maintaining, issuing and updating configuration information, (3) managing relationships and (4) coordinating execution. It may involve additional issues, such as related to legal aspects, encapsulation etc., which will not be detailed here as they may vary from case to case and do not have a direct impact on the management type.
6. Application Domain: Besides all the other categories listed above, a Grid solution may be allocated in a certain application domain or community such as Medicine or Engineering. For the purpose of the BEinGRID project it is proposed to use the domains identified for each of the Business Experiments as a descriptive category.

Optimisation of Resource Selection

The optimization component offers a service to the Grid users aiming at optimizing the scheduling of the jobs in the environment. In particular, the Optim provides a service that can be used by the Scheduler to improve quality of resource allocation. The component receives from the scheduler one or more jobs to be scheduled and it returns, for each job, an ordered list of available computing resources of the grid on which the job can be carried out respecting SLA’s constraints.

The Optimisation pattern is composed of two main components: the Optim and the GridOptimizer Components. On the basis of the Publish/Subscribe patterns, the Optim component receives from the scheduler the job to carry out (each job is related both with a RES -resource file- and the SLA that contain information about the inherent constraints like resources and time slots).

The Optim component receives both from the GRID and the Monitoring components information about the status of the system.

In particular, by using the Adapt Pattern the Optim Component obtains information about the whole grid resources from the the Grid Component; while the Monitoring Component gives information about the already existing schedule and therefore about the effective availability of each resource in the grid.

All this information is processed to evaluate which optimizing algorithm is more suitable and efficient to solve the scheduling problem. Once the problem is solved by the GridOptimizer component, the output is notified to the scheduler.

A European Multi-cloud Infrastructure for Experimentation

This week I’m at Cloudscape presenting BonFIRE, a European multi-Cloud facility that is ready, open, in operation and being used today.

Many organisations still hesitate before moving their applications and data to the Cloud. The promise is clear: increased productivity, high flexibility, elastic access to infrastructure resources, and reduced costs; especially attractive to (but not limited to) small and medium businesses. However, there are three major areas of concern that slow down the uptake; the security and privacy of my data, the trust of the chosen provider and to ensure that I am not locked in for life.

BonFIRE is the first multi-Cloud infrastructure mainly based on European open source technology (Open Nebula), with a Cloud Broker and using specifications (OCCI, OVF) that enable the concept of research by experimentation or discover by doing. BonFIRE is in operation and open for researchers from both academic and industrial organisations. It supports research across applications, services and systems targeting the services research community on the Future Internet.