Introduction to Cloud Computing. Lecture 02 History of Enterprise Computing Kaya Oğuz

Transcription

1 Introduction to Cloud Computing Lecture 02 History of Enterprise Computing Kaya Oğuz

2 General Course Information The textbook: Enterprise Cloud Computing by Gautam Shroff (available at bookstore). Course evaluation: One project with Google App Engine 30% One midterm 30% One final 40% Syllabus: will probably be updated until next week; but...

3 General view of topics History of enterprise computing architectures Major cloud platforms Cloud computing economics Key technologies for cloud computing New programming models and development paradigms for the cloud. The impact of cloud computing on enterprise computing Developing cloud applications on Google App Engine

4 Enterprise Computing Enterprise computing: the use of computers for data processing in large organisations (IS, IT). Begins in 1960s with early mainframe computers. Over the years paradigms changed with new technologies (PCs, internet, e-commerce, finally the cloud). With these advances enterprise systems have increased in complexity and consequently in cost.

5 Key Elements of Cloud Computing Computing resources packaged as a commodity and made available over the internet. The ability for end-users to rapidly provision the resources they need. A pricing model that charges consumers only for those cloud resources they actually use.

6 Consequences of the cloud Not surprisingly, much of the interest in cloud computing today is based on expectations of such cost savings. The concentration of massive clusters of computing resources within cloud providers open up possibilities for large-scale data analysis. A number of new programming models and development tools have been developed to enable large-scale computations and to improve software development productivity.

7 Mainframe Architecture A typical mainframe architecture. A terminal based user interface would display screens controlled by the mainframe server using the virtual telecommunications access method (VTAM) for entering and viewing information. Terminals communicated with the mainframe using the systems network architecture (SNA) (not TCP/IP)

8 Mainframe Architecture (2) While mainframe computers had limited CPU power, their I/O bandwidth was (and is) generous. In early mainframe architectures, application data was stored either in structured files or in databased systems based on hierarchical or networked data model (not relational until mid 80s) (Required Transaction-Processing Monitors). Mainframes also pioneered the large-scale use of virtual machine technology. Many design features of the mainframe era are now hallmarks of today's cloud computing world.

9 Client-Server Architecture The microprocessor revolution of 80s brought PCs to desktops and homes. It was conceivable to move some data processing tasks away from the expensive mainframes to exploit seemingly powerful and inexpensive desktop CPUs. 'Forms' architecture involved use of terminals to access server-side logic in C, later with GUIs, instead of CUIs. Significant processing logic started to get executed in a client application: the 'fat-client'. The client app makes direct calls to relational database. Business logic largely resides within the client some business logic can be implemented within database for faster performance.

10 Client-Server Architecture (2)

11 Client-Server: Downfall Client-server architecture soon began to exhibit its limitations as its usage grew beyond a small group. Since processing logic on the client directly accessed the database layer, many bulky requests are made to the server. It also became clear over time that application maintenance was costlier when user interface and business logic code was intermixed. Lastly, client server model did not scale.

12 3-Tier Architecture Unlike the mainframe, the client-server architectures had no virtual machine layer or job control systems to control access to limited resources (CPU and disk). Transaction-processing (TP) monitors redeveloped to solve this problem for midrange database servers. First examples of middleware which sat between the client and a database server to manage access to scarce server resources, essentially by queuing client requests. In a TP monitor arch, the requests being queued were services implementing business logic and database operations.

13 Middleware: I'm lovin' it!

14 3-Tier Architecture (2) Services encoded business logic. Client applications are purely user interface management and behaviour. Such applications turned out to be far easier to maintain than the fat client applications. The TP monitor became the 3-tier architectural model, where client, business and data layers are clearly separated and often reside on separate machines.

15 Essential lessons from 3-tier Clear separation of user interface and business logic Load balancing using request queuing to support high transaction volumes. Both of these have become fundamental principles of enterprise software architecture design. 3-tier model never disappeared and has become an integral aspect of web-based computing using the internet standards. Make sure you check Table 1.1 on page 14 for a comparison of these architectures.

16 Internet and Web Applications Internet born in 1990 with the development of HTTP protocol and HTML at CERN by Tim Berners Lee. Using a browser, information published over the internet could be accessed anonymously by the public, giving rise to the WWW. Internet-based applications rely fundamentally on HTTP and HTML. Browsers and servers implement the defined standards to enable content publishing over the internet. XML and SOAP are also important.

17 Internet and Web Applications (2)

18 Internet and Web Applications (3) In the initial years of the web, HTML's support for data entry forms presented the opportunity to develop browser-based interfaces to legacy systems. Programs were developed to communicate with the mainframe by passing results back and forth via CGI. It became possible to publish information in legacy systems to www. The additional benefit of the browser becoming a universal client and eliminating the cumbersome task of upgrading user desktops. Web enabling made it easy to provide geographically distributed operations access the applications running in data centers regardless of location.

19 Internet and Web Applications (4) One marked disadvantage was the relatively limited user interface that could be created with plain HTML. This limitation has receded significantly in recent years with new technologies such as AJAX, enabling rich internet applications in the browser.

20 Web Application Servers In a web-enabled application architecture, processing logic (including database access), takes place outside the web server (via scripts or programs). Each invocation included the overhead of launching the required server program as a fresh operating-system process. Java made it possible to execute application functionality inside the web-server process (threads), leading the birth of the application server architecture. Requests could also be processed by multi-threaded execution environments, called containers.

21 Web Application Servers (2)

22 Web Application Servers (3) The servlet container allowed Java programs to execute in a multi-threaded manner within the server process as a servlet code. The container would also manage load balancing across incoming requests using these threads, as well as database connection pooling, similar to TP monitors. So, application-server arch also enjoys the advantages of 3-tier architecture: the ability to handle larger workloads as compared to the client-server model.

23 Internet of Services Once applications became web-enabled, it became natural to open up access to some of their functionality to the general public. A web service is an interoperable machine-to-machine interaction over HTTP. The data format and resource naming are done by XML and URI. The XML-RPC standard mimics remote procedure calls over HTTP with data being transferred in XML. To support complex nested (object oriented) types the SOAP protocol is developed, whereby the schema of the messages exchanged is defined by WSDL (web serviced description language). Using SOAP application could call the web services published by other applications over the internet.

24 Internet of Services (2) In 2000, XMLHTTPRequest was made available in the Javascript language. Javascript was being used to provide dynamic user interface behaviour within HTML pages, such as simple validations. Using XMLHTTPRequest it became possible to make HTTP requests, possibly to servers other than the one that served up the main HTML page being displayed. Thus came a new approach for integrating applications at the client side instead of between servers: AJAX.

25 Internet of Services (3)

26 Emergence of SaaS Even during the early days of the internet it had become evident that software products could be packaged and sold as remotely hosted application services. First wave of applications did not succeed: The internet bandwidth was not adequate Used remote-desktop-sharing, transmitting screenbuffer images back and forth Offered no significant cost advantages over the traditional model

27 Emergence of SaaS Successful solutions came when applications were completely web-based and designed for sharing across multiple customers. For customers SaaS solutions offered three main advantages over traditional software development by corporate IT: Business users could subscribe with a credit card Users found out that they could make customizations Users did not have to worry about upgrades

28 Successful SaaS Architectures Completely web-based architectures Exploited internal cost advantages from multi-tenancy and configurability. These architectural features enabled these solutions to offer sustained economic advantages over traditional software. If the software was installed in customer premises, a large part of the costs go into managing different versions of the product and supporting upgrades to multiple customers. With multi-tenancy the hosted SaaS application runs a single code base for all customers while ensuring that the data seen by each customer is specific to them.

29 SaaS Architecture

30 Successful SaaS Architectures Releasing a new version of a SaaS product amount to a single production upgrade for all customers. Multiple versions of the product do not need to be maintained. Costs of a new release are small, upgrades can be frequent, smaller and more likely to be stable. With traditional on-premise software corporate IT is responsible for development and maintenance of customizations to software products and their integration with other IT systems. It has often been documented that software maintenance costs are often two to three times greater than developing software. The complexity of modern multi-tier archs which require different technologies at each layer also adds to maintenance costs.

31 Customization: meta-data Customer specific customizations were captured as just another form of data, rather than code. Such data about the application functionality is more appropriately called meta-data. The SaaS application code which is the same for each customer (or tenant), interprets this meta-data at runtime, thereby rendering and executing varied functionality for each customer.

32 Cloud Computing Whereas software as a service is about packaged applications made available over the internet, cloud computing makes a lower level of infrastructure and tools available over the internet in data centers maintained by a cloud provider. A SaaS provider could implement their systems using web application server architectures. Since these offerings usually catered to small or medium businesses, the number of users are relatively small.

33 Amazon's Model The first 'cloud' provider. To display one page featuring a book, a number of services from fairly complex applications are needed (reviews, recommender systems, etc). Peaks and troughs of the seasonal retail business necessitated Amazon to continuously monitor load and automatically provision additional capacity on demand. They saw the need to support their suppliers with some minimal IT.

34 Amazon's Model (2) Amazon exploited virtualization extensively to automatically and dynamically provision hardware with those applications that were most utilized as demand fluctuated through the year. Key differences between Amazon cloud and traditional hosting: Degree of automation made available to end-users, as web services, to control the number of virtual instances running at any point in time The ability for users to package and save their own configurations of virtual machines Charging per hour of actual usage as opposed to monthly or yearly charges These enabled many users of the cloud to build complex applications without having to rely on deploying and configuring traditional middleware and database products.

35 Google's Model The scale of computing power needed to support largescale indexing of the web, the immense volume of searches and machine-learning-based targeting of advertisements across this volume meant order of magnitude larger computational needs as compared to even the largest enterprise. Large banks have tens of thousands of servers Google is estimated as running over a million servers.

36 Google's Model (2) Google developed innovations in programming models for large-scale distributed processing, such as the Map Reduce model for partitioning a sequence of tasks to be performed on a very large data set and executing it in parallel across a very large set of machines. Supporting the massive volume of search queries necessitated building a highly scalable application server architecture designed from the beginning to execute in parallel.

37 Google App Engine Users can program using development libraries (Python, Java) and deploy their code on app engine. The code deployed would always be running and would automatically scale on the app engine's large-scale distributed executing infrastructure. Data services were provided through the Google Datastore, a non-relational distributed database.

38 Cloud Models

39 Homework Install Google App Engine Install JDK (Java Development Kit) first Install Eclipse (Classic 4.2.1) Within Eclipse, click Help/Install New Software Use to install Google Plugin for Eclipse 4.2 and Google App Engine Java SDK. Also install Web Page Editor for syntax highlighting of JSP pages. Follow the tutorial at

40 References Enterprise Cloud Computing, Gautam Shroff Google App Engine Web Site, accessed on