Successfully reported this slideshow.
Your SlideShare is downloading. ×

eigr.io A Serverless Runtime on the BEAM V1.3

Ad

A Serverless Runtime on the
BEAM
Code BEAM Europe
Marcel Lanz, 20 May 2022, Stockholm

Ad

• Serverless compute, Function as a Service
• Moving to the Cloud
• The eigr.io Project
• Eigr Functions
Code BEAM Europe,...

Ad

• How many of you run some serverless production workload in the cloud?
• How many of you run your entire production workl...

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Check these out next

1 of 20 Ad
1 of 20 Ad

eigr.io A Serverless Runtime on the BEAM V1.3

Download to read offline

Serverless runtimes are often hidden in a cloud providers offering and exposed solely by their programming API and deployment procedures. In this talk, we’ll explore an open-source Serverless runtime built for the cloud and on-premises, running on the BEAM with a polyglot programming model to build general purpose applications.

Serverless runtimes are often hidden in a cloud providers offering and exposed solely by their programming API and deployment procedures. In this talk, we’ll explore an open-source Serverless runtime built for the cloud and on-premises, running on the BEAM with a polyglot programming model to build general purpose applications.

More Related Content

eigr.io A Serverless Runtime on the BEAM V1.3

  1. 1. A Serverless Runtime on the BEAM Code BEAM Europe Marcel Lanz, 20 May 2022, Stockholm
  2. 2. • Serverless compute, Function as a Service • Moving to the Cloud • The eigr.io Project • Eigr Functions Code BEAM Europe, Stockholm, 2022 Agenda A Serverless Runtime on the BEAM
  3. 3. • How many of you run some serverless production workload in the cloud? • How many of you run your entire production workload in the cloud? • How many of you would trust a cloud provider with your entire production workload built as a serverless system and therefore don't own all of your stacks code? Code BEAM Europe, Stockholm, 2022 A Poll A Serverless Runtime on the BEAM
  4. 4. • How many of you run some serverless production workload in the cloud? • How many of you run your entire production workload in the cloud? • => 42% • How many of you would trust a cloud provider with your entire production workload built as a serverless system and therefore don't own all of your stacks code? • => 57% Code BEAM Europe, Stockholm, 2022 A Poll – Whova A Serverless Runtime on the BEAM
  5. 5. "A serverless architecture is a way to build and run applications and services without having to manage infrastructure. Your application still runs on servers, but all the server management is done by AWS." – by AWS Code BEAM Europe, Stockholm, 2022 Serverless – Definition #1 A Serverless Runtime on the BEAM
  6. 6. "Serverless is a cloud-native development model that allows developers to build and run applications without having to manage servers. There are still servers in serverless, but they are abstracted away from app development." – Redhat Code BEAM Europe, Stockholm, 2022 Serverless – Definition #2 A Serverless Runtime on the BEAM
  7. 7. Code BEAM Europe, Stockholm, 2022 Realities of a todays Enterprise-Developer #1 A Serverless Runtime on the BEAM
  8. 8. • Technology stacks are given • Moving away from it is nearly impossible • Strategy! “We’re moving to the Cloud” • regardeless how • With the same principles applications built Code BEAM Europe, Stockholm, 2022 Realities of a todays Enterprise-Developer #2 A Serverless Runtime on the BEAM
  9. 9. • Technology stacks are given • Moving away from it is nearly impossible • Strategy! “We’re moving to the Cloud” • regardeless how • With the same principles applications built Code BEAM Europe, Stockholm, 2022 Realities of a todays Enterprise-Developer #2 A Serverless Runtime on the BEAM
  10. 10. • Build and Migrate application to the programming model the cloud is made for • Accept to cut strings with the past • Accept to use a reduced degrees of freedom…but gain some new • Obervability and Traceability • Decoupling • Scaling and the ability to run parts concurrently • Ability to version features • Roll out without shutting down the monolith Code BEAM Europe, Stockholm, 2022 Make the move A Serverless Runtime on the BEAM
  11. 11. • Serverless Runtime • that enables General Purpose Applications to be built • Open Source Project • Evolution based on a concept of another open source project • Implementation of a Cloudstate Service Proxy • Based on a Protocol • Polyglot SDKs eiger.io & Cloudstate eigr.io – A Serverless Runtime on the BEAM Code BEAM Europe, Stockholm, 2022
  12. 12. Code BEAM Europe, Stockholm, 2022 Eigr Functions • A Service Proxy • with managed State • Cloud Native deployment (k8s) • A Protocol • gRPC based, with a spec and a TCK • Polyglot Programming Model • SDKs in JavaScript, Python, Kotlin, Java, Go, C#, Dart, Elixir, … • Runs on the BEAM eigr.io – A Serverless Runtime on the BEAM
  13. 13. • Eigr Functions is an Evolution of the Cloudstate Protocol • Abstracts State • State Models as a protocol in *.proto files • gRPC based • based on HTTP/2 • enables Streaming • Protocol spec defined in *.proto (protocol buffer) • Technology Compatibility Kit (TCK) • ensures proxy and SDKs compatibility Code BEAM Europe, Stockholm, 2022 Eigr Functions eigr.io – A Serverless Runtime on the BEAM
  14. 14. • “Message IN, Message OUT” • eigr/massa • Implemented in Elixir • Kubernetes Controller Code BEAM Europe, Stockholm, 2022 Service Proxy eigr.io – A Serverless Runtime on the BEAM
  15. 15. • FaaS is usually stateless • State is brought to the function • State Model to choose • Action (FaaS) • Eventsourcing • CRDTs • Value Entity (CRUD) Code BEAM Europe, Stockholm, 2022 Inversion of State eigr.io – A Serverless Runtime on the BEAM
  16. 16. Code BEAM Europe, Stockholm, 2022 Inversion of State eigr.io – A Serverless Runtime on the BEAM
  17. 17. • FaaS is usually stateless • State is brought to the function • State Model to choose • Action (FaaS) • Eventsourcing • CRDTs • Value Entity (CRUD) Code BEAM Europe, Stockholm, 2022 Inversion of State eigr.io – A Serverless Runtime on the BEAM
  18. 18. • Service Proxy in Elixir • gRPC Reflection ☑️ • Discovery Protocol ☑️ • Action Protocol ☑️ • Functions Controller ☑️ • Challenges • Implement State Models • CRDT, Eventsourcing, CRUD • Enhance and Improve SDKs • Focus on JS, Java, Python and Go • Enhance the TCK Code BEAM Europe, Stockholm, 2022 Current state & Challenges eigr.io – A Serverless Runtime on the BEAM
  19. 19. • Eigr Functions is a Serverless Runtime • That can be deployed on-premise or in the cloud. • Kubernetes is our operational runtime • Function State is managed as an abstraction • Inversion of state with multiple state models • We’re running on the BEAM with its solid, proven and fault tolerant model to operate. • …we’re not done yet :) Code BEAM Europe, Stockholm, 2022 Summary A Serverless Runtime on the BEAM
  20. 20. Code BEAM Europe, Stockholm, 2022 V1.3 eigr.io github.com/eigr @eigr_io Thanks! Alpiglen, below Eiger – August 2013, M.Lanz

Editor's Notes

  • Welcome.
    Thank you for having me at this wonderful conference. I'm very excited to be here.
    It's also great to meet in person again, after many many months of online conferences. Human interaction is still the best and I think we're not really made for a remote life.

    Today I'm talking about a Serverless Runtime that is being built as an open source project on the BEAM.
    My name is Marcel Lanz and I'm a BEAM and Erlang-Ecosystem outsider so far. I work in the Swiss fintech and insurance industry mostly with Java or JVM based enterprise systems on the server built in the last 20 years.
    Before that I spent my time in the dark deep low-level space of networked, embedded and realtime-systems.
  • I divided my talk into the following parts. First we’ll define what Serverless is about in the context of our project.

    Second, I’ll show how through a little dilema, we’re motivated to use serverless technology.

    And the last two parts are about the eigr.io Project and its implementation of a serverless runtime.
  • So lets get started. Lets start with a little poll:

    How many of you run some serverless production workload in the cloud?

    How many of you run your entire production workload in the cloud?

    How many of you would trust a cloud provider with your entire production workload built as a serverless system and therefore don't own and control all of your stacks code?
  • Yesterday I started a Whova Poll and this is what we’ve got here
  • As this talk is about Serverless, lets define what it is, this is definition number 1
  • And a second one.

    I think this is even better. In our context for this talk lets agree that Serverless compute, also called Function as a Service is our way how to run code. So instead to deploy a whole application, we use the function as an abstraction, and we're able to deploy these functions. I think AWS lambda was one of the first instances of such an abstraction that got promoted as a product to be used in AWS.
  • A few weeks ago this message thread had been retweeted, I only quote parts, but it shows well how some of us live in an another world while another “reality” moves forwards with what is possible, in the cloud.
  • The Functions as a Service development model is fundamentally different to how systems have been built for many years.
    Also a Serverless runtime or better said products, usually can't be deployed on premise but instead are offerings of a Cloud provider. Depending on your business, your tradition or how you generally trust such an offering, you don't want to give a cloud provider so much trust to build your entire business on it. It's fair to say, that a vendor lock in is a risk for some in this regard.

    For many companies its very hard to move away from their often yearlong and established investment in their technology stack. In the field of enterprise, its often excaclty defined what technology can be used for systems development. From my personal experience, in some of these companies, switching technical grounds is nearly impossible without very very good reasons to do so. This applies to the fleet of programmes doing the daily work, on boring business software that has been developed and maintained for many years.

    So even if we think, as an example the BEAM and Elixir or Go to name an another language, is more appropriate to solve a problem, its way more likely that we would stick with what is allowed to be used. In the enterprise world, this is often a Java or JVM based stack. To change this in a Java-Shop as an example, is nearly impossible.
  • Moving to the Cloud, continuoud

    The last few years, even the last companies found their way to have a strategy to move to the cloud. What happens there, is, that existing applications, often monoliths by their own, are packaged into a container image and then, deployed to Kubernetes or a container runtime. Regardless if this makes any sense of how kubernetes works. It is the strategy to use a "modern" build and continuous deployment pipeline. This by itself has advantages, for sure, like the aspect of automating the deployment and eliminate manual steps in the process.

    For organizations without a strong engineering culture, moving to the cloud is often driven by the operational aspect of how their systems have been working so far. Sure they made the switch from bare metal servers to virtual machines, but they’re running within their own infrastructure, their own networks, their compliance to standards and especially their burden to be able to scale their workloads if they have to; to scale up but also to scale down.
  • I explained why it seems not possible for some to move away from their old technology. Since we’re talking about to use also a Serverless runtime. There must be a way to do it.

    And I think this way is quite radical. As we haven’t learned how to use our tools offered freedom, its time to reduce this degrees of freedom and start to migrate to the way to implement functionality, systems and enhancements with an abstraction we have here with serverless compute. For sure this is not an easy task, but it also doesn’t make any sense, to just run legacy code in a cloud native environment and at the same time don’t gain any advatages out of it.

    Some are: Obervability and Traceability, decopupling, scaling, geo location, the ability to run parts of the workload in parallel, simply to be able to version features and last, being able to rollout new versions without shutting down your server and having donwtimes.

    We don’t have to completely move over to a new language or paradigm, just use it differently.
  • Eiger is an open source project we've initiated after Cloudstate, another open source project, had been terminated.

    Cloudstate, after its end, was revealed as a "testbed" exploring state management in the serverless space.

    It had identified that state management is the hardest part of Function as a Service. Beside its exploration how to build state management in this space, it defined a protocol. The protocol is and was Cloudstate's most valuable asset. It defined how to run different state models so that FaaS functions don't have to know and so they don't have to connect to a database or they don't have to connect to a stateful service.

    Cloudstate was terminated, but it was also a success. The open source community around it, implemented not only the very popular and well known CRUD a.k.a Entity State model, the community also provided implementations of SDKs for 6 additional languages. One language had been implemented the full support for all state models.

    The core of Cloudstate was built on top of a popular JVM Actor Framework, called Akka. Its creator Lightbend also lead the Cloudstate opensource project. Lightbend today provides a commercial implementation of parts of the original Cloudstate project in form of their Kalix platform as a service product - kalix.io

    While a commercial implementation had been built, the Cloudstate open source community started the eigr.io project to implement an open source implementation of the Cloudstate protocol.
  • Lets dive now into what we're doing with the Eigr Functions Project.

    Eiger Functions is our name for that and is an implementation of the Cloudstate protocol, no surprise here. What is different is the base technology we've choosen to implement it.
    We decided not to compete with the Akka Project and their creators. It seemed not to make any sense to continue the abandoned codebase or to rewrite it in Scala on the JVM again.

    (mention?: jvm starttimes? graalvm)

    We iterated on a few options. We considered to use Go or Rust. But fast we came to the conclusion that to rewrite a system like Akka or AkkaCluster was just too much work. Go would have been an appropriate option, as Go is widely used for cloud software these days. As much as I like Go, it simplicity as a Language as well as its tooling and concurrency model, the buildings blocks we needed just where not available so we considered something else. You might guess it!

    Some of us had experience with Elixir and we thought, "what could be better suited that to use the technology Akka was based and inspired originally". Also, the Cloudstate model implemented a virtual like Actor system with its protocol.

    Akka took the "best parts of Erlang", according to its creator, (source J.Bonér) and brought it to the JVM. Why should'nt we take the best parts of Akka and bring them now back to Erlang, right? :)

    The decision was made to use the BEAM and implement our system with it and this is where the excitement about to use Erlang began for us.
  • Eigr Functions - how it works

    We decided not to name our project Eigr Serverless. Even if we think that Serverless is an appropiriate term, there might be a better name for it. Or there is more than just the aspect of that its something "without servers".

    As I explained already, the Cloudstate protocol, now the Eigr protocol, is one important part of our system. Language SDKs are the second one. Third is a message proxy that we now implement on the BEAM in Elixir. While from a languages perspective I like Erlang for its simplicity, the majority of the projects member prefer Elixir - thats fine :)

    Lets have a look how the different components interact as a system to built the runtIme.

    User functions are defined with an API first approach. A function is defined using gRPC. gRPC is a modern and efficient transport on top of HTTP/2 to move data or better said messages between clients and servers. Messages are defined as so called "protocol buffers" using the *.proto file format.

    This is an example of a user function as a gRPC service.

    (insert: example of protobuf definition)
  • As I explained, we support multiple programming languages in which a function can be implemented. Therefore and luckily gRPC has broad support for many languages, so it can be used to generate stubs for languages to implement the gRPC server as well the client of a service. gRPC also supports enhanced features like streaming, both for the client as well as the server or even bidirectional streaming on both sides. gRPC as well as protocolbuffers as its messages encoding are established and widely used in cloud software projects for many years.

    The service proxy is connected to a user function implementation. The proxy implements a discovery protocol to get to know which services are implemented by a user function deployment.
    The proxy faces any clients who like to invoke the user functions services and then is able to route them to a concrete instance of the user function.

    (This way, user functions are exposed by the proxy to client. If a client uses an API, the API requests messages incoming message gets moved by the proxy over to the user function.)

    wip: k8s deployes these

    We run the user functions in kubernetes and the proxy itself is deployed as so called side-car. It runs beside the user function in the same pod as a process. The sidecar pattern is well established for such kind of functionality, service proxies in general run this way in kubernetes.

    There is an optimization where we could run multiple user functions with only one running instance of the proxy with which we could run multiple user functions save resources, but we concentrate on the standard sidecar pattern for now where one proxy is assigned to one user function.
  • The Proxy Protocol vs the SDK Protocol

    We just saw how user functions where defined, how the proxy discovers them as a sidecar, and then routes client requests towards these functions deployed running as kubernetes pods.

    The actual Eigr Protocol is divided into two parts conceptually. One part, the Proxy Protocol, is responsible to discover user functions and route client requests or manages errors towards the user functions implementation.

    The second part, the SDK protocol, represents the state models with which we're able to choose from beeing a user function.
  • State Models

    What I've just described now is nothing more than a concept how FaaS or Function as a Service can be implemented technically.
    But there is more. What we're able to do is also to manage state. This is done in a way where the function itself does not connect to a stateful service or a database, instead, the state is brought to the function whenever the function is invoked.

    The concept can be summarized as "inversion of state".
    This concept is shorty illustrated here.

    There are different state models a user function can choose from. The simplest model, the Action state model, is also a non-state model in the traditional sense. It represents the traditional Function as a Service - the function that gets a message in and returns a message out.

    Beside the Action protocol there are models to support Eventsourcing, CRDTs and the well known CRUD.


  • One of the most interesting state models is one supporting so called CRDTs – Conflict-free replicated data type.
    CRDTs have the ability to converge eventually in a distributed system without further coordination. There are multiple types well known in the CRDT space and the protocol uses some of them like Flags, Sets, Counters and Maps.

    One of the simpler ones is a Flag. Think of a boolean, that is false until its true. If any party in a distributed system decides to set the flag to true, eventually, the true state will get be set to true on all parties and there is no conflict to decide when a remote state has to be merged locally.

    Implementing CRDTs and its state model is not trivial. To implement CRDTs, we're looking to use existing projects on the BEAM. We started to explore the Antidote Project, a CRDT database, and the recently announced Vaxine project that is built on top of Antidote as a possible implementation.

    There was a great talk yesterday at this conference by James Arthur introducing the Vaxine project.
    If you haven’t seen it already, it explains well what is possible with this exciting state model.
  • We’re working continuously on our project, since we’re completely open source and we’re doing it just for fun it takes some time.
    But we made good progress the last few months. Our next focus point will be the CRDT state model, focus on the Javascript SDK as well as he test compatibility kit.

    We also identified some parts where libraries like the gRPC in Elixir implementation could be improved, performance wise. We have a labs project, where we investigate whats possible there.

    For sure we’re happy if others interested in the project like to join with ideas, collaboration on issues as well as exploring
  • Before closing this talk, lets summarize what we have.
  • You might have noted that the Eigr project got his name from a Swiss Mountain. The picture here shows what happened in August about 10 years ago, when the BEAMs of the sun touched the lower base of the Eiger mountain.

    It lasted only a few minutes before the sun set behind the horizon.

    Thats all I have, Thank you for your attention.

×