Thinking Like A Cloud Part 2 - Open Source and Inner Source - How Open Enables Innovation

Innovation in Innovating

The way we innovate has, in recent years, experienced innovation of its own. This innovation in innovation has changed the way even market leaders go about their work. The driver for this new style of innovation is being open beyond the walls of the team directly responsible for the innovation. This openness can but does not always need to go beyond the walls of a single company.

Collaboration

Ideas and perspectives can come from anywhere. Sometimes the combination of different ideas from different people with different perspectives can create something new and innovative.

To illustrate this point, we can look at an example that happened to Kubernetes, the open source container management platform. When Kubernetes was first launched by Google it was difficult, if not practically impossible, to run state-based workloads, such as databases. When containers are scheduled and moved it means something different for a stateless 12-factor application and a database like MySQL. Developers at Red Hat and Google worked together to come up with StatefulSets, a method to describe and handle applications with state needs in Kubernetes. A collaboration of people at different companies brought this idea to life and made this possible.

The ability to run stateless container workloads was not new. Platform as a Service (PaaS) platforms, such as Heroku and Cloud Foundry, had been doing it for years. Google had figured out how to run stateful workloads in containers but has done so by leveraging a series of proprietary filesystems that pair with their internal container management. What was new here was the ability to handle stateful workloads with commodity storage available to everyone.

What made this collaboration possible is that Kubernetes is developed in the open. What made this collaboration successful is that subject matter experts from far-flung organizations were able to work together.

As we will see in a moment, not all open needs to go beyond the walls of a single company.

Building Blocks

Being open has provided a second benefit beyond the ability to innovate via collaboration. Being open provides easy access to others work to use as building blocks. This happens through both consuming source code as libraries or supporting applications and through leveraging application interfaces (APIs). To illustrate this we can look at a couple examples.

WordPress is a popular example because it powers over 30% of all websites. In addition to being popular, WordPress provides us an example application that has built on others work by leveraging another application (i.e. MySQL) as a dependency and is dependent on others software libraries (e.g., jQuery, Farbtastic, etc). Because WordPress developers did not have to develop a database or JavaScript libraries they were able to focus on their business differentiator (i.e. the content management experience).

With the advent of cloud, a new form of building block has become popular. This new form is software services available through a internet based API. These services have benefits for those who want to innovate. For example, API consumers can consume services over an API rather than having to learn how and take time to operate something. That saved time can be put into innovating around something else.

Examples of this are common. For example, Amazon Web Services (AWS) has dozens of these small services that others can build on ranging from Internet of Things (IoT) supporting services to machine learning and many more in between. And, AWS doesn’t just provide this for others. They use the pieces themselves to build other services. For example, their database services leverage other services such as virtual machines and storage.

This isn’t just AWS. The major public clouds all do this, OpenStack – the most popular open source cloud software – has numerous services like this, and there are 3rd parties that provide services such as SendGrid and Cloudflare.

Inner Source

Up to this point we have been looking at open source projects and public services. Not everything fits well into these situations yet the principles of open can still be adopted while not being public. The first example of this is something called inner source.

Inner source is very similar to open source but handles the case where source code for an application or library cannot be released publicly. This can be for a variety of reasons including situations where the software has intellectual property or some other business value.

Inner source is where the software is open internally within a company for those in the company to access or contribute to but not outside of the company. This enables those within the company to collaborate with each other and build on each others work.

Google is well known for this approach. Most of the software within Google is widely available to any of the developers and developers can collaborate with those on other teams working on entirely different pieces of software.

To facilitate inner source many companies are turning to applications such as GitHub Enterprise and Gitlab.

Hybrid Cloud and Shared Services

While open source and inner source enable people to contribute to and use the work of others, whether it be applications, microservices, or libraries, there is still another part of open enablement that comes from open APIs.
Many application developers and operators are not experts in the dependencies they use. Yet, they can build upon the work of others. If we look at the WordPress example from earlier we can take the MySQL dependency and change how it is operated. Instead of someone running MySQL themselves they can consume it as a service. In this setup they do not handle the operational burden. By not spending time learning about the operational needs of MySQL and performing the operations tasks they are able to put more time and energy into the business differentiator for this WordPress instance or WordPress itself.

This model is common enough that all the major public clouds offer common services where the cloud provider takes on operational responsibility and consumers of it can access the services through an open API.

This model showcases three opportunities for service providers and hybrid cloud solutions.

1. Applications that are being used bymany, similar to the MySQL example, can be setup using a Software as a Service (SaaS) model. This centralizes the operational concerns to enable those building on it to focus on their custom business logic and innovation. It also provides an opportunity to track value for this service across the company and possibly open up the service to others including those outside the company. This model can be used for company custom solutions.

2. Hybrid cloud often includes an element of on-premise hosting. This can include whole datacenters or co-located hardware in someone else’s datacenter. In these on-premise situations the common services, such as the previously discussed MySQL, can be operated as a service for others to consume. This follows the popular and useful model of public clouds. In these on-premise situations the common services can be targeted at the situation’s consumers need.

3. SaaS solutions at different providers typically have a different API. To continue the MySQL example, the API calls to create and manage clusters in each of the major public clouds is different. The opportunity here is to work towards a unifying management layer. The open source example in this space is the Open Service Broker which already has backing from AWS, Azure, and Google Cloud. This provides opportunities such as using the Kuberentes Service Catalog project combined with Helm, the Kuberenetes package manager, to make cross platform service management accessible in Kubernetes.

Taking advantage of these three opportunities will enable us to focus specialties and enable cross cloud operations while providing new opportunities whether in a public or private cloud.



▶    The contents are protected by copyrights laws and the copyrights are owned by the creator.
▶    Re-use or reproduction as well as commercial use of the contents without prior consent is strictly prohibited.