See the full blog post (with graphs of the results) at jClarity -->

Server / Nodes and their Roles - Survey results

Back on May the 29th we sent round a survey on our community mailing list, Friends of jClarity, asking our members about what infrastructure they were deploying onto and how they were deploying to it. We were looking for information about whether people were really adopting cloud deployment technologies and how they were being used.

We knew how laborious it can be to fill out endless surveys, so we decided to keep it extra short, with just four main questions.

1. Types of machines

The first question we asked about was what kind of machines people were deploying to.  As you can see from the graph below people aren’t using bare metal for deploying their JVM Apps anywhere near as much as they used to.  In particular the rise of cheap virtual machines has been incredibly popular.

Infrastructure-As-A-Service is also particularly on the rise as a technology.  This shouldn’t be seen as too surprising given that in many ways IAAS cloud providers have many of the advantages of using virtual machines, but with sometimes more convenient pricing models. We also asked people to specifically name the IAAS vendor, if they were willing, and unsurprisingly Amazon’s EC2 came out massively on top.

Platform-As-A-Service cloud models, despite the hype, were considerably less popular.  These tend to be more restrictive platforms where developers have to target and deploy to the platform in question.  A lot has been said about the PAAS model with huge amounts of talk about vendors like Heroku but so far, for our users at least, people haven’t made the mass migration to PAAS. We hope to re-run this survey again in the future, which will let us establish adoption trends for these kind of technologies. 

2. Number of servers/nodes

The second question was about how many servers/nodes they deployed to. The results here weren’t too surprising as we knew that a majority of our community came from traditional Java enterprise backgrounds. There were the two distinct groupings that you’d expect of the small/medium sized shops and a few of the financial services / government behemoths.

What was interesting is that there seemed to be no 1-10 server “hobbyists? or pet project style responses, which is perhaps an early indicator that Java/JVM developers weren’t yet experimenting with the Java/JVM PaaS space back in May 2013. It could also mean that our respondents were purely responding in their “work? capacity as opposed to any “at home? projects they may be working on.

It did make it clear to us that our tooling would need to help users find issues quickly within a cluster of at least 11+ machines. This was invaluable for us in terms of the UI/Ux design for our products. 

3. Infrastructure and deployment technologies

The third question was about the infrastructure and deployment technologies they used.  This resulted in a very diverse range of answers with no particular technology dominating the field.  Both Puppet and Chef provide a DSL for managing the configuration of servers and are clearly on the rise in popularity, but haven’t yet reached mass market appeal.  The goold old-fashioned shell script still being the most popular choice for many people: it may not be pretty, but it works.

Some PAAS and IAAS providers also develop their own tooling which lets you control your software deployment and a few users had begun to adopt these, whilst windows users felt comfortable with the MSI format for installing their software.  This suggests that some niche platforms will continue to use different tooling no matter what the overall market adopts.

Another popular choice was to use an artifact repository, such as Nexus or Artifactory, in order to manage assets internally.  We do this internally at jClarity and it lets us very easily track and managed released binaries.  If you submit a bug report on a 6 month old Censum build then we can almost instantly grab the exact same binary that you’re using and reply ASAP.

The idea of having a single golden image which gets deployed had some traction.  This is a nice simple solution for rolling out images across machines if you have a very homogenous environment.  On the other hand rolling out updates to a small part of the image isn’t particularly easy without rolling out a whole new image.  Amazon’s EC2 service has built in support for this kind of golden image approach through their AMI tooling.

4. Homogenous servers/nodes?

The final major question was whether they deployed homogenous servers/nodes (or not).

Just over half of the respondents had a deployment model where they deployed servers that fulfilled a certain role and stayed that way.  The remainder had some sort of variation of their servers fulfilling roles in some sort of a dynamic manner.

This was an unexpected result as we had anticipated that there would be a higher percentage of enterprise deployments that were set in concrete with strict guidelines and boundaries on what roles they could play.

The large minority of dynamically changing servers may be a result of rapidly changing business needs, a growing confidence in devops tools being able to handle the complexity or simply a case of a deployment model that grew organically.  We look forward to asking more questions in this space for a future survey.

We should also caveat that in total the survey had 47 replies. This is a reasonable number and we think the data is useful enough to publish, but one should always bear in mind that this is a relatively small sample compared to the total number of developers in the JVM ecosystem. We would love for more companies to try and get numbers out about these kind of topics and plan to run a much larger survey in the coming months.

We’ve built the jClarity and Censum products based directly off feedback from small surveys such as these as well as numerous conversations with our ~1000 strong Friends of jClarity community. Come and grab your free trial of the results of that work, Java/JVM performance analysis tools, ready for the cloud (and the enterprise)!


The jClarity Engineering Team