Models in IBM pureapplication System adopt Best practices

Brief introduction

Over the past few years, we have witnessed the beginning of a real change in the way middleware operations are implemented. The first is the release of the IBM WebSphere Cloudburst Appliance version, followed by a later version of IBM workload Deployer and IBM Pureapplication System, introducing a model-based deployment approach that Some have helped customers make fundamental changes in the way IBM middleware is planned, deployed, and managed. We have seen that this approach has changed the way the system operates and has had a significant impact on the relationship between development and operations in the company that adopted it. These model-based approaches, combined with the comprehensive system integration provided in Pureapplication system, have radically changed the way it organizations operate with them.

However, we have also found that in order to achieve the full benefits of these changes, these companies also need to adopt a set of organized, operational best practices to maximize the potential of pureapplication System. This article documented some of the best practices and provides evidence that you can use pureapplication System to have a significant positive impact on organizational efficiency and TCO.

Before we explain these best practices, we need to briefly discuss the asset types that exist in Pureapplication System, and introduce a taxonomy pattern to help you understand the different management technologies we recommend for these assets, enabling you to implement the Pureapplication The maximum benefit that System obtains.

Asset governance in the Pureapplication System

On a very general level, there are two types of assets in the Pureapplication System, and for the purposes of this article we refer to them as shared assets and transient assets.

Shared assets are long-lived resources that are used by multiple teams or individuals. These assets include physical cloud assets (ITE hardware, storage, and network switches), as well as virtual cloud assets (environment profiles, cloud groups, IT groups). This category also contains software assets, such as mirroring and script packages, and it is important to include virtual system patterns. We classify virtual system patterns as shared assets because they should be built in a way that maximizes the potential for reuse. This is directly related to the organizational structure that is best suited to creating and managing the lifecycle of these assets.

If the shared asset is a long-standing resource, the transient asset is the resource that is relatively short in time. Transient assets include virtual system mode instances and volume allocations. Another important transient asset type is the virtual application pattern. The generic virtual application pattern (and the specific WEB application pattern) contains the specific deployable resources that are included in the build pattern. In these "cloud-centric" application types, topologies are transient assets, and the actual topology may change at run time based on policies that are executed, such as scalability policies. The definition of a pattern is also a transient asset, because everything you specify in virtual application mode is application-specific. This includes the resources that are needed (application servers, databases, and so on), as well as policies that describe how these resources should be used. In this case, the EAR file or the DDL is another application-specific asset that has the same relative lifetime as all other aspects of this particular application.

Each asset in the Pureapplication System, whether shared or transient, will have its own lifecycle and your specific monitoring point for that lifecycle. To maximize the effectiveness of pureapplication System, IT organizations need to consider setting up an organization to handle the following general asset management aspects:

Maintain a directory or list of available assets.

Set appropriate policies around the management of the asset lifecycle.

Track the individual lifecycle of assets and transfer them as appropriate.

We will not give you a complete list of the types of governance policies you need to develop, and here is a representative list of some of the most common scenarios.

Some common shared resource policies include:

How long can you keep the virtual system mode version available?

How long do you support previous or deprecated schema versions?

What is the naming convention for the virtual system version?

Some of the more common transient resource strategies include:

The amount of each resource (storage, CPU, network) that you allow to use for each pattern instance

If not, how long do you keep the pattern sample (virtual system and virtual application) running?

If it is not currently in use, how long do you keep the mode instance available?

This list becomes longer when you consider policies that revolve around the management of physical and virtual cloud assets (not just schemas). For example, if a customer has more than one pureapplication System, schema directory management across two of instances becomes a missing and important consideration. What patterns are defined in each pureapplication system rack's software directory, and which schemas are deployed to each pureapplication system rack, need to be combined with factors to determine, for example, the need to support high availability and disaster recovery configurations for specific patterns , the use of each pattern (for example, a pattern with a batch behavior similar to MDM has a high utilization rate only at a certain time of the day), and the need to balance development requirements (such as load testing) with production requirements. In general, these racks can be used for both production and development/testing, as long as appropriate partitions are set up using the cloud groups and environment profiles used for isolation.

Best practices

This section lists the major best practices that we consider useful for the effective adoption of pureapplication System. We first discuss who created the assets to execute the policy on, and what automation technology is needed to execute the described asset strategy.