During the dot-com boom, when Oracle was the dominant supplier of relational databases to startups and established enterprises alike, it used its profits to fund the acquisition of application serving middleware, notably BEA WebLogic, and then applications, such as PeopleSoft and Siebel, and then Java and hardware systems, from its acquisition of Sun Microsystems. It was an expensive proposition, but one that paid off handsomely for the software giant.
In the cloud and hyperscale era, open source middleware is the driving force and in a lot of cases there is nothing to acquire. Projects either go open themselves or are mimicked by those who open them, and there is no money to be culled from IT budgets for the creation of the technology. The best anyone can hope to do is contribute to the community, make a platform from the pieces, and get as much support money as possible from as large a pool of enterprises as can be found who will pay. It is a good thing that such transitions take decades, or Oracle and companies like it would die almost instantly and would not have time to adapt.
Change, however, comes slow to enterprise systems software, and there is plenty of time to react and readjust for both vendors and IT shops. The trick is to move fast enough to keep your customers, and keep them moving, and not losing them to competitive options that are forging ahead.
With over 430,000 customers and $37.7 billion in revenues in its fiscal 2017 that ended in July, Oracle has an installed base that is ready and eager to employ its cloud infrastructure to run its database and middleware and sometimes its application software. The same is true of Microsoft, which has tens of millions of customers using Windows Server and a portion of those using its SQL Server database and various Dynamics applications. It is these stodgy enterprise applications that are driving adoption of clouds at companies like Oracle and SQL Server, and the same holds true of VMware with its more than 500,000 customers and its partnership with Amazon Web Services to build a cloud based on the VMware stack that customers can rent. Each of these three will see adoption of their cloud technologies by their vast installed bases, even if they cannot grow to the size of AWS. Despite how it seems sometimes, AWS will not have all the customers when this cloud transition is done.
That said, these legacy platform vendors do well to absorb all the cool technologies they can, and that is what Oracle announced it was doing at its Open World 2017 extravaganza in Silicon Valley this week. The company has two new technologies that will allow it to go toe-to-toe with AWS, Google Cloud Platform, and Azure with container orchestration, container registry, and serverless environments. In fact, Oracle has been inspired by technologies created by Google and by AWS to bring these new compute platform layers onto the Oracle cloud.
For the Container Engine and Container Registry services, Oracle has pulled the code directly from the Kubernetes 1.7 stack from the repository hosted by the Cloud Native Computing Foundation, which was created two years ago as the home of the Kubernetes container orchestrator that Google open sourced and that is inspired by the Borg container and cluster workload manager that has been running the search engine giant’s internal infrastructure for more than a decade.
Oracle joined the CNCF a few weeks ago as a platinum member, and as part of its initial contribution to this open source community it open sourced a variant of the Terraform infrastructure configuration management controller (it is like Kubernetes for hardware) that was created by HashiCorp. This particular variant of Terraform was self-serving, of course, in that it configured virtual infrastructure on Oracle Cloud so it could run Docker containers and the Kubernetes orchestrator for it, and here we are two weeks later and Oracle is launching a full-blown container service on Oracle Cloud.
Bob Quillen, vice president of developer relations at the software giant, tells The Next Platform that the container service has been used internally at Oracle for various workloads for quite a while. (Oracle also announced that it has woven Kubernetes into its commercially supported Oracle Linux 7 distribution, which is a spinoff of Red Hat Enterprise Linux.)
The Container Engine service can be used separately or in conjunction with a tweaked version of the open source Docker container registry service, which Oracle has tweaked to integrate with its various bits of middleware and systems software on its cloud, and a new continuous integration/continuous delivery (CI/CD) development environment, called Container Pipelines, which is based on the tools that came to the company through its acquisition of Wercker earlier this year.
One of the features that Oracle has added to Container Engine that is missing from similar services offered by other cloud providers, says Quillen, is high availability clustering for the Kubernetes control plane underneath it. But Oracle has cooked up its own, and it looks like this:
The Kubernetes containers do not run on virtualized infrastructure, but on bare metal instances, and integrates with the load balancing, persistent storage, and block storage services already on the Oracle Cloud, too. (The load balancers act as the front end for Kubernetes master nodes and for the etcd key/value storage that holds all of the state information for the containers.) The Oracle Kubernetes stack also includes node pooling, which allows for containers to be mixed and matched and ran across bare metal and virtual machine instances.
The Container Registry Service, which is based on open source components from the Docker community, has some extra goodies woven into it. One of the important ones is that Oracle is taking elements of the Zettabyte File System (ZFS) to add de-duplication of container images on its registry – something that the real Docker Registry does not have.
With the combination of Kubernetes, Wercker, and Docker Registry, the Oracle Cloud has a next-gen application development and deployment platform akin to Red Hat OpenShift or VMware Cloud Foundry. Quillen says that Oracle is only offering this stack on its public cloud and is not going to deliver it on premises, which might turn out to be a mistake. But with the combination of Oracle Linux with Kubernetes and Wercker and hooking into the Container Registry Service, enterprise customers that want the same stack internally as well as externally should be able to get that experience, more or less. As for concerns about vendor lock in, those who choose Oracle or Microsoft or AWS platforms know full well they are getting locked in.
That’s the thing about enterprise customers: If you give them a platform, a real platform, they are fine with paying a premium and even waiting as it adopts new technologies. Lock in is not as scary as taking big risks and losing your job. At hyperscalers, taking big risks is the job, and so is the need for those risks to pan out. They are rich enough to make big mistakes and not be hurt by them, too.
In addition to the container stack on its public cloud, Oracle is launching its own serverless platform, called Fn, that is a framework that has its heritage in the work of Iron.io, one of the pioneers in this field that seeks to reduce computing to a bunch of functions thrown at a bunch of data, streaming or static, without any care for the underlying infrastructure which, obviously, is still there in all of its complex glory. Iron.io was founded back in 2011 and developed a serverless stack called IronWorker and a messaging stack called IronMQ to interface with legacy applications and data. The company was sold to Xenon Ventures in April of this year, and founder and CEO Chad Arimura joined Oracle soon thereafter to fire up its serverless efforts. In fact, the same team of people who developed IronFunctions, the function part of the Iron.io stack, have joined Oracle to create Fn.
The Fn code base is going to be open sourced with an Apache 2 license, and the Fn Flow high-level workflow controller for the serverless stack will initially be hooked into Java and then into Go. (The Fn tool itself is largely written in Go, like many system programs these days, thanks to Google’s influence in infrastructure and the success of Kubernetes, which is written in Go, in particular.) Fn runs wherever there are Docker containers – it ain’t picky. Arimura says that the Fn stack is not quite ready for production but can be used with that caveat, and that within six months or so it should be ready. Importantly, it is compatible with any functions written in AWS Lambda, and it doesn’t care if your container orchestrator is Kubernetes, Mesos, or Docker Swarm. You can download the code for Fn here on GitHub.