One important decision for delivering a platform independent solution with low memory footprint and minimal dependencies was the choice of the programming language. We considered a few from Python (there was already a reasonably large Python code base at Thumbtack), to Go (we were taking our first steps with it), and even Rust (too immature at the time).

We ended up writing it in C. It was easy to meet all requirements with only one external dependency for implementing the web server, clearly no challenges running it on any of the Linux distributions we were maintaining, and arguably the implementation with the smallest memory footprint given the choices above.

At Epsagon, we use hundreds of AWS Lambda functions, most of them are written in Python, and the Serverless Framework to pack and deploy them. One of the issues we've encountered is the difficulty to package external libraries into the Lambda environment using the Serverless Framework. This limitation is probably by design since the external code your Lambda needs can be usually included with a package manager.

In order to overcome this issue, we've developed a tool, which we also published as open-source (see link below), which automatically packs these libraries using a simple npm package and a YAML configuration file. Support for Node.js, Go, and Java will be available soon.

The GitHub respoitory: https://github.com/epsagon/serverless-package-external

We are hardcore Kubernetes users and contributors. We loved the automation it provides. However, as our team grew and added more clusters and microservices, capacity and resources management becomes a massive pain to us. We started suffering from a lot of outages and unexpected behavior as we promote our code from dev to production environments. Luckily we were working on our AI-powered tools to understand different dependencies, predict usage, and calculate the right resources and configurations that should be applied to our infrastructure and microservices. We dogfooded our agent (http://github.com/magalixcorp/magalix-agent) and were able to stabilize as the #autopilot continuously recovered any miscalculations we made or because of unexpected changes in workloads. We are open sourcing our agent in a few days. Check it out and let us know what you think! We run workloads on Microsoft Azure Google Kubernetes Engine and Amazon EC2 and we're all about Go and Python!

How Uber developed the open source, end-to-end distributed tracing Jaeger , now a CNCF project:

Distributed tracing is quickly becoming a must-have component in the tools that organizations use to monitor their complex, microservice-based architectures. At Uber, our open source distributed tracing system Jaeger saw large-scale internal adoption throughout 2016, integrated into hundreds of microservices and now recording thousands of traces every second.

Here is the story of how we got here, from investigating off-the-shelf solutions like Zipkin, to why we switched from pull to push architecture, and how distributed tracing will continue to evolve:

https://eng.uber.com/distributed-tracing/

(GitHub Pages : https://www.jaegertracing.io/, GitHub: https://github.com/jaegertracing/jaeger)

Bindings/Operator: Python Java Node.js Go C++ Kubernetes JavaScript OpenShift C# Apache Spark

At Kong while building an internal tool, we struggled to route metrics to Prometheus and logs to Logstash without incurring too much latency in our metrics collection.

We replaced nginx with OpenResty on the edge of our tool which allowed us to use the lua-nginx-module to run Lua code that captures metrics and records telemetry data during every request’s log phase. Our code then pushes the metrics to a local aggregator process (written in Go) which in turn exposes them in Prometheus Exposition Format for consumption by Prometheus. This solution reduced the number of components we needed to maintain and is fast thanks to NGINX and LuaJIT.

Following its migration from vanilla instances with autoscaling groups to Kubernetes, Postmates began facing challenges while “migrating workloads that needed to scale up very quickly.”

The built-in Horizontal Pod Autoscaler (HPA) automatically scales the number of pods in a replication controller, deployment or replica set based on observed CPU utilization. But the challenges for Postmates is that there’s no way to configure the scale velocity of one particular cluster with an HPA.

For Postmates, which runs at least three different types of applications with distinct performance and scaling characteristics, this proved problematic.

To overcome these challenges, the team created and open sourced the Configurable Horizontal Pod Autoscaler, which allows for fine-grained tuning on a per-HPA object basis. The result is that “you can configure critical services to scale down very slowly, while every other service could be configured to scale down instantly to reduce costs.”

Initially, I wrote my text adventure game in C++, but I later rewrote my project in Rust. It was an incredibly easier process to use Rust to create a faster, more robust, and bug-free project.

One difficulty with the C++ language is the lack of safety, helpful error messages, and useful abstractions when compared to languages like Rust. Rust would display a helpful error message at compile time, while C++ would often display "Segmentation fault (core dumped)" or wall of STL errors in the middle. While I would frequently push buggy code to my C++ repository, Rust enabled me to only even submit fully functional code.

Along with the actual language, Rust also included useful tools such as rustup and cargo to aid in building projects, IDE tooling, managing dependencies, and cross-compiling. This was a refreshing alternative to the difficult CMake and tools of the same nature.

Another major decision was to adopt Elixir and Phoenix Framework - the DX (Developer eXperience) is pretty similar to what we know from RoR, but this tech is running on the top of rock-solid Erlang platform which is powering planet-scale telecom solutions for 20+ years. So we're getting pretty much the best from both worlds: minimum friction & smart conventions that eliminate the excessive boilerplate AND highly concurrent EVM (Erlang's Virtual Machine) that makes all the scalability problems vanish. The transition was very smooth - none of Ruby developers we had decided to leave because of Elixir. What is more, we kept recruiting Ruby developers w/o any requirement regarding Elixir proficiency & we still were able to educate them internally in almost no time. Obviously Elixir comes with some more tools in the stack: Credo , Hex , AppSignal (required to properly monitor BEAM apps).

Go is a high performance language with simple syntax / semantics. Although it is not as expressive as some other languages, it's still a great language for backend development.

Python is expressive and battery-included, and pre-installed in most linux distros, making it a great language for scripting.

PostgreSQL: Rock-solid RDBMS with NoSQL support.

TypeScript saves you from all nonsense semantics of JavaScript , LOL.

NATS: fast message queue and easy to deploy / maintain.

Docker makes deployment painless.

Git essential tool for collaboration and source management.

Our new backend micro services are primarily written in Node.js and Go and legacy systems are written in Java. For our new stack decision, we aimed to achieve greater developer productivity, low IO latency and good community so we had couple of technologies in hand to choose but finally we concluded to go for Node.js for API layer and Go for CPU/IO intensive tasks. Currently the inter-services communication is happening via REST but soon to be moved to RPC-based communication.

We have added very little to the CoffeeScript Hubot application – just enough to allow it to talk to our Hubot workers. The Hubot workers implement our operational management functionality and expose it to Hubot so we can get chat integration for free. We’ve also tailored the authentication and authorization code of Hubot to meet the needs of roles within our team.

For larger tasks, we’ve got an internal #CLI written in Go that talks to the same #API as Hubot, giving access to the same functionality we have in Slack, with the addition of scripting, piping, and all of our favorite #Unix tools. When the Hubot worker recognizes the CLI is in use, it logs the commands to Slack to maintain visibility of operational changes.

For the backend of https://www.rsvpkeeper.com I went with Go.

My past few project have been built with Go and I'm really loving it. It was my first statically typed language after many years with PHP and Node.js - and honestly I couldn't be happier to have made the switch.

The biggest thing for me, is that with the forced declaration of types - it's made me feel like I've made a more solid backend. Sometimes with PHP I felt like a stiff breeze could knock the whole thing down. I know that's an exaggeration - but it's kinda how it feels.

Anyways, everyone knows that it almost doesn't even matter what an app is actually made with - what really matters are the design decisions you make a long the way.

At FlowStack we write most of our backend in Go. Go is a well thought out language, with all the right compromises for speedy development of speedy and robust software. It's tooling is part of what makes Go such a great language. Testing and benchmarking is built into the language, in a way that makes it easy to ensure correctness and high performance. In most cases you can get more performance out of Rust and C or C++, but getting everything right is more cumbersome.

When you think about test automation, it’s crucial to make it everyone’s responsibility (not just QA Engineers'). We started with Selenium and Java, but with our platform revolving around Ruby, Elixir and JavaScript, QA Engineers were left alone to automate tests. Cypress was the answer, as we could switch to JS and simply involve more people from day one. There's a downside too, as it meant testing on Chrome only, but that was "good enough" for us + if really needed we can always cover some specific cases in a different way.

In our company we have think a lot about languages that we're willing to use, there we have considering Java, Python and C++ . All of there languages are old and well developed at fact but that's not ideology of araclx. We've choose a edge technologies such as Node.js , Rust , Kotlin and Go as our programming languages which is some kind of fun. Node.js is one of biggest trends of 2019, same for Go. We want to grow in our company with growth of languages we have choose, and probably when we would choose Java that would be almost impossible because larger languages move on today's market slower, and cannot have big changes.