KubeCon event report (2 of 2)

(This is the continuation from the previous post.)

New Era of Open Source

In the 2010s, open-source was driven mainly by startups as a strategy to build a viable business, which led to companies like Red Hat, CloudBees, Elastic, & Mongo.

It was also painfully clear in KubeCon that the forces that shaped the landscape of open-source has changed completely. Today, open-source is primarily driven by unicorn end user companies who needed to solve problems that vendors didn’t even knew existed. That’s where innovations are. And they don’t need to make any money from those projects unlike startups. Substantive projects highlighted in KubeCon were from companies like Uber, Lyft, and Spotify. Sessions by engineers from those companies were packed. Everyone wants to be like them, no wonder their projects are popular.

The other kind of open-source projects are from vendors. They are either Hail Mary gamble moves out of desperation (e.g., IBM’s razee), or torpedos designed to drag down the market leaders through indirection or commoditization.

I still saw plenty of startups who are trying to repeat the single vendor open-source model of the 2000s, but the going will be really tough for them. First, they have to find problems that aren’t already solved by unicorn end users. Then they have to cross the sea where 3 cloud titans are shooting torpedos to each other and random Hail Mary are shot into from the sidelines. Really the only sensible move is SaaS.KubeCon escalator

3 Cloud Titans

Speaking of 3 cloud titans, Microsoft won my respect once again with their SMI announcement. Along with KEDA, together they clearly show the Microsoft OSS strategy of making sure innovations in the Kubernetes ecosystem get contained behind the common portable interface/spec. Then Microsoft can “embrace and extend” or build their proprietary implementation nicely integrated with the rest of Azure. This is the exact same play IBM, BEA, Oracle, etc. have done with JavaEE. Use JCP to create portable APIs, let Sun implement the free tier, and focus on building the for-pay value-add tier. The move makes sense, and it works because end users share the same interest.

I didn’t see Amazon, but I assume they are making sure that EKS is good and otherwise doing the bare minimum in the Kubernetes ecosystem. That way, they can focus on building up their own services, like Microsoft.

What made me wondering is Google’s plan. Maybe it’s just that they didn’t get the air time they deserve in KubeCon, but it felt like they are going down the route Sun did. They seem to be busy building awesome commons that benefits everyone, which wins tremendous developer love, but no $$$. I’m sure GKE is the best managed Kubernetes service right now, but it is a thin value layer that requires constant upkeep.

It’s a tragedy that it takes a truly selfless act of engineering brilliance to create a great developer platform, like Sun and Google, yet the inventing company itself never financially gains from the innovation. But then maybe that’s why they gain so much respect and fame. I truly love those companies.KubeCon mosaic

End Users Need Industry Standard

It was also very clear that app developers are overwhelmed with choices and chaos of the ecosystem. It was proclaimed, as if that’s what people want, that “Kubernetes is a platform to create platforms.” Well, most people there are writing apps, not creating a platform. The last thing they want is to pick & choose their own cloud native platform out of 100+ CNCF ecosystem software just so that they can write apps. I wonder who solves this problem for them. That gotta be the biggest opportunity.

I noticed that quite a few consultancy shops were there posing as Kubernetes experts, claiming to solve that problem on behalf of the customers, but I question how much they know themselves.

Jenkins X is clearly in the right spot, with this regard. Its code and governance are growing at a breakneck speed thanks to the Jenkins X community and the CDF, but the market is growing faster.

My money is on Microsoft, Red Hat, and end user companies to come up with JavaEE/WS-I/WHATWG-esque “standard” body that defines a set of the common APIs, like SMI and KEDA. This will include the space Jenkins X is in, so it will have a role to play, too. That way, end users get to avoid lock-in, cloud providers get to provide implementations specific to their cloud and compete with value-add. It will be like the LAMP stack of the cloud native.Kubernetes 5th anniversary


KubeCon is worth a visit. History is repeating itself. Open-source is thriving, though the rules have changed.

KubeCon event report (1 of 2)

KubeCon / CloudNativeCon in Barcelona was amazing. I’ve been hearing great things from my colleagues who have been to past KubeCon, but hearing and seeing are two entirely different experiences.


The energy was clearly in the air, reflecting the amount of interest, excitement, innovation, and investment in the cloud native space.

The number of projects that were represented there in some shape or form were staggering. Endless list of “meet the maintainer of the XYZ project,” “introduction to the XYZ project,” or “deep dive into the XYZ project.”

So many people were there, so many talks were offered in parallel. Everyone was trying to absorb what’s going on, and there is simply no way anyone can keep up. Even at lunch tables, conversations were “what interesting things did you see?”

As if that wasn’t enough, at least two significant new projects were launched and announced during keynotes. There must have been 100+ vendors in the exhibit space. Dozen+ co-located events. And numerous private small meetings.

Nobody knows exactly what’s happening, but everybody knows something significant is happening. It’s basically a giant week-long festival for geeks.

KubeCon show floor


Just as clear as the energy was how incredibly chaotic the whole scene is. How can you expect otherwise? CNCF has no single command-n-control structure where the entire effort gets planned and coordinated. It’s a group of entities with conflicting interest, acting and reacting to each other.

This chaos was perhaps the most visible in keynotes. Take the Day 2 keynote as an example. First, the host from VMware does his opening and declares that the theme of the keynote is “Kubernetes is a platform for creating platforms.”

Then an SRE from Spotify comes on the stage and proceeds to tell a great story of how they can recover from a major Ops mistake without any visible disruption to customers, except Kubernetes didn’t play any positive role in that story, and the story delivery was so clumsy I couldn’t help but wonder how magical the experience would have been if the speaker did a bit more practice.

The next one on the stage was a VP from Oracle Cloud, and he proceeds to present a strange mix of the ecosystem praise, followed by a marketing video of an Oracle customer (CERN) praising how WebLogic is awesome on Kubernetes. Wait, CERN guys had their own keynote yesterday and there was no mention of WebLogic. And WebLogic on Kubernetes, well, let’s just say that story felt weak. This short Oracle keynote was followed by another end user company, who explained their quite ordinary run-of-the-mill cloud transformation journey but in a beautiful presentation by an eloquent speech. Basically, the complete opposite of the Spotify keynote.

KubeCon keynote

There’s no story arc that connects those 3 segments. None of them have anything to do with the supposed theme of the keynote “Kubernetes is a platform for creating platforms.” There was probably no coordination and not even a concerted effort to push presenters to practice. Just about the only upside is that so many competing vendors working together nicely enough sends a very powerful message.

Compare that with, say, Microsoft Build keynote, and the contrast cannot be starker. That also had quite a few segments run by other people, but they were designed to tell a consistent story to drive a point. Or compare that with Dockercon, where even ordinary session speakers are asked to do dry-run in front of the engineers of the event team and to iterate based on the feedback.

What Creates Ecosystem?

But as I was walking out of the keynote somewhat frustrated and trying to make sense of what I just saw, it dawned on me that I was looking at it completely wrongly.

Sure, Microsoft Build has shown off a well produced keynote and the breadth and depth of what Microsoft does. But that’s not where the future is getting created; It’s created in this CNCF ecosystem. In fact, Mighty Microsoft and even Amazon are forced to play along with this. As RedMonk says, developers are the kingmakers.

And if I look at it as a developer, it’s obvious why KubeCon is the carnival and why Microsoft Build isn’t. KubeCon sells the aspirational lifestyle of devs and ops. We all want to work in a blameless continuous learning culture, and to survive a data center loss without any customer impact like Netflix or Spotify. And those customer stories tell you such lifestyles are not your imagination. You could be them! Except you can’t really. It’s like Nike and “just do it.”

Then KubeCon shows you the vast boom town under construction. The city hall at the center is beautiful and rock solid, but the church over there is only half built and not roofed yet. Where the market is supposed to go up is currently just a sprawl of tents. Three police stations are being built by 4 groups, but nobody is building a fire station. The Kube city has no mayor and every volunteer group is run totally differently. If you are a developer, this is legitimately amazing. There’s so many ways to participate in this grand construction project. Everyone is screaming for more hands. Anyone can instantly spot 10 things that need to be worked on. The whole scene is screaming “opportunities.”

OTOH, the Microsoft city is run by the party, like China. Smart people are in charge, and they have a great plan, but there’s no election. They have a beautiful story of how the Microsoft city lets its residents focus on building your apps that will make a real world impact. The city is still a long way from what the scale model makes you believe, but it’s already quite livable and convenient. They even let you participate in some construction activities here and there. But for a developer, this place feels suffocating. You are a consumer in this city.

KubeCon Party

I think there’s something important to learn here for product managers and marketers who are trying to attract developers. These people tend to value a beautiful vision, and coherent messages, and incorrectly believe that developers would enjoy them too. Yet I think what attracts developers is the opposite. Every end user companies have a certain number of engineers who feel a lot more passionate about how they build, as opposed to what they build. Those people come to the Kube city.

As Peter Drucker said, “culture eats strategy for breakfast.” The Kube City eats the Microsoft city for breakfast.

(Continues to the next post)

Microsoft Build event report

This is my event report from Microsoft Build last week. More pictures of the event is here. The last time I’ve been to a flagship Microsoft event is more than 10 years ago, where we showed Sun hardware that was certified for Windows Server and I was handing out Sun T-shirts. Before I joined Sun in 2001, I was a developer fully immersed in the Microsoft ecosystem, so I always had a soft spot in my heart for Microsoft.

Obviously a lot has changed, but there are many moments that reminded me that what made Microsoft great back then are still alive and kicking.

As you can see, I loved the show, and I came back fully impressed with what Microsoft is up to.


Depth & Breadth

What struck me on the first day is the depth and the breadth of technology that Microsoft has in its arsenal. This is in your face in so many ways, from the size of the exhibit space to the list of sessions so long it takes forever to scroll.

Microsoft covers everything from …:

  • Established “boring” products everyone need & use today. Compute & storage on cloud, developer tools, Windows, Office, Xbox, …
  • Nextgen developer infrastructure that look solidly production ready, like managed Kubernetes service, serverless, Cosmos DB, monitoring & alerting, plethora of data services covering ingestion to storage to analysis, business intelligence, machine learning, …
  • More research-y stuff like vision/language AI, holo-lens, industrial automation AI, …

And then on some of the key parts of that stack, they have quite a “breadth,” too! Doing one IDE is hard enough, now they have three. Linux & Windows. C#, Python, JavaScript, and more. Intel & ARM. That they have enough engineers to cover them all and still turn profit is almost unbelievable.


This is one of those “Microsoft DNA,” I think. So many things they do leverage each other, in such a way that once you get hooked into their ecosystem, it starts to make more and more sense to use the rest of the Microsoft stuff. Whether you see that a good thing or a bad thing, I’m not sure.

As a case in point, it felt like every developer platform from robotics to gaming, from serverless to ML, have IDE and Azure DevOps integration. “Run this command and we’ll generate your CI/CD pipeline” was a common theme. Another example is their ML development platform leveraging their BI platform for visualization.

Or when you use their PaaS , monitoring is integrated out of the box. It’s a far cry from deploying Kubernetes, install Datadog agents, and wire up Datadog with PagerDuty.

Microsoft has been great to Azure ISVs like CloudBees in the past few years, but seeing this “everything is fully integrated” DNA, I understood why — it’s the “land & expand” play. They are so confident with their ability to “expand” to gradually increases their share of the IT spend of a customer, they don’t mind to “land” with ISVs to meet customers where they are today.

Hybrid Cloud

One key misunderstanding I fixed in this trip is what Microsoft means with “private cloud” or “hybrid cloud.” I used to think this term was coined by vendors like VMware/Oracle around tech like OpenStack who wanted their customers to believe you can have something comparable to public cloud in your own data center. That is a complete hallucination, so I dismissed the idea of hybrid cloud, too.

I must have missed the memo, but the industry (certainly Microsoft) doesn’t use the term that way anymore. It’s more analogous to Mac and iPhone working well together, or Windows desktop and Windows servers. Different things that together covers different parts of a spectrum, with consistency where possible. And Microsoft is pushing this lineup even further down to the smaller scale by adding micro-controller to Azure brand. That makes sense.

I bet, however, that enough customers are still living in the hallucination, and Microsoft seems to be benefiting from this. Those customers just want a better data center control plane, and they assume that the productivity gain from that is sufficient. They are wrong on that last point, but by then Microsoft has “landed.”

Combined with Microsoft’s enterprise salesforce and customer relationship, I think this is a convincing story for Microsoft to win. I’m curious how well AWS is meeting this challenge. From where I see, it looks to be a no match.


Developer Eyeballs

Another Microsoft DNA that is alive and kicking is their obsession to developer eyeballs. They simply don’t let other companies set up a toll booth between themselves and developers. Compare that with companies like Google, Amazon, and Oracle.

They have 2 IDEs (legacy Visual Studio and Visual Studio code) that are AFAIK of completely different codebase. They are both very popular and still adding tons of features. Then no top of that, in this event, they announced a web IDE.

On top of all that, they have Azure DevOps and GitHub to complete the picture. That’s how obsessed they are. No wonder Microsoft paid top price for GitHub.

I already talked about how so many of what they do leverage these IDEs and developer services. AWS should be really nervous about the fact that people are developing with VSCode to deploy to AWS.


There’s so much more to write about, but this post is already getting too long.

Being an old-timer and ex-Sun, I can’t help but feel a deja-vu of the Microsoft vs Java war to some extent. Microsoft is still leading with the value of more integrated products that work better together (used to be Windows, Exchange, & SharePoint, now Azure), backed by enterprise salesforce and relationship building & nurturing. A tried & tested winning formula for decision makers.

Meanwhile, developers and disrupters are building loosely connected OSS projects on top of a platform they control (used to be Linux, now Kubernetes) and they are happy to wire those on their own. Presumably, the difference in how better the technology is compared to the fully integrated solution make up for the cost of wiring them on your own.

But there are difference in this round, too. Now those two worlds aren’t mutually exclusive. The latter world can happily run on Azure.

As so many people have already written, I think Microsoft is being pretty successful at the moment. But to me, the question is why Microsoft is not even more successful.


Dockercon 2019

I was at the Dockercon last week. TL;DR is that +1 for the event team, their OSS strategy, and ARM, but -1 for the CTO’s stage performance, and their product value.


Docker is clearly focused on developer experience (DX) that hides rapidly evolving “implementation details” (think Kubernetes, Helm, etc.) As the OSS strategy, that made sense because Docker is already in every developer’s laptop. The problem is that they overly focus on what devs do from their laptops, ignoring (or unaware of?) the reality that much of the software development is around making those things happen automatically at the right time. For example, one of the demos was developers making a change on their laptop and pushing that to production, but in the real world, nobody deploys to production from their laptops. Instead, you design a flow around environments and branches. Something Jenkins X gets right.

On the exhibit floor, it was clear the money is in operations (security, monitoring, & policy.) Curiously, Docker products don’t seem to do any of those. In fact, I came out of two keynotes feeling entirely unclear what their product values are. It was almost like they forgot to talk about products completely. They clearly sell support, they seem to sell “simplicity” (but isn’t that the top-of-the-funnel OSS thing? since when enterprise is simple?), and there was one mention of “SAML authentication,” but what else? IMHO, that was a fail on their part.


The most brilliant strategic move during the whole show was by ARM. Through Docker, they made it drastically easy for developers to build equivalent images simultaneously for amd64 and arm64. They worked with Amazon that arm64 is available cheaply on AWS (50% cost reduction was claimed.) The story they are working toward is “15 minutes will save you 50% on your EC2” and I think that’s very compelling. On top of that, they seem to be working toward bringing container-based app development to “edge computing,” aka their home turf. If the single development & deployment paradigm can span everything from embedded devices to servers, I think that’d be amazing. Docker on embedded devices would be a tremendous boost to the sorry state of typical embedded app development.

Two keynotes were well produced and demo were well scripted. IOW, their event team and the product team did a great job. Demo wasn’t just a proof that something works, it told a story. But two key speakers on the stage were a little disappointing. The CEO was OK but clearly reading from a teleprompter. The CTO was worse — he was lacking energy and conviction, at times apologetic, and his interaction with demo staff lacked chemistry. To me, it’s a sign that they didn’t put enough effort into practicing. I’m pretty sure the CTO is smart, thoughtful, and quiet guy; it’s just that that combo doesn’t make a great keynote speaker by default, so he has to make up for that by practicing more. That’s something I have to be careful myself.

Lastly, as a speaker, I was impressed by the touch that the Docker team provided for speakers. They reviewed outline with you, made sure you prepare slides early on, put you through dry-runs, and provided useful feedback. That must have taken tons of efforts. Hats off to the team.