Happy new year 2014

Joern Barthel

2013 was a great year for us - we did a lot of amazing consulting work and build a whole bunch of exciting software. With the new year fresh of the boat I think it's time to have a quick look back and reflect on our stack choices and what we think about their respective future. I’ve split the field into languages & frameworks as well as operations support - while this does not cover all the activities we undertook it probably represents the areas of most interest for an outside party.

In 2013 we build and shipped in Ruby, Javascript, Java, Python, Perl and Go. Let’s talk about that for a second!

Languages & frameworks

2014 sure looks like an exciting year for Ruby with another impressive improvement to garbage-collection as this years christmas present! Rails (still going strong) and Sinatra (so obvious it’s copied everywhere are our usual choices for developing web applications and APIs. Platform-wise we did not deploy anything on the JVM but stuck to MRI - this might change in 2014 but despite being the platform of choice for our web server of choice (puma) we have not yet seen any compelling reason to deploy on JRuby. Even though the amazing drip helps with the startup pain of JRuby it still feels way more sluggy to work with than MRI.

In the famed a-little-more-than-micro-benchmark from TechEmpower the Ruby stack consistently places in the bottom half, though. While this won’t take Rails as the number #1 choice for web applications from our table it helped accelerate our move to different languages and platforms for certain classes of problems.

Javascript is everywhere, in frontends, backends and everywhere in between - and we're no exception. My esteemed colleagues Daniel and Giuseppe blogged about our efforts with the language extensively already so I'll just reference a few of their post here, here and here.

Java - we’ll, it’s still around! Modern Java is a world away from what once was modern Java (which in turn was a world away from what once was modern Java) and offers amazing depth and breadth. It’s not going anywhere, anytime soon especially with more and more languages being ported to its platform.

Newcomer Go made a splash in the company for a couple of reasons: first and foremost it runs and builds quite fast! The language was once advertised by Google as a project build on top of the lessons-learned from their C++ teams and it shows: stuff like the compiler preventing circular dependencies, unused imports or declarations; a (relatively) uniform, tool-supported common syntax; a no-nonsense documentation approach. These are all great and useful things. Even the (extended) standard library feels very complete and mature even though it lacks some seemingly obvious stuff. It’s still more C than C++ unfortunately: personally I find Go super-easy to pick-up but the flip-side is it’s lack of expressive power - the type system in it’s current state is not really suited for functional iterators for instance. For toolchain and (some classes of) API development it’s nevertheless a very interesting choice and will remain in our toolkit for the upcoming year!

Operations support

For our operations-support and consulting we build and maintained provisioning infrastructures in puppet (partially under mcollective) and Chef (solo and server). For what it’s worth we currently put our faith in Chef - it’s just more integrated into the platform we already use extensively in other environments.

AWS OpsWorks continues to be interesting as it continues to close the gap between the infrastructure provisioning AWS offers on the one hand and the provisioning as well as the deployment of distributed software environments on the other. This is done through familiar patterns (like Chef solo and git push) and integrates infrastructure features such as auto-scaling in a compact way. The major reason we do not have a lot of software running on it are the turnaround times (which are way to long) and the subtle and sometimes tricky differences between developing locally (using Chef solo and Vagrant) and on OpsWorks. As long as the gap between a fast and fully understood local system and OpsWorks is not closing, we’re probably not coming back. Our faith in our partner AWS is remains unbroken though - Gartner is still very impressed and so are we.

In a similar spirit of OpsWorks we’ve also had a somewhat extensive encounter with the growing PaaS enterprise landscape which promises to simplify deployments and enforce useful architectural properties in todays fast-moving requirements for services and applications. CloudFoundry seems to be winning in some parts of the world, even though Berlin-based cloudControl made a big splash earlier this year with their new turnkey-enterprise-PaaS product (and exciting partners!). What really turned our heads around though, was the new kid on the block: Docker and it’s already fledging ecosystem (e.g. CoreOS and the associated toolchain). I’ve personally never had the pleasure of working with a piece of the operations toolchain that realized value as immediate and as obvious as Docker did and in turn it’s now powering our whole internal infrastructure. It remains to be seen what the company-formerly-known-as-dotcloud can do to the PaaS market with their rebranding to docker inc. and the traction that name currently generates.

What's next in 2014? We’ll probably see a deployment of a Clojure project which we’re currently using in relatively small quantities (e.g. for internal tools). Haskell is also rearing it’s multicoloured head, especially favored from our coworkers in Poland. It seems our stack’s future is going to be the same multi-language, multi-paradigm rainbow it was in 2013.

Onwards, to even better solutions and happy new year everyone!

Joern Barthel

Joern has been developing, debugging and designing software for many clients. At kreuzwerker he is responsible for architecture, new technologies and concepts. A computer science graduate, his professional interest is in the use of functional programming languages and the…

Read More ...
comments powered by Disqus