Cisco is currently working on an open source ‘microservice-infrastructure’ project, which will support the continuous deployment of microservice-based applications, and is built upon technologies such as Mesos, Consul and Docker. Development is occurring primarily in the open, via the CiscoCloud Github account.
The Cisco Cloud Blog states that a primary goal of the microservice-infrastructure project is to provide a service on top of the cloud platform at Cisco, which will enable the ability to deploy microservice-based applications that may be run in a multi-datacenter configuration. Cisco plan to provide a consistent development experience across their own cloud and partner platforms (and anyone else utilising the platform), and leverage popular open source technologies, such as Terraform, Docker and Kubernetes, to create a modular open source microservice-based application continuous integration and deployment framework.
Cisco believe that the core properties of such a platform must include:
- The ability to deploy applications utilising resources across multiple datacenters (and even clouds)
- Deploying in a decentralized control model
- Supporting intelligent endpoints
- Heavy automation
- The on-demand nature of deploying these services to support business requirements and scale
InfoQ sat down with Keith Chambers, project lead for microservice-infrastructure at Cisco, and asked several questions about the project.
InfoQ: It is great to see this kind of microservice platform being built primarily out in the open. Can we ask what are the motivations for open sourcing the project?
Chambers: I’m happy to share our motivations! Cisco is betting big on IoT and this is part of our bet. We want to democratize the primitives (Kafka, Spark, Cassandra, Elasticsearch, etc) for building distributed IoT applications by making them available to all. There is a lot of anxiety around proprietary solutions and developers simply refuse to adopt closed platforms and platforms that lock them in to a particular cloud. So we knew from the beginning that whatever we did, it had to be open. Never in a million years could we have imagined the project would take off like it did.
We know of two production deployments outside of Cisco and we have begun offering "Marathon as a Service” for Cisco product teams. Even more exciting, we have signed support contracts with two Fortune 100 companies to support their Mesos deployments (not based on our open source project). We’re clearly on to something BIG!
InfoQ: The Cisco microservices-infrastructure platform is based on the Apache Mesos cluster manager. Can we ask why you chose to build on top of this platform?
Chambers: From the beginning we knew we had to build on a solid foundation and we knew we had to support a board range of open source data services. We wanted to standardize around Docker for software packaging and distributing so that it was simple developers to build and deploy applications.
Mesos was one of several technologies we consider. We like that you can easily run ephemeral applications in Docker containers with Marathon and Kubernetes, and we like its ability to support complex stateful services including Apache Kafka and Apache Cassandra. After our own testing we solicited feedback from Google, Docker Inc., and HashiCorp. These companies all agreed Mesos is the gold standard for cluster management and resource scheduling.
InfoQ: The project's Github README.md mentions that Kubernetes support is also planned (as a Mesos framework). Can we ask why you’re choosing to support both Mesos/Marathon and Kubernetes, which are often seen as competitors?
Chambers: I remember back when Puppet and Chef were disrupting in the config management space. You had Puppet camps and Chef camps. Most of us didn’t care which one you were using just so long as you were using one of them!
We approach Marathon and Kubernetes in a similar way. Both have their strengths. We’ll make it easy for you to try them both and pick the one that works best for you. This highlights the power of Mesos — choice!
InfoQ: We notice that two Hashicorp open source products, Consul and Vault, are currently being used within the project, and Terraform and Packer are also being introduced. Do you have any particular relationship with Hashicorp, or is this the best technology available?
Chambers: It’s a bit of both. I hired Ryan Uber in to Cisco about four years ago and we worked together on a number of really exciting “DevOps” services for the WebEx business. He was working on Serf when Mitchell Hashimoto reached out and made him an offer. I encouraged him to take the offer, which of course he did. Ryan and I are still very close. He introduced me to Armon Dadgar and Kevin Fisher over at HashiCorp. I was immediately impressed by their talent, passion, and drive. Things just clicked and we’ve been working closely every since!
Armon and I actually sketched out the initial architecture together back before Atlas was even announced publicly. Unfortunately Terraform didn’t support OpenStack when we started so we were forced to start with Ansible — but the vision has always been to leverage HashiCorp technology.
I think everyone agrees that the entire portfolio of open source tools from HashiCorp are best in class. I really like the direction they are heading with Atlas and there are a couple exciting features we’re working on together — so stay tuned!
InfoQ: Several other organizations are releasing microservice platforms, such as Capgemini's Apollo. Do you have any comments about this, and will you be looking to share ideas and collaborate?
Chambers: Yes more definitely! We admire the work they have done on Apollo and want to collaborate. In fact Graham Taylor and I have a phone call scheduled for early next week to discuss how we can work together.
Apollo further validates that there is real demand for an application centric hybrid cloud operating system built on open technologies. We are at the beginning of the next area of computing — these are very exciting times!
InfoQ: The latest version of the microservice-infrastructure project is 0.2. Can you provide any more details of the upcoming goals or roadmap?
Chambers: We plan to cut 0.3 in about 2 weeks. That will include support for AWS, GCE, and OpenStack via Terraform as well as our new mesos-consul and marathon-consul bridges. It’s exciting stuff!
We’d like to work with our community to define priorities 0.4. Kafka, Elasticsearch, and Kubernetes are all high on our list.
InfoQ: What is the best way for InfoQ readers to get involved with the microservice-infrastructure project?
Chambers: The best way to get involved it to head over to our GitHub page at https://github.com/CiscoCloud/microservices-infrastructure. The project README has a link to our chat room and we encourage people to open a Github issue if you need help or run in to any issues. The team is quick to jump in and offer support!
InfoQ: Is there anything else you’d like InfoQ readers to know?
Chambers: First, I want to thank our community and partners working hard to make this project possible including Container Solutions, Asteris, BDOSS, Mesosphere, HashiCorp, Twitter, Metaswitch, Elasticsearch, and Basho.
And if you plan to attend Cisco Live in San Diego, please stop by the DevNet Zone to get a first look at Project Shipped. Project Shipped enables small teams of developers to build and deploy distributed applications on top of microservices-infrastructure and Mesosphere DCOS. We think developers will love it.
The Cisco microservice-infrastructure project can be found on Github, and developers are encouraged to experiment with the code and open a Github issue if any help is required.