L3 - Enabling Technologies

Cloud Computing
Enabling technologies
Emiliano Casalicchio, Phd

Department of Computer Science
Sapienza University of Rome
• Reduced Investments and
Benefits
Proportional Costs
Business • Increased Scalability
• Capacity planning Drivers • Increased Availability and
• Cost Reduction Definition Reliability
Cloud
• Agility Computing
Risks
• Web 2.0
• Data centers Inspiring/Enabling
• Cluster computing technologies • Increased Security Vulnerabilities
• Service computing • Reduced Operational Governance
• Grid computing
• P2P computing Control
• Utility computing • Limited Portability Between Cloud
• Virtualization
• Architectural styles for DC Providers
• Inter process • Multi-Regional Compliance and Legal
communication
Issues
Distributed Computing
Casalicchio@di.uniroma1.it
Agenda
Chapter 2 of the book
Mastering Cloud Computing, R. Buyya, C. Vecchiola,
• Main topics are: S. Thamarai Selvi
• Distributed computing/systems
• Architectural Styles Chapters 1 and 2 of the book
• Inter Process Communication Microservice patterns, C. Richardson
(styles and technologies)
• Datacenter technologies
• Automation
• High availability
• Computing Hardware
• Cloud Computing Concepts, technologies and
• Storage Hardware
architectures
• Chapters 3, 4, 5
• Suggested reading
Distributed computing
• Is a computational models; Defines how computation is carried on
• The computation is broken down into units executed concurrently on

different computing elements
• Processors on different nodes, processors on the same computer, or cores within the
same processor.
• Distributed often implies

• Different locations of the computing elements
• Heterogeneity in terms of hardware and software features
Could you provide me with an example
of distributed computation?
Examples of distributed computation
• Bach data analytics by

using map reduce
paradigm
• A simple word count
can be distributed
• Data storage and

retrieval can be
distributed
Distributed systems
• A distributed system is a collection of independent computers that
appears to its users as a single coherent system [Tanenbaum]
• Focus on unified usage and aggregation of distributed resources
• A distributed system is one in which components located at networked

computers communicate and coordinate their actions only by passing
messages [Coulouris]
• Focus on the networked nature and communication among processes
by passing messages
40 CHAPTER 2 Principles of Parallel and Distributed Computing
Components of a distributed system

Turn the HW and OS into the
distributed system
Support distributed
programming
Uniform interface for
Frameworks for
distributed application Applications
Distributed
developers Programming
(e.g. Hadoop, Spark)
Middleware
IPC Primitives for
Control and Data
Operating System
Inter-process communication
(IPC), process scheduling and Networking and
management, and resource Parallel Hardware
management in terms of file Hardware
system and local devices

FIGURE 2.10 Casalicchio@di.uniroma1.it
A layered view of a distributed system.
Distributed system and Cloud computing
CHAPTER 2 Principles of Parallel and Distributed Computing 2.4 Elements of distributed computing
systems
Distributes system layered view Cloud Computing system layered view
Social Networks,
Scientific Computing,
Enterprise Applications
Frameworks for Applications

Distributed Applications (SaaS)
Programming
Frameworks for
Middleware
IPC Primitives for
Cloud Application
Control and Data Development
Middleware (PaaS)
Operating System
Networking and Virtual Hardware,

Parallel Hardware Networking, OS Images, Hardware and OS (IaaS)
Hardware and Storage
2.10 FIGURE 2.11

d view of a distributed system. A cloud computing distributed system.
Cloud computing is a specialized formin of

features the distributed
form of graphicalcomputing that introduces
user interfaces (GUIs) accessible locally or through the
utilization
he very bottom layer, computer and network models for remotely
hardware constitute provisioning
the physicalvia scalable and measured resources
a Web browser. For example, in the case of a cloud computing system, the use of Web t
infrastructure;
ogies is strongly preferred, not only to interface distributed applications with the end user b
omponents are directly managed by the operating system, which provides Casalicchio@di.uniroma1.it
the basic services
to provide
rprocess communication (IPC), process scheduling and management, and resource platform services aimed at building distributed systems. A very good example is
manage-
Architectural styles System Software
SOA
Distributed
computing RPC
Models
Inter Process
Communication DO, DOF
(IPC) Web Services, REST

Technologies
Architectural styles
• It’s a blueprint of the system
• Define
• the different roles of components in the distributed system
• how the components are distributed across multiple machines
• How the components interact
• System architecture styles
• Organization of the distributed system in terms of its major
components
• can include both HW and SW and how SW map on HW
• Software architecture styles
• Logical organization of the software components
Software architectural styles
• Five main styles

• Call and return
• Independent components
• Data-centered
• Data flow
• Virtual machine
Call & Return style: Top-down
• Imperative programs
• divide-and-conquer approach
• A divide-and-conquer algorithm works by recursively breaking down a problem into
two or more sub-problems of the same or related type, until these become simple
enough to be solved directly. The solutions to the sub-problems are then combined
to give a solution to the original problem)
• Components are procedures and subprograms

• Connections are procedures call or methods invocations
• RPC/RMI can be used
• The calling program pass input data with parameters and
receive output data as return value or parameters
Call & Return style: Layered
• System organized in layers
• Each layer interact with an upper (high
abstraction) and lower (low abstraction)
layers; interaction is defined by specific
protocols and interfaces
• The user/client interact with the highest
abstraction layer that complete its activity
interacting and using services provided by
the lower layer. This process is repeated, if
needed by the lower layer, and so on.
• E.g. Modern OS kernels, TCP/IP stack
Independent Components
• Components have their own life
cycles and interact each other to
perform their activities
• Communicating processes
• Event systems
P2
• Communicating processes S2
• Independent processes that use IPC
(RPC, Web Services, REST, DO) for P1 Pn
coordination management S1 Sn
• Each process provides services and
can use services exposed by the other
processes
Independent Components: Event based
systems
• loosely coupled and connected
components Event/message broker
P1 S1
• Each component publish a collection e1
of events other components can
subscribe e2
Sn
• Subscriber component provides a
callback that will be executed when
the event is activated
• Foster the development of open
systems: a component can be easily
integrated as long as they have
compliant interfaces for registering to
events
Microservices: an independent
components software architecture
• “Microservices Patterns Chris Richardson”
• Available at the following link
https://livebook.manning.com/book/microservices-patterns/about-
this-book/
• Chapter 1 of the book
• (consider this book as a reference to develop your applications in the
future)
LP2 - 2017
Microservices (or microservice
architecture)
• Is an architectural style that structures an application as a
collection of services that are
• Highly maintainable and testable
• Loosely coupled
• Independently deployable
• Organized around business capabilities
• Owned by a small team
• The microservice architecture enables
• the rapid, frequent and reliable delivery of large, complex applications
• an organization to evolve its technology stack
LP2 - 2017
Microservices and scalability
The scale cube
The Art of Scalability (Addison-Wesley, 2015).
LP2 - 2017
Z-axis scaling
X-axis scaling Data partitioning
Horizontal duplication
Y-axis scaling
Functional decomposition
From microservices patterns
LP2 - 2017
Microservices vs. Monolithic architecture
• Monolithic architecture
• Prons
• Simple to develop & easy to make radical changes
• Straightforward to test & deploy
• Easy to scale
• Cons
• When the complexity increase (and technologies evolve) development, testing,
deployment and scaling became much more difficult
LP2 - 2017
Monolithic vs Microservices (cont’d)
LP2 - 2017 From microservices patterns

Benefits of microservice architecture
• It enables the continuous delivery and deployment of large,
complex applications
• Services are small and easily maintained
• Services are independently deployable
• Services are independently scalable
• The microservice architecture enables teams to be autonomous
• It allows easy experimenting and adoption of new technologies
• It has better fault isolation
LP2 - 2017
Drawbacks of the microservice
architecture
• Finding the right set of services is challenging
• there isn’t a concrete, well-defined algorithm for decomposing a
system into services
• Planning the scaling of a single service is challenging
• A research with Ericsson on that is in progress and thesis are available
• Distributed systems are complex and so development, testing
and deployment is challenging
• Deploying features that span multiple services requires careful
coordination (among development teams)
• Deciding when to adopt the microservice architecture is
difficult
LP2 - 2017
System architectural styles
• Cover the physical organization of components and processes
over a distributed infrastructure
• Help engineers to quickly identify the major advantages and
drawbacks of a given deployment and whether it is applicable
for a specific class of applications.
• Two fundamental reference styles:
• client/server Apply also to SW architectures
• peer-to-peer
Communication
Client/Server architecture protocols

HTTP, TLS, FTP
• Suitable for many-to-one scenarios request
• Listen
Two Tier• Request • Response
• Accept
(Classic Model)
client response server
• Three main components

• presentation, application logic, and data storage
Three Tier
• Thin clients
• Server: application logic + data storage; Client: presentation
• Fat-client model
client Client: presentation + application logic
• Server: data storage:; server
server/client
N Tier
C/S architecture: the multi-tiered model
2.4 Elements of distributed computing
• Presentation, application logic, and data maintenance can be seen as
conceptual layers, which are more appropriately called tiers.
request
• Suitable for systems of Two Tier
limited size (Classic Model)
• Suffers from scalability issues client response server
Three Tier
• More scalable, it is possible

to distribute the tiers into client
server/client server
several computing nodes;

N Tier
• performance bottlenecks
server
could be isolated
client server/client server/client
server
FIGURE 2.12
N-tier web server system
Examples Client
Client
Client
Client
Client Client
Three-tier web server system Client Client
Web Web
Server Server
Peer-to-peer architecture
• Symmetric architecture
• All the components (peers) play the same role and incorporate both client and server
capabilities
• Consistency is usually maintained by using consensus algorithms
• Suitable for highly decentralized architecture

• Can scale better along the dimension of the number of peers
• E.g. distributed storage/cloud storage, blockchain
https://www.g2.com/categories/blockchain
Distributed Datastore
• Each node has the same
role:
• Keep a portion of the
dataset
• Synchronize with peers
that have the same data
• Participate in the
consensus algorithm that
validate transactions (read
and write)
Architectural styles System Software
Distributed
computing RPC
Models
Inter Process
Communication DO, DOF
(IPC) SOA, Web Services, REST

Technologies
Models for Inter Process Communication
• IPC connects together the SW components for exchanging
data and information and/or coordinating the activity of
processes
• By means of IPC, processes exchange messages
• Message - any discrete amount of information that is passed from one
entity to another
• an invocation to a remote procedure
• a serialized object instance
• a partial result of a distributed computation
• Processes can interact with each other in different ways
• Remote procedure call (RPC)
• Distributed objects
• SOA
• Message passing (Point-to-point, Publish-subscribe, Request-reply)
Remote procedure call (RPC)
• Call of procedures beyond the boundaries of a single process,
that is the execution of code in remote processes
• Imply an underlying client/server architecture
• Client: the process that call the remote procedure
• Server: a remote process hosting a server component; it executes the
code and returns the result of the execution
• Messages
• Transport
• the information about the procedure to execute
• the required parameters
• the return values
• Are automatically created
2.5 Technologies for distributed computing 55
Remote Procedure Call implementation

Node A Node B
Main Procedure Procedure Registry
Procedure A Procedure C:Node B

Procedure C
Procedure B RPC Library RPC Service
Program A (RPC Client) Program C (RPC Server)
Parameters Marshaling Return Value Parameters Unmarshaling Return Value

and Procedure Name Unmarshaling and Procedure Name Marshaling
Network
RPC: application design
• RPC infrastructure
• Responsible for marshaling/un-marshaling
• Handle the request-reply interaction between client and server
• SW developer responsibilities
• Design and implementation of the server procedures that will be exposed for remote
invocation
• Registration of remote procedures with the RPC server on the node where they will
be made available
• Design and implementation of the client code that invokes the remote procedure(s)
• Implementation is done using RPC API

• Platform dependent implementations – e.g. RPyC, RPClib
• Platform independent implementations – e.g. XML-RPC, JSON-RPC
Distributed objects
• Implementation of the RPC model for the object-oriented paradigm
• remote invocation of methods exposed by objects
• Each process registers a set of interfaces that are accessible remotely
• Client processes can request a pointer to these interfaces and invoke
the methods available through them
• The object implementing the method became the Server
• The underlying runtime infrastructure is in charge of transforming the
local method invocation into a request to a remote process and
collecting the result of the execution
• The communication between the caller and the remote process is
made through messages
Distributed objects (cont’d)
• Distributed object models introduce the
complexity of
• object state management (by contrast RPC is stateless) Contacts: ArrayList
• Lifetime elements: Array
• The methods remotely executed is associated to add(object): void

insert(int, Object): void
an object instance get(int): object
• created for the sole execution of the method,
• exist for a limited interval of time, or
• are independent from the existence of requests
Distributed Object Framework
The
reference is The server
a pointer to maintains a
an instance registry of
of a shared active
type of objects
interface or published
class using
interface
definition or
class
definition
RPC
Marshaling/un-marshaling managed by the infrastructure

Distributed object framework (cont’d)
• If the method invocation foreseen an object to be
passed as parameter
• Marshaling by value
• A copy of the object is created on the server
• Inconsistency problems
• Marshaling by reference
• No duplication of the object – a proxy is created on the server
• More complex and resource demanding for the infrastructure –
remote references have to be tracked
Distributed object activation
• Server-based
• The object has its own life and the remote method
invocation is occasional
• The creation is user controlled
• Client-based
• The object is created with the purpose of executing
the method invoked – e.g. the remote object is
functional to modify/access data/database on the
server
• The creation is implicit, the life time is controlled by
the runtime infrastructure
• A new object for each invocation – mechanism for object reuse in
case of subsequent method invocation
• Only one instance at time – lifetime controlled by the frequency
Distributed object framework (cont’d)
• Examples
• Common Object Request Broker Architecture (CORBA)
• Distributed Component Object Model (DCOM/COM+) – predecessor
of .NET
• Java Remote Method Invocation (RMI)
• .NET remoting
Service Oriented Architecture
• An application is an aggregations of services that are
coordinated within a SOA
• A service encapsulates a software component and has
four main characteristics
• Boundaries are explicit, interfaces are kept minimal to foster
reuse and simplify interaction
• Services are autonomous, can be integrated in different
systems at the same time, can handle failures
• Services share schema and contracts, a contract describe the
structure of messages the service can send and/or receive and
additional constraint on their ordering
• allow to check structural compatibility using machine-based techniques
• Service (semantic) compatibility is determined based on
policies
• Policies define the capabilities and requirements in term of expressions
that must hold true
Service Oriented Architecture (SOA)
• There are two major roles (and three
main components) within SOA
3. SC-SP establish
• Service provider a connection
• maintainer of the service using the binding
info
• Publish the service in a registry together with a 4. SC uses the
service schema and contract service
• Service consumer
• locate the service metadata in the registry
• develop the required client components to 1. SC discovers a service
bind and use the service. 2. SR return binding info
• Service providers and consumers can
belong to different organization bodies or
business domains. 44
Service Oriented Architecture (SOA)
• Components can play the roles of both service provider and
service consumer
• Aggregating services in workflows and using them to satisfy consumer
research
• E.g. travel planner – search for flight, search for hotel, book hotel, search for car
rental/sight-seen attractions, …
• How services can be coordinated and managed?
• Service Orchestration
• A service orchestrator coordinate and manage the composition and interaction of
services
• Service choreography
• Coordinated interaction of services without a single point of control
Orchestration and Choreography
LP12 - 2016 Emiliano.Casalicchio@BTH.se 46

Enterprise features in SOA
• Standardized service contract – to facilitate interoperability
• Loose coupling – to minimize dependencies
• Abstraction – to hide technical implementation details
• Reusability – use of third party services (fee based or free)
• Autonomy – services control themselves
• Lack of state – stateless to foster reuse and multiple customers support
• Discoverability – description documents other then schema and contract
• Composability – by means of orchestration/choreography
Web services – a SOA implementation
• An implementation of the RPC concept over HTTP
• Allow the interaction of components that are developed with
different technologies
• A Web service is exposed as a remote object hosted on a Web server
• Method invocations are transformed in HTTP requests using specific
protocols
• Simple Object Access Protocol (SOAP)
• Representational State Transfer (REST).
logs using Universal Description Discovery and Integration (UDDI) or, most likely, directly
retrieve the service metadata by interrogating the Web service first. The Web service description
Web services
document allows service consumers to automatically generate clients for the given service and
embed them in their existing application. Web services are now extremely popular, so bindings
• Based on object
oriented abstraction
The web server client is
• Method operations
(automatically) built on the
support parameters
basis of WS description
Web WSDL(s) Web Service and return values in
(2) Server the form of complex
se
spon )
L UDDI Registry
and simple types
WS Client Re SD Web WSDL
(W
Server • WSDL allow to
(1) HTTP Service implemented with express simple and
Application Query
company specific technology complex types in
platform-independent
(3) manner
In
• Made accessible
vo
ca
Web Service
tio
through web servers

n
WS Client
WSDL • HTTP the most
popular transport
Application
protocol
Application
FIGURE 2.16 Casalicchio@di.uniroma1.it

A Web services interaction reference scenario.
Representational State Transfer (REST)
• REST is a lightweight alternative to SOAP
• The HTTP methods (GET, PUT, POST, DELETE) are used to implement the
operation requested by Web Services
• RESTful Web services are quite popular
• Twitter,
• Yahoo! (search APIs, maps, photos, etc),
• Flickr,
• Amazon.com,
• …
• References
1. RESTful Web services: The basics (2008/2015) IBM developerWorks series, Alex Rodriguez
https://www.ibm.com/developerworks/library/ws-restful/index.html
2. RESTful Web Services: Principles, Patterns, Emerging Technologies (2013) - pdf on Classroom
3. RESTful Web Services (2007) Leonard Richardson, Sam Ruby; O'Reilly Media, Inc.
REST
• REST Web service follows four basic design principles:
• Use HTTP methods explicitly.
• Be stateless.
• Expose directory structure-like URIs.
• Transfer XML, JavaScript Object Notation (JSON), or both
• Basic REST design principle establishes a one-to-one mapping between

create, read, update, and delete (CRUD) operations and HTTP methods.
According to this mapping:
• To create a resource on the server, use POST.
• To retrieve a resource, use GET.
• To change the state of a resource or to update it, use PUT.
• To remove or delete a resource, use DELETE.
Example: insert a new record in a db
USING POST (correct way) USING GET (not correct but largely used)
POST /users HTTP/1.1 GET /adduser?name=Robert HTTP/1.1

Host: myserver
Content-Type: application/xml
<?xml version="1.0"?>
<user>
<name>
Robert
</name>
</user>
Stateful vs Stateless
• an application may request the next page in a multipage result
set
Microservices vs. Service Oriented
Architecture
• High level similarities
• SOA and microservices structure a system as a set of components
• Differences
• Communication mechanisms
• Data handling
• Size of the services
LP2 - 2017
Architecture (cont’d)
• Differences (communication)
• SOA uses heavyweight technologies (SOAP and other WS* standards)
• SOA uses Enterprise Service Bus, a communication middleware that
contain business and messaging processing logic, to integrate the
services
• Slow communication
• Single point of failure
• High configuration and maintenance complexity
• Microservices uses lightweight, open-source technologies
• message broker
• REST, gRPC (a modern open source high performance RPC framework)
LP2 - 2017
Architecture (cont’d)
• Differences (Data)
• SOA applications typically have a global data model and share
databases
• In the Microservice architecture each service has its own database and
data model
• Differences (size of the services)

• SOA is typically used to integrate large, complex monolithic
applications
• application usually consists of a few large services
• Microservice architecture use much smaller or ideally tiny services
• application typically consists of 10s or 100s of small services.
LP2 - 2017
Home/Class-work
• Consider a monolithic architecture you have developed in the past or, (e.g if you
have never designed an application) consider a travel planning application and:
• 1) Identify the microservice needed (for the monolithic application you should
decompose it in microservice)
• 2) specify the functionalities offered (exposed) by each microservice
• 3) specify how the microservice interact each other (who calls whom) - is that
orchestration or choreography?
• For the travel planning application the functionalities could be: search of
hotels/B&B/apartments/...; visualization of locations on a map;
booking/reservation of hotels; searching and buying flight/train tickets;
searching and buying events tickets; visualization of events location on a map;
credit card transaction; change/cancellation of reservation; rent cars; suggestion
of events, activities, places nearby the destination of the trip.
• Post your solution in G Classroom (there is a question activated for that) - i will
provide a feedback. You can work in group (remotely!!!)
Questions?

L3 - Enabling Technologies

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

L3 - Enabling Technologies

Uploaded by

Copyright:

Available Formats

Cloud Computing

Emiliano Casalicchio, Phd

• The computation is broken down into units executed concurrently on

• Distributed often implies

• Bach data analytics by

• Data storage and

• A distributed system is one in which components located at networked

Components of a distributed system

system and local devices

Frameworks for Applications

Networking and Virtual Hardware,

2.10 FIGURE 2.11

Cloud computing is a specialized formin of

(IPC) Web Services, REST

• Five main styles

• Components are procedures and subprograms

From microservices patterns

LP2 - 2017 From microservices patterns

Client/Server architecture protocols

client response server

• Three main components

• Suffers from scalability issues client response server

• More scalable, it is possible

several computing nodes;

• Suitable for highly decentralized architecture

• E.g. distributed storage/cloud storage, blockchain

(IPC) SOA, Web Services, REST

Remote Procedure Call implementation

Main Procedure Procedure Registry

Procedure A Procedure C:Node B

Procedure B RPC Library RPC Service

Program A (RPC Client) Program C (RPC Server)

Parameters Marshaling Return Value Parameters Unmarshaling Return Value

• Implementation is done using RPC API

• The methods remotely executed is associated to add(object): void

Marshaling/un-marshaling managed by the infrastructure

LP12 - 2016 Emiliano.Casalicchio@BTH.se 46

through web servers

FIGURE 2.16 Casalicchio@di.uniroma1.it

• Basic REST design principle establishes a one-to-one mapping between

POST /users HTTP/1.1 GET /adduser?name=Robert HTTP/1.1

• Differences (size of the services)

You might also like