The N1 Grid solution is not a replacement for doing good architectural design work. The N1 Grid is best realized by using architecture as the link between business decisions and the physical environment on which people, process, and technology decisions are carried out. Because of architecture's importance, this section provides an overview of Sun's architectural principles and building blocks.
The SunToneSM Architecture Methodology (SunTone AM) frameworks provide the means to create a mobile, service-centric IT environment:
The SunTone AM builds on the ideas that make up the Unified Process. Like the Unified Process, the SunTone AM is use case focused, architecture-centric, iterative, and incremental. The SunTone AM significantly extends the Unified Process through the incorporation of two additional fundamental concepts: it is systemic qualities driven, and patterns based.
For a complete discussion of the methodology, refer to:
The SunTone AM cube (FIGURE 4-2) decomposes service functionality along three axes:
Figure 4-2. SunTone AM Cube Functionality Axes
As the name implies, the functionality axes are often drawn together in a cube.
Tiers enable you to break up an analysis or a solution into discrete structures along some form of distinctive boundary. The distinctiveness is defined in relation to the other tiers in its enclosing system (for example, the other tiers in an "N-tier" system). There are at least three types of tiers. Each tier delivers a different distribution strategy to consider:
The design is simplified when logical tiers map closely to, or even exactly to, conceptual tiers, but this correspondence can migrate over time due to business or technology choices (for example, updates move some part of the business logic tier out to presentation or client tiers, or persistence gets moved into the business tier).
Physical tiers can map to individual logical tiers, or several logical tiers can run on the same physical tier if similar control, security, or scalability characteristics need to be delivered. A physical tier enables the support for multiple underlying configurations or a future evolution of the underlying hardware topology without significant code changes or service interruption.
A typical example of a physical tier is a set of servers delivering HTTP connections behind a hardware load balancer. The individual servers can be different in size or platform or even be removed, replaced, or updated during HTTP service delivery. Working in combination behind the load balancer, they supply the HTTP service at the advertised HTTP access point. The abstraction of the service provided from the platform on which it runs is an important element of N1 Grid solution problem analysis and solution creation.
Layers constitute another discrete analysis and distribution strategy axis. The type and number of layers is determined by the architectural style and level of desired granularity or control. Typical layers can be defined as follows:
TABLE 4-2 depicts some example layers for several common tier types.
Note that each layer represents a particular type of provider-consumer relationship between a deployable entity and its container. Using the business tier example, some of the relationships to explore are:
The virtualization, provisioning, and control of network-centric providers and consumers is one of the central capabilities delivered by the N1 Grid system. Think about the virtualized provider-consumer relationships in your data center as you encounter additional examples throughout this book. You should also think about the benefits you will gain from virtualizing your providers and containers and automating the provisioning of your consumers and services.
Systemic qualities are delineated on the final axis of the cube. As mentioned, systemic qualities are used to discuss and collect the current and future goals of the N1 Grid system as it fits into the business and operational environment. Although it is useful to work with individual qualities in an architecture, the qualities are often grouped to assist explaining their definition or source. FIGURE 4-2 reflects one such grouping (that is, user, service, system and strategic qualities):
This list of qualities is often described as the "ilities." The groups of qualities discussed are an illustrative list. They are not intended to be complete indeed, how many and which qualities to incorporate into a network computing problem analysis and system design is rightfully left to the architect as a function of the problem space complexity, solution history, and architectural methodology.
Note that the combination of many smaller cubes (at the intersection of each point along the three axes that form the larger SunTone AM cube) invoke interesting architectural questions. The generic form of the questions is: "How will your design address the ility for the layer in the tier?" Three specific examples are:
The sum total of the individual questions creates a basis for the definition of the problem space, the architectural activities to decompose that space, and the design and operational efforts to deliver the required solutions.
Additional SunTone AM Principles
Although the SunTone AM cube describes the runtime stack in a very useful way, other aspects of the methodology address the business and operations elements that complement the functional service representation of IT services in the cube.
Use Case Focused
Use cases are functional scenarios that describe the complete flow of an operation from the perspective of an actor. Actors are entities that are external to the system, typically users or other systems. In use-case-driven design and development, every attempt is made to prioritize design and development around the realization of complete, end-to-end use cases. The advantage of this approach is that it keeps the project team focused around continuously delivering functionality directly related to the end product being developed. Functional use cases illuminate certain working elements of the system: users can log on and view web content, the business tier successfully integrates information from several sources, or the database responds to a certain number of simultaneous queries. Operational use cases capture activities that support the system in use: people, processes, and tools are in place to support error condition collection and display, problem management capability is functioning, or service level agreement (SLA) metrics are being successfully calculated from the various underlying event, capacity, and performance information managers. N1 Grid solution use cases extend these typical functional and operational use cases by moving provisionable entities between elements that can host them (for instance, moving the database from one server to another) or supporting a service life cycle for a particular application or set of applications (for instance, from the development environment, to the test environment, to the production environment, and eventually to the deactivation of service).
In an architecture-centric approach, architecture is defined and validated before the development teams begin the bulk of implementing the system design. This is generally accomplished by building a prototype that exercises all of the unproven, but architecturally significant, aspects of a system prior to the start of detailed design and large-scale development. The architectural prototype focuses on such things as benchmarking the system or service response to a volume of representative transactions, testing the compatibility of various technologies, and certifying the smooth operation of a failure recovery mechanism. Some N1 Grid solutions will benefit from these initial validation steps.
Iterative and Incremental
Development in the SunTone AM is executed as a series of iterations, each of which consists of the development and integration testing of complete use cases. In this way, integration testing occurs early, often, and throughout the development cycle. The iterations enable the early detection and correction of requirements, design technology, or usability issues. These corrections are folded back into the earlier requirements gathering, measurement, or analysis phases, and the outcome of the earlier phases is reconsidered with the new information that the later phases uncovered. In addition to this iterative construction, system functionality can be broken down and delivered incrementally in a series of intermediate, well-tested releases each of which builds on the functionality delivered in the previous release.
Regression testing has an important role in interative and incremental development. The testing metrics from each previous run should either be deprecated or applied (as appropriate) to ensure no regressions creep into the architecture.
As the next sections introduce concepts that define areas for N1 activity, consider how iterative approaches can be built into a complete solution. Two examples might be iterating through compute, then storage, then network resources, as you drive to separate the delivery of these resource capabilities from the platforms that provide the capability, or iterating through automating service provisioning and observability in preparation for the policy-based optimization of those services.
People, Processes, and Tools
The functionality of the designed system cannot be delivered on its own. It requires the operational qualities to be realized in an environment that combines people, processes, and tools to deliver IT services to an agreed-upon service level in a predictable fashion with acceptable risk and cost. As previously illustrated, people and process have a huge impact on the cost, availability, security, and reliability of data center services. Aspects of operational maturity, possible impacts, and possible capabilities are discussed throughout the remainder of this book.