Nick Hardiman outlines the steps of taking an example SaaS solution to the world by taking advantage of AWS CloudFormation templates.
Please take a ticket and wait to be called. You are in a queue. Your request is important to us.
In order to show how a few pieces of the SaaS jigsaw fit together, I'm going to demonstrate a way of revving up a service using Amazon Web Services and their CloudFormation templates as a base for my infrastructure. My example SaaS on offer is a support ticketing system - a service that a lot of organizations and businesses need. Okay, this is not a real opportunity. The business plan and the technology are, well...let's just call them incomplete. Getting ahead in business isn't that easy. However, the steps here are the basic outline of how your great idea for a service can actually make it to customers all over the world via the wonder of the cloud. The hardest things you'll have to do are come up with a business plan and make the initial design choices, outlined below.
A support ticket system
Every product vendor needs a support ticket system to communicate with its customers. It's a pretty well-established set of request tracking functions.
- A customer requests support by putting their details in a web front end and getting a ticket number.
- Records are created in a data store back end.
- Tickets are queued up for the support workers.
- Support workers help and update the support records.
I'm not offering a service where my customers raise support tickets for me. I'm providing my customers with a support ticket service so their customers can raise support tickets for them.
Support ticket systems have been around a long time and are widespread. Basecamp, Intervals and Unfuddle are successful project management service companies that offer web-based request tracking services.
There are many knobs and dials that vendors can twiddle to differentiate their support systems.
- The workflow control system is much fancier than just having a status of new, in progress, or resolved.
- Email, telephone and other communication tools are cleverly integrated with the support system
- Licensing options range from free to carrier-grade.
Companies founded in the last few years had the opportunity to sidestep the requirement to spend a million dollars on computing power up-front. This has the advantage of lowering the barrier to entry to the IT world, and the disadvantage of saturating the market with entrepreneurs trying out new ideas. I will have many competitors in this support space.
Location, location, location
The global reach of the Internet eroded the requirement to be close to customers. I may choose to move my company to one of the startup hotspots like Berlin, San Francisco, or Tel Aviv to be close to a business incubator, but I don't need to move to make SaaS sales.
Should this service be near me? Do I want to keep data in country boundaries? The machines, data stores and everything else that make up the service don't have to be in or near my company.
Should this service be near my customers? Do I want a CDN?
Make it scalable
Just because this support service is centrally hosted on a cloud service does not make it SaaS. B2C (business to consumer) websites have been around since long before the cloud. This service does run on the AWS multi-tenant infrastructure so that qualifies.
Always available, instant service
My SaaS solution must be on-demand and self-service. I want to provide an instant service. A new customer can register any time they want, day or night. They must be able to start running their own support ticket system within ten minutes. That's an aggressive reaction time that will only work with an automated system.
The good thing about APIs is all the automatic provisioning it has made possible. A lazy sysadmin can dream of automating all the work he does and lying back, basking in his own laziness (don't underestimate the work involved in avoiding work --automating everything is on a par with moving a mountain).
For my Support Ticket Service, the virtual machine creation will be automated using AWS CloudFormation templates. AWS brought out its CloudFormation service in 2011, to automate the build process.
Why not build the system manually? This is a scalable system. Creation and destruction of machines to match demand may be a daily event. If you tell two system administrators to create two identical clusters of machines to an exact specification, you can guarantee those two clusters will be different. The only way of getting a reproducible cluster is to automate the build process.
I'm providing my customers with a service so their customers can raise support tickets for them. They all have a slice of my system, so I must avoid the dangers of noisy neighbours, security breaches, and policy compliance.
Open source softwareThe community around the Amazon OS and Drupal CMS are enormous. There is both free and paid support available. When a technical hitch is frying my noodle, I can use their support ticket systems to reach out for help.
Open source has the beneficial side effect of taking the money that would have gone to buying closed source licensing and re-allocating it to marketing my SaaS.
The simplest way to charge is to charge each customer for the time they use. The final part of my SaaS decision is to offer metered billing -- some kind of charge based on usage, such as time taken, tickets raised, or computing resource used.
What would you do?
More to go
This is a handful of fanciful design decisions around my example service. It's not comprehensive. What is comprehensive is the success of SaaS services. We still have a long way to go -- just because Salesforce.com owns the CRM SaaS space doesn't mean there is no room for budding entrepreneurs and visionary enterprise leaders to successfully bring their own SaaS solutions to market.
In the next installment, I'll introduce you to the CloudFormation web interface, choose a sample template, and take you through the steps of creating a key pair and making basic configuration decisions.