Integration of container platform essentials (Part 5)
In Part 4 of this series, we looked into details that determine how your integration becomes the key to transforming your omnichannel customer experience.
It started with laying out the process of how I’ve approached the use case by researching successful customer portfolio solutions as the basis for a generic architectural blueprint. Now it’s time to cover more blueprint details.
As mentioned before, the architectural details covered here are based on real customer integration solutions using open source technologies. The elements presented here are then the generic common architectural elements that I’ve identified and collected in a generic architectural blueprint. It’s my intent to provide a blueprint that provides guidance and not deep technical details.
This section covers the visual representations as presented, but it’s expected that they’ll be evolving visually over time. There are many ways to represent each element in this architectural blueprint, but I’ve chosen icons, text, and colors that I hope are going to make it all easy to absorb. Feel free to post comments at the bottom of this article, or contact me directly with your feedback.
Now let’s take a look at the details in this architecture and outline the elements uncovered in my research.
Everything you need to grow your career.
With your free Red Hat Developer program membership, unlock our library of cheat sheets and ebooks on next-generation application development.SIGN UP
Central to all the research I conducted was the use of a container platform for some if not all of the microservices and applications associated with the omnichannel solution.
Without a doubt, the flexibility and consistency provided by a container platform enhance the delivery of solutions provided by the development teams. The operations teams became efficient with container deployments, management, and monitoring standardized across multi-cloud infrastructures.
Within the container platform, the first elements are related to the microservices intended to facilitate front-end applications interactions with the rest of the integration services. Specific groups of (front-end) microservices are used to service the externally deployed applications:
- Front-end microservices (providing access to internal integration microservices)
- Process facade microservices (providing access to automated integration processes)
- Other integration applications (providing access to aggregated microservices or other internal applications)
- Single sign-on or SSO plugins, which proliferate for security across the microservices and container platform
Deeper access to internal microservices are the next details we’ll examine, touching on integration and data microservices.
This section of the blueprint highlights a few containerized services and the core microservices.
The process facade microservices expose core process integration functionality that is part of the depicted process server elements. Most deployments host two servers for availability and to leverage the container platform’s load balancing features.
The integration microservices and integration data microservices provide access to most anything in the organization. Imagine mainframes, third-party helpdesk desktop applications, third-party cloud platform service integrations, or whatever your imagination can come up with. Data integration can be container-native storage, third-party products, or traditional storage components found in any architecture.
An SSO server element is shown to complete the story of what’s backing the connectivity from microservices to the authentication and authorization back-end system(s) in an organization.
The final items shown here are special instances of storage labeled real-time data storage, which was part of a researched solution that included integration services requiring special performance storage in containers to stream video to external applications. Those are interesting enough to show separately here, although you would expect it in the storage services.
These details are not all-telling, but should give you the guidance you’d need to get started in your own architectural situations.
This overview covers the container platform elements that make up our architecture blueprint for omnichannel customer experience use case.
An overview of the series on omnichannel customer experience portfolio architecture blueprint can be found here:
- Part 1: How integration is key to customer experience
- Part 2: Common architectural elements for modern integration architectures
- Part 3: Integration of external application details
- Part 4: Integration of API management details
- Part 5: Integration of container platform essentials (this article)
- Part 6: Details of specific elements (storage services)
- Part 7: Application integration details
- Part 8: Dissecting several specific application integration architectures
Catch up on any articles you missed by following one of the links above.
Next in this series, we’ll be taking a look at the details of specific elements in an architecture for omnichannel customer experience.
To learn more, visit our Join the Red Hat Developer Program (it’s free) and get access to related cheat sheets (e.g. containers), books (e.g. microservices), and product downloads that can help you with your microservices and/or container application development.