Which technology stack should I choose to build my product?
We aim to write as much of our own stuff here at Oxford Knight, but sometimes it’s just necessary to big-up others who contribute great stuff on the web. Here is an Article by Rupen Patel CTO at Mercurium which does a great job of explaining the logic behind selections of as tech stack.
This question is often asked by both business founders and software engineers when considering how best to position their companies or careers. In seeking an answer, one must consider important factors with respect to productivity, engineering talent, maintainability, scalability, and environment. In this article, we will explore these general considerations and highlight them using popular technology stack choices for current web based and SaaS products
First, let me motivate what I mean by technology stack in this context and why you might care – especially for non-technical decision makers. It is a set of code (and hardware) modules which build one on top of the other from general to specific. The lower in a stack that one goes the closer to hardware one gets (i.e. operating system). The higher one goes, the more specialized the functionality (i.e. web server). For purposes of a software company, choosing a primary technology stack mostly involves: a programming language/run-time, standard libraries, de-facto/standard frameworks, higher level subsystems (i.e. database), and the community which supports it. The primary stack is the one which most of your engineers will use to create the majority of your code base. Many secondary technology stack choices may be made to augment for specialized needs.
So, what are some vital factors to consider when making a technology stack choice?
Scalability. Scalability in this context refers to servicing more requests/customers with steady response times and cost. Scaling may take place horizontally (more machines) or vertically (more compute per machine). If your product will get heavy request traffic then it is important to consider the efficiency of the stack that you choose, since it will impact your operational cost and operational burden. For example, at a recent conference a presenter showed that a particular sample application in CRuby was 30x slower than C, PHP was 8x slower than C, and a JRuby/JPython/Java implementation was about 2x slower than C. For languages which run on a virtual machine (C#, Ruby, PHP, Python, Java), the underlying virtual machine becomes the bottleneck. The JVM (Java Virtual Machine) is currently considered one of the most performant general purpose virtual machines and supports Java, JRuby, JPython, Scala, and several other languages.
Environment. Many times the technology stack choice is strongly influenced by the operating constraints of the company. For instance, a company developing native iPhone apps might be forced to use Objective C – though you may still have choices for your server side software. As a SaaS software company with little devops support you may choose to leverage a PaaS provider such as Heroku/Google App Engine and rely on a stack they support. Consider carefully if all or part of your company must be aligned with a particular technology vendor, support certain legal requirements, or make tradeoffs in operational costs. This could become your overriding decision making factor though carefully balance against the vendor lock-in implications.
Community. A crucial point in the choice of the technology stack is the community. Active and vibrant communities support fast adaptation of software to specific needs and quick bug fixes. It is hard to overstress that when dealing with limited resources, the community support should be strong. C/C++, C#, PHP, Ruby, Python, Java based stacks all have vibrant and active communities.
Legal/Licensing. Open source v.s. commercial (sometimes commercial solutions support features not present in open source). Most software products today can be built using open source solutions – it is important to be aware of the type of license that software is open sourced under as future deals/M&A can be affected by it. GPL is generally considered the most commercially restrictive license. Most languages and their runtime environments are non-GPL, however, many libraries are GPL (or dual licensed).
As you consider these factors, it may be helpful to look into some of the popular choices. While non-exhaustive, this list captures most mainstream technology stacks used by current SaaS and consumer facing web products:
Language: Web Frameworks
- Java: Spring/Hibernate, Struts, Tapestry, Play! (Scala)
- PHP: CodeIgniter, Zend, Cake, Symfony
- Python: Django, web2py, TurboGears, Zope
- Ruby: Rails, Sinatra
- C#: ASP.NET
- Sql Server
- Linux (numerous versions)
Cloud PaaS Solutions
- Microsoft Azure
- RedHat OpenShift
For reference, here are a few resources to research adoption levels of the numerous web framework and language options:
- Web frameworks at wikipedia:http://en.wikipedia.org/wiki/Comparison_of_web_application_frameworks
- Job listing based language popularity: http://jobstractor.com/monthly-stats
- Open source project language popularity: http://lang-index.sourceforge.net/
- Web search language popularity:http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html
Today’s technology market relies on planned obselesence while simultaneously selling long term stable platform visions. This bi-polarity is mirrored in a tension between choosing something which supports current trends and also future proofs. As a result, there are hundreds of technology stack choices addressing different types of applications (even specialized languages for things like machine learning and statistical analysis). One must make technology choices which are appropriate to their own situation. The bottom line is that one must consider several factors in making a choice. Expect that the technology stack you choose today may be different than the one you choose two years from now.
Get in touch using the contact form below or give us a ring at 020 3137 9570. We'd love to speak with you about what we can offer.