Personal blog of Yzmir Ramirez

IoT devices currently lack a standard way of applying security. It leaves consumers, whether business or individuals, left to wonder if their devices are secure and up-to-date. Foundries.io, a company that launched today, wants to change that by offering a standard way to secure devices and deliver updates over the air.

“Our mission is solving the problem of IoT and embedded space where there is no standardized core platform like Android for phones,” Foundries.io CEO George Grey explained.

What Foundries has created is an open and secure solution that saves everyone from creating their own and reinventing the wheel every time. Grey says Foundries’ approach is not only secure, it provides a long-term solution to the device update problem by providing a way to deliver updates over the air in an automated manner on any device from tiny sensors to smart thermostats to autonomous cars.

He says this approach will allow manufacturers to apply security patches in a similar way that Apple applies regular updates to iOS. “Manufacturers can continuously make sure their devices can be updated with the latest software to fix security flaws or Zero Day flaws,” he said.

The company offers two solutions, depending on the size and complexity of your device. The Zephyr RTOS microPlatform is designed for smaller, less complex devices. For those that are more complex, Foundries offers a version of Linux called the Linux OE microPlatform.

Grey claims that these platforms free manufacturers to build secure devices without having to hire a team of security experts. But he says the real beauty of the product is that the more people who use it, the more secure it will get, as more and more test it against their products in a virtuous cycle.

You may be wondering how they can make money in this model, but they do it by charging a flat fee of $10,000 per year for Zephyr RTOS and $25,000 per year for Linux OE. These are one-time prices and apply by the product, regardless of how many units get sold and there is no lock-in, according to Grey. Companies are free to back out any time. “If you want to stop subscribing you take over maintenance and you still have access to everything up to the point,. You just have to arrange maintenance yourself,” he said.

There is also a hobbyist and education package for $10 a month.

The company spun off from research at Linaro, an organization that promotes development on top of ARM chips.

To be successful, Foundries.io needs to build a broad community of manufacturers. Today’s launch is the first step in that journey. If it eventually takes off, it has the potential to provide a consistent way of securing and updating IoT devices, a move which would certainly be welcome.

Oracle, a company not exactly known for having the best relationship with the open source community, is releasing a new open source tool today called Graphpipe, which is designed to simplify and standardize the deployment of machine learning models.

The tool consists of a set of libraries and tools for following the standard.

Vish Abrams, whose background includes helping develop OpenStack at NASA and later helping launch Nebula, an OpenStack startup in 2011, is leading the project. He says as his team dug into the machine learning workflow, they found a gap. While teams spend lots of energy developing a machine learning model, it’s hard to actually deploy the model for customers to use. That’s where Graphpipe comes in.

He points out that it’s common with newer technologies like machine learning for people to get caught up in the hype. Even though the development process keeps improving, he says that people often don’t think about deployment.

“Graphpipe is what’s grown out of our attempt to really improve deployment stories for machine learning models, and to create an open standard around having a way of doing that to improve the space,” Abrams told TechCrunch.

As Oracle dug into this, they identified three main problems. For starters, there is no standard way to serve APIs, leaving you to use whatever your framework provides. Next, there is no standard deployment mechanism, which leaves developers to build custom ones every time. Finally, they found existing methods leave performance as an afterthought, which in machine learning could be a major problem.

“We created Graphpipe to solve these three challenges. It provides a standard, high-performance protocol for transmitting tensor data over the network, along with simple implementations of clients and servers that make deploying and querying machine learning models from any framework a breeze,” Abrams wrote in a blog post announcing the release of Graphpipe.

The company decided to make this a standard and to open source it to try and move machine learning model deployment forward. “Graphpipe sits on that intersection between solving a business problems and pushing the state of the art forward, and I think personally, the best way to do that is by have an open source approach. Often, if you’re trying to standardize something without going for the open source bits, what you end up with is a bunch of competing technologies,” he said.

Abrams acknowledged the tension that has existed between Oracle and the open source community over the years, but says they have been working to change the perception recently with contributions to Kubernetes and Oracle FN, their open source Serverless Functions Platform as examples. Ultimately he says, if the technology is interesting enough, people will give it a chance, regardless of who is putting it out there. And of course, once it’s out there, if a community builds around it, they will adapt and change it as open source projects tend to do. Abrams hopes that happens.

“We care more about the standard becoming quite broadly adopted, than we do about our particular implementation of it because that makes it easier for everyone. It’s really up to the community decide that this is valuable and interesting.” he said.

Graphpipe is available starting today on the Oracle GitHub Graphpipe page.

The Cloud Native Computing Foundation (CNCF) may not be a household name, but it houses some important open source projects including Kubernetes, the fast-growing container orchestration tool. Today, CNCF announced that the Prometheus monitoring and alerting tool had joined Kubernetes as the second “graduated” project in the organization’s history.

The announcement was made at PromCon, the project’s dedicated conference being held in Munich this week. According to Chris Aniszczyk, CTO and COO at CNCF, a graduated project reflects the overall maturity where it has reached a tipping point in terms of diversity of contribution, community and adoption.

For Prometheus that means 20 active maintainers, more than 1,000 contributors and more than 13,000 commits. Its contributors include the likes of DigitalOcean, Weaveworks, ShowMax and Uber.

CNCF projects start in the sandbox, move onto incubation and finally to graduation. To achieve graduation level, they need to adopt the CNCF Code of Conduct, have passed an independent security audit and defined a community governance structure. Finally it needs to show an “ongoing commitment to code quality and security best practices,” according to the organization.

Aniszczyk says the tool consists of a time series database combined with a query language that lets developers search for issues or anomalies in their system and get analytics back based on their queries. Not surprisingly, it is especially well suited to containers.

Like Kubernetes, the project that became Prometheus has its roots inside Google. Google was one of the first companies to work with containers and developed Borg (the Kubernetes predecessor) and Borgmon (the Prometheus predecessor). While Borg’s job was to manage container orchestration, Borgmon’s job was to monitor the process and give engineers feedback and insight into what was happening to the containers as they moved through their lifecycle.

While its roots go back to Borgmon, Prometheus as we know it today was developed by a couple of former Google engineers at SoundCloud in 2012. It joined Kubernetes as the second CNCF project in May 2016, and appropriately is the second graduate.

The Cloud Native Computing Foundation’s role in all of this to help promote cloud native computing, the notion that you can manage your infrastructure wherever it lives in a common way, greatly reducing the complexity of managing on-prem and cloud resources. It is part of the Linux Foundation and boasts some of the biggest names in tech as members.

GitHub, the code hosting service Microsoft recently acquired, is launching a couple of new features for its business users today that’ll make it easier for them to access public repositories on the service.

Traditionally, users on the hosted Business Cloud and self-hosted Enterprise were not able to directly access the millions of public open-source repositories on the service. Now, with the service’s release, that’s changing, and business users will be able to reach beyond their firewalls to engage and collaborate with the rest of the GitHub community directly.

With this, GitHub now also offers its business and enterprise users a new unified search feature that lets them tap into their internal repos but also look at open-source ones.

Other new features in this latest Enterprise release include the ability to ignore whitespace when reviewing changes, the ability to require multiple reviewers for code changes, automated support tickets and more. You can find a full list of all updates here.

Microsoft’s acquisition of GitHub wasn’t fully unexpected (and it’s worth noting that the acquisition hasn’t closed yet), but it is still controversial, given that Microsoft and the open-source community, which heavily relies on GitHub, haven’t always seen eye-to-eye in the past. I’m personally not too worried about that, and it feels like the dust has settled at this point and that people are waiting to see what Microsoft will do with the service.

Nginx, the commercial company behind the open source web server, announced a $43 million Series C investment today led by Goldman Sachs Growth Equity.

NEA, which has been on board as an early investor is also participating. As part of the deal, David Campbell, managing director at Goldman Sachs’ Merchant Banking Division will join the Nginx board. Today’s investment brings the total raised to $103 million, according to the company.

The company was not willing to discuss valuation for this round.

Nginx’s open source approach is already well established running 400 million websites including some of the biggest in the world. Meanwhile, the commercial side of the business has 1,500 paying customers, giving those customers not just support, but additional functionality such as load balancing, an API gateway and analytics.

Nginx CEO Gus Robertson was pleased to get the backing of such prestigious investors. “NEA is one of the largest venture capitalists in Silicon Valley and Goldman Sachs is one of the largest investment banks in the world. And so to have both of those parceled together to lead this round is a great testament to the company and the technology and the team,” he said.

The company already has plans to expand its core commercial product, Nginx Plus in the coming weeks. “We need to continue to innovate and build products that help our customers alleviate the complexity of delivery of distributed or micro service based applications. So you’ll see us release a new product in the coming weeks called Controller. Controller is the control plane on top of Nginx Plus,” Robertson explained. (Controller was launched in Beta last fall.)

But with $43 million in the bank, they want to look to build out Nginx Plus even more in the next 12-18 months. They will also be opening new offices globally to add to its international presence, while expanding its partners ecosystem. All of this means an ambitious goal to increase the current staff of 220 to 300 by the end of the year.

The open source product was originally created by Igor Sysoev back in 2002. He introduced the commercial company on top of the open source project in 2011. Robertson came on board as CEO a year later. The company has been growing 100 percent year over year since 2013 and expects to continue that trajectory through 2019.

On June 6th, 2014 Kubernetes was released for the first time. At the time, nobody could have predicted that 4 years later that the project would become a de facto standard for container orchestration or that the biggest tech companies in the world would be backing it. That would come later.

If you think back to June 2014, containerization was just beginning to take off thanks to Docker, which was popularizing the concept with developers, but being so early there was no standard way to manage those containers.

Google had been using containers as a way to deliver applications for years and ran a tool called Borg to handle orchestration. It’s called an orchestrator because much like a conductor of an orchestra, it decides when a container is launched and when it shuts down once it’s completed its job.

At the time, two Google engineers, Craig McLuckie and Joe Beda, who would later go on to start Heptio, were looking at developing an orchestration tool like Borg for companies that might not have the depth of engineering talent of Google to make it work. They wanted to spread this idea of how they develop distributed applications to other developers.

Hello world

Before that first version hit the streets, what would become Kubernetes developed out of a need for an orchestration layer that Beda and McLuckie had been considering for a long time. They were both involved in bringing Google Compute Engine, Google’s Infrastructure as a Service offering, to market, but they felt like there was something missing in the tooling that would fill in the gaps between infrastructure and platform service offerings.

“We had long thought about trying to find a way to bring a sort of a more progressive orchestrated way of running applications in production. Just based on our own experiences with Google Compute Engine, we got to see firsthand some of the challenges that the enterprise faced in moving workloads to the cloud,” McLuckie explained.

He said that they also understood some of the limitations associated with virtual machine-based workloads and they were thinking about tooling to help with all of that. “And so we came up the idea to start a new project, which ultimately became Kubernetes.”

Let’s open source it

When Google began developing Kubernetes in March 2014, it wanted nothing less than to bring container orchestration to the masses. It was a big goal and McLuckie, Beda and teammate Brendan Burns believed the only way to get there was to open source the technology and build a community around it. As it turns out, they were spot on with that assessment, but couldn’t have been 100 percent certain at the time. Nobody could have.

“If you look at the history, we made the decision to open source Kubernetes and make it a community-oriented project much sooner than conventional wisdom would dictate and focus on really building a community in an open and engaged fashion. And that really paid dividends as Kubernetes has accelerated and effectively become the standard for container orchestration,” McLuckie said.

The next thing they did was to create the Cloud Native Computing Foundation (CNCF) as an umbrella organization for the project. If you think about it, this project could have gone in several directions, as current CNCF director Dan Kohn described in a recent interview.

Going cloud native

Kohn said Kubernetes was unique in a couple of ways. First of all, it was based on existing technology developed over many years at Google. “Even though Kubernetes code was new, the concepts and engineering and know-how behind it was based on 15 years at Google building Borg (And a Borg replacement called Omega that failed),” Kohn said. The other thing was that Kubernetes was designed from the beginning to be open sourced.

He pointed out that Google could have gone in a few directions with Kubernetes. It could have created a commercial product and sold it through Google Cloud. It could have open sourced it, but had a strong central lead as they did with Go. They could have gone to the Linux Foundation and said they wanted to create a stand-alone Kubernetes Foundation. But they didn’t do any of these things.

McLuckie says they decided to something entirely different and place it under the auspices of the Linux Foundation, but not as Kubernetes project. Instead they wanted to create a new framework for cloud native computing itself and the CNCF was born. “The CNCF is a really important staging ground, not just for Kubernetes, but for the technologies that needed to come together to really complete the narrative, to make Kubernetes a much more comprehensive framework,” McLuckie explained.

Getting everyone going in the same direction

Over the last few years, we have watched as Kubernetes has grown into a container orchestration standard. Last summer in quick succession  a slew of major enterprise players joined CNCF as AWS, Oracle, Microsoft, VMware and Pivotal all joined. They came together with Red Hat, Intel, IBM Cisco and others who were already members.

Each these players no doubt wanted to control the orchestration layer, but they saw Kubernetes gaining momentum so rapidly, they had little choice but to go along. Kohn jokes that having all these big name players on board is like herding cats, but bringing in them in has been the goal all along. He said it just happened much faster than he thought it would.

In a recent interview with TechCrunch, David Aronchick, who runs the open source Kubeflow Kubernetes machine learning project at Google, was running Kubernetes in the early days. He is shocked by how quickly it has grown. “I couldn’t have predicted it would be like this. I joined in January, 2015 and took on project management for Google Kubernetes. I was stunned at the pent up demand for this kind of thing,” he told TechCrunch.

As it has grown, it has become readily apparent that McLuckie was right about building that cloud native framework instead of a stand-alone Kubernetes foundation. Today there are dozens of adjacent projects and the organization is thriving.

Nobody is more blown away by this than McLuckie himself who says seeing Kubernetes hit these various milestones since its initial release has been amazing for him and his team to watch. “It’s just been a series of these wonderful kind of moments as Kubernetes has gained a head of steam, and it’s been  so much fun to see the community really rally around it.”

Helm is an open source project that enables developers to create packages of containerized apps to make installation much simpler. Up until now, it was a sub-project of Kubernetes, the popular container orchestration tool, but as of today it is a stand-alone project.

Both Kubernetes and Helm are projects managed by the Cloud Native Computing Foundation (CNCF). The CNCF’s Technical Oversight Committee approved the project earlier this week. Dan Kohn, executive director at the CNCF says the two projects are closely aligned so it made sense for Helm to be a sub-project up until now.

“What’s nice about Helm is that it’s just an application on top of Kubernetes. Kubernetes is an API and Helm accesses that API. If you want you to install this [package], you access the Kubernetes API, and it pulls this many containers and pods and [it handles] all of the steps involved to do that,” Kohn explained.

This ability to package up a set of requirements allows you to repeat the installation process in a consistent way. “Helm addresses a common user need of deploying applications to Kubernetes by making their configurations reusable,” Brian Grant, principal engineer at Google and Kubernetes (and a member of the TOC) explained in a statement.

Packages are known as “charts,” which consist one or more containers. Kohn says for example, you might want to deploy a chart that includes WordPress and MariaDB in a single container. By creating a chart, it defines the installation process and which pieces need to go in which order to install correctly across a cluster.

Kohn said they decided to pull it out as a separate program because it doesn’t always follow the Kubernetes release schedule, and as such they wanted to make it stand-alone so it wouldn’t necessarily have to be linked to every Kubernetes release.

It also allows developers to benefit from the community, who could build Charts for common installation scenarios. “By joining CNCF, we’ll benefit from the input and participation of the community, and conversely Kubernetes will benefit when a community of developers provides a vast repository of ready-made charts for running workloads on Kubernetes,” Matt Butcher, co-creator of Helm and principal engineer at Microsoft said in a statement.

Besides Microsoft and Google, other project sponsors include Codefresh, Bitnami, Ticketmaster and Codecentric. The project website states there are currently 250 developers contributing to this project. By becoming part of CNCF that will very likely increase soon.

OpenStack is one of the most important and complex open-source projects you’ve never heard of. It’s a set of tools that allows large enterprises ranging from Comcast and PayPal to stock exchanges and telecom providers to run their own AWS-like cloud services inside their data centers. Only a few years ago, there was a lot of hype around OpenStack as the project went through the usual hype cycle. Now, we’re talking about a stable project that many of the most valuable companies on earth rely on. But this also means the ecosystem around it — and the foundation that shepherds it — is now trying to transition to this next phase.

The OpenStack project was founded by Rackspace and NASA in 2010. Two years later, the growing project moved into the OpenStack Foundation, a nonprofit group that set out to promote the project and help manage the community. When it was founded, OpenStack still had a few competitors, like CloudStack and Eucalyptus. OpenStack, thanks to the backing of major companies and its fast-growing community, quickly became the only game in town, though. With that, community events like the OpenStack Summit started to draw thousands of developers, and with each of its semi-annual releases, the number of contributors to the project has increased.

Now, that growth in contributors has slowed and, as evidenced by the attendance at this week’s Summit in Vancouver.

In the early days, there were also plenty of startups in the ecosystem — and the VC money followed them, together with some of the most lavish conference parties (or “bullshit,” as Canonical founder Mark Shuttleworth called it) that I have experienced. The OpenStack market didn’t materialize quite as fast as many had hoped, though, so some of the early players went out of business, some shut down their OpenStack units and others sold to the remaining players. Today, only a few of the early players remain standing, and the top players are now the likes of Red Hat, Canonical and Rackspace.

And to complicate matters, all of this is happening in the shadow of the Cloud Native Computing Foundation (CNCF) and the Kubernetes project it manages being in the early stages of the hype cycle.

Meanwhile, the OpenStack Foundation itself is in the middle of its own transition as it looks to bring on other open-source infrastructure projects that are complementary to its overall mission of making open-source infrastructure easier to build and consume.

Unsurprisingly, all of this clouded the mood at the OpenStack Summit this week, but I’m actually not part of the doom and gloom contingent. In my view, what we are seeing here is a mature open-source project that has gone through its ups and downs and now, with all of the froth skimmed off, it’s a tool that provides a critical piece of infrastructure for businesses. Canonical’s Mark Shuttleworth, who created his own bit of drama during his keynote by directly attacking his competitors like Red Hat, told me that low attendance at the conference may not be a bad thing, for example, since the people who are actually in attendance are now just trying to figure out what OpenStack is all about and are all potential customers.

Others echoed a similar sentiment. “I think some of it goes with, to some extent, what’s been building over the last couple of Summits,” Bryan Thompson, Rackspace’s senior director and general manager for OpenStack, said as he summed up what I heard from a number of other vendors at the event. “That is: Is open stack dead? Is this going away? Or is everything just leapfrogging and going straight to Kubernetes on bare metal. And I don’t want to phrase it as ‘it’s a good thing,’ because I think it’s a challenge for the foundation and for the community. But I think it’s actually a positive thing because the core OpenStack services — the core projects — have just matured. We’re not in the early science experiment days of trying to push ahead and scale and grow the core projects, they were actually achieved and people are actually using it.”

That current state produces fewer flashy headlines, but every survey, both from the Foundation itself and third-party analysts, show that the number of users — and their OpenStack clouds — continues to grow. Meanwhile, the Foundation is looking to bring up attendance at its events, too, by adding container and CI/CD tracks, for example.

The company that maybe best exemplifies the ups and downs of OpenStack is Mirantis, a well-funded startup that has weathered the storm by reinventing itself multiple times. Mirantis started as one of the first OpenStack distributions and contributors to the project. During those early days, it raised one of the largest funding rounds in the OpenStack world with a $100 million Series B round, which was quickly followed by another $100 million round in 2015. But by early 2017, Mirantis had pivoted from being a distribution and toward offering managed services for open-source platforms. It also made an early bet on Kubernetes and offered services for that, too. And then this year, it added yet another twist to its corporate story by refocusing its efforts on the Netflix-incubated Spinnaker open-source tool and helping companies build their CI/CD pipelines based on that. In the process, the company shrunk from almost 1,000 employees to 450 today, but as Mirantis CEO and co-founder Boris Renski told me, it’s now cash-flow positive.

So just as the OpenStack Foundation is moving toward CI/CD with its Zuul tool, Mirantis is betting on Spinnaker, which solves some of the same issues, but with an emphasis on integrating multiple code repositories. Renski, it’s worth noting, actually advocated for bringing Spinnaker into the OpenStack foundation (it’s currently managed on a more ad hoc basis by Netflix and Google).

“We need some governance, we need some process,” Renski said. “The [OpenStack] Foundation is known for actually being very good and effectively seeding this kind of formalized, automated and documented governance in open source and the two should work together much closer. I think that Spinnaker should become part of the Foundation. That’s the opportunity and I think it should focus 150 percent of their energy on that before it builds its own thing and before [Spinnaker] goes off to the CNCF as yet another project.”

So what does the Foundation think about all of this? In talking to OpenStack CTO Mark Collier and Executive Director Jonathan Bryce over the last few months, it’s clear that the Foundation knows that change is needed. That process started with opening up the Foundation to other projects, making it more akin to the Linux Foundation, where Linux remains in the name as its flagship project, but where a lot of the energy now comes from projects it helps manage, including the likes of the CNCF and Cloud Foundry. At the Sydney Summit last year, the team told me that part of the mission now is to retask the large OpenStack community to work on these new topics around open infrastructure. This week, that message became clearer.

“Our mission is all about making it easier for people to build and operate open infrastructure,” Bryce told me this week. “And open infrastructure is about operating functioning services based off of open source tool. So open source is not enough. And we’ve been, you know, I think, very, very oriented around a set of open source projects. But in the seven years since we launched, what we’ve seen is people have taken those projects, they’ve turned it into services that are running and then they piled a bunch of other stuff on top of it — and that becomes really difficult to maintain and manage over the long term.” So now, going forward, that part about maintaining these clouds is becoming increasingly important for the project.

“Open source is not enough,” is an interesting phrase here, because that’s really at the core of the issue at hand. “The best thing about open source is that there’s more of it than ever,” said Bryce. “And it’s also the worst thing. Because the way that most open source communities work is that it’s almost like having silos of developers inside of a company — and then not having them talk to each other, not having them test together, and then expecting to have a coherent, easy to use product come out at the end of the day.”

And Bryce also stressed that projects like OpenStack can’t be only about code. Moving to a cloud-native development model, whether that’s with Kubernetes on top of OpenStack or some other model, is about more than just changing how you release software. It’s also about culture.

“We realized that this was an aspect of the foundation that we were under-prioritizing,” said Bryce. “We focused a lot on the OpenStack projects and the upstream work and all those kinds of things. And we also built an operator community, but I think that thinking about it in broader terms lead us to a realization that we had last year. It’s not just about OpenStack. The things that we have done to make OpenStack more usable apply broadly to these businesses [that use it], because there isn’t a single one that’s only running OpenStack. There’s not a single one of them.”

More and more, the other thing they run, besides their legacy VMware stacks, is containers and specifically containers managed with Kubernetes, of course, and while the OpenStack community first saw containers as a bit of a threat, the Foundation is now looking at more ways to bring those communities together, too.

What about the flagging attendance at the OpenStack events? Bryce and Collier echoed what many of the vendors also noted. “In the past, we had something like 7,000 developers — something insane — but the bulk of the code comes down to about 200 or 300 developers,” said Bryce. Even the somewhat diminished commercial ecosystem doesn’t strike Bryce and Collier as too much of an issue, in part because the Foundation’s finances are closely tied to its membership. And while IBM dropped out as a project sponsor, Tencent took its place.

“There’s the ecosystem side in terms of who’s making a product and selling it to people,” Collier acknowledged. “But for whom is this so critical to their business results that they are going to invest in it. So there’s two sides to that, but in terms of who’s investing in OpenStack and the Foundation and making all the software better, I feel like we’re in a really good place.” He also noted that the Foundation is seeing lots of investment in China right now, so while other regions may be slowing down, others are picking up the slack.

So here is an open-source project in transition — one that has passed through the trough of disillusionment and hit the plateau of productivity, but that is now looking for its next mission. Bryce and Collier admit that they don’t have all the answers, but if there’s one thing that’s clear, it’s that both the OpenStack project and foundation are far from dead.

Kubernetes, the open source container orchestration tool, came out of Google several years ago and has gained traction amazingly fast. With each step in its growth, it has created opportunities for companies to develop businesses on top of the open source project.

The beauty of open source is that when it works, you build a base platform and an economic ecosystem follows in its wake. That’s because a project like Kubernetes (or any successful open source offering) generates new requirements as a natural extension of the growth and development of a project.

Those requirements represent opportunities for new projects, of course, but also for startups looking at building companies adjacent that open source community. Before that can happen however, a couple of key pieces have to fall into place.

Ingredients for success

For starters you need the big corporates to get behind it. In the case of Kuberentes, in a 6 week period last year in quick succession between July and the beginning of September, we saw some of the best known enterprise technology companies including AWS, Oracle, Microsoft, VMware and Pivotal all join the Cloud Native Computing Foundation (CNCF), the professional organization behind the open source project. This was a signal that Kubernetes was becoming a standard of sorts for container orchestration.

Surely these big companies would have preferred (and tried) to control the orchestration layer themselves, but they soon found that their customers preferred to use Kubernetes and they had little choice, but to follow the clear trend that was developing around the project.

The second piece that has to come together for an open source community to flourish is that a significant group of developers have to accept it and start building stuff on top of the platform — and Kubernetes got that too. Consider that according to CNCF, a total of 400 projects have been developed on the platform by 771 developers contributing over 19,000 commits since the launch of Kubernetes 1.0 in 2015. Since last August, the last date for which the CNCF has numbers, developer contributions had increased by 385 percent. That’s a ton of momentum.

Cue the investors

When you have those two ingredients in place — developers and large vendors — you can begin to gain velocity. As more companies and more developers come, the community continues to grow, and that’s what we’ve been seeing with Kubernetes.

As that happens, it typically doesn’t take long for investors to take notice, and according to CNCF, there has been over $4 billion in investments so far in cloud native companies — this from a project that didn’t even exist that long ago.

That investment has taken the form of venture capital funding startups trying to build something on top of Kubernetes, and we’ve seen some big raises. Earlier this month, Hasura raised a $1.6M seed round for a packaged version Kubernetes designed specially to meet the needs of developers. Just last week, Upbound, a new startup from Seattle got $9 million in its Series A round to help manage multi-cluster and multi-cloud environments in a standard (cloud-native) way. A little further up the maturity curve, Heptio has raised over $33 million with its most recent round being a $25 million Series B last September. Finally, there is CoreOS, which raised almost $50 million before being sold to Red Hat for $250 million in January.

CoreOS wasn’t alone by any means as we’ve seen other exits coming over the last year or two with organizations scooping up cloud native startups. In particular, when you see the largest organizations like Microsoft, Oracle and Red Hat buying relatively young startups, they are often looking for talent, customers and products to get up to speed more quickly in a growing technology area like Kubernetes.

Growing an economic ecosystem

Kubernetes has grown and developed into an economic powerhouse in short period of time as dozens of side projects have developed around it, creating even more opportunity for companies of all sizes to build products and services to meet an ever-growing set of needs in a virtuous cycle of investment, innovation and economic activity.

If this project continues to grow, chances are it will gain even more investment as companies continue to flow toward containers and Kubernetes, and even more startups develop to help create products to meet new needs as a result.

Last week at KubeCon and CloudNativeCon in Copenhagen, we saw an open source community coming together, full of vim and vigor and radiating positive energy as it recognized its growing clout in the enterprise world. Kubernetes, which came out of Google just a few years ago, has gained acceptance and popularity astonishingly rapidly — and that has raised both a sense of possibility and a boat load of questions.

At this year’s European version of the conference, the community seemed to be coming to grips with that rapid growth as large corporate organizations like Red Hat, IBM, Google, AWS and VMware all came together with developers and startups trying to figure out exactly what they had here with this new thing they found.

The project has been gaining acceptance as the defacto container orchestration tool, and as that happened, it was no longer about simply getting a project off the ground and proving that it could work in production. It now required a greater level of tooling and maturity that previously wasn’t necessary because it was simply too soon.

As this has happened, the various members who make up this growing group of users, need to figure out, mostly on the fly, how to make it all work when it is no longer just a couple of developers and a laptop. There are now big boy and big girl implementations and they require a new level of sophistication to make them work.

Against this backdrop, we saw a project that appeared to be at an inflection point. Much like a startup that realizes it actually achieved the product-market fit it had hypothesized, the Kubernetes community has to figure out how to take this to the next level — and that reality presents some serious challenges and enormous opportunities.

A community in transition

The Kubernetes project falls under the auspices of the Cloud Native Computing Foundation (or CNCF for short). Consider that at the opening keynote, CNCF director Dan Kohn was brimming with enthusiasm, proudly rattling off numbers to a packed audience, showing the enormous growth of the project.

If you wanted proof of Kubernetes’ (and by extension cloud native computing’s) rapid ascension, consider that the attendance at KubeCon in Copenhagen last week numbered 4300 registered participants, triple the attendance in Berlin just last year.

The hotel and conference center were buzzing with conversation. Every corner and hallway, every bar stool in the hotel’s open lobby bar, at breakfast in the large breakfast room, by the many coffee machines scattered throughout the venue, and even throughout the city, people chatted, debated and discussed Kubernetes and the energy was palpable.

David Aronchick, who now runs the open source Kubeflow Kubernetes machine learning project at Google, was running Kubernetes in the early days (way back in 2015) and he was certainly surprised to see how big it has become in such a short time.

“I couldn’t have predicted it would be like this. I joined in January, 2015 and took on project management for Google Kubernetes. I was stunned at the pent up demand for this kind of thing,” he said.

Growing up

Yet there was great demand, and with each leap forward and each new level of maturity came a new set of problems to solve, which in turn has created opportunities for new services and startups to fill in the many gaps. As Aparna Sinha, who is the Kubernetes group product manager at Google, said in her conference keynote, enterprise companies want some level of certainty that earlier adopters were willing to forego to take a plunge into the new and exciting world of containers.

As she pointed out, for others to be pulled along and for this to truly reach another level of adoption, it’s going to require some enterprise-level features and that includes security, a higher level of application tooling and a better overall application development experience. All these types of features are coming, whether from Google or from the myriad of service providers who have popped up around the project to make it easier to build, deliver and manage Kubernetes applications.

Sinha says that one of the reasons the project has been able to take off as quickly as it has, is that its roots lie in a container orchestration tool called Borg, which the company has been using internally for years. While that evolved into what we know today as Kubernetes, it certainly required some significant repackaging to work outside of Google. Yet that early refinement at Google gave it an enormous head start over an average open source project — which could account for its meteoric rise.

“When you take something so well established and proven in a global environment like Google and put it out there, it’s not just like any open source project invented from scratch when there isn’t much known and things are being developed in real time,” she said.

For every action

One thing everyone seemed to recognize at KubeCon was that in spite of the head start and early successes, there remains much work to be done, many issues to resolve. The companies using it today mostly still fall under the early adopter moniker. This remains true even though there are some full blown enterprise implementations like CERN, the European physics organization, which has spun up 210 Kubernetes clusters or JD.com, the Chinese Internet shopping giant, which has 20K servers running Kubernetes with the largest cluster consisting of over 5000 servers. Still, it’s fair to say that most companies aren’t that far along yet.

But the strength of an enthusiastic open source community like Kubernetes and cloud native computing in general, means that there are companies, some new and some established, trying to solve these problems, and the multitude of new ones that seem to pop up with each new milestone and each solved issue.

As Abby Kearns, who runs another open source project, the Cloud Foundry Foundation, put it in her keynote, part of the beauty of open source is all those eyeballs on it to solve the scads of problems that are inevitably going to pop up as projects expand beyond their initial scope.

“Open source gives us the opportunity to do things we could never do on our own. Diversity of thought and participation is what makes open source so powerful and so innovative,” she said.

It’s worth noting that several speakers pointed out that diversity of thought also required actual diversity of membership to truly expand ideas to other ways of thinking and other life experiences. That too remains a challenge, as it does in technology and society at large.

In spite of this, Kubernetes has grown and developed rapidly, while benefiting from a community which so enthusiastically supports it. The challenge ahead is to take that early enthusiasm and translate it into more actual business use cases. That is the inflection point where the project finds itself, and the question is will it be able to take that next step toward broader adoption or reach a peak and fall back.