Marketplace service catalog concepts first design analysis EGI

Marketplace & service catalog concepts, first design analysis EGI Engage Project Dean Flanders Sept. 26, 2014

Vision from the European Commission: In 2012 the European Commission emphasized: “…as most knowledge creation and transfer uses digital means, all barriers preventing seamless online access to digital research services for collaboration, computing and accessing scientific information and to e-infrastructures must be removed by promoting a digital ERA. ” Brussels, 17. 7. 2012 COM(2012) 392 final

What are we trying to do with the marketplace? GOAL: Enable people to share and discover ANY resource they need for science. These resources can be: • Local (e. g. core facilities, lab resources) • Other institutions (e. g. software tools, clusters) • Commercial (e. g. cloud services, software licensing) OUTCOME: Increased competitiveness of European researchers

Important aspects about “cloud”: • Cloud is just a business model enabled by technology • Enables efficient sharing of resources • Allows users to focus on their core business and value creation • Forces competition between providers • Levels the competitive playing field for large and small users

Cloud efficiencies:

We need a broader understanding of what a cloud service is… …all of which need to be cloud enabled.

Science as a Service

Organizational structures have changed: Org. A Org B Org F Org C Org B Org G Org A Org. D Org H Org C Org D Org E Old world: Hierarchical New world: Federated http: //www. fedsm. eu/

Audiences for the marketplace: audience description requirements users Anyone (academic, commercial, private, etc. ) Support for multiple affiliations and discover resources. groups A group of people affiliated with one institution. Track usage and billing information of resources used by their group. organizations Any legal entity (commercial, academic, NGO, association, etc. ). A legal entity that can control users and groups, and handle related billing information. projects A group of people affiliated with one or more organizations. Useful for providing access to data. communities Like an organization but with people and groups affiliated with one or more organizations. Useful for large collaborations across multiple institutions. providers Can be a lab, core facility, commercial, etc. Can be affiliated with one or more organizations/communities. Publish into a service catalog, authentication services, billing, usage statistics, , etc. trust

Challenges they face: • Users: discovery of resources, easy access to resources • Groups: providing access to follow users in a group to resources, monitoring usage and billing of resources, approval processes • Organizations: catalog of local and external resources, facilitating billing, access management • Projects: giving access to results collected from different services • Communities: ability to organize resources shared across multiple institutions • Providers: tools allowing them to share resources internally and externally

What will the marketplace be? marketplace = enablement platform It will not be just a market place, but offer value added services such as authentication/security, mailing lists, statistics, etc. for users, groups, organizations, projects, communities, and providers.

A possible architecture: user • • • group organization community Favorites Ratings Etc. attribute providers user profile marketplace portal • • Authentication (edu. GAIN, social, enterprise, etc. ) Group management (organizational, local, etc. ) Attributes (billing information, ORCID, etc. ) Etc. directory / authentication • Search across all service types Service Catalogs • • VM registry software instruments cloud services API etc. Plugin Modules accounting / reporting billing persistent identifiers • • • proposals etc. • • Different catalogs (App. DB, GOCDB, Helix Nebula, IRIS, etc. ) Catalogs should deliver additional value to providers Can have multiple of the same type of catalog Different plugins for catalogs (e-GRANT, etc. ) Plugins should deliver additional value to service catalogs Not mandatory to the catalogs. Can have multiple of the same type of plugin

Marketplace portal: • Single portal to find all resources • Aggregation of service catalogs • User profile management • Ratings of services • Etc.

Directory: • Authentication: local, direct (e. g. organization), edu. GAIN, social, etc. • Atrribute management/integration (billing information, address, ORCID, etc. ) • Group management (local or organization integrated) • Support of concepts for users (multiple identities), groups (e. g. research), organizations (academic/commercial), communities, projects, and providers. • Self-service • Etc.

Service catalogs: • Types of items: software, cloud services, VMs, lab services, instruments, etc. • Self-service (i. e. a provider can register and use it immediately) • Provide search data into portal • Provide value added services to service providers to “cloud enable” them. • There can be redundant catalogs • Restrict visibility of resources

Plugins: • Optional to providers • Provide value added services • There can be redundant plugins

Challenges for the marketplace: • Conflict between open source and commercial services. • Commitment from organizations, providers and communities to the platform. • Duplication of entries

Examples: Net+ from Internet 2 Science Exchange UK Digital Marketplace

Questions for discussion: • What other functionalities are needed in the marketplace? • What functionalities are needed in the service catalogue? • How do they relate to each other? • What is the relationship with the pay-for-use activity and business model?