Some companies prefer traditional on-premise software, but others have decided to move to the cloud. If you’re thinking about choosing a Software as a Service platform, which offers mobility and access to information anywhere there is an internet connection, there are several questions you’ll want to answer first. To clear up any haze, we’ll shine our fog light on three of those conundrums here. Read Part 2.
1. Choice of Platform: Data Center or Utility Cloud?
When choosing a cloud version of your software, you may debate whether you should build your own data center, use a co-location service or go with one from a utility cloud provider. Your own data center, also known as a “co-lo” is an interesting choice because you can get great performance from your software by running it on specialized hardware such as a high-speed storage area network (SAN).
You can get this performance without making any changes to the architecture of your product, which saves time and money. You can also outsource the operations of your SaaS product to a managed services firm. This will save you from having to build your own team with that expertise.
The utility cloud is a compelling compute as needed. They have a growing global footprint that allows you to expand internationally. Finally, public utility cloud companies are investing a lot in security, which we’ll get into more in my next column. However, employing a utility cloud will mean you have to migrate your software. Either separate your architecture into a set of services or contain it and run it using cluster and scheduling tools such as Docker and Docker Swarm.
With SpheraCloud we chose to host our software for the performance and cost benefits. I’m proud to share that the product has achieved 99.92 percent availability every month (including scheduled down times). We’ve been able to accomplish this with an elite team of only three engineers. We’re actively working on a roadmap to transition to the utility cloud because we believe it’s difficult decisions to keep SpheraCloud relevant and thriving for years to come.
2. Tenancy: Which Model Will You Use?
Tenancy—or how many customers use a particular instance—is a key consideration when it comes to SaaS. With single tenancy there is a separate instance of the software and the supporting infrastructure for each customer, including the database. You have little, if anything, shared between customer deployments.
With multitenancy you have a single instance of the software and its supporting infrastructure serving all your customers. That means the software application, database, file shares and other resources are all shared. In other words, your software architecture separates customers from one another.
There are ways to make single tenancy work if your current architecture doesn’t lend itself to multitenancy. Single tenancy might even be preferred by customers because they had their own dedicated instance that is walled off from other customers (who might even be competitors). To make this work you’ll want to have a roadmap that leads you to evolving your architecture to services that are shared among your single instances over time.
By doing so, you’d be taking advantage of the shared infrastructure or platform services over time, bringing down costs and modernizing your software architecture. The shared infrastructure of a multitenancy architecture is generally preferable. Having customers of all sizes sharing infrastructure and data center operations means you can keep costs low. Maintenance is also much easier when you have one instance to update and operate. You can also avoid doing lots of provisioning of new infrastructure every time you bring a new client on board. When parlayed with a utility cloud provider, you can also take advantage of their platform services over time, which allows you to increase capacity without additional infrastructure.
SpheraCloud is a multitenant architecture that allows us to innovate quickly and deliver a great experience for our customers. We use the New Relic Platform to monitor web-transaction response time against throughput over a rolling seven day period to ensure the platform is working properly—and we take action quickly if it’s not!
3. How Often Should You Release Your SaaS Solution?
Traditional enterprise software typically has an infrequent release cadence. It’s common to see updates once or twice a year, but with a SaaS product, customers expect updates much more frequently— possibly even many times per week.
Deploying software on a single set of servers for one customer is straightforward. You can execute a few scripts, program and run an installer, and then you have an update. Deploying software across a span of servers that supports many customers gets more complex quickly. You must have infrastructure and process in place to sequence the delivery of changes. Most importantly though, you must wring out all the manual steps in your deployment so that engineers have a “push button” way to deploy their functionality to staging environments, for testing and, finally, to production for the actual release.
We’ve found that deploying SpheraCloud twice a week is the right balance between innovation and time for our customers to absorb changes. Frequent deployments drive good engineering practice. In fact, we’ve made over 3,000 discrete server updates so far this year. Our highly available infrastructure enables full patch and reboot cycles for all servers each month with zero user impact. It’s pretty-cool stuff really, and even though we have our head in the Cloud, there are nothing but sunny days ahead for our SpheraCloud customers.
Perry Marchant was previously Sphera’s chief technology officer.