DEV Community

Arpit Mohan
Arpit Mohan

Posted on • Originally published at

About trunk-based development; Mixpanel's move from Erlang to Python; & Kubernetes

TL;DR style notes from articles I read today.

Why I love trunk-based development (or pushing straight to master)

  • Earlier and better feedback, while the code is being written, from your pair partner.
  • Collective code ownership by the team and strong team style, since it is no one’s sole responsibility or brainchild.
  • You can have actual continuous integration with small changes locally tested and then pushed out, without problem ignored till later.
  • Fewer issues with merge conflicts since your whole team is up to date on small changes every time.
  • High visibility of team members’ work so you can easily (and early) spot where a teammate needs help.
  • You can preserve the whole commit history, which is an advantage for future developers working on the same codebase.

Full post here, 15 mins read

How and why we switched from Erlang to Python

  • Mixpanel had coded one of their servers using Erlang because of performance requirements.
  • After 2 years, it became hard for them to debug downtime & performance issues because they didn't have any Erlang experts on their team.
  • They switched to their de-facto language, Python. Having more code clarity & maintainability were the two main reasons for this move.
  • For the framework and networking library to scale, Mixpanel used eventlet’s raw WSGI library (instead of Python’s asynchronous I/O) since its”green threads” resemble Erlang’s “actors”.
  • For the JSON library they used simplejson coded in C, for roughly a ten times better performance.
  • Using the right Python libraries avoided adding more servers horizontally.

Full post here, 5 mins read

Will Kubernetes fall into the “shiny things” trap?

  • New & shiny can also mean immature.
  • Developers must be cautious about excessive reliance on new technologies.
  • Do not ask simply how to leverage Kubernetes at scale, ask how to use a single abstraction to cover Kubernetes, on-premises visualization and the entire IT landscape.
  • To be cloud-native, you may need to rewrite your existing tech as containerized microservices.
  • Build your version for full compatibility with other vendors instead of complete portability and abstraction across environments.

Full post here, 6 mins read

Get these notes directly to your inbox every weekday by signing up for my newsletter, in.snippets(), here.

Top comments (1)

exadra37 profile image
Paulo Renato

How and why we switched from Erlang to Python

This article is from 2011, and nowadays is not so hard to find Erlang engineers or learn it, because we have more resource available, like lots of different worldwide conferences around the Erlang ecosystem, and they happen all year around.

But the main reason is that since Elixir was released, and gained traction, it brought Erlang along, thus being now more exposed to wider audience.

For the ones not aware Erlang was during a lot of years considered a secret weapon in their arsenal, by a lot of companies:

Once upon a time, Cisco, Ericsson, Klarna, Goldman Sachs, T-Mobile, WhatsApp, Amazon and many other top companies kept a secret. Erlang was that badly kept secret. Many have heard of it, but few realise that it controls vast amounts of infrastructure, including the fixed and mobile networks we use on a daily basis. It was monumental when Cisco revealed that it ships 2 million devices per year running Erlang at the Code BEAM Stockholm conference in 2018. This translates to 90% of all internet traffic going through routers and switches controlled by Erlang. And have you heard about Ericsson? It has Erlang at the core of its GPRS, 3G, 4G and 5G infrastructure. With a market share of 40%, there’s a high probability a program written in Erlang assigned the IP address your smartphone is using today (amongst other things).

So no matter if you are browsing the Internet or doing just a phone call you have pretty good chances to be using an Erlang system ;).

Nowadays you even have an Erlang Ecosystem Foundation, that aims in their own words:

The Erlang Software Foundation’s goal is to grow and support a diverse community around the Erlang and Elixir Ecosystem, encouraging the continued development of technologies and open source projects based on/around its runtime and languages

So the bottom line is that now 8 years have been passed from when they migrated, therefore the reason of that team to switch from Erlang to Python may have not been an issue today.