Book Image

IBM Cloud Pak for Data

By : Hemanth Manda, Sriram Srinivasan, Deepak Rangarao
3 (1)
Book Image

IBM Cloud Pak for Data

3 (1)
By: Hemanth Manda, Sriram Srinivasan, Deepak Rangarao

Overview of this book

Cloud Pak for Data is IBM's modern data and AI platform that includes strategic offerings from its data and AI portfolio delivered in a cloud-native fashion with the flexibility of deployment on any cloud. The platform offers a unique approach to addressing modern challenges with an integrated mix of proprietary, open-source, and third-party services. You'll begin by getting to grips with key concepts in modern data management and artificial intelligence (AI), reviewing real-life use cases, and developing an appreciation of the AI Ladder principle. Once you've gotten to grips with the basics, you will explore how Cloud Pak for Data helps in the elegant implementation of the AI Ladder practice to collect, organize, analyze, and infuse data and trustworthy AI across your business. As you advance, you'll discover the capabilities of the platform and extension services, including how they are packaged and priced. With the help of examples present throughout the book, you will gain a deep understanding of the platform, from its rich capabilities and technical architecture to its ecosystem and key go-to-market aspects. By the end of this IBM book, you'll be able to apply IBM Cloud Pak for Data's prescriptive practices and leverage its capabilities to build a trusted data foundation and accelerate AI adoption in your enterprise.
Table of Contents (17 chapters)
Section 1: The Basics
Section 2: Product Capabilities
Section 3: Technical Details

In-namespace sub-tenancy with looser isolation

Even if the same OpenShift cluster is shared, there is still the overhead and expense of running multiple installations of Cloud Pak for Data services for each tenant. While namespace-based separation provides much more assurance in terms of meeting security, compliance, and performance SLA guarantees, it comes with additional expense. For example, we would need to install separate copies of the Kubernetes deployments in each tenant namespace, and that implies more oversight and maintenance personnel (even if the Operator pattern makes it easier to upgrade, scale, and so on). Separate copies also take up additional compute and storage resources, thus increasing the cost of procurement in the first place, as well as ongoing operational expenses.

In some cases, in the interests of reducing expenditure, some enterprises may choose to share more resources between tenants, even if it means losing flexibility or reduced isolation. In this...