Many of the services that we write at Plex rely on REST (or REST-like) APIs. While REST APIs make sense for many of these services, it does not make sense for all of them. For some domains, such as EDI, that require many endpoints, performance, and maintenance concerns start to become a problem. Every API call is a round-trip from the client to the server, impacting the overall performance of the initial request.
At Plex, all container images in our environments are sourced from our internal container registries. While this gives us greater control over which images can and cannot be used in our environments, it poses a bigger problem. How can we leverage container images that are managed in the public cloud? A common solution to this problem is to sync the public container image to your organization’s private registry by pulling down the image and then pushing it to your internal registry.
The feedback loop when deploying to Kubernetes can be quite slow. Not only does the YAML need to be syntactically correct, but we need to ask ourselves: Is the API version of our resource definition compatible with the version of Kubernetes that it is being deployed to? Kubernetes is constantly evolving, and over time, deprecates older APIs in favor of newer ones. A deployment definition may successfully apply on one version of Kubernetes, but not another.
At Plex, our initial adoption of Terraform was relatively painless. There weren’t many teams writing infrastructure as code, and most of the changes that were being deployed through Terraform were new pieces of infrastructure that didn’t have any dependencies. As the number of teams using Terraform and managing their own infrastructure grew, it became apparent that we needed to start putting some processes in place for a few reasons. Collaboration was difficult In order for an engineer to verify their Terraform changes, they needed to be able to run terraform plan against live infrastructure.