Bluemix Local: Architectural Overview

We are ready to take Bluemix into your datacentres, behind your firewall. Some of our customers require that their data should remain on premise, they want more control over the catalog, and they must have an operational view. Bluemix local delivers on all these requirements, and is powered by Relay.

Bluemix Local is a collaborative cloud development and production environment that enables developers to build applications around their most sensitive data and workloads, and deploy them to an on-premises cloud environment, addressing concerns over data sovereignty, performance, latency, and compliance by giving you direct control over the physical location of your data.

Bluemix Local rounds out the foundation of our hybrid story for us and for our customers, and we have now three distinct flavors of Bluemix to choose from: Public, Dedicated andLocal.

Architectural elements of Bluemix Local

While detailed information about our Public and Dedicated offerings have been available, let’s dive into the architectural elements of Bluemix Local.

Relay

Bluemix will be delivered, deployed and maintained through a relay. Relay allows us to push new platform updates through a consistent testing and validation process that involves initially pushing code to our staging environments, then our own internal Bluemix deployment, then to our public and dedicated environments, and finally to Bluemix Local environments.

Relay achieves secure connectivity through an outbound SSL, V** tunnel that originates from the inception virtual machine using certificates that are specific to each Bluemix Local instance. The traffic on this tunnel is UrbanCode automation for serving and maintaining the platform, compute resources, and services for your instance and allows us to remotely deploy and update Bluemix Local installs.

The initial Bluemix releases are baked into the Inception VM, which also acts as an automation agent machine for deployment and updates. SSL connection originates from Inception machine, and once a secure connection is established back to our relay, we check for the currency and consistency of Bluemix releases, and start the deployment. Relay is then used to update Bluemix Local based on a sliding window (21 days) agreed to by the customer. Beyond the initial deployment, relay is also used for consequent monitoring, logging and updates to help with operations.

Network Requirements

Inception virtual machine(s) run in a network behind the customer DMZ which can have outbound connectivity back to the Relay running in IBM Cloud. Bluemix core and services run in a private isolated VLAN. Bluemix Local uses it for the private subnet, which is more secure and can help avoid routing issues. DataPower appliances which are responsible for providing access to Bluemix application domains connect to the network which is accessible typically from the customer intranet, and where the end users deploying applications and services will plug in. It requires approximately 10 customer network IP addresses that have outbound internet access. The routing from Datapower back to the isolated Bluemix deployment is handled through NAT.

Bluemix Fabric

With the initial launch of Local, Cloud Foundry is the core open source platform which lays the foundation. Fabric is where your applications run, and they are deployed inside linux containers running on Cloud Foundry VMs. All the Cloud Foundry components like cloud controller, health manager, routers, DEAs etc. are deployed as part of the fabric, and in addition we have various Bluemix management components running there as well.

We are starting with a Cloud Foundry 64GB application pool. An additional 1.5 TB of storage is required for every four DEAs. This example is based on a DEA configured with 32 GB of RAM, 4x vCPU, and 300 GB of storage.

Bluemix Core Services

Core services support the fabric. Monitoring and Logging are deployed in customer data centers, and the data remains there. Based on certain rules, alerts are sent back to IBM, and they don’t contain any sensitive information. Logging is based on the ELK stack, and allows Bluemix to capture data from Bluemix management components for problem resolution as well Security perspective. Speaking of Security services, amongst other things we also deploy IBM QRadar Security Intelligence Platform to provide a unified architecture for integrating security information and event management, log management, anomaly detection, incident forensics and configuration and vulnerability management. IBM Endpoint Manager (IEM) is deployed in the environment as well to manage multiple endpoints from a patching perspective.

Operation and Development

The Bluemix Admin Console provides an operational view in the environment, and allows customer admins to have a view of utilization information (disk/cpu/memory/network etc.) and usage information (number of users/applications/organizations/spaces etc.). It also enables them to perform user administration from corporate LDAP, and provides access to audit reports, logs etc.

In addition, it allows Catalog management, which enables customer Bluemix operators to decide what services and runtimes they want to expose to their organizations, as well as to do fine grain management of Cloud Foundry organizations and spaces.

The Syndicated Catalog allows us to consume our Public, Dedicated and Local offerings in a true hybrid fashion. to Allows customers to consume locally deployed services, as well as services from Public Bluemix offering, making it a truly hybrid experience. Services available in hosted Bluemix can be displayed and provisioned through this syndicated catalog on demand. That means all the services provided by IBM (Watson, IoT, mobile, data services) as well as the ones from open source community and third party service providers (Twilio, Mongo, Redis etc.).