Live at OSCON — Cloud-Native, Before and After Containers – InApps is an article under the topic Software Development Many of you are most interested in today !! Today, let’s InApps.net learn Live at OSCON — Cloud-Native, Before and After Containers – InApps in today’s post !
Read more about Live at OSCON — Cloud-Native, Before and After Containers – InApps at Wikipedia
You can find content about Live at OSCON — Cloud-Native, Before and After Containers – InApps from the Wikipedia website
A lot of great thinkers and makers are all in one place at a conference such as OSCON. For this edition of InApps Analysts podcast, Alex Williams gathered several such people at one time, for what he suspects is the largest group he’s assembled yet for a podcast, and in this case bigger is definitely better.
- Sam Charrington, principal analyst with InApps.
- Casey West, principal technologist for Cloud Foundry at Pivotal.
- Jesse Proudman, CTO at Blue Box, an IBM company.
- Abby Kearns, technical marketing for Pivotal Cloud Foundry.
- Sam Ramji, CEO, Cloud Foundry Foundation.
- Klint Finley, journalist for Wired, InApps and Mindful Cyborgs.
For more episodes — with smaller panels, but just as good — check out the podcast section of InApps.
Listen to all TNS podcasts on Simplecast.
This podcast is also available on YouTube.
To start the conversation, Alex acknowledges the various open source foundations that have materialized of late, at least since the OpenStack Foundation was founded in 2012. The Cloud Foundry Foundation is six months old. The Node.js Foundation was announced earlier this year. The Open Container Initiative (OCI) is a little over one month old. And now, the Cloud Native Computing Foundation (CNCF), to which Google is turning over its container management program, Kubernetes, just launched at OSCON.
“I think it’s a consequence of the fact that open source has won,” says Sam Ramji, “and part of winning means that it’s become mainstream, and it’s the core business.”
“Once you have the economic incentive,” he continues, “then everybody’s behavior gets a little more fearful, because it starts looking not like open source used to look.”
Regarding the news from Google, Abby says that having investment from this type of company is exciting, and it speaks to the need to rally around a common theme, and presents an opportunity to leverage such participation into bigger and better technologies.
Klint recalls that, not too long ago, the single owner versus foundation question was actively debated. “That’s almost been completely obliterated in the last few months,” says Klint. “Rails is one of the only major open source projects I can think of that’s a one-company thing now.”
Jesse observes that the recently-emerged foundations are all in the service of “foundational technologies” (as contrasted with supporting technologies). He adds, “The goal is to drive consistency from provider to provider, or software release to software release.”
Sam Charrington sees an interesting twist, in that Google’s CNCF announcement tends to marginalize the just-established OCI. “By raising the level of abstraction around the container-native applications, there’s a lot less focus on the importance of an individual container runtime.”
Is a battle of the foundations imminent? Sam Ramji reminds us,
“The CNCF, the OCI, and Cloud Foundry Foundation are all under the Linux Foundation. That means that we should be friends. We should have common governance. The lines should be fairly soft. That should benefit all of us.”
This leads to a discussion of Garden, a platform-neutral API for containerization, and Casey observes that as containerization has become widespread and less novel, next-level interest has shifted to scheduling, orchestration, and management at a larger scale. “There are a lot of technologies that are starting to come into their own,” says Casey. “I think that’s where Kubernetes is at, and that’s exciting.”
Regarding the distinctions between services running on Kubernetes, such as Red Hat’s OpenShift, and services running through Cloud Foundry, such as IBM’s Bluemix and Pivotal Cloud Foundry, Jesse says, “Ultimately it’s about service catalog, and deliverability of the applications.”
“Kubernetes gives you a blank canvas on which to build everything you want to build, all on your own, and that can be incredibly powerful for a lot of organizations, and is a great tool for doing greenfield design and implementation of your application and all its associated services,” says Jesse. “It also can be time-consuming.”
“The flip side is,” he continues, “Cloud Foundry, and particularly Bluemix, gives you a pre-defined Cloud Foundry runtime and a service catalog that allows you to ignore all those other pieces and just get going today, with the application that you have.”
“A better analogy,” says Sam Ramji, “is between Kubernetes and Diego, because they’re both container schedulers,” noting that Cloud Foundry is more of a stack, with many components outside of what exists in Kubernetes.
Alex turns the discussion toward the meaning of the term “cloud native.” Klint says that in this new context the term sounds suspiciously like branding, and that it confuses things. Sam Charrington agrees that it’s confusing, and says, “I feel that in naming the foundation that way, and in branding it that way, there’s an implicit statement that container technologies are the only ways to achieve cloud nativity, and it’s clearly not the case.”
“We’ve been talking about cloud native for years,” he continues, “and it has to do with principles around statelessness, and scale-out versus scale-up — a lot of the things that come out in the twelve-factor conversation.”
On the other hand, Jesse saw a broader scope in the press release; he says that the CNCF is more than just about containers. “It’s about how we build a consistent framework for using different pieces of modern technology in multiple environments, and containers are a portion of that, but all of those elements support this notion of cloud-native applications,” Jesse says.
“You’re going to build a platform, or you’re going to buy a platform,” says Casey. “At Pivotal, we have a lot of experience building, deploying, and running on top of platform after platform.”
And this, Pivotal believes, is cloud native, says Casey.
“These twelve factor apps — the contract that you’re going to adhere to in order to have the possibility of portable and horizontally scalable applications — and then when you put those apps into containers and you orchestrate them — that’s a reasonably decent method for repeatability in terms of deployment, fast spin-up, fast spin-down.”
“Those are powerful tools, and Kubernetes is a good tool for that,” he says. But, he adds, “You need to put a lot of other things on top of it, and that’s where it gets messy, because you are going to need to aggregate your logs and be able to analyze them effectively. You are going to have to have an elastic load balancer, and a decent routing mechanism for incoming requests on your services.”
“The concept of cloud native is the composition of all of these pieces, but you need to have them all,” he says. “That’s one thing that we’re coming to the realization of.”
And this all comes before the break, which just goes to show what a big panel can accomplish.
In the second part of the program, the group explores the effect of the ongoing transformation on infrastructure, server architecture, and IT itself — how these new, complex patterns are more about the process than the machines.
IBM, Pivotal and Red Hat are sponsors of InApps.
Featured Image via The British Library Flickr page (where 1,000,000 images have been recently released into the public domain); Image taken from page 183 of ‘Routledge’s Book of Travel and Adventure … With … illustrations,’ London, 1885, remixed by Luke Lefler.
Let’s create the next big thing together!
Coming together is a beginning. Keeping together is progress. Working together is success.