Why did we build a Generic Multi-Tenant Enterprise SaaS platform first?

Madhava Cheethirala, Co-Founder and Vice President of Engineering at WiteSand

The WiteSand team has created software products for three startups that have generated billions of dollars in revenue and been deployed by hundreds of thousands of customers. In our experience, delivering SLAs, scalability, and availability are all outcomes of a solid software foundation.

With the evolution of cloud-native architecture and contributions from companies like Google, Facebook, Airbnb, Uber, and HashiCorp, cloud native software development is easier than ever.

Our goal at WiteSand was to build a cloud application that would disrupt wired and wireless networking and security. We would have loved to pick a ready-made platform and get to business logic as quickly as possible. It may seem that a collection of open source technologies would be sufficient in theory, however as you will see below, this is not true. Most cloud-native companies end up building their own platform for the same reasons.

While there is no one-size-fits-all solution, many large and startup companies confirmed that a multi-tenant SaaS platform could drastically cut their application development costs and time

The elements that we built as a platform first are typically required by most cloud native enterprise applications. Moreover, we did not want it to be tied to any one cloud provider; this way it could be hosted on any cloud provider or even in a private data center. A further benefit of the platform is that it allows flexible tool choices, so we won’t mention which tools we used for our application.

The platform elements we built include:

  1. Multi Tenancy – Tenant lifecycle, data separation, contexts, and per tenant keys
  2. Application API Architecture – Objects, URLs, Websockets, filters, metrics, search, history, named references, privileges, validation, spec, status, mandatory fields, defaults etc
  3. Infrastructure – Kubernetes, Micro-services, Envoy, Service Mesh
  4. Edge PoDs – Kubernetes edge pods near customer locations worldwide that integrate seamlessly with the main Kubernetes cluster
  5. Communications – gRPC and PubSub
  6. Distributed Scheduling 
  7. Data Aggregation – Ability to pull aggregated data and drill down with no latency compromise
  8. Role-based access control – Local users, custom groups, SAML, IAM, access control at every entry point
  9. Encryption – Key Store, Per Tenant Keys, Data in Motion, At Rest, Secrets, RPC
  10. AI/ML Pipelines – Both in-line and batch
  11. Configuration Data – SQL with anonymization searches, snapshots
  12. Metrics – With data anonymization, RBAC, and high availability
  13. Search – With RBAC, NLP, and handling data anonymization
  14. Change Logs
  15. Events
  16. Alerts – Coalescing, correlating, and investigating root causes
  17. Templates – Ability to apply policies consistently to multiple datasets
  18. Policy Labels – Flexibility in arranging assets into groups
  19. Reports – by email or PDF
  20. File Manager – Storing reports, snapshots, and other files with object-store as backend
  21. Integrations – PagerDuty, Webhooks, Teams, Slack, Splunk, and more
  22. Framework for customized charts – For customers and developers
  23. Licensing – Subscription for features based on the modularity of the components and the duration of data retention, and others
  24. Compatibility upgrade – Automated tools available to notify and adjust for changes made on objects during compilation and runtime
  25. SaaS infrastructure security tools – WAF, NGFW, API security, Container security, patch management, open source scanning, static analysis, penetration testing
  26. SaaS Infrastructure High Availability – Backup of all data types, restoring the entire platform in the event of a region failure.
  27. SaaS Infrastructure Cost Optimization – For example, avoiding egress charges
  28. Front-end – Generated automatically (both in light and dark mode) using a Golang based compiler
  29. Testing – Hardening functionality, Chaos Monkey Testing, and Scaling
  30. …and the list keeps growing

A fully SOC2 compliant platform for Security, Confidentiality, and Availability

A Networking/Security developer’s day at WiteSand begins with writing object yaml files and backend Golang code as part of microservices. The Golang code executes the business logic and uses APIs for metrics, alerts, etc., but is completely unaware of any of the platform complexity above. In addition, the developer provides a GUI yaml file, which specifies the names of the objects, charts, and tables he would like to see in the front-end. The power of auto-generation and infrastructure rules the world after that. 

This SaaS platform now enables us to deliver network and security features and updates at lightning speed to our customers

Whether you are a startup trying to prove your value proposition quickly or an enterprise building cloud-native applications, get in touch with us here if our Platform appeals to you for cloud agnostic SaaS or on-prem, single- or multi-tenant use-cases.

See More Blog Posts »