Software engineering and developer communities are driving the market for cloud consumption and leading each industry into a new era of software-defined disruption. There are no longer questions about elastic and flexible agile development as the way to innovate and reduce time to market for businesses. Open source software plays a key role in the transformation taking place to cloud native and understanding how your business strategy needs to address this next disruption in software development is crucial to the success of your business. The first key area is to automate your Software Development Life Cycle (SDLC). The modern SDLC for Software Disruption is shown below.
Cisco Shipped Developer Experience
The core of Cisco Shipped is modern, simple developer experience for cloud native development that addressed the modern SDLC. The project addresses both the developer needs in the build and deploy phases as well as the operations users in the run (monitor and metering) capabilities. Shipped leverages another open source project called Mantl for multi-cloud/data center deployments for a full container platform that supports Kubernetes and Mesos side by side.
I like to call this Hybrid Devops as developers will be developing in a mixed application mode for some time as they move from traditional and cloud models to containers. Also, there will always be a next generation capability that needs to be integrated to this model, so in effect, we are always moving from existing to next gen continuously. Shipped was designed to address this new hybrid model.
Cloud Native Model
The open source project Mantl provides a complete container platform. I use the term platform to represent both the hardware and software associated with delivering the software disruption transformation the enterprise is undertaking. A platform can only be a strong as the physical systems that comprise the hardware architecture of the platform. The security and performance of the underlying physical infrastructure is how your business differentiates. The infrastructure layer is still important to the overall experience as performance and security aspects of the stack require full integration of the physical and logical security components. Being able to optimize the network, compute, and storage resources in a fully automatic and consumption based economic model has been optimized to meet the business requirements.
The mantl curated container stack is shown below.
Mantl is an open source, end to end, integrated stack for running container workloads across multiple clouds. Mantl includes deployment automation and assurance and monitoring. We designed the project to be pluggable and grow into a hybrid platform to support application development and data services. With Mantl, enterprise grade networking (L2-4 and overlay), security (secret, AAA, network), and storage (persistent, object, and ephemeral) capabilities built in.
Mantl address a common problem in application orchestration – multi-orchestrator capabilities. There are several use cases and different types of orchestrators that address these use cases. Mantl’s design is extensible and today supports Mesos/Marathon, and/or Kubernetes, and/or Docker Swarm. What is important in a multi-orchestrator model is unification across the service discovery and load balancing to enable multi-cloud deployments – customer choice.
Application Intent
As I looked at the expanding gap between business requirements and infrastructure configuration components, a thought occurred to me to address the business SLAs by understanding the sensitivity of the application called Application Intent. In the definition here, we introduce the business goal of sensitivity. Sensitivity is defined as the degree to which the performance and response time of the application is to these parameters influencing the end users perception of the application performance. It’s best to consider it a scale of no sensitivity to high sensitivity that can be adjusted in real time by the perceptions of the performance being measured by the system and end users.
The Application Intent sensitivities are defined as:
- Compute
- CPU Sensitivity
- Memory Sensitivity
- Storage Latency Sensitivity or Volume Sensitivity
- I/O
- Latency Sensitivity
- Throughput Sensitivity
- Thresholds (Optional numerical value – ie 80 connections/sec)
- Fault/performance
- Recovery Sensitivity
- Availability Sensitivity
- Scale Sensitivity
- Accounting – Cost Sensitivity
The configuration is shown below:
Given these sensitivities, the policy system can create an SLA for the business objectives defined here. In addition to these sensitivities, there are hints that the policy system would like to understand. The first one has to do with dependencies:
- Services
- Service Affinity
- Service Anti-Affinity
- Security Policies (Data Classification)
- Placement Policies
- Host Affinity
- Host Anti-Affinity
- Availability Zones
- Regions
- Geo
- Constraints – non-coexistence
The second has to do with limits and understanding the constraints on the policy
- Metering Limits
- IO
- CPU
- Memory
- Connections/sec
- Security Governance
- Organizational Constraints (IE, HR, Legal, Engineering)
- Data Type Constraints (Public, Sensitive, Confidential, Top Secret)
- Operational Constraints
- Encryption
- Auditing
- Log Retention
Given the sensitivities, dependencies, and limits, the developer can set initial application intent, measure the performance of this initial intent, and make changes based on the actual performance. The Data platform will then be able to enhance the application capabilities in almost real-time to provide the performance and scale the business requires. Over time, the community will continue to add more intelligence into the intent model and enforcement engine.
The runtime view is shown below:
Come Join Us
We hare hosting several sessions at Cisco Live in the Devnet zone (see below). If your attending Cisco Live US in Las Vegas, please sign up for the sessions of interest as space fills up quickly!
Developing Cloud Native Applications Using the Shipped and Mantl Platforms – A Technical Overview
Session ID: DEVNET-1065 Kenneth Owens, CTO, Cisco
SCHEDULE Tuesday, Jul 12, 12:00 p.m.
Introducing Cloud Development with Project Shipped and Mantl: A Deep Dive
Session ID: DEVNET-1202 Brian Hicks, Cisco
SCHEDULE Tuesday, Jul 12, 9:00 a.m.
Shipped & Mantl – The Business Case for Using an Integrated Cloud Development Platform Session ID: BRKDEV-1003 Kenneth Owens, CTO, Cisco
SCHEDULE Wednesday, Jul 13, 1:30 p.m
Deploying Applications with Cisco Shipped and Mantl – A Technical Deep Dive
Session ID: DEVNET-2027 Fabio Giannetti, Principal Engineer, Cisco Systems
SCHEDULE Thursday, Jul 14, 11:00 a.m.
Tenant Container Monitoring in Shipped
Session ID: DEVNET-2031 Fabio Giannetti, Principal Engineer, Cisco Systems
SCHEDULE Wednesday, Jul 13, 9:00 a.m
Devnet Workshop – Deploying Applications with Cisco Shipped and Mantl
Session ID: DEVNET-2028 Kenneth Owens, CTO, Cisco
SCHEDULE Monday – Thursday, Jul 11, 9:00 a.m
Devnet Workshop – Mantl: How to use it
Session ID: DEVNET-2030 Ken Owens, CTO, Cisco
SCHEDULE Monday-Thursday, Jul 11, 10:00 a.m.
CONNECT WITH CISCO
LET US HELP
Call us: 1.800.553.6387 - Ext 118
US/Can | 5am-5pm Pacific Other Countries