- Challenges of Software Integration
- Integrated Software Stacks
- Stacks and System Architectures
- Requirements of Software Integration Architectures
- Software Integration Architectures
- Software Stack Management and Deployment Frameworks
- About the Author
- Ordering Sun Documents
- Accessing Sun Documentation Online
Stacks and System Architectures
For most real-world data centers, a single software stack is insufficient to implement an architecture. A solution or system architecture is often implemented from several interrelated stacks and from meta information that exists outside the stack itself.
The following subsections describe the meta information that is often necessary to implement a system architecture using integrated software stacks, and provide recommendations for their use.
Providing a System Architecture
A system architecture must specify metainformation about the software stacks, such as the relationships between stacks or interdependencies between certain stacks. A system architecture must also specify information outside the software stacks, such as the hardware requirements the software stacks must be bound to, and the specification and configuration of components to meet infrastructure requirements.
A complete system architecture should furnish a design and functional documentation that specifies:
Physicals (cabling and hardware component layout)
Plumbing and infrastructure requirements including router, switch, and hub configurations
Relationships and interdependencies between modules or tiers of the architecture
Shared disk configuration requirements
Application data needs or requirements
Load generation and performance metrics
Stack recipes for the raft of stacks
To deploy or implement a complete system architecture, you must have access to the design, the functional specification, and the raft of stacks that implement the tiers of the architecture.
Testing and Validating Stacks and Slabs
When creating or developing a stack, it is important to keep in mind the relationships and any interdependencies between slabs. These interdependencies typically center around software version requirements or restrictions between slabs. These issues are typically well known, such as Oracle 9i requiring the Solaris 8 Operating Environment, or a later version. However, as software releases add features or as software patches are released, versioning interdependencies might become very subtle.
A software integration architecture must implement or provide for validating all monolithic stacks as well as testing and validating slab changes made to piecemeal stacks. Furthermore, this requires the changes to the integrated stack, as well as any changes to the integration architecture, be tracked, managed, and audited.
We strongly recommend that you implement a change control procedure for stacks. Additionally, stacks must be tested and validated after changing any of the slabs or recreating a monolithic stack, and before deploying the modified stack back into production.
Requirements and Recommendations for Using Integrated Stacks
By definition, integrated software stacks provide consistency and ease of maintenance while being rapidly deployable, reproducible, and readily understandable. When designing software stacks, design for ease of maintenance and scalability.
All of these attributes provide the benefits of standardization, reusability, modularity, minimization of the risks associated with software upgrades, and reduction of TCO. These attributes and benefits also make software ideally suited for use in business continuity planning (BCP) and disaster recovery operations.
Due to their inherent flexibility and modularity, piecemeal stacks are typically most useful during the implementation and test phases of an architecture, or the implementation of that architecture.
Monolithic stacks are typically used when an architecture or service domain is promoted to production. Monolithic stacks are also very useful for disaster recovery or BCP. Monolithic stacks can be used to rapidly recover, or, to reinstall a service domain or an entire architecture at a remote disaster recovery site.