Summary
AXIS 10 is a fundamental re-architecture of the AXIS platform, not a feature-only release. The architectural changes are designed to improve upgradeability (take AXIS Product updates in days, versus migrations that previously spanned several months), hosting efficiency, improved resiliency, scalability, deployment automation, and cloud-provider choice while preserving AXIS' role as a premium OTT platform for complex, differentiated streaming experiences.
Kubernetes-based container deployment supports more efficient hosting, deployment, resiliency, and scalability.
The platform moves from a monolithic architecture toward discrete microservice domains that can scale and evolve more independently and efficiently, due to reduced scaling time.
Modernized, versioned API contracts reduce the risk of breaking changes and create a clearer integration path.
A more disciplined extensibility model protects upgradeability by reducing direct changes to core AXIS engines.
Customer-specific needs can be supported through configuration, productised capabilities, or bespoke microservices integrated with AXIS.
A new ingestion service introduces a REST API and single microservice entry point for content ingestion.
Release and upgrade flows are designed around component-level releases, automated deployment, migration scripting, regression testing, and load testing.
Visit our What is AXIS 10? article for an introduction, and AXIS 10 changes for Presentation Manager operators and administrators for UX/UI details.
Backend change map
Area | AXIS 10 backend change | Customer benefit |
|---|---|---|
Hosting and runtime | AXIS is deployed in Kubernetes containers. | More efficient hosting, faster environment setup and deployments, and a stronger foundation for scaling high-demand OTT services. |
Architecture | AXIS is decomposed from a monolith into microservice domains. | Greater relialiance, more targeted scaling, improved maintainability, and a stronger foundation for ongoing product evolution. |
Cloud strategy | AXIS is decoupled from AWS dependency and made compatible with AWS, GCP, and Azure. | More flexibility to align AXIS deployments with preferred cloud providers, regional requirements, and data-sovereignty needs. |
Deployment | Infrastructure configuration and management are treated as code. | More consistent deployments and clearer path to repeatable environment management. |
APIs | Existing API contracts are modernized and versioned. | Lower integration risk and clearer expectations when adopting new capabilities or platform releases. |
Legacy components | Legacy ISL, ESB, and Rocket components are removed. | A cleaner architecture that removes outdated dependencies and supports a more modern operating model. |
Architecture changes
Kubernetes and Containerization
AXIS 10 uses Kubernetes containers to improve deployment, hosting efficiency, and scalability. This supports more standardised environments, streamlined CI/CD, improved resource utilisation, and faster deployments.
Platform infrastructure and microservices are provisioned as part of onboarding.
Regression and load testing confirm whether the environment is ready for expected usage.
Infrastructure can be refined based on test outcomes before production launch.
Microservices-based architecture
The backend shifts away from a monolithic model into discrete microservice domains. This is intended to support independent scaling, performance optimisation, better maintainability, and more efficient product development, testing, and deployment.
Specific service boundaries and deployment details are confirmed during solution design so the AXIS 10 architecture can be aligned to each customer's operating model and integration needs. This allows for easy integrations of bespoke services e.g., customers wanting to use their own Search or Recommendations services.
Domain-driven development
AXIS 10 applies domain-driven development principles so the software model better reflects business needs. The expected backend benefit is clearer extensibility and maintainability across platform domains.
Versioned API contracts
Implementation detail: API versioning rules, compatibility expectations, endpoint references, authentication patterns, and request/response examples are confirmed as part of the technical onboarding and integration workstream.
AXIS 10 modernises and versions existing API contracts. This helps reduce the risk of future breaking changes and provides a clearer way to manage new features over time.
Customization and Extensibility model
AXIS 10 changes the backend customisation model so customer platforms can remain closer to the product roadmap and easier to upgrade. The core principle is to avoid direct changes to AXIS Core engines and use defined extensibility routes instead.
Customization route | Use when | Backend guidance |
|---|---|---|
Configuration | Existing functionality can be modified sufficiently without code. | User configuration for supported extensions such as custom rows, page layouts, non-playable catalog items where supported, and search fine-tuning. |
Productization | A customer requirement has wider product value. | Access for inclusion in the AXIS roadmap or product capability set. Tenant-specific feature flags may be used selectively, but should be limited to avoid unnecessary divergence. |
Bespoke microservices | The requirement does not fit the AXIS domain or is highly customer-specific. | Create a custom component that integrates with AXIS using modernised REST APIs and projections, and deploy it on the same infrastructure where agreed. |
Core engines no longer customizable
Publish, Events Store, API Caching, and Management API are treated as AXIS Core engines. Protecting these core engines from direct customer-specific change helps avoid fragmented implementations and reduces the effort required for future upgrades.
Requirements are first assessed against existing functionality and configuration options.
Requirements that may benefit multiple customers can be considered for productisation.
Customer-specific requirements are reviewed to determine whether a bespoke implementation is the right long-term approach.
Where bespoke implementation is required, the preferred route is a microservice or component integrated with AXIS rather than a core fork.
REST APIs and projections for extensions
AXIS 10 provides a modernised suite of REST APIs and projections, including system-event messages and notifications. These enable custom components to extend selected aspects of the platform where required.
Content ingestion backend changes
Implementation detail: Ingestion schemas, validation rules, authentication, retry and error handling, dependency-order examples, and sample payloads are confirmed during technical onboarding.
AXIS 10 introduces a new ingestion service. Content ingestion may still need to reflect customer-specific metadata and workflow requirements, but the new API is designed to make implementation easier and more standardised than existing XML-based workflows.
Content ingestion is handled through a REST API rather than complex and outdated XML workflows.
A single microservice API entry point is provided for all content ingestion.
A standardised template will be available, while custom solutions remain possible.
The ingestion service is expected to simplify handling of asset creation and dependencies, including asset relations, and offers.
During onboarding, customer content metadata is ingested for VOD, live, and linear requirements as applicable.
Release, upgrade, and deployment flow
Customer onboarding
AXIS repositories, access permissions, and CI/CD setup are prepared for the customer environment.
The required AXIS platform infrastructure and microservices are provisioned.
Testing automation is configured for the relevant environments.
Presentation Manager page structure and information architecture are configured after design and sitemap sign-off.
Customer content metadata is ingested into AXIS using the new ingestion capability.
Regression and load testing validate the environment against anticipated platform usage.
Infrastructure is refined based on test results before production readiness is confirmed.
Customer-specific test coverage is maintained as the platform evolves.
Customer product and technical training.
New releases
AXIS 10 releases are component-oriented. Typically only a subset of components changes in a given release, depending on the features or fixes included.
Customer upgrade adoption
Upgrade scheduling is agreed customer by customer. AXIS 10 is designed to make it easier for customers to adopt new releases soon after they become available, with deployment to the customer environment, regression testing, issue resolution, and go-live handled through an agreed release process.
We recommend that customers are not on a version of AXIS any later than current release -1 for maintainability reasons.
Customer migrations
Existing AXIS customers complete a migration activity to benefit from AXIS 10. The migration assesses current customizations, integrations, data, infrastructure, and bespoke functionality so the new architecture can be adopted safely.
New AXIS 10 customer migrations require a collaborative exercise between Product and Project on a gap analysis, where Project provides details of all Project customisations for analysis by the product team for how best to accommodate these in AXIS 10.
