Abstract: Asynchronous and non-blocking execution is a highly coveted attribute of high volume web services. Server side web services strive to make contractual agreements upon interface based APIs to other services, assuming their environments to be highly-available, recoverable, & loosely-coupled. However these attributes are often in direct disagreement with an APIs implementation given: (1) the underlying multi-threaded libraries an API must rely upon and (2) the outside data source whose assets must be operated upon before an API can complete. This hindrance often results in contractual agreements across services tying down & blocking the multithreaded resources of a given architecture. This bottleneck is only half solved by frameworks where asynchronous request processing is paired with either NoSQL or SQL databases whose data access must block an incoming thread in order to make durable mutations on an asset. Techniques such as caching & sharding in-memory data structures alleviate the bottleneck for modifications on data at the cost of added complexity; exposing a view of the data that cannot be atomically mutated, results in complex and eventually consistent architectures.
In this paper we introduce Baratine, an asynchronous web framework with an improved thread and data execution model. By only accessing data for a particular service on a single thread, Baratine provides an authoritative owner of data services to be operated on continuously, solving both (1) & (2) sources of the aforementioned bottleneck. These services can persist no state operating entirely in-memory, persist to Baratine’s internal reactive document-style database or choose to persist to a traditional outside datasource. Baratine’s internals provide high availability, recoverability, and thread context isolation to each service within its environment. Baratine puts forth an API level abstraction for developing services that match the POJO style of Java EE & Spring applications prevalent in today’s architecture.
Abstract: We present Baratine as an asynchronous facade that can be placed in front of an existing library with no modifications to the library’s code base. Thus accomplishing two tasks: (1) exposing the library as a web service available to any language and (2) simplifying the requirements to have a nonblocking scalable (shardable + able to be partitioned) web service.
We have done this to illustrate how Baratine’s POJO platform provides an API-centric approach to building high performing microservices.Through performance benchmarks we show that a good purpose system built in Baratine can compete with a special purpose system built around a specific library.
Abstract: This paper explores the architecture of a web application composed as a set of Baratine services. Each individual service functions as an implementation of the the applications API that can be sharded and scaled on a per service basis. Thus the application can be said to be a network of loosely-coupled microservices, using the Baratine platform.
The application also demonstrates Baratine's single data ownership and non-blocking principles. Throughout the application, immutable data is accessed only through a single-owning thread, providing automatic batching performance and high throughput. This principle also eliminates the possibility of data access bottlenecks and synchronization.
Abstract: Bartil is a Baratine service that exposes common data structures as REST services. Bartil provides a map, list, tree, string, and counter type that are callable from any client supporting WebSockets or HTTP. You can store any object as the key or value field in the map, list, and tree data types.
Bartil services are persistent; they are stored into Baratine's internal key-value store, io.baratine.core.Store. Saves to the store are batched for high performance and efficiency. Bartil uses a journal to ensure that batched saves are reliable and protected from data loss.Bartil services are addressed by URL. This enables clustering out of the box with no change in code. When Bartil is deployed to a multi-server Baratine pod (virtual cluster), its services become sharded automatically; requests are hashed on the URL and sent to the owning server.
In many ways, Bartil is very similar to Redis; thus, Bartil services should be familiar to Redis users. Bartil shows that you can write any kind of Baratine service that runs about as fast as Redis, but with much more functionality (without having to resort to Lua scripting).