The Architecture Element - Part 3

Unicon is publishing an article on ways of approaching decision-making about adopting cloud and/or managed services. The article will be broken down into segments. The segments will cover elements including: strategic, financial, architecture, security, process, and people.

We continue the series this week by publishing the architecture segment of the article.

The Architecture Element

Architecture addresses the non-functional requirements of systems. Important non-functional requirements include reliability, availability, and scalability, often referred to as RAS. It is important to understand the RAS requirements of the service(s) under consideration, how those needs are met today, and how the underlying cloud infrastructure supports those constructs.

Questions to consider:

• Can the app scale out horizontally, and if so, which tiers?
• If there is a scale-up only tier, what is the limit of that component (cpu, memory, I/O, bandwidth, etc.) and what are its limits in the proposed cloud infrastructure?
• If the service requirements are high availability (HA) 24x7, is that 99.9% or higher availability?  
• What cloud and application architecture approaches to achieve HA exist and are they compatible?  

Today, there are few Service Level Agreement clauses in cloud services although the design and operations of the offering are consistent with 4 or 5 9's of availability (Note: Expect competitive pressures to change the SLA story over time). The track record of the provider, if available, can give some indication of ability to deliver on availability requirements but some organizations will still need committed SLAs from their cloud provider.  

Disaster recovery for mission-critical applications is an important RAS consideration. Cloud can provide substantially reduced investment levels to achieve DR, even using traditional “stand by” types of approaches.  Native cloud capabilities, however, can provide simplified DR foundations, handling data replication, name resolution, and routing if the app can take advantage of the cloud platform that offers such capabilities.  As with any DR plan, the means for regular testing need to be considered.

There are several other dimensions to architectural aspects when considering cloud. For the applications and services under consideration, do the application architectures lend themselves to the cloud environment under consideration? The tech stack across all tiers of the app needs to be considered along with how well the cloud environment supports these. As examples, if a clustered caching tier is present that relies on IP multicast, can the cloud environment support the necessary networking and clustering or will other means need to be used for scaling and performance? Sometimes the consideration is as mundane as database or storage size. Many cloud vendors have a limit on the sizes of a storage volume or database size for various persistence solutions. If you have a large app with a 2TB database and the cloud provider limit is 1TB, can the application's db be sharded or federated to fit into these constraints or not? High transaction volume applications can provide specific challenges where horizontally scaled database tiers rely on high speed node inter-connects and high speed access to shared storage. Alternatively, if new applications are under consideration or development, make sure they are architected to take advantage of cloud environments. Applications should have small, easily deployed and scaled services, data persistence technologies that fit cloud deployments, and packaging and deployment automation to simplify provisioning.

Additionally, the overall operating environment needs to be considered - are candidate applications fully isolated or are they integrated with other systems or do they play a role in complex workflow or dataflow? In some cases, the risks associated with delivering required service levels where integrated components straddle cloud and private/dedicated environments is too large and the "as is" deployment continues to make sense. On the other hand, well-isolated systems and applications may be attractive targets for cloud migration. Even in complex integration scenarios, however, the advantages of cloud may outweigh the complexities. Referring back to the seasonal demand issues in educational apps, migrating a learning management system to the cloud may have such great scale up/down advantages (performance and cost) that the complexities of integrations with identity stores and campus information systems make the cloud very attractive.

Hybrid cloud solutions which mix fixed, dedicated resources (physical or virtual) with dynamically deployable resources carry some similar characteristics with highly integrated environments.  The deployment and management complexity can be higher, requiring investment in automated provisioning/de-provisioning (as well as understanding the metrics that should trigger scale up/down) to make the approach effective.  For highly variable workloads or rapidly increasing demands where there is already fixed capacity, hybrid approaches might be effective, but engineering and management complexity is generally high.

Every week for the next three weeks Unicon will publish another segment of this article. Please check back for the next segment, which will cover the security element.