Continuous Innovation Is a New Business Pattern for Cloud Foundry

by Sophie TurolAugust 24, 2015
In his keynote, Sam Ramji of the Cloud Foundry Foundation explains why the future is after open source and Continuous Innovation.

The dawn of a new era

Those who can’t adapt to the changing market, soon drop off. Continuous Innovation seems to be the pattern to adopt to stay competitive. Still, you may face certain difficulties when building Continuous Integration and Continuous Deployment. Sam Ramji explains how to address such issues. In addition, he explains what role the foundations play in today’s market and how Cloud Foundry confronts vendor lock-in.

We can’t but agree with the truth said out loud numerous times: “Things are changing faster than they’ve ever changed before.” Sam Ramji brings our attention to it once again, emphasizing that the change in human behavior has an instant dependence with us “putting Internet on all things.”

“We want information when we want it in the way we want it…and businesses are starting to shift to match the change.” —Sam Ramji, the Cloud Foundry Foundation

The risks are also high as never before. To illustrate it, Sam turns to statistics that speaks for itself.

sam-ramji-keynote-oscon

The reason is simple: companies that fall off the list stick to the used-to-be strategies. Sam refers to Rita McGrath from Business School of Columbia. In her book “The end of competitive advantage,” she mentions that used-to-be golden standard for businesses: “Establish many monopolies, establish pricing power, customer control, and then exploit that for as long as possible to be able to generate a maximum profit.” As you guess, it no longer works. So, what is the new pattern?

“Continuous Innovation is the new frame, Continuous Innovation is a response by business that the market is changing fast and they need to move faster now.” —Sam Ramji, the Cloud Foundry Foundation

 

Foundation boom

2015 can be truly called the year of foundations. June 22 was marked by launching the Open Container Initiative. On July 21, the Cloud Native Computing Foundation was started.

Sam considers that the reason for the foundation boom is the economical attractiveness of open source that “breeds competition and distrust.” On the one hand, venture capitalists get a chance to take a promising open-source technology, wrap a company around it, and hit the jackpot. Still, the very essence of open source wears out and distrust sets in, when the whole thing gets bigger and gains importance. There is that fear of vendor lock-in. So, the foundations serve as a bridge to “multi-vendor open source to enable competing corporations to collaborate.”

That seems to be the point. The collaboration of Pivotal, IBM, and HP (each company has its own PaaS offering: Pivotal CF, Bluemix, and Helion) resulted in the Cloud Foundry Foundation. The purpose of it is to “open the development roadmap, standardizing through certification.”

sam-ramji-keynote-oscon-the-cloud-foundry-foundation

There were concerns as to what Docker’s reaction would be to CoreOS launching Rocket. Would it evolve as a PaaS and eat Cloud Foundry’s lunch? Such thoughts were triggered by Docker’s roadmap from December 2014. What we got is Docker and Rocket meeting in the Open Container Initiative. What’s more, Microsoft announced that runC is going to be the standard interface for Windows containers. So, Microsoft is planning to implement Linux-type features to be able to support the runC requirements.

Quite the same story with the Cloud Native Computing Foundation. It takes roots in Kubernetes vs. all the other container orchestration systems. The idea was to bring it all together and “harmonize Kubernetes and Mesos and reimagine schedulers as plug-ins.”

 

Tailored Kubernetes Implementation Roadmap

Why would it work?

Really, why would rivals team up? Why not try to become better, faster, stronger than anyone else? Sam points it out: “We are living in the age of open source and open-source data centers.” Thus, we have got the full stack from infrastructure to programing frameworks at our disposal.

sam-ramji-keynote-oscon-open-source-stack

So, why not pull the efforts together to harmonize that stack? Next, according to Sam, every meaningful technology has a movement around it. And it seems that Continuous Innovation is the one for Cloud Foundry, Docker, Kubernetes, CoreOS, Mesos, etc. Continuous Innovation means both Continuous Integration and Deployment. And though most of the companies choose that pattern, it still takes months to move to production.

The solution is obvious: bring Dev and Ops worlds and create a new world, where everything is ephemeral, scalable, and agile.

“We can blow up containers, we can add containers, and we can grow and shrink clusters. We are not particularly precious about any particular workloads, where the workload exists on mass. No instance is going to destroy us. It’s also about agility: smaller pieces of code changing faster reduces the risk for anyone change.” —Sam Ramji, the Cloud Foundry Foundation

Sam offers the following pattern as a potential solution, already field-tested by Toyota.

sam-ramji-keynote-oscon-ways-out

“If you need more than two pizzas to feed your entire team, it’s probably too big.” —Sam Ramji, the Cloud Foundry Foundation

He also points out that we need to have soft boundaries to continue to explore the nature of the cloud. It’s also about making technologies working together. As an example, he talks about the differences between Cloud Foundry and Kubernetes.

“It’s like comparing apples and dinosaurs, I don’t know where to start. Kubernetes and Diego are about schedulers, how could they work together? Could Diego run on Mesos as an application workload scheduler?” —Sam Ramji, the Cloud Foundry Foundation

He says that foundations help to make these boundaries softer and concentrate on such issues as manageability and security.

 

With Cloud Foundry in the clouds

What the Cloud Foundry community strives for is to protect the freedom to move from cloud to cloud. Sam nails it by reminding that in 5 years—let alone longer time from now—your code may still be in production, while your cloud providers won’t be there. So, Cloud Foundry is all about rebalancing the situation towards the user and continuing to fight vendor lock-in.

The Cloud Foundry Foundation was a breakthrough. So, what’s with the new two on the list?

The Open Container Initiative is driven by 30+ sponsors (Docker, Microsoft, Google, IBM, HP, CoreOS, Pivotal, VMware, etc.). The project is under the patronage of the Linux Foundation. It aims at creating open industry standards around container formats and runtimes.

The Cloud Native Computing Foundation, also housed in the Linux Foundation, was started by 19 companies, Google as a leader.

Actually, both the foundations share a lot of the same members.

These newcomers in the foundations’ family—which seems to grow by days—haven’t made such a hit yet, as the Cloud Foundry Foundation did. Surely, foundations have their perks, but there is also a concern that they may become the new monopoly. Anyway, it’s at the mercy of the ecosystem to not let it happen.

 

Want details? Watch the video!

Table of contents
  1. Why Continuous Innovation is the new business pattern? (00:21)
  2. Why are there so many foundations? (01:51)
  3. How the Cloud Foundry Foundation was started? (03:05)
  4. What is behind the Open Container Initiative? (03:46)
  5. What is the Cloud Native Computing Foundation? (05:12)
  6. Why do all these technologies work together? (06:38)
  7. How to successfully implement the Continuous Innovation pattern? (07:34)
  8. Prescriptive vs. assembled environments (11:11)
  9. What is happening with Cloud Foundry? (12:27)

In this video, Sam Ramji discusses what’s behind the development of a cloud-native platform.

 

About the expert

Sam Ramji is CEO at the Cloud Foundry Foundation. With 20+ years of IT experience under his belt, he was Chief Strategy Officer for Apigee (APIC), designed and led Microsoft’s open-source strategy, founded the Outercurve Foundation, and drove product strategy for BEA WebLogic Integration. Previously, Sam built distributed systems and client software at firms including Broderbund, Fair Isaac, and Ofoto. He is an advisor to multiple companies—including Insight Engines and the Linux Foundation—and served on the World Economic Forum’s Industrial Internet Working Group. Sam received his B.S. in Cognitive Science from UCSD in 1994.


The post was written by Sophia Turol with assistance from Alex Khizhniak.
Interested in how to manage secure Cloud Foundry deployments distributed across multiple data centers?
  •  
  •  
  •