A robust and extensible Cloud platform is the foundation for building and distributing powerful Software as a Service (SaaS). It provides a common layer upon which you can quickly iterate to deliver specialized services to meet the needs of your end users.
Joni Collinge, Diagrid's founding software engineer, presented at QCon London and discussed a case study on the evolutionary design and implementation of the Diagrid Cloud platform, which underpins Diagrid’s SaaS offerings.
Cloud platforms such as Google Cloud Platform (GCP), Azure, and Amazon Web Services (AWS) are essential for delivering Software as a Service (SaaS) due to their capabilities in self-service, multi-tenancy, scalability, and elasticity. These platforms enable developers to use high-level coding patterns and bootstrap their applications effectively, supporting a cloud-agnostic environment that accommodates technologies like Kubernetes (K8s), MySQL, and Redis. A significant advantage of using these cloud services is maintaining a multi-cloud strategy, as seen in the Diagrid model, which helps manage egress costs and ensures compliance by keeping data portable across various regions.
To effectively manage these cloud environments, the design of the control plane is crucial. This includes developing a robust API strategy using Cloud APIs, Cloud Control API, and ARM API, designed to streamline resources' exposure and management. The Kubernetes Resource Model (KRM) and tools like OpenTofu and Terraform enhance resource management by providing structured templates and examples. Adopting a cell architecture and decentralized control through solutions like Kubernetes Control Plane (KCP) allows for scalable, elastic environments supporting complex multi-plane architectures. Integrating REST APIs and custom control options ensures that users and service providers have efficient and flexible control over their resources.
After the session, InfoQ interviewed Joni Collinge.
InfoQ: Given your experience leading the engineering efforts at Diagrid, how do you approach designing a cloud platform that meets current user and business needs and is adaptable to future requirements and technologies? Could you share specific strategies or design principles that have helped you ensure the platform remains extensible and maintainable as it evolves?
Joni Collinge: Building a Cloud Platform that can be easily extended to meet future use cases and evolve to support increased demand is a complex task. However, a deliberate design isolating machinery layers from business logic specifics can simplify this process. The machinery responsible for providing the mechanics of how to structure data generically, how it moves through the platform, and when logic operates on it should not handle specific implementation details. Instead, the business logic is mapped onto the machinery to provide the APIs and specialized processing logic to serve a particular set of use cases. This approach allows for the introduction of new implementations on top of the existing machinery when a new use case arises, eliminating the need to start from scratch.
The API server in Kubernetes is an excellent example of achieving this separation. Its design has led to its use beyond its original scope in many cases. However, using it directly as a general-purpose Cloud API server can be challenging and inefficient due to certain constraints in the Kubernetes system. Therefore, I recommend that others deconstruct its design, understand the founding principles that enable its extensibility, and identify its limitations. Once these principles are clear, you can search for similar characteristics in other places to help you build an extensible Cloud Platform that goes beyond the limits of Kubernetes.
InfoQ: You mentioned exploiting abstractions such as Kubernetes, Dapr, and Cloud-Native services. Can you elaborate on how these technologies contribute to achieving portability and extensibility in SaaS offerings?
Collinge: There is a distinction between how you choose to host your Cloud Platform and the service your Cloud Platform provides. For instance, you may give your users a Kubernetes "like" API to manage their resources, but this does not necessarily mean you need to run your Cloud Platform on Kubernetes. Appreciating this difference is essential so you don’t limit yourself to trying to solve both problems simultaneously when they can be solved separately. If you want your Cloud Platform to remain portable across infrastructure, your code has to bind to APIs and execute on a runtime that is agnostic to the provider. Choosing which APIs and runtime you select is a decision driven by your specific requirements and constraints.
However, as a start-up, it’s generally good advice to offload as much work as possible to your hosting provider by leveraging managed services. For us, this meant using Kubernetes for our runtime, MySQL for our database, and Redis for caching and streaming. The Dapr project can also help by abstracting your code from the underlying infrastructure, allowing you to bind to more productive Cloud APIs without sacrificing portability. For instance, you can use Dapr’s Pub/Sub API to perform asynchronous messaging against Redis or a higher-level service like AWS’s SQS with no code change required.
InfoQ: Additionally, are there any pitfalls or challenges that teams should be aware of when integrating these Cloud-Native technologies into their development process, especially when aiming for rapid adaptability in a competitive landscape?
Collinge: My biggest concern when it comes to adopting Cloud-Native technologies is the increased level of complexity and fragmentation. Most Cloud-Native technologies have a compelling use case, but that does not mean they are necessarily valuable for your solution. Adopting any new technology should be driven by your own requirements and after doing due diligence to ensure its value. Don’t underestimate the mental tax you are charging your engineers by adopting technology for the sake of it.
Access recorded QCon London talks with a Video-Only Pass.