Disruption in Open Source Delivery, the Open Source Service
In a two part post, I'll talk about two new approaches to delivering software as a service so that engineers can build better applications. One model I will call Open Sourced Services (Part 1) and another model I will call Managed Anywhere Services (to-be-written Part 2).
These posts will mostly describe a vision I have but will also include some back story and some technical information. The attended audience is anyone building or using applications.
Where are we today?
Today's Cloud Services
Today's Open Source
Well, what do we want?
The three main items that stick out are:
- services
- control
- portability (no lock in)
Below, I will talk about one way how we can get there.
Model #1 - Open Sourced Services
An open source service is the packaging and delivery of open source software such that it is delivered as a service. An open source service should have these characteristics:
It is controlled as a service, not as software - The consumer takes action on the service itself versus it's subcomponents. They can initiate upgrades of the service. They can start, stop or restart the service as needed. The service should expose configuration knobs so that the consumer can control the level of redundancy, user access, scaling parameters (auto scaling, infrastructure thresholds, etc), capacity and user access.
It can run anywhere - The service should be able to be deployed anywhere. In a public cloud or in your company's data center.
It is open - The source code of the software and the declarative definition of how the software is wrapped as a service should both be open sourced. This will give the the consumer of the service the control they desire.
How do we get to Open Sourced Services?
Note: I'll be using Docker and Kubernetes in the rest of this article but you should know that there are alternatives (swarm, mesospahre, rocket, oci, etc).
Docker enables us to easily build, ship and run software by packaging it up in a way that will run on a wide range of systems. If open source groups takes their code and packages it inside containers they will have the building blocks required for turning their software into a service (that can run anywhere).
Once the software is packaged in Docker containers we can turn their software into services by using kubernetes's features. Kubernetes's goal is to take a set of infrastructure (that lives anywhere) and provide an API to create services on top of that infrastructure. Kubernetes includes features like load balancing, scaling, rolling-updates, service discovery, name spaces, APIs, scheduling and configurable infrastructure threshold limits. Using these features, we can create declarative services and give control of the service to the consumer. Kubernetes helps groups deliver on the above characteristics for what makes up an open source service.
Creators of open source software now have a way to package their software up and deliver it as a service. Sweet!!!! So, how would we consume these new services?
How will we consume open sourced services?
Second, consumers would need to choose and install some open source services . For example, let's say they want to use a noSQL service for their application. Previously, their choices where using something like AWS's DynamoDB (with AWS lock-in) or they could have engineered their our own Cassandra cluster with a bunch of blood and sweat. With open source services, all consumers will need to do is install the cassandra service on their kubernetes cluster of choice. They might do this with an easy command line tool ('kubernetes install service cassandra') or perhaps by logging into an app store and clicking on the cassandra service. Consumers will want to control the service by setting some parameters, like capacity limits and redundancy options, so that the service meets their needs. After that, the consumer simply starts using the service and keeps an eye on all the fun metrics and logs the service provides.
In this new world, consumers will have more control of their application and the services that they depend on. They can move our applications between clouds or between private and public. Consumers can run their applications actively across multiple clusters or do active-standby. All this is sweetness.
In summary
Up next - Marriage #2 - Managed Anywhere Services
One of the down sides to open sourced services is that sometimes there is no one to call in case things go wrong. In my next post I'll write about an alternative approach that aims at solving that problem and opens up a new way for companies to make $$$ by delivering these services.
End
Thanks
Chris
--
Some useful links:
End
Thanks
Chris
--
Some useful links:
- Learn more about containers and kubernetes: http://kubernetes.io/v1.0/docs/whatisk8s.html
- A list of some early versions of open source software packaged up as services: https://github.com/kubernetes/kubernetes/tree/master/examples