Hello there! We (the dev guys) kind of have taken possession of Thursdays in this blog for our own purposes, and we are actually enjoying it! It’s a joy to have the chance of letting you know about the cool technologies we use on a daily basis and how we power our infrastructure and architecture to bring you the best possible SMS platform for your marketing and alert purposes.
On earlier posts we discussed how we use microservices and how RabbitMQ is the key player backstage that takes care of routing and delivering the messages to the right components. Today we want to talk about why we choose and how we use the Elixir language to create our main and core microservices.
What Is It
Erlang is a language created by Ericsson in the 80s. It is a functional language and has features that can be used to create massively scalable, fault tolerant, and soft real time systems, mainly used in the telecom business (as its original objective) but nowadays extended to every scenario that requires a rock solid platform to build distributed systems.
Elixir takes full advantage of all the erlang features, but it also adds a few ingredients that are really useful for fast prototyping and for creating DSLs (Domain Specific Languages). It also has a syntax that resembles the Ruby language.
Why We Choose It
We choose both Elixir and Erlang for our code, but we are a bit more inclined to Elixir for designing some core components due to it’s great ecosystem of tools and libraries, like Ecto, which is an abstraction layer over databases like MySQL, and provides a DSL to make it really easy to run queries against it, and work and validate data and types.
Also, being able to rapidly create DSLs of our own makes it possible to extend our systems easily (like our API endpoints) without losing access to all the erlang features and libraries, so it’s like having the best of all worlds.
Besides all of the above, we experienced that it is far more easy to call erlang code from Elixir than viceversa.
Where We Use It
We use Elixir in our autonomous components whenever we feel like we need process isolation, supervision, or a distributed environment.
One example is the part of our infrastructure that handles the REST API calls, where we need code that can be horizontally scaled and be robust enough so a crash in one part of the system will not affect other users.
Another good example is the code in charge of running and monitoring the SMS campaigns, where we send thousands of messages while at the same time processing inbound text messages and responses and events from our own downstream carriers.
Both of this examples rely on a distributed architecture, where process isolation and messaging plays a central role. When relying on code written to be run on the BEAM we feel like nothing can go wrong, and when it does we can just keep calm and let it crash 🙂
As we stated in our earlier posts, it’s great to be able to work with this kind of technologies.
Not only because they are fun and state of the art, but also because they are rock solid and have been proven to be the best over and over.
By combining these great tools and our own best attempts at working with passion and discipline we can give you a great service for you and your customers!
Until the next time 🙂
— The PortaText Team.