SolSA: Architecture as Code for the Kubernetes Era
Kubernetes is becoming the de facto standard for managing applications in the cloud. Thanks to operators, Kubernetes can be extended to manage virtually any kind of application resources: not only containers and microservices, but also virtual machines, cloud functions and events, managed cloud services, policies, meshes, etc. Each resource can be declared and configured with a few lines of YAML. However, while YAML is a fine language to perform some basic configuration, we believe application developers need to reason about applications at a higher-level of abstraction using the languages and tools they are familiar with.
The SolSA library for Node.js —a shorthand for Solution Service Architecture — makes it possible to specify the architecture of cloud applications as programs. SolSA enables developers to configure Kubernetes-managed resources by writing JavaScript or TypeScript code instead of YAML. SolSA automatically translates the developer written code to the required lower-level YAML. SolSA integrates with IDEs such as Visual Studio Code to provide online validation, code completion, and documentation of the various resources and configuration parameters.
But SolSA is not just a syntax. SolSA enables the definition of either simple or sophisticated architectural patterns that can be used across many applications. These patterns can be smart and vary their content based on configuration parameters or deployment context.
A First Example
SolSA offers a ContainerizedService abstraction that combines a Kubernetes Deployment and a Kubernetes Service. This containerized service exposes a small set of curated configuration parameters including the service name, container image, and service port.
SolSA can automatically derive an Ingress for a ContainerizedService and adapt this ingress to the deployment context. Under the hood SolSA leverages Kustomize to permit targeting multiple environments, e.g., a local development cluster, a Red Hat OpenShift on IBM Cloud cluster, or an IBM Cloud Kubernetes Service cluster.
Multiple resources can be combined into a Bundle.
To generate the YAML for this example we invoke the solsa yaml command:
solsa yaml hello-world.jsAs illustrated by this example, the SolSA code is much shorter than the corresponding YAML. More importantly, the SolSA code is simpler and requires less expertise from the developer than YAML.
SolSA handled a lot of the details for us. It automatically linked the Kubernetes deployment and service together with labels and selectors. It configured default readiness and liveness probes. Finally, it configured the ingress for the specifics of my Kubernetes cluster, in particular handling the ever troublesome TLS configuration. When necessary, default choices made by SolSA can of course be selectively overridden.
Conclusions
The SolSA library makes it possible to specify the architecture of cloud applications as well as reusable architectural patterns as JavaScript or TypeScript programs. SolSA translates the code to YAML that can be deployed with plain kubectl. SolSA works offline. There is nothing to install on your cluster.
SolSA has one goal and focuses on doing this one thing well:
- SolSA supports nothing but Kubernetes resources because 1) Kubernetes is cloud agnostic and vendor agnostic, and 2) we believe that, soon enough, thanks to operators, Kubernetes is going to manage all your resources.
- SolSA is not about reinventing applications, projects, microservices, software stacks, life-cycle management, CI/CD pipelines, GitOps, etc. because, frankly, there are plenty of people and tools doing that already.
SolSA is an open-source project with an Apache 2.0 license. We welcome contributions. Stay tuned for more!
Links
- NPM package: https://www.npmjs.com/package/solsa
- GitHub repository: https://github.com/IBM/solsa
- Examples and tutorials: https://github.com/IBM/solsa-examples
