Contents


Path to designing a cloud-based, always-on system

An architecture for the cloud enabled data center

Comments

The consumer banking industry is reorienting its business models by moving from product-centric silos to customer-centric strategies. Banking systems must become highly resilient platforms to take advantage of consumers' ability to access their accounts and conduct transactions through multiple channels (including mobile devices). Financial institutions are struggling to sustain and improve resiliency in their legacy data center environments to support new revenue-generating services — especially services that are evolving to leverage cloud computing, mobile technology, and enterprise APIs. As banks take on these technologies, they discover the inefficiencies and limitations of their existing legacy environments and ponder ways to modernize to take advantage of the new technologies.

This article presents a case study, from a high-level perspective, of the design of a private-cloud-enabled solution for consumer banking services. Our architectural approach builds on proven techniques for identifying resiliency issues, establishing resiliency targets, and using cost-controlled patterns for transforming a traditional IT environment into a resilient cloud-based system. The approach is also applicable to industries other than financial services.

The need to define an always-on architecture

The financial institution we worked with wanted its digital-channel services to be continuously available (always on). We performed a capability analysis of the applications and platforms that comprise the channel-access services and business services that support critical customer-service functions (log in, view account balances, view recent transactions, make payments, and shop for services). Figure 1 is a high-level overview of application systems and related system components for the bank's existing digital-services areas. We observed that applications are developed, deployed, and managed in a vertical model (silos), whereas storage and network components are enterprise-wide shared resources.

Figure 1. Mobile and online banking system
Image shows diagram of the bank's existing system architecture for digital services
Image shows diagram of the bank's existing system architecture for digital services

The group of customer-facing applications that we considered consisted of:

  • A web server farm running online banking services
  • Application servers running mobile services
  • Enterprise information services
  • Legacy security with single sign-on
  • Enterprise integration services

This set of interdependent, interoperating applications also relies on additional services within the bank's IT environment and from external third-party service providers.

The key application architecture characteristics of the existing system are that it:

  • Is architected in a layered fashion with a loosely coupled approach.
  • Uses open standards (Java™ Enterprise Edition and related technologies) following component-architecture patterns.
  • Uses industry-standard communication mechanisms and protocols (HTTP, Java Database Connectivity [JDBC], Simple Object Access Protocol [SOAP], etc.).
  • Follows industry best practices in a standards-based framework implementing a service-oriented architecture (SOA) approach for integration and routing among major subsystems through enterprise integration services.

Figure 2 is an overview of the existing banking solution's IT architecture.

Figure 2. IT landscape supporting the current mobile and online banking system
Image shows overview diagram of the existing banking solution's IT architecture
Image shows overview diagram of the existing banking solution's IT architecture

This traditional architectural model contains shared layers of network and storage services with fragmented and heterogeneous server farms, along with platform components. The bank was just starting to define a common monitoring and management system for the system landscape. In combination with the bank's then-current non-streamlined maintenance practices, the landscape posed a high risk of failure because the system's components are interdependent: The resilience capabilities (or lack thereof) of any one affects all of its dependent neighbors. Only a holistic view and approach will yield a highly resilient system. Fortunately, solutions that adhere to a loosely coupled, standard-based framework can take advantage of the cloud computing model operating on virtual infrastructure and platforms.

Cloud-based architectural approach for always-on services

The basic tenets of cloud architecture are standardization, virtualization, and automation. When leveraged correctly and integrated together, these tenets are the key to highly resilient systems. Virtualization of infrastructure components (such as servers, storage, and network) and sharing of platform components (such as databases, application servers, and integration buses) — combined with cloud service-management aspects (such as provisioning, monitoring, and automation) — are fundamental to supporting highly resilient systems.

Standardization, virtualization, and automation are central to the bank's vision of providing always-on digital services to customers, through one or more of the following characteristics:

  • Highly available end-to-end systems, with all components designed with fail-over mechanisms that are triggered in the event of failure
  • High integrity of data/information through resilient system components that ensure that customer transactions are completed
  • No scheduled or unscheduled downtime for maintenance of any system or application components

The IBM cloud-enabled data center (CEDC) approach enables resilience through several layers of architectural construct:

  • Infrastructure as a Service (IaaS)
  • Platform as a Service (PaaS)
  • Software as a Service (SaaS)
  • Business Process as a Service (BPaaS)

Figure 3 is a diagram of the CEDC architectural model.

Figure 3. CEDC reference model and key components enhancing resiliency
Image shows diagram of the CEDC architectural model
Image shows diagram of the CEDC architectural model

In the model shown in Figure 3, the IaaS and PaaS layers, along with the resiliency building blocks, are the primary enablers of highly resilient solutions. Virtualization of infrastructure and IaaS enable better utilization of capacity and higher availability. The resiliency-governing building blocks help define policies and procedures for implementing, managing, tracking, and monitoring cloud applications for higher resiliency.

The operational support services (OSS) and business support services (BSS) layers of the common cloud management platform (CCMP) help to enable automation. Standardization of infrastructure and platform elements with BSS/OSS enables maximization of platform resources and reduces deployment errors, leading to high availability. CCMP with OSS is the key component for automation activities. Automation — combined with integrated monitoring and virtualized infrastructure — helps with dynamic adjustment and scaling of computing resources. The dynamically expandable and flexible set of virtualized compute, storage, and network technology building blocks suffice to remove silos. Automation through OSS and BSS will help to transition the bank's traditional IT environment into a robust and highly resilient always-on environment.

Based on this CEDC reference model, we developed an always-on solution for the bank. Figure 4 depicts the cloud architecture for the solution.

Figure 4. Cloud-based, always-on system architecture for mobile and online banking solution
Image shows diagram of cloud-based architecture for the mobile and online banking solution
Image shows diagram of cloud-based architecture for the mobile and online banking solution

Key architectural aspects of the infrastructure layer

The solution is foundationally enabled by an IBM SoftLayer IaaS layer with compute, storage, and network components shared across some major application groups — particularly external consumer-facing static support systems, routing functions of online services, and mobile banking apps. The critical nature of financial-services business needs dictated that the solution architecture be based on SoftLayer's dedicated bare-metal offering in a highly secured environment with a single-tenant model. Following are some of the salient aspects of the integrated compute, storage, and network IaaS in our solution architecture that are geared toward making the always-on vision a reality.

Compute

For compute, we selected the SoftLayer bare-metal option to provide a highly available always-on solution that satisfies the institution's need for a private environment. With bare-metal solutions, the customer has exclusive use of the computing server and the network and storage, which can be configured for local and global resiliency. As an alternative to bare metal, we considered the virtual-server offering from SoftLayer as a way to maximize operational expense (OPEX) savings through the multi-tenancy computing approach. However, certain regulatory requirements affecting the participating business functions led us to do an architectural trade-off analysis that ruled out the virtual-server option.

Storage

Because achieving always-on with local storage would require redundant local storage in the globally dispersed bare-metal configurations, the storage configuration architected was storage area network (SAN). A SAN architecture provides better management and flexibility across bare-metal instances because it is designed to support RAID 5 or greater configurations easily to synchronize data.

We considered synchronous data updates for data-sensitive applications (financial transactions) and asynchronous updates for less data-sensitive (such as static customer-support information) or backup solutions. SAN storage in this context is recommended over local storage for better integrity and performance. Such storage virtualization allows elastic bandwidth on-demand in support of auto-scaling an application — scaling up in response to higher demand and scaling down as demand decreases. This solution meets the demands of organizations that need highly available, always-on private environments that continue to reduce capital and operational expenses.

Networking and network security

The SoftLayer network architecture — with high-speed intra-data center connections with load balancing — provides the redundancy and flexibility expected by users with stringent recovery time objectives (RTOs) and recovery point objectives (RPOs). SoftLayer's core capability of global provisioning for distributed business applications across geographically diverse, yet integrated, data centers addresses the need for high availability to the tune of 99.999 percent uptime. For businesses demanding high performance for some their consumer-access systems, the point of presence (POP) network feature of SoftLayer provides direct or shorter connections for lower latency.

To help to protect the bank's business-critical applications, SoftLayer's perimeter security is implemented through carrier-class firewalls and virtual firewalls. This network-within-a-network aspect of the architecture maintains a secure environment. For systems administration and cloud environment access through a web console, our architecture includes VPN connections with encryption, and role-based security with identity and access management.

Monitoring and management

The monitoring and management aspects of the original system are enhanced with automation through BSS/OSS support functions and resiliency building blocks. These components, along with the IaaS API layer, ensure elasticity of the system for higher resiliency.

The IaaS layer is supported by the SoftLayer API with about 2,000 APIs for monitoring and managing the elasticity of the system. This API architecture is the basis for the auto-scaling that the bank needed to integrate with its on-premises monitoring systems. Management of an always-on infrastructure is supported programmatically at many levels through SoftLayer's API management model, which provides programmable interfaces. Management of applications runs without any human intermediation, which streamlines server management and reduces the cost of IT operations for the always-on infrastructure.

PureSystems

In addition to the SoftLayer-based IaaS, IBM PureSystems® is a key component in the always-on architecture. A critical function of the solution stack, enterprise integration services, supports not only the bank's customer-systems domain but also other domains in the enterprise. The pain of migrating this particular business function module outside the premises is high relative to the gain. The pain comes mainly from the need to integrate on-premises systems, with myriad other back-end applications, with cloud when security concerns are high. The fast and efficient way to build on-premises private cloud systems that are highly available for always-on infrastructure was a key consideration in including PureSystems in our architecture. PureSystems integrates compute, storage, network, and management software into preconfigured platforms optimized for the needs of specific workloads and environments.

An additional reason for including PureSystems is that it can be configured with a PaaS component, which in this solution is required for the enterprise integration services platform. The architecture with PureSystems includes a proven model for network redundancy, addressing a need for interconnectivity and global load balancing to maintain resiliency with functionally independent distinct and redundant resources. The flexible security configuration supports identities, access, encryption, monitoring, and auditing to meet compliance requirements. The SmartCloud Orchestration management packaged with PureSystems helps users create images, provision environments, and deploy on a private cloud, and it also provides a basis for cross-cloud integration.

Platform layer

We recommended that the bank take a phased approach to implementing the layered and structured CEDC model:

  • Phase 1 — Implement the IaaS, along with some automation-enablement elements with a CCMP/BSS/OSS layer as the foundation.
  • Phase 2 — Consolidate the platform components with the data- and integration-platform elements.

In Phase 2, the solution architecture is also enabled by a PaaS layer in which some of the core platform components are consolidated. Within the platform layer:

  • The data layer is consolidated with a data platform consisting of InfoSphere® and DB2® database software with InfoSphere Streams. The InfoSphere multi-tenant feature provides the base for multiple applications to share the data platform, and the InfoSphere Streams feature addresses high-transaction-volume analytics needs.
  • A core integration platform, based on WebSphere® software, enables decoupled integration services among the applications.

Conclusion

The need for always-on systems isn't unique to the banking industry. Any business that has high connectivity with services delivered through multiple channels — and that seeks to maintain high customer-satisfaction rates — can leverage cloud computing and the CEDC model for highly resilient and highly available systems. A phased approach to implementing the CEDC model by first implementing IaaS and then consolidating platforms by enabling PaaS is an ideal way to achieve an always-on system.


Downloadable resources


Related topics


Comments

Sign in or register to add and subscribe to comments.

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=Cloud computing
ArticleID=963409
ArticleTitle=Path to designing a cloud-based, always-on system
publish-date=06292014