Enterprises are dealing with vast amounts of data segmented across domains, leaving them needing help to identify it or capture critical insights. Furthermore, the competitive business landscape has intensified post-pandemic and spurred the realization that digital transformation is a requirement—not merely a "nice to have".
We see new business models emerging across all industries, forging new partner alliances to leverage the data within a company’s ecosystem for the next breakthrough product or service.
Taking center stage in this change is the most valuable resource in the world: data.
Unlocking the ability to capture data efficiently and provide businesses with new monetization opportunities needs a comprehensive strategy and a tactical approach. Digital transformation isn’t a product or a solution, but a continuous process with new technologies and ways of working. Many organizations' first step into digital transformation is with Red Hat OpenShift, a leading enterprise-ready Kubernetes platform.
Red Hat OpenShift has become the application platform of choice because of the secure and flexible foundation which provides a consistent experience across on-premises and multi-cloud. Designed to address the challenges that come with modernization, OpenShift provides:
- An open hybrid cloud approach
- A robust partner ecosystem
- Application and data services
- Advanced Kubernetes cluster security
- Advanced Kubernetes cluster management
- Automated installations, upgrades and life cycle management on any cloud platform
The data is everywhere
From an integration perspective, accessing data sources can require new APIs that are often designed and built from the bottom up and map directly to databases. This creates challenges for front-end teams that need to map to solution-centric UIs (user interfaces) to create customer experiences.
When multiple teams across domains need access to data, everyone ends up building another unique API layer on top of existing microservices to orchestrate for persistence and cost. However, this often spins out of control and leads to critical security issues. The lack of visibility and unification presents many technical, cross-functional process and team communication issues.
Bridging your enterprise data is not a trivial task that can be done with only a single framework or solution.
Modern data synchronization requires:
- Instant access to the data independent of the connectivity
- Flexibility on how data is handled and fetched
- Ensuring data consistency and preventing data loss
- Extend existing legacy infrastructure to cloud and mobility
Modern application teams need a layer that unifies all APIs, microservices and services to view multiple data sources as an entire data set.
Great microservices can create great complexity for app devs. Data synchronization is required to meet the challenges of complexity by ensuring data consistency. Consistency of the data is what’s necessary to create a seamless user experience and provide an edge for business.
Apollo Federation provides a unified set of data sources that compose a modularized graph. The end result—a supergraph—makes life simple again for your app developers. Their view is a single schema representing all published subgraphs, allowing them to browse and query any data they need. They don’t need to know where the data comes from, because it’s automatically composed into a supergraph as new subgraphs are created and published through the organization.
‘If I had to do it all over again…’
Being able to look at an entire customer data set transforms the approach to creating customer experiences.
“Knowing what I know now, before spending time and money to get a microservices transformation right, the first layer to really invest in is the graph." - Telco Platform Architect
One of the biggest blockers in a transformation is not having the visibility to understand your data. It ends up being a much heavier lift and time burden on teams than planned.
Moving from a product mindset to a data mindset creates unlimited potential. Instead of looking at individual components for productization, the overall data is suddenly visible because of the graph. Your graph then becomes the foundation for your customer experiences, and this is the mindset shift: Your graph becomes the actual product.
Running the Apollo Suite on Red Hat OpenShift
App dev UX
Creating a new customer experience is more than just how an end user interacts with an interface. Developers stitch complex layers together that not only craft a seamless user experience, but also create actionable intelligence for business. Interestingly, just finding the right APIs can command a great deal of a developer’s time. But, imagine if that developer had a unified schema that allowed them to:
- Create queries that fetched the exact data
- See API performance
- Enable the right APIs for use within minutes instead of days
- No longer manage backend versioning changes
With a unified supergraph, you can query a single GraphQL endpoint for all the data you need and discover, consume and optimize the data that powers new app experiences without having to navigate a sea of REST APIs and microservices.
One key principle of GraphQL is abstract, demand-oriented schema, which starts with the data an app needs to power a new customer experience. GraphQL schema design is focused on providing the data needed to power the customer experience and abstracts both the underlying microservices and data layer underneath.
The most powerful graphs abstract the lower-level backend domain models into a curated customer experience model (similar to a View Model in an MVVM pattern) that provides the high-level information displayed in the UI. This experience model can provide a consistent UX (user experience) across web, mobile and wearable apps, and also decouple the backend services from the front end with the graph serving as a facade on top of your existing microservices.
Backend dev UX
As a backend dev, you want to focus on building new services and capabilities, the freedom to evolve your services without breaking consumers, and to deliver autonomously without lots of cross-team coordination. This is a tall order when clients are consuming your services directly. Understanding what clients are using which types and fields in your service make it more difficult to refactor without introducing breaking changes, and to understand the impact of making a breaking change. This often requires coordination with all the client teams.
Backend teams need to provide their slice of the graph (a subgraph), deliver autonomously on their own schedule and compose back into a unified graph, along with many other small teams—all without breaking clients in the process. Apollo Federation provides an architecture for declaratively composing subgraphs into a unified graph, so each backend team can own their slice of the graph independently.