INMARSAT OpenShift Dedicated: An Inmarsat Story Kevin Crocker Integration and Interoperability Centre of Excellence Copyright Inmarsat Global Limited 2017
OpenShift Dedicated: An Inmarsat Story Outline 1 Intro 2 min 2 Who is Inmarsat 5 min 3 What we were looking for 5 min 4 Why OpenShift Dedicated 5 min 5 What are our challenges and lessons learned 10 min 6 What are our next steps 3 min
02 INMARSAT Integrations and Interoperability Who is Inmarsat Meeting the remote and mobile connectivity needs of our customers Copyright Inmarsat Global Limited 2017
Inmarsat (originated from the International Maritime Satellite Organization) In 1979, Inmarsat was set up by the International Maritime Organization to enable ships to: stay in constant touch with shore to call for help in an emergency 37-year track record in providing connectivity to customers on the move Today we support many different sectors: Governments Airlines The broadcast media Oil and gas, mining and construction Humanitarian aid agencies Providing global coverage, typically where terrestrial telecom networks are unreliable or simply cannot reach Supported by a range of satellite systems, fully optimised ground infrastructure networks and market-leading distribution partnerships
03 What we were looking for INMARSAT Integrations and Interoperability An Inmarsat for Inmarsat Copyright Inmarsat Global Limited 2017
The Business Case for an ESB Situation: Undergone growth Did not really have a core integration layer at a enterprise level to support integrations between applications and our enterprise software Significant portion of legacy application architecture is integrated through a point to point model Objective: Simplify the Architecture Reduce integration activities through a simplified integration architecture and greater re-use of components Provide flexibility and scalability to meet changing business needs Support for hosting web services and message brokers Strategy: Focus on Future An ESB is a foundational component in the target architecture Adopt newer architectural models such as API, microservice, containerization, etc. Sys 1 Sys 2 Sys 3 Sys 1 Sys 2 Sys 3 App 3 SaaS App 3 E S B SaaS App 2 App 2 DB App 1 DB App 1 Portal Portal
The Decision Approach: Due Diligence Completed significant research on ESB platforms and various vendors Developed an extensive list of functional and non-functional requirements (100+) Criteria: High Level Future flexibility and scalability was key Resiliency to avoid a single point of failure Capabilities Developer Tools Developer Flexibility Deployment Options High Availability Infrastructure Models Load Balancing Capabilities Service Deployment Options Distribution of components Formation of a logical bus Management of messages Isolation of components Decision: RedHat Based on the technical, non-technical and commercial analysis JBoss Fuse Integration Services met our integration needs
04 Why OpenShift Dedicated INMARSAT Integrations and Interoperability Focus on the Services Copyright Inmarsat Global Limited 2017
The open source projects that underpin the platform are very stable Numerous connectors available or ability to write our own New open source components supporting new architecture models are typically available faster than other vendor roadmap availability Because the platform has open standards then there is no vendor lock-in Cloud platform based on industry standard Docker containers Fits well with our delivery approach (Agile/DevOps/CI-CD) and the deployment model gives us flexibility in what we use to implement each service Strong support for on premise, cloud and hybrid-cloud deployments OpenShift lets us develop, test and deploy our services independently Supports deployments in a distributed hosting model with no single point of failure Enabled us to focus on building and deploying the services, rather than on operating the base platform.
05 INMARSAT Integrations and Interoperability What are our challenges and lessons learned Copyright Inmarsat Global Limited 2017
Learning and Discovery #1: OpenShift Dedicated - Capacity Management Assumptions: Stability was guaranteed in the out of the box state Assumed we would use FIS (Camel based applications) for all integration services That the footprint of our services (memory, cpu) would be greatly diminished with the container model Challenges: How to properly test and tune resource configurations for optimization Pods are not isolated. They can impact each other by constraining the physical hardware on the node OpenShift helped us start to look at a micro-service model but we are challenged on the balance between having small, independent deployable components versus the resource footprint the component consumes on the platform Lessons: That setting proper resource limits in the platform is important A lot more responsibility on the designers, developers and testers to plan for capacity and write optimized code Using a micro-service model can decentralize a lot of decisions regarding programming languages, frameworks and allow developers to experiment more. Technology itself will not replace a well-defined and working team structure but OpenShift is very receptive to the DevOps Model.
Learning and Discovery #2: OpenShift Dedicated - Upgrades Assumptions: That OpenShift Dedicated would just work and upgrades would not be something we would have to worry about. Challenges: Educating others about the platform Planning a upgrade in a small window and with the least disruption Lessons: Platform upgrades have to be managed like any other upgrade
Learning and Discovery #3: OpenShift Dedicated Non-Functional Requirements Assumptions: Enterprise level monitoring capabilities and logging would be out of the box Challenges: Achieving a centralized logging Achieving a common monitoring capability to see all services and their health at a glance. Developers are primarily using the platform and are learning a lot of the administrative and supporting tasks. Lessons: Understand the differences between the offerings (OpenShift Dedicated vs OpenShift Container Platform)
Learning and Discovery #1: General - Container Development Assumptions: Challenges: Shift in mindset to treat the environment as containers and not as an enterprise application server. There is often a mindset that we should share/pool authentication, certificates, libraries, database connection and pooling across all applications. Testing of containers and environment management Lessons: Education and awareness across all groups and not just the architectural ad development team
Learning and Discovery Feedback from the Team Challenges: Steep learning curve for the team. Have to learn new platform, CI/CD practises, Java etc. Limited syntax help available for creating yaml/json files for creation of containers/pods/services etc. Absence of acceptable best practice guidelines for the use of OpenShift. CLI documentation is not complete and correctness is questionable. Limited validation and/or reports from a platform upgrade. Customer left to validate and raise support tickets. Support processes Accomplishments: Keeping a development team interested Delivering reusable enterprise level micro-services Simple call to return specific data Delivering data feeds Integration service that handles 14+ million messages / day
06 INMARSAT Integrations and Interoperability Next Steps Continuing to build. Copyright Inmarsat Global Limited 2017
OpenShift Dedicated OpenShift Platform (FIS) Better visibility of system performance and capacity for improved planning Evaluate other container and micro service languages thus looking beyond FIS for services that are very small (python, go service, etc) Looking at making the system fully fault tolerant using multi AZs Bringing operational roles into the team Additional Uses BPM Suite Non-Integration Type Application Development