Software design patterns for PAAs environments

Note: Codename:bluemix is a beta-grade product and will continue to improve as we continue to make it more functional and easier to use. We will do our best to keep this article up to date, but it is not always in full progress. Thank you for your understanding!

Effective, innovative applications can even be compromised or fail in the marketplace because they do not meet the NFRs of performance, response time, and overall reliability. Traditionally, architects respond to NFRs by modifying the shape and size of the infrastructure. The number of concurrent users is handled by partitioning a user's session to multiple systems running concurrently, and response times can be improved by eliminating performance bottlenecks, often in database and storage use, and service requirements by adding new services that can quickly perform High-volume event records; But in a cloud environment, architects are more limited in their choice of ways to manage NFRs.

The cloud infrastructure, the service (IaaS) platform, makes infrastructure modifications more economical and easy (which explains why the IaaS environment is prevalent in fast-changing, rapidly expanding workloads), and the architect's choices are correspondingly reduced. The cloud Platform, a service (PaaS) environment, goes a step further in this paradigm, eliminating horizontal scaling, component placement, logging, and system Management from a user perspective. These actions can occur, but as an IT architect, you cannot control (or have little control over) them.

However, the architect's management of NFR does not disappear in the cloud environment. Instead, they are transferred to the internal mechanism of the application for some application design patterns. The implementation of these patterns ensures that cloud applications are "civilians" in the cloud Operating environment (CLOUDOE) and do not connect to the CLOUDOE mechanism and are consistent with how Cloudoe works. This article describes the NFRs patterns and types that they solve in the PaaS environment, as well as IBM Codename:bluemix, an open standard PaaS cloudoe in which you can take the design pattern into effect.

NFRs and Stress Cases

Functional and non-functional requirements are conceptually different. Both represent the motives of the stakeholders or the affected person of the defined system. As IT technologies and roles evolve, software systems continue to increase the number of stakeholders and the complexity of their requests. In addition to the users of the system, stakeholders and their respective needs include:

Developer: Structure and sharpness of code maintenance personnel: Logging and Debugging Tools testers: Tracking and other problem-solving tools providers: The simplicity of application training operators: Providing information level Operations Manager: Solution Scalability Configuration Management Specialist: supported middleware packaging and levels Database administrator database Resource Usage and Optimization Service Manager: Skills and work network and system management specialists for monitoring operations: Supported Tools Enterprise Architect: Compliance security officer with corporate standard architecture procurement staff: scalability and adaptability of solutions evaluators: Auditing tools. Support staff: The complexity of user operations: Communication staff: interface Clarity

This situation considers complex systems with difficult functional requirements and rigorous NFRs, including very high availability, fast performance, and challenging security requirements. Cloud computing also adds to the need for high flexibility and geographic dispersion-available anytime, anywhere.

How does IT architects ensure that the architecture of the system is able to satisfactorily encompass all of these requirements? The crisis here is that the solutions to the needs are isolated and do not take into account the impact that a demand solution might have on other requirements.

To consider the requirements as a whole, you can envision them as relative "forces" (force), as shown in Figure 1. IT Solutions may address these forces in an optimal manner.

Figure 1. Demand is a relative force

In Figure 1, these forces include:

Functional Requirements The quality requirements and constraints we impose on IT systems (NFRS): Runtime quality non-run-time quality business constraints technical constraints

Of particular importance is the combination of relative forces that may run together at any given time. In addition, some of the simultaneous effects of the force will be mutually reinforcing. In other words, their effects increase the stress on specific parts of the system. For example, the combination of a large number of concurrent users with a shorter recovery time after an error may put pressure on the user's identification subsystem after a system failure, leading to a large number of operations and actual blocking operations. Similarly, strict response times combined with databases with limited resources can result in a combination of unhandled requests, unless the application is designed to handle it (for example, by using caching mechanisms). As in civil engineering, we use lexical stress cases to identify these simultaneous and mutually reinforcing forces.

The cloud provider's service level agreement (SLA) is one of the requirements (constraints) of the solution and may affect stress cases. For example, if the IaaS contract specifies a certain amount of virtual network, this potential constraint on the internal throughput of the managed application may require a specific mechanism to achieve the external throughput target.

Sometimes a stress case can make it impossible to meet all the requirements at the same time. In these cases, you may have to set a more restrictive set of requirements to maintain a reasonable level of service for your users. We call these cases degraded operations. Degraded operations may not be avoidable in a cloud application, so it is important to design them carefully and communicate with the user when they appear.

A simple, universal example of a demotion operation is off with the final consistency mechanism of the fragmented database. These databases provide multiple read instances in the cloud to ensure performance and reliability, while writes for a particular data element are always completed on the same instance (in order to maintain write consistency). Because the time it takes to copy new data is limited, the information in one instance of the database may be inconsistent when it is read; Applications that use the final consistent data must be able to support degraded operations by making jokes about inconsistencies that the user perceives (for example, by displaying updates that are still in the buffer and not committed), or (if no active data is available) by alerting the user when the database is last updated.

An example

To help explain how to handle the NFRs in the Cloudoe PaaS environment, we will develop an example based on a fictitious Amgro.cloud company that sells its products through a network of independent, part-time salespeople who earn commissions.

Amgro decided to start entering the online sales market by providing a directory to purchase applications. To accelerate deployment, Amgro plans to develop the application in a cloud provider's PaaS environment, which will provide Web UI, security services, and access control, and link to the online services of market leaders in delivery and payment services. The new application must also be integrated with the existing Amgro Enterprise resource Planning (ERP) platform for accounting and warehouse management.

The NFRs of Amgro's new applications include:

The number of

concurrent users is estimated to be about 10,000. All catalog views are expected to be available in less than 1 seconds on a regular ADSL connection or a high-speed cellular network. Amgro's cloud environment and payment services are expected to have 24x7 availability. Amgro and delivery service providers through regular Internet connections.

The response to the service request is a 2-hour commitment SLA. In addition, the availability goals of delivery services vary during the night, during which they perform system maintenance. This SLA should not be changed for contractual reasons.

Because the new PaaS application will connect to the Amgro ERP system, this interface is highly sensitive and must be adequately protected.

Figure 2 illustrates the Amgro example. (This figure and most of the graphs later in this article use the TOGAF archimate concept.) ）

Figure 2. Amgro sample

In the Amgro system, the following NFR combinations must belong to stress cases:

Case 1: Sub-second response time, but the system is loaded:

10,000 Concurrent User sub-second level response time

Case 2: Sub-second response time, but the external system is slow or unreliable:

second-level response time delivery and payment services via a regular Internet connection

Case 3: The application should be available, but the external system is asynchronous or has a mismatched SLA:

24x7 Availability Internet Connectivity Availability SLA does not match offline processes

Case 4: Mixed cloud:

Secure Connection

The role of PaaS applications, NFRs, and architects

A cloud-operating environment based PaaS Solution leverages the Cloudoe programming model to manage NFRs and eases some of the tasks for the application architect:

Manage user load on a horizontal scale: Cloudoe Add and remove component instances from the virtual machine based on the workload for appropriate adjustments. The application architect no longer needs to deal with scalability, but now must understand which components must be expanded at the same time, and how to manage different levels of expansion between the components of the communication. Leverage the latest technology for critical paths: in internally deployed solutions, architects take advantage of the latest technology in critical parts of the system (databases, message backbone, etc.). In cloud computing, you use standard technology and have a limited number of basic choices. Eliminates hardware or software technical inconsistencies, but critical paths must be handled through design patterns. Eliminate performance bottlenecks by putting them in the same location: placing adjacent artifacts with a high degree of interactivity is a common practice for improving performance. You can still do this with applications in Cloudoe (assuming that this bundle does not hinder horizontal scaling), but you may not be able to control the synergy of applications and technical services (such as MongoDB) with multiple distributed replicas. Control SLA: In Cloudoe, no applications are isolated. For the purpose of enhancing the overall reliability of the system, the components involved can be anywhere. On the other hand, the SLA submitted by the local cloud provider may be different from the SLA submitted by another connected component on the different cloud platforms. The application Architect cannot assume a unified SLA and must consider the likelihood of a response being lost or delayed.

PaaS NFRs Management model

If you draw a PaaS action context diagram, we can identify 4 types of external roles:

the user of the application itself (the consumer of the application Service): These role peers have requirements related to the response time and availability of the application. In addition, typical cloud applications often have unpredictable complexity due to the number of concurrent users. External systems: These are physical systems outside the cloud that are not under the control of the application architect. Event-driven services: Some services may implement long-running processes or an asynchronous interface. Internally deployed systems (mixed services): The Cloud components and internal components of the internal deployment system are under the control of the application architect, so the architect can adjust them according to the NFRs.

In response to 4 PaaS roles, we identified 4 NFR-related design patterns:

Stateless application mode that manages the expansion of the number of users, high availability, and support for short response times, even when the system is loaded. Asynchronous application Mode, which manages response time and continuous availability when long-running services need to participate in the application process. External API patterns that manage high availability and scaling when the process flow involves external systems. Secure VPN mode, securely integrates internally deployed systems.

Figure 3 illustrates 4 patterns and their relationship to 4 roles.

Figure 3. PaaS mode

Stateless Application Mode

The goal of stateless application mode is to ensure that the system can be extended at the same time, service a large number of requests and keep execution paths as short as possible. Figure 4 illustrates the stateless application pattern.

Figure 4. Stateless Application Mode

The basic mechanism used is the cloudoe horizontal extension function. Horizontal extensions are provided by performing dynamic opening and closing of environment instances, and by system-level routers/balancing components.

To efficiently use dynamic extensions, application components must be completely stateless. Typically, in a traditional WEB application, all requests from a user are routed to the same application server instance, which saves session data and dialog state in memory. Session cookies are used as keys to retrieve session data and process requests from memory. In cloud computing, most managed cloud implementations cannot guarantee that the same application instance will serve a session. Session requests must be routed to different application instances by the Internet-facing routers. Therefore, in this mode, to keep the execution instance completely stateless, memory storage is used externally and is shared as a service between all instances provided by the managed cloud. (otherwise, a downward adjustment is not possible until all sessions of an instance are closed.) ）