Dave Bartoletti, an analyst with IT consultancy Forrester, said it’s clear that Kubernetes has won at the orchestration layer. “There’s too much mindshare around it,” he said in a phone interview with The Register. “There are too many developers who just want this.”
Pretty much everyone has the sentiment that kubernetes has won.
More details from Joseph Tsidulko at CRN:
While some components of Enterprise Edition previously could be made to work with Kubernetes, the crucial control plane for managing the lifecycle of containerized applications was incompatible. Docker, however, had participated in the Kubernetes project, and always believed the technologies were complementary, Chanana said.
Docker is now focused on building out the components needed to make Kubernetes an enterprise-grade solution, just as it did with Swarm, he said, including security, high availability, and ease of use through its existing tools and control plane. Those are capabilities Docker uniquely can deliver to ease a lot of the struggles customers face in taking advantage of Kubernetes’ advanced container-scheduling capabilities.
Source: Kubernetes has won. Docker Enterprise Edition to support rival container-wrangling tech
It happens to be the case that CF — because it’s an app platform and wants to let the user focus on their code — provides a way to convert code in to containers inside the platform without having to start messing around with Dockerfiles and the like. And this functionality even does some cool things for you like keeping your container OS automatically patched so you don’t have to build CI pipelines to monitor your base images and rebuild stuff.
That’s why I love Cloud Foundry’s Application Runtime. Of course, because of these constraints — the constraints that are why I love it — the App Runtime can’t possibly work for complex stateful services: the whole point is for it not to. And that’s why it’s fantastic that there’s now a Container Runtime (which I wish we’d called a Stateful Services Runtime because that’s how I think of it).
Source: CF vs Kube: Is the difference who creates the container?
There’s a new survey out from the Cloud Foundry Foundation, looking at the users of Cloud Foundry. Here’s some highlights and notes:
- Another ClearPath joint, n=735.
- It’s important to keep in mind that this is covers all distress of Cloud Foundry, including open source (no vendor involved).
- “The percentage of user respondents who require over three months
per app drops from 51 percent to 18 percent after deploying Cloud Foundry Application Runtime”
- “…while the percentage of user respondents who require less than a week climbs from 16 percent to 46 percent.”
- “Nearly half (49 percent) of Cloud Foundry Application Runtime users are large enterprises ($1+ billion annual revenue).”
- This chart is hard to read, but it shows a reduction in time to deploy across various time periods:
- Uptake is early, but there are definitely mature users: “A plurality of Cloud Foundry Application Runtime users (61 percent) describe their deployments as somewhere in the early stages—trial, PoC, evaluation, or a partial integration into specific business units. Meanwhile, 39 percent have deployed Cloud Foundry Application Runtime more broadly across their company, from total integration in specific business groups to company-wide deployment.”
- “Comcast, for example has more than 1500 developers using Cloud Foundry Application Runtime daily. Home Depot reports more than 2500 developers.”
- “Comcast has seen between 50 percent and 75 percent improvement in productivity.”
- “Half of Cloud Foundry Application Runtime users are currently using containers, such as Docker or rkt, with another 35 percent evaluating or deploying containers.”
- Container management – there’s a wide variety of tools that people use for container orchestration, including DIY (14%). There’s a lot of interest in having CF do it: “Nearly three-quarters (71 percent) of Cloud Foundry Application Runtime users currently using or evaluating containers are interested in adding container orchestration and management to their Cloud Foundry Application Runtime environment.” Hence, validating the Cloud Foundry Container Runtime.
- Of course, the surveyed are already CF users, so they’re biased/driven by what they know.
- Almost half of respondents say that getting started with CF. But people end up liking it: “An overwhelming majority of users (83 percent) would recommend Cloud Foundry Application Runtime to a colleague, including 60 percent who would do so strongly.”
- “As more companies roll out Cloud Foundry Application Runtime more broadly, the footprint continues to grow. Currently, 46 percent of users have more than 10 apps deployed on Cloud Foundry Application Runtime, including 18 percent with over 100 (and eight percent with over 500).” 4% have over 1,000 apps.
- CF’s uses: “The primary use is for microservices (54 percent), followed by websites (38 percent), internal business applications (31 percent), Software-as-a-Service (SaaS) (27 percent) and legacy software (eight percent).”
- Validating multi-cloud: “60 percent say this is very important, and another 30 percent describe it as somewhat important.” Meanwhile, 53% are using more than one type of IaaS.
I have an extra piece in The Register this month. I was asked to frame the history of software product theory between the Cluetrain, Andrew Clay Shafer’s agile infrastructure talk, DevOps, and the “we’re a software company now” trope.
Try to go beyond hand waving and opinions and find out what really is happening. A good way to start is to ask people to picture what their scenario would look like if everything was perfect. This puts them into a positive frame and helps focus on great outcomes. Once you’re sure you’re working on an improvement opportunity that’s worth your time, try small time-bound experiments that you actually follow through on. Use what you learn to come up with the next step. I’ve found that the combination of being bold with the vision but taking small steps to get there is a good combination.
Source: The Spotify Model is No “Agile Nirvana”
You probably still want to know who actually built a given container and what’s running in it.
Source: Google, IBM and others launch an open source API for keeping tabs on software supply chains
From an interview with Jeffrey Hammond and Marc Cecere on developer skills gaps. Here, the trend to training with people in person and then (slowly) going back “home”:
[Hammond:] One of the things I think you see is it– so many companies have used the words, partnering model, for years, and it’s been more or less lip service. But you do see a little bit more of a partnering and more highly tailored model. As an example, if you look at some of the projects that we see companies like a Pivotal or an IBM running these days, they may actually start in a garage that is near the organization so in San Francisco, or in London, or in New York City, but they start off-site. And the client’s developers, the client’s business personnel, go to those rooms, those war rooms if you will, and start work. Now, over time, some of that work may migrate offshore, or migrate back to the client. In the case of Pivotal, they’ll run multiple teams through their centers. Allstate is a really good example where they have I think over 100 developers and have kind of been through that process now, and they’ve drained their local talent pool. But it’s much less a, “This is the work we need to do and here’s the requirements and here’s the scope and let’s put this out to bid.” It’s much more a business transformation or a re-engineering type of project that is very high-touch. And I don’t see companies being able to do that if they’re not at least down the street from their clients and from their development shops. So I think it changes the nature of the types of engagement. I think it’s one of the reasons that you’ve seen so many of the large systems integrators buying agency talent as quickly as they can, because when you look at the sort of design experience techniques that are used, journey mapping, ethnography, those sorts of things, at least right now they still tend to be very custom – almost a manual process. You see sticky notes up on walls. You see war rooms. You see an environment that is kind of hard to capture from a remote, tool-based sort of delivery model.
Source: The Battle For Talent, Forrester
I assume this is across distros, and including use of just the ope source stack,
Source: Cloud Foundry adds native Kubernetes support for running containers, TechCrunch
On overview of how Bloomberg is looking at the likes of Pivotal Container Services:
“Many Kubernetes distributions are good on day one, when they’re first deployed,” said Andrey Rybka, technical architect in the office of the CTO at Bloomberg, the global finance, media and tech company based in New York. “But what happens on day two, when something fails? Kubernetes doesn’t [automatically] address things like failures at the physical node level.”
The roadmap for Cloud Foundry Container Runtime includes support for stateful applications based on the StatefulSets feature that became available with Kubernetes 1.7 in June. The foundation also plans to integrate the Istio project, founded by IBM, Google and Lyft in May, which helps to manage network communications between microservices
Also, see coverage of the general announcement in TechCrunch, the related press release, and our discussion in this week’s podcast.
Source: Cloud Foundry Container Runtime eases Kubernetes ops