Cross Cutting Concerns in a Kubernetes World

Devlab is the Kubernetes based platform my team has been working 6+ months on and we are onboarding our first team’s application. I am excited about the opportunities Kubernetes offers because of its flexibility. Devlab can please a broad set of stakeholders with conflicting needs like security and product development. That is not the case of old.lab our Windows Virtual Machine platform which is painful and costly to make adjustments to.

Backlog and Roadmap Direction

Team Topologies backlog future This is my current understanding of how my platform team might evolve. I borrowed the image from this concise cheat sheet about Team Topologies.

My team is a mix of software developers and operations engineers crafting a white-glove experience for .NET developers. Over time I am expecting the team to grow to focus on different characteristics of the platform and split as the demand and cognitive load grows.

Kubernetes reduces or avoids the consequences of poor architecture decisions via easier migrations. In older platforms the stakes are high and any architectural mistake becomes costly over the years. I expect, due to Kubernetes flexibility, my team will experiment with less risk. It is still early and I am not sure what architecturally significant decisions will cause me to regret the direction of this product.

My biggest fear is solving a problem in the wrong cross-cutting concern solution. I created a mind map below of the overlapping abilities of microservice chassis, service mesh, and API gateway.

Cross-Cutting Concerns

API Gateway, Service Mesh, Microservice Chassis overlap

As part of the white-glove self-service portal experience, the devlab team offers a microservice chassis. .NET core assists with some features like externalized configuration. We are expecting adoption to be slow thus if 20 applications over 6 to 12 months need to be reworked or migrated in the future it isn’t terrible. It could be possible these applications never require distributed tracing in the future or logs do a good enough job. This article also helped me understand the additional overlap between service mesh and API Gateway. I fear that a microservice chassis is simple to generate but in my experience difficult to update. In six months will I say I prefer steeltoe or dapr? Network-based solutions tend to be the simplest and easiest solution for keeping things up to date. I am optimistic about automated dependency upgrades via a solution like dependabot.

My gut tells me the riskiest architectural decisions will come from where we decide to solve a problem. Either the microservice chassis, service mesh, API Gateway, and whether they are the right fit long term. One of those upcoming decisions will be the design around the security of our applications running in Kubernetes.

Namespaces and secure access

Early on the security architect pointed out that our current namespace per project strategy might be too granular. It remains to be seen whether this is problematic or not. There are simpler solutions than creating rules for every application’s communication.

Namespace communication As you can see this becomes a bit of a mess if we use network security policies to allow any communication.

Namespace grouping We could use namespaces with more applications running allowed to talk to each other. Then enforcing authentication and authorization when communicating across namespaces.

Service Communication

Another alternative is to deny all communication by default. Then only allowing services using some kind of “scoped” access via a service mesh or API gateway.

Accessing Value

If you are building an internal developer platform I recommend viewing this webinar or slides from Giant Swarm. Platform To Value Some great tips that resonated for me from this webinar. One of those tips is focusing on the training and enablement of teams. We are now focused on working with an internal technical trainer to help communicate the shift to cloud-native practices for our teams. I look forward to sharing more with you all in six to twelve months as this platform becomes generally available.