The N1 Grid software delivers a flexible provisioning capability that can provision simple individual service components (for example, a web server or EJB) or a larger collection of service components that comprise a complete business service (for example, an entire three-tier application). Combining the automated provisioning of services through repeatable, flexible frameworks with this level of flexibility opens up completely new opportunities for businesses. Although provisioning business applications is a relatively simple process, manual provisioning is time consuming and error prone. The issues that arise are usually caused by:
Even if you do a good job of the initial provisioning, changes occur over time. For example:
Consider the typical data center in which a favorite application is used all of the time. The IT teams know it well and install it a lot. And still, how many times after the installation has a configuration error taken down that service or has that service inexplicably ended up in an unexpected state that is different than the state in which it was initially installed?
The N1 Grid architecture helps you smooth out your application design and provisioning throughout the life cycle and throughout the stack. The N1 Grid architecture does this by providing the tools and products that support the provisioning and operations associated with a service. No longer is there testing, manipulation, and rollback on one targeted portion of the stack without visibility to the rest of the stack or service. As with virtualization, there are options to consider for each part of the stack and for the stack as a whole.
To illustrate these provisioning examples, consider the following example of a classic three-tier architecture. Refactoring the layers of the SunTone AM cube to suit the three-tier architecture, TABLE 4-4 depicts the provisionable entities for each layer.
In this typical three-tier architecture pattern, each tier is typically hosted in a separate set of servers or containers. The virtual layer, if present, provides an element of separation between the operating system layer and application. The layers listed denote levels of abstraction to deliver that tier's functionality:
In this typical Internet architecture pattern, each tier is typically hosted in a separate set of servers or platforms. The layers listed for each tier denote levels of abstraction to deliver that tier's functionality.
Even in this simplified model, there are many provisioning options for each tier:
Tiers and layers provide the means to decompose the provisioning space and to choose the appropriate blends of people, processes, and technology for each deployable entity. Using the previously described example tiers and layers, Tables 4-5, 4-6, and 4-7 present possible provisioning scenarios. The shaded areas represent areas that can be addressed with N1 Grid software.
The options are presented as illustrative; there are certainly many other possibilities.
Three options are presented for the presentation tier:
Three options are also presented for the business tier:
There are two options presented for the database tier:
To be able to automate these provisioning activities, you must understand the individual steps in your current manual provisioning processes. After these steps have been identified, the N1 Grid software is ready to automate and perform many of these common provisioning tasks. Understanding the dependencies and operational activities associated with the entity to be deployed can be captured in use cases, allowing the information needed to be easily identified and extracted for use.
Dependencies and Use Cases
You must check for a good match between the service component about to be deployed and the service container that has been selected to host the service component. The N1 Grid software simplifies this activity by allowing dependency checking to be included as part of the provisioning process. Provisioning activities should be recorded in terms of base-supported use cases, with additional dependency checks during the installation or removal of a resource. These manual use cases can then be expressed in N1 Grid provisioning workflows in preparation for testing the now mobile, newly automated service deployment capabilities.
Issues to protect against include items like installing web servers on a server or in an N1 Grid Container that is already running a web server, if doing so would cause tuning and port conflicts. Other dependency conflict examples include mismatches in licensing cost models where small applications are run as one of many items on a large, multi-CPU server or an attempt to place an application that cannot be clustered into a clustered container environment. Many of the dependencies introduced in the virtualization section in this chapter also apply here. The dependencies of the N1 Grid software provisioning capability act as counterparts to the dependencies of the virtualized N1 Grid Containers, into which the service components can be provisioned.
Resource management was introduced during the discussion about N1 Grid Containers. Resource managers control the assignment and sharing of resources when multiple service consumers have been deployed into a service container. Typically, a minimum threshold is set for each running process so that a baseline performance level can be guaranteed. In the absence of other loads, running processes can use all of the available CPU, memory, and network resources, but usage is ramped down to the guaranteed level as other loads begin to appear.
Consider adding the assignment of resource manager shares (that is, the fraction of operating system CPU, memory, or I/O allocated) as a part of the provisioning process to provide the appropriate capacity for the entity being deployed. This activity prepares the entity for a mobile environment as multiple applications with unknown workload needs come in and move out of the server on which they were originally provisioned. Having a guaranteed percentage of the CPU, memory, and network resources assists the original deployable entity to maintain a minimum level of service delivery and performance. The naming conventions established can serve as a basis to distinguish the identity of the resource groups that are required for a service.
Security and Trust Models
N1 Grid software is not a shortcut to bypass security. The N1 Grid software does not change the services that run, how they are configured, the protocols they use, or the way in which those configured services might be vulnerable to some particular exploit. It still requires every bit of the security considerations you currently include (or should be including) when you architect, implement, and manage business services. In fact, by capturing golden images and leveraging automation to ensure what is placed into production is an exact copy of what was tested in development, the N1 Grid solution actually helps your security efforts. However, these mobile and flexible stack entities now have several possible roles they can play in N1 Grid solution scenarios and use cases (for instance, provider, consumer, or interested party), so the roles, responsibilities, and policies of the people who run them must be rethought and refreshed. While the goal of this book is not to cover all elements of N1 Grid system security, it is obvious that elements must be added to your enterprise security policy that boost the confidentiality, integrity, and availability of assets before, during and after application provisioning activities. Your defense-in-depth additions should consider these aspects as the allowed procedures check or direct which components can live on the particular resources that might host them, for instance:
Concrete examples of some of these confidentiality, integrity, and availability notions include:
The next section provides guidelines to help you prepare to automate the provisioning of application stacks and to focus on the individual layers, as well as the stack as a whole.