Roy's Blog

On Software and Fish.

Java and the Lean SaaS Startup

| Comments

I’ve had a lot of time on my hands lately. I’ve mostly spent it playing with fish tanks, but as of last week, I was all out of fish work and room for new tanks… so I started talking to a few Atlanta startups. I basically go in, they hammer me with questions and I do my best to not look stupid. After what I helped build at LoopFuse, you’d be hard pressed to find someone in this town that can build something that secure, scalable, fault-tolerant and damn intuitive to use! This isn’t San Francisco, and yes, that was an arrogant statement.

There are a few common challenges I see that keep popping-up in the Atlanta Java SaaS startup world. I’ll try my best to summarize what I think is the best-of-breed combination of SaaS startup technologies and hopefully arrive at a decent stack. These are common threads I keep seeing, and also tools that I used one of my many SaaS jobs or while I worked at JBoss.


MySQL: Let me get this out of the way. I know it has nothing to do with Java, but it’s free and near-infinitely scalable in a multi-tenant SaaS environment. If you’re a startup, go MySQL. Your first few years in business won’t call for OracleDB and you’ll just run out of money faster.  Wait for your Series C, where you hire 5 DBAs and have a multi-million-dollar Oracle server running in a bunker, then you go Oracle. I don’t believe the future is unclear for MySQL under Oracle control like many others do, but that’s a different blog post.

Application Server

Tomcat (or JBoss): Now the decision becomes, which app server to use… Tomcat or JBoss? JBoss. Although, I have rarely built out a system that required full-fledged JBoss, the pluggable architecture is a nice-to-have for future build-out. Tomcat meets all the requirements for something that is fault-tolerant, high-throughput, scalable, and secure. I’m wary of having to “plug-in” components 2 years down the road in to a stock Tomcat instance, however. Most of the startups I’ve visited are deploying on JBoss, and a lot of the reasoning behind it is based on three thoughts:

  1. Everything in a box: It’s like getting those gift baskets with all the cheeses and meats. I hate salami and stinky cheese, but one day, when I’m starving, I will certainly eat it, so it’s nice that it’s included. Since JBoss includes cache/clustering/tomcat/hibernate/messaging as pluggable components, then there is some assurance that it must all work well together.

  2. Support: JBoss offers “Support from the Source”. No-brainer here. One day you will need it, and I’d rather pay for JBoss support than be at the mercy of an Apache email list.

  3. Tomcat included: This is obvious… Tomcat is the servlet engine under the hood. It can be tuned for massive multi-threading/throughput, and complemented with custom Filters and Valves. You will need those customer Filters/Valves if you plan to have any measure of security in your application. It is also the easiest way to prevent against (XSS) Cross-Site-Scripting attacks.

Why not mention Glassfish? Oracle will cripple it. IBM + Gluecode = Websphere Children’s Edition. Expect the same from ORA.


Hibernate: If you’re building your app on some No-SQL/Hadoop/MapReduce thing, good luck to you. For those of you that are building a viable startup, Hibernate is the way to go. Hibernate gives you two things that will impact your startup:

  1. Object-Relational-Mapping: Removes the need for hand-coding JDBC queries and automagically maps objects to to your schema. This feature alone, will result in faster development cycles, as Hibernate has a low learning curve and is a convenience tool. Hibernate talent is easy to find, so new developers ramp up quickly as well.

  2. Less Refactoring: Your database schema will likely change 100 times as you build-out your app. Hand-coded JDBC queries are an absolute nightmare to maintain with a schema that is changing. Hibernate gives you the ability to quickly refactor mappings and HQL calls throughout your entire codebase, where JDBC falls flat. ie. It’s much easier for a developer to find/refactor usages/properties of a Hibernate object than to run a wildcard search across the JDBC layer of code to find a table-name.

Pitfall to avoid: Whatever you do, never ever allow Hibernate to be your DBA by letting it automatically create and update  your database schema ( flag in your cfg file). Your DB should be designed by someone with experience in building scalable DB architecture, and not a schema-export tool that’s reading from an XML file a developer hacked together! Your database WILL BE your central point of failure and your performance bottleneck eventually. Don’t make it worse!


By all means, you should all go out and use Spring or Struts or JSF or Seam as your foundation for a solid and usable UI.

When you’re done swallowing and expelling that line of crap that’s dished-out at Java conferences, let me welcome you to 2011…

For a clean dynamic UI, I advocate… no… champion… no… worship Ext-JS. I developed LoopFuse entirely on Ext-JS… you can see the ExtJS blog post here. It was only after I looked at what a competitor was doing with ExtJS that I decided to completely GUT JSF from the system and replace it with a “flatter” architecture without any MVC. Who the hell does page-turning apps these days anyway? The beauty of it is that redoing the UI in ExtJS was trivial, and the impact to customers with regards to usability was immeasurable!

Lessons learned:

  1. The flatter the architecture, the easier to maintain/adjust and ramp-up new talent.

  2. Separation of disciplines. Would you have the carpenter that installed your front door also lay your plumbing and wire the electrical in your new house? No. So don’t have the Java plumber work on your UI. Have a UI guy work on your UI.

  3. Business layer and DB layer were untouched by the move.

  4. Page-turning went away.

  5. JSON was used as the standard communication format between UI  and Java Servlets.

  6. Those same JSON calls were then leveraged with the help of Jersey to offer a WS API (Killed two birds with one stone.)

  7. No more cryptic JSF error messages.

  8. You can actually refresh a page without triggering an action!

  9. The volume of free ExtJS plugins and components is amazing.

  10. . ExtJS, even with it’s default theme, looks sweet!

  11. . It’s cross-browser compatible.

  12. . Dynamic flash charts also understand JSON… double-win!

Let me qualify why I DON’T like the use of MVC frameworks – your Java developer should NOT be touching UI code. I know… Java developers are the smartest people in the world, but really now, Java guys are generally horrible at building UIs unless they’re targeted for other developers. I have never liked MVC frameworks, and I accuse them for being the sole reason that tech like PHP and RoR have grown in adoption with the web crowd compared to Java. A developer hacking at XML for a UI, is just wrong, and the learning curve is steep in some cases.

And so that is all for now. I’m sure I’ll update the blog soon with some other nuggets of wisdom to share as I spend my time walking about town.