It is also worth mentioning that I have seen many companies pursuing microservices because they fail to organize large applications as their tooling (languages and frameworks) do not provide good abstractions to manage those. So microservices are often seen as a solution for structuring code by imposing the separation of concerns from top to bottom. Unfortunately, prematurely adopting microservices often negatively impacts the team’s productivity. Therefore, it is also important for languages and frameworks to provide proper abstractions for handling code complexity as the codebase grows.<\/p>\n
Background<\/h2>\n
Elixir<\/a> is a concurrent and distributed programming language that runs on the Erlang Virtual Machine (Erlang VM) focusing on productivity and maintainability. Before we go into microservices, I would like first to argue why Elixir\/Erlang may be the best platform out there for developing distributed systems (regardless if you have a microservices architecture or not).<\/p>\n The Erlang VM and its standard library were designed by Ericsson in the 80’s for building distributed telecommunication systems. The decisions they have done in the past continue to be relevant to this day and we will explore why. As far as I know, Erlang is the only runtime and Virtual Machine used widely in production designed upfront for distributed systems.<\/p>\n The Elixir runtime has the notion of applications<\/strong>. In Elixir, code is packaged inside applications which:<\/p>\n provide a unified directory structure and configuration API. If you have worked with one application, you know the structure and how to configure any other one<\/p>\n<\/li>\n contains your application supervision tree, with all processes<\/strong> and their state<\/p>\n<\/li>\n<\/ol>\n Throughout this post, processes<\/strong> mean a lightweight thread of execution managed by the Erlang VM. They are cheap to create, isolated and exchange information via messages.<\/p>\n The impact of applications in a project is highly beneficial. It means that Elixir developers, when writing applications, are given a more explicit approach to:<\/p>\n what are the processes that make part of an application and therefore what is the application state. If you can introspect your application tree, you can introspect any process and, therefore, all the components that make up your application<\/p>\n<\/li>\n how the application processes will react and be affected in case of crashes or when something goes wrong<\/p>\n<\/li>\n<\/ol>\n Not only that, the tooling around applications is great. If you have Elixir installed, open up “iex” and type: You can see all applications that are part of this node on the left side. Clicking an application shows the processes tree of that application. Double-clicking any process opens up a window with information about the process, which function it is executing, its particular state and more. Furthermore, you can kill any process and see the impact it will have on your system.<\/p>\n When compared to other languages, the difference here is that Applications and Processes give you an abstraction to reason about your system in production. Many languages provide packages, objects and modules mostly for code organization with no reflection on the runtime system. If you have a class attribute or a singleton object: how can you reason about the code that manipulates it? If you have a memory leak or a bottleneck, how can you find the entity responsible for it?<\/p>\n This visibility is one of the major benefits of building systems in Elixir. If you ask anyone running a distributed system, that’s the kind of insight they want, and with Elixir you have that as the building block.<\/p>\n When building a distributed system, you need to choose a communication protocol and how the data will be serialized. Although there are many options out there, unfortunately a lot of developers choose HTTP and JSON, which is a very verbose and expensive combination for performing what ends up becoming RPC calls.<\/p>\n With Elixir, you already have a communication protocol and a serialization mechanism out of the box via Distributed Erlang. If you want to have two nodes communicating with each other, you only need to give them names, ensure they share the same secret cookie, and you are done.<\/p>\n Not only that, because all Elixir processes communicate with each other via message passing, the runtime provides a feature called location transparency<\/strong>. This means it doesn’t really matter if two processes are in the same node or in different ones, they are still able to exchange messages.<\/p>\n I wrote a quick introduction to Elixir that covers how to get started with Elixir from creating a brand new project up to node communication on How I Start<\/a>. Check it out for more information.<\/p>\n The Distributed Erlang protocol and serialization mechanism are also documented and therefore it can be used to communicate with other languages. The Erlang VM ships with a binding for Java and others can be found for Python, Go and more.<\/p>\n Earlier I mentioned I have seen many companies pursuing microservices because they fail to organize code at the project level. So often they prematurely split their architecture in microservices which affects productivity in the short and long run. From Martin Fowler’s article:<\/p>\n In Elixir, breaking a large application into smaller ones is simpler than anywhere else, as the process tree already outlines dependencies and the communication between those dependencies always happen explicitly via message passing. For example, imagine you have an application called This is such a common aspect of working with Elixir projects that its build tool, called Mix, provides a feature called umbrella projects<\/strong> where you have a project composed of many applications that may depend on each other on any fashion.<\/p>\n Umbrella projects allows you to compile, test and run each application as a unit but also perform all the tasks at once if required. Here is quick example:<\/p>\n The snippet above creates a new umbrella project, enters its Once the main application So far I haven’t talked about microservices. That’s because, up to this point, they don’t really matter. You are already designing your system around tiny processes that are isolated and distributed. Call them nanoservices if you’d like to!<\/p>\n Not only that, those processes are packaged into applications, which group them as entities that can be started and stopped as unit. Combined with Distributed Erlang, if you want to deploy your In other words, you can focus on how to deploy your applications based on what is driving you to break them apart. Is it code complexity? You can work on them separately but still deploy them as a unit. Is it for scability or multi-tenancy reasons? If If you are not familiar with Elixir, after reading this far, you may be wondering: is Elixir good only for building distributed systems?<\/p>\n Elixir is excellent for building any kind of long running system exactly because of all the insights you have on your application, even if it is deployed to a single node. The language is also expressive and pleasant to learn and work with (I am certainly biased though), with a getting started guide<\/a> and many learning resources<\/a> already available.<\/p>\n While there is a learning curve, the abstractions outlined here are elegant and simple, and the tooling does an excellent job on guiding you to build your first application. The command I hope I have illustrated how the design decisions done by Elixir and the Erlang VM provide a great foundation for building distributed systems.<\/p>\n It is also very exciting to see companies starting to enjoy and explore those characteristics through the Elixir programming language. In particular, it is worth watching Jamie Windsor talk at Erlang Factory 2015 and how they were able to leverage this to build a game platform<\/a>.<\/p>\n Finally, a lot of this post focuses on building systems through Distributed Erlang. Although Distributed Erlang will definitely be the most productive approach, there is no reason why you can’t leverage the benefits outlined here by using Elixir with another protocol like Apache Thrift.<\/p>\n And, if at the end of the day, all you want is to use HTTP and JSON, that is fine too and libraries like Plug<\/a> and frameworks like Phoenix<\/a> will guarantee you are as productive as anywhere else while enjoying the performance characteristics and robustness of the abstractions outlined here.<\/p>\n Happy coding!<\/p>\n Note I have not covered techniques like blue\/green and canary deployments because they depend on the system and communication protocol you are running. Elixir provides conveniences for process grouping and global processes (shared between nodes) but you can still use external libraries like Consul or Zookeeper for service discovery or rely on HAProxy for load balancing for the HTTP based frontends.<\/em><\/p>\n Since microservices have been a common topic lately, there are a lot of questions about how Elixir fits in microservice architectures. On this post, I won’t focus on the merits of microservices, as many have already discussed that to exhaustion. In particular, Martin Fowler’s entry on the topic aligns well with my thoughts and is … \u00bb<\/a><\/p>\n","protected":false},"author":4,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"ngg_post_thumbnail":0,"footnotes":""},"categories":[1],"tags":[232,143,233],"aioseo_notices":[],"jetpack_sharing_enabled":true,"jetpack_featured_media_url":"","_links":{"self":[{"href":"https:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/posts\/4787"}],"collection":[{"href":"https:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/users\/4"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/comments?post=4787"}],"version-history":[{"count":9,"href":"https:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/posts\/4787\/revisions"}],"predecessor-version":[{"id":4811,"href":"https:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/posts\/4787\/revisions\/4811"}],"wp:attachment":[{"href":"https:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/media?parent=4787"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/categories?post=4787"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/tags?post=4787"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}Applications<\/h2>\n
\n
\n
:observer.start()<\/code>. Besides showing information and graphs about your live node, you can kill random processes, see their memory usage, state and more. Here is an example of running this in a Phoenix<\/a> application:<\/p>\n![\"Observer](\"http:\/\/i.stack.imgur.com\/7j9BR.png\")
<\/p>\nCommunication<\/h2>\n
Breaking monolithic applications<\/h2>\n
![\"Complexity](\"http:\/\/martinfowler.com\/bliki\/images\/microservice-verdict\/productivity.png\")
<\/p>\nabc<\/code> that has grown larger with time, you can break it apart into applications a<\/code>, b<\/code> and c<\/code> by extracting its supervision tree to different applications.<\/p>\n$ mix new abc --umbrella\n$ cd abc\/apps\n$ mix new a\n$ mix new b --sup\n$ mix new c --sup\n<\/code><\/pre>\napps<\/code> directory and create three applications: a<\/code>, b<\/code> and c<\/code>, where the last two contain a supervision tree. If you run mix test<\/code> at the abc<\/code> project root, it will compile and test all projects, but you can still go inside each application and work with it in isolation.<\/p>\nabc<\/code> is broken apart, you may also move each part to a separate repository if desired, or you may not. The benefit is that developers are able to handle growing code complexity in small, granular steps, without making large decisions upfront. We cover this with more details in our Mix and OTP guide<\/a>.<\/p>\nMicroservices<\/h2>\n
a<\/code>, b<\/code> and c<\/code> applications as [a, b]<\/code> + [c]<\/code> or [a]<\/code> + [b]<\/code> + [c]<\/code>, you will have very little trouble in doing so due to their inherent design and built-in communication.<\/p>\nc<\/code> requires more instances or the application with user specific concern, then it is reasonable to isolate it and deploy multiple instances of c<\/code>.<\/p>\nIs Elixir good only for building distributed systems?<\/h2>\n
mix new my_app --sup<\/code> we have executed above will generate an application, with its own process tree, which you can directly use and explore to learn more.<\/p>\nWrapping up<\/h2>\n
\n ![\"Subscribe](\"http:\/\/blog.plataformatec.com.br\/wp-content\/uploads\/2015\/05\/elixir-radar-subscribe.png\")
\n<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"