Chapter 4

Architecting Software Solutions for Public IaaS Cloud (without SaaS)

4.1  Introduction

How to architect software or solutions (leave alone ‘cloud’) itself is an interesting topic for discussions. References [21, 22] discuss methods of architecting software. This knowledge is essential and fundamental to architecting solutions or products. These details are not repeated here; and conveniently, it is assumed that readers will be familiar with the contents in those references Such an assumption is essential to focus on the intent of this book.

Reference [20] discusses how the cloud pushed the frontiers of architecting software or solutions. Chapter 3 discusses elaborately the conceptual view of Infrastructure as a Service (IaaS) that is good enough for an architect. In future, all softwares will be deployed only on IaaS.

This chapter illustrates how to architect software for IaaS. This is simple and straightforward. Although the complexity of knowledge required for this is low, this information of how to architect solution for deployment in cloud IaaS is provided in this chapter. Many novice solutions architects expressed need for this simple information.

Primarily, solution software will be deployed in public (or private) IaaS. Irrespective of the fact whether solution software need or need not serve multiple tenants as in cloud software as a service (SaaS) solution, the architect needs to follow steps mentioned here for deploying solution software on IaaS.

In future, all softwares will be deployed only on IaaS – be it private or public, be it for single tenant as dedicated system or for multiple tenants as in cloud SaaS. Therefore, learning to architect solutions to deploy on IaaS is inevitably the first major step.

The steps involved in the method discussed in this chapter to architect these solutions will anyhow be required to architect cloud SaaS solutions that will be discussed in Chapters 7, 8 and 9. This method is illustrated through a case study.

4.2  The Method in Brief

Reference [17] discusses how to architect solutions when there are no requirements available upfront from customers. Chapter 2 has a relevant extract of the same.

References [32, 33] explain the context, usefulness and applicability of the solutions used as case study in this chapter.

Proceed from requirements until you (architect) complete architecting solution as usual. There is no big change in steps until this point is reached or this deliverable is made ready in solution architecting project. Reference [4] will be of some use in detailing steps involved in this part of architecting. References [21, 22] are absolutely very good resources for architecting solutions. Chapter 9 will be useful if the solution is cloud SaaS solution. (The case study presented here enumerates some of these steps too.)

At the end of solutioning phase, architects would have identified solution building blocks (SBBs). Some SBBs may be software product/s, and some SBBs may require custom development.

Architecting for IaaS starts with deployment architecture development and its implementation structure. To be ready for this step, the architect needs to analyse all SBBs thoroughly and come up with implementation hardware and other infrastructure software requirements for each of them.

4.2.1  Identifying Minimum Deployment Hardware Configuration for each SBB

1. Each SBB will have, in itself, many tiers: Web tier, business tier, data tier, etc. For each tier, the architect needs to collect the minimum deployment hardware configuration and deployment architecture.
2. In addition, it is essential to collect information on minimum online and concurrent users for the specified minimum deployment configuration for each of the modules of every SBB. This in turn will be used to determine minimum deployment architecture configuration to be prescribed or arrived at for each of the building blocks.
3. For deploying each product, respective product vendor would have specified minimum configuration of infrastructures required to deploy for each of the tiers.
4. Some product vendors give hardware requirement calculators; this can be used by architects to calculate the configuration of the hardware required for each tier of the product for a prescribed minimum login users and concurrent users.
5. Sometimes, product vendors would specify directly the number of users their recommended minimum-hardware configuration can handle.
6. Most of the product vendors provide calculators to arrive at final deployment hardware configuration for peak loads – this is of no use for cloud SaaS solution; the architect needs to look for minimum configuration and also the number of users the minimum configuration can entertain with agreeable user-response time.
7. Architects should avoid very trivial configuration of putting in a single box of minimum configuration all the tiers and infrastructure software required for any COTS or software products. One minimum configuration for each – scalable – tier and one each for every single-infrastructure product.
8. For custom-built modules, architects need to specify deployment architecture for each of the tiers. This is again minimum configuration, and architects need to document minimum number of users for the minimum configuration.
9. The basic reason for specifying the above steps is to apply scalability algorithms for each of the tiers or modules of the SBBs involved at a fine granular level of each tier or module of each SBB.

4.2.2  Calculating IaaS Infrastructure Configuration

1. Map each (minimum configuration) unit hardware into ideal instances in the catalogue of IaaS infrastructure service provider.
2. Select necessary support services and also note down their one-time, initial, annual or recurring cost. Most of the time, these costs are not pay-per-use types.
3. For selecting an IaaS service provider from a list of probable service providers (assuming that their technical capabilities will meet the requirement for the solution), the above steps need to be repeated for every vendor being evaluated. These costs, along with pay-per-use costs, will help in deciding the final public IaaS vendor. There may be many more criteria such as legal protection to the cloud SaaS software and customer data that the IaaS provider may offer. Such facilities may also play a part in selecting the vendor. (Discussion of legal aspects to select public IaaS provider is out of scope for this book.)

   After finalizing IaaS service provider,

4. Arrive at scaling algorithm when implemented in the target IaaS platform. This will help the solution to scale-up on demand as well as scale down during off-peak demands. (Chapter 7 illustrates with a case study how to arrive at scaling algorithm).

These steps are the only difference in specifying IaaS as part of solution from conventional deployment architecture calculations.

Now we will study how these steps are applied through a case study.

4.3  Digital Communication Platform

For various perspectives of this case study, please refer to Refs. [32, 33]. The following is a case discussed in detail.

System Requirements

Customer wants to have a digital communication platform. This may comprise a website (content management system) that is mobile-enabled with social media interaction for the following three phases of a sports event:

1. Pre-event
2. During the event
3. Post-event
   1. The ‘digital communication platform’ will have website accessible by desktop clients, mobile clients and will have ubiquitous access.
   2. It will have two gateways to open free popular social media: One is to publish about the events in those media and the other is to collect what people are talking in those media about the event to take corrective action.
   3. Conventional push technologies such as email and SMS will be required.
   4. The user community will be general public, sports fans, participating athletics, event officials, media persons and many more types. The platform will also provide as many of the features on mobile clients too.
   5. Apart from fans, there are other important stakeholders such as athletes, coaches, media partners, fan clubs, retail advertisers, etc., whose needs must be catered to before, during and after the event.
   6. It should also provide many means to promote the event.

Website

1. Requirements from athletics associations: the website should follow certain statutory principles prescribed by governing sporting bodies in that geographic region.
2. Mobile site content should be accessible via iOS and android mobile devices. (Other operating systems are of lesser priority.)
3. Leverage in advance software engineering practices in the areas of mobile and cloud computing for the event.
4. Syndication and aggregation of news feeds and support for Web services.
5. Support for special features, graphics and contents as per guidelines provided by the customer.
6. Web stats: It is imperative that each customer department be able to effectively review, analyse and audit the usage of their extranet. Administrators and Web masters should also be able to review how various extranets and intranets are being used and increase content effectiveness.
7. Time visitor traffic and their flow through the site.
8. Search engine optimized (SEO) design of website in a way that it will appear higher in search engine rankings.
9. Search functionality: Search is the core functionality in any website/portal implementation.
10. Live streaming and post-event streaming of events videos.
11. High-quality hardware platform and state-of-the-art hosting infrastructure that is highly scalable and available to be provided by vendor.

Mobile Apps

1. Requirement of mobile apps for ticketing, photo gallery and video streaming for the event.
2. Accessibility of calendar and news page through mobile apps.
3. Accessibility of accreditation documents (PDFs) through mobile apps.
4. Live video streaming (of any such events) should be viewable through mobile app.
5. Accessibility to stadium or venue information through mobile apps.
6. Rating of the contents of site through mobile apps.

Social Media

1. Increased buzz about the event in the relevant public domain, leading to increased ticket/merchandise sales.
2. Creation of long-term relationship with the fans that can be leveraged for post-event activities and brand-building.
3. By providing timely information over internet. Increase patronage of fans who are not physically present during the event (because of timely information provided to them through the games website).
4. Creation of referenceable information database that can be re-used for similar events conducted by the customer.

Social media solution is suggested in three innovative buckets:

1. Collaboration platform - This platform is within the customer official event site (where different users can engage on discussion forums, blogs, community discussions, photo sharing, etc.).
2. Listening platform - This platform would allow for the customer to listen to social messages that are of relevance.
3. Broadcasting platform - This platform will serve the following two purposes:
   1. To act on insights generated by listening platform selectively in wallpost/tweet on a particular social profile that might be ‘detracting’ the customer brand.
   2. To proactively reach out to audiences through targeted communications on events, merchandise, calendar, giveaways, etc.

4.4  Approach to Realization

Functional Architecture

Following is the solution in nutshell for the customer to support the sports event.

Proposed functional architecture description: The following explains the functional architecture of the solution using Figure 4.1.

1. It has various functional modules: user management, content management server (CMS), event management (including ticketing), media management, doc management, Web analytics, messaging, social media, general (widgets management, accreditation).
2. The platform has a website for desktop clients, and it also includes a mobile access to the same.
3. Web content management (w)CMS server serves as the heart of the solution. This has both Web content database and a separate mobile content database.
4. To this a listening platform, such as Radian6, is attached which fetches the customers’ comments from the open social media such as Facebook™ or Twitter™.
5. Analytics functionalities are available – say custom-built sentiment analytics as well cloud service based – and helps analyse the comments of the customers and infer the overall feedback from sports enthusiasts and fans. Each stakeholder department can get analytics of their interest area.
   

   Figure 4.1  Functional architecture with architectural building blocks derived from grouped requirements of the solution

6. In addition, the solution provides a separate and exclusively created ‘enterprise social media’ for customers to chat, blog or comment or, in general, express themselves or exchange views and points among various stakeholders of this event. This can be organized to provide customer-helping-customer both during post- and pre-events. Also at the back-end, analytics can be run on this to understand the sentiments that are running about the event.
7. Broadcaster service is (unlike RSS feed) to make regular announcements by the events organizers in popular pre-configured social media.
8. Of course e-commerce server delivers requests from both desktop clients and mobile clients. Hence, it scales up with specific functionalities to serve as mobile-commerce (m-commerce) too.
9. Payment gateway is a component that must already exist in any e-commerce solution.
10. Please notice that there are specific technical software components for deducting mobile devices when the site is accessed from a mobile device. In addition, one can entertain dedicated mobile apps through a separate server.
11. Please notice location services that will add ‘spice’ to mobile contents in the form of location-aware content delivery.
12. In order to increase the communication mechanism – conventional SMS, FAX and email servers are included.
13. In addition, the solution has envisaged various mobile applications for various groups of users and has corresponding applications for each user group.
14. Video can be one of the inputs through this platform. Pre-recorded videos can come from popular video sites such as YouTube, or it can come from fans or it can be a live one too.
15. Video live streaming, from archival and also from open free public external sources, is provisioned.
16. Tools and platform
    1. COTS products such as (w)CMS server and CMS as explained in the diagram;
    2. .Net will be the main platform and will also be integration platform;
    3. Cloud-based SaaS solutions such as Radian6 and Google™ analytics;
    4. Some open sources to keep the cost under control such as WURFL;
    5. Entire infrastructure platform is on private cloud to ensure safety and security at the same time only on pay-per-use cost advantage.
17. Ticket booking/ticket status reporting through mobile apps.
18. ‘My interest’ feature – allows users/participants to jump into areas of his/her interest.

    Customization

19. Private secured cloud-based IaaS solution cost – effective, pay-as-you-go model and highly scalable hardware infrastructure.

    Integration of Subsystems

20. Communication including instant messaging (IM) via Smartphone (provide this feature through mobile app).
21. Event promotion through broadcaster/event manager/Web channel.
22. Live video streaming, Recording/Past Events Video streaming, links to open sources of video.
23. Web Content Management Systems ((w)CMS) server supports multiple file formats and also allows metadata associated with these various file formats to be uploaded into (w)CMS server. (w)CMS server will need to be integrated with a video streaming server for rendering multimedia content. Graphical/animation can be easily shown from (w)CMS server in mainly three ways – through a (w)CMS server data factory Web service (basic Web service), by calling (w)CMS server pages directly that output XML/HTML data to read/render and by outputting the data directly on the page integration with social media.
24. Integrated with many popular public social media.
25. Solution also provides exclusive enterprise social media within the digital communication platform for various user groups to collaborate.
26. Easily configurable workflow for approving contents/approving contents that need to be published in social media.

    Integration with External Systems

27. Listening platform is cloud-based (Radian 6), and hence is very cost effective and follows pay-as-you-go model.
28. All data communication in the form of restful services enables seamless integration between cloud, mobile apps and partner’s (other vendors and stakeholders home grown) apps or systems.

4.5  Realization of the Envisaged Solution Architecture

Table 4.1 summarizes various software products (or technologies such as .Net) and meets the functional modules mentioned in previous section. (The grouping of functional capabilities can be roughly considered as architectural building blocks (ABB).)

Table 4.1  Indicates realization of envisaged architecture by indicating what functional group will be realized by (finalized or selected) software products

Note: In the above illustration, the Web server and app server are assumed to be in the same physical box.

The recommended (w)CMS Server solution comes bundled with (w)CMS Trace/Google™ analytics. The (w)CMS Server-based framework is also compatible with other Web analytics and reporting tools such as Web trends, Surf Aid and Hitbox. Raw data related to website usage and tracking is saved in log files, a bespoke reporting module can be built to review and analyse the usage of various intranets and extranets.

The use of (w)CMS Server Relate+, which offers a rich set of features (such as blogs, discussions, forums, bulletin boards, etc.), is necessary for creating social media and collaboration platform.

Figure 4.2 gives a pictorial view of the solution products finalized, and tabulated in Table 4.1, for each of the modules. (Reference [6] is international grade, which provides guidelines to what are all views of architecture can be provided. However, the architecture views provided, in this chapter or in the entire book, are not checked for its compliance with the benchmarks.)

Figure 4.2  Mapping SBBs into ABBs: selection of software solution products that can match ABBs

4.6  Architectural Considerations

Description: Refer Figure 4.3 also for physical deployment architecture.

1. The above view depicts the physical view of the proposed system.
2. The users will be screened through the protocol firewall.
3. Based on some of the non-functional requirements regarding number of concurrent users and active users, the recommended practice is to deploy all these servers as clusters in a federated environment. The server capacity may be for forecasted peak loads.
   

   Figure 4.3  Physical deployment architecture

   (For cloud IaaS, it is recommended to obtain the details of minimum configuration and the number of users or load it can handle; then as and when the load increases through an auto-scaling algorithm, additional servers will be automatically provisioned. See Chapter 7 for an illustrated explanation of this.)

   For solutions such as sports events, which last for a few days, or maximum a few weeks, the organizers prefer using maximum estimated load as default hardware size.

   For events such as this, it is better to go for maximum load approach; after the event, the load will drastically drop down, and hence it can be brought to highly shrinked architecture to save the cost. The same is illustrated here too. See the spreadsheet ‘capacity’ for it.

   Auto-scaling is essential when the load surges beyond the estimated maximum load. Also some of the modules may face high load, depends on the features used by users, even though the overall load is well under max load for the system.

4. In a federated environment (as depicted here), Web requests are routed to corresponding Web server cluster through the load balancer.
5. Once user-credential validation process is successful, access to the Windows 2008 server, where IIS application server is loaded, would be available. (w)CMS server along with the extension software would be installed in this server.
6. This solution would make use of mail server that will facilitate all the email-related requirements. Please note that the mail server is an open-source product.
7. An FTP server is also recommended. This FTP server will be used for sharing information such as video/audio between external customer drives. In addition, this would be useful in storage of video/audio, images and document files that need to be archived in the file system instead of database.
8. The SQL server database cluster will be housed in a separate Windows 2008 server across a firewall. For disaster-recovery (D-R) purposes, these clusters are typically housed inside a highly secured data centre.

In the above diagram, all servers will be in clusters under load balancers (application servers and database) will scale on demand as it is undervirtualized (private cloud or public IaaS) environment.

4.7  Mapping Deployment Architecture into Public IaaS Cloud

The steps required for this is already explained in Section 4.2.

Disclaimers

1. The cost indicated are tentative and illustrative but does not reflect the actual cost taken from AWS.
2. AWS itself provides a cost calculator.
   
   
3. AWS of Amazon^TM is used as an illustration; AWS is taken up as illustration as it also supports Windows and .Net in their IaaS infrastructure. Since the terms such as ‘large’, ‘medium’ referring to ideal server sizes are very pertinent to AWS.

Explanations for the spreadsheets:

First sheet to be studied is titled as ‘topology’: This explains how a virtual private cloud is created within public IaaS; and the same is accessed from a remote developer LAN for developing and dumping the developed or maintained code into the IaaS.

The diagram did not show how users would access the system; it is through cloud from their devices.

Second sheet to be studied is titled ‘availability’: This indicates for how long the individual servers are required for the project.

1. Some of the servers are required for development purposes; therefore, they need to be available well ahead of the event date.
2. Some of them are required only during and post-event period.
3. This sort of information should be collected during system study and development.
4. The availability information is carried into cost calculation in next sheet to be studied and titled ‘IaaS cost calculation’.

Third sheet to be studied is ‘IaaS cost calculation’:

1. This is the sheet where deployment servers are mapped on to IaaS ideal server sizes (see Table 4.1).
2. This sheet also gives the operating system or other infrastructures that are required for each server and hence, each corresponding instance in the IaaS. The cost of infrastructure software is also usually on pay-per-use model from IaaS providers.
3. There is a fixed one-time cost and there is a pay-per-use cost.
4. The cost indicated here is an estimated cost and not actual cost; actual cost will be pay-per-use plus the one-time cost.
5. Readers ’ attention is drawn to the details one needs to have as estimate before calculating the cost; these details are data storage requirement, bandwidth requirements, etc.

4.8  Summary

• The main objective of this chapter is to illustrate how to arrive at a deployment architecture suitable to map a public IaaS.
• In addition, this chapter provided details of mapping a deployment architecture to public IaaS.
• One can also learn how to move from requirements to ABBs and then to identify corresponding SBBs.
• A detailed calculation of cost of IaaS is provided.