- Software Development
- KubeCon + CloudNativeCon EU Confronts the Great App-Delivery Challenge – InApps Technology 2022
KubeCon + CloudNativeCon EU Confronts the Great App-Delivery Challenge – InApps Technology is an article under the topic Software Development Many of you are most interested in today !! Today, let’s InApps.net learn KubeCon + CloudNativeCon EU Confronts the Great App-Delivery Challenge – InApps Technology in today’s post !
Read more about KubeCon + CloudNativeCon EU Confronts the Great App-Delivery Challenge – InApps Technology at Wikipedia
You can find content about KubeCon + CloudNativeCon EU Confronts the Great App-Delivery Challenge – InApps Technology from the Wikipedia website
Today, most Sandbox projects of the Cloud Native Computing Foundation fall under the broad categories of runtime and application delivery, reflecting how DevOps teams continue to seek ways to improve the developer and operations experience when building and deploying applications on cloud native environments, especially for those built on Kubernetes. DevOps teams are often receptive to trying new solutions — such as those still in the earlier stages of development as CNCF Sandbox projects — as they try to find ways to reduce the often enormous complexity to help alleviate the pressures they face associated with deploying applications and pushing code into production at an ever-rapid pace.
This was one of the main takeaways during KubeCon + CloudNativeCon EU keynotes and talks that took place Wednesday.
Application Delivery category represents the most @CloudNativeFdn’s Sandbox projects, by “bridging the gap between writing code and that code being packaged and delivered as an application that can be run in the cloud,” @lizrice. #kubeconEU+#CloudNativeCon #sponsored @thenewstack pic.twitter.com/aV05EJc0ke
— BC Gain (@bcamerongain) May 5, 2021
The largest share of the CNCF Sandbox projects falls under the application-delivery category, where APIs serving as the conduit for improved automation and less complexity for the development and deployment cycle. During her keynote, Liz Rice, chief open source officer for Isovalent and chair of the CNCF Technical Oversight Committee, defined how tools falling under the application-delivery category are used to “bridge the gap between a developer writing code at a keyboard and that code being packaged and delivered as an application that can be run in the cloud.”
In other words, most activity around CNCF Sandbox projects has been associated with improving the developer experience for cloud native production pipelines. The projects with the runtime tag are thus “where we’re seeing the most experimentation” to “make it easier for developers and operators to build and run cloud native applications,” with 11 projects of these types of projects in the Sandbox category, Rice said.
New #Kubernetes runtimes being considered by the @CloudNativeFdn Runtime SIG: Sysbox (Containers as VMs), Krustlet (WASM on K8s), SSVM (WebAssembly for edge, blockchain, AI). Trow (container image registry), Rootless containers — @raravena80, #KubeConEU2021 @KubeCon_ #sponsored pic.twitter.com/MCP4jb5CO4
— Joab Jackson (@Joab_Jackson) May 5, 2021
GitOps with More Kubernetes Reach
The quest to improve CI/CD inevitably involves finding the best git processes — or GitOps — given that git solutions such as GitHub and GitLab are used as platforms that extend beyond serving as code repositories. To that end, Weaveworks’ Flux has widened its reach as a platform to help maintain the state of Kubernetes clusters that match their configuration in Git. Flux’s frameworks capabilities were also recently introduced ahead of Flux’s graduation from the Sandbox category to become a CNCF Incubating project a few days ago.
Stefan Prodan, a developer experience engineer for Weaveworks, described during his keynote “CNCF Project Update: Flux” how the framework’s capability helps to “to bridge the gap between source control access and Kubernetes access” in a way that allows for the verification of users’ identities who create a commit.”
“You can verify that that person has the right access to modify something on your production cluster, and then the toolkit can run those changes and operations by impersonating Kubernetes account,” he said. He also said Kubernetes cluster access remains restricted, depending on how the cluster-admin configures access control.
A Kubernetes Management Plane ‘What If’
One of the challenging areas for CI/CD, as well as DevOps teams in general, is how to develop, deploy and manage applications often spread across different cloud environments. Service mesh and control planes will, of course, continue to play a key role. But just how simple — or boring, as many speculate — could Kubernetes management become?
In his talk “Kubernetes as the Control Plane for the Hybrid Cloud,” Clayton Coleman, architect for Kubernetes and OpenShift for Red Hat, and a Kubernetes committer, described a control plane without “thousands of services,” but instead, having “1,000 little clusters, each running one service.” “What if we reverse direction?” Coleman said, “What if we could let Kubernetes — the API — take the lead?”
@RedHat‘s Clayton Coleman, #Kubernetes committer, described: “Imagine having instead of one cluster with 1000s of services, having 1000 little clusters, each running one service. #kubeconEU+#CloudNativeCon #sponsored @thenewstack pic.twitter.com/0AfsrhWtxL
— BC Gain (@bcamerongain) May 5, 2021
Coleman described a prototype configuration of what Kubernetes could eventually “look like without pods” and what the tools would look like “in our pod-less toolbox.” These tools would offer namespaces to subdivide workloads, RBAC (Role-Based Access Control) for security, and secrets and config maps that could accept generic configurations.
“So what you’re seeing is a really simple prototype of how a cube-like control plane might behave: a Kubernetes API without pods containers or nodes, and all the extensibility client support and tooling needed to integrate declarative APIs describing a much more integrated world,” Coleman said. “How might we change our applications and the API” in order to bring that to life? Team A and Team B collaborate on a service without knowing about the implementation details of the other.”
@onepeloton‘s @JHaughwou @EnvoyProxy and other @servicemesh is on order for IoT, mobile and edge fitness apps to “pull all these technologies together.” #kubeconEU + #CloudNativeCon #keynotes #sponsored @thenewstack pic.twitter.com/mCZo6w34lr
— BC Gain (@bcamerongain) May 5, 2021
Putting the CNCF Pieces in Place
After implementing Kubernetes for the first time last year, Jim Haughwout, vice president of platform for the exercise solutions provider Peloton, described in his talk “How Cloud Native Tech Helped Peloton Ride to Exponential Growth” how Peloton’s fitness app’s operations, after starting from scratch last year, now run completely on Kubernetes.
The next step: implementation of a service proxy, such as Envoy. To do that, Haughwout described how his DevOps team is reviewing how “CNCF and others have solved problems” associated with service-discovery perimeter management, improving security and the management of communications between services “not just in the cloud or mobile, but all the way to the edge, and to our connected fitness devices.”
“This isn’t just a buzzword — I know this is getting to be a very popular term for today — this is central to our role of connected fitness and connecting our connected fitness devices to all of our technology. We’re probably going to find some really interesting Envoy cases and perhaps Envoy mobile cases in this,” Haughwout said. “I think the thing here is there are so many challenges between mobile, edge and cloud, between cloud native, mobile native and just amazing opportunities for us to challenge, using CNCF and other open source technologies.”
InApps Technology is a wholly owned subsidiary of Insight Partners, an investor in the following companies mentioned in this article: LaunchDarkly.
Let’s create the next big thing together!
Coming together is a beginning. Keeping together is progress. Working together is success.