1 of 16

Cloud 101 - backend applications

Andrei Dragomir

2 of 16

What we'll talk about

Particularities of backend applications
Components
Patterns: communication (choosing protocols)
Patterns: databases (choosing databases etc)

3 of 16

Why have backend applications

You need a backend application to solve problems of multi-user communication and state saving
Any state that is saved on a user's computer is unavailable if that computer is offline
Peer to peer systems are much harder to reason about than centralized systems

4 of 16

Particularities of backend applications

You need a computer to run them

For most any other applications, your user brings the computer (or phone)

They are invisible and headless

Until they break
You need to put in extra effort for visibility into what the apps are doing, automates testing etc

They are inherently multi-user

Problems of concurrency, resources, etc

Their main interface is communication over a network

And networks are unreliable

5 of 16

Communications over a network

The network is reliable.
Latency is zero.
Bandwidth is infinite.
The network is secure.
Topology doesn't change.
There is one administrator.
Transport cost is zero.
The network is homogeneous.

<< All these things are fake

6 of 16

Protocols

Overloaded term: transport protocols (how the data moves), encoding protocols (how the data looks)
Design considerations

Connection oriented / stream oriented
Binary / text
Loose or strong typed

7 of 16

Transport protocols

For client <-> server communication (Internet to cluster), HTTP/1.1 is still probably the best choice
Inside the cluster, HTTP/2 is becoming pretty popular

As well as socket connections etc

HTTP/2 improvements:

More efficient
Multiple streams, flow control

8 of 16

What does an app endpoint talk

REST style

URLs as resources
Can be made discoverable
Some automated documentation tools: Swagger
about "Objects" or "Things"

RPC style

typed interfaces
similar to function calls
about "Functions" or "Actions"

9 of 16

gRPC

RPC style built on top of Protocol Buffers
Strongly typed, evolvable binary protocol

service HelloService {

rpc SayHello (HelloRequest) returns (HelloResponse);

}

message HelloRequest {

string greeting = 1;

}

message HelloResponse {

string reply = 1;

}

10 of 16

JSON

Data interchange format
Loosely typed, textual
Simple to use and understand

{

"type": "student",

"age": 20,

"metadata": {

"k": "v"

}

11 of 16

Example App

API: JSON, single endpoint which takes data from the mobile app and saves it to a database
What do you need for a backend application ?

A web server (either separate or embedded, application server, plain server w/ CGI etc)
An actual app (that communicates with the webserver, or includes it)
A way to talk to the clients: HTTP endpoints APIs
Your business logic
All kinds of non-functional requirements: metrics, configuration, security)

12 of 16

Spring boot

Spring boot is a framework that gives you things that almost all backend apps need:

Endpoints (Controllers, parameter validation etc)
Object wiring (dependency injection)
HTTP infrastructure
Metrics / monitoring

Framework versus library - the Hollywood principle
You USE the library code, but you FILL IN code in a framework

13 of 16

App building blocks - async programming

Async programming means parallelism (NOT concurrency)
NOT always applicable - relies on empirical observation that network apps do a lot of network calls
Promises

Are a way of wrapping a future "value" into a wrapper
They are composable - you can chain them, stop them, wait until all are done etc

CompletableFuture

14 of 16

App building blocks - databases

Data storage is the hardest problem in distributed systems
Inherently concurrent (NOT parallel)
SQL / NoSQL databases
Different consistency levels
NOT always applicable - relies on empirical observation that network apps do a lot of network calls
Promises

Are a way of wrapping a future "value" into a wrapper
They are composable - you can chain them, stop them, wait until all are done etc

CompletableFuture

15 of 16

References

https://github.com/donnemartin/system-design-primer - Learn how to develop distributed systems
http://www.rgoarchitects.com/Files/fallacies.pdf - Fallacies of distributed computing explained
https://gist.github.com/hellerbarde/2843375 - Latency numbers every programmer should know
https://grpc.io/ - gRPC
https://json.org/ - JSON
https://spring.io - Spring
https://spring.io/projects/spring-boot - Spring
https://aphyr.com/posts/313-strong-consistency-models - Consistency models
https://github.com/aphyr/distsys-class - Class notes for a distributed systems course
https://blog.golang.org/concurrency-is-not-parallelism - Concurrency is not parallelism

16 of 16

THANK YOU