At Cisco Live 2016, held in Berlin, the latest version of Cisco’s open source microservice platform, Mantl, was released. New features in this 1.0. release include multi-data center configuration via tooling like Project Calico, simplified version control of a developer's entire infrastructure configuration, and blue/green testing as part of a service upgrade process.

InfoQ sat down with Ken Owens, CTO of Cisco Intercloud Services, and asked about the use cases, design decisions and future plans associated with this latest release of Mantl.

InfoQ: Hi Ken, thanks for taking the time to talk to InfoQ today. Could you briefly explain what Mantl is please?

Owens: Mantl provides all the infrastructure components you need to deploy your microservices platform. We have chosen industry standard components, such as Docker, Mesos and Terraform, and made them work well together, so you don't have to write any glue code. Mantl automates tasks that used to require months of DevOps time to do, that way your can focus on your application and not your infrastructure. Our vision is to enable you to focus on the application code and business agility, not infrastructure APIs. The Mantl framework is able to provision both infrastructure and software as code. This allows users to deploy their services and applications in a programmable, repeatable manner. Mantl is also cloud agnostic - it can deploy to a range of cloud providers: Rackspace, AWS, DigitalOcean, Google Cloud Platform, etc. Alternatively, private clouds can be provisioned: OpenStack, VMWare, bare metal or any set of systems running CentOS. We also plan to build a community around providing an end-to-end solution for microservice infrastructure, not around an individual component, designed to solve business and team challenges, one platform, improved by the community and tested everywhere.

InfoQ: You're talking at Cisco Live 2016, held in Berlin, about the launch of a new version of Mantl. How has Mantl changed since InfoQ last published details about the project?

Owens: Quite a lot has changed. Here are the highlights: Multi-data center configurations are supported using a WAN and tools like Project Calico.

Many services are available to use out of the box (with more being added daily): software defined networks, software defined storage, DNS support, databases, monitoring tools, service discovery (Consul), secret storage (Vault), logging (ELK stack), security, etc..

The user’s entire project stack, from infrastructure to application configuration, can be placed under version control.

The Mantl project is automatically tested against a range of cloud providers to ensure quality.

Since Mantl 0.6, it is possible to perform blue/green testing as a part of the upgrade process.

InfoQ: Could you explain the typical uses cases that Mantl is appropriate for, and also explain why a developer or architect should choose this project as their infrastructure platform?

Owens: Typical use cases fall into cloud native (Gartner’s ‘mode 2’), data analytics, and transform. Some of the most important components include Mesos, Marathon, Docker and Consul. Mesos is the backbone of Mantl. It places a layer of abstraction on resources (cpu, ram, ports, etc.) and is able to allocate work over a cluster of machines. Marathon is a simple orchestration tool to start microservices. A service definition would specify the resources required which is then submitted to Mesos for allocation, via Marathon. Marathon then ensures that the service is healthy and restarts the service if it ever fails. Consul is a service discovery mechanism. Mesos tasks are automatically given a Consul endpoint based upon their name, for service discovery. So to connect to zookeeper, for example, it is as simple as addressing zookeeper.service.consul. The most important configuration file is the Ansible playbook. This defines what will and will not be installed at a high level. For example, there is that code defines the software that is installed on a host that has been defined with the role of “control”. On all of the nodes with the role of control, they will also be given the roles of Vault, ZooKeeper, Mesos, Marathon, Chronos and mantl-ui. These refer to the components that are going to be installed, which are defined elsewhere in the project. We believe that the architecture of Mantl addresses the next evolution of application development automation is a microservices model.

InfoQ: Many developers and organisations are evaluating the use of Kubernetes, stating that operational effort required for deploying Mesos-powered platforms only has a justifiable ROI for large-scale deployments (i.e. Twitter and Apple). What are your thoughts on this?

Owens: Great question. Choice and extensibility are the key elements of any true transformational model. Mesos has a framework approach which have been very useful for several of our enterprise customers. Kubernetes has some definite performance and scale benefits that we have tested. One of the values of Mantl is that we handle all these operations aspects in the platform and support large-scale deployments. However, if you’re interested in Kubernates, we have integrated Kubernates into the Mantl platform and will have a release in about 1 month with the initial support. For more information you can check out our github repo.

InfoQ: Are you planning to offer any support model or SLAs for users of the Mantl?

Owens: Yes, we plan to offer a support model for Mantl as well as an enterprise grade model in addition to the open source model.

InfoQ: Could you offer any insight into how components of Mantl are chosen, e.g. the HashiCorp Terraform, Logstash etc. Is there an evaluation process, or do you simply chose 'best of breed' technology?

Owens: We follow a service design methodology. The first aspect is sensing the large shifts in this technology space and defining an architecture for mode 1 to mode 2+ methodologies. Once we had the architecture we asked for feedback from our enterprise developer and SP partners while we looked at the different open source projects that were most popular. Open source is a big part of the culture we have at Cisco. Once we have the feedback and software options in mind, we created a prototype of Mantl in a project called 'Microservices Infrastructure'. This involves lots of testing, optimizing, evaluating, and scale testing aspects. As we went into the Service Design phase, we looked at the gaps in today’s tools and what the architecture required and we approached those in the project. This includes networking (IP per container/group of containers), services discovery, service availability, security, and application policy. In the end, we had Mantl which address the architectural needs, “best of breed” technology, and customer feedback.

InfoQ: Can we ask for your predictions in the container/orchestration space over the next year, particularly in relation to the enterprise space? Will Docker be fully embraced? Will another viable container format emerge? How will the traditional IT infrastructure vendors deal with the changing landscape and emergence of platforms like Mantl etc?

Owens: The industry is in the middle of another transformation towards microservice infrastructures. The hype around this is higher than any technological transformation I have ever been involved in. I’m not convinced that we will have a winner in the next year. I believe the adoption rate will grow but the complexity of a single container vendor and ecosystem will have the enterprise looking at converged solutions like Mantl.

InfoQ: Thanks for you time today Ken. Is there anything else you would like to share with us?

Owens: We look at this as a community effort and invite your readers to get involved. Please check out Mantl at http://mantl.io and follow us on Twitter at @usemantl.

Additional information on the Mantl project can be found on the framework’s website, and also within the associated GitHub repository.