This originally debuted on the Amalgam Insights blog. An unfortunate side effect of being an industry analyst is that it is easy to become jaded. There is a tendency to fall back into stereotypes about technology and companies. Add to this nearly 35 years in computer technology and it would surprise no one to hear an analyst say, “Been there, done that, got the t-shirt.” Some companies elicit this reaction more than others. Older tech companies with roots in the 80’s or earlier tend to get in a rut and focus on incremental change (so as not to annoy their established customer base) instead of the exciting new trends. This
This was also published on Amalgam Insights. Kubernetes has, in the span of a few short years, become the de facto orchestration software for containers. As few as two years ago there were more than a half-dozen orchestration tools vying for the top spot and now there is only Kubernetes. Even the Linux Foundation’s other orchestrator project, CloudFoundry Diego, is starting to give way to Kubernetes. Part of the success of Kubernetes can be attributed to the support of Google. Kubernetes emerged out of Google and they have continued to 0the project even as it fell under the auspices of the Linux Foundation’s CNCF. On August 29, 2018, Google announced
This was published previously on the Amalgam Insights site. For much of the past 30 years, Microsoft was famous for its hostility toward Free and Open Source Software (FOSS). They reserved special disdain for Linux, the Unix-like operating system that first emerged in the 1990s. Linux arrived on the scene just as Microsoft was beginning to batter Unix with Windows NT. The Microsoft leadership at the time, especially Steve Ballmer, viewed Linux as an existential threat. They approached Linux with an “us versus them” mentality that was, at times, rabid. It’s not news that times have changed and Microsoft with it. Instead of looking to destroy Linux and FOSS,
This was originally published on Amalgam Insights. Companies struggle with all types of compliance issues. Failure to comply with government regulations, such as Dodd-Frank, EPA or HIPPA, is a significant business risk for many companies. Internally mandated compliance also represents problems as well. Security and cost control policies are just as vital as other forms of regulation since they protect the company from reputational, financial, the operational risks. IT helps to manage compliance risks in two ways. First, by deploying systems that detect and assist the company in complying with risk. For example, an analytics system designed to discover Dodd-Frank violations in a bank is a way for IT
This was also released under a slightly different name on Amalgam Insights. Development organization continue to feel increasing pressure to produce better code more quickly. To help accomplish that faster-better philosophy, a number of methodologies have emerged that that help organizations quickly merge individual code, test it, and deploy to production. While DevOps is actually a management methodology, it is predicated on an integrated pipeline that drives code from development to production deployment smoothly. In order to achieve these goals, companies have adopted continuous integration and continuous deployment (CI/CD) tool sets. These tools, from companies such as Atlassian and GitLab, help developers to merge individual code into the deployable code
This originally debuted on the Amalgam Insights blog.
An unfortunate side effect of being an industry analyst is that it is easy to become jaded. There is a tendency to fall back into stereotypes about technology and companies. Add to this nearly 35 years in computer technology and it would surprise no one to hear an analyst say, “Been there, done that, got the t-shirt.” Some companies elicit this reaction more than others. Older tech companies with roots in the 80’s or earlier tend to get in a rut and focus on incremental change (so as not to annoy their established customer base) instead of the exciting new trends. This makes it hard to be impressed by them.
Oracle is one of those companies. It has a reputation for being behind the market (cloud anyone?) and as proprietary as can be. Oracle has also had a difficult time with developers. The controversy over Java APIs (which is really a big company spat with Google) hasn’t helped that relationship. There are still hard feelings left over from the acquisition of Sun Microsystems (a computer geek favorite) and MySQL that have left many innovative developers looking anywhere but Big Red. Oracle’s advocacy of Free and Open Source Software (FOSS) has been at best indifferent. When the FOSS community comes together, one expects to see Red Hat, Google, and even Microsoft and IBM but never Oracle.
Which is why my recent conversation with Bob Quillin of Oracle came as a complete surprise. It was like a bucket of cold water on a hot day, both shocking and at the same time, refreshing.
Now, it’s important to get some context right up front. Bob came to Oracle via an acquisition, StackEngine. So, he and his team’s DNA is more FOSS than Big Red. And, like an infusion of new DNA, the StackEngine crew has succeeded in changing Oracle on some level. They have launched the Oracle Kubernetes and Registry Services which brings a Container Engine, Kubernetes, and a Docker V2 compatible registry to the Oracle Cloud Service. That’s a lot of open source for Oracle.
In addition, Bob talked about how they were helping Oracle customers to move to a Cloud Native strategy. Cloud Native almost always means embracing FOSS since so many components are FOSS. Add to the mixture a move into serverless with Fn. Fn is also an open source project (Apache 2.0 licensed) but one that originated in Oracle. That’s not to say there aren’t other Oracle open source projects (Graal for example) but they aren’t at the very edge of computing like Fn. In this part of the FOSS world Oracle is leading not following. Oracle even plans to have a presence at Kubecon+CloudNativeCon 2018 in Seattle this December, an open source-oriented conference run by The Linux Foundation, where they will be a Platinum Sponsor. In the past this would be almost inconceivable.
The big question is how will this affect the rest of Oracle? Will this be a side project for Oracle or will they rewrite the Oracle DNA in the same way that Microsoft has done? Can they find that balance between the legacy business, which is based on high-priced, proprietary software – the software that is paying the bills right now – and community run, open source world that is shaping the future of IT? Only time will tell but there will be a big payoff to IT if it happens. Say what you will about Oracle, they know how to do enterprise software. Security, performance, and operating at scale are Oracle’s strengths. They are a big reason their customers keep buying from them instead of an open source startup or even AWS. An infusion of that type of knowledge into the FOSS community would help to overcome many of the downsides that IT experiences when trying to implement open source software in large enterprise production environments.
Was I surprised? To say the least. I’ve never had a conversation like this with Oracle. Am I hopeful? A bit. There are forces within companies like Oracle that can crush an initiative like this. As the market continues to shift in the direction of microservices, containers, and open source in general, Oracle risks becoming too out of step with the current generation of developers. Even if FOSS doesn’t directly move the needle on Oracle revenue, it can have a profound effect on how Oracle is viewed by the developer community. If the attitude of people like Bob Quillin becomes persuasive, then younger developers may start to see Oracle as more than just their father’s software company. In my opinion, the future of Oracle may depend on that change in perception.
This was also published on Amalgam Insights.
Kubernetes has, in the span of a few short years, become the de facto orchestration software for containers. As few as two years ago there were more than a half-dozen orchestration tools vying for the top spot and now there is only Kubernetes. Even the Linux Foundation’s other orchestrator project, CloudFoundry Diego, is starting to give way to Kubernetes. Part of the success of Kubernetes can be attributed to the support of Google. Kubernetes emerged out of Google and they have continued to 0the project even as it fell under the auspices of the Linux Foundation’s CNCF.
On August 29, 2018, Google announced that it is giving $9M in Google Cloud Platform (GCP) credit to the CNCF Kubernetes project. This is being hailed by both Google and the CNCF as an announcement of major support. $9M is a lot of money, even if it is credits. However, let’s unpack this announcement a bit more and see what it really means.
- Google Already Hosts the project’s Development. The Kubernetes project’s development is currently hosted on GCP. The donation helps to ensure that the project does not migrate to a different cloud platform. Google’s donation ensures that it will pretty much stay where it is. So, for the immediate future, one would not expect disruptions such as migration to other platforms.
- $9M now but what about later? Google is allocating $9M to the project now, but what will happen when the credits run out? There are a number of options. First, Google may give more credits to the CNCF. Or, they might not. If they don’t then the CNCF will have to start paying for the Kubernetes project to continue to be hosted on GCP or migrate to another platform. The latter would be disruptive but may happen if someone else ponies up free or cheap resources. $9M represents a lot of cloud resources but it’s not forever.
The $9M in credits is also over three years. That suggests that after that period of time CNCF or sponsors will have to start paying for these resources themselves or that Google will get to make another announcement.
- Might they pull the rug out from under the CNCF? Probably not. While it’s possible Google might shove the Kubernetes project off the GCP when the $9M runs out, it would be incredibly stupid. Google is many things but stupid isn’t one of them. The reputational risk and negative PR alone mean they wouldn’t do this. They would risk losing much of the influence they have over Kubernetes and Kubernetes is important to them. So, no they won’t do something like that.
What does “opening the Kubernetes project’s cloud resources up to contributors” mean? This was the terminology used in the Google press release. Google goes on to say that it had provided “CI/CD testing infrastructure, container downloads, and other services like DNS” but doesn’t explain how that affects the Kubernetes project. CNCF expresses this a little differently. They say that “CNCF and Kubernetes community members will take ownership of all day-to-day Kubernetes project operations. Responsibilities will include operational tasks for the development of Kubernetes such as testing and builds, as well as maintenance and operations for the distribution of Kubernetes.” This suggests that Google has been managing the actual project operations despite this being a CNCF project. When the community doesn’t control the operations of an open source project, the source may be open, but the project really isn’t.
Ultimately, it’s a positive development for the Kubernetes project. The CNCF will take more responsibility for the Kubernetes project which, in turn, makes them less reliant on Google. This makes the Kubernetes project an open project and not just open source. There is, however, some risk. If the cost of the Kubernetes project grows or the community finds itself at odds with Google, they may find themselves searching for more money or donated resources. Given the three year outlook, project leaders have plenty of time to de-risk the project resources.
This change in project responsibility makes sense for Google as well. They get some positive PR while removing themselves from long term responsibility of the project. They also shield themselves from claims that they are using their resources to maintain control of the project to the detriment of their competitors. The Free and Open Source (FOSS) community can be suspicious of the motives of large companies even while benefiting from those same companies.
Open source projects are a little like children. They need parents to nurture them through their formative stages of development. After awhile though, they need to fully leave the nest and become grownups. Kubernetes has grownup and it’s time for it take charge of its own future.