Lately, my colleague Gianpaolo and I have been talking to many SaaS startups and SaaS company wannabes. Our current verdict: single instance, multi-tenancy is still a black art that only selected few have been able to master.
Looking through the lens of an architect, architecting software as a service is an area sorely in need of better guidance. Of the companies I have spoken to, some have redelivered classic client-server applications using technology similar to terminal server so that they can expedite the time-to-market, only to run into scalability issues when the market demand for their software service takes off; some have chosen to put all their customers’ data in one database, with no upfront consideration for data performance and regulatory compliance issues; a few have attempted to solve per tenant data model extensions issues with many battle scars to prove apparent intractability of the perfect solution…
This is great. The above are all reasons why I have a day job…
I’ve been spending a lot of time looking into how my team can help lower the bar for software vendors to deliver software as a service. I’m a fan of SaaS, because I believe this software delivery mechanism changes the economics of the software industry in a way that allows online information and computing to be accessible to many more people in emerging markets such as India and China. This is a topic that warrants a separate posting a different time. For now, I want to highlight what Microsoft is bringing to the table in terms of SaaS architecture guidance.
If I can try to summarize the key areas where architects should spend their time, it would be the following:
Scaling the application means maximizing concurrency and using application resources more efficiently – optimizing locking duration, statelessness, sharing pooled resources such as threads and network connections, caching reference data and partitioning large databases are examples of best practices for scaling applications to a large number of users.
The single-tenant data models of many existing on-premise applications constrain running application instance to only use operation and business data owned by a single organization. In a multi-tenant SaaS environment, this application instance and data ownership binding must be relaxed. For example, when a user from Acme is accessing customer information using a CRM application service, the application must be able to retrieve the customer data for Acme and not for any other companies. In order to enable multi-tenancy, the underlying application data model must be designed to accommodate flexibility for manipulating tenant specific data.
Many SaaS customers will want to customize the application services they subscribe to. Altering workflows, extending business documents, modifying business rules and customizing brands, logos and user interfaces are all within the plausible realms of application customizations. The challenge for the SaaS architect is to ensure that the task of customizing applications is simple and easy for the customers, yet at the same time, not incur extra manual development or operation costs for each customization. Expect meta-data to play a big part in SaaS solutions.
Of course, accomplishing these feats is no child’s (or the average architect (this may be an oxy-moron)) play – especially for existing applications that are client-server based and those that are miles away from being scalable, multi-tenant ready and customizable.
I don’t know about you, for me, all these thinking really beg the question - what would a book on SaaS architecture guidance look like? After an evening of cranking and a few iterations with fellow architects, I have scoped out the table of content of a potential bestseller:
2. Business Model
3. Application Architecture Overview
4. Scaling 101
5. Data Management
6. Tenant Management
Hybrid: e.g. federation for tenants and delegated admin for tenants' customers.
7. Tenant Customization
8. Application and Data Security
9. Programmable Software Services
10. Programmable Software Service Consumption
11. Instrumentation and Monitoring
12. Configuration Management
14. Infrastructure Security
15. Operation Structure
This book will not appear in a big bang. Instead, following the tradition of Microsoft CTP practice, you can expect to see partial but frequent releases of guidance papers from us. Also be prepared to see the chapters being revealed out of sequence.
I expect my future contributions to the guidance to be an exciting journey, with perhaps a happy destination to look forward to when the final chapter is pen. But for our SaaS ISVs, SaaS is truly a journey, with new challenges and solutions to deal with as they mature in each stage of their SaaS business model, application architecture and operational excellence.
Your SaaS journey can be exciting too – we invite you to walk with us when we open the chapter into this new era of software delivery.