TAP 1.6 – Local Source Proxy

One of the best new features, if not the best new feature in TAP 1.6, is the introduction of a new component called Local Source Proxy (LSP). One of the main challenges we have seen with rolling out TAP, is that while TAP aims to provide an abstraction above kubernetes, making the infrastructure invisible to the developer, the amount of infra level config that is needed on the developers machine, just to get started was a nightmare. From installing Tanzu CLI from Tanzu network, to getting the right access to a kubernetes cluster and configuring the correct kubeconfig, and then above all of that, the user needed docker on their machine, as well as credentials to access the image registry of choice within the organization in order to do iterative development, as the OCI registry is used as a conduit for passing the source code form the developers IDE to the remote cluster. In TAP 1.6, a huge amount of this has been solved. I have another post in which i go into detail on the new Tanzu CLI, and in this post we will be talking about LSP which solves the docker issue. Now in TAP 1.6, my developers no longer need access to the image registry from their machines, and don’t need to have docker either! LSP is a new components which has been integrated into the entire inner loop tooling. With LSP, when a developer begins a new inner loop development by use of the Tanzu apps CLI, or from the IDE plugins, instead of the source code being uploaded to the image registry from their machine, a port forward is opened between the LSP service on the cluster and their machine which serves as a inline proxy for the apps plugin to push the code too, which in turn mushes it to the image reigstry, however as this happens from within the cluster, a single registry credential is needed to be configured for LSP itself, and no developer ever needs access to it! This new method, also works with ECR which is great, as the flow currently with ECR is even worse, sue to the fact that amazon do not allow for repo creation on push, and that meant that in nearly all cases, developers needed to pre-create repositories in ECR for every new microservice, making their lives much more entangled in the infrastructure then it ideally should be. The new LSP model, works really well, and after testing it for a few weeks, i can say that it truly is a game changer for the developer experience, especially when onboarding developers to TAP, as its one less thing they need to deal with. I was working with a customer on TAP recently where they have harbor configured with OIDC based authentication, which due to how Harbor works, requires their developers to login to the Harbor UI every few hours, and then login via the CLI again, just in order to do inner loop development. This new feature provided by LSP will greatly simplify the DevEx, and make the context switching and overall cognitive load much more reasonable for the average developer. Summary It is really great to see the improvements in this area, and i believe that these types of changes are what will truly help make the adoption of TAP a much smoother process, making developers truly happy, as well as giving operators the control and governance they need, without standing in the way of the developers.