How, where, and why IBM Bluemix Local System and PureApplication fit in your cloud
A cloud computing primer that explains when Bluemix Local System and PureApplication make sense
Cloud computing delivers a set of technology capabilities and business functions as services on demand over the Internet or on a private network. The "cloud" is the infrastructure that the services run on. It generally consists of hypervisors, virtual machines (VMs), containers, storage devices, and networking devices, in addition to the workload management technologies that make it possible to effectively deliver those services.
Using such technologies as middleware and web-based software as services saves money, expedites development and deployment time, and reduces resource overhead. Users access only what they need for a particular task and benefit from the flexibility, economies of scale, and optimized management of resources.
IBM® Bluemix® Local System and PureApplication® simplify and automate how you create, provision, and reuse applications and their environments. By using pre-built, customizable patterns of expertise from IBM and IBM Business Partners, and by using IBM Bluemix® cloud platform services, you can significantly reduce the amount of time, effort, and resources that are needed to deliver your apps.
IBM PureApplication product family
The PureApplication product family has the following members:
- IBM Bluemix Local System (on Intel® x86)
- IBM PureApplication System (on IBM POWER8®)
- IBM PureApplication Software
- IBM PureApplication Service
IBM Bluemix Local System on Intel and PureApplication System on POWER® are cloud-in-a-box configurations. They are fully integrated systems that include hardware, software, hypervisors, and network devices, all converged in a single physical box and managed through a unified console.
The IBM Bluemix Local System is the newest member of the family, announced on 26 July 2016. It is specially designed and built to bring cloud-enabled applications and cloud-native apps onto the same Intel x86 environment. Much like PureApplication System on POWER8, the Bluemix Local System comes with pre-integrated hardware and PureApplication and Bluemix Local software, saving you significant installation and configuration time.
PureApplication Software, which is included in Bluemix Local System and PureApplication System, provides the deployment engine and management console. If you want to use your own hardware rather than a pre-built system, PureApplication Software is also available as a stand-alone purchase. You will need to install PureApplication Software on your own VM that runs on a VMware VSphere Hypervisor. Then, you need to configure it to work with one or more existing hypervisors, including the same hypervisor that hosts the PureApplication Software itself.
PureApplication Software currently supports only Red Hat Enterprise Linux (RHEL) 5.x, RHEL 6.x (32-bit and 64-bit), Microsoft® Windows® 2008 R2 (64-bit), Windows 2012 (64-bit), and Windows 2012 R2 (64-bit). To use PureApplication Software to create your own cloud environment for proofs of concept and development work, see Build Your Own Cloud Sandbox.
IBM PureApplication Service on SoftLayer® is based on the same idea as PureApplication Software, but uses worldwide data centers from SoftLayer to provide an off-premises option. This service provides dedicated hardware that is configured as PureApplication Software on the IBM SoftLayer cloud. PureApplication Service is also based on the x86 architecture and VMware virtualization technology.
Patterns that are developed with one member of the Bluemix Local System and PureApplication family can be shared with other members with little or no change. For example, you might want to deploy an enterprise app in the cloud. In this case, you can deploy a pattern that is created with the Bluemix Local System (on-premises) onto a SoftLayer cloud environment (off-premises) by using the PureApplication Service on SoftLayer. Or, you might want to perform development and test in the cloud and then deploy the app in your private cloud data center. Similarly, you can deploy a pattern that is created with PureApplication Service on SoftLayer onto the Bluemix Local System, PureApplication System, or PureApplication Software that is running on your hardware.
Cloud service delivery models
Cloud offers three service delivery models: infrastructure as a service (IaaS), platform as a service (PaaS), and software as a service (SaaS). These models determine the levels of sharing and possible multi-tenancy that a cloud provider can offer its users. As the following figure illustrates, at each level in the stack, tenants share components that are part of that delivery model.
Infrastructure as a service
At the lowest layer is IaaS, where tenants share infrastructure resources, such as processors, network, storage, and the operating system. Tenants install their own middleware components and applications, which gives them more flexibility. However, it also makes configuration and maintenance more difficult, especially in organizations with dozens or hundreds of applications, each with their own environment or topology. IaaS provides users with shared computing capacity, network-accessible storage, and an OS. Everything else must be installed, configured, managed, and maintained separately.
Platform as a service
PaaS is a layer above IaaS and provides middleware components, databases, storage, connectivity, reliability, caching, monitoring, and routing. PaaS builds upon IaaS to deliver progressively more business value by simplifying at the platform level and saving significant time, effort, and resources. Tenants continue to use their individual applications, but can use PureApplication's shared middleware services, such as monitoring, security, and databases, and patterns of expertise for transaction-oriented web and database applications. The Bluemix Local System plays a key role in this space, providing a preconfigured, open platform for PaaS solutions.
Software as a service
With SaaS, tenants use and share everything that they might share in an IaaS and PaaS solution, plus an application. In this case, all tenants share the same application, but maintain their data isolated. With SaaS, it is easier to add new tenants because you simply select and customize a cloud application without worrying about building the middleware or installing the application. You have little left to do.
Cloud deployment models
As the following figure shows, cloud computing has four deployment models.
A public cloud is open to the general public. The cloud infrastructure exists on the premises of the cloud provider and can be owned, managed, and operated by one or more entities. One of the main reasons companies move to a public cloud is to replace their capital expenses (CAPEX) with operating expenses (OPEX).
A public cloud uses a "pay-as-you-go" pricing model. In this model, the consumer does not need to buy the necessary hardware to cover peak usage up front, nor worry about correctly forecasting capacity requirements. This pay-as-you-go pricing model, often referred to as utility computing, enables consumers to use compute resources as they would a utility service. They pay only for what they use and get the impression of unlimited capacity, available on demand.
In this deployment model, consumers do not normally care about where or on what hardware the processing is done. They trust the cloud provider will maintain the necessary infrastructure to run their applications and provide the requested service at their required service-level agreement (SLA).
A private cloud is deployed for the exclusive use of an organization; it is dedicated and isolated for that organization. The organization or a third party can own, manage, and host it, and its infrastructure can exist on-premises or off-premises. When a third party manages the cloud, it is called a managed private cloud. When the private cloud is hosted and operated off-premises, it is called a hosted private cloud. IBM SoftLayer, for example, hosts a public cloud, but also provides private cloud services where consumers can build, manage, and have total control of the virtual servers that they use.
Companies adopt private cloud solutions for the following reasons among others:
- Use existing hardware investments. Companies that already have a significant investment in hardware on-premises prefer to consolidate their IT resources. They can then use cloud technologies to provide automation, self-service, and better integrated management tools to reduce their total operating costs.
- Data security and regulatory compliance. Many clients have concerns over data security and issues of regulatory compliance and privacy with multiple client organizations sharing the same resources. Therefore, clients often start their cloud venture behind an enterprise firewall or in completely isolated environments.
- Resource contention. In public cloud environments, resources are shared among multiple customers. A company might prefer exclusive use of hardware, such as servers and load balancers, to handle specific workloads or to obtain higher availability of systems and applications at specific times.
What does an on-premises private cloud have to offer an organization that has a highly virtualized environment with scripts written to provision new applications? The answer is that a private cloud does not just make the provisioning faster and easier, but it also provides a way to offer cloud-based services to your internal organization.
With the Bluemix Local System, you get a dynamically scalable, highly standardized, self-service infrastructure, a workload catalog with ready-to-run workload patterns, approvals, metering, and integrated management through a single console. Bluemix Local System also gives you the ability to use a standard catalog of VMs or virtual resources that you can provision at any time and expand on demand to more quickly respond to changing business needs. Virtualization alone does not give you these advantages.
A hybrid cloud consists of two or more different cloud infrastructures that remain distinct but share technologies that enable porting of data and applications from one to the other. Hybrid cloud solutions provide interoperability of workloads and data that can be managed across multiple cloud environments. They include access to third-party resources and to a client partner network. The idea is to seamlessly link on-premises applications—whether home-grown, packaged, or running on a private cloud—with off-premises clouds. PureApplication excels in this area because you can create and deploy patterns on-premises with a Bluemix Local System or PureApplication Software. You can also deploy those patterns off-premises onto the SoftLayer infrastructure by using PureApplication Service on SoftLayer, or vice versa.
For many enterprises, hybrid and multi-cloud implementations are the end goal, because they offer the most savings and flexibility. The following scenarios might explain why:
- An organization might host its normal workload in a private cloud and use a public cloud to handle its peak traffic.
- An organization might use a public cloud to host an application and place the underlying database in a more secure private cloud.
- A company might use a private cloud to host some of its workload and a public cloud for specific uses, such as backup and archive.
- A team might decide to split the location of an application based on its lifecycle stage. For example, it might choose to do in-house development and then go live in a cloud environment. Or, the team might do development in a cloud and go live in an on-premises private cloud.
A community cloud is for the exclusive use of a community, which is a group of people from different organizations that share a common interest or mission. This type of cloud can be owned, managed, and hosted by one or more members of the community, a third party, or a combination of both. It can exist on-premises of one of the parties that is involved or off-premises for everyone. Vertical markets and academic institutions, in particular, can benefit from community clouds to address common concerns. For example, technology companies that work together on a new specification can use a community cloud to share resources, proofs of concept, and internal incubation projects.
Essential characteristics of a cloud environment
The National Institute of Standards and Technology (NIST), which was founded in 1901 to promote US innovation through measurement science, standards, and technologies, identifies five essential characteristics of any cloud environment:
- Broad network access. The capabilities of a cloud should be available over a broad network and accessible by standard devices, such as workstations, laptops, tablets, and mobile phones.
- On-demand self-service. The environment should
support a "do-it-yourself" model. In this model, consumers can
provision resources in an automated fashion through a web browser
or by using an application programming interface (API), without
requiring human interaction with the service
Bluemix Local System and PureApplication offer a user interface (UI) that provides workload and administration consoles for creating, deploying, and managing pattern-based cloud solutions. They also offer a REST API and a command-line interface (CLI) that enable service providers to create their own do-it-yourself interfaces for consumers.
- Resource pooling. The system should pool resources
so that multiple consumers can easily share them. Shared resource
pools enable the system to assign or reassign resources as needed
based on demand. Resource pooling is especially useful to support
multi-tenancy models where multiple organizations or tenants share
resources in a cloud environment.
Maximizing the use of hardware resources is also particularly important when multiple VMs share them. Resource pooling treats a collection of hardware resources—compute, memory, storage, and networking bandwidth—as a single pool of resources that is available on demand. This way, hypervisors and higher-level programs can dynamically assign and reassign resources based on demand and priority levels. Resource pooling is what enables multiple organizations or tenants to effectively share resources in a cloud environment.
- Rapid elasticity. The environment should be able
to automatically (or at least quickly) add or remove compute
resources based on workload demand, without interrupting the
The term workload generally refers to the processing demand that is placed on a computer resource at a particular time. Within Bluemix Local System and PureApplication, workload also refers to the deployed form of a virtual application (application-centric), virtual system (middleware-centric), or virtual appliance (machine-centric). Within the context of cloud, such phrases as "provisioning a workload" or "deploying a workload," refer to enabling that virtualized application with everything else that is needed to run it, including the VM, the operating system (OS), and supplemental files. When considering how well a specified server can handle a workload, the term refers to how well it can handle the compute, memory, disk, and networking resource demands of that deployed virtual system, virtual application, or virtual appliance.
Not all workloads are the same. The resources that are needed for an I/O-intensive workload, for example, are different from the resources that are needed for a compute-intensive or memory-intensive workload. Not all workloads require the same quality-of-service (QoS) levels either. Determining which workloads will run best under the different environments can be an effective way to reduce costs. Hybrid clouds and, in particular, Bluemix Local System and the PureApplication family of products play an important role in this area.
Capacity planning for particular workloads can be challenging. As the following figure shows, the usual issues are known. That is, not planning for enough capacity to meet workload demands is unwise and will lead to downtime. Conversely, overestimating capacity requirements will result in one or more servers that are underutilized or sitting idle. Even correctly allocating capacity for peak usage is not enough because workload demands fluctuate, and capacity is wasted when the system does not run at peak level. The end of a test cycle, for example, might be followed by significantly lower utilization of the hardware. Even with the best capacity planning in place, in some cases, the workload demand is unpredictable. The ideal situation is to allocate only the capacity that is required at any particular time. This concept is called elasticity, which is an important characteristic of any cloud environment.
- Measured service. A cloud environment must be able to meter and rate the resources that are being used—and by whom—to better manage workloads and optimize their execution. It must also be able to provide a transparent view to the consumer of resource utilization.
It’s all about virtual patterns
At the heart of Bluemix Local System and PureApplication is the "pattern engine." The pattern engine is found in all PureApplication product family members and in other IBM cloud offerings, such as IBM Cloud Orchestrator.
With the pattern engine, you can use the following deployment methods:
- Virtual appliances
- Virtual system patterns
- Classic virtual system patterns
- Virtual application patterns
A virtual image or virtual appliance is a pre-configured VM that you can use or customize. Virtual appliances are hypervisor editions of software and represent the basic parts that you use in a Bluemix Local System to build more complex topologies. By adding new virtual images to the catalog, you can deploy multiple instances of that appliance from a single virtual appliance template.
Virtual appliances are portable, self-contained configurations of a software stack. They are also called virtual images and are usually built to host a single business application. The industry standard for the format of virtual appliances is the Open Virtualization Format (OVF), published by the Distributed Management Task Force (DMTF). Member companies, such as IBM, VMware, Citrix, Microsoft, and Oracle®, all support OVF in their products.
As the following figure shows, the OVF definition of a virtual appliance can support a single VM with a single application or multiple applications in a single-tier architecture. However, OVF also supports having multiple VMs that are packaged as a single virtual appliance.
Bluemix Local System and PureApplication do not support this approach. Instead, they provide a more flexible, reusable solution. You can deploy multiple VMs or Docker containers as part of a pattern, and then use links and script packages to orchestrate the interaction between them. This approach enables the virtual images and containers, in addition to the script packages, to be independently reused in other patterns.
Virtual appliances offer a new way to create, distribute, and deploy software. They have an abstract layer above the hypervisor and can package the software and distribute it as a preconfigured and "ready-to-run" unit. Therefore, they reduce the provisioning and deployment time of applications, which means an increase in time to value. They also improve the quality of the final deliverable. A completely configured application that does not require installation and configuration is less prone to errors.
Virtual system patterns
You can use virtual system patterns to graphically describe a middleware topology to be built and deployed onto the cloud. By using virtual images or parts from the catalog, in addition to optional script packages and add-ons, you can create, extend, and reuse middleware-based topologies. Virtual system patterns give you control over the installation, configuration, and integration of all the components that are necessary for your pattern to work.
Classic virtual system patterns
Classic virtual system patterns are an earlier version of virtual system patterns. As with virtual system patterns, classic virtual system patterns enable you to graphically create a logical view of a middleware topology, but there is a difference. Classic virtual system patterns are mainly provided for compatibility with an earlier versions. For example, they do not allow you to include policies for scaling, security, placement, and fixes, which was only a feature in virtual application patterns. Fortunately, by using PureApplication, you can promote a classic virtual system pattern to a virtual system pattern.
Virtual application patterns
A virtual application pattern, also called a workload pattern, is an application-centric approach for deploying applications to the cloud. With virtual application patterns, you do not need to worry about the topology that is required to run your application. Instead, you can specify an application, such as a .ear file, and a set of policies that correspond to the SLA that you want to achieve. Bluemix Local System and PureApplication then transform that input into an installed, configured, and integrated middleware application environment. The system also automatically monitors application workload demand, adjusts resource allocation, and fine-tunes prioritization to meet your defined policies. Virtual application patterns address specific solutions, incorporating years of expertise and best practices.
Choosing the right type of pattern
Using virtual application patterns involves the least amount of work and, in one sense, represents the ideal situation. You can create an application, and then Bluemix Local System and PureApplication can handle the infrastructure that is required to meet a specified quality of service. This method promises the lowest total cost of ownership and the shortest time to value. However, not all configurations fit easily into an available virtual application pattern type. At times, you might need more granular control.
By using virtual system patterns and classic virtual system patterns, you can specify the exact topology that you need to support your application while still benefiting from the reusability of patterns. With virtual system patterns, you can also take advantage of such features as auto-scaling.
Unless you need to control the topology and manage the environment through administrative consoles, try to use the optimization and convenience of virtual application patterns.
Understanding hypervisors, virtual machines, and containers
Using virtualization to consolidate resources, reduce space, and save on energy costs is one of the key elements that make cloud computing work. IBM first developed virtualization in the 1960s to multiplex its expensive mainframe computers. In 1967, the first fully virtualized machine, the IBM S/360-67, appeared in the market, and by 1972, VMs had become a standard feature of all S/370 mainframes.
Hypervisors provide platform virtualization, which means they logically divide a physical machine into multiple VMs or guests. A hypervisor, also called a virtual machine manager (VMM), controls and presents the physical resources of a machine as virtual resources to the VMs. Hypervisors enable other software (usually operating systems) to run concurrently, as though they had full access to the real machine.
The following figure shows two types of hypervisors: Type 1, which run directly on the physical hardware, and Type 2, which require a host operating system to run. Examples of Type 1 hypervisors include: IBM z/VM®, IBM PowerVM®, and VMware VSphere/ESX/ESXi Server for Windows. Other Type 1 hypervisors include Citrix Xen and Microsoft Hyper-V®. Because they run on top of the hardware itself, Type 1 hypervisors are also called native or bare-metal hypervisors.
Examples of Type 2 hypervisors include VMware Workstation, VMware Server, kernel-based virtual machine (KVM), and Oracle VM VirtualBox. Type 2 hypervisors are also known as hosted hypervisors.
Other terms that you should be familiar with
You should also be familiar with the following essential terms when you consider Bluemix Local System or PureApplication:
- Compute nodes. Hardware units that contain processors and memory, in addition to networking and storage interfaces.
- IP groups. Sets of IP addresses that can be dynamically assigned to VMs at deployment time.
- Hypervisors. Configured connections to platform virtualization servers (to the hypervisors as just explained) that can virtualize the compute nodes and provision and run VMs.
- Cloud groups. Collections of configured
hypervisors of a certain type (for example, VMware
VSphere/ESX/ESXi Server or IBM PowerVM®). Each cloud group
can contain only hypervisors of the same type, meaning from a
single vendor. A cloud group can contain one or more hypervisors,
but a hypervisor can belong to only one cloud group. Cloud groups
help organize compute nodes and IP groups.
Every cloud group provides two virtual local area networks (VLANs):
- Cloud group management VLAN, which is used by the PureApplication System to manage the VMs
- Application data VLAN, which is used to provide network connectivity to the applications that are running in the VM
- Environment profiles. Configured deployment targets that specify environment-specific policies for VM placement, naming conventions, and resource constraints.
Bluemix Local System and PureApplication use collections of hypervisors that are arranged into cloud groups to help provision VMs and provide the virtualization capabilities of the cloud. In the pattern builder, each part that is dropped onto the canvas generally corresponds to a VM with its own operating system and usually one or more middleware components.
To learn more about what's inside the IBM Bluemix Local System, read Experience the power of private cloud: IBM Bluemix Local System.
Version 2.6.24 of the Linux kernel introduced support for Linux Containers (LXC). The Linux Containers are a lightweight alternative to full hardware virtualization. Instead of the platform virtualization that hypervisors provide, containers provide OS-level virtualization. They enable a single machine or VM to operate multiple Linux instances (Linux containers). Each one is isolated in its own operating environment within the OS. All containers run under the same kernel, but each one maintains its own process and network space.
The two main features behind Linux Containers are namespaces and control groups (cgroups). Namespaces isolate Linux resources at the process level, ensuring that a container detects only its own environment, while cgroups help control, account for, and isolate the resources that a collection of processes can use.
Docker is an open source container-based technology that enables developers to build, ship, and run applications unchanged on any infrastructure, whether on a laptop or a VM in a cloud. Docker containers build upon the LXC low-level functions to yield a much smaller footprint and greater portability than VMs. Launching new containers is also much faster than launching new VMs.
In short, Docker replaces sandboxing with containerization. An application that is deployed on a VM comes bundled with all the necessary dependencies, such as its binary files, libraries, and the guest OS. A Docker container requires only the application and its dependencies, and a lightweight runtime and packaging tool called the Docker Engine. As with LXC, all Docker containers share host OS and kernel. Docker also consists of a public registry for sharing applications, called the Docker Hub, which has over 13,000 (and counting) containers that are ready for reuse or to be used as base images for new containers.
Bluemix Local System on Intel and PureApplication System on POWER8 support using Docker containers in patterns and in PureApplication Software. If you have the Docker Pattern type installed and enabled in the system, you can drop Docker containers from the pattern builder as software components onto the canvas of your virtual system patterns. You can reference Docker containers from the Docker Hub or from a private Docker registry that is already included in Bluemix Local System or PureApplication.
You can create and deploy single-container and multi-container Docker applications, and perform multi-node orchestration of Docker containers. Within the pattern builder, you can connect containers across nodes by linking them.
Chef is an automation platform from Opscode that you can use to programmatically describe how to configure and manage your infrastructure. Chef treats your infrastructure as code, which means you can version and test it, just like any application.
Each machine in a Chef system plays a specific role:
- Chef node. Any system that Chef manages. It can sit on a physical server, a VM, or a container. All nodes run the Chef client software.
- Chef server. The centralized store for configuration information. It is a large repository that contains all the configuration files that clients can use. The server also organizes the data so that clients can pull it easily.
- Chef workstation. A computer that is used to upload configuration changes to the Chef server. Configuration files that are uploaded to the Chef server are made available to be deployed to any node.
Bluemix Local System and the PureApplication family support Chef. This integration with Chef enables new possibilities, such as deploying pattern instances with nodes that can automatically update themselves based on recipes that are pushed to the Chef server. Also, the open Chef community has thousands of recipes that you can reuse and inject into PureApplication patterns, or you can create your own recipes and upload them to a Chef server from within PureApplication.
The following figure illustrates how PureApplication supports Chef deployments.
The numbers in the following list correspond to the numbers in the previous figure:
- Within PureApplication, you can connect to a Chef server through an external shared service. You can add Chef clients as software components onto the PureApplication nodes of a virtual system pattern.
- Chef clients can be nodes that are VMs or Docker containers within a VM. Chef clients that are deployed by using PureApplication also use the shared service to communicate with the Chef server.
- The Chef server contains cookbooks and recipes that describe how to define, provision, and configure application resources in Chef clients. Chef recipes are the configuration tasks or instructions that you write to install and configure resources on a node. A cookbook is a collection of related recipes.
- Chef clients periodically poll the Chef server for updates to the cookbooks or settings. If updates are available, the client pulls the content from the server. By using PureApplication, you can specify how often clients should poll the server for updates.
- The Chef server sends the latest versions of the cookbooks and recipes to requesting clients. Each Chef client updates itself with the configuration information it receives from the server.
- A Chef workstation is any external machine, such as your laptop, that is configured as a local Chef repository and has the Knife tool installed and configured. You can use Knife, a command-line tool, to upload cookbooks and recipes to the Chef server. You create and edit configurations and definitions on a workstation and commit them to version control before you send them to the server. By using PureApplication, you can directly add recipes to run at installation time.
- The Knife tool is also regularly used to communicate with the nodes by using Secure Shell (SSH).
OpenStack is an open source cloud operating system that provides a set of services for controlling cloud resources in a consistent manner across the data center. OpenStack provides a common dashboard and a set of APIs (REST services) to enable portability across multiple cloud platforms.
OpenStack includes the following primary services:
- Horizon: Dashboard
- Heat: Orchestration
- Nova: Compute
- Cinder: Block storage
- Trove: Database
- KeyStone: Identity services
- Neutron: Network
- Swift: Object storage
- Glance: Image
As part of its overall open strategy, IBM PureApplication has been progressively increasing its support for OpenStack. Initially available as a technology preview, Bluemix Local System and PureApplication now support Open Patterns, which are based on OpenStack Heat. A Heat Orchestration Template (HOT) is a text file that is readable and writable by humans. You can use it to describe how software should be installed and deployed and what the relationship between resources should be (such as the order in which to create the required infrastructure). You can also include a scaling group as a resource in a HOT template. Heat manages the entire lifecycle of an application. With Open Patterns, existing PureApplication patterns still work the same. However, they have the added benefit of being based on open source technology (HOT) and, therefore, are portable across vendor solutions that support OpenStack Heat orchestration.
IBM PureApplication and Bluemix
IBM Bluemix is an implementation of the IBM Open Cloud Architecture. Based on Cloud Foundry, another open source technology, Bluemix abstracts and hides most of the complexities that are associated with hosting and managing cloud-based applications. With Bluemix, an application developer can focus on developing applications without having to manage the required infrastructure.
Bluemix supports several programming languages and services, in addition to integrated DevOps to build, run, deploy, and manage applications on the cloud. Bluemix also provides pre-built mobile-backend-as-a-service (MBaaS) capabilities and middleware services that applications can readily use. The goal is to simplify the delivery of an application by providing services that are ready for immediate use and hosting capabilities to enable Internet scale development.
Bluemix Secure Gateway
You can connect your data centers to IBM Bluemix Public by using the Bluemix Secure Gateway, which is a secure tunnel from Bluemix Public to your data center. The Bluemix Secure Gateway enables you, for example, to connect Bluemix to an on-premises DB2 or MySQL database running on Bluemix Local System, PureApplication, or other infrastructure.
Bluemix deployment models
Bluemix has three deployment models:
- Bluemix Public. The cloud platform that is hosted in IBM SoftLayer. It provides a PaaS layer about SoftLayer, with both services that are ready to use and hosting capabilities that empower developers to quickly create, deploy, and manage applications in the cloud. Some of the Bluemix services categories that are available include Data & Analytics, Watson, DevOps, Application Services, APIs, Internet of Things, and Mobile.
- Bluemix Dedicated. The power and simplicity of Bluemix Public, but in a dedicated environment within a SoftLayer data center. As the name implies, Dedicated means that it is a single-tenant offering within SoftLayer that is dedicated to the client. Think: our center, your cloud. Bluemix Dedicated is a hosted-managed cloud service within an IBM SoftLayer data center that is securely connected to the client environment.
- Bluemix Local. A private deployment of the Bluemix
platform in your data center. You can use Bluemix Local, for
example, to keep certain workloads on-premises to comply with
security policies or with regulatory compliance and data privacy
laws. You can also use it to help minimize network latency.
Because Bluemix Local sits in your data center, its close
proximity to existing systems helps improve the performance of
cloud-native and hybrid applications.
Bluemix Local is delivered as a service. IBM installs Bluemix Local on your private infrastructure and then, working in close collaboration with your IT team, remotely manages and monitors the platform by using IBM Relay technology. Relay is a secure Continuous Integration and Continuous Delivery (CI/CD) remote management pipeline. By using Relay, the IBM Bluemix Operations team can connect to your Bluemix Local environment and keep the platform working correctly and the services and security patches current.
IBM tests and validates all platform updates in testing and staging environments in both public and dedicated Bluemix before it makes the updates available to Bluemix Local environments. Your team then uses the administrative console in your Bluemix Local environment to apply the updates.
With Bluemix Local, you can protect your most sensitive workloads behind a company firewall, while keeping them securely connected and in sync with Bluemix Public. You can create rules and policies to control access to its Bluemix private catalog, effectively creating a private, syndicated catalog, while including services that are syndicated from and available for use from Bluemix Public.
Bluemix Local System W3500 and W3550
IBM's latest cloud platform, Bluemix Local System, is considered the evolution of the IBM PureApplication System offering based on Intel. It comes pre-integrated with Bluemix Software and PureApplication Software. Through activation, it extends the capabilities of their predecessors by enabling you to concurrently run cloud-enabled applications (PureApplication) and cloud-native applications (Bluemix) on a single on-premises system.
The Bluemix Local System is available in two models:
- IBM Bluemix Local System W3500 “iSCSI”: Optimizes price/performance and is well suited to workloads, such as WebSphere Application Server, WebSphere Commerce, and WebSphere Portal.
- IBM Bluemix Local System W3550 “Flash”: Is targeted for workloads, such as IBM MQ and Analytics. This model includes all flash drives, Fibre Channel internal networking, and more memory for performance-sensitive applications.
Benefits of the IBM Bluemix Local System
Many of the benefits of Bluemix Local System are based on the value of the PureApplication platform:
- Factory-assembled and pre-provisioned to host a Bluemix Local instance, so that you can quickly be up and running, even within a day, in most cases
- Pre-installed PureApplication software so that you can simplify and automate deployment of full stack application environments and easily move environments across your cloud landscape with just a few clicks
- With both Bluemix Local and PureApplication, support for interoperability of workloads (cloud-enabled and cloud-native) within a single platform
- Built-in monitoring for all of the virtual resources and their underlying hardware, in addition to cognitive health monitoring
- High availability with redundant hardware and automatic failover capabilities
- The ability to scale by adding more compute nodes to the system
- A single IBM support contact for help with all components in the system
Support for multi-speed architectures
Multi-speed or two-speed (bimodal) architectures refers to the ability of a company to have a fast track that allows some projects to be implemented quickly, while maintaining and enhancing traditional infrastructure and services. Mode 1 is traditional IT (such as conventional, stable, and waterfall), while Mode 2 is agile IT (such as innovative, agile, and iterative). Such tools as UrbanCode Deploy (UCD) support multi-speed architectures, which is important if you have conventional systems that need to co-exist in a more agile world. DevOps and tools, such as UCD and Bluemix DevOps Services, play a key role here.
Bluemix Local System is a great fit for multi-speed architectures because you can cloud-enable your existing systems to reduce operational costs, while focusing on speed and agility when delivering new applications that are based on Bluemix. As mentioned earlier, Bluemix Local System also supports hybrid solutions that require interoperability of workloads (cloud-enabled and cloud-native) within a private cloud.
PureApplication Software and PureApplication Software Suite
Depending on your needs, Bluemix Local System will optionally require entitlement to the PureApplication Software (at V2.2.2 at the time of this writing) if you want to run PureApplication patterns (including Open Patterns). Alternatively, it will require entitlement to the PureApplication Software Suite, which bundles the PureApplication Software with WebSphere Application Server, and DB2 database.
Besides the Bluemix Local System, PureApplication Software V2.2.2 supports the PureApplication Systems W3700, W2700, W2500, W1700, and W1500 models. Some of its features include:
- Support for multi-cloud deployments so that you can enforce segregation of an application's tiers (such as web and database) and then use a single pattern to deploy the tiers to different cloud groups
- FedRAMP and FISMA readiness with package delivery for standardized government security assessment and authorization, and protection of government information
- Support for the new VMware Remote Console (VMRC) stand-alone application to connect to a VM console
- A diagnostic console so that you can diagnose the status of hardware and components when the PureApplication console is not available
- Entitlements to IBM Application Performance Management (APM), which detects and addresses performance issues in your applications and infrastructure
- Support for VMware 6 and the latest IBM Power Virtualization Center (PowerVC), Hardware Management Console (HMC), and Virtual I/O Server (VIOS)
- Snapshot enhancements that consolidate data stores so that, if space is not available for a snapshot, the system automatically creates a new data store and migrates your deployment to that data store before taking the snapshot
By reading this article, you now have an overview of the cloud computing options that are available, and why IBM Bluemix Local System and PureApplication matter so much in today's cloud world. Whether the cloud you want is private, public, or hybrid, the powerful IBM Bluemix Local System and PureApplication solution can be your enabler of choice.
The author thanks the following IBMers for their help with this article: Lauren S. Frazier, Larry Heathcote, Nita Maheswaren, Angela F. Reese, and Bobby Woolf.
- Bluemix essentials
- Bluemix articles and tutorials in developerWorks
- Bluemix Developers Community
- Connect to Cloud
- Connecting to the cloud, Part 1: Leverage the cloud in applications
- Tutorial series: Navigating the IBM Cloud
- IBM developerWorks PureSystems
- PureApplication articles and tutorials in the developerWorks Middleware hub
- developerWorks Premium: Tools, services, training, and networking for the cloud