While application architectures are evolving to become stateless, application state and state management are naturally emerging as a service in themselves. This session outlines the development, operation, and maintenance of an application state service for the cloud with Java 9, using a serverless strategy. The presentation investigates some of the challenges of designing an infinite-capacity, infinite-processing platform capable of reliably running everything from the smallest application to a globally distributed enterprise-class infrastructure for the mobile and IoT domains.
This is especially pertinent to our session as we are showing a bit of in-progress work and sharing the lessons we have learned along the way. The exact feature set and pricing is still being determined.
ED
Letâs start off with a provocative statement and then pull it back a bit.
For all the hype about stateless architectures, all the buzz about REST, and the renewed popularity of pure functional languages and functional features of non-functional languages, the truth is that any useful application is going to have to deal with state.
Letâs be fair, though. Stateful apps do have a host of problems:
Side-effect class of bugs
Harder to parallelize
Harder to do real CQRS
Easy to be lazy Analogy, itâs like that one closet or drawer at home where you just throw stuff and close it.
And stateless architectures have many good properties
Composability
Distributability
Not to say it is not a good stance but perhaps you can maintain some of these benefits, such as composability, with state??
It is better to add state judiciously to an otherwise stateless system than just get lazy and throw state all over the place.
HR
Use call by reference analogy instead of call by value
ED/HR
Letâs take a look at some options that are in use to provide externalized state.
HR
Donât want to pay for what you donât use.
HR
Donât want to pay for what you donât use.
HR
Mention that you have to use SQL, or ORM.
HR
HR
HR
Returning to your data structures class.
When you get below the line: allows a client to deterministically know where an entry resides on a remote process without having any kind of consultation.
Mention this does not even mention the absolutely necessary concern of replication
We are building our state service on top of Oracle Bare Metal Cloud Service and a special version of Oracle Coherence.
Coherence has years of customer used, battle hardened Site Reliabiity Engineering experience inside.
Oracle Bare Metal Cloud
Microsecond latency in an AD
Guaranteed millisecond latency between availability domains.
Talk about coherence backup strength notion: node, machine, rack, site safety.
Even if you lose an AD, anything that was written to the store, will still be there.
Example: half TB ram 30 TB NVME, so we want to take advantage of that.
HR
Docker run state service
Switch to intellij
Create a main class, do Session.create(localhost)
Put some data, do a query,
Mention that this docker image does not mount any volumes, so we are not saving anything we put in here.
Provision CloudMap, mention this is K8s running on Oracle Public Cloud
Modify local program to point to it.
Show itâs empty
Add some data.
Share connection details, including Wercker (from todayâs keynote) auth token with Ed.
API Exploration, in Harveyâs IDE
HR
This is where we are taking advantage of NVME drives
The underlying Coherence has been modified to write everything to these disks.
This gives you rock solid phoenix system properties.
