Virtual Services In Gloo

Virtual Services in Gloo

As the picture becomes clearer as to what to point at.  There are many options in a complete system.  The problems involved are have solutions in different forms.  Take routing for example, Istio has the concept of a Virtual Service as does Gloo.  The Gloo variant can route to many different implementations for the final compute.  

Earlier posts have been focusing on Kubernetes svc Route Destinations, but there is also the possibility of linking into the server-less world.  There are pretty strong arguments from Google as to why to standardize on Kubernetes engines for your workload, data locality being one.  Nevertheless, server-less cannot be ignored.  In this context Gloo is the clear winner: you don't have to choose.  You can have both.  

So routing comes in two forms.  Istio and Gloo : both are using Envoy under the covers.

Another concept that has several layers is that of how to aggregate services so that you can have not one but many in the aggregate.

How do you create a set of services "A" that has many complex dependencies and then take that set and wrap it in another set?  Basically, how do you do replication?  That could be done by having some kind of controller object.  It could live inside Kubernetes and be in charge of replicating templates of not implementation A, but Type A. 

It would seem that by using Gloo Matchers, new self contained islands of compute could be created, the islands being implementations of Type A.   A kubernetes Operator would process the Resource and Routing DSL's.  The Operator would be in charge of creating duplicates of compute resources and creating routes to call them.

There is a pattern to both Resource and Routing configuration.  The patterns should be expressed in declarative formats and the system should process  this configuration to bootstrap itself.  Kind of like Kubernetes config files but one level up and in Go as the engine with Yaml as expression language for the DSLs.

By coding dynamically and declaratively, you open the to door for further interaction from other intelligent Operators.  CRDS would be the interface inside of Kubernetes,  using the Kubernetes infrastructure for work queues and distributed tasks.  ETCD could contain state and well know conflict resolution mechanisms could ensure the engine maintains its state.  I think the Operator could use a combination of CRD for runtime state and Yaml DSL which could abstract out the construction of resources and routes.   

Now you can boot up entire systems by expressing the configuration for CRDs in Yaml Templates.  CRDs are runtime - YAML provides expressive syntax that can be processed by an engine to setup the initial CRDs.

This is not Dr McCoy's replicator mind you; we are transcending the physical here.  We are not merely replicating desserts, these replicas are working entities in a system of systems.  Systems talk to systems.  Systems participate in communities.  

Update 9_18_2020:

Realizing that if you could create a "unit of work" inside a pod.  That unit of work being a complete component in "shared nothing" system; meaning it could perform operations on its own.  Then.. there would be a special case of this "complex set of dependencies" where data locality could exist in each "shared nothing" island.

In this type of setup - a Stateless set would fit in very nicely.  Each island would be pod and each pod would be unique. 

There was that advanced statefulset with super fast container switching that might also apply here:

https://openkruise.io/en-us/docs/advanced_statefulset.html

It appears K8's itself supports binding specific services to specific pods

https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/#pod-name-label

Pod Name Label

When the StatefulSet Controller creates a Pod, it adds a label, statefulset.kubernetes.io/pod-name, that is set to the name of the Pod. This label allows you to attach a Service to a specific Pod in the StatefulSet