IBM BP Session - Multiple CLoud Paks and Cloud Paks Foundational Services.pptx
•Als PPTX, PDF herunterladen•
0 gefällt mir•1,028 views
Diese Präsentation beinhaltet Erfahrungen, Empfehlungen und Planungs-Gedanken, die man beachten sollte, wenn man multiple IBM Cloud Paks auf der Container Platform OpenShift installieren / deployen möchte. Es beschreibt die Grundlagen zu "common services", auch "foundational services" genannt, die als Basis-Services die Lauffähigkeit dieser Cloud Paks auf OpenShift erläutert und wie man Cloud Paks auch logisch trennen kann auf OpenShift worker nodes über taints und node selectors.
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Ähnlich wie IBM BP Session - Multiple CLoud Paks and Cloud Paks Foundational Services.pptx
Ähnlich wie IBM BP Session - Multiple CLoud Paks and Cloud Paks Foundational Services.pptx (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
IBM BP Session - Multiple CLoud Paks and Cloud Paks Foundational Services.pptx
- 1. Multiple Cloud Paks auf OpenShift Best Practices und Empfehlungen IBM Cloud Pak Foundational Services and Automation Foundation Georg Ember IBM Deutschland Brand Technical Specialist, IBM Automation
- 2. Table of Contents A Platform for Multiple Cloud Paks Architectural View of Cloud Paks on OpenShift IBM Cloud Paks Foundational Services Automation Foundation (Services) Cloud Pak on OpenShift Dependencies
- 3. IBM Cloud Paks Automate Predict Secure • Customer Experience • Business Ops • Workforce Management • App and Infrastructure Stability • Platform Ops • Optimize AI Ops • Hybrid Cloud Integration • Real-Time Interactions • Transactional Integrity • Site Deployment Automation • 4G/5G Telco Cloud Platform • NFV Lifecycle Management • Data Modernization • Data Ops • AI Lifecycle Management • Data Warehousing • Trusted and Distributed AI • Continuous Integrated Financial Planning • Operational and IT Risk Management • Customer Service Automation • Textual / Document Analysis • Advanced Threat Detection • Data Security • Incident Response • Threat Hunting • Risk Management IBM Cloud Pak for Data IBM Cloud Pak for Security Cloud Pak for Business Automation Cloud Pak for Watson AIOps Cloud Pak for Integration Cloud Pak for Network Automation IBM Cloud Pak Foundational Services and Automation Foundation Services Red Hat OpenShift + RHEL Enterprise-Grade Kubernetes Orchestration IBM Cloud Public Cloud AWS • Azure • GCP • Other IBM Systems Enterprise Infrastructure Edge 3
- 4. Cloud Pak Foundational Services Red Hat OpenShift remains very much the core of this platform, with common Foundational Services sitting atop of this platform to interoperate capabilities with the IBM Cloud Paks Beneath the applications and Cloud Paks is the set of core, common, shared services — called the Cloud Paks Foundational Services or (in brief) Foundational Services (aka “common services”) 4
- 5. Foundational Services Overview 5 https://www.ibm.com/docs/en/cloud-paks/1.0?topic=cloud-pak-foundational-services Note : Not all of the IBM Cloud Paks support all of the foundational services.
- 6. IBM Foundational Services aka “Common Services” aka “Bedrock” Red Hat OpenShift + RHEL Enterprise-Grade Kubernetes Orchestration IBM Cloud Paks Automate • Predict • Secure Application Services Data & Event Services Operational Services Security Services User Experience Services IBM Cloud Paks Foundational Services Certification and Governance for Enterprise Standards • API/Endpoint Library • Notifications • Behavior Analytics • Gateway / Front Door • Execution Engines • Kafka Service • Repositories • Databases • Metering • Licensing • Logging & Monitoring • Operator-based Lifecycle Management • Service Mapping Framework • Bedrock Storage Map • IAM • Vault Service • Threat Detection • Audit Log (Compliance) • Certificate Management • UI/UX Standards • App Lifecycle UI • Bedrock Admin Hub • Job Scheduling • Extensible UI Framework & Extension Registry (ZenRock)
- 7. UX Services — Cloud Pak Administration Hub 7
- 8. Sizing and Deploying Foundational Services 8 https://www.ibm.com/docs/en/cloud-paks/1.0?topic=services-hardware-requirements-recommendations-foundational Important: https://www.ibm.com/docs/en/cpfs?topic=co-installing-cloud-pak-foundational-services-in- custom-namespace-version-37x-onwards - You can install foundational services in a custom namespace only if you are installing them for the first time in your cluster. - You cannot migrate foundational services to another namespace if they are already installed in your cluster. - You can install foundational services in only one namespace in your cluster.
- 9. Cloud Pak for Data Example for Deploying Foundational Services 9 https://www.ibm.com/docs/en/cloud-paks/cp-data/4.0?topic=tasks-installing-cloud-pak-foundational-services
- 10. Automation Foundation (Services) IBM Automation foundation (IAF) provides a foundation for the IBM Cloud Paks for Automation. Cloud Paks use the event framework that is built on - Kafka cluster, Flink Cluster, Elasticsearch cluster, Apicurio instance 10
- 11. Automation Foundation Event Processing Framework The following event framework (IBM Automation Foundation Event Processing) components are extra dependencies for Business Automation Insights. Apicurio Registry (iaf-system-apicurio) Apicurio Registry is a datastore for sharing event schemas across event-driven architectures. You can share and manage your data types and API descriptions at run time by using a REST interface. Apache Kafka (ibm-events-operator) A managed cluster that can be shared by IBM Cloud Paks. Each Cloud Pak is supplied with a set of credentials for Kafka that provides full access to create, delete, read, and write resources. Apache Flink (EventProcessor: iaf-flink image) A framework and distributed processing engine for stateful computations over unbounded and bounded data streams. Elasticsearch (ibm-elastic-stack-operator) An Elasticsearch, Logstash, and Kibana (ELK) stack to collect and store all Docker-captured logs. Zookeeper (iaf-system-zookeeper) You can configure Flink clusters to work with high availability services like Zookeeper. 11
- 12. Automation (Foundation) Assets IBM Automation assets Users of the IBM Automation foundation are able to use the Automation assets to share assets across platform capabilities. Storing assets, such as JSON schemas, within this repository allows them to be accessed directly within the user interface of certain capabilities. 12
- 13. Cloud Pak Dependencies OpenShift Versions Licensing Worker Nodes Node Selectors Catalog Source Operators
- 14. IBM Cloud Pak and Red Hat OpenShift version compatibility objective https://www.ibm.com/support/pages/node/6457303 IBM Cloud Paks come with a Red Hat OpenShift limited (cloud pak only usage) license where both follow slightly different lifecycle policies. IBM objective is to continue stay compatible with Red Hat OpenShift releases. IBM Cloud Pak Versions will focus on OCP EUS versions. It will be necessary to update Red Hat OpenShift at least once during the Cloud Pak support lifecycle to remain on a supported Red Hat OpenShift level. All supported Cloud Pak continuous delivery versions will support the latest OpenShift EUS minor version (e.g. 4.6) within 30 days of its release, for the duration of its support period. To stay current with the updated RedHat OCP lifecycle policy (https://cloud.redhat.com/blog/time-is-on-your-side-a- change-to-the-openshift-4-lifecycle), EUS versions are even minor releases beginning with 4.8. 14
- 15. Which common services will be installed by Cloud Paks ? The Cloud Pak Operator installs the following services (if not already present) : - Certificate management service (ibm-cert-manager-operator) - Identity and Access Management Service (IAM Service) – if a specific userid to a GUI is needed. - Administration hub (ibm-commonui-operator, e.g. ZEN) - Automation Foundation (Event Processing) Which common services will NOT be installed automatically by a Cloud Pak (but you can install individually) : - License Service - Logging, Monitoring - Metering, Auditing - Robotic Process Automation (RPA) 15
- 16. Licensing Service just runs ONCE in an OCP cluster ! https://www.ibm.com/docs/en/cloud-paks/cp-integration/2021.4?topic=service-verifying-completeness-license-usage-data#validation Note: Only one instance of License Service is deployed per cluster regardless of the number of IBM Cloud Pak solutions and containerized products that you have installed on this cluster. 16
- 17. Operational Services — Licensing Services per Cluster 17
- 18. IBM Cloud Pak Installation Dependencies https://www.ibm.com/docs/en/cloud-paks/1.0?topic=environment-preparing After you've installed Red Hat OpenShift Container Platform, there are a set of tasks you can perform before installing your IBM Cloud® Paks. 18
- 19. Placing Cloud Pak pods on OpenShift worker nodes using Taints https://docs.openshift.com/container-platform/4.8/nodes/scheduling/nodes-scheduler-taints-tolerations.html Taints and tolerations allow the node to control which pods should (or should not) be scheduled on them. You apply taints to a node through the Node specification (NodeSpec) and apply tolerations to a pod through the Pod specification (PodSpec). When you apply a taint to a node, the scheduler cannot place a pod on that node unless the pod can tolerate the taint. You can put multiple taints on the same node and multiple tolerations on the same pod. OpenShift Container Platform processes multiple taints and tolerations 19
- 20. Node Selectors for Cloud Paks https://docs.openshift.com/container-platform/4.8/nodes/scheduling/nodes-scheduler-node-selectors.html A node selector specifies a map of key/value pairs that are defined using custom labels on nodes and selectors specified in pods. For the pod to be eligible to run on a node, the pod must have the same key/value node selector as the label on the node. You can use a node selector to place specific pods on specific nodes, cluster-wide node selectors to place new pods on specific nodes anywhere in the cluster, and project node selectors to place new pods in a project on specific nodes. You can use node selectors in a project together with labels / taints on nodes to constrain all pods created in that project to the labelled nodes. When you create a pod in this project, OpenShift Container Platform adds the node selectors to the pods in the project and schedules the pods on a node with matching labels in the project. 20
- 21. Catalog Source and Entitlement Key https://www.ibm.com/docs/en/cloud-paks/cp-integration/2021.4?topic=installing-adding-catalog-sources-online- openshift-cluster A catalog source (e.g. ibm-operator-catalog) should be specified for each Cloud Pak, either cluster-wide or per namespace. It depends what is good for your org and installation type (online or air-gapped). The entitlement key and pull-secret sometimes needs to be updated, if new Cloud Pak releases or image versions will be pulled. This is due to access control of your purchased software products in PA. 21
- 22. Multiple Cloud Pak Considerations and Planning Important points to be planned ahead : Which Cloud Paks together ? Common Services or Closed Services ? Storage Access Modes (default storage class) OpenShift Cluster Version compatibility Licensing and Node Limits Networking Zones and Node placement Inter-Cluster HA or Intra-Cluster HA ?
- 23. IBM IT Infrastructure / © 2021 IBM Corporation
- 24. Foundational Services — 5 Key Pillars The foundational Foundational Services (accessible by each of the IBM Cloud Paks) represent aggregations of microservices, technologies, and capabilities. Foundational Services can be organized into 5 distinct pillars: Application Services, Security Services, Operational Services, User Experience, and Data Services • Each pillar of services support a common, consistent operational experience, user experience, and integration experience • Not every Platform Service will be transparent to end-users or customers, but each service will directly (or indirectly) benefit those audiences • These services are not something that can be purchased from a catalog — they are embedded as part of the IBM Cloud Paks experience on top of OpenShift (and eventually the Cloud Paks Platform) Application Services Data & Event Services Operational Services Security Services User Experience Services IBM Cloud Paks Foundational Services Certification and Governance for Enterprise Standards 24
- 25. Operational Services — Logging & Monitoring WHO • DevOps Managers, Site Reliability Engineers (SREs), Developers WHAT • Built on top of an Elasticsearch, Fluentd, and Kibana stack, it provides pre-configured and self-updated logging services for both the Platform cluster and applications running atop of it WHY • DevOps teams and Site Reliability Engineers (SREs) can easily view real-time resource utilization of Cloud Paks services and applications, allowing clients to isolate and resolve application issues quickly • Logging information is integrated with role based access control (RBAC) so that teams can only see what they are authorized to see 25
- 26. Security Services — Certificate Management WHO • IT Security and Ops, System Administrators, Regulators WHAT • The certificate manager can automatically refresh leaf certificates created from a CA issuer, using KeyProtect from IBM Cloud WHY • Administrator can easily configure my preferred certificate authority and know that services will utilize the right standards for secure interactions • Certificate management gives clients the ability to easily secure service interactions without concern for the certificate authorities that customers have established 26
- 27. Security Services — Identity and Access Management WHO • IT Security and Ops, System Administrators, Regulators WHAT • Customers can use common login, SSO, manage RBAC to resources across their IBM Cloud Paks investments, and integrate with their identity provider of choice WHY • Customers can log in once and navigate between various Cloud Paks, common services, and OpenShift Container Platform without ever being presented with another authentication-related screen for the duration of their active session 27
- 28. UX Services — Application Lifecycle UI WHO • Operations Managers, Cluster Managers, Developers WHAT • Provides a UI component library for instance creation, editing, and upgrade • Adds basic CRUD (create-read-update-delete) operations on custom resource APIs WHY • Customers of multiple Cloud Paks will be able to readily and easily move from one to the other • Creating and managing software instances will be more consistent, regardless of what service a customer is working with 28
- 29. Security Services — Audit Logging (Compliance) WHO • IT Security and Ops, System Administrators, Regulators WHAT • A common audit logging service and framework simplifies and standardizes the delivery of software capabilities that can be configured to log security events and comply with common policies WHY • Products running on the platform can easily be configured to log security events, for compliance with common internal or external security policies • Accelerated delivery of products that comply with common security postures, through adoption of a common service and format, instead of developing their own 29
- 30. UX Services — Bedrock Administration Hub WHO • Cluster Administrators, Operations Managers, Developers WHAT • Provides a central point for configuration, information, and interaction with IBM Cloud Paks and other Foundational Services installed in an OpenShift cluster WHY • Provides a consistent experience for IBM customers looking to conduct administration across their Cloud Paks investments • They need to understand at a glance which Cloud Paks are running, how resources are being consumed across the cluster, the ability to add users for Cloud Paks, and trigger serviceability connections 30
Hinweis der Redaktion
- In this presentation you will learn how common services, containers, and an orchestration platform come together to enable modernized application services that is ready for the hybrid multicloud world. This presentation explores how IBM Cloud Paks Foundational Services are critical to a customer’s success in this endeavor.
- Table of contents for this presentation.
- Let's start with examining the 3 core aggregations— "Security," "Data," and "Automation" (and their respective Cloud Paks) —at the top, and then progress further down the stack to the underlying common Foundational Services, to the OpenShift Container Platform for Kubernetes orchestration, to the infrastructure at the base. This chart depicts the catalog of Cloud Paks as they exist in April 2021 and going into 2022. The Cloud Paks are aggregated into three pillars of Security, Data, and Automation, with details below those pillars on the types of use cases and personas that these collections of Cloud Paks are intended to support. Those of you familiar with the history of Cloud Paks will recognize that IBM already had a Cloud Pak for Data and a Cloud Pak for Security in the past, yet today and going forward "Security" and "Data" are also the names of the pillars (to which these Cloud Paks belong). It's important to frame conversations of these three pillars with customers as "capabilities" and "use case" value, rather than getting into the underlying Cloud Paks too soon in the discussion. Remember: IBM is aiming to further and further remove the boundaries between the individual Cloud Paks (moving from verticals to horizontals). Your focus should be on what are use cases and personas you're targeting (as a seller), what are the capabilities your customers need to address those challenges, and what Cloud Paks we can recommend as a solution. Keep in mind as well that the integrated nature of Cloud Paks (today, and increasingly so going forward) means that customers can consume Cloud Paks capabilities in a modular and ad-hoc fashion, integrating them seamlessly in support of applications running atop OpenShift and Cloud Paks stacks.
- Cloud Paks: yes they are containerized, yes they run on OpenShift, yes they are getting certified. But they are also packaged in what could be described as a "coarse grain view" of IBM software: with each Cloud Pak are multiple capabilities that support specific use cases and personas, aggregated into a single offering, pre-integrated so it can be installed as one thing. Customers can pick and choose the capabilities out of that to support their own applications and services. This is essentially what IBM calls a Cloud Pak: an aggregation of capabilities, in containerized form, running on Red Hat OpenShift as the hybrid multicloud platform. This layering has been around for a while and hasn't gone away. In 2019-2020, when IBM first began work on IBM Cloud Paks in earnest, the general philosophy of the architecture was to have Cloud Paks running atop of OpenShift, with a layer of "Bedrock" core services layered between the two. Compare that to today's architecture and you'll find that this more or less remains the case. OpenShift remains very much the core of this platform, common "Foundational Services" are still sitting atop of this platform to interoperate capabilities with the Cloud Paks, and the Cloud Paks (of which there were 6 flavors at the time in 2019-2020) remain at the uppermost strata of the layers. There is a fundamental difference, however, with respect to the Cloud Paks and core Foundational Services, and the relationship these components have with one another. The challenge IBM encountered (internally in terms of management and externally with respect to customer adoption) was that the earlier generation of Cloud Paks were relatively isolated and siloed from one another. The architecture was too "vertical" and created too much friction when trying to integrate capabilities across the various Cloud Paks solutions. The future-facing direction and philosophy of Cloud Paks is to rearchitect Cloud Paks from a series of "verticals" into "horizontals," in order to break down the silos between the various services and truly embrace the "plug and play" (modular) vision of Cloud Paks. The first step was started in 2020-2021 and continues into 2021-2022 (and beyond.) The new wave of Cloud Paks represents that evolution. Instead of having six discrete Cloud Paks, IBM has three functional "pillars" around Security, Data, and Automation. Security and Data existed as distinct Cloud Paks before, and the newly-created "Automation" pillar in fact contains multiple Cloud Paks tailored for specific use cases or needs. The result is that Cloud Paks are now organized based on aggregations of capabilities (capabilities around Data, around Security, around Automation), in support of specific personas and customers. While these labels may change slightly over time— there might be some repackaging, one box may move from one aggregation into another, or may move into the Foundational Services (underlying all of this) in order to service all of the Cloud Paks atop —but overall this is the structure IBM is building towards and it's a fair assumption that these three pillars will be where future capabilities live. IBM’s strategic long term goal is the creation of one IBM Cloud Paks Platform (CPP). All of IBM’s software capabilities will be built upon and running on a common base: with a common operational model, a common user experience across everything, a common set of basic technologies and other capabilities available in that ecosystem, and then on top of that common base a set of specific capabilities (Cloud Paks) in support of precise use cases or personas that a customer can select from in a very granular way. To bring things back to the "verticals" and "horizontals" mentioned earlier, IBM is ultimately moving from multiple vertically-aligned Cloud Paks silos to a single horizontally-integrated Cloud Paks Platform. Everything IBM is doing architecturally today is in support of that end-goal.
- Beneath the applications and Cloud Paks is the set of core, common, shared services. What we call "Cloud Paks Foundational Services" or simply "Foundational Services." IBM and product naming are strange bedfellows. Particularly so in the case of services that IBM doesn’t "sell" (per se), such as the Foundational Services depicted here, which aren't sold as a standalone catalog product but nevertheless are of critical value to customers. As such, you may hear Foundational Services described by a slew of different names, depending on where you look: core services, foundations, and so on. Understand that all of these terms are referring to the same thing— the layer between the Cloud Paks containerized software above and the OpenShift container orchestration platform below —what we call "Foundational Services." The five pillars you see depicted on this chart are similar to the 3 groupings (Security, Data, Automation) shown earlier on the Cloud Paks architecture slide. They represent aggregations of microservices, technologies, and capabilities of Foundational Services into 5 distinct pillars: Application Services, Security Services, Operational Services, User Experience, and Data Services. We will go into each of these in much further detail later on in this presentation. For now, understand that the pillars on this chart are in support of a common, consistent operational experience, user experience, and integration experience. Not all of these items are going to be something a customer needs to concern themselves well. In fact, with Foundational Services, a significant benefit of having this shared common layer across all of the Cloud Paks is that customers don't need to worry about these components — but they give IBM huge gains in efficiency and consistency with regards to maintaining and developing the OpenShift and Cloud Paks Platform. One example of "things that keep us up at night" as systems administrators and purveyors of "as a Service" offerings is the use of data services. Obviously IBM has many capabilities across its portfolio that make use of data. We at IBM often need to ask ourselves: can everyone bring their own database? How many different flavors of SQL do we need and can support on this platform? Wouldn't it make more sense if we were to go and consolidate on a known and well-defined set of SQL and NoSQL data services, and then have IBM customers prioritize use of those databases, instead of rolling their own each time? That provides IBM with significant efficiency gains (in the sense that IBM doesn’t need to reinvent the wheel and duplicate efforts across the board). It also makes it easier for us to run all of these things in concert, or run them on the same cluster, and we avoid things such as versioning or implementation conflicts between different versions of different things. All of this translates to a better quality of life and experience for our customers, who no longer need to ask questions about "how is it implemented?" but rather focus on "what can this software do for me?"
- Bedrock Administration Hub (“Admin Hub”) https://pages.github.ibm.com/IBMPrivateCloud/BedrockServices/UXServices/Bedrock-Administration-Hub.html https://pages.github.ibm.com/IBMPrivateCloud/BedrockServices/AdopterGuides/AdminHubAdoption.html WHO Cluster Administrators Operations Managers Developers WHAT The Admin Hub provides a central point for configuration, information, and interaction with IBM Cloud Paks and other Foundational Services installed in an OpenShift cluster. The service is typically used by the Cluster Administrator to: Ensure that Cloud Paks and their required Foundational Services are installed and running correctly Administer identity management through the Identity and Access Manager (IAM) Manage license compliance for IBM containerized offerings Launch into the OpenShift console in the context of IBM offerings for more detailed analysis Gather cluster information and specific IBM offering information for use in problem determination or reporting issues to support WHY The Admin Hub provides a consistent experience for IBM customers looking to conduct administration across their Cloud Paks investments. Administrators need to understand at a glance: which Cloud Paks are running; how resources are being consumed across the cluster; the ability to add users, teams, and roles for actively-running Cloud Paks; and the ability to trigger serviceability connections.
- Table of contents for this presentation.
- Licensing https://pages.github.ibm.com/IBMPrivateCloud/BedrockServices/OperationalServices/Licensing.html WHO System Administrators Lines of Business Operations Managers WHAT The License Service provides license consumption reporting and audit readiness for IBM containerized software. It is required for license tracking of IBM Cloud Pak solutions and IBM Certified Containers, and covers the requirements that are defined by IBM’s worldwide (WW) pricing guidelines (as well as outlining of customer obligations as defined in the Container Licensing rules). The License Service is also useful to any customer that wants to view and understand their license consumption of IBM Certified Container Software or IBM Cloud Pak solutions running on a Red Hat OpenShift cluster. It also supports non-OpenShift environments like IBM Cloud public Kubernetes clusters. It also provides optional support for sending the collected license usage data to Red Hat Marketplace via optional configuration. Starting with the IBM Cloud Paks Foundational Services v3.5 release, the License Service provides another optional component— License Service Reporter —with a Web UI that displays information on multi-cluster license usage, simplifying how customers consolidate data from multiple clusters and traditional IBM License Metric Tool (ILMT) deployments. WHY A license consumption service is immensely useful for any customer that wants the ability to check the VPC license consumption of an IBM Certified Container or IBM Cloud Paks running on a Red Hat OpenShift cluster. Customers can determine their daily license utilization, or check if they are in compliance with respect to the purchased licenses quantities, for all IBM Cloud Paks or Certified containers in any cluster. In turn, customers will be able to understand what they have installed and how heavily they are utilizing those licensed offerings. Enterprise clients in particular need to be always ready for software audits. They require a certified backend license counting tool that is continuously capturing VPC license consumption of IBM software —and ready at any time to generate a digitally signed audit snapshot, required by IBM Compliance during any audit activities.
- Table of contents for this presentation.
- How does IBM prevent OpenShift and Cloud Paks from becoming a large, monolithic mess that we can't reasonably install on a customer system? Particularly if a customer wants to start small? (Which, obviously, many customers do want to start small.) A lesson learned the hard way in the past is that no vendor can go to a customer on Day 1 and say: "Here's a production-ready environment. By the way, you'll need to set up X number of servers and workers nodes before you can even run 'Hello, World!' Good luck." Instead, certification and standards spell out a clear set of principles that directly guide how IBM wants to build the common Foundational Services and how to define a consumption model for them. One of the most important of these principles is that everything in Bedrock needs to be OPTIONAL. After all, IBM wants to support the start-small initiatives of its customers, as much as the expansive full-stack requirements of its enterprise clients. IBM wants to get away from going to customers and asking them to install OpenShift, then Foundational Services, and then Cloud Paks — when really all that the customer wanted was access to the Cloud Paks in the first place. This approach reverses the conversation so that on Day 1 an IBM seller can have the conversation with a customer along the lines of: "What are the capabilities you need, which Cloud Paks meet that requirement, and how can common Foundational Services pull those capabilities together and deploy them under the covers, where and when they are needed?" In that respect, it's useful to avoid thinking about Foundational Services as yet another "first class citizen" layer within the Cloud Paks stack. After all, Foundational Services aren't a catalog item that customers will be making a purchase order for. Instead, Foundational Services are deliberately designed be a SECOND CLASS CITIZEN because everything done in Foundational Services is in direct support of the functionality of the Cloud Paks themselves. Cloud Paks are IBM offerings — they are what IBM goes to market with and what customers order off the catalog. Foundational Services are NOT an offering and will NOT be a product that we sell (directly), but it's nevertheless a tremendous means to an end and value-add.
- Logging & Monitoring https://pages.github.ibm.com/IBMPrivateCloud/BedrockServices/OperationalServices/Logging.html https://pages.github.ibm.com/IBMPrivateCloud/BedrockServices/OperationalServices/Monitoring-Redhat-Application-Monitoring-Service.html WHO DevOps Managers Site Reliability Engineers (SREs) Developers WHAT Built on top of an Elasticsearch, Fluentd, and Kibana stack, it provides pre-configured and self-updated logging services for both the platform cluster and applications running atop of it. Clients are able to easily view and understand Cloud Paks observability metrics, integrating these logging tools with their own services. The Foundational Service's monitoring is built on top of Prometheus and uses pre-installed Grafana to query and visualize cluster metrics. Prometheus is an open source project designed for event monitoring and alerting, particularly for time series data where the capture of real-time metrics is essential. Grafana likewise focuses on time series data and specializes in providing interactive visualizations (charts, graphs, and alerts) for such data points. WHY DevOps teams and Site Reliability Engineers (SREs) can easily view real-time resource utilization of Cloud Paks services and applications, allowing customers to isolate and resolve application issues quickly. Application logs are consolidated in a common location, with search and aggregation available on those records to help administrators isolate and resolve problems more efficiently. Logging information is integrated with role based access control (RBAC) so that teams can only see what they are authorized to see.
- Certificate Management https://pages.github.ibm.com/IBMPrivateCloud/BedrockServices/SecurityServices/Certificate-Management-data-security.html WHO IT Security and Ops System Administrators Regulators WHAT The certificate manager can automatically refresh leaf certificates created from a certificate authority (CA) issuer, using KeyProtect from IBM Cloud. WHY CA issuers, within the scope of cryptography, are able to issue digital certificates that give proof of some entity’s ownership of a public key (certifying that the public key is valid and therefore trusted for use with your personal ‘private’ key). By providing a Certificate Management layer within IBM Cloud Paks Foundational Services, administrators can easily configure their environment to work with their preferred CA issuers, and know that Cloud Paks services (or applications built atop of them) will utilize the right standards— every time —for secure interactions. Customers only need to integrate the Foundational Service with their existing security standards, infrastructure, and applications.
- Identity and Access Management (IAM) https://pages.github.ibm.com/IBMPrivateCloud/BedrockServices/SecurityServices/Identity-and-Access-Management.html WHO IT Security and Ops System Administrators Regulators WHAT Customers can use common login, single sign-on (SSO), manage role-based access controls (RBAC) to resources across their Cloud Paks investments, and integrate with their identity provider of choice. SSO allows users to log in and access all capabilities of the Platform, without needing to repeatedly log in again from the same system (or device). RBAC in particular will help customers tailor the users’ platform capabilities (what they can and cannot see within the platform) according to that user’s roles and level of access within your organization. The Access Management component provides a set of prebuilt roles and permissions as well. There are two key dimensions to what the Identity and Access Management service provides IBM Cloud Paks: it helps define roles and permissions which govern access to the capabilities provided by the platform; secondly, it provides access controls to Kubernetes orchestration resources via "Kubernetes Access Management" for customers that need access to Kubernetes namespaces and control over which users can access those namespaces. This component will update the Kubernetes namespace using the Kubernetes RBAC mechanism. Consumers of the IAM Foundational Service will integrate using Open ID Connect (OIDC) or OAuth protocols. The IAM component will allow integrations that leverage both API and Web Browser flows. OIDC and OAuth flow are the preferred standards, without eliminating the possibility of including non-standard flows to support backward compatibility or to accommodate user scenarios not contemplated by the specification (i.e. API Key-based grant types). Applications running atop of the IBM Cloud Paks will register with the IAM component to act as an OIDC / OAuth client / relying party. The IAM component will be the issuer of security tokens by acting as the OIDC / OAuth authorization server. WHY Customers can log in once and navigate between various Cloud Paks, common services, and OpenShift Container Platform without needing to be presented with additional authentication-related screen for the duration of their active session. They can easily integrate existing enterprise directories into authentication and authorization for IBM Cloud Paks. For administrators overseeing one or more Cloud Paks capabilities, it is vital to be able to easily locate users and manage their access to resources and services. An administrator can easily view and filter IAM content to show items relevant to a particular Cloud Pak or namespace, eliminating potentially tedious and confusing manual browsing of environments where multiple Cloud Paks are running.
- Application Lifecycle UI https://pages.github.ibm.com/IBMPrivateCloud/BedrockServices/UXServices/Application-Lifecycle.html WHO Operations Managers Cluster Managers Developers WHAT Provides a UI (user interface) component library for instance creation, editing, and upgrades. IBM Cloud Paks make use of operators to managing custom resources and deliver capabilities to end-users. Naturally, those IBM Cloud Paks need to be able to manage the lifecycle of those custom resources over time. The Application Lifecycle UI provides a clean, simple, configurable sets of components for each of these lifecycle operations. It also provides an express router which enables basic CRUD (Create, Read, Update, Delete) operations on custom resource APIs. For example: Cloud Pak for Integration users can create instances of integration capabilities from within the platform navigator UI App Connect users can deploy instances of integration servers from within the App Connect Dashboard Users of a common service catalog will need to create instances of those services via the UI WHY Customers of multiple IBM Cloud Paks will be able to readily create and manage software instances, custom resources, and resource lifecycles in a more consistent fashion, regardless of what service a customer is working with.
- Audit Logging (Compliance) https://pages.github.ibm.com/IBMPrivateCloud/BedrockServices/SecurityServices/Audit-Logging.html WHO IT Security and Ops System Administrators Regulators WHAT A common audit logging service and framework that simplifies and standardizes the delivery of software capabilities, which can be configured to log security events and comply with common security policies. The service uses a variety of technologies to carry out audit logging and compliance checks, including: CADF (Cloud Auditing Data Federation) - Audit logging format standards Sysflow - Tool suite for monitoring system behavior for scalable security, compliance, and performance analytics Fluentd - Open Source data collector for audit logs WHY Products running on the platform can be easily configured to log security events in order to maintain compliance with common internal or external security policies. The service accelerates the delivery of products that comply with common security postures, through adoption of a common service and format, instead of requiring customers to develop their own (from scratch) each time. For example, a client might request to configure their software capabilities to log security events in support of internal or external audits, governance, or compliance mandates. By using IBM Cloud Paks and the Foundational Services layer, those clients can automatically collect identity and access (create, read, update, and delete) information to comply with industry compliance standards (e.g. PCI, FISMA, or HIPPA ). When using Cloud Paks capabilities in their development pipelines, customers gain access to the tools needed to deliver compliant solutions. When security problems arise, they can quickly track down identity and access patterns that may have been responsible for the incident. PCI: Payment Card Industry data security standard that ensures all companies accept, process, store, and transmit credit card information in a secure environment. FISMA: Federal Information Security Management Act, established in 2002 by the US federal government, mandates federal agencies to develop, document, and implement information security strategies across said agencies and their partners or contractors. HIPPA: Health Insurance Portability and Accountability Act provides national standards, guidance, and protections for personal health information within the United States of America.
- Bedrock Administration Hub (“Admin Hub”) https://pages.github.ibm.com/IBMPrivateCloud/BedrockServices/UXServices/Bedrock-Administration-Hub.html https://pages.github.ibm.com/IBMPrivateCloud/BedrockServices/AdopterGuides/AdminHubAdoption.html WHO Cluster Administrators Operations Managers Developers WHAT The Admin Hub provides a central point for configuration, information, and interaction with IBM Cloud Paks and other Foundational Services installed in an OpenShift cluster. The service is typically used by the Cluster Administrator to: Ensure that Cloud Paks and their required Foundational Services are installed and running correctly Administer identity management through the Identity and Access Manager (IAM) Manage license compliance for IBM containerized offerings Launch into the OpenShift console in the context of IBM offerings for more detailed analysis Gather cluster information and specific IBM offering information for use in problem determination or reporting issues to support WHY The Admin Hub provides a consistent experience for IBM customers looking to conduct administration across their Cloud Paks investments. Administrators need to understand at a glance: which Cloud Paks are running; how resources are being consumed across the cluster; the ability to add users, teams, and roles for actively-running Cloud Paks; and the ability to trigger serviceability connections.