2 posts tagged with "project"

Lately we decided to promote Spawn from eigr-labs to the main eigr github organization: https://github.com/eigr/spawn. At the same time we archived the massa proxy repository and explained our motivation behind it.

It has been three years ago when we met in a new open source community while we tried to make a then shiny new project successful–https://cloudstate.io/. While we've discovered and also implemented a communications procotol for a multitude of programming languages, we constantly iterated on ideas how to build a system that is able to scale and also being usable on many places not only on backend services. At the time we discovered the serverless space, having also solved the stateful aspect of it by using a then promising new procotol and concept called Cloudstate. After some re-priorization with the project as a whole, the core OSS community moved on to build eigr.io and discover our ideas under this new umbrella organization https://eigr.io/.

The Actor Mesh​

Over the last couple of months, Spawn has been shaped by our vision to have a simpler and more focused way to bring an actor system to a polyglot environment, where the way of how components can interact like Actors and Processes do, is not that well known in other languages. eigr/Massa always was about to solve the challenge of stateful serverless, like it took the vision from its originating project. But at the same time Massa also tried always to solve two things at the same time. Building a polyglot serverless runtime and also solve the aspect of statefull serverless has been sometimes being too much at the same time. Spawn is a focused effort to solve one problem first, and then, being enabled to build the stateful aspect of serverless on top of it. In this regard, we focus now on something that is that enabler and perhaps one for other problems to solve.

This has been the work of ours lead by Adriano with help from Wesley and Elias; beside that I was able to participate a bit in discussions and presenting our project a two occasions over the last year. I'm looking forward to see Spawn growing into something really cool, special and useful. There is still a lot of work ahead of us and we're very exited to see how we can collaborate and grow as a project.

The Future of Eigr is based on Spawn​

We are 100% focused on making Spawn a robust, scalable, dynamic and expandable platform, taking us far beyond what we imagined we were capable of in the initial Cloudstate project and with our previous implementation of Massa. Massa has served us brilliantly as a means of experimentation, and now I feel deeply that we are ready to accomplish whatever we set out to do.

We invite everyone who is here to download and try Spawn and that we are ready to welcome those who want to contribute, whether with doubts, suggestions, a little code is also welcome, or a text review, any contribution is welcome. We greatly admire all of you who are interested in our project.

My name is Adriano, I'm a software engineer, I'm 40 years old, I'm Brazilian, and I've been in the technology area for over 20 years on different fronts and having worked in a long list of companies, I'm also the co-founder of the Eigr project together with @marcellanz and @guyso, previously the three of us were core members of the Cloudstate project and mainly worked on the supporting SDKs, but we also participated in the central development of Cloudstate technology and collaborated a lot on the development mainly of its protocol.

I see that many of you have just arrived here and that's why I think it's important to give an overview of what we do and talk a little about the current status of the project.

Well, let's go!

Overview:​

Our ecosystem is called Eigr, and we focus mainly on the following projects:

• Eigr Functions Controller: it's our deployment brain in Kubernetes, it controls the entire lifecycle of our sidecar along with user functions.

• Massa: is a Sidecar Proxy and part of the Eigr Functions offering that aims to provide a high-level abstraction for General Purpose Stateful Serverless application development.

Massa is responsible for managing the entire data access infrastructure for user functions, as well as other technical tasks such as providing the implementation of the user contract via gRPC to the outside world, transcoding HTTP requests to gRPC, caching, making requests to external sources when requested and other tasks that would once have to be performed by the developer directly in his application.

With Massa the developer only has to worry about their domain objects and their user service interface via a contract-first declarative approach. These two components together form Eigr Functions.

In addition to these projects, we also work on several other R&D projects that allow us to understand certain parts of the problem we are trying to solve and thus apply the acquired knowledge to the main projects. Research projects worth noting are the following:

• Falco: A fork of the elixir-grpc project where we try to improve performance and provide a replacement for the original project that is not being updated by the community that created it. Its development continues in research status.

• Steinadler: A high-level alternative to Erlang Distribution. While we are aware of the incredible capabilities of the Erlang Distribution, we also know that there are numerous deficiencies in this protocol that we are trying to address. Its development is currently at a standstill.

• Spawn: The Actor Mesh Framework is based on the [sidecar proxy pattern] (https://dzone.com/articles/sidecar-design-pattern-in-your-microservices-ecosy-1) to provide the multi-language Actor Model framework. Spawns' technology-stack on top of the BEAM VM (the Erlang virtual machine) provides support for different languages from its native Actor model. Spawn is made up of the following components:

  1. A semantic protocol based on Protocol Buffers.

  2. A Sidecar Proxy written in Elixir that implements this protocol as well as persistent storage adapters.

  3. SDKs to support different programming languages.

  Spawn is currently in full development where its main parts will likely be incorporated into the core of Massa.

• Astreu (https://github.com/eigr/Astreu): High-performance Messaging System based on a gRPC protocol written in Elixir. Your development is on hold (usable for testing).

Eigr Functions!​

Currently, the Massa project, where our greatest effort is concentrated, is capable of communicating with user functions that implement the Cloudstate protocol in version 0.5 and is capable of dealing only with Action-type entities, which are stateless entities.

In the next version of our proxy, we will probably no longer support the Cloudstate protocol because, once Cloudstate has been discontinued, we will adopt our own Protocol and entities.

We intend to support all the original project entity types, namely Action a.k.a. Stateless support, Event Sourcing, Value Entity (CRUD), and CRDTs (Conflict Free Replicated Data Types). We will just not bring the semantics of the previous protocol, and creating our own protocol to support these entities.

So we are in the process of a complete redesign of our protocol and therefore our proxy as well. We are doing this with proof of concepts in parallel projects and in project-specific branches within Massa.

This is a summary of what we have done and where we intend to go. I hope to be able to count on your collaboration in any way, with code, with good discussions, answering doubts, or just making small talk around here.

I'm curious to know a little more about you and what you expect from us.

Ah, I was forgetting, for those who want to know the reasons for the name Massa I suggest reading here.

Thanks for reading!