Oct
07
2020
--

Kong launches Kong Konnect, its cloud-native connectivity platform

At its (virtual) Kong Summit 2020, API platform Kong today announced the launch of Kong Konnect, its managed end-to-end cloud-native connectivity platform. The idea here is to give businesses a single service that allows them to manage the connectivity between their APIs and microservices and help developers and operators manage their workflows across Kong’s API Gateway, Kubernetes Ingress and Kong Service Mesh runtimes.

“It’s a universal control plane delivery cloud that’s consumption-based, where you can manage and orchestrate API gateway runtime, service mesh runtime, and Kubernetes Ingress controller runtime — and even Insomnia for design — all from one platform,” Kong CEO and co-founder Augusto “Aghi” Marietti told me.

The new service is now in private beta and will become generally available in early 2021.

Image Credits: Kong

At the core of the platform is Kong’s new so-called ServiceHub, which provides that single pane of glass for managing a company’s services across the organization (and make them accessible across teams, too).

As Marietti noted, organizations can choose which runtime they want to use and purchase only those capabilities of the service that they currently need. The platform also includes built-in monitoring tools and supports any cloud, Kubernetes provider or on-premises environment, as long as they are Kubernetes-based.

The idea here, too, is to make all these tools accessible to developers and not just architects and operators. “I think that’s a key advantage, too,” Marietti said. “We are lowering the barrier by making a connectivity technology easier to be used by the 50 million developers — not just by the architects that were doing big grand plans at a large company.”

To do this, Konnect will be available as a self-service platform, reducing the friction of adopting the service.

Image Credits: Kong

This is also part of the company’s grander plan to go beyond its core API management services. Those services aren’t going away, but they are now part of the larger Kong platform. With its open-source Kong API Gateway, the company built the pathway to get to this point, but that’s a stable product now and it’s now clearly expanding beyond that with this cloud connectivity play that takes the company’s existing runtimes and combines them to provide a more comprehensive service.

“We have upgraded the vision of really becoming an end-to-end cloud connectivity company,” Marietti said. “Whether that’s API management or Kubernetes Ingress, […] or Kuma Service Mesh. It’s about connectivity problems. And so the company uplifted that solution to the enterprise.”

 

Aug
05
2020
--

Microsoft launches Open Service Mesh

Microsoft today announced the launch of a new open-source service mesh based on the Envoy proxy. The Open Service Mesh is meant to be a reference implementation of the Service Mesh Interface (SMI) spec, a standard interface for service meshes on Kubernetes that has the backing of most of the players in this ecosystem.

The company plans to donate Open Service Mesh to the Cloud Native Computing Foundation (CNCF) to ensure that it is community-led and has open governance.

“SMI is really resonating with folks and so we really thought that there was room in the ecosystem for a reference implementation of SMI where the mesh technology was first and foremost implementing those SMI APIs and making it the best possible SMI experience for customers,” Microsoft director of partner management for Azure Compute (and CNCF board member) Gabe Monroy told me.

Image Credits: Microsoft

He also added that, because SMI provides the lowest common denominator API design, Open Service Mesh gives users the ability to “bail out” to raw Envoy if they need some more advanced features. This “no cliffs” design, Monroy noted, is core to the philosophy behind Open Service Mesh.

As for its feature set, SMI handles all of the standard service mesh features you’d expect, including securing communications between services using mTLS, managing access control policies, service monitoring and more.

Image Credits: Microsoft

There are plenty of other service mesh technologies in the market today, though. So why would Microsoft launch this?

“What our customers have been telling us is that solutions that are out there today, Istio being a good example, are extremely complex,” he said. “It’s not just me saying this. We see the data in the AKS support queue of customers who are trying to use this stuff — and they’re struggling right here. This is just hard technology to use, hard technology to build at scale. And so the solutions that were out there all had something that wasn’t quite right and we really felt like something lighter weight and something with more of an SMI focus was what was going to hit the sweet spot for the customers that are dabbling in this technology today.”

Monroy also noted that Open Service Mesh can sit alongside other solutions like Linkerd, for example.

A lot of pundits expected Google to also donate its Istio service mesh to the CNCF. That move didn’t materialize. “It’s funny. A lot of people are very focused on the governance aspect of this,” he said. “I think when people over-focus on that, you lose sight of how are customers doing with this technology. And the truth is that customers are not having a great time with Istio in the wild today. I think even folks who are deep in that community will acknowledge that and that’s really the reason why we’re not interested in contributing to that ecosystem at the moment.”

May
23
2019
--

Takeaways from KubeCon; the latest on Kubernetes and cloud native development

Extra Crunch offers members the opportunity to tune into conference calls led and moderated by the TechCrunch writers you read every day. This week, TechCrunch’s Frederic Lardinois and Ron Miller discuss major announcements that came out of the Linux Foundation’s European KubeCon/CloudNativeCon conference and discuss the future of Kubernetes and cloud-native technologies.

Nearly doubling in size year-over-year, this year’s KubeCon conference brought big news and big players, with major announcements coming from some of the world’s largest software vendors including Google, AWS, Microsoft, Red Hat, and more. Frederic and Ron discuss how the Kubernetes project grew to such significant scale and which new initiatives in cloud-native development show the most promise from both a developer and enterprise perspective.

“This ecosystem starts sprawling, and we’ve got everything from security companies to service mesh companies to storage companies. Everybody is here. The whole hall is full of them. Sometimes it’s hard to distinguish between them because there are so many competing start-ups at this point.

I’m pretty sure we’re going to see a consolidation in the next six months or so where some of the bigger players, maybe Oracle, maybe VMware, will start buying some of these smaller companies. And I’m sure the show floor will look quite different about a year from now. All the big guys are here because they’re all trying to figure out what’s next.”

Frederic and Ron also dive deeper into the startup ecosystem rapidly developing around Kubernetes and other cloud-native technologies and offer their take on what areas of opportunity may prove to be most promising for new startups and founders down the road.

For access to the full transcription and the call audio, and for the opportunity to participate in future conference calls, become a member of Extra Crunch. Learn more and try it for free. 

Nov
15
2018
--

Uber joins Linux Foundation, cementing commitment to open-source tools

Uber announced today at the 2018 Uber Open Summit that it was joining the Linux Foundation as a Gold Member, making a firm commitment to using and contributing to open-source tools.

Uber CTO Thuan Pham sees the Linux Foundation as a place for companies like his to nurture and develop open-source projects. “Open source technology is the backbone of many of Uber’s core services and as we continue to mature, these solutions will become ever more important,” he said in a blog post announcing the partnership.

What’s surprising is not that they joined, but that it took so long. Uber has been long known for making use of open source in its core tools, working on over 320 open-source projects and repositories from 1,500 contributors involving over 70,000 commits, according to data provided by the company.

“Uber has made significant investments in shared software development and community collaboration through open source over the years, including contributing the popular open-source project Jaeger, a distributed tracing system, to the Linux Foundation’s Cloud Native Computing Foundation in 2017,” an Uber spokesperson told TechCrunch.

Linux Foundation Executive Director Jim Zemlin was certainly happy to welcome Uber into the fold. “Their expertise will be instrumental for our projects as we continue to advance open solutions for cloud native technologies, deep learning, data visualization and other technologies that are critical to businesses today,” Zemlin said in a statement.

The Linux Foundation is an umbrella group supporting myriad open-source projects and providing an organizational structure for companies like Uber to contribute and maintain open-source projects. It houses sub-organizations like the Cloud Native Computing Foundation, Cloud Foundry Foundation, The Hyperledger Foundation and the Linux operating system, among others.

These open-source projects provide a base on top of which contributing companies and the community of developers can add value if they wish and build a business. Others like Uber, which uses these technologies to fuel their backend systems, won’t sell additional services, but can capitalize on the openness to help fuel their own requirements in the future, while also acting as a contributor to give as well as take.

Aug
09
2018
--

Prometheus monitoring tool joins Kubernetes as CNCF’s latest ‘graduated’ project

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.

Jun
06
2018
--

Four years after its release, Kubernetes has come a long way

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.

Photo: Cloud Native Computing Foudation

“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.

Photo: Swapnil Bhartiya on Flickr. Used under CC by SA 2.0 license

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 AWSOracleMicrosoftVMware and Pivotal all joined. They came together with Red Hat, Intel, IBM Cisco and others who were already members.

Cloud Native Computing Foundation Platinum 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.”

Jun
01
2018
--

Helm moves out of Kubernetes’ shadow to become stand-alone project

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.

May
07
2018
--

As Kubernetes grows, a startup ecosystem develops in its wake

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 AWSOracleMicrosoftVMware 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.

Photo: Georgijevic on Getty Images

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.

Photo: Fitria Ramli / EyeEm on Getty Images.

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.

Cloud Native Computing Foundation projects. Photo: Cloud Native Computing Foundation

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.

May
06
2018
--

Kubernetes stands at an important inflection point

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.

Photo: Ron Miller

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.

Photo: Cloud Native Computing Foundation

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.

Photo: Ron Miller

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.

Dec
18
2017
--

As Kubernetes surged in popularity in 2017, it created a vibrant ecosystem

 For a technology that the average person has probably never heard of, Kubernetes surged in popularity in 2017 with a particular group of IT pros who are working with container technology. Kubernetes is the orchestration engine that underlies how operations staff deploy and manage containers at scale. (For the low-down on containers, check out this article.) In plain English, that means that as… Read More

Powered by WordPress | Theme: Aeros 2.0 by TheBuckmaker.com