Modern Application Architectures: How to Design for Scalability and Performance

Modern Application Architectures:

How to Design for Scalability and Performance

Table of Contents

A. The Evolution of Service-Oriented Architecture

and the Cloud

1

B. Why SOA Matters

2

C. Natural Synergy: SOA and the Cloud

3

D. The Many Benefits of Using SOA With the Cloud

3

E. Merging SOA and the Cloud: Key Considerations

4

F. SOA and the Cloud at Rackspace

®

₈

G. Appendix

8

A. The Evolution of Service-Oriented

Architecture and the Cloud

The early days of web-based computing saw a major boom in service-oriented

architecture (SOA). Servers and storage networks were installed on a massive scale, with applications designed to operate narrowly scoped services. Those apps interacted with one another and with users through a separate presentation layer.

As services expanded, enterprises built additional servers and networks. Companies wishing to rapidly expand their offerings sometimes bought smaller organizations and folded the new architecture into existing infrastructure. The acquired architecture was treated as another service, to be called upon as needed. For years, this kind of operating strategy worked well, giving progressive (and cash-rich) tech companies a quick way to scale operations and deploy a wide array of systems.

Recently, however, problems with traditional SOA have begun to emerge. Enterprise-class organizations have struggled with increasingly complex architectures. Data and functions may be duplicated in multiple silos, for example, or applications may fail to communicate with one another properly. In enterprise-scale distributed computing environments, managing the scope of sprawling architectures is a massive challenge.

More and more people are looking to the cloud for solutions. According to the IDG

Enterprise Computerworld Forecast Study 20151_{, cloud computing projects are the}

leading technology initiatives currently underway. If cloud initiatives have gained such strong momentum, surely they have been steadily freeing organizations from convoluted hardware architectures and turning vast infrastructures into inexpensive, simple, shared commodities — right? Not so fast. Too often, as applications are redesigned with cloud computing and storage in mind, valuable SOA principles fall by the wayside. It has become far too common to develop substandard, monolithic cloud applications that can be

deployed in a matter of weeks or even days.

Today, the cloud is the default choice for new application development, but the considerable challenges of operating in the cloud are consistently downplayed. The largest of these challenges is scalability. Many of today’s cloud-based apps are not even built to scale, because it is assumed that they will be irrelevant in six months to a year. But that mindset has created its own problems in a cloud-centric world. Cloud servers are facing CPU bottlenecks and network bandwidth issues due to heavy demand. The

cloud may have been designed with such stressors in mind, but poor architecture is forcing companies to pay more for cloud services, and performance is not living up to customer expectations.

The solution lies in SOA. By combining the principles of SOA with those of cloud computing, enterprises can build a best-of-both-worlds IT environment. Splitting up applications into modular, reusable parts that remain deployed in the cloud will clear bottlenecks and ease pressure on networks.

In the pages that follow, we’ll talk about the numerous benefits of a hybrid SOA-cloud environment, including enhanced scalability, improved business flexibility and more.

B. Why SOA Matters

One key advantage of SOA: It provisions a common service bus on which multiple disparate services can operate. The service bus allows for the complete independence of applications that interact with it, but also lets them remain loosely coupled. In other words, business processes can independently use the service bus and SOA to exchange information. The service bus can be thought of as a water or electrical line, into which all the devices in a home can tap freely. In an application architecture, the service bus provides a common framework for applications to manipulate data.

SOA is like an N-tier Architecture, except the application layer of an N-tier design becomes a business logic/service tier. (See Appendix to learn about the differences between the two.) In an N-tier environment, applications stand alone. In SOA, they become reusable components that are integrated into a mesh of common services to allow those services to work together more freely.

SOA provides additional benefits to the organization. The concept of reusability is key because it allows services to be deployed in a variety of scenarios. Reusing code lowers development costs, shortens development cycles and tightly integrates business functions. SOA also enables a more distributed approach to development. Because services operate independently, an application designer doesn’t need to know how other applications in the system work. The applications will, however, share a common schema, which helps ensure interoperability. This in turn helps build a common development mentality in the organization, even if the applications are developed by separate teams. Services can be developed in parallel, shortening the development cycle even further.

The use of schema, in conjunction with a translation layer, means that services don’t have to be developed on the same hardware or operating system platform. A robust SOA architecture can pass information among Windows, Linux, HP-UX, AIX and all other common platforms. The service bus is concerned only with the integrity of the information, not the method by which it is accessed and delivered.

C. Natural Synergy: SOA and the Cloud

As businesses look to move their operations to the cloud, they face a basic challenge: migrating legacy apps to web-based platforms. Some legacy apps have been around for decades. One of the most exciting emerging solutions involves SOA.

In a typical enterprise, architects have to deal not with a handful of applications (as in our simplified examples above) but with hundreds of them, and their interdependencies can be highly complex. What happens when a system-of-record application needs to change the length of a data field spanning multiple systems? This kind of seemingly simple change can require countless hours of architectural and implementation work across dozens of disparate systems. An SOA bus running in the cloud provides a more streamlined way for changes like this to be distributed to other apps in the system. Naturally, cloud-based systems are also essential when trying to bring legacy apps into a web-centric world. Modern development may take place on web-based or mobile-centric platforms, but that doesn’t mean the organization wants to leave its older client-server apps behind. SOA in the cloud is a pathway that connects the two environments. Most importantly, combining SOA and the cloud yields an immediate increase in

development speed. SOA provides a framework for all applications to easily access cloud-based services, and entrusts the SOA layer with the task of reshaping data.

D. Natural Synergy: SOA and the Cloud

As businesses look to move their operations to the cloud, they face a basic challenge: migrating legacy apps to web-based platforms. Some legacy apps have been around for decades. One of the most exciting emerging solutions involves SOA.

In a typical enterprise, architects have to deal not with a handful of applications (as in our simplified examples above) but with hundreds of them, and their interdependencies can be highly complex. What happens when a system-of-record application needs to

change the length of a data field spanning multiple systems? This kind of seemingly simple change can require countless hours of architectural and implementation work across dozens of disparate systems. An SOA bus running in the cloud provides a more streamlined way for changes like this to be distributed to other apps in the system. Naturally, cloud-based systems are also essential when trying to bring legacy apps into a web-centric world. Modern development may take place on web-based or mobile-centric platforms, but that doesn’t mean the organization wants to leave its older client-server apps behind. SOA in the cloud is a pathway that connects the two environments.

Most importantly, combining SOA and the cloud yields an immediate increase in development speed. SOA provides a framework for all applications to easily access cloud-based services, and entrusts the SOA layer with the task of reshaping data.

D. The Many Benefits of Using SOA With the Cloud

On its own, the cloud provides many benefits to enterprises, but SOA can magnify those benefits considerably. Here are some of the most impressive examples:

•High availability. One of the greatest benefits of the cloud, higher availability,

is also a major boon to SOA environments. A traditional SOA is no less vulnerable to downtime than any other standard client-server architecture. Hardware can fail, and a network is only as strong as its weakest link. In the cloud, however, the SOA layer can be deployed behind load-balancing gear and configured with redundant servers. If a server fails, another can immediately pick up the slack. Servers can be distributed globally to further improve availability and performance and protect against natural disasters, power outages and other regional catastrophes.

•Security. In an SOA environment, data is constantly being exchanged among

a large number of relatively chatty applications. This flow of information has raised some security concerns. Denial-of-service attacks and SQL injection attacks are both particularly worrisome. Merging SOA with the cloud doesn’t eliminate these risks, but it does shift them to a potentially more robust system with better load balancing and higher availability. A well-coded SOA layer will act as a gatekeeper: Application B, for example, may be forbidden from

interacting with Application Z. This prevents hackers from flooding Application Z with requests from Application B: Properly architected SOA will simply deny these kinds of packets. In a cloud environment, more robust system logic can alert administrators that something is wrong and allow for a quicker response to a security incident. As this type of design grows in sophistication — with dozens or hundreds of gatekeeping rules — increased robustness will simplify cloud management and oversight.

•Data privacy. Despite the best efforts of management, sometimes software

is rushed out the door without proper consideration for data privacy. Data schemata have been known to include personally identifiable information that shouldn’t be passed among applications. That opens up organizations to significant legal liability. But cloud-based SOA can be used to build safeguards into the design. For example, logic that encrypts data as it is received can be added at the SOA layer, or personally identifiable information can be stripped before it is passed along. SAML authentication or WS-Security standards can be enforced between applications, and authentication actions can be passed over to a secure user/service management system like Active Directory or LDAP. Developers need not concern themselves with authentication or user management routines — the SOA layer handles the job for them. This simplifies privacy management while speeding up development.

•Ease of integration. By design, SOA provides a schema for the proper

structuring of data, but folding SOA into the cloud makes integrating multiple applications even easier. When applications communicate with one another in a non-SOA environment, developers have to be aware of the data structures used by every other application in the enterprise, and then provide customized outputs for each one. By contrast, SOA creates a common data framework for all applications, making complex customization and data translation work unnecessary. Storing these schemata on the cloud means that any app, legacy or modern, can access the SOA layer on the fly and in real time without a private network.

•Ease of collaboration. By design, the cloud facilitates collaboration among

developers. Physical location is fully transparent in a cloud environment, enabling greater flexibility in the deployment of development resources. In an SOA environment, this collaborative flexibility becomes especially valuable.

E. Merging SOA and the Cloud: Key Considerations

So, are you ready to give cloud-based SOA a shot? Before you dive in, know that SOA should not be undertaken casually. Careful planning is essential. Here are some key points to consider as you’re architecting your environment:

• Match service tiers to business logic. This is a central principle of SOA, and

it requires developers and management to collaborate on the business logic of the environment. First you must decide which business units need to talk to one another, and how. For example: What information do manufacturing and logistics need to share? Then that logic must be built into the SOA layer from a programmatic standpoint. The schema also needs to be designed to account for all relevant data shared among the applications specified by the business logic.

• Plan for exceptions and auditing. Each application should be designed to

handle exceptions and auditing functions. Tracked exceptions should include faults caused by failing infrastructure (disk failures, network outages, etc.), mistakes and bugs in software coding, and problems with user inputs. Auditing is often overlooked in SOA implementations, but it is legally or contractually required in many environments.

• Separate business functions from the presentation tier. The presentation

tier is the top level of the architecture, where users interact directly with the system. Shield business functions by strictly relegating users to the service tier. This makes it easier to modify the user interface and adds a layer of security.

• An API will make services accessible to higher layers. As a corollary

to the above, the application programming interface (API) converts service requests and translates between the presentation layer and the business logic layer.

• Ensure that each service messages through its own channel. Good

design means building applications that send and receive messages on their own channels. Each message should include a unique identifier that maps back to the original request. This allows auditability if something goes wrong.

• Business services should have a single implementation. Your architecture

should be designed so that each service function is controlled by a single instance of logic. Services should be narrowly aligned with singular responsibilities and should not appear in multiple instances, which can lead to redundant work and operational inconsistencies.

• The presentation tier should include no logic of its own. The presentation

tier should only be concerned with taking user requests and returning the results. SOA is built on teamwork, and it’s critical to fully leverage the strengths of each layer. The service tier should be exclusively responsible for all logical operations; the presentation layer should be solely responsible for sending information to the screen.

• The presentation tier should be governed by multiple servers. This is a

natural by-product of the cloud and a best practice for designing high availability and scalability. Load balancers can be used at both the service layer (to help manage performance) and the presentation layer.

• Remember that SOA may be overkill for smaller enterprises. SOA can

be a complex endeavor, and it makes sense only for organizations with many interconnected moving parts. If you’re designing a simple application with a single business function, don’t get lost in the weeds of a complex architectural environment like SOA. Develop a stand-alone application. If your needs expand later, you will be able to integrate the application into an SOA environment by developing the API layer.

F. SOA and the Cloud at Rackspace

Our developers know how to build application architectures that leverage SOA. We can answer any questions you might have about integrating SOA into the cloud, and help get your system up and running successfully. But we don’t just make our application-architecture expertise available to customers. We also provide enterprise-class infrastructure, so that once you are in production, you can deploy your applications and service plans on our infrastructure and alleviate your operational burden.

Whether you want to design and implement application architectures on your own, or get help from our cloud experts, Rackspace has the expertise and infrastructure you need to operate your app securely and at scale.

Find out more at www.rackspace.com/cloud.

G. Appendix

COMMON ARCHITECTURES, EXPLAINED

In development terms, an architecture provides a framework in which program

components are stored and partitioned and supplies a set of rules for the re-use of these components. Architecture informs application design, deployment and interoperability, and it sets the terms of the debate on application development.

Choosing an appropriate architecture requires a fundamental understanding of

architecture types. Here are some of the most common architectures influencing modern application design:

• N-Tier Architecture. Commonly used in web applications, N-tier Architecture

typically has a three-tier design to partition applications into physically separate but connected strata. A database server stores information on behalf of the application. The application server stores the primary code base, and a web server interfaces directly with the user via a browser. More complex N-tier systems can have additional partitions, or tiers, all stacked on top of one another like a layer cake. The key is that each tier is completely independent and communicates only with the tiers directly above or below it.

• Service-Oriented Architecture. Service-Oriented Architecture (SOA) builds on

N-tier Architecture to enhance functionality. The two architectures are not mutually exclusive. The key difference is that an SOA infrastructure is not as strictly siloed. In a typical SOA environment, applications are exposed to a common message bus or API layer that acts as an intermediary within the application tier (commonly referred to as the second tier). Services that operate within this layer are independent, but communicate with both the database layer and the web/presentation layer through a common schema (such as XML) across the message bus. Multiple SOA services may operate on this bus simultaneously, and these services may be located on either the internal network or a remote server.

• Domain Architecture. Domain Architecture, or Domain Driven Design (DDD),

approaches architecture by directly modeling the business domain. Applications are built to mimic business functions, and application roles are similarly business-oriented. A common language — abstracted to exclude dense technical terms — is used to help non-expert team members understand the architecture. Ideally, the design and development of applications becomes accessible to everyone involved.

• Message Bus Architecture. Message Bus Architecture refers to systems that can

send and receive messages on a common channel without any knowledge of other systems on that channel. The most common form of Message Bus Architecture is called Publish/Subscribe, which is widely used for text-based messaging systems. Here, the publisher does not send messages directly to subscribers, but rather outputs the message to a queue known as a “class.” Subscribers are able to access the classes they are interested in but do not know the identity of the publisher. As the name implies, Pub/Sub systems see wide implementation within email and other messaging platforms.

• Object-Oriented/Component-Based Architecture. Object-oriented design isn’t a

new idea, but it’s being revived thanks to the containerization features in projects like LXC, Docker and Rocket. The guiding principle of Object-Oriented Architecture is that all code should be independent but also interact well with other applications. Systems are split up into reusable, independent objects, and objects interact with one another through a loosely coupled system. The workload is moved into a container of multiple objects and executed, and after the job is completed, the container is killed.

H. Reference

About Rackspace

Rackspace® _{(NYSE: RAX) is the #1 managed cloud company. Its technical expertise and Fanatical Support}®

allow companies to tap the power of the cloud without the pain of hiring experts in dozens of complex technologies. Rackspace is also the leader in hybrid cloud, giving each customer the best fit for its unique needs — whether on single- or multi-tenant servers, or a combination of those platforms. Rackspace is the

founder of OpenStack®_{, the open-source operating system for the cloud. Based in San Antonio, Rackspace}

serves more than 300,000 business customers from data centers on four continents.

GLOBAL OFFICES

Headquarters Rackspace, Inc.

1 Fanatical Place | Windcrest, Texas 78218 | 1-800-961-2888 | Intl: +1 210 312 4700

www.rackspace.com UK Office

Rackspace Ltd. 5 Millington Road Hyde Park Hayes Middlesex, UB3 4AZ Phone: 0800-988-0100 Intl: +44 (0)20 8734 2600 www.rackspace.co.uk Benelux Office Rackspace Benelux B.V. Teleportboulevard 110 1043 EJ Amsterdam Phone: 00800 8899 00 33 Intl: +31 (0)20 753 32 01 www.rackspace.nl

Hong Kong Office

9/F, Cambridge House, Taikoo Place 979 King’s Road,

Quarry Bay, Hong Kong Sales: +852 3752 6488 Support +852 3752 6464 www.rackspace.com.hk

Australia Office

Rackspace Hosting Australia PTY LTD Level 1

37 Pitt Street Sydney, NSW 2000 Australia

© 2015 Rackspace US, Inc. All rights reserved.

This white paper is for informational purposes only. The information contained in this document represents the current view on the issues discussed as of the date of publication and is provided “AS IS.” RACKSPACE MAKES NO REPRESENTATIONS OR WARRANTIES OF ANY KIND, EXPRESS OR IMPLIED, AS TO THE ACCURACY OR COMPLETENESS OF THE CONTENTS OF THIS DOCUMENT AND RESERVES THE RIGHT TO MAKE CHANGES TO SPECIFICATIONS AND PRODUCT/SERVICES DESCRIPTION AT ANY TIME WITHOUT NOTICE. USERS MUST TAKE FULL RESPONSIBILITY FOR APPLICATION OF ANY SERVICES AND/OR PROCESSES MENTIONED HEREIN. EXCEPT AS SET FORTH IN RACKSPACE GENERAL TERMS AND CONDITIONS, CLOUD TERMS OF SERVICE AND/OR OTHER AGREEMENT YOU SIGN WITH RACKSPACE, RACKSPACE ASSUMES NO LIABILITY WHATSOEVER, AND DISCLAIMS ANY EXPRESS OR IMPLIED WARRANTY, RELATING TO ITS SERVICES INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, AND NONINFRINGEMENT.

Except as expressly provided in any written license agreement from Rackspace, the furnishing of this document does not give you any license to patents, trademarks, copyrights, or other intellectual property. Rackspace, Fanatical Support, and/or other Rackspace marks mentioned in this document are either registered service marks or service marks of Rackspace US, Inc. in the United States and/or other countries. OpenStack is either a registered trademark or trademark of OpenStack, LLC in the United States and/or other countries. Third-party trademarks and tradenames appearing in this document are the property of their respective owners. Such third-party trademarks have been printed in caps or initial caps and are used for referential purposes only. We do not intend our use or display of other companies’ tradenames, trademarks, or service marks to imply a relationship with, or endorsement or sponsorship of us by, these other companies.