Hi all! Hope you are doing fine today.- For those having a multi-cloud/Hybrid arch. When designing your platform, how do you deal with the different types of container strategy and responsibility limits base on: • on Prem standar container (Managed) • On prem DIY container service (responsibility limited to bare metal VM) I guess my question is: How flexible you are in terms of accepting non standard container services from stakeholders, and what is the challenges base on that for your own platform strategy?

Hi @Roberto Carrera The way i design this is with Zero trust in mind. The first thing you need to solve is routing and networking between these environments. There are chances you may face overlapping IP spaces between the environment. And the other challenge depending on your kubernetes deployment, are your podIPs routable. Generally speaking, outside of public clouds (GCP, azure, AWS) pod IPs are not routable. Public clouds make the pod ip routable by default unless you specify another CNI. You then open yourself to a potential security risk so you have to figure out how to manage the access from and to (containers) apps/services etc… I would also isolate the different container strategies you have into different fault/security domains. It also depends on what services these on prem environment need to access to. The DIY environment i assume they will be short lived environments? There are a a few open questions here. One way to solve it is with a, multi cloud/multi runtime, service mesh. With a service mesh you’ll be able to specify access policies, authz rules etc…, between applications, domains, environments etc…. A service mesh can span multiple clouds/environments/runtimes. You can also combine it with api-gateways possibly, it all depends on your architecture. Just my 2 cents 🙂

Thanks for the reply @Jona Apelbaum, awesome inputs in your response. 🙏 The DYI are environments in which stakeholders take full responsibilities on the clusters we build, but do not operate. So they are mostly isolated, shipped and finally delivered to them as non standard, but appliance service. I will check more literature about the service mesh arch, we have ambitions for multi-cloud, but yet dealing with legacy and modernization of Data Centers, etc. Log way to go, but transformation has started, including an internal Developer Planform initiative, whish me luck! 😄

@Roberto Carrera, you are most welcome! Adopting a multi cloud strategy can be challenging indeed. One of the challenges being shield that complexity away from the developers. Changes are slow, and should also be sometimes as it can affect developer productivity. An IDP (in its broader context) + service mesh, in my opinion is the way to go as it will allow you to get there faster and automate the aspects that Developers dont want, or you dont want them, to deal with. Like the complexity of the network, security, etc…. Good luck! 🙂