The Rise of the Container Orchestrator SDKs
AppDynamics sponsored this post.
Take a journey back to the gilded age of software distributions 10 to 15 years ago. If you were building a distributed platform such as a portal or eCommerce site, it most likely would be written in Java — thanks, “write once, run anywhere” (WORA). The packaging for the binary distributions would be made up of one or several EARs (enterprise archives), WARs (web archives) and/or JARs (Java archives). There would be specific instructions for different application servers. From a product management standpoint, you would ship different web.xml files to take into account differences in application servers.
What a great time.
Fast forward to today. There is a litany of packing and distribution mechanisms to make your product adopted. Clients and end users want choice as to where and how to install your product. This requires product managers to make decisions not only about creating the raw binaries but also about including infrastructure-as-code, cloud provider-specific automation and container orchestrator formats. For increasingly complex distributed platforms, application infrastructure requirements such as quorum or session clustering can prove difficult to describe simply in these new distribution formats.
Do You Have a Docker?
When I worked as a solutions architect for several companies during the container boom, clients would often ask me if we had a Dockerized version of our products/platforms. Whenever I asked why, they would say they were following a company directive requiring their workloads to head to container formats, as the enterprise was adopting a container orchestration strategy. Their end goal? Container nirvana where middleware (or system) engineering teams would manage only the container orchestration.
Not So Fast
Rarely is a platform totally stateless by itself. A typical platform could have dozens of stateless and stateful services that need to be orchestrated. Certain pieces or applications will not containerize. Martin Fowler’s Strangler Pattern starts to become very real as systems evolve at different paces. With complex, distributed infrastructure such as messaging, there are specific tolerances and infrastructure requirements to manage.
Let’s say you’re dealing with a failure or in-place upgrade. A robust installation might not be easily configurable with a container orchestrator, for example, because the clustering mechanisms need specific metrics to react. The path of least resistance would be to apply to shoehorn the platform into an orchestrator. Could you containerize? Yes. Could you recover from a failure of a stateful workload? No, because the steps might involve a workflow such as a replay or retry that the orchestrator by itself cannot perform.
Marathon vs. Kubernetes: Is This Still Going On?
Looking at the container orchestrator landscape, two dominant platforms are Marathon and Kubernetes, the latter having become the 800-pound gorilla. For a majority of organizations going through their containerization journey, the initial hurdle is describing their applications in one of the two formats: a marathon.json or a kubernetes.yaml.
Each orchestrator has its pros and cons, of course. The feature gap between Marathon and Kubernetes always seems to bring about rapid change in the two communities. For the more complex distributed platforms, the run-of-the-mill Kubernetes YAML might not have enough granularity to describe the operational steps with a vanilla install/implementation of the orchestrator around initialization, for example.
Why Hello, SDK
Lurking previously in the shadows of the orchestrators are the Software Development Kits (SDKs), such as the Mesosphere DC/OS SDK. With the contribution from CoreOS with Operators for Kubernetes, RedHat/CoreOS has recently introduced the Operator Framework.
Now, instead of describing your application or platform with a deployment descriptor, you build your application or platform to the SDK. Imagine in Kubernetes extending the custom resource definition (CRD) and controller that would go along with the CRD — basically, writing a controller in GO to define what needs to be watched and how to react to changes in state.
One more decision for our fearless product manager to consider: Making the shift from redescribing the original packaging (e.g. including a Puppet or Chef script) to creating a new release/deployable built to one of the orchestrator SDKs.
By building to one of the orchestrator SDKs, the end consumers of the product can manage and scale with the implements of one of the orchestrator interfaces; Mesosphere CLI / KubeCTL. The complex wiring to cluster the product or a workflow to replay/retry is obfuscated by one of the orchestrator interfaces.
How Much Traction?
GitHub offers a good list of platforms that are building on Kubernetes operators. The list gets updated regularly. For the DC/OS SDK, it’s a little harder to tell what actually includes the SDK, because use of the SDK is not called out in the DC/OS Universe. The project has this structure.
Final Thoughts
Behind hybrid cloud with Mesosphere’s DC/OS and Kubernetes’s Federation, I believe the SDKs are second in importance and will usher in more complex workloads, ones that have strayed from being easy to describe with an orchestrator/resource manager. Potentially deploying an SDK could change your vanilla install of an orchestration framework, as customizations/internals need to be written to the orchestrator to support additional features. As of late June 2018, the DCOS SDK is in alpha and the operator framework SDK is in pre-alpha. Certainly, lots of change to come in these fast-moving projects at a fast-moving space.
AppDynamics is a sponsor of The New Stack.
Feature image via Pixabay.
