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.
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.
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.
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.
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.
If you are building an internal developer platform I recommend viewing this webinar or slides from Giant Swarm. 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.