Cloud Native Platform Engineering Framework & IDP Insights
[Q&A]
A Technical Perspective: GitOps and Multi-Cluster Networking
Meet Dan Donahue, who recently wrote the ebook called What Happened to Platform Engineering?? Having done it for almost 25 years, working as a Platform Software Engineer, Dan is passionate about this topic. Currently, Dan is the Principal Solutions Architect at Nethopper.?
Let’s get started!?
Q1:? Dan, you often say “Let Devs dev and Ops op.” Explain what you mean by it.????????
Dan Donahue: ?Glad to elaborate on it!
Let me ask this rhetorical question as an example: What happens when you need to build and provision infrastructure?
I can tell you that it results in one of two scenarios:?
Put it simply, the result is either “Devs doing Ops work” or “Ops folks doing Devs work.” In both scenarios, nobody is happy, and the organization is not functioning well.
The best way to solve the infrastructure abstraction reality for cloud native architectures is an IDP, or Internal Developer Platform, which enables “Devs to dev and Ops to op.”?
Q2: So the path to success is an IDP.? What’s an IDP supposed to do??????
Dan Donahue: ?An IDP provides a framework the Ops team uses to create an operational cloud native ecosystem that serves all contexts for an organization’s applications.
A typical ecosystem has the following deployment contexts: Dev, QA, Staging, and Prod.
An IDP should be able to build infrastructure, deploy and observe the applications using existing CI/CD pipelines to achieve true Continuous Deployment for each of the contexts in a consistent manner.
Q3: I’ve heard you emphasize that GitOps and Multi-Cluster Networking are important for any platform engineering.? Why is that????
Dan Donahue: That’s a guidance for platform engineering teams responsible for building and maintaining an IDP.?
The foundation of any IDP needs to include GitOps, and Multi-Cluster Networking, which provides a consistent and secure way to connect clusters.??
Let’s unpack it.?
First, GitOps is required because it gives you a declarative way for instantiating both your infrastructure and applications. With GitOps, you now have a full audit-trail of who changed what and when.?
Also, you have a source of truth for both those applications. Nothing changes in your ecosystem unless it changes in Git.
For example, if you’re using a GitOps approach for IaC, and you build like an Amazon EKS cluster and someone with appropriate IAM rights were to log in my Amazon EKS console, and change something about that cluster, the Amazon EKS cluster would allow it, as it should.?
However, GitOps would detect it, and reververt that infrastructure to whatever is in Git, which is the source of truth. A GitOps approach is good from both an audit trail and a consistent way to do your applications and infrastructure.?
Second, Multi-Cluster Networking is absolutely required for any IDP.
Because you are going to manage an ecosystem of clusters, I can almost guarantee that you will do it in multiple contexts, like in Dev, QA, Staging, Prod.
So you need a consistent way to connect clusters and have a Kubernetes control plane over them.
Kubernetes was architected from a software perspective to abstract the networking from your apps.? But it did so in an intra-cluster way, meaning, if I have services on a cluster that need to talk with one another, they do that pretty seamlessly in Kubernetes on the same cluster.
However, because Kubernetes natively does not support inter-cluster communication, it becomes complex when you need a service in one cluster that needs to communicate with an endpoint in another cluster.
To do that, you now need to add a load balancer, or a node port, or an ingress–and you also have to create networks. Hence the need for multi-cluster networking for you to have that control plane capability. ? ?
At Nethopper , we built KAOPS to make it easier to operate any Kubernetes across any cloud or clusters. We provide a GitOps framework or approach, where we use a layer 7 overlay network on top of the physical network to create what we call an ‘app network.”
That is, we create a group of clusters, say Dev or? Prod, connected together at layer 7, so that GitOps operations can be done, and our users can deploy and monitor applications, as well as build the underlying infrastructure for that.
Our customers and partners, including Kubernetes managed service providers (MSPs) have an easy way to do multi-cluster and multi-cloud with KAOPS.?
[Quick Links]
For more information:
VP Strategic Solutions @Nethopper.io | Private AI for Enterprise
10 个月I love listening to Dan speak.