“Write Things Once” Principle in SolSA
SolSA makes it possible to use a scripting language — Javascript or Typescript for now — to the define the software architecture of cloud-native solutions. Compared to configuring Kubernetes resources using YAML, one immediate benefit is a dramatic reduction in code size. In particular, SolSA strives to enable the developer to write things once. Today, we will review examples of this guiding principle.
Ingress
Previously, we have shown how to deploy a microservice using SolSA.
In order to permit external access to the ContainerizedService (lines 4 to 8), we included an Ingress (line 9). The construction of this ingress illustrates a typical SolSA idiom. Rather than defining the ingress from scratch using the form new Ingress(...), we derive it from another resource using the form new resource.Ingress(...). This idiom makes it possible to reuse part of an existing resource configuration to configure a new resource, thus avoiding repetitions. In this example, the ingress configuration is entirely derived from the containerized service configuration, hence the constructor invocation requires no additional argument.
The generated YAML for this ingress for my Kubernetes cluster is:
The ingress name (line 4), backend service name (line 11), and port (line 12) have been obtained from the containerized service. If necessary, all of these configuration elements can be selectively overridden by passing explicit values into the constructor invocation.
Event Streams Topic
The write things once principle also applies to custom resources managed by Kubernetes operators. In this example, we derive a Topic from an EventStreams instance:
This example assumes the IBM Cloud Operator and the Event Streams Topic operators have been deployed to the targeted Kubernetes cluster. It configures both a managed Event Streams instance on the IBM cloud and a topic on this instance.
The generated YAML for the Topic resource is:
In this example, the YAML itself is not bad as the Event Streams Topic operator makes it possible to simply refer to the Event Streams resource by name.
Knative Kafka Event Source
Not all Kubernetes operators however permit such concise YAML. Next, we derive a Knative Event Source from the topic. The SolSA code is very much the same:
Line 6, we add a source component to the resource bundle by invoking new bundle.topic.Source(...).
The generated YAML for the Knative Event Source is much more involved:
This YAML has to include configuration information from both the Event Streams instance and topic. The configuration schema is non-trivial.
- The name of the Event Streams instance is required in several places (lines 19, 28, 32).
- Part of the required configuration values — the
bootstrapServers(lines 12 to 20) — has to be obtained from the live deployment of the Event Streams instance as it cannot be predicted, requiring the use of the Composable operator — a topic for another blog post. - While the Event Streams Topic operator can simply retrieve the credentials for the Event Streams instance when given just the instance name, the Knative Event Source operator requires inlining the credentials structure into the resource YAML (lines 22 to 34: user, password, authentication protocol, encryption protocol).
Thankfully, SolSA entirely shields the developer from all these intricacies.
Summary
SolSA makes it possible to write things once by automatically deriving configuration elements for new resources from configuration elements of existing resources. Moreover and perhaps more importantly, SolSA supports a uniform idiom — uniform syntax — to derive new resources from existing resources even if this uniformity translates to very different implementation mechanisms depending the specific resources considered. As our last example shows, these mechanisms can be very complex in practice.
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
