Southern Technology Leaders

Which technology stack should I choose to build my product?

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, for sale
one must consider important factors with respect to productivity, sick 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.

Image courtesy of FreeDigitalPhotos.net

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?

Time to market/productivity.  Certain technology stacks can have productivity advantages in the early stages of a venture when the biggest threat is lack of a viable market.  Lately, there is a lot of positive press around dynamic language based stacks (i.e. Javascript, PHP, Python, Ruby).  The barrier to entry for new programmers to dynamic languages tends to be lower and there are many sample scripts that can be quickly copy/pasted for common problems such as uploading a file, sending an email, etc.

Engineering talent.  Each generation of programmers tend to favor languages which have support in their peer group.  As a result, it is important to consider the type of talent you need i.e. hipster hacker,  enterprise developer, web scripter, scientist, etc.  If you are in an existing software business consider your lead developers and balance their preference against business factors.  Many programmers enjoy experimenting with specialized languages  (Clojure, Scala, Erlang, Haskell, server side Javascript, etc) and this could be a way of attracting them if it matches a product need.  Occasionally, language preferences are tied to geography or large employers in the area.  For instance, Seattle is host to developers well versed in the Microsoft C++/C# technology stack.

Maintainability.  Each language and stack promotes a particular style of programming i.e. Object Oriented (OO) v.s. Functional or Strongly Typed v.s. Dynamic.  The OO v.s. Functional debate has raged for decades and generally speaking the OO solutions matter when team size and complexity grows.  There is considerable debate among advocates of strongly typed language (i.e. C++,C#, Java, Scala) frameworks versus dynamically typed ones (i.e. PHP, Python, Ruby, Javascript).  Strongly typed languages generally support better tools.  Non-mainstream languages can have the down side of compatibility issues and longer defect resolution cycles.  It is less of a surprise that, mainstream strongly typed OO languages tend to have the most enterprise support where code base size, team size, and maintenance matters.

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)
  • Javascript: JQuery, Sencha, YUI, Dojo
  • PHP: CodeIgniter, Zend, Cake, Symfony
  • Python: Django, web2py, TurboGears, Zope
  • Ruby: Rails, Sinatra
  • C#: ASP.NET

Web/App Servers

  • Apache
  • Tomcat
  • Netty
  • Ngnix
  • Unicorn
  • Passenger
  • IIS

Relational Database

  • MySql
  • Postgres
  • Sql Server
  • Oracle

Operating Systems

  • Linux (numerous versions)
  • Windows

Cloud PaaS Solutions

  • Heroku
  • EngineYard
  • CloudFoundry
  • Microsoft Azure
  • RedHat OpenShift

For reference, here are a few resources to research adoption levels of the numerous web framework and language options:

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.

Posted

in

, , , ,

by

Rupen Patel

Tags:

, ,