Chapter 9

Architecting Cloud Compatible SaaS Software Products

9.1  Introduction

In order for a software product to be deployed as cloud compatible software as a service (SaaS), it has to meet the characteristics mentioned in Chapter 5.

Whether an existing software product is cloud compatible or not can be assessed through the cloud compatibility measures described in Chapter 6.

Many of the current versions of software products in the market are not cloud compatible. Reference [24] confirms the same. Reference [5] also indicates the same although it was chronological earlier.

Therefore, the question of ‘how to make the existing products as near as ultimately cloud compatible’ is the main topic of this chapter. The body of knowledge is too enormous. This chapter touches upon many areas at top level. It also skips a few, thinking it is not critical for a quick overview.

Although any existing software can be deployed as such without any modification to it, in infrastructure as a service (IaaS), such a deployed software cannot be considered as ‘cloud SaaS’. It will not have automatically on its own all (or at least required) the characteristics, pointed out in Chapter 5, for cloud SaaS software.

Continuing to answer the main question raised, there are two options to make an existing product completely cloud compatible:

1. Option 1 is to develop the software product again ground up by completely having an ideal cloud compatible architecture.
2. Option 2 is to retrofit the existing current version of the product to make it more cloud compatible. Reference [5] also indicates the same.

Option 1 is highly time consuming and also a costly approach. Business economics may not permit such an approach.

However, on examining the characteristics of cloud SaaS software, one can easily conclude that cloud characteristics stem from architecture (of software products) rather than from a functionality of the products. Therefore, for ‘cloudifying’ (meaning making closer to absolutely cloud compatible) an existing product altering its architecture is more appropriate. Thus, retrofitting an existing product to meet this objective is difficult. Option 1 of re-architecting seems inevitable.

As it is a costly and time-consuming exercise to re-architect, many of the software product vendors have not taken their products for making it cloud compatible.

As a domino effect, the same reason leaves a less number of cloud compatible products in the market. This in turn has resulted to invent mechanisms such as those described in Chapter 7 or 8 to provide cloud SaaS solutions with no or partially cloud compatible products.

However, service consumers need some solutions until the market gets cloud compatible SaaS products. Therefore, the customers need solutioning techniques such as those described in Chapter 7 or 8.

Such an action will help software vendors to provide a cloud SaaS solution using existing products. Hence that can give additional revenue from new emerging markets such as small- and medium-sized enterprises (SMEs) or ‘long tail’, which are possible to reach only because of cloud-based software services. That in turn will give both money and a good data point to know the potential market size of ‘SME’ or ‘long tail’. Hence, product vendors can evaluate their product position on whether to invest for making their products fully cloud compatible or not.

Also during this time, gray-scale solutions may emerge between nothing or only re-architecting and redeveloping as an option. If some such option emerges, it may reduce the cost of re-architecting their products.

Some examples of gray-scale intermediary approaches are re-pack a non-compatible existing version of the software into cloud compatible product using techniques described in Chapter 7 or 8.

This chapter explains a Greenfield approach of starting from scratch, a ground-up approach to build a cloud compatible SaaS software product. Although it is little idealistic, the content of this chapter will provide an ideal architecture that any cloud compatible software must have. Engineering knowledge discussed in this chapter is useful even for architecting cloud SaaS solutions; also architects can use this knowledge to evaluate architectures of any software product for its suitability to provide cloud SaaS or include architecture as one of the criteria for cloud compatibility assessment of software products.

There are no major big differences between architecting solutions or products. But in architecting solutions, the differences are as follows:

1. The major concentration is on integrating functional modules.
2. Wherein the functional modules (SBBs) may be mostly be filled by products.
3. Thus, product (SBB) selection is important aspect.
4. There are very little custom code being developed (since most of the functionality is met by the products and their customization).
5. Solution architects will have least control over the inside code of the constituent products; custom code being developed specifically for the solution will
   1. Either fill in those additional functionality not covered by any of the products – this is very rare situation, or
   2. Integrate various modules and products that constitute the solution.
6. The major role for the solution architect is to find solution building blocks (SBBs) meeting architectural building blocks (ABBs) – meaning identifying appropriate products (SBBs) that will meet the functional requirements (ABBs).
7. The focus on functional realization will be at broad top level unlike the fine granular-level focus on functional realization for product architects.
8. Evolving solution architecture is much simpler in this sense.
9. If the constituent products are more cloud compatible, architecting, subsequent realization and operations becomes much easier, less costly and hence can be competitively priced lower.

But on the other hand, product architecting involves a lot of critical decisions that may affect product architecture. Product team needs to pay a lot of attention to detail during product realization from its architecture. This chapter will explain these in detail, as much as it could.

9.2  Cloud SaaS Product Architecture Development Methodology

Architecture development methodology (ADM) is to put a process governing architecture development projects to get intended desired work products – the architecture of cloud SaaS product in this case.

TOGAF Version 9.1 ADM provides the umbrella process.

Adopting it and customizing it to suit product vendors’ organizations must have been preceded at the beginning of this specific project.

Adopting it further to specific project is left to product stakeholders.

Chapter 2 discusses additional points and methods. Chapter 2 provides two types of special situations encountered in architecture development project:

1. Where the probable customers are a large number of SMEs.
2. Agile architecting process is another situation where architecture needs to be developed while functional requirements are evolving; that demands architects to be more agile (rather than waiting for functional requirements to be fully collected and frozen before start of architecture development project).

Adopting the open group architecture framework (TOGAF) will give a set of architectural principles.

Adopting service-oriented architecture (SOA) RA and cloud computing reference architecture (CCRA) will give a few more architectural principles that will be useful for this class of projects also.

All relevant phases of TOGAF will be applicable to this class of architectural development projects also.

9.3  Drivers Influencing Architecture of Cloud SaaS Products

There are many factors that influence arriving at an appropriate architecture for a product:

1. Most of them come from business decisions.
2. Some of them come from the target market segment to which the product is aimed at.
3. Key drivers come from the business model of providing cloud SaaS (which is briefly discussed in Chapter 1 but that is not adequate to know the intricacies of cloud business models).
4. Also, the functionalities of the software product aimed to offer.
5. (For the purpose of this section, we highlight those that come from other sides.)
6. Cloud SaaS itself will bring a set of architecture-influencing drivers:
   1. Scalable, multi-tenant efficient and customizable (explained elaborately in Chapter 5) are important parameters that differentiate between well-architected to poorly architected SaaS product.
      1. Multi-tenancy is a challenge to architect as it demands a paradigm shift in architecting. Chapter 6 explains this characteristic in detail.
      2. Customizing is a self-service for customers, and hence it should be easy to do without any programming effort for customers.

      Notes: As discussed in Chapter 5 and illustrated in Chapter 7, ‘scalable’ in cloud SaaS architecture refers to on-demand scaling design provision (especially by horizontal scaling) to accommodate more number of simultaneous users for a given implementation architecture. This is discussed in detail in Chapter 6 and some finer details are provided.

   2. ‘Long tail’ – one possible market segment is a large number of small enterprises and also they may be small IT consumers. Their requirements are different and briefly covered in Chapter 1.
   3. A special class of ‘long tail’ is SMEs whose characteristics and the factors emanating from them for considering before architecture is discussed in Chapters 1, 2 and 7.
   4. Building a business model into a product is somewhat new for product development! And most of the hooks need to be provided in the architecture, and balance is nicely taken care if the architects chose to align with any of the CCRA. CCRA prescribes and will help architects in giving a list of aspects to be covered apart from giving a templatized architecture itself.
   5. Cloud compatibility is not zero-or-nothing proposition. Using a correct judgement of on what are all that parameters it should be more cloud compatible and what are all not important is project-/product-specific decision for architects.
7. Adapting the natural choice of SOA and CCRA will bring another set of influencers, which can be had from their respective Refs. [24, 26, 28]
8. Providing a robust ‘operational model’ that will provide SLAs both legally and financially viable is another influencing factor.
9. This book including the contents of this chapter focuses on providing information to architect cloud SaaS software. In enterprises, architects need to be more pragmatic such as consult infrastructure team on using either in-house private cloud or sometimes even utilizing public cloud.

All these factors influence the final architecture; these will also set various architectural principles that will guide subsequent realization steps of the architecture.

9.4  Characteristics Required for Cloud-SaaS-Products’ Architecture

Characteristics required for a cloud SaaS product is described in Chapter 5. Chapter 5 also discusses the characteristics as ‘requirement–solutions pair’ and that provided realization of these characteristics as well. Here, we give architectural implications.

1. Highly scalable: Highly modularized multi-tier architecture gives a natural room for auto-scaling as explained in Chapter 3.
2. Multi-tier architecture: Multi-tiered architecture that is a variation of three-tier architecture is preferred and
   1. This helps in achieving highly modularizing the functionalities that are provided to users.
   2. Such a model will help many of the SaaS users to select their needed functionality and
   3. Provider can track usage and bill only for the selected functionalities.
   4. Highly bundled function is difficult to split into fine granular level if customers demand to save their spend as explained in case study in Chapter 7.
3. N-tier or multi-tier architecture is also referred to as distributed architecture (since each tier and also constituent modules can be deployed on independent hardware servers on a distributed computing environment such as LAN or WAN).
4. All functionalities need to be exposed as a service in the functional layer of the SOA of the CCRA:
   1. Some of the functionalities may be consumed by the service providers or by service creators themselves.
   2. But those functionalities that the ultimate end-service consumer will use and pay for it is the purpose for which the product is being built. These set of functionalities can be collectively referred to as ‘payload’ (the ‘load’ that ultimately pays, and all other loads are dead loads and helps in making this one pay. The term ‘pay load’ is adopted from aeronautical industry – the passengers or cargo that brings revenue to the airline operators).
   3. (Currently, in the market some of the software vendors provide service APIs for the functionalities over the existing version of the product. Thus, it will give a look to consumers that the software is ‘service oriented’. But that is not adequate for using this software to provide SaaS through cloud. One simple and obvious reason may be that a given software may not have inherent multi-tenancy).
5. The functional layer is part of CCRA.
6. Customizable: As discussed in Chapter 5, writing a custom code is not the appropriate solution for cloud SaaS software as it is single-instance multi-user software. Instead, each customer’s customization should be recorded as metadata to configure the way the software appear and behave for themselves.

   Cloud SaaS product should have provision for end-user customization of each possible functionality of the solution.

7. Deployable on IaaS: the software product is recommended to be architected for deploying on IaaS.
8. With a strong emergence of mobile devices – such as mobile, smart phones or tablets, it is essential to consider architecting to address use of even mobile clients also. Designing data model as a service to enable mobile devices to access them is one of the examples; another one is the UI that needs to be amenable for mobile devices also. (See Refs. [31–33] for a little more details on functional requirements that come from mobile device use alone).

9.5  Selection of Basic Architecture for Cloud Compatible SaaS Product

Selection of Architecture Style

1. Conventional two-tier architecture definitely would not meet the above epectations.
2. Its extension of Web-enabled a two-tier architecture also would not fit in for this purpose: The main reason is we are looking for ‘single-instance serving multiple enterprises’. Hence, either option 1 mentioned above or any existing desktop-based or traditional client–server(two-tier) ‘Web-enabled’ application can never be made to run in a single logical instance (that too with metadata centric approach)^[5].
3. Basic architecture will be a three-tier architecture; but that needs an appropriate modification to be adopted for cloud SaaS purposes as will be explained next.
4. As scalability and performance will be a major guiding factor, a multi-tiered architecture is ideally recommended.
5. This will have an SOA approach as we are talking basically about providing SaaS where SOA is a natural choice.
6. The CCRA^[24] discusses SOA-based approach in depth (see Chapter 10), and it is built over SOA reference architecture. Therefore, by adopting CCRA makes the product automatically SOA based.
   

   Figure 9.1  A multi-tiered service oriented (distributed) architecture-schematic

7. Therefore, the selected architectural style is service oriented at the top level; and at anatomy level, the software’s architecture is multi-tiered distributed computing system. Figure 9.1 indicates the various relations here.

9.6  Starting Points for Architecting Projects

Development of architecture for cloud SaaS products requires knowledge from two important areas:

1. ADM (already covered in Section 9.2 of this chapter)
2. Technical engineering aspects

There are two starting points for technically starting the architecture development project:

1. CCRA
2. Functional requirements of cloud SaaS product that need to be developed

9.6.1  Starting from CCRA for SaaS

1. CCRA provides a templatized SOA-based architecture that is complete in all respect to offer a cloud SaaS product or solution.
2. CCRA is reviewed in Chapter 10 of this book.
3. Select all the relevant building blocks for cloud SaaS product project. For example:
   1. Architects need to decide whether to use (public) IaaS or an in-house un-virtualized hardware environment (The latter is not at all recommended.): Using (public) IaaS
      • Simplifies a lot of implementation issues, shortens development time and cost; for example, the CCMP used by IaaS can also be used for the product on implementation.
      • Also, the auto-scaling can be easily provided.
   2. Whether to have PaaS or BPaaS from other cloud service providers or not
   3. There are many more fine granular decisions too that need to be taken on going through the ABBs.
   4. What are the service provider or service creator services that need to be retained for this project?
4. Identify (‘pay load’) all services that will be exposed only to end-customers for which customers will pay-per-use; and identify those that can be accessed only for internal purposes such as with cloud SaaS provider or CCMP or by service creators.
5. Determine tools required to implement CCMP with BSS and OSS functionality; if (public) IaaS is selected, these will already be there; the same can be used while providing this specific cloud SaaS too. This is also a recommendation of CCRA, and that lessens the burden on the architectural development project.
   

   Figure 9.2  Common building blocks of CCRA (a high leve abstraction)

6. The common building blocks that are necessary to complete and launch a software product as a full-fledged SaaS in cloud can be obtained from CCRA: Figure 9.2^[25] summarizes common building blocks at a very high level of abstraction from the published BIG three’s (HP^TM, IBM^TM and Microsoft^TM) CCRA.

   Figure 9.3 gives a basic idea of major inevitable ABBs that are present in modern days software. Also the same figure shows the security layer as crosscutting ‘concern’ layer, which includes logging, authentication configuration, caching, etc.

7. Now architects need to locate SBBs meeting the selected ABBs of the finalized lists. Having now removed the worries about the paraphernalia that are required to launch a software product as cloud SaaS, let us dive into details of the main internal architecture of the product.

Figure 9.3  Architecture building blocks for modern applications

9.6.2  Starting from Functional Requirements of Cloud SaaS Product

9.6.2.1  Pre-Requisite Knowledge and Expertise

Architects will benefit from reviewing SOA reference architecture Ref. [TOGAF’s SOA RA]. That knowledge and experience is essential for architecting cloud computing solutions including architecting cloud SaaS products.

CCRA document in Ref. [24] gives a complete list of TOGAF’S SOA RA documents that an architect can consult: also Ref. [14] will be of some good use to practical architects to gain insight into how to architect products using SOA and SOA RA. Reference [16] gives a good account of taking care of security inside the product. Some brief points are touched upon on security in Chapter 11.

Understanding how to make a software as ‘server’ is another essential knowledge, since most of the times cloud SaaS will function as a server either in a solution where this plays a part as component or even in standalone services.

Understanding to develop ‘skinnable’ applications is another subject area that needs to be mastered before getting into Web tier or user interface.

A thorough evaluation and in agreement with business stakeholders to finalize the business model of providing SaaS cloud services is a key step before starting this project.

The functionalities will be grouped in ABBs.

These will be provided as a service APIs for service consumers (both internal and external consumers). It will be prepared for getting listed in the service directory.

Decide on how crosscutting functionalities/services (such as security aspect) will interact with every payload services. Guidelines are already given in CCRA, and this is the time to nail them down. For example, identify all the hook points from where a payload service will start engaging a billing service to track the functionality use. This will be later used by billing services to charge the customer as per billing policy for the customer for this specific functionality/service.

Realizing ABBs

1. The functionalities grouped into ABBs;
2. Map each ABB to SBB;
   1. Identify actual SBBs that will be either any software product or ‘engine’ or
   2. May be a custom module to be developed
   3. Sometimes, one single ABB may map to more than one SBB or vice versa too.

Deciding on inter-tier communication

In a multi-tiered SOA, it is better to keep the inter-tier or even inter-module communication as services. These services need not be registered in service registry of the product that will typically be in CCMP layer. These are just service APIs.

That provides a loose coupling between modules and any module become easily replaceable.

Replacing a faulty software module with bug fixed one is a very common requirement in cloud SaaS providing situation. Hence, avoiding hard coding of interfaces between the tiers or even critical modules is desirable. Retrieve the interface address between layers from a lookup table. There are many more techniques but recognizing the problem situation is important.

Service API can not be decided unilaterally and blindly in all cases; for example huge volume of data can not be sent through service API.

Asynchronous or completely loose-coupled interface through message exchanging can be a last option: The size of data and the speed at which it needs to be exchanged through the interface will limit the use of this mechanism. References [10–12] will give some idea about this point.

Other options available are push or pull, synchronous communication, asynchronous communication and file drop.

9.7  Distributed Applications Architecture

9.7.1  Tier-Wise Specific Points Relevant to Architecture of Cloud SaaS

This section gives further finer points about ‘hows (how it has to be) and whys (why it has to be)’ of the internal architecture of the product.

1. Functionality of SaaS product:
   1. It is better to identify as much fine-granular functions as possible; being identified as fine grained, later these can be combined to provide coarse-granular services or functions. As discussed in Chapter 7, customers will look for high flexibility to choose fine-granular functions to minimize cost.
   2. If it is a service-oriented approach, coarse-granular services can be formulated from fine-granular ones. Reference [13] will provide guidelines to formulate well-formed services from constituent fine-granular services.
   3. Collecting functionality for the entire domain is not new for product vendors; but collecting functional requirements for ‘long tail’ or SMEs – as discussed in Chapter 7 – provides new challenges.
   4. Designing every function, as much as possible, as end-user configurable is desirable.
2. Well-defined application layers: presentation, business, data access layers:
   1. Naturally develop application components in multiple tiers/layers.
   2. Presentation layer: this is conventional Web tier; but it can have a separate module to handle all possible clients; if there are any screen flow logic, then that must be separated out from tight coupling to screens presentation themselves. Appropriate workflow services can be employed even for navigating screen flows. Later, this can be easily extended by configurable plug-in for customizing screen navigation.
   3. For ubiquitous presentation – to ensure present the screens on any client – one needs a strategy to adapt ‘universal’ any (past or present or even future) clients. For some guidelines for handling conventional desktop clients with mobile devices, readers are referred to Refs. [31–33].
   4. User interface
      1. All brand-specific information should be kept separate. They should be retrieved from metadata files that are in the path similar to organization/lang id/file type/filename.
      2. On the landing page if multiple portlets are there, facility should be provided to enable/disable the portlets and rearrange the same.
      3. Facility should be provided to have two or three themes of interface with respect to menu. It should be possible to have either a ribbon menu or a menu as a left-hand pane. This should be set at a customer level.
      4. The entire user interface properties should be set through style sheets. No property should be hard coded. The style sheets can be selected specific to an organization/customer. The use of style sheet can facilitate customization of ‘look and feel’ of fonts, colour, adding customer logo, etc. These are also referred to as ‘skin’ of an application and software should be architected for ‘skinnable’.
      5. It should be possible for ‘literals’ to be modified for different customers. Ensure that the literals are available as a separate pack that can be modified for different customers/organizations.
      6. Have information for controlling the control visibility outside the page. The information on the visibility and other visual attributes of all controls in a page can be kept in a database (DB) or property file specific to an organization/customer. The page rendering will use this info for displaying the right set of controls with the right attributes.
      7. Have some additional controls available which is hidden. Based on the customer needs, this can be enabled to support for capturing/showing additional information. The enabling info is available in the DB/property file specific to a customer.
      8. UI services also need to be developed to support mobile devices such as smart phone’s or tablets; this means all needed UI functionalities also need to be provided as ‘services’ to facilitate these devices could consume them.
3. Business layer: high modularization is advised.
   1. Internal workflow within the software has to be segregated from customer workflows; business processes need to be separated out from the remaining workflows.
   2. Screen flow logic also needs to be segregated from screen logic; it is worth considering implement the screen flow through platform-based workflow module (such as in .Net).
   3. Reference [10] explains design principles on how to segregate workflows from business processes; this segregation will allow some customization of business processes to individual customers’ need.

      Certain work flows such as approval workflows can be customized without affecting main business process; even if the workflow needs to be modified for customization of business rules (as discussed below), this approach, of taking platform-based workflow (as in .Net) or workflows within software products, will be useful. Every product such as e-commerce or enterprise content management (ECM) software come with internal workflow module to design and carryout work flows specific to them that need to run internal to their products such as shopping cart to cash point exit in ecom. Such workflows can be left to those internal to those products rather than being brought to main business processes.

   4. Business rules need to be separated from the application business logic to facilitate each customer to customize as many business rules as permitted. Thinking of employing a business rules engine is advisable. (But it is desirable that the rules-engine is also a cloud compatible product.) Customization of business rules left as self-help by customers can also be facilitated through this approach.
   5. Program flow control logic should be separated from program or business logic. Consider implementing the program flow control also through platform-based workflow modules (such as in .Net).
   6. Also, separate validation logic from main business logic.
   7. Business process engine: (employing commercially available multi-tenanted BPM product is more advisable). As per CCRA’s recommendation, these need to have been exposed as service in process layer of functional layer of the CCRA. Process services can be consumed both by the internal of the product software and also by the customer (cloud SaaS service consumer). But there is no need for employing two different products – one for workflow and the other for BPM.
      • Customers will heavily customize the business processes while initially setting up use of cloud SaaS and also later. For example, one subscribing customer would like their sales personnel to get his/her sales managers approval before confirming an order, whereas another subscribing organization would like their sales personal to confirm an order without such procedure but get approval from stocks manager to ensure that the order can be full filled.
   8. Integration server: the role of integration server is to integrate all the components in this layer and also those including the third-party tools that may be used. This component is not common in earlier architectures.
   9. Communication server: it has become common to provide many communication provisions with customers – email is one obvious example; fax has not yet died; also business processes are communication enabled with audio–video-text kind of software and SMS think these functional blocks as a part of architecture is advisable. An extreme example is illustrated in Figure 9.4 where a complete unified communication module is presented.
   10. Business logic: Extension requirements to solutions need not be cosmetic alone. There will be various situations where certain additional validations need to be added to the business logic or other requirements such as doing additional postings on successful completion of a particular transaction. Hence, have callouts on different transactions to support these types of specific changes, have specific callouts at end of transaction for terminal actions of each page such as ‘save document’, etc.
   11. Wherever business functionality is required to be configurable, go for engines. For example, have a tax engine to handle tax or pricing engine for pricing purposes.
   12. Business tier should be designed as a ‘server’.
4. Data tier: There can be three different modules or sub-tiers or better called as components under data tier.
   1. Data access objects (DAOs)
   2. Relational database management system: DB
   3. Data storage
      1. Encapsulate access to DB, and this is a general technique.
      2. Cash data on server and/or client for improved performance.
         

         Figure 9.4  Unified communication

      3. For DB design or data models, please refer to Chapter 5 for details.
      4. DB design: database implementation
         • All tables in the DB have to be horizontally partitioned with the organization id as one of the primary keys. (One reason for horizontal partitioning is to anticipate a larger number of rows than usual single-enterprise solutions.) All the tables will have a column for the organization ID.
         • All joins will have to ensure that all the organization IDs are same for all the tables participating in a join.
         • Wherever possible, it is better to have separate DB instances for different customers groups.
         • We need to ensure that the DB connectivity from app server is obtained from property files/DB depending on the organization.
         • See Chapter 5 for a detailed discussion on three different data models that can be choosen for cloud SaaS. Choose the appropriate one for the product.
         • For all data access operations, employ all techniques to maximize concurrency – This can be optimal utilization of connection to DB (as pooling them and ‘acquire or release’ connections from pool), or unless absolutely necessary do not lock record in DBs such as read operations.
5. Closed architecture

   ‘Closed architecture’ indicates that modules in a tier can call other modules in the same tiers or modules in one layer above or below; but cress-cross calling jumping across layers need to be completely avoided.

6. Loosely coupled layers

   The inter-layer calls and inter-module calls should be highly loose coupled or precisely service oriented. This helps in on-the-fly replacement of defective modules with corrected ones (there are other methods available to replace defective module as discussed later in this chapter and also see Chapter 5), also to implement security as ‘aspect’.

7. Incorporate failover and redundancy for disaster recovery (DR).
8. Wrapping of third-party products and components: It is better to choose third-party tools where the development team can have a direct access to their source codes and can have rights to modify them. Tucking them as proper SBB and wrapping it in the designated layer with custom wrapper is advised. Custom wrapper and accessing products’ functionalities through loose-coupled interface will help in replacing or maintenance situations.
9. Reports
   1. Use a basic reporting engine and report creator for generating reports.
   2. Reports should be available at different levels, to all the organizations.
   3. The report menu will be populated based on this mapping.
   4. Considering specialized products for report generation is also good, if the customer expectation is high. Expecting a multi-tenanted product will limit the choice of available reporting product to choose from since not many are multi-tenanted. Most of SMEs customers or customers from ‘long tail’ may also demand two extreme expectation on customization of reports, which has a lot of practical limitation to architect or implement. DB also should permit enough customization (as discussed in Chapter 5) to support certain type of reports requested.
   5. Architects need to identify through evaluation process cloud compatible scalable reporting engine.

9.7.2  Architecting to Scale the Application

Scaling is possible in two ways: one is known as ‘scaling vertically’ and another is known as ‘scaling horizontally’ (see Chapters 3 and 4 for some detailed discussions on scaling).

Scaling vertically refers to have more processing power such as higher speed processor (CPUs) or adding more processors to the same server; in addition or alone adding more main memory. Essentially, this means going for higher performing hardware. This is also referred in literatures^[5] as ‘scaling up’.

Scaling horizontally is adding more servers of same processor speed and memory; these hardware work in a cluster under a load balancer; and in these additional servers, additional components of software will function in parallel. This is also referred to as ‘scaling out’. Scaling out can be achieved through on-demand provisioning of additional servers as explained in Chapter 3.

In cloud SaaS software, scaling horizontally (scaling out) is what is mostly preferred as discussed in Chapter 4. Cloud SaaS software should scale out (horizontally) with a priori (arbitrary) number of servers; each of the servers have one or more instance of the application or its components to accommodate any arbitrary number of users.

Apart from architecting the SaaS application as highly modularized and tiered to allow scaling of each of these independently, as discussed in Chapter 4, the internals of the application need to be specifically designed and implemented with some more of the following points, in addition to other points discussed earlier in this chapter. A detailed discussion of these topics need a separate book. The following provides some finer details that can be used in the software design:

1. In a horizontal scaling (or scale out) means, many instances of the same software are luckily to run in the operations. To take advantage of this, the product should be in a position to move around transactions to any available instance. This can occur many a times even during a single transaction. Transactions should be totally unaware of the fact that it is being moved around to various instances. A software behaving in this fashion is said to be ‘statelessness.’
2. To achieve a software to function in a ‘stateless’ fashion, many more aspect has to be taken care of. One of them is to store user data on client side so that any instance can access it and use it rather than storing it on server side (in Web tier).
3. In case ‘state’ is stored in the Web layer, it is better to go for affinity-based access. Do not store session info in the app server.
4. Technique of ‘pool’ing has to be adopted both for optimizing computing resources and also collect metrics on their usage for resources such as DB connections, threads or even network connections.
5. A common age-old technique of handling I/O asynchronously will help in freeing resources for useful work till the slow I/O operation is complete.
6. It should be possible to add new access elements specific to customer for supporting access authorization specific to an organization or customer. Details are discussed in a separate section below named ‘identity and access management (IAM)’.
7. For horizontal scaling, the tier/component model expressed in earlier chapters is a key consideration.

(x) Architecting for maintenance

Maintainability is one of the key attributes for this architecture:

1. Most of the cloud SaaS offering is 24×7 in use.
2. Single instance is used by multiple customers.
3. Many things including customization are left to self-service of users/customers.
4. Any one customer may bring down the system, or any one of the components such as DB may bring down the whole system due to ‘illegal operations’.

   Hence, the system is highly vulnerable for going down.

5. System cannot be stopped for maintenance or upgrades or for applying patches, but they are inevitable operations.
   1. Normally, a redundant site is used for upgrading and regular maintenance; at one time when the upgrades are ready, the Web server will point out the new server in a blink of moment.
   2. High modularization and multi-tiered approach will give flexibility to upgrade at individual component level.
   3. There are specific discussion about DB design and recovery in multi-tenant situation elsewhere in this book.
6. Designing DB for roll-back or recovery, especially when a single customer has crashed the DB, is an important aspect. Some of them are touched upon in Section 5.7.
7. Fault isolation is another important aspect in the architecture design: fault of one customer should not bring down or crash the entire cloud SaaS software. If a fault occurs because of one customer, then that customer should be isolated and can terminate the specific customer.
8. An enterprise-scale architecture needs to include DR plan as well as business continuity plan in the overall design. As the concepts for these are simple extrapolation of what is being currently practised for non-cloud solutions. However, these are specialized area, and it is not covered here.

9.7.3  Service Orientation of Entire Product Architecture

The entire cloud SaaS product architecture is SOA. Chapter 10 discusses this point a little more elaborately using cloud reference architecture.

Providing only service APIs for non-SOA products cannot be counted as ‘service-oriented architecture’ as discussed in Chapter 6.

Figure 9.1 is a unique contribution of this book, which clearly explains the integration of service-oriented + multilayered + distributed architecture that is essential for cloud SaaS software.

Having said the same, this book will not introduce SOA or attempt to go into any detail of SOA. References [14–16] will help a lot.

Important points on service orientations that are essential for cloud SaaS software are highlighted below:

Inter-module or inter-tier communication will be strictly service oriented and not conventional tight coupled. If a very loose coupling is desired, then message oriented-service interface can be thought of as design option. Queuing techniques need to be incorporated to architecture as queuing is inevitable for handling messages.

A large volume of data cannot be sent through service interfaces. This is one of the restrictions of service interfaces. Therefore, other methods need to be exploited.

Use of appropriate service protocols either SOAP or REST depends on the nature of the interface whether the communication across the interface be asynchronous or synchronous, respectively.

Obviously, all these services are not relevant for end–users, and hence these will not be exposed to end-users.

Service orientation has another weakness of security. Reference [16] gives a detailed method to secure service interfaces and access even at module level.

9.8  Identity and Access Management

Most of the products in the market give two options for system integrators who will make a solution using the product:

1. Access enterprise IAM and provide a role-based authentication.
2. Inside the product have features to set role-based authorization; it can sync up with enterprise IAM for user management.

   Such an approach is not suitable in a multi-tenanted environment; many of the popular ECM products, in the market, have these kinds of facilities, which is a huge limitation while architecting cloud solutions using these products.

   Ideally, a product dynamically, on-the-fly should be in a position to get authorization and authentication for every logged-in user before entering into every function or service of the product.

   Therefore, IAM can be a separate module; it can be made to work with customer’s enterprise IAM too.

   One is user identity and the other is role-based authorization for feature access. In many cloud SaaS service consumption, customers also desire to define their own roles and assign access rights to various SaaS features – which makes implementation more complex. Sometimes, business rules also may control access to features.

   For a further discussion on this topic, readers should refer to Refs. [5, 16]

   IAM is the main entry point for any user to get in to consume the services offered. Thus, IAM, being the main entry gateway in, can be connected to rest of the solution through a ‘trusted mode’.

   A connection between two servers are said to be trusted on fulfilling conditions such as the following (see Figure 9.5):

3. The product assumes that any call that comes from IAM can always be trusted.
4. Both IAM server and the product servers are under a fire wall, and hence no intrusion is possible.
5. IAM can provide a token on authorization and a separate one for authentication. This token is carried into the product, and the product uses this for verification before entertaining the requested service at any level and every time. (Token based is one of the many possible approaches).

Figure 9.5  IAM and cloud SaaS product are connectedly ‘trusted mode’

9.9  Transaction-less vs Transaction-intensive Products

The subject product for which architecture needs to be developed grossly influences the intricacies and difficulties of developing an architecture for it. These difficulties are at gross levels of the nature of the product.

This book classifies products, for this purpose, into two categories:

1. Transaction-less software product
2. Transaction-intensive software product

ECM software such as Alfresco is considered transaction-less software. The term ‘transaction-less’ need to be understood as ‘transaction nil’. An ECM software stores or retrieves a file for the user.

(Contrast this with a banking software that allows a user to transfer the money from one account to another. Such a transaction needs double commits, and there is a unit of action and a facility for roll back. A relational DB software is another extreme example for transaction-intensive software).

The experience gained thus far indicates architecting a multi-tenanted product of transaction-less product is several orders easier than the other one.

9.10  Efficient Multi-tenancy

There is no universally accepted measure for ‘efficiency’ of multi-tenancy. The simplest guiding factor is how many of users can be served by the cloud SaaS in a unit hardware infrastructure.

This is a relative measure rather than an absolute one. This means comparing two situations for same hardware configuration:

1. One cloud SaaS solution can serve 50 users.
2. Another cloud SaaS solution can serve 100 users.

The second one is more efficient compared with the first. Such a measure is not practical because there can be no two solutions having the same deployment (unit) architecture.

Therefore, the basic question of efficiency is how many more users can be packed into a given set of deployment architecture and infrastructure software.

As discussed in Chapters 4 and 7, each module will require different hardware configuration; also, each module will inherently differ in packing maximum number of users per unit hardware instance. Hence, continuously finding ways to improve the number of users at module level is inevitable point in cloud SaaS architecting exercise.

9.11  Infrastructure Softwares’ Architectures for SaaS Solutions

A cloud SaaS product relies on several infrastructure software during runtime. Some obvious ones are operating system, application servers, middlewares and DB software. If these are also multi-tenanted, then it is an ideal situation. As of now, not many in the stack are available in the multi-tenanted form. The most critical of these is relational DB; thank God, we now have both COTS and open-source cloud-ready RDBMS, and these are in use for a year or more now.

If the subject of software product, say an app server or RDBMS, needs to be made cloud compatible, then the problem is much more complex. All the knowledge mentioned here are required and much more too; nevertheless, that will be a delightful project to be in.

The main reason for these need to be multi-tenanted are economy of scaling, efficient resource utilization by sharing and hence metering for pay-per-use for every user. Right now, such platforms are emerging.

Review of some of even publically available product architectures will be of high use to architects who take on cloud SaaS product architecture assignment:

1. High availability architecture of Oracle WebLogic
2. The open-source and ECM software Alfresco
3. Multi-tenanted RDBMS architecture
4. Discussions on architecture of multi-tenanted middleware

9.12  Deployment Architecture Basics for Cloud SaaS Products

Multi-tiered distributed service-oriented cloud compatible CCRA-based cloud SaaS product provides a natural deployment architecture. It is highly scalable architecture. (Compare discussions in Chapters 4 and 7)

1. Each tier can be on a single hardware server.
2. Major components or modules also can be on individual servers.
3. CCMP in CCRA provides a lot other components each of which also can go on individual servers.
4. The configuration of each server would have been calculated as per packing efficiency of multiple tenants in a minimum given configuration for each module/tier/product/engines. For further details on this aspect, refer to Chapters 4 and 7.
5. The remaining steps will be exactly like the one mentioned in Chapter 7 for auto-scaling and auto-provisioning.
6. It is recommended to choose IaaS as the deployment environment.
7. Public IaaS provides a lot of OSS and BSS facilities that are required for providing cloud SaaS.

9.13  Future Direction

On software product vendors coming up with cloud compatible software products, it opens a lot of market opportunities for them: Unfortunately on the other hand, if the vendors could get completely cloud compatible software products, they will tend to offer more the product as cloud SaaS services or solutions rather than offering them as software product.

The interesting new possibility is to offer them as cloud SaaS or its functionalities as cloud services. (This can be in addition to selling them as a product itself in a conventional way in conventional or any market). This may open out a set of new market and revenue for the product vendors.

In this new possibility, system integrators, architecting cloud SaaS solutions, will face new challenges. The bunch of functionalities (provided by the product) is then available as cloud services or cloud SaaS and not as a product. Integrating these into an overall (cloud SaaS) solution is the key technical concern and the challenge is securing. Also, integration is taking cloud services and not necessarily taking products. Architecting solutions all involving cloud services is different in nature and not covered in this book in this edition.

9.14  Summary

• This chapter gives a lot of technical points for architecting absolutely cloud compatible software products.
• The starting point is CCRA.
• It recommends the product need to have SOA.
• The product will have highly scalable multi-tiered distributed architecture.
• For each of the tiers – Web tier, business tier and data tier, this chapter gives a lot of points that need to be taken into consideration while designing those tiers.
• It gives reasonable explanations how cloud SaaS characteristics such as customizing and multi-tenancy, scaling, etc., need to be implemented while architecting the product.
• Certain clues on architecting for maintainability are provided.
• It also provides some connecting explanations on infrastructure architecture, connecting IAM while solutioning are touched upon.