Time for another spotlight - today we.re talking to Darko Fabijan, co-founder of Rendered Text, the creators of Semaphore.
3 Likes
Please tell us a little bit about Semaphore and Rendered Text
Our story began in 2009 when a university friend Marko and myself set up a software consultancy company called Rendered Text(link) while working on a social web startup. We were passionate about both making software and improving people’s lives through it. We launched Semaphore (a CI/CD platform) in 2012 based on these values.
Semaphore has now grown into a service that is used in over 100 countries. Our team is also distributed, with colleagues working all over the world.
How did you discover Elixir?
I discovered Erlang in early 2013, which was around the time we launched Semaphore. I was exploring the language, looking through the documentation and the associated best practices for building distributed systems and at that time, I found mainly academic resources. And then one day, I discovered Elixir!
The first version of Semaphore was written in Ruby and José Valim was a prominent member of the Ruby community. We started following his new project. The Elixir and Ruby communities were close, the tooling around Elixir was great, the documentation was also great. There were so many goodies from the Erlang universe for building distributed systems! We jumped on board and started writing code in Elixir in 2015.
How are you using Elixir in Semaphore 2.0?
We are using it for various things in Semaphore 2.0. Semaphore 2.0 has adopted a microservice architecture - there are more than 20 different services to it. They’re all communicating. Two are written in Ruby, one in Go and all the rest are written in Elixir. You could say that around 95% of Semaphore 2.0 is written in Elixir.
What attracted you to Elixir the most, or what was the biggest advantage of Elixir that was most relevant to you and what you do?
When we started building Semaphore 2.0 the plan was to expose the APIs from Semaphore Classic and to build everything from scratch in Elixir. We wanted gRPC to communicate with the Ruby core. In the meantime we also changed how we’re going to ship our new product and the core written in Ruby has shrunk to 5% of what it was. We took many parts out, turning them into different applications. They are all written in Elixir.
In terms of advantages, Semaphore is very distributed by nature because things are just running on different machines. We are executing jobs and it’s very asynchronous. You push something to GitHub, we accept that hook and then we start building it. We are interpreting your pipeline, starting many different jobs, waiting for jobs to finish and it’s all running in the background. For building reliable systems at scale that are also distributed, Elixir and Erlang together bring a lot of goodies so that we don’t have to reinvent the wheel. So naturally it was a perfect match for Semaphore 2.0.
Were there any difficulties in transitioning to Elixir?
It’s a relatively long journey. We started using Elixir in production in 2016. The whole team adopted it in 2017 when we ramped up the work on Semaphore 2.0. The language is nice, the tooling around it is very good. The syntax is also very nice so the language is easy to adopt. However, understanding all the libraries around building distributed systems (OTP) took some time. It was a process and we are not quite yet 100% there.
What was crucial when learning Elixir for you and the team?
Being flexible when building software is really important. For example, you build something and then throw it away because in the end of the process you figure out that it should have been built in a different way. Reading different books and experiences people had online also helped a lot. Meeting people at different Erlang and Elixir conferences and local meetups was also enriching. We talked with people, exchanged experiences while learning new things from them too.
How happy are you with your choice in using Elixir?
We definitely don’t regret going the Elixir route. When starting building Semaphore 2.0 we also adopted gRPC, which was still at early stages and not very stable. But, it was already supported by Google for Ruby, Go and so on. We jumped into this, fixed couple of bugs and also got very nice support from the maintainer of the library. There are some hurdles along the way with using Elixir when comparing to Go which is pretty much mainstream.
The overall ecosystem and the libraries available are not yet on the same level as in some of the mainstream programming languages, but the community is great and very helpful. There are a lot of smart and dedicated people working on different projects. We really enjoy meeting people online and offline.
Is there anything in particular that you’d like to see in Elixir?
I don’t see that anything is really missing. It’s just a matter of time for the ecosystem to mature and the libraries to become more production ready. It’s also only just a matter of time when the big companies embrace the language and start investing into it.
What would you say to other companies thinking about adopting Elixir?
Go to the Elixir events (there are plenty of conferences in Europe and USA), meet the people, feel the vibe. You’ll have a better understanding of the maturity of the language and its overall ecosystem. This will help you evaluate if Elixir is the right choice for you. Smaller teams like us (we are a team of 10 engineers) can experiment and adopt a new language with no real struggles. However, this is not the case for the bigger companies. If you are the latter, just make sure you understand what you are getting into before making the jump.
Thank you for answering our questions! Is there anything else you’d like to share? Any plans? News? Tips?
Make sure you check out Semaphore 2.0 and let us know what you think. We hope it’s going to make your life building software easier, more pleasant and faster!
7 Likes
