InfoQ Homepage Presentations WebSockets, Reactive APIs and Microservices

WebSockets, Reactive APIs and Microservices

Bookmarks

View Presentation

Speed:

Download

44:58

Summary

Todd Montgomery investigates whether WebSockets, HTTP/2, Reactive Streams and microservices can deliver the high scalability, resiliency, and ease of development promised.

Bio

Todd Montgomery is a networking hacker who has researched, designed, and built numerous protocols, messaging-oriented middleware systems, and real-time data systems, done research for NASA, contributed to the IETF and IEEE, and co-founded two startups. He currently works as an independent consultant on high performance systems and is active in several open source projects.

About the conference

Software is changing the world. QCon empowers software development by facilitating the spread of knowledge and innovation in the developer community. A practitioner-driven conference, QCon is designed for technical team leads, architects, engineering directors, and project managers who influence innovation in their teams.

Key Takeaways

We are in a state of constant evolution as computer scientists, architects or software engineers. Everything is changing. Waiting for a technique to become mature is not useful anymore.
The idea of WebSockets is to take the existing pieces of HTTP and override them. It upgrades the protocol that creates asynchronous request-response and allows for streaming and ingest. It's also a mature technology used in a lot of places.
One of the best ways we have when working asynchronously is Reactive extensions. From a user interface perspective it's easy, it's the Observable pattern.
You will not be able to change versions and message formats 20-30 times a day without disrupting the infrastructure unless you think carefully about versioning, message layout and dependencies.

Show notes

00:25 A title containing WebSockets, Reactive APIs and Microservices seems to contain a lot of buzzwords and hype, but a lot of these techniques are actually in use today.
00:35 We are in a state of constant evolution as computer scientists, architects or software engineers. Everything is changing, so waiting for a technique to become mature is not that useful anymore.
01:30 This is a story in three parts; about WebSockets, Reactive APIs and Microservices.

Websockets

02:10 Request-response has never been enough. We have always added something else, for instance stream data.
02:30 We are coming from an old HTTP specification with synchronous request-response, but just two years ago a redefinition of HTTP was done.
04:00 HTTP is an application level protocol, designed for serving documents, mostly with static content.
04:20 "Everything changes and nothing stands still", a quote from Heraclitus of Ephesus.
04:40 We have seen changing needs, like data feeds, interactivity and cancelling a transfer of large documents, none which is supported by HTTP/1.1
05:10 WebSockets came around in 2013 when it was standardized but goes back to 2007.
05:24 The idea of WebSockets is to take the existing pieces of HTTP and override them. It upgrades the protocol to support asynchronous request-response and allow for streaming and ingest.
06:13 WebSockets is a mature technology used in a lot of places.
06:20 WebSockets starts with a HTTP-connection which after an initial handshake is upgraded to a WebSocket. After that it's just byte exchange on each side.
07:32 Some challenges using WebSockets are hostile intermediaries, load balancing and TLS termination.
08:50 One of the best way to deal with hostile intermediaries is to use push in both directions.
09:02 A lot of load balancing products now supports WebSockets.
09:08 There are lots of different options for TLS termination.
09:30 One example on use of WebSockets are telemetry or live data feeds, for instance a stock exchange pushing data out.
10:30 An extension of the previous example is interactivity where a trader reacts by sending requests or commands over the same connection.
11:20 A few years ago a million connections on a server was a lot, today it's rather common, together with hundreds of thousands of messages a second going over them.
11:44 Responsiveness in a user interface is a third example where WebSockets can make a difference by asynchronously sending and receiving messages from the backend.

Reactive APIs

13:00 With asynchronous UIs and the ability to do execution on live data streams we have created reactivity, and the complexity this can bring has to be handled.
13:52 Simple UIs always wins over more common, complex UIs.
14:04 Today asynchronous is the norm, but composition of asynchronous behaviour can be hard.
14:46 One of the best ways we have when working asynchronously is Reactive extensions. From a UI perspective it's easy, it's the Observable pattern.
17:00 One challenge is non-blocking back pressure with finite use and asynchronous processing. ReactiveStreams and RxJava 2.0 have a simple API that also can deal with back pressure.
16:38 Heterogeneous connectivity can also be a problem. How do you agree on protocol or encoding with different reactive libraries in frontend and backend?
17:44 The different Rx libraries are commonly used for asynchronous UIs and they work really well, simplifying some of the more complex use cases and provide a comprehensive error handling.
19:25 An API is a protocol and should be treated as one, meaning we have to think about the treatment and formatting, but also about correct etiquette and precedence.
21:50 Web Services is a kind of a Reactive API.
23:13 Then HTTP/2 happened. "We didn't really do a good job on HTTP/1, can we do better with 2?"
24:10 Basically SPDY was standardized and evolved into HTTP/2 mid 2015.
24:20 HTTP/2 provide true asynchronous request and response along with streaming or server push.
24:37 The ability to do what was normally done with web services, but with HTTP/2 is a real game changer.
24:50 HTTP/2 feature set includes:
Persistent connection, a browser now needs only one tcp connection with everything duplexed on top of it.
Binary encoding for efficiency.
Multiple stream.
Efficient headers (HPACK).
Server push.
25:31 With HTTP/2, It is now fairly simple to implement Framing, Streams and Settings.
26:05 For APIs, HTTP/2 means there will be interesting times ahead. It's now possible to do a lot of things that wasn't possible with HTTP/1. The complexity is not dramatically different but opens up a lot of different avenues.
26:25 GRPC uses HTTP/2 as the transport mechanism underneath.
26:30 With more experience with the protocol and how to implement new ideas it will become more attractive to many organizations.

Microservices

27:40 Microservices is about moving faster with confidence.
28:00 The core to strive for includes:
Service independence
Fast service evolution
Service isolation
Independent deployability.
28:52 At the innermost core it's really about component decoupling. Between services we want asynchronous binary boundaries, removing the temporal dependency and enforcing that e.g. an object must be encoded across the boundary.
30:25 Serverless and lambda is a step to a new logical extreme. Making the state smaller means less to do and less dependencies.
30:45 Protocols couple things together. Examples include:
Version dependence.
Response dependence
Insufficient encapsulation
3^rd party service dependence
32:25 Message layout brings several questions, including:
To serialize an object or not. Most of the time messages are just messages, a short-lived thing sent from one place to another, not objects that have to be serialized.
To schema or not. Often the discussion is similar to the one comparing static with dynamic typing.
Efficiency is often overlooked. Choosing the right encoding can make a huge difference.
34:45 Simple Binary Encoding (SBE) is a tool for encoding and decoding in a binary format. It is schema based but may be interesting if parsing takes a long time.
35:55An old argument is if a client should be given a thick client or a specified protocol, (which often will have both an over-specified and an under-specified part).
37:19 With a client you are giving out, like an SDK, it's often tempting to add logic that is not part of the protocol, giving a thick client with a lot of different contexts within.
38:18 In a lot of cases you have to do both, a specified protocol that describes how it works, but also a kick-starter client that shows how to use the protocol. In some sense the client is the distribution of the protocol.
38:58 Almost everyone is doing microservices in some aspect or another. Many of the ESBs can be seen as microservices, although bigger than normally seen. Most payment system also. But the size may be larger than you typically think.
39:37 In the trading environment people has been building pieces of trading architecture, using messaging to tie components together. The more successful ones were shrinking the size of the services to make them quicker to evolve and easier to deploy.
40:34 To get a really responsive or asynchronous user interface requires shrinking a lot of the internal backend services.
41:10 The idea of deploying in trading was overwhelming many years ago. Today some constantly deploy but also change versions and message formats.
42:15 You will not be able to change versions and message formats 20-30 times a day without disrupting the infrastructure unless you think carefully about versioning, message layout and dependencies.
42:35 All these techniques are not revolutionary new, it's more of a constant evolution.