[cncf-toc] New version of Cloud Native Landscape

Quinton Hoole quinton.hoole at huawei.com
Thu Sep 14 02:21:13 UTC 2017


Would it make sense to also highlight “CNCF Member” projects, distinct from “CNCF Project”s?  The former much less prominently than the latter of course.

For example:

Oracle Database
Amazon Kinesis
Etc.

Q

Quinton Hoole
Technical Vice President
[cid:image001.png at 01D26682.FC05B5E0]
America Research Center
2330 Central Expressway, Santa Clara, CA 95050
Tel: 408-330-4721   Cell: 408-320-8917   Office # E2-9
Email: quinton.hoole at huawei.com<mailto:quinton.hoole at huawei.com>   ID#Q00403160

From: <cncf-toc-bounces at lists.cncf.io<mailto:cncf-toc-bounces at lists.cncf.io>> on behalf of Brian Grant via cncf-toc <cncf-toc at lists.cncf.io<mailto:cncf-toc at lists.cncf.io>>
Reply-To: Brian Grant <briangrant at google.com<mailto:briangrant at google.com>>
Date: Wednesday, September 13, 2017 at 18:21
To: Dan Kohn <dan at linuxfoundation.org<mailto:dan at linuxfoundation.org>>
Cc: Alexis Richardson via cncf-toc <cncf-toc at lists.cncf.io<mailto:cncf-toc at lists.cncf.io>>
Subject: Re: [cncf-toc] New version of Cloud Native Landscape



On Wed, Sep 13, 2017 at 5:37 PM, Dan Kohn <dan at linuxfoundation.org<mailto:dan at linuxfoundation.org>> wrote:
Coming back to this:

Please move Openstack, VMWare, and the other private cloud platforms back to the bottom. Bare metal should be side by side with public clouds, not in the provisioning layer.

In the next version, we'll rename Public cloud to cloud and put the bare metal category next to the public cloud one.

CI/CD definitely needs to be moved back up to the top.

That's done on 0.9.7, along with identifying Jaeger and Envoy as CNCF Projects.

https://raw.githubusercontent.com/cncf/landscape/master/landscape/CloudNativeLandscape_v0.9.7.jpg

"CI/CD Security" is incorrect/confusing. Image Security? And Vault isn't really in the same category as the others. That would be Key Management or Identity.

That category is changed to Secure Images. Where would you put a Key Management category? What else would go there?


https://en.wikipedia.org/wiki/Key_management

https://square.github.io/keywhiz/
https://lyft.github.io/confidant/
https://medium.com/@Pinterest_Engineering/open-sourcing-knox-a-secret-key-management-service-3ec3a47f5bb
https://www.openstack.org/videos/hong-kong-2013/barbican-1-0-open-source-key-management-for-openstack

But I'm not very familiar with any of those. Most clouds offer them, too.

Hashi's comparisons:
https://www.vaultproject.io/intro/vs/index.html

I'll think more about the layering, but I don't think provisioning is egregiously wrong, as it's a service commonly offered by clouds, configuration management tools, orchestration systems, and so on, which applications usually need in order to be able to authenticate with any other services.


Though not a recent change, it would probably make sense to move Registry Services down to the provisioning layer.

OK.

Nit: cri-o is a Kubernetes project, so it's owned by CNCF. Not sure how you want to indicate that.

I think it might make sense to list as a CNCF project when it exits incubation. Or we could call it a CNCF sub-project, or something like that.

No CNCF projects have graduated incubation yet :-)




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cncf.io/pipermail/cncf-toc/attachments/20170914/1ca4d1a2/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001[8].png
Type: image/png
Size: 5049 bytes
Desc: image001[8].png
URL: <http://lists.cncf.io/pipermail/cncf-toc/attachments/20170914/1ca4d1a2/attachment-0001.png>


More information about the cncf-toc mailing list