We often say that the cloud is for everyone, but not for everything. Between social networks, mobile apps and entertainment, we all use some type of cloud-based service. However, SaaS operators who are anxious to move off of legacy hardware and on to the cloud may find that due to regulatory or industry constraints, parts of their architecture must remain in a dedicated environment. For example, a finance-related service could run its website front end, file storage and test/dev in the cloud, but due to federal regulations, it could be unable to move sensitive customer databases or shopping cart functions to the public cloud. This is a hurdle that prevents many businesses from adopting any type of cloud asset.
Last week, we talked about why SaaS startups choose cloud, however the cloud isn’t just for SaaS startups. Mature SaaS businesses traditionally plan capacity based on historical performance. If an application saw a spike during a certain period last year, you’ll plan to handle that same spike next year. Retailers, for example, use this model to secure the additional capacity needed to manage big holiday buying days like Black Friday and Cyber Monday. Taking on the capacity to serve millions for a few days of the year while only seeing a few hundred hits a day the rest of the year means creating a resource gap between what’s used and what’s sitting idle.
Though we work with many large enterprises, as a former startup ourselves, we are passionate about helping new businesses access the infrastructure needed to build out their dreams. More so than other business models, a SaaS application provider’s infrastructure is akin to the storefront of a brick and mortar business. If the windows are dirty and customers can’t get in the front door, your store won’t thrive. Similarly, if an app is plagued with slow response and frequent downtime due to inefficient infrastructure planning, your app is likely to wind up dead the water.
Last week we talked about cloud services to help enhance your SaaS application infrastructure. Today we’ll talk about how to use the cloud to expand your current infrastructure into the future. The cloud gives you the same options for scaling that you’d find in a traditional SaaS environment with advantages that you can’t get out of traditional architecture.
The SaaS market is expected to grow to over $12 billion in the next two years, according to Gartner. New apps are being released at an alarming pace, generating intense competition. In the battle to survive, SaaS operators need the freedom to focus on creating differentiated software solutions and not become bogged down with the complexities of infrastructure planning and application service delivery. That’s where Rackspace Application Hosting Services help ISVs eliminate hardware responsibilities, access better infrastructure resources and focus more time on growing the business.
Pod architecture assigns a set of machines to a specific job or customer for all of its required tasks. In most of our SaaS configurations, our customers use shared firewall, load balancing and storage layers across multiple pods. Each pod contains the web, application and database layers for the customer’s individual users. Architecting in this way delivers the following benefits:
Can your business survive a website failure? The answer varies based on the criticality of your website to overall business operations. Walk into an understaffed brick and mortal establishment with a rusty, hard-to-open door, cracked windows and a faulty cash register — for most, the condition of the store would be enough to walk out without even checking out the products and services. If your business runs on the web, you can suffer the same loss of confidence with slow performance, rampant downtime and security holes.
After years of working with SaaS customers, I hear every day about horror stories and challenges related to scaling. Simply put: scaling can be a headache. SaaS applications thrive – or die – on the performance of their infrastructure and as you grow you’ll have no choice but to face the scaling dilemma. How you scale your application to distribute traffic and run your code can mean the difference between an instant response for users or users waiting for your app to respond or update.