Whats your stack?

At work one of our standard interview questions is for the interviewee to describe their current stack, from Operating System through to front end libraries give us a full view of what technology they would choose if they had a choice.

I’ve been playing with lots of different tech recently, and thought it would be a good time to answer the question myself.

So lets start from the bottom, and work up from the Hardware through the stack.

Amazon Web Services

This one is a simple decision, the freedom that the AWS stack provides when it comes to trying new technologies and a forced attitude to configuration management and fault tolerant infrastructure design just makes

With a solid configuration management solution, being able to fully automate a copy of your production system in a matter of minutes is an amazing game changer. Especially when it will only cost a matter of dollars.

There are any number of other reasons to run an AWS stack, but the second biggest benefit has to be the Auto-scaling ability. As long as you design for scale and use the right types of indirection, you’ll have a platform that can handle tiny and massive loads while only paying for the platform you use.

Git

What more is there to say, the Git technology and tools like GitHub and Stash have improved on a already key technology (Subversion) by adding excellent branch management.

The big success of Git adoption has been the innovation that has come out of GitHub. I could fill this blog post with the things I love about GitHub and the features they have added to source control.

For corporate developers that need to run a Git server inside their enterprise look at Stash by Atlassian, while it doesn’t have all the features of GitHub, it has enough to get the benefits of Git.

Chef

This is the most recent tool in my kit, but it is beginning to feel the most exciting.

I’ve needed a way to manage application server configuration for a long time, and with the introduction of AWS into the toolkit being able to provision from bare (or near bare) metal with Chef is key.

I’m only a few weeks into work out how it all hangs together and how to best make it fit to solve my needs, but its getting massive amounts of work done quickly.

The ability to repeat a configuration deployment from scratch is amazing. This is where application development is currently innovating, by turning the entire stack into code we get much more control and flexibility in our environments.

Capistrano

My first serious introduction to Configuration Management was through the use of some simple Capistrano scripts.

While Capistrano is best suited for the deployment of Ruby based applications, we have been able to extend its core features to support application deployment and configuration of complex Java applications.

Its core support for executing remote commands (via SSH) on multiple sets of servers is a simple feature, but enables a whole depth of possible actions.

For a long time our entire Configuration Management was run fully by Capistrano scripts, only to be recently upgraded for Chef for more ‘off the shelf’ component deployments.

Java

While a great number of my stack elements are not Java products or libraries, I still feel that as an application programming language of large and complex systems you can’t beat the JVM and the depth of Java Libraries.

As I am more introduced to tools around Ruby I can see a place for it moving forward, but in a supporting role not as the main codebase.

Tomcat

While Tomcat has been around for ages and a day, its rock solid, well understood and just works.

I’m also bias’d towards Tomcat as its pretty much the only application container I have run, but has always suited the needs of the projects I’ve been on.

Apache

So if Tomcat has been around for ages, then Apache was ancient why Tomcat was pre 1.0. But the same rules apply, it works, does its job well, rock solid and well known.

By connecting Apache and Tomcat together, you end up with a flexible configuration platform that can use Apache modules to generate powerful rewrite rules, load balancing even security settings.

Sensu

Application monitoring is becoming the most critical part of any platform. With multi server environments and more and more moving parts, having a central view of what is running and how it is performing is critical to the success of any application.

Sensu falls into the category of something I’m interested in, but have not yet had the chance to take for a serious run. I like all I am reading about it and what it offers, but am yet to have the chance of running a serious sensu implementation.

Coming in a close second in monitoring has to be the tried and true Nagios, this is what we (and I guess a lot of others) actually run to monitor our systems, but its beginning to feel long in the tooth and adds more configuration overhead that we get out of it.

The fact that it works and does its job well enough is the hard sell on spending more time with Sensu, but moving towards more dynamic and adaptive environments (especially around AWS) a new monitoring solution is required.

New Relic

One of the greatest finds of the past 12 months has to be New Relic. Its monitoring and performance tracking in a box is just amazing, and shows what modern SaaS solutions should be.

New Relic is a great application tier monitoring solution, and while I would love it to do many more things, its still amazing how much it can do.

It is still lacking a bit in non application monitoring, so can’t hold all the cards at the moment, but works well alongside other platforms.

Don’t write this off as a Java tool, I know I initially did, but we have had it run against PHP stacks with just as much useful information generated.

Metrics (by Yammer)

Got put onto this simple library that has finally linked my need to get application tier monitoring with the existing platform monitoring.

While New Relic can get ‘some’ key metrics from the server, it lacks the scalpel like focus you sometimes need on metrics. By this the Metrics library you can extract any JMX metric value, or even include you own deep integrations to export your metrics.

If there is only 1 thing you look at from this post, I would recommend to go and look at Metrics.

Think about it as the Bootstrap for application metrics.

Librato

Not sure where I first found this tool, but its a very simple tool for graphing metrics against a time series, and while this sees like a simple task, the swathe of plugins available and the ease of integration shows off its power.

There are lots of things that can produce data, and as I’ve stated many times in this post, knowledge is power, but wading through pages and pages of data doesn’t often help. Being able to interpret the data as information is key.

Timeseries data needs to be visualised on a graph, and with the massive amount of data you need to analyse application performance you really need to be able to overlay multiple dimensions of data on the fly.

Librato at it’s core is a simple tool, but a powerful cornerstone in your application’s stack.

Summary

If you’ve read this far you can see my stack is very bottom heavy, and that is by design. The application tier will vary from product to product, but they all require the same support from their platform.

Having a solid platform, an ability to control it and identify how it is performing is key to maintaining a successful product.

The best thing about nearly all of these projects are they are OpenSourced and available to all, so you can stand on the shoulders of giants, scratch your own itch and help your fellow developers all while building a flexible, scalable and hopefully profitable product.