Software Stack · Platform

Best technology stack: tradeoff between rapid prototyping and scaleability

Dan Itsara Co-Founder at Glazziq

March 27th, 2014

I'm working on building a SaaS product. Right now I'm trying to decide on what technologies to use as the basis for my software. I'm considering both a pure open source approach, such as MongoDB + Rails, as well as just going with a platform provider like Google App Engine or AWS.

What combination of technologies do you think represents the best tradeoff between rapid prototyping and scalability?

Is vendor or platform lock-in something I should remotely worry about at this stage?

Todd Ellermann Experienced I.T. Leader, CTO, and Creative Entrepreneur

March 27th, 2014

Disclaimer: We run 10 Million Unique visitors a month through Groovy/Grails on Virtualtourist.com and I have been a Linux Java guy since 1998.  I have also run/lead Asp.net, Perl, Cold Fusion, PHP and Ruby/Rails sites/teams so I am generally versed in the big frameworks.

IMHO
If we agree that there are really only 4 valid mainstream options:
Ruby/Rails
Groovy/Grails
PHP/Drupal/Joomla/Wordpress
C#/ASP.NET

Then we either need to talk about your target market, your budget, or local access to skills.
If you have no budget for licensing, then the closed M$ system is out.
If you have no budget for development  and you are B2C then PHP "Visual Basic for the Web" is your best chance.  But you are not going to scale to enterprise level, and good luck finding high quality developer talent.  Like VB, PHP developers are easy to find and inexpensive by comparrison, GOOD PHP developers are mostly white whales who would rather be working in another language (Groovy/Ruby).

If you do have some budget for development, and scale or B2B are part of your SAAS, then you really have a choice between Ruby/Rails or Groovy/Grails.   Both can run on AWS, rightscale, or various other providers e.g. Heroku etc..  Both can talk to various NoSQL or SQL solutions, likely to need both. Both Scale to reasonably degrees. Both have libraries for Enterprise type integration, both make reasonable SAAS platforms.   Both have plug-in ecosystems for development. Java is obviously more mature with more libraries depending on your requirements. Both can talk to SOLR or Elastic Search. All of them are going to be run behind Apache (except M$ stuff of course).

Now you are really in a conversation called what local talent is available, and how do I attract them?

I find that I can find lots of talented Java developers who are excited to work on Groovy/Grails/JVM here in the L.A. area. Ruby/Rails guys here tend to be a little more expensive and harder to find.

Fundamentally, I don't think you should be thinking at all about what data store No SQL/SQL you are using Mongo/Postrgres/Cassandra/Redshift/Memcache/ et al...  You aren't qualified to make that decision, nor am I with the little information you have given us.   

At the end of the day, if you are approaching Enterprise class customers, you are going to want to go with Groovy/Grails because of Spring/J2EE and JVM being under the hood.  Enterprise class customers are going to see the SPRING platform, ability to buy support etc... as a comfort.   

If you are looking for funding, that may also change your choice.  Some VC's have tech people they are comfortable with in either PHP/Ruby/(Java/Groovy)/.NET and they may be more or less likely to invest if they are familiar/experienced with that particular platform.  Your strategy on this front, might actually dictate/limit your choices.

Food for thought.


 






Lawrence Lerner Digitalization and Transformation Coach

March 27th, 2014

Dan, your technology stack should be "fit to purpose."  Even among the open source NoSQL DB (Mongo) there are many choices.

What does your product do?  Scaleable could mean a lot of things. Big data files sent regularly? Streaming small packets? Complex or simple user interface? Business rules attached?

Could you give us a few points so we can help point you in a direction? 

Harshit Rastogi

March 27th, 2014

 i enjoy prototyping with Rails +mongodb  and deploy on heroku (just few commands to deploy) .

As far as scaling is concerned , Rails can go quite a long way and if it becomes an issue then you may have enough funding by that time .

Is you are javascript lover then MEAN(mongo,express,angular,node.js) is another stack to follow. 

Panos Kougiouris Founder at NeatSchool

March 27th, 2014

Hi Dan, Assuming you are not the technology person, I would say that the key factor is to pick the platform that your technology team feels more comfortable with. All the choices you mentioned are reasonable ones, pick the one where your team believes they can execute faster. If you are successful and you are still  on one of these platforms, it might be old news in a few years anyways… Just make sure your CTO has enough stake and business thinking that she/he will not jump to the next sexier stack at that point. Lock-in is something you should remotely worry about, but only remotely. In my experience, there is never time to change the platform/vendors etc so in theory the more sources you have for your choices the better but probably these are options you will not exercise. In my lean startup, I picked Google App Engine because despite the partial lock-in it shaved tons of time and expenses on the DevOps front. There have been frustrations along the way but none big enough to justify changing the vendor altogether. --Panos

Aurangzeb Agha Founder at Metrical, Inc.

April 7th, 2014

The best solution is the one you know.  If you know PHP, you can use Laravel to get "Rails-like" rapid development going.  If you know Ruby, go with that.

At the end of the day, it's about taking an idea from concept to initial version and then iteration.  As Paul Graham says, be comfortable building stuff that might get thrown away.  Just get busy building.

Sergio Bayona Ruby on Rails Consultant

March 27th, 2014

I've hear the word "prototyping" used in multiple ways. One is developing a product front-end without backend logic. The other is, developing a quick app with front and back end. On the later, it is generally assumed that the code isn't well thought off, not meant for production, let alone engineered for future growth. In other words throw-away code. It is important to make sure everyone agrees on the meaning of prototyping.

I know of a startup were the founder thought he was getting the well-engineered software, the managers called it a "prototype" (but they really meant production grade software) and the developers were delivering throw-away code. When they finally realized the mistake they'd wasted 6 months.

Douglas Tarr Entrepreneur and Software Architect

March 27th, 2014

Rails + Heroku + Postgres still can't be beat for this.     You can get started with a free hobby plan + $20 / mo for SSL.

You can stand up a new SaaS product in week or so, prototype a lot of features, and rely on a large and mature set of libraries that can help you scale.

If you are doing a sophisiticated mobile platform, perhaps you could consider Mongo/Node etc but those aren't as full featured.

You can also pretty much pay for scale via Heroku for a long time without having to develop for it.  This is really valuable in an early stage startup.  It can get expensive once your traffic starts growing, but you can always invest in development to improve that later.

Anand Ramachandran Founder & CEO at IdeaGPS

March 27th, 2014

I would not worry about scalability until you have a proven concept, feature set, etc.  You don't really know what/how to scale at this point.

As such, the focus should really be on the rapid part of rapid prototyping.  I would take a simple task relevant to your app and see how long it takes to develop on a platform vs. open-source. 

Having a long history with the .net stack, I've found the Azure cloud to be pretty effective and fast not just for basic data-driven apps but also for more complex deployments with cloud services, virtual machines running solr, etc.  The Google App Engine provides a similar set of services albeit with different languages.

Pick the approach that lets you focus on learning about your business not new technologies..

Chris Phenner

March 27th, 2014

This article addressesthe 'MongoDB vs. MongoLab' portion of your question, but may help you think through it. Not being technical I cannot 'weigh in full,' but I do want to see how this plays out and wonder if PaaS providers like Heroku, Parse and others of their ilk might arise in others' responses -- it's a great (and likely never-really-answered) question.

Chris Phenner

March 27th, 2014

Sorry. My embedded URL in my original post was stripped by the listserv. http://mrdanadams.com/2012/mongohq-mongolab-mongodb-customer-service/#.UzRUf61dWod Again: This article only looks at options within the 'hosted Mongo' providers (and is now a year old).