Distributed Transactions and Microservices Still Don’t Mix

I’m talking as someone who has actually implemented multiple distributed transaction systems. People moving to microservices are now discovering a lot of the challenges and hurdles of distributed systems and it is only natural to want to go back to the cozy transactional world, where you can reason about things properly.

This post is in response to this article: Microservices and distributed transactions, which I read with interest, because it isn’t often that a post will refute it’s own premise with the very first statement.

Reviewing Sled: Part II

The first part is here. As a reminder, Sled is an embedded database engine written in Rust. It takes a very different approach for how to store data, which I’m really excited to see. And with that, let’s begin. I stopped in my last post when getting to the flusher, which simply sleeps and calls flush on the iobufs.

The next file is iobuf.rs.

Using TLS in Rust: The Complexity of Async, Macros, and Madness

After a lot of trouble, I’m really happy that I was able to build an async I/O implementation of my protocol. However, for real code, I think that I would probably recommend using with the sync API instead since at least it's straightforward and doesn’t incur so much overhead at development time. The async stuff is still very much a “use at your own risk” kind of deal from my perspective. And I can’t imagine trying to use it in a large project and no suffering from the complexity.

As a good example, take a look at the following bit of code:

Using TLS With Rust: Authentication

After running into a few hurdles, I managed to get rust openssl bindings to work, which means that this is now the time to actually wire things properly in my network protocol. Let’s see how that works, shall we?

First, we have the OpenSSL setup:

Making Money From Open Source Software: How We Do It

After my previous two posts on the topic, it is now time to discuss how we make money from Open Source Software. Before I start, I want to clarify what I’m talking about:

  • RavenDB is a document database.
  • It is about a decade old.
  • The server is released under the AGPL/commercial license.
    • We offer free community and developer licenses without any AGPL hindrance.
  • The RavenDB client APIs are licensed under the MIT license.
  • RavenDB (the product) is created by Hibernating Rhinos (the company).

I created RavenDB because I couldn’t not to. It was an idea that had to go out of my head. I looked up the details, and toward the end of 2008, I started to work on it as a side project. At the time I was involved in five or six active open source projects, had just gotten my NHibernate Profiler product to stable ground, and was turning the idea of getting deeper into databases in my head for a while. So I sat down and wrote some code.

Technical Presentation Delivery Notes

I’m writing this post as I’m sitting in the airport, leaving the CodeMash conference. This has been my first “true” conference for a while, because I was able to not just speak and stand in a sponsor booth but actually participate in a lot of sessions and talk to a lot of people. I had a blast, and both the IRS and my wife consider this a work trip.

I have been presenting in international conferences for over a decade now and I wanted to put in a few words for people who are speaking at a technical conference. None of this is new, mind you. If you have been reading any recommendations about how to present in conferences, I’m probably going to bore you. I’m writing this because I saw several sessions that had technical issues in how they were delivered. That is, the content was great, but the way it was delivered could be improved.

Data Modeling With Indexes: Event Sourcing (Part 1)

In this post, I want to take the notion of doing computation inside RavenDB’s indexes to the next stage. So far, we talked only about indexes that work on a single document at a time, but that's just the tip of the iceberg of what you can do with indexes inside RavenDB. What I want to talk about today is the ability to do computations over multiple documents and aggregate them. The obvious example is in the following RQL query:

That is easy to understand — it is simple aggregation of data. But it can get a lot more interesting. To start with, you can add your own aggregation logic in here, which opens up some interesting ideas. Event sourcing, for example, is basically a set of events on a subject that are aggregated into the final model. Probably the classiest example of event sourcing is the shopping cart example. In such a model, we have the following events:

Using TLS in Rust: Getting Async I/O With tokio (Part 2)

On my last post, I got really frustrated with tokio’s complexity and wanted to move to using mio directly. The advantages are that the programming model is pretty simple, even if actually working with it is hard. Event loops can cause your logic to spread over many different locations and make it hard to follow. I started to go that path until I figured out just how much work it would take. I decided to give tokio a second change, and at this point, I looked into attempts to provide async/await functionality to Rust.

It seems that at least some work is already available for this, using futures + some Rust macros. That let me write code that is much more natural looking, and I actually managed to make it work.

Self-Inflicted Wounds: The SSL Failure on the Linux Build Server

A nasty cousin of It Works On My Machine is the It Fails On That Machine. It is nasty because you know that there is something wrong, but you can’t reproduce it.

The machine in question was our Linux build agent, and the failure in question was a set of failing tests that failed to perform a certain operation when TLS was enabled. The problem? They were failing with I/O errors, but only with TLS, and the connection was using localhost. Further investigation showed that the most likely reason for the failure was a timeout. But how could that be? For fun, sometimes, the test passed. So it wasn’t an issue of a firewall of some kind. Testing using openssl s_server and connecting to it manually didn’t show any issues.

Data Modeling With Indexes: Predicting the Future

Computation during indexes opens up some nice features when we are talking about data modeling and working with your data. In this post, I want to discuss predicting the future with it. Let’s see how we can do that, shall we?

Consider the following document, representing a (simplified) customer model:

Using TLS in Rust: Going to async I/O With tokio (Part 1)

Now that we have a secured and authentication connection, the next stage in making a proper library is to make it run more than a single connection at a time. I could have used a thread per connection, of course, or even use a thread pool, but neither of those options is valid for the kind of work that I want to see, so I’m going to jump directly into async I/O in Rust and see how that goes.

The sad thing about this is that I expect that this will make me lose some/ all of the nice APIs that I get for OpenSSL in the sync mode.

Data Modeling With Indexes (Part 2): Business Rules

In my last post on the topic, I showed how we can define a simple computation during the indexing process. That was easy enough, for sure, but it turns out that there are quite a few use cases for this feature that go quite far from what you would expect. For example, we can use this feature as part of defining and working with business rules in our domain.

For example, let’s say that we have some logic that determines whatever a product is offered with a warranty (and for how long that warranty is valid). This is an important piece of information, obviously, but it is the kind of thing that changes on a fairly regular basis. For example, consider the following feature description:

Implementing PhantomReference in C# [Snippet]

I ran into this very interesting blog post and I decided to see if I could implement this on my own, without requiring any runtime support. This turned out the be surprisingly easy if you are willing to accept some caveats.

I’m going to assume that you have read the linked blog post, and here is the code that implements it:

Design Exercise: Distributing (Consistent) Data at Scale

The Question

Before I start discussing this topic, I want to talk a bit about the speed of light. That pesky limit basically means that there is an inherent lag in passing information between any two points in space. In your daily life, you can mostly ignore it. The human brain is far too slow to perceive it, and even if you are working with computers, you can usually ignore the speed of light for anything less than about 500 miles.

But the speed of light is merely the hard upper limit of our ability to send information from one location to another. In practice, the lag time between any two computers connected to a network is much higher. In fact, if you are a gamer, you are very well acquainted with that fact.

Fuel Your Blog