Overview

• 1: Technology Overview

1 - Technology Overview

Manhattan Active® Platform is a cloud-native platform for deploying and managing Manhattan’s Active® SaaS solutions such as the Manhattan Active® Omni, Supply Chain, and Inventory. The platform is built using innovative design, cutting-edge technology, software engineering expertise, and modern software development practices. This document is an overview of the objectives, architecture, and inner workings of Manhattan Active® Platform.

The reader is expected to be familiar with the architectural nuances of a modern enterprise SaaS solution and technologies such as Java, Spring framework, Docker, and Kubernetes. Familiarity with deployment architecture concepts such as load balancing, high availability, security, and operations management is also recommended.

Manhattan Active® Platform Objectives

The fundamental goal of Manhattan Active® Platform is to provide a scalable, highly available, secure, and resilient runtime for the Manhattan Active® solutions. To achieve this goal, three core objectives and the corresponding architectural principles are woven into the design of the platform:

Efficiency

The Manhattan Active® Platform is designed to run as an efficient machine to serve customers with varying volume and throughput requirements at the maximum throughput while minimizing the cost of ownership for Manhattan and the customers. The efficiency of Manhattan Active® Platform comes from its ability to run business transactions with:

• High availability to maximize the uptime of the applications and to maintain business continuity based on the committed SLAs
• Elasticity to proactively scale compute proportional to the size of the business workloads
• Cost-effectiveness to maximize the value of compute resource consumed while keeping the costs of compute low by eliminating overcommitment and waste

Flexibility

Users are most productive when the software fits well in the existing ecosystem without mandating modifications to established usage practices that require additional training efforts or incurring sizable upgrade costs. In other words, software must be malleable to fill the business gaps in an existing ecosystem. Flexibility is built into the Manhattan Active® Platform for it to be:

• Configurable based on the purpose, use cases, and requirements of the customer
• Extensible to allow customizations of business workflows and data models
• Adaptable to allow seamless integration with other applications in the customer’s environment

Open Architecture

Manhattan Active® Platform leverages modern open-source technologies and cloud-native architecture to make it polyglot and pluggable to a variety of compute vendors. Because of its open architecture, Manhattan Active® Platform can:

• API-First: Business interfaces and data operations are exposed as well-documented REST API endpoints that work equally well for both custom integration and Manhattan Active® Solution user interfaces
• Open-source: Developed, tested, delivered, deployed, and managed using well-accepted and commonly available open-source languages, frameworks, and runtimes
• Current: Remain current with the latest bugfixes and security updates offered by the open-source community
• Future Friendly: Remain future-friendly by adopting modern technologies promptly and often

Cloud-Native Microservices Architecture

The microservice architecture emphasizes modularizing the application into smaller and physically decoupled functional modules, where each module runs and functions independently while presenting a holistic business solution to the end-users. The functional modules can run as one or more instances in a separate, isolated process. Each instance of these functional modules is deployed as a disposable process and interacts with other parts of the system via a lightweight remote communication protocol built using REST/HTTP. A microservice is generally defined as a functional module with a set of key characteristics:

• Bounded context: Well-defined and minimal set of functional responsibilities
• Loosely coupled: Fewest dependencies on other functional modules, and a private state
• Service-oriented: Publishes flexible, yet backward compatible service contracts
• Disposable: Remains stateless with graceful startup and shutdowns, and is reusable
• Concurrent: Can scale horizontally as one or more ephemeral processes on demand

By contrast, applications built with monolithic architecture have multiple, tightly coupled tiers and are typically written as a single large process with a shared state spanning the entire process. Tightly coupled functional modules and a shared state make it harder and more expensive to scale, update, or upgrade the applications.

From its conception, Manhattan Active® Platform is built to run microservices as decoupled, independent, and scalable processes. The platform comprises over 250 microservices including:

• The application components and custom extensions to feature the business functionality
• The system services for indexing, messaging, identity & authorization, service discovery, monitoring and logging
• The lifecycle services for automated deployments, upgrades, scaling, healing, and configuration management

Groups of these microservices represent one or more Manhattan solutions such as Manhattan Active® Omni, Supply Chain, or Inventory. Manhattan Active® Platform provides a cloud-native runtime for these microservices, while constantly accommodating new microservices as Manhattan continues to innovate and expand its solutions and business features.

Containers

While the microservices architecture paves the way for building an elegant solution for decoupling, flexibility, and scalability, it wouldn’t be advantageous without an equally reliable deployment architecture. Manhattan Active® Platform relies on modern deployment methods to implement an equally elegant deployment architecture, using containers and Kubernetes at its core. The microservices, or the building blocks of the Manhattan Active® solutions, are built, delivered, and deployed as Docker images. Containerization offers several benefits to the release management processes for these microservices:

• Immutability of the contents of the image for consistency and authenticity of delivery
• Encapsulation of code, configuration, and dependencies into a single delivery instrument
• Isolation of microservice processes by “jail-celling” their execution runtime
• Portability across a variety of supported Docker platforms without the host OS dependency

The Continuous Integration Pipeline which builds, tests, and releases the software binaries, is responsible for containerizing the microservices and publishing them to the container registry for downstream delivery and deployment. Manhattan Active® Platform uses a Debian-based openjdk image as the base FROM layer. As part of the CI pipeline, the layers of the Docker images are scanned for known security vulnerabilities and patched promptly based on the severity of the vulnerability. To ensure a consistent Docker image structure and build process, Manhattan Active® Platform has put in place automated tooling to provision a single Dockerfile template for building the images for all application components.

Container Orchestration

Manhattan Active® Platform uses Kubernetes to manage the microservices containers. The application components and supporting services of Manhattan Active® Platform are configured, clustered, deployed, and orchestrated using pure Kubernetes, without syntactic dependencies on the underlying IaaS provider. Using Kubernetes as the abstraction layer between Manhattan Active® Platform runtime and the IaaS provider allows for a clean decoupling between the two, keeping the Manhattan Active® Platform portable to other IaaS providers.

RUBIK DEPLOYMENT FRAMEWORK

Rubik is the deployment framework built by Manhattan that provides deployment and management abstraction over the underlying infrastructure and the control plane. The Rubik deployment framework automates the deployment of the runtime components of Manhattan Active® Platform. Rubik consists of a set of modular shell scripts, YAML templates for the Kubernetes specifications, and bundles compatible versions of command-line interfaces for kubectl and other infrastructure services. Rubik is built and delivered as a containerized tool-set to the Manhattan Cloud Operations team, which uses it to perform management operations on the target instances.

To ensure that the deployment framework does not become tightly coupled with the underlying cloud provider and to maintain flexibility in choosing cloud providers, Rubik provides a set of consistent commands that work across multiple cloud providers.

RUBIK STACK

Every customer environment is deployed in a network-isolated instance that Manhattan calls a Rubik Stack or simply a Stack. A stack consists of the Kubernetes cluster responsible for orchestrating the containers and a set of infrastructure services.

A stack is created using the Rubik deployment framework commands. A newly created stack consists of:

• A Kubernetes Cluster that orchestrates compute resources, network, certificates, environment configuration, and the containers for the application microservices, essential services, and custom extensions
• A set of Infrastructure Services such as the database, IAM, DNS, messaging, and persistent storage.

KUBERNETES CONFIGURATION

The application components and supporting services are configured as Kubernetes specification files for deploying them on a Kubernetes cluster. Some of these specification files are listed below as examples:

• StatefulSet specs are used for defining stateful microservices such as the system services that offer support for persisting state.
• Deployment specs are used for defining stateless microservices such as the application components.
• Service specs are used for binding and load balancing the incoming TCP traffic from the caller to the target container.
• DaemonSet specs are used for operations that run as background processes.
• Job and CronJob specs are used for performing maintenance tasks on an ad hoc or recurring schedule.
• ConfigMap and Secret specs are used for storing configuration or sensitive data used by other runtime services.
• Ingress specs are used for defining the gateway endpoints for the incoming traffic.

Learn More

• Concept Guides
• Quick Starts

Author

• Kartik Pandya: Vice President, Manhattan Active® Platform, R&D.