Special Guest Post by Joe Dennis, Intuit Group Product Manager
Special contribution by Vishal Aggarwal, Intuit Senior Product Manager
In a comment on a recent blog post, some questions were raised about moving from desktop-focused development to a SaaS-based model. We’re increasingly hearing these kinds of questions from developers who want to take advantage of Intuit’s growing SaaS ecosystem.
In this post, I’ll try to address some of these questions (e.g., hosting / resource strategy, data persistence) in the context of what to think about when creating a new SaaS stack.
I was a co-founder and the CEO of Itrios – the company behind the itDuzzit platform – so I’ve gone through the steps of founding and growing a SaaS platform company. Much of what I’ll go into here is based on the experiences that Steve Mendoza (one of my co-founders) and I had in creating the itDuzzit technology and deploying it as a SaaS solution.
One caveat – what I’m discussing in this post largely concerns technical stack choices. This all assumes (a huge assumption) that the product concept is all in good shape – that is, there is a validated product approach (think lean startup methodology), you know who the customer is, and you’ve at least done several iterations of mockups with prospective customers.
First, where to host?
There are a number of great IaaS (infrastructure-as-a-service) and PaaS (platform-as-a-service) offerings:
IaaS (infrastructure-as-a-service): If you are building an independent app (something that isn’t tightly coupled to a functional platform), IaaS is the way to go. AWS (or a similar platform) is a no-brainer – you can leverage on established best practices and features to rapidly stand-up a secure, scalable stack at a reasonable cost. Platforms like this have plenty of automation features to address resources (e.g., automatically spin up additional servers when load increases). I mention AWS specifically as that’s what we used for itDuzzit, and it is the industry leader – but there are other excellent choices. You might want to stay a bit “vanilla” with this – that is, use technologies on this stack that are available on other stacks so that you’re not locked into one in particular – but that’s not necessarily a big problem.
PaaS (platform-as-a-service): PaaS (e.g. force.com) makes sense if you’re building an app to specifically target a particular ecosystem. So, if for example, you’re building an app that will be tightly coupled to Salesforce and distributed through Salesforce’s AppExchange, force.com is a natural choice (great engineering and distribution within the ecosystem). However, if you aren’t going to primarily target a specific ecosystem, the downside of the PaaS approach is that you’re locking into a proprietary development stack. That’s not a platform viability risk, but rather a lock-in / pricing risk. So, unless the platform services are very compelling, I’ve got a preference toward using commodity technologies that can be deployed in multiple IaaS stacks.
Assuming you’ve chosen an IaaS platform, the next thing to do is choose a tech stack to develop with on that platform. Let’s say that you’re building a web app that persists some data (sort of vague – but we’ll start there). If your data is transactional in nature (you always need a consistent view of data at any one time in the system), you should be considering a relational DB such as MySQL. On the other hand, if the data you persist isn’t transactional, or doesn’t have relational structure, and you don’t care if everyone sees exactly the same thing at the same time (as long as eventually they do), then a NoSQL db can be a great choice. You could even go with a hybrid approach (something we’re doing with itDuzzit) where transactional data is in a relational datastore and blob data is in a NoSQL datastore. IaaS providers are making databases available as a service (they handle backups, maintenance, etc), making operation of a production db relatively painless.
The application and front-end layers also depend on what kind of app you’re building. If you believe that your app needs massive scalability from the get-go, you’ll want to consider a more robust (but perhaps more complex) framework. However, if you’re still at the point of getting minimal viable product out, and believe you’ll be reworking later, you want to choose a platform that maximizes speed of development. There are a lot of good choices; I’d select based on:
1) Widely Used, Open Technology – I want to select technology that I can run on many IaaS platforms (so that I can treat hosting as a commodity). So, slight preference to something like PHP, Node JS, Java vs. something like .net – I don’t want to be locked into anything that I need to buy from one provider.
2) What is my dev team comfortable with – again, there are a lot of good choices – so hopefully you’ve got good developers that are using current technology. As long as they are on an open current technology, it doesn’t matter that much which one. (We all have our preferences, but people can get overly religious about this – there really are a number of good choices).
3) Web Services – plan to incorporate web services into your offering from day one. In fact, if you use a design style in which all backend processes are callable via web service, and your frontend uses these web services, you’ll have a great integration story from inception of your app. Note that I’m really biased in favor of web services, as integrating apps via web services has been my main focus over the last several years with itDuzzit – but this really will serve you well, as in the SaaS world, interoperability is a big driver for app distribution and adoption. When designing and developing web services, look to adopt a straightforward, standard model (e.g. use OAuth2 for authentication, REST as the style for exposing web service resources, and JSON as the payload). You want to make it as easy as possible for your developers to adopt and integrate your technology – so using industry standards really helps.
We’d love to hear your thoughts, comments, and questions, and look forward to continued discussions around developing SaaS solutions. Comment below, join the discussion on our forums at http://intuit.me/IntuitDevForums, or Email us at IntuitDeveloperRelations@intuit.com.
Leave a Reply