While everyone is talking about ‘stateless’ services as a way to achieve scalability and high availability, the truth is that they are about as real as the unicorns. Building applications and services that way simply pushes the problem further down the stack, which only makes it worse and more difficult to solve (although, on the upside, it might make it somebody else’s problem). This is painfully obvious when building microservices, where each service must truly own its state. The reality is that you don’t need ‘stateless’ services to either scale out or be fault tolerant — what you really need is a scalable, fault tolerant state management solution that you can build your services around. In this talk we will discuss how some of the popular microservices frameworks are tackling this problem, and will look at technologies available today that make it possible to build scalable, highly available systems without ‘stateless’ service layers, whether you are building microservices or good ol’ monoliths.

1. THE ILLUSION OF STATELESSNESS
ALEKSANDAR SEOVIC
Architect, Oracle Coherence
See all the presentations from the In-Memory Computing
Summit at http://imcsummit.org

2. WARNING

3. STUPID SHIT YOU CAN FIND ON THE WEB, TAKE 1
Bottom line: Stateless apps are ideal.
Server-side database writes are your enemy. If you
must save state, save it on the client. Use cookies and
Ajax where appropriate.
If you follow this rule, you will multiply your scalability.

4. STUPID S#!T YOU CAN FIND ON THE WEB, TAKE 1
Bottom line: Stateless apps are ideal.
Server-side database writes are your enemy. If you
must save state, save it on the client. Use cookies and
Ajax where appropriate.
If you follow this rule, you will multiply your scalability.

5. STUPID SHIT YOU CAN FIND ON THE WEB, TAKE 1
Bottom line: Stateless apps are ideal.
Server-side database writes are your enemy. If you
must save state, save it on the client. Use cookies and
Ajax where appropriate.
If you follow this rule, you will multiply your scalability.

6. STUPID SHIT YOU CAN FIND ON THE WEB, TAKE 2
Services should be stateless. One benefit that you get from
this is scalability. You can move expensive operations to a
cluster of dedicated machines and it does not matter which
one responds to a particular request since all of them are
independent.

7. STUPID S#!T YOU CAN FIND ON THE WEB, TAKE 2
Services should be stateless. One benefit that you get from
this is scalability. You can move expensive operations to a
cluster of dedicated machines and it does not matter which
one responds to a particular request since all of them are
independent.

8. STUPID SHIT YOU CAN FIND ON THE WEB, TAKE 2
Services should be stateless. One benefit that you get from
this is scalability. You can move expensive operations to a
cluster of dedicated machines and it does not matter which
one responds to a particular request since all of them are
independent.

9. AND FINALLY SOMEONE WITH A SENSE OF HUMOR…
http://whatis.techtarget.com/definition/stateless

10. AND FINALLY SOMEONE WITH A SENSE OF HUMOR…
http://whatis.techtarget.com/definition/stateless

11. AND FINALLY SOMEONE WITH A SENSE OF HUMOR…
http://whatis.techtarget.com/definition/stateless

12. FACT #1
HTTP protocol is stateless

13. FACT #2
But your RESTful service is not

14. AN EXAMPLE OF A TRULY STATELESS SERVICE
@Path("calc")
public class Calculator
{
@GET
@Path("add")
public int add(@QueryParam("x") int x, @QueryParam("y") int y)
{
return x + y;
}
}

15. AN EXAMPLE OF A “STATELESS” SERVICE
@Path("cart")
public class CartService
{
@POST
public Response addItem(
@CookieParam("user.id") String userId,
@FormParam("sku") String sku,
@FormParam("price") BigDecimal price)
{
Cart cart = cartDao.getCartForUser(userId);
cart.add(sku, price, 1);
cartDao.save(cart);
return Response.ok().build();
}
@Inject
private CartDao cartDao;
}

16. MYTH
“Stateless” services scale better

17. (REALLY) LIVE DEMO
NEED A FEW VOLUNTEERS…

18. FACT #3
“Stateless” services scale only as
good as the state management
layer they depend on

19. BIG QUESTION
So how do we really build scalable
services and applications then?

20. RULE #1
Separate state management and
durability aspects.
Manage state in memory, using
technology that allows you to scale.

21. EXAMPLE: LIGHTBEND LAGOM

22. EXAMPLE: ORACLE COHERENCE

23. EXAMPLE: APACHE IGNITE

24. EXAMPLE: ON DISK DURABILITY

25. EXAMPLE: MULTI-DATACENTER DURABILITY

26. RULE #2
Don’t move data unless you
absolutely have to.
Send operations to the data instead.

27. AN EXAMPLE: NEAR CACHING

28. AN EXAMPLE: JAVA 8 LAMBDAS
@Path("cart")
public class CartService
{
@POST
public Response addItem(
@CookieParam("user.id") String userId,
@FormParam("sku") String sku,
@FormParam("price") BigDecimal price)
{
cartDao.process(userId, cart -> cart.add(sku, price, 1));
return Response.ok().build();
}
@Inject
private CartDao cartDao;
}

29. AN EXAMPLE: COHERENCE 12.2.1 DISTRIBUTED LAMBDAS
public <R> R process(String userId, Remote.Function<Cart, R> cartFunction)
{
return carts.invoke(userId, entry ->
{
Cart cart = entry.getValue();
R result = cartFunction.apply(cart);
entry.setValue(cart);
return result;
});
}

30. RULE #3
Do whatever you can
asynchronously

31. AN EXAMPLE: AT THE ARCHITECTURAL LEVEL
Is REST truly the best?

32. AN EXAMPLE: JAVA 8 CompletableFuture
// synchronous
cache.put(1, "Aleks");
// asynchronous
cache.async().put(1, "Aleks");
// synchronous
System.out.println("Name: " + cache.get(1));
// asynchronous
cache.async().get(1)
.thenAccept(name -> System.out.println("Name: " + name));

33. AN EXAMPLE: REACTIVE EXTENSIONS
// reactive
Observable<Void> observable = rx(cache).put(1, "Aleks");
rx(cache).get(1)
.subscribe(name -> System.out.println("Name: " + name));
https://github.com/coherence-community/coherence-
rx
CoherenceRx

34. RULE #4
Model complex processes as finite
state machines, and use events to
trigger state transitions

35. AN EXAMPLE: ORDER PROCESSING

36. RULE #5
Don’t use global locks, counters or
other stupid shit that prevents you
from scaling out.

37. EXAMPLES (OF WHAT NOT TO DO)

38. EXAMPLES (OF WHAT NOT TO DO)

39. EXAMPLES (OF WHAT NOT TO DO)

40. RECOMMENDED
READING

41. Q & A
THANK YOU!

42. Q & A
THANK YOU!