Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
REACTIVE	POLYGLOT
MICROSERVICES	WITH
OPENSHIFT	AND	VERT.X
	
CLEMENT	ESCOFFIER
Vert.x	Core	Developer,	Red	Hat
VERT.X
I N 	 1 0 	 S L I D E S . . .
V E R T. X 	I S 	 A 	 TO O L K I T 	T O 	 B U I L D
D I S T R I B U T E D 	 A N D 	 R E AC T I V E
S Y S T E M S 	 O N 	 T...
TOOLKIT
Vert.x	is	a	plain	boring	jar
Your	application	depends	on	this	set	of	jars	(classpath,	fat-
jar,	...)
DISTRIBUTED
“ 	You	know	you	have	a	distributed	system	when	the	crash
of	a	computer	you've	never	heards	of	stops	you	from	g...
REACTIVE
Reactive	systems	are
Responsive	-	they	respond	in	an	acceptable	time
Elastic	-	they	scale	up	and	down
Resilient	-...
POLYGLOT
vertx.createHttpServer()
.requestHandler(req -> req.response().end("Hello Java"))
.listen(8080);
vertx.createHttp...
MICROSERVICES
R E B R A N D I N G
D I S T R I B U T E D
A P P L I C A T I O N S
MICROSERVICES
“ 	The	microservice	architectural	style	is	an	approach	to
developing	a	single	application	as	a	suite	of	smal...
A	SUITE	OF	INDEPENDENT
SERVICES:
Each	service	runs	in	its	own	process
So	they	are	distributed	applications 	
Lightweight	i...
A	SUITE	OF	INDEPENDENT
SERVICES:
Independently	developed,	tested	and	deployed
Automated	process
(Liskov)	substitutability
...
NO	FREE	LUNCH
VERT.X	&	MICROSERVICES
We	wont'	build	regular	microservices,	but	reactive
microservices
Responsive	-	fast,	is	able	to	hand...
PICK	YOUR	OWN
DEVELOPMENT	MODEL
vertx.createHttpServer()
.requestHandler(request -> {
doA("Austin", ar -> {
doB("Reactive ...
PICK	YOUR	OWN
DEVELOPMENT	MODEL
vertx.createHttpServer()
.requestHandler(request -> {
Future<String> a = doA("Austin");
Fu...
PICK	YOUR	OWN
DEVELOPMENT	MODEL
vertx.createHttpServer()
.requestHandler(request -> {
CompletableFuture<String> a = doA("A...
PICK	YOUR	OWN
DEVELOPMENT	MODEL
HttpServer server = vertx.createHttpServer();
server.requestStream().toObservable()
.subsc...
WHAT	DOES	VERT.X
PROVIDE	TO	BUILD
MICROSERVICES?
TCP,	UDP,	HTTP	1	&	2	servers	and	clients
(non-blocking)	DNS	client
Event	...
HTTP	&	REST
B E C A U S E 	 I T 	 A L W A Y S
B E G I N 	 W I T H 	 A 	 R E S T
VERT.X	HELLO	WORLD
vertx.createHttpServer()
.requestHandler(request -> {
// Handler receiving requests
request.response()....
VERT.X	HELLO	WORLD
Invoke
E V E N T 	 L O O PS
VERT.X	ASYNC	HTTP	CLIENT
HttpClient client = vertx.createHttpClient(
new HttpClientOptions()
.setDefaultHost(host)
.setDef...
SERVICE	DISCOVERY
Locate	the	services,	environment-agnostic
SERVICE	DISCOVERY	-
KUBERNETES
No	need	for	publication	-	Import	Kubernetes	services
HttpEndpoint.getClient(discovery,
new ...
CHAINED	HTTP	REQUESTS
Invoke
MESSAGING	WITH
THE	EVENT	BUS
T H E 	 S P I N E 	 O F 	 V E R T . X
A P P L I C A T I O N S
THE	EVENT	BUS
The	event	bus	is	the	nervous	system	of	vert.x:
Allows	different	components	to	communicate	regardless
the	imp...
POINT	TO	POINT
vertx.eventBus().send("address", "message");
vertx.eventBus().consumer("address", message -> {});
PUBLISH	/	SUBSCRIBE
vertx.eventBus().publish("address", "message");
vertx.eventBus().consumer("address", message -> {});
REQUEST	/	RESPONSE
vertx.eventBus().send("address", "message", reply -> {});
vertx.eventBus().consumer("address",
message ...
DISTRIBUTED	EVENT	BUS
Almost	anything	can	send	and	receive	messages
DISTRIBUTED	EVENT	BUS
Let's	have	a	java	(Vert.x)	app,	and	a	node	app	sending	data
just	here:
bonjour	from	node	(248)
hello...
DISTRIBUTED	EVENT	BUS
EVENTBUS	CLIENTS	AND
BRIDGES
Bridges
SockJS:	browser,	node.js
TCP:	languages	/	systems	able	to	open	a	TCP	socket
Stomp
AMQ...
RELIABILITY
PATTERNS
D O N ' T 	 B E 	 F O O L , 	 B E
P R E P A R E D 	 T O 	 FA I L
RELIABILITY
It's	not	about	being	bug-free	or	bullet	proof,
it's	impossible.
It's	about	being	prepared	to	fail,
and	handlin...
MANAGING	FAILURES
Distributed	communication	may	fail
vertx.eventbus().send(..., ...,
new DeliveryOptions().setSendTimeout(...
MANAGING	FAILURES
	
Invoke
CIRCUIT	BREAKER
CIRCUIT	BREAKER
cb.executeWithFallback(future -> {
// Async operation
client.get("/", response -> {
response.bodyHandler(b...
CIRCUIT	BREAKER
	 Invoke
SCALABILITY
PATTERNS
B E 	 P R E P A R E D 	 T O 	 B E
F A M O U S
E L A S T I C I T Y 	 P A T T E R N S
BALANCING	THE	LOAD
When	several	consumers	listen	to	the	same	address,	Vert.x
dispatches	the	sent	messages	using	a	round	ro...
BALANCING	THE	LOAD
BALANCING	THE	LOAD
Invoke
SCALING	HTTP
THIS	IS	NOT	THE
END()
BUT	THE	FIRST	STEP	ON	THE	REACTIVE
MICROSERVICE	ROAD
HOW	TO	START	?
https://www.openshift.org 	
http://vertx.io
http://vertx.io/blog/posts/introduction-to-vertx.html
http://es...
@clementplop
THANK	YOU!
					clement.escoffier@redhat.com
Reactive Polyglot Microservices with OpenShift and Vert.x
Reactive Polyglot Microservices with OpenShift and Vert.x
Upcoming SlideShare
Loading in …5
×

Reactive Polyglot Microservices with OpenShift and Vert.x

470 views

Published on

Vert.x is a framework to create reactive distributed and polyglot applications on the Java Virtual Machine.

Vert.x takes the JVM to new levels of performance yet having a small API. It lets you build scalable microservice-based applications transparently distributed and packaged as a single jar file.

Due to this simplicity, deploying and managing Vert.x applications on OpenShift is a breeze, upload your jar and Vert.x internal cluster manager will connect all your pods in single distributed network. Several examples are shown during the talk and demonstrate how Vert.x can simplify DevOps daily job when working together with OpenShift such as deployment, rolling updates, monitoring, metrics...

Published in: Technology
  • Be the first to comment

Reactive Polyglot Microservices with OpenShift and Vert.x

  1. 1. REACTIVE POLYGLOT MICROSERVICES WITH OPENSHIFT AND VERT.X CLEMENT ESCOFFIER Vert.x Core Developer, Red Hat
  2. 2. VERT.X I N 1 0 S L I D E S . . .
  3. 3. V E R T. X I S A TO O L K I T T O B U I L D D I S T R I B U T E D A N D R E AC T I V E S Y S T E M S O N T O P O F T H E J V M U S I N G A N A S Y N C H R O N O U S N O N - B L O C K I N G D E V E L O P M E N T M O D E L .
  4. 4. TOOLKIT Vert.x is a plain boring jar Your application depends on this set of jars (classpath, fat- jar, ...)
  5. 5. DISTRIBUTED “ You know you have a distributed system when the crash of a computer you've never heards of stops you from getting any work done. (Leslie Lamport)
  6. 6. REACTIVE Reactive systems are Responsive - they respond in an acceptable time Elastic - they scale up and down Resilient - they are designed to handle failures gracefully Asynchronous - they interact using async messages http://www.reactivemanifesto.org/
  7. 7. POLYGLOT vertx.createHttpServer() .requestHandler(req -> req.response().end("Hello Java")) .listen(8080); vertx.createHttpServer() .requestHandler({ req -> req.response().end("Hello Groovy") }) .listen(8080) vertx.createHttpServer() .requestHandler(function (req) { req.response().end("Hello JavaScript") }) .listen(8080); vertx.createHttpServer() .requestHandler(req => req.response().end("Hello Scala")) .listen(8080)
  8. 8. MICROSERVICES R E B R A N D I N G D I S T R I B U T E D A P P L I C A T I O N S
  9. 9. MICROSERVICES “ The microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies. (Martin Fowler)
  10. 10. A SUITE OF INDEPENDENT SERVICES: Each service runs in its own process So they are distributed applications Lightweight interactions - Loose-coupling Not only HTTP Messaging Streams (async) RPC
  11. 11. A SUITE OF INDEPENDENT SERVICES: Independently developed, tested and deployed Automated process (Liskov) substitutability It's all about agility
  12. 12. NO FREE LUNCH
  13. 13. VERT.X & MICROSERVICES We wont' build regular microservices, but reactive microservices Responsive - fast, is able to handle a large number of events / connections Elastic - scale up and down by just starting and stopping nodes, round-robin Resilient - failure as first-class citizen, fail-over Asynchronous message-passing - asynchronous and non- blocking development model
  14. 14. PICK YOUR OWN DEVELOPMENT MODEL vertx.createHttpServer() .requestHandler(request -> { doA("Austin", ar -> { doB("Reactive Summit", ar2 -> { request.response().end(ar.result() + "n" + ar2.result()); }); }); }).listen(8080);
  15. 15. PICK YOUR OWN DEVELOPMENT MODEL vertx.createHttpServer() .requestHandler(request -> { Future<String> a = doA("Austin"); Future<String> b = doB("Reactive Summit"); CompositeFuture.all(a, b).setHandler(ar -> { request.response().end(a.result() + "n" + b.result()); }); }).listen(8080);
  16. 16. PICK YOUR OWN DEVELOPMENT MODEL vertx.createHttpServer() .requestHandler(request -> { CompletableFuture<String> a = doA("Austin"); CompletableFuture<String> b = doB("Reactive Summit"); CompletableFuture.allOf(a, b).thenRun(() -> { request.response().end(a.join() + "n" + b.join()); }); }).listen(8080);
  17. 17. PICK YOUR OWN DEVELOPMENT MODEL HttpServer server = vertx.createHttpServer(); server.requestStream().toObservable() .subscribe(req -> { Observable<String> a = doA("Austin"); Observable<String> b = doB("Reactive Summit"); Observable.zip(a, b, (s1, s2) -> s1 + "n" + s2) .subscribe(s -> req.response().end(s)); }); server.listen(8080);
  18. 18. WHAT DOES VERT.X PROVIDE TO BUILD MICROSERVICES? TCP, UDP, HTTP 1 & 2 servers and clients (non-blocking) DNS client Event bus (messaging) Distributed data structures Load-balancing Fail-over Service discovery Failure management, Circuit-breaker Shell, Metrics, Deployment support
  19. 19. HTTP & REST B E C A U S E I T A L W A Y S B E G I N W I T H A R E S T
  20. 20. VERT.X HELLO WORLD vertx.createHttpServer() .requestHandler(request -> { // Handler receiving requests request.response().end("World !"); }) .listen(8080, ar -> { // Handler receiving start sequence completion (AsyncResult) if (ar.succeeded()) { System.out.println("Server started on port " + ar.result().actualPort()); } else { ar.cause().printStackTrace(); } });
  21. 21. VERT.X HELLO WORLD Invoke
  22. 22. E V E N T L O O PS
  23. 23. VERT.X ASYNC HTTP CLIENT HttpClient client = vertx.createHttpClient( new HttpClientOptions() .setDefaultHost(host) .setDefaultPort(port)); client.getNow("/", response -> { // Handler receiving the response // Get the content response.bodyHandler(buffer -> { // Handler to read the content }); });
  24. 24. SERVICE DISCOVERY Locate the services, environment-agnostic
  25. 25. SERVICE DISCOVERY - KUBERNETES No need for publication - Import Kubernetes services HttpEndpoint.getClient(discovery, new JsonObject().put("name", "vertx-http-server"), result -> { if (result.failed()) { rc.response().end("D'oh no matching service"); return; } HttpClient client = result.result(); client.getNow("/", response -> { response.bodyHandler(buffer -> { rc.response().end("Hello " + buffer.toString()); }); }); });
  26. 26. CHAINED HTTP REQUESTS Invoke
  27. 27. MESSAGING WITH THE EVENT BUS T H E S P I N E O F V E R T . X A P P L I C A T I O N S
  28. 28. THE EVENT BUS The event bus is the nervous system of vert.x: Allows different components to communicate regardless the implementation language and their location whether they run on vert.x or not (using bridges) Address: Messages are sent to an address Handler: Messages are received in handlers.
  29. 29. POINT TO POINT vertx.eventBus().send("address", "message"); vertx.eventBus().consumer("address", message -> {});
  30. 30. PUBLISH / SUBSCRIBE vertx.eventBus().publish("address", "message"); vertx.eventBus().consumer("address", message -> {});
  31. 31. REQUEST / RESPONSE vertx.eventBus().send("address", "message", reply -> {}); vertx.eventBus().consumer("address", message -> { message.reply("response"); });
  32. 32. DISTRIBUTED EVENT BUS Almost anything can send and receive messages
  33. 33. DISTRIBUTED EVENT BUS Let's have a java (Vert.x) app, and a node app sending data just here: bonjour from node (248) hello from java (286) bonjour from node (247) hello from java (285) bonjour from node (246) hello from java (284) bonjour from node (245) hello from java (283) bonjour from node (244)
  34. 34. DISTRIBUTED EVENT BUS
  35. 35. EVENTBUS CLIENTS AND BRIDGES Bridges SockJS: browser, node.js TCP: languages / systems able to open a TCP socket Stomp AMQP Camel Clients: Go, C#, C, Python, Swift...
  36. 36. RELIABILITY PATTERNS D O N ' T B E F O O L , B E P R E P A R E D T O FA I L
  37. 37. RELIABILITY It's not about being bug-free or bullet proof, it's impossible. It's about being prepared to fail, and handling these failures.
  38. 38. MANAGING FAILURES Distributed communication may fail vertx.eventbus().send(..., ..., new DeliveryOptions().setSendTimeout(1000), reply -> { if (reply.failed()) { System.out.println("D'oh, he did not reply to me !"); } else { System.out.println("Got a mail " + reply.result().body()); } });
  39. 39. MANAGING FAILURES Invoke
  40. 40. CIRCUIT BREAKER
  41. 41. CIRCUIT BREAKER cb.executeWithFallback(future -> { // Async operation client.get("/", response -> { response.bodyHandler(buffer -> { future.complete("Hello " + buffer.toString()); }); }) .exceptionHandler(future::fail) .end(); }, // Fallback t -> "Sorry... " + t.getMessage() + " (" + cb.state() + ")" ) // Handler called when the operation has completed .setHandler(content -> /* ... */);
  42. 42. CIRCUIT BREAKER Invoke
  43. 43. SCALABILITY PATTERNS B E P R E P A R E D T O B E F A M O U S
  44. 44. E L A S T I C I T Y P A T T E R N S
  45. 45. BALANCING THE LOAD When several consumers listen to the same address, Vert.x dispatches the sent messages using a round robin. So, to improve the scalability, just spawn a new node!
  46. 46. BALANCING THE LOAD
  47. 47. BALANCING THE LOAD Invoke
  48. 48. SCALING HTTP
  49. 49. THIS IS NOT THE END() BUT THE FIRST STEP ON THE REACTIVE MICROSERVICE ROAD
  50. 50. HOW TO START ? https://www.openshift.org http://vertx.io http://vertx.io/blog/posts/introduction-to-vertx.html http://escoffier.me/vertx-hol Secure Enclaves For Reactive Cloud Applications
  51. 51. @clementplop THANK YOU! clement.escoffier@redhat.com

×