Chapter 12. Cloud Functions: Serverless applications
What are microservices?
What is Google Cloud Functions?
Creating, deploying, updating, triggering, and deleting functions
Managing function dependencies
How pricing works for Google Cloud Functions
12.1. What are microservices?
A “microservice architecture” is a way of building and assembling an application that keeps each concrete piece of the application as its own loosely coupled part (called a microservice).
microservice can stand on its own
A traditional application has many parts that are intertwined with one another, incapable of running independently.
Typical application, you’d start a project and then start adding controllers to handle the different parts of the application
Ability to sign up and log in, and then add more functionality such as creating to-do lists.
Creating items on those lists, searching through all the lists for matching items.
Application would be a single code base, running on a single server.
Microservices
Chopping up each bit of functionality into its own loosely coupled piece.
Microservice responsible for signing up.
Another for logging in,
Benefits is that each service is only loosely coupled to any other services.
Each microservice can run on its own.
Each piece isolated from the others means that deployment is much more straightforward.
Implementation under the hood doesn’t matter so long as that contract is fulfilled by the service.
Major changes in a monolithic application.
Just rewrite the microservice.
12.2. What is Google Cloud Functions?
Abstraction of physical infrastructure in favor of virtual infrastructure.
Turn on a virtual computer in a few seconds.
Cloud Functions takes that concept to the far end of the spectrum.
Fit well with microservice architectures.
Single functions that run in an entirely serverless environment.
Write only short, narrowly scoped functions, and these functions are run for you on demand.
Typical flow of an application, most requests are triggered by users making requests, usually over HTTP.
Other types of events from lots of different cloud services can trigger requests.
Function can be triggered by someone uploading a file to Cloud Storage or a message being published via Cloud Pub/Sub.
Events can be monitored by different triggers.
Ability to knit different pieces together that makes Cloud Functions so interesting.
Associate small pieces of code to different events and have that code run whenever those events happen.
Hook up a function so that it runs whenever a customer uploads a file into a Cloud Storage bucket.
Function might automatically tag the image with labels from the Cloud Vision API
12.2.1. Concepts
Function isn’t all that useful without the ability to connect it to other things
events and triggers.
Work together to form a pipeline that you can use to build interesting applications.
Events are things that can happen.
Functions are chunks of code that run in response to events.
Triggers are ways of coupling a function to some events.
Make sure to run function X whenever a new GCS Object is created.
Cause further events in which other triggers cause more functions to run.
Connect multiple microservices together to build complex applications.
Events
Event corresponds to something happening.
End up causing a function to run.
An HTTP request, places such as Google Cloud Storage or Google Cloud Pub/Sub.
Event comes with attributes.
Basic details of an event (such as a unique ID, the type of the event, and a timestamp of when the event occurred.
Resource targeted by the event, and the payload of data specific to the event.
Data attached to an event depends on the type of the event, common data types are used to minimize the learning curve.
HTTP events have an Express Request object in the data field.
Events from Cloud Storage have the affected Cloud Storage Object in the data field.
Events based on HTTP requests are synchronous events (the requester is waiting for a response),
Coming from other services such as Cloud Pub/Sub are asynchronous (they run in the background).
Code you write to list for synchronous events will be slightly different from that for asynchronous events.
Events are the basic building blocks used to pass along information about things happening.
Functions
Function itself is the equivalent of a single microservice in an application.
Function should be responsible for a single thing and have no problem standing on its own.
At its core, a function is an arbitrary chunk of code that can run on demand.
Tells the Cloud Functions runtime how to execute the function.
How long to run before timing out and returning an error.
Amount of memory to allocate for a given request.
Cloud Functions lets you write these functions in JavaScript or Python, but depending on whether you’re dealing with a synchronous event (an HTTP request) or an asynchronous event (a Pub/Sub message), the structure of the function can be slightly different.
Functions written to handle synchronous events use a request and response syntax, similar to request handlers in Express.
exports.echoText = (req, res) => {
if (req.get('content-type') !== 'text/plain') {
res.status(400).send('I only know how to echo text!');
} else {
res.status(200).send(req.body);
}
};
Both a request and a response as arguments to the function.
Read from the request and send data back to the user by calling functions (like .send()) on the response.
Code for asynchronous events to handle things like a new message arriving from Cloud Pub/Sub?
Called background functions instead of getting the request and response as arguments, they just get the event along with a callback
signals the completion of the function.
Logs some information based on an incoming Pub/Sub message.
exports.logPubSubMessage = (event, callback) => {
const msg = event.data;
console.log('Got message ID', msg.messageId);
callback();
};
Event is passed in as an argument.
Can read from and do things with.
When you’re done, you call the callback provided.
How did the Pub/Sub message get routed to the function?”.
“How did an HTTP request get routed to the first function?”.
Triggers
Use triggers to specify which events should be routed to a given function.
Specify that you’re interested in events from a given service (such as Cloud Pub/Sub), as well as some filter to narrow down which resource you want events from (such as a specific Pub/Sub topic).
12.3. Interacting with Cloud Functions
Write the function itself in JavaScript or Python.
Deploy it to Google Cloud Functions,
Define what exactly triggers it.
HTTP requests, Pub/Sub messages, or Cloud Storage notifications.
Writing a function that responds to HTTP requests by echoing back the information sent and adding some extra information.
12.3.1. Creating a function
Synchronous function.
Write it in the request and response style.
Creating a new directory called echo and, in that directory, a new file called index.js
exports.echo = (req, res) => {
let responseContent = {
from: 'Cloud Functions'
};
let contentType = req.get('content-type');
if (contentType == 'text/plain') {
responseContent.echo = req.body;
} elseif (contentType == 'application/json') {
responseContent.echo = req.body.data;
} else {
responseContent.echo = JSON.stringify(req.body);
}
res.status(200).send(responseContent);
};
Request specifically accepts text requests and responds with a JSON object.
Extra data saying that this came from Cloud Functions.
12.3.2. Deploying a function
Cloud Storage bucket, which is where the content of your functions will live.
Enable the Cloud Functions API in your project.
Navigate to the Cloud Console and enter Cloud Functions API in the search box at the top of the page.
Create Function
Name the function
Code the functions - select python3.7 Entry point function name must match function in code
Place proper entries in requirements.txt
Deploy Function
HTTP is a protocol which allows the fetching of resources, such as HTML documents. It is the foundation of any data exchange on the Web and it is a client-server protocol, which means requests are initiated by the recipient, usually the Web browser. A complete document is reconstructed from the different sub-documents fetched, for instance text, layout description, images, videos, scripts, and more.
Clients and servers communicate by exchanging individual messages (as opposed to a stream of data). The messages sent by the client, usually a Web browser, are called requests and the messages sent by the server as an answer are called responses.
Designed in the early 1990s, HTTP is an extensible protocol which has evolved over time. It is an application layer protocol that is sent over TCP, or over a TLS-encrypted TCP connection, though any reliable transport protocol could theoretically be used. Due to its extensibility, it is used to not only fetch hypertext documents, but also images and videos or to post content to servers, like with HTML form results. HTTP can also be used to fetch parts of documents to update Web pages on demand
The Transmission Control Protocol (TCP) is one of the main protocols of the Internet protocol suite. It originated in the initial network implementation in which it complemented the Internet Protocol (IP). Therefore, the entire suite is commonly referred to as TCP/IP. TCP provides reliable, ordered, and error-checked delivery of a stream of octets (bytes) between applications running on hosts communicating via an IP network. Major internet applications such as the World Wide Web, email, remote administration, and file transfer rely on TCP, which is part of the Transport Layer of the TCP/IP suite. SSL/TLS often runs on top of TCP.
https://developer.mozilla.org/en-US/docs/Web/HTTP/Overview
A Google Cloud Function can be called in response to multiple types of events, and of the most useful events to use is an HTTP request. This allows you to make a GET, POST or other HTTP request to a URL provided by your Cloud Function, and have it run in response to the given request.
HyperText Transfer Protocol (HTTP)
HTTP (Hypertext Transfer Protocol) is perhaps the most popular application protocol used in the Internet (or The WEB).
HTTP is an asymmetric request-response client-server protocol as illustrated. An HTTP client sends a request message to an HTTP server. The server, in turn, returns a response message. In other words, HTTP is a pull protocol, the client pulls information from the server (instead of server pushes information down to the client).
HTTP is a stateless protocol. In other words, the current request does not know what has been done in the previous requests.
HTTP permits negotiating of data type and representation, so as to allow systems to be built independently of the data being transferred.
Quoting from the RFC2616: "The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. It is a generic, stateless, protocol which can be used for many tasks beyond its use for hypertext, such as name servers and distributed object management systems, through extension of its request methods, error codes and headers."
Browser
Whenever you issue a URL from your browser to get a web resource using HTTP, e.g. http://www.nowhere123.com/index.html, the browser turns the URL into a request message and sends it to the HTTP server. The HTTP server interprets the request message, and returns you an appropriate response message, which is either the resource you requested or an error message. This process is illustrated below:
Uniform Resource Locator (URL)
A URL (Uniform Resource Locator) is used to uniquely identify a resource over the web. URL has the following syntax:
protocol://hostname:port/path-and-file-name
There are 4 parts in a URL:
Protocol: The application-level protocol used by the client and server, e.g., HTTP, FTP, and telnet.
Hostname: The DNS domain name (e.g., www.nowhere123.com) or IP address (e.g., 192.128.1.2) of the server.
Port: The TCP port number that the server is listening for incoming requests from the clients.
Path-and-file-name: The name and location of the requested resource, under the server document base directory.
For example, in the URL http://www.nowhere123.com/docs/index.html, the communication protocol is HTTP; the hostname is www.nowhere123.com. The port number was not specified in the URL, and takes on the default number, which is TCP port 80 for HTTP. The path and file name for the resource to be located is "/docs/index.html".
Other examples of URL are:
ftp://www.ftp.org/docs/test.txt
mailto:user@test101.com
news:soc.culture.Singapore
telnet://www.nowhere123.com/
HTTP Protocol
As mentioned, whenever you enter a URL in the address box of the browser, the browser translates the URL into a request message according to the specified protocol; and sends the request message to the server.
For example, the browser translated the URL http://www.nowhere123.com/doc/index.html into the following request message:
GET /docs/index.html HTTP/1.1
Host: www.nowhere123.com
Accept: image/gif, image/jpeg, */*
Accept-Language: en-us
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)
(blank line)
When this request message reaches the server, the server can take either one of these actions:
The server interprets the request received, maps the request into a file under the server's document directory, and returns the file requested to the client.
The server interprets the request received, maps the request into a program kept in the server, executes the program, and returns the output of the program to the client.
The request cannot be satisfied, the server returns an error message.
An example of the HTTP response message is as shown:
HTTP/1.1 200 OK
Date: Sun, 18 Oct 2009 08:56:53 GMT
Server: Apache/2.2.14 (Win32)
Last-Modified: Sat, 20 Nov 2004 07:16:26 GMT
ETag: "10000000565a5-2c-3e94b66c2e680"
Accept-Ranges: bytes
Content-Length: 44
Connection: close
Content-Type: text/html
X-Pad: avoid browser bug
<html><body><h1>It works!</h1></body></html>
The browser receives the response message, interprets the message and displays the contents of the message on the browser's window according to the media type of the response (as in the Content-Type response header). Common media type include "text/plain", "text/html", "image/gif", "image/jpeg", "audio/mpeg", "video/mpeg", "application/msword", and "application/pdf".
In its idling state, an HTTP server does nothing but listening to the IP address(es) and port(s) specified in the configuration for incoming request. When a request arrives, the server analyzes the message header, applies rules specified in the configuration, and takes the appropriate action. The webmaster's main control over the action of web server is via the configuration, which will be dealt with in greater details in the later sections.
HTTP over TCP/IP
HTTP is a client-server application-level protocol. It typically runs over a TCP/IP connection, as illustrated. (HTTP needs not run on TCP/IP. It only presumes a reliable transport. Any transport protocols that provide such guarantees can be used.)
TCP/IP (Transmission Control Protocol/Internet Protocol) is a set of transport and network-layer protocols for machines to communicate with each other over the network.
IP (Internet Protocol) is a network-layer protocol, deals with network addressing and routing. In an IP network, each machine is assigned an unique IP address (e.g., 165.1.2.3), and the IP software is responsible for routing a message from the source IP to the destination IP. In IPv4 (IP version 4), the IP address consists of 4 bytes, each ranges from 0 to 255, separated by dots, which is called a quad-dotted form. This numbering scheme supports up to 4G addresses on the network. The latest IPv6 (IP version 6) supports more addresses. Since memorizing number is difficult for most of the people, an english-like domain name, such as www.nowhere123.com is used instead. The DNS (Domain Name Service) translates the domain name into the IP address (via distributed lookup tables). A special IP address 127.0.0.1 always refers to your own machine. It's domian name is "localhost" and can be used for local loopback testing.
TCP (Transmission Control Protocol) is a transport-layer protocol, responsible for establish a connection between two machines. TCP consists of 2 protocols: TCP and UDP (User Datagram Package). TCP is reliable, each packet has a sequence number, and an acknowledgement is expected. A packet will be re-transmitted if it is not received by the receiver. Packet delivery is guaranteed in TCP. UDP does not guarantee packet delivery, and is therefore not reliable. However, UDP has less network overhead and can be used for applications such as video and audio streaming, where reliability is not critical.
TCP multiplexes applications within an IP machine. For each IP machine, TCP supports (multiplexes) up to 65536 ports (or sockets), from port number 0 to 65535. An application, such as HTTP or FTP, runs (or listens) at a particular port number for incoming requests. Port 0 to 1023 are pre-assigned to popular protocols, e.g., HTTP at 80, FTP at 21, Telnet at 23, SMTP at 25, NNTP at 119, and DNS at 53. Port 1024 and above are available to the users.
Although TCP port 80 is pre-assigned to HTTP, as the default HTTP port number, this does not prohibit you from running an HTTP server at other user-assigned port number (1024-65535) such as 8000, 8080, especially for test server. You could also run multiple HTTP servers in the same machine on different port numbers. When a client issues a URL without explicitly stating the port number, e.g., http://www.nowhere123.com/docs/index.html, the browser will connect to the default port number 80 of the host www.nowhere123.com. You need to explicitly specify the port number in the URL, e.g. http://www.nowhere123.com:8000/docs/index.html if the server is listening at port 8000 and not the default port 80.
In brief, to communicate over TCP/IP, you need to know (a) IP address or hostname, (b) Port number.
HTTP Specifications
The HTTP specification is maintained by W3C (World-wide Web Consortium) and available at http://www.w3.org/standards/techs/http. There are currently two versions of HTTP, namely, HTTP/1.0 and HTTP/1.1. The original version, HTTP/0.9 (1991), written by Tim Berners-Lee, is a simple protocol for transferring raw data across the Internet. HTTP/1.0 (1996) (defined in RFC 1945), improved the protocol by allowing MIME-like messages. HTTP/1.0 does not address the issues of proxies, caching, persistent connection, virtual hosts, and range download. These features were provided in HTTP/1.1 (1999) (defined in RFC 2616).
Apache HTTP Server or Apache Tomcat Server
A HTTP server (such as Apache HTTP Server or Apache Tomcat Server) is needed to study the HTTP protocol.
Apache HTTP server is a popular industrial-strength production server, produced by Apache Software Foundation (ASF) @ www.apache.org. ASF is an open-source software foundation. That is to say, Apache HTTP server is free, with source code.
The first HTTP server is written by Tim Berners Lee at CERN (European Center for Nuclear Research) at Geneva, Switzerland, who also invented HTML. Apache was built on NCSA (National Center for Supercomputing Applications, USA) "httpd 1.3" server, in early 1995. Apache probably gets its name from the fact that it consists of some original code (from an earlier NCSA httpd web server) plus some patches; or from the name of an American Indian tribe.
Read "Apache How-to" on how to install and configuare Apache HTTP server; or "Tomcat How-to" to install and get started with Apache Tomcat Server.
HTTP Request and Response Messages
HTTP client and server communicate by sending text messages. The client sends a request message to the server. The server, in turn, returns a response message.
An HTTP message consists of a message header and an optional message body, separated by a blank line, as illustrated below:
HTTP Request Message
The format of an HTTP request message is as follow:
Request Line
The first line of the header is called the request line, followed by optional request headers.
The request line has the following syntax:
request-method-name request-URI HTTP-version
request-method-name: HTTP protocol defines a set of request methods, e.g., GET, POST, HEAD, and OPTIONS. The client can use one of these methods to send a request to the server.
request-URI: specifies the resource requested.
HTTP-version: Two versions are currently in use: HTTP/1.0 and HTTP/1.1.
Examples of request line are:
GET /test.html HTTP/1.1
HEAD /query.html HTTP/1.0
POST /index.html HTTP/1.1
Request Headers
The request headers are in the form of name:value pairs. Multiple values, separated by commas, can be specified.
request-header-name: request-header-value1, request-header-value2, ...
Examples of request headers are:
Host: www.xyz.com
Connection: Keep-Alive
Accept: image/gif, image/jpeg, */*
Accept-Language: us-en, fr, cn
Example
The following shows a sample HTTP request message:
HTTP Response Message
The format of the HTTP response message is as follows:
Status Line
The first line is called the status line, followed by optional response header(s).
The status line has the following syntax:
HTTP-version status-code reason-phrase
HTTP-version: The HTTP version used in this session. Either HTTP/1.0 and HTTP/1.1.
status-code: a 3-digit number generated by the server to reflect the outcome of the request.
reason-phrase: gives a short explanation to the status code.
Common status code and reason phrase are "200 OK", "404 Not Found", "403 Forbidden", "500 Internal Server Error".
Examples of status line are:
HTTP/1.1 200 OK
HTTP/1.0 404 Not Found
HTTP/1.1 403 Forbidden
Response Headers
The response headers are in the form name:value pairs:
response-header-name: response-header-value1, response-header-value2, ...
Examples of response headers are:
Content-Type: text/html
Content-Length: 35
Connection: Keep-Alive
Keep-Alive: timeout=15, max=100
The response message body contains the resource data requested.
Example
The following shows a sample response message:
HTTP Request Methods
HTTP protocol defines a set of request methods. A client can use one of these request methods to send a request message to an HTTP server. The methods are:
GET: A client can use the GET request to get a web resource from the server.
HEAD: A client can use the HEAD request to get the header that a GET request would have obtained. Since the header contains the last-modified date of the data, this can be used to check against the local cache copy.
POST: Used to post data up to the web server.
PUT: Ask the server to store the data.
DELETE: Ask the server to delete the data.
TRACE: Ask the server to return a diagnostic trace of the actions it takes.
OPTIONS: Ask the server to return the list of request methods it supports.
CONNECT: Used to tell a proxy to make a connection to another host and simply reply the content, without attempting to parse or cache it. This is often used to make SSL connection through the proxy.
Other extension methods.
"GET" Request Method
GET is the most common HTTP request method. A client can use the GET request method to request (or "get") for a piece of resource from an HTTP server. A GET request message takes the following syntax:
GET request-URI HTTP-version
(optional request headers)
(blank line)
(optional request body)
The keyword GET is case sensitive and must be in uppercase.
request-URI: specifies the path of resource requested, which must begin from the root "/" of the document base directory.
HTTP-version: Either HTTP/1.0 or HTTP/1.1. This client negotiates the protocol to be used for the current session. For example, the client may request to use HTTP/1.1. If the server does not support HTTP/1.1, it may inform the client in the response to use HTTP/1.0.
The client uses the optional request headers (such as Accept, Accept-Language, and etc) to negotiate with the server and ask the server to deliver the preferred contents (e.g., in the language that the client preferred).
GET request message has an optional request body which contains the query string (to be explained later).
No comments:
Post a Comment