And it begins. The birth of a company with a direct conflict of interest in making Kubernetes so simple to use/administer that you don't need to pay another company for 'enterprise support'.
This happens quite frequently with open source infrastructure. Keep an eye on them to push back against improvements that directly conflict with their company's "enterprise sauce".
The overall stewards and interests behind Kubernetes have a greater interest in making it simple to use and administer.
It isn't quite there yet but things are improving on that front all the time and will be significantly better for newbies in a few more versions. In other words, it is getting there, don't worry about it.
True, but I've seen enough of it now that open source politics should almost be a field to major in. :)
It's never blatant, it's always calls for seemingly good things like extra pluggable points to make sure we don't favor particular solutions. Then it's making sure that any decision is brought to a huge vote by a giant committee that spends weeks arguing about if it's something they should even decide on, etc.
Ultimately there are ways to do immense damage to open source communities with small well placed "concerns" that seed doubt. Usually it's a mailing list post (or github issue) with some grand question like "Is X something Kubernetes should really be doing?" followed by bullet points outlining other unrelated issues that "we should be focusing on" and to "leave X up to other tools because the solutions are a matter of taste and therefore there is no right solution."
Note that this is just some people who helped start the project when they were at Google, and both of them have since left. Kubernetes is managed by the Cloud Native Computing Foundation, and a very large number of companies are involved in managing the project's direction with an open governance model. There are diverse enough interests already that there isn't really any risk of one company's interests driving the project off course in a way that's harmful for the larger Kubernetes community.
God, I don't think I've ever groaned audibly while reading a comment like this before on HN. It's totally correct and true and apt, but I hope it's wrong over the long term.
I'm hopeful k8 won't go the way of openstack because the problem domain is simpler and more well defined, but I'll be damned if I ever believe a "diverse" group of enterprises with shared interests can reliably produce good software.
Fool me once, shame on me. Fool me twice, shame on the standards committee.
I feel like openstack will end up being the subject of an interesting book that will explore all the ways it ended up screwing itself despite (or perhaps because of) corporate sponsorhip.
K8s has a significantly more solid base today than OpenStack did upon its public release by NASA. It was barely functional, and gained the ascendency by virtue of Eucalyptus somehow managing to be even worse.
OpenStack has begun to feel more of a vendor marketplace with each of them trying to see if you can adopt their flavor. It looks somewhat similar to the large number of the Linux distros that were popular about 10 years ago, except that these are much more opinionated and have serious vendor lock-in possibilities since it relates to enterprise. Kubernetes, on the other hand feels like a harmonious and homogeneous solution to a specific problem.
I don't know. I got the same feeling at Kubecon with all the booths and their big signs promising to "solve enterprise devops" and "virtualize your network providing seamless connectivity."
Kubernetes has exactly the same issue. The core of openstack compute doesn't have much fragmentation, but all of the flavors come about when you snap in different deployment technologies, different storage backends, different networking backends, etc. Kubernetes is not prescriptive for any of these things either, so it will end up in exactly the same place as openstack with its current trajectory.
[This is Craig -- CEO of this new venture, co-founder of K8s (with Joe and Brendan), and person who started CNCF (with Jim Zemlin, and a bunch of community wonks from big tech)]
It is a funny you say this. I spent a lot of time looking around the community at what existed before starting CNCF, and agonized over this. We needed to take K8s to foundation so that it wouldn't be a 'Google project'. Google was actually the best steward of the tech you could imagine, because the plan was always to make k8s ubiquitous and just win on quality of infrastructure but the community had no way to know that.
I looked at OpenStack hard, and like the energy and enthusiasm but really worried about (1) balkanization that was emerging with no 'true north' -- it just didn't have technical taste, (2) the tragedy of the commons -- most vendors were focused on their own interests and neglected the end users, (3) lack of coherence.
When designing CNCF I tried hard to work through this by creating a better foundation structure.
(1) the business board has very limited authority over projects, hopefully making sure that we avoid it being a pay-for-play affair.
(2) we made provisions for little companies to get top level seats based on community contributions (ditto)
(3) we created an empowered end user group that would have equal authority to any other affair to make sure real users interest are promoted
(4) we added a TOC (technical oversight committee) that was the most empowered group to establish true north that is community elected -- the idea is they need to champion the projects and establish technical 'taste' (e.g. Brian Grant from Google -- the guy who drives consistency sat on this group, not me the guy who had access to the purse strings and who was focused on the business).
(side note: i picked this structure because i was geeking on government structures at the time, and figured that the separation of powers yields more sustainable administration)
So being a PTL in OpenStack I have some various comments and questions that would be nice to have your thoughts on.
In terms of looking at OpenStack hard; and reaching decisions based on various <things> did you do any reach out to the OpenStack community to actually communicate the things you found or heard or concluded so that the group there (including myself) can actually work on improving itself (or perhaps some of the reasons you stated aren't even correct and the community could have helped you clarify those)? If not then it concerns me that you may have reached conclusions without actually talking with that community (but I don't want to jump to any conclusions without getting your thoughts/input).
So far from looking outwards in on the CNCF and seeing how it compares to the OpenStack community (which I am more involved with, including other small side-communities that I also work in) I've yet to understand what exactly the CNCF is targeting. It seems to be a body that is just adopting various projects that align to some mission (?); I have personally a hard time understanding the reasoning some of the projects have been adopted, maybe you can shed some light on that (what is true north for the CNCF, where is it written down, what is the TOC actually making adoption yes/no decisions on? what criteria? what is the technical taste you talk about, where is it written down?)
The nice thing about OpenStack is that they are writing most/all of this down and agreeing on those kinds of questions in public:
A fair point. One thing worth remembering is that this was a point in time thing. I have seen a lot of movement and some very positive signals around convergence of OpenStack, and a real focus on the end user community. When I was doing the digging things felt different and there is a decent chance that were open stack where it is now I would have taken a different position.
The mission of CNCF is the promotion of 'cloud native technologies' -- specifically container packaged, dynamically scheduled, micro-services oriented workloads. It isn't about picking winners, it is about establishing a safe space for innovation and bringing to bear the collective communities. We have legitimately taken some time in getting the identity of the foundation established, but I feel like Dan Kohn (our new ED) is doing super work in creating a collaborative space for new projects.
Thanks for the part of the response though I'm still concerned at the 'felt' part though, especially if that felt part didn't involve talking with much/any(?) of that community in a public forum. Is there anything I can do to help you understand it better, I'd at least like to be able to echo whatever concerns you had to that community, because at that point it can be actual data that made the decision to go with CNCF creation and not just feelings or thoughts of movement or positive signals (all very fluffy things IMHO).
So in the CNCF, are competing implementations allowed / encouraged?
For me that would have repercussions for what other tech a CNCF project supports (e.g. is all stats monitoring based on Prometheus, or can 2 projects in the CNCF support different technologies)
Projects can do what they like. We believe that users, communities, market pressures, and so on, will drive good outcomes here. For example to date, all projects have worked to interoperate of their own volition. No committees were formed to achieve this.
Do you allow competing APIs for the same service? If not, how is that any different from OpenStack? If so, how do you address the issue of fragmentation across deployments?
You said it yourself in another comment on here: "It's never blatant, it's always calls for seemingly good things like extra pluggable points to make sure we don't favor particular solutions. Then it's making sure that any decision is brought to a huge vote by a giant committee that spends weeks arguing about if it's something they should even decide on, etc."
This kind of premature generalisation by committee is what has pulled OpenStack down; a situation from which it is now apparently recovering. CNCF seeks to avoid this, by encouraging projects towards interop but not in mandated ways.
to elaborate for @hueving @mugsie et al., consider that OpenStack is organised around Nova, the scheduler++ that is at the heart of any OpenStack deployment. If the CNCF was "like OpenStack" then it could mandate that all projects are organised around Kubernetes, playing a role analogous to Nova. But we didn't want to be solely a "Kubernetes foundation". The market is early stage, and there are other valid approaches to orchestration, including Docker Swarmkit, Hashicorp Nomad, Mesos & DCOS templates like Marathon, and others. So, we need a different approach.
Of course there are people who want a KubeStack that is like OpenStack, for better or worse. That's fine too! We just don't want that to be the ONLY choice for customers.
So, also being a PTL in OpenStack I would say that the foundation design is very similar to the OpenStack one.
1 - the openstack board has 0 technical input to projects - the way to get things done in OpenStack is still to throw developers at it.
This does somewhat push the balance of power to larger companies - they have the money to employ developers.
2 - we have "community directors" who are elected by the people who actually commit code
3 - definite improvement over the initial setup of openstack, but that is currently changing with the User Committee
One question I would have about this - how are the end user groups requirements put forward? what mechanisms is there to ensure developers work on the defined priorities?
4 - Yup - we have the equivalent with the Technical Committee (the TC in OpenStack slang)
Separation of powers is ++ - but how does that play out when the TOC decides that they want to do something that does not mesh with the boards plans?
"how are the end user groups requirements put forward? what mechanisms is there to ensure developers work on the defined priorities?" --> projects are run by their leads, they are not told what to work on. In this sense, CNCF operates more like IETF/ASF but with (arguably) less intrusive governance.
The underlying idea here is that a well-run open source project gets plenty of strong direction from actual users, who must be interacted with directly.
There is a still-forming End User Board designed to create a strong forum for some types of User-Project discussion. But overall CNCF will lean towards "voluntary" and not "mandatory" requirements.
I think you're undervaluing Joe Beda's work. Him, Brendan Burns, and Craig Mcluckie founded kubernetes. They didn't just help start the project, they started the project. Subtle, but notable difference. Otherwise, you're spot on!
To be clear -- Kubernetes was built on ideas that were proven out at Google over 10 years. While it was a new code base, those ideas were the product of a cast of (literally?) thousands.
What Brendan, Craig and I did was (a) meld those ideas with the external-to-Google world (including Docker), (b) motivate releasing it as Open Source (not the default model for Google TI) and (c) work to seed a really open community that we wanted to participate in.
Soon after we started some other folks from around Google and beyond joined in. From Google, those include Ville Aikas (not super active these days, doing other stuff at Google), Tim Hockin, Brian Grant, Dawn Chen, Daniel Smith. Most of these folks had worked on Borg and/or Omega. From outside Kelsey Hightower got involved very early (long before Kubernetes was a thing for CoreOS) and the folks from RedHat (led by Clayton Coleman). I'm sure I'm forgetting folks but hopefully that gives some context.
1. There is already a company doing that, among other things: CoreOS
2. There is usually not a "natural" conflict for companies that started out of open source projects
3. A full kubernetes deploy is already hard
I'm actually quite happy that we will now see Heptio and CoreOS pushing for boxed kubernetes deploys. Multiple entities pushing an open source core is usually a good thing.
>Multiple entities pushing an open source core is usually a good thing
No, it's not that cut and dry. Depending on their product, they end up pushing the core to be more pluggable and extensible to make it work better with their product and have places to add secret sauce.
Any company that sells support benefits from more complexity because they compete by gaining expertise. Any company that makes a product for it benefits from fewer features in the open source version.
Kubernetes will help reduce the number of engineers needed to maintain large systems. This is the beginning of the end for the DevOps engineering career - There will still be DevOps jobs left but they won't pay as much.
Maybe for companies that employ many devopses, but most of my clients already have only one or two.
That is, me with eventually a junior that I'm getting up to speed so he can take my place.
Furthermore, the "run" part is only a fraction of the job, the whole pilgrimage from developers' code to a production-ready container is most of the work, and that's very client-specific.
For example, I will always have a high-paying job at making workflows that help ensuring average developers cannot send bad code in production, that they are reviewed etc.
Kubernetes is great because the "run" part was really the low-hanging fruit. A container is a container, and setting up routing, provisioning etc is very generic and boring.
I'm the CTO and I actually agree with you. We need to continue to make it easier to use. We want to set up Heptio so that motivations are aligned.
When integrating something like Kubernetes with existing systems and processes there will always be opportunity for additional systems and support that aren't easily built in the open. Often times these aren't fun things and so are harder to get critical mass in the open.
The first part of our plan is to help fill usability gaps for Kubernetes in the open. This will grow the pie and expand our standing in the community.
Commercially we will filling gaps unique to large companies around integration with existing systems and managing ops and dev relationships. Specifics here will have to wait until product is ready.
In general we have a value around "Honest Technology". We want to build products that just work and do what it says on the tin.
The reason it happens so frequently, it that developers eventually realise that consulting is the only way to get sustainable source of income for FOSS and big corporations are usually the only ones willing to pay for it.
I think this is awesome news. We have been experimenting with container engines for past 3 months. We are building a massive API backed for bioinformatics where container orchestration and wrapping of heterogenous tools seems to be the way to go.
Yes, the previous projects preceding Kubernetes have a history of being Star Trek references, specifically to the Borg [1].
As to Heptio’s name, Beda explained: “When we were helping create Kubernetes, we pitched it as ‘Seven of Nine,’ a ‘Star Trek: Voyager’ character who’s a former Borg drone. That was a reference to the Borg, a code name for Google’s internal version of Kubernetes, the thing that runs its search and apps and ads. It’s total geek culture. We wanted a friendlier Borg. That name turned into ‘Project Seven.’ When we went public with Kubernetes, we didn’t want to lose track of the ‘seven.’ The Kubernetes logo has seven sides. ‘Hept’ is the Greek prefix for ‘seven,’ and it’s a way to pull the ‘seven’ through.”
I mapped out the influencer networks for Docker and Kubernetes using the tool Little Bird - you can see here[1] that the Kubernetes network is not dominated by any one subgroup: it's not an ecosystem dominated by anybody (except Google, and not in the same way as most OSS which come out of companies). So don't worry about Heptio in that way -- if anything worry that too many companies are all trying to fix the same problems, and they'll be duplicative and not economically viable.
Those graphs are very hard to read, and don't show things like stdev. It just looks like to me that docker is a much more popular project (200+ people in single groups)
They are groupings off of a network clustering based on Twitter following relationships -- scale questions aside, I think they indicate that Docker has a few tightly-connected clusters (the three big ones are roughly DevOps influencers, Docker employees, and Kubernetes folks) vs Kubernetes, which is more fragmented (if you squint the clusters are Docker, CoreOS, Red Hat, a few Google ones, etc.)
I'll try to publish a more detailed analysis soon. My hypothesis is that the K8s influencer ecosystem is not dominated by any one group or any one company, which is not surprising at this stage.
Pardon me if this is somewhere right under my nose, but what is it that Heptio will actually do to "Bring Containers to Enterprise"? Will they maintain a commercial Kubernetes spin, ala Tectonic? Are they going to be mostly about consulting? Will they sell any add-ons?
[disclosure: Craig -- CEO]
to name a few
1. support and services. this is a really important factor for most enterprises; they want to know they have expert staff on call who have a decent shot at getting a change they need upstreamed.
2. consolidation and operations at scale. turns out Kubernetes is being deployed as a 'devops tool' today and people create lots of teensy clusters. we built it to be super flexible and work either for smaller clusters, or work at scale (using namespaces, etc). there are advantages to running larger expert operated clusters (borg style) and we want to help enterprises get there with consolidation and operations tools.
3. integration tech. there are oceans of 'legacy' systems that basically run enterprise today and need to be integrated with.
4. help with for non-Google environments. despite the fact that there are tons of interested commercial parties in K8s, except for a few awesome community folks companies aren't putting a ton of resource into AWS, or OpenStack, etc and do unglamorous testing work, etc. Would love to help get the cloud provider model sustainable, and put effort into doing stuff like testing and better deployment tech.
Greg,
Is business model centered on delivery & facilitating heavy lifting necessary for large enterprise? Will this heavy lifting be delivered as "professional & support" service....batteries included like solutions for legacy system integrations. Primarily K8S focused high powered consultancy services??
Company centered & focussed on helping enterprise embrace open cloud, cloud native systems and help them realize value is fantastic. We are at a juncture where building a company on such tenets make sense....better chance of a building viable business model around it. Pain of vendor lock-in in enterprise software space will only grow strongly in coming years.
Story goes like this: Joe and I did Google Compute Engine together. Once that was on rails we started looking at the gap between GAE and GCE. Joe found Docker way back before it was a household name, and we started thinking hard about the 'compute continuum'. What beyond the container format was needed. Brendan was working in the meantime on something that looked like cloud formation that we were also playing with. We had instantly good chemistry with the three of us, and he started looking at Docker too.
To raise awareness of Docker in Google, I asked Brendan to pull together a demo for our all hands. In a nutshell what he produced was the bones of Kubernetes. I remember looking at it and having a moment, he had built a mini borg cell on VMs. Basically made borg a devops accessible tool, not just a monolithic clustering tool (like Mesos was). When I saw that the product ramifications were obvious, I called Joe over to look and the rest is history.
This was all in the Seattle office. From the Mountain View office, some of the Borg team had been muttering about "something something Borg as a service", but we really didn't know the first thing about cloud products. When we saw the first demos of what would become Kubernetes, we knew pretty quickly that this was the way. From that point on, the synergy was pretty electric.
LOL. Borg is 13 years old, and has THOUSANDS of person-years of work in it. Kubernetes is less than 3 years old. Kubernetes is great, but Borg is a custom-built, totally proprietary system which is fully integrated in the Google ecosystem. You don't replace something like that in 2 years.
I don't use k8s, so forgive my ignorance, but what are the use cases in "the enterprise"? How many "enterprises" need to manage 1K microservice containers to approve weekly timesheets? Is this just a play for companies that want to run their products/services on private cloud?
We're a consultancy doing this right now, and medium and big companies need and want this.
Just one simple example of many: think of all the software services that Tesla needs to do the fancy stuff that they are doing.
There are many car companies right now trying to catch up, building scalable and resilient services, doing analytics, navigation, M2M stuff, emergency services, car rental, lots of stuff.
Weekly timesheets of course is definitely not the use case for this.
Congrats to the Heptio team! I love using k8s and I hope this will lead to even more contribution and adoption by more folks. k8s is what really makes it possible to use Docker containers in a production pipeline.
75 comments
[ 2.2 ms ] story [ 149 ms ] threadThis happens quite frequently with open source infrastructure. Keep an eye on them to push back against improvements that directly conflict with their company's "enterprise sauce".
It isn't quite there yet but things are improving on that front all the time and will be significantly better for newbies in a few more versions. In other words, it is getting there, don't worry about it.
It's never blatant, it's always calls for seemingly good things like extra pluggable points to make sure we don't favor particular solutions. Then it's making sure that any decision is brought to a huge vote by a giant committee that spends weeks arguing about if it's something they should even decide on, etc.
Ultimately there are ways to do immense damage to open source communities with small well placed "concerns" that seed doubt. Usually it's a mailing list post (or github issue) with some grand question like "Is X something Kubernetes should really be doing?" followed by bullet points outlining other unrelated issues that "we should be focusing on" and to "leave X up to other tools because the solutions are a matter of taste and therefore there is no right solution."
It is unlike, for example, Influxdata that they own InfluxDB and dont integrate clustering capability into open source edition.
I'm hopeful k8 won't go the way of openstack because the problem domain is simpler and more well defined, but I'll be damned if I ever believe a "diverse" group of enterprises with shared interests can reliably produce good software.
Fool me once, shame on me. Fool me twice, shame on the standards committee.
It is a funny you say this. I spent a lot of time looking around the community at what existed before starting CNCF, and agonized over this. We needed to take K8s to foundation so that it wouldn't be a 'Google project'. Google was actually the best steward of the tech you could imagine, because the plan was always to make k8s ubiquitous and just win on quality of infrastructure but the community had no way to know that.
I looked at OpenStack hard, and like the energy and enthusiasm but really worried about (1) balkanization that was emerging with no 'true north' -- it just didn't have technical taste, (2) the tragedy of the commons -- most vendors were focused on their own interests and neglected the end users, (3) lack of coherence.
When designing CNCF I tried hard to work through this by creating a better foundation structure. (1) the business board has very limited authority over projects, hopefully making sure that we avoid it being a pay-for-play affair. (2) we made provisions for little companies to get top level seats based on community contributions (ditto) (3) we created an empowered end user group that would have equal authority to any other affair to make sure real users interest are promoted (4) we added a TOC (technical oversight committee) that was the most empowered group to establish true north that is community elected -- the idea is they need to champion the projects and establish technical 'taste' (e.g. Brian Grant from Google -- the guy who drives consistency sat on this group, not me the guy who had access to the purse strings and who was focused on the business).
(side note: i picked this structure because i was geeking on government structures at the time, and figured that the separation of powers yields more sustainable administration)
In terms of looking at OpenStack hard; and reaching decisions based on various <things> did you do any reach out to the OpenStack community to actually communicate the things you found or heard or concluded so that the group there (including myself) can actually work on improving itself (or perhaps some of the reasons you stated aren't even correct and the community could have helped you clarify those)? If not then it concerns me that you may have reached conclusions without actually talking with that community (but I don't want to jump to any conclusions without getting your thoughts/input).
So far from looking outwards in on the CNCF and seeing how it compares to the OpenStack community (which I am more involved with, including other small side-communities that I also work in) I've yet to understand what exactly the CNCF is targeting. It seems to be a body that is just adopting various projects that align to some mission (?); I have personally a hard time understanding the reasoning some of the projects have been adopted, maybe you can shed some light on that (what is true north for the CNCF, where is it written down, what is the TOC actually making adoption yes/no decisions on? what criteria? what is the technical taste you talk about, where is it written down?)
The nice thing about OpenStack is that they are writing most/all of this down and agreeing on those kinds of questions in public:
https://github.com/openstack/governance/tree/master/referenc... (github is a mirror, not the source of this repo, but easier for browsing purposes).
The mission of CNCF is the promotion of 'cloud native technologies' -- specifically container packaged, dynamically scheduled, micro-services oriented workloads. It isn't about picking winners, it is about establishing a safe space for innovation and bringing to bear the collective communities. We have legitimately taken some time in getting the identity of the foundation established, but I feel like Dan Kohn (our new ED) is doing super work in creating a collaborative space for new projects.
For me that would have repercussions for what other tech a CNCF project supports (e.g. is all stats monitoring based on Prometheus, or can 2 projects in the CNCF support different technologies)
Do you ask projects to support all the implementations or just choose one?
You said it yourself in another comment on here: "It's never blatant, it's always calls for seemingly good things like extra pluggable points to make sure we don't favor particular solutions. Then it's making sure that any decision is brought to a huge vote by a giant committee that spends weeks arguing about if it's something they should even decide on, etc."
This kind of premature generalisation by committee is what has pulled OpenStack down; a situation from which it is now apparently recovering. CNCF seeks to avoid this, by encouraging projects towards interop but not in mandated ways.
Of course there are people who want a KubeStack that is like OpenStack, for better or worse. That's fine too! We just don't want that to be the ONLY choice for customers.
1 - the openstack board has 0 technical input to projects - the way to get things done in OpenStack is still to throw developers at it.
This does somewhat push the balance of power to larger companies - they have the money to employ developers.
2 - we have "community directors" who are elected by the people who actually commit code 3 - definite improvement over the initial setup of openstack, but that is currently changing with the User Committee
One question I would have about this - how are the end user groups requirements put forward? what mechanisms is there to ensure developers work on the defined priorities?
4 - Yup - we have the equivalent with the Technical Committee (the TC in OpenStack slang)
Separation of powers is ++ - but how does that play out when the TOC decides that they want to do something that does not mesh with the boards plans?
The underlying idea here is that a well-run open source project gets plenty of strong direction from actual users, who must be interacted with directly.
There is a still-forming End User Board designed to create a strong forum for some types of User-Project discussion. But overall CNCF will lean towards "voluntary" and not "mandatory" requirements.
What Brendan, Craig and I did was (a) meld those ideas with the external-to-Google world (including Docker), (b) motivate releasing it as Open Source (not the default model for Google TI) and (c) work to seed a really open community that we wanted to participate in.
Soon after we started some other folks from around Google and beyond joined in. From Google, those include Ville Aikas (not super active these days, doing other stuff at Google), Tim Hockin, Brian Grant, Dawn Chen, Daniel Smith. Most of these folks had worked on Borg and/or Omega. From outside Kelsey Hightower got involved very early (long before Kubernetes was a thing for CoreOS) and the folks from RedHat (led by Clayton Coleman). I'm sure I'm forgetting folks but hopefully that gives some context.
2. There is usually not a "natural" conflict for companies that started out of open source projects
3. A full kubernetes deploy is already hard
I'm actually quite happy that we will now see Heptio and CoreOS pushing for boxed kubernetes deploys. Multiple entities pushing an open source core is usually a good thing.
No, it's not that cut and dry. Depending on their product, they end up pushing the core to be more pluggable and extensible to make it work better with their product and have places to add secret sauce.
Any company that sells support benefits from more complexity because they compete by gaining expertise. Any company that makes a product for it benefits from fewer features in the open source version.
That is, me with eventually a junior that I'm getting up to speed so he can take my place.
Furthermore, the "run" part is only a fraction of the job, the whole pilgrimage from developers' code to a production-ready container is most of the work, and that's very client-specific.
For example, I will always have a high-paying job at making workflows that help ensuring average developers cannot send bad code in production, that they are reviewed etc.
Kubernetes is great because the "run" part was really the low-hanging fruit. A container is a container, and setting up routing, provisioning etc is very generic and boring.
When integrating something like Kubernetes with existing systems and processes there will always be opportunity for additional systems and support that aren't easily built in the open. Often times these aren't fun things and so are harder to get critical mass in the open.
The first part of our plan is to help fill usability gaps for Kubernetes in the open. This will grow the pie and expand our standing in the community.
Commercially we will filling gaps unique to large companies around integration with existing systems and managing ops and dev relationships. Specifics here will have to wait until product is ready.
In general we have a value around "Honest Technology". We want to build products that just work and do what it says on the tin.
As to Heptio’s name, Beda explained: “When we were helping create Kubernetes, we pitched it as ‘Seven of Nine,’ a ‘Star Trek: Voyager’ character who’s a former Borg drone. That was a reference to the Borg, a code name for Google’s internal version of Kubernetes, the thing that runs its search and apps and ads. It’s total geek culture. We wanted a friendlier Borg. That name turned into ‘Project Seven.’ When we went public with Kubernetes, we didn’t want to lose track of the ‘seven.’ The Kubernetes logo has seven sides. ‘Hept’ is the Greek prefix for ‘seven,’ and it’s a way to pull the ‘seven’ through.”
[1] http://www.geekwire.com/2016/ever-come-kooky-kubernetes-name...
I would describe this as a case of 'domain based naming' (i.e. we could get the domain name, it was uncontested space).
I hope to create something positive out of it, if we do it up right hopefully the company character will dominate the name.
1: https://twitter.com/jtroyer/status/799451113606893568
I'll try to publish a more detailed analysis soon. My hypothesis is that the K8s influencer ecosystem is not dominated by any one group or any one company, which is not surprising at this stage.
You can clearly see the diverse number of contributors/companies
[1]https://cauldron.io/
Please, have in mind it is (for now) just a proof of concept.
To raise awareness of Docker in Google, I asked Brendan to pull together a demo for our all hands. In a nutshell what he produced was the bones of Kubernetes. I remember looking at it and having a moment, he had built a mini borg cell on VMs. Basically made borg a devops accessible tool, not just a monolithic clustering tool (like Mesos was). When I saw that the product ramifications were obvious, I called Joe over to look and the rest is history.
Google Cloud does offer hosted k8s though.
Well but why not having some more diversity in that area.
Just the title sounds like no one would be working on this angle.
I would love your feedback on the mailing lists or twitter: https://coreso.com/community
Just one simple example of many: think of all the software services that Tesla needs to do the fancy stuff that they are doing.
There are many car companies right now trying to catch up, building scalable and resilient services, doing analytics, navigation, M2M stuff, emergency services, car rental, lots of stuff.
Weekly timesheets of course is definitely not the use case for this.
Some other pointers that give context here:
My blog post on my motivations: https://www.eightypercent.net/post/another-leap-heptio.html
The press release: https://blog.heptio.com/founding-members-of-kubernetes-team-...
Blog post: "Cloud Native Part 1: Definition" https://blog.heptio.com/cloud-native-part-1-definition-716ed...
Guest article (from Craig): "Cloud Native: Service-driven Operations that Save Money, Increase IT Flexibility " http://thenewstack.io/towards-cloud-native-operations/