The need for digital innovation
Whatever your business might be, your internal and external customers expect more and more services, greater efficiency and a better experience. Providing new services (which in most cases will mean a new or revamped application) to customers and anticipating your competitors’ moves attracts new customers and retains the existing ones.
Often the line of business developers are not satisfied with the support they receive from the IT operations teams in terms of flexibility and speed to start a new project, especially if new technologies or skills are required (e.g. developing and deploying cloud native applications).
The perception of IT operations depends also on the frequency of supporting the efforts of releasing fixes for broken services and on the process of testing so that production environments are “bug-free”, after going through functionality and reliability tests.
Frequent releases and the quality of the code can benefit a lot from automation in all the phases of a software project, though end-to-end automation is not absolutely necessary; it’s just much better!
The fundamental pillars are organizing workflows and processes to ensure they cover every need (no gaps in the responsibility, no grey area in communication among different departments, shared objectives instead of finger pointing).
Figure 1 below shows the evolution of methodologies and the impact on the value perceived by the business. The stars represent the moment when business value is realized by a release of the application in production.
With traditional waterfall projects, it happens only at the end of the project (by the way, with a lot of uncertainty due to delays and unexpected trouble during the development and the test phases).
Agile methodology reduces risk by repeating shorter cycles of design, coding and testing that can address any surprises and adjust the course of the project sooner if necessary. But deployment in production still happens at the very end of the project.
The innovation allowed by Continuous Integration and Continuous Deployment (CI/CD) brings the application in production at every cycle (new releases or bug fixing) ensuring optimal quality and a deterministic outcome: the business will appreciate the benefit in terms of time-to-market for their initiatives.
DevOps is not a technology nor a product
DevOps means collaboration between Developers and Operations.
The work of whoever is responsible for design and implementation of the code (the dev team) does not finish when a new build of the application is released. Developers should also collaborate in testing the entire system (code, infrastructure and process), releasing it in production, operating and measuring its KPI.
The Operations team do not just execute a defined process to maintain the system but should collaborate since the design phase of the application and, most importantly, provide constructive feedback from the production environment that can help improve and extend the application in next development cycles, e.g. application errors and their reason, performances issues, support tickets opened by users, etc.
The collaboration and the feedback loop are foundational principles in DevOps, as described in next paragraph. [See The DevOps Handbook: How to Create World-Class Agility, Reliability, and Security in Technology Organizations]
Cultural change
Necessary cultural change should be promoted (breaking silos in the organization), with incentives and gradual adoption of practices that will improve with time: the entire organization and the individuals have to digest a new way of working, openly analyzing its outcome and contributing to the progress with personal feedback and suggestions. A great book describing this cultural change is the Phoenix Project.
DevOps practices suggest that the entire lifecycle of a service is managed by a single team: from the inception phase and the requirements analysis, to the implementation, testing, release and related operational processes. They can be more efficient and provide more value if they know everything about the service and they can react to any problem quickly, as well as evolving it based on new requirements.
The DevOps team should include representatives from different departments (lines of business, IT Architecture, Operations…) that bring their skill and experience, so a new organizational model may be required. The result can be a “dotted-line” reporting structure with functional responsibilities across different teams.
It is not necessary to build a team for each service. Some services can be grouped in one team, especially if they belong to the same business area or if they are responsible for the building blocks of a composite application (in a microservices architecture).
DevOps principles reference
Gene Kim defines the principles of all DevOps patterns (the Three Ways) in the books “DevOps Handbook” and “The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win.” He asserts that the Three Ways describe the values and philosophies that frame the processes, procedures, practices of DevOps, as well as the prescriptive steps.
The First Way – Systems Thinking
- Understand the entire flow of work
- Seek to increase the flow of work
- Stop problems early and often – Don’t let them flow downstream
- Keep everyone thinking globally
- Deeply understand your systems
First Way Goals
- One source of truth – Code, environment and configuration in one place
- Consistent release process – Automation is essential (one click)
- Decrease cycle times, Faster release cadence
The Second Way – Feedback Loops
- Understand and respond to the needs of all customers (internal and external)
- Shorten and amplify all feedback loops
- With feedback comes quality
Second Way Goals
- Defects and performance issues fixed faster
- Ops and InfoSec user stories appear as part of the application
- Everyone is communicating better
- More work getting done
The Third Way – Synergy
- Consistent process and effective feedback result in agility
- Now use that agility to experiment
- You only learn from failure – So fail often, but recover quickly
Third Way Goals
- Ability to anticipate, even define new business needs through visibility in the systems
- Ability to test and optimize new business opportunities in the system while managing risk
- Joy
Now that we have covered the basics of DevOps, let’s have a look at a product from Cisco that could make it easier to adopt DevOps practices. Remember that DevOps cannot be bought: it is the set of good practices that you define and refine as continuous improvement based on experience. Automation is only a part of the story.
The Cisco multicloud approach
Many organizations are using at least one private or public cloud, but more and more use a combination of different clouds: that implies a need for consistent governance, security, networking, analytics and automation that apply to every environment. The multicloud portfolio includes products, services and reference architectures that span all technologies mentioned above to make the adoption of clouds simpler.
This post explains how we have built a demo using products in the automation bucket to support a DevOps use case (i.e. Continuous Integration and Continuous Deployment, aka CI/CD).
The two products are the Cisco CloudCenter Suite (CCS) and the Cisco Container Platform (CCP), briefly described in the following paragraphs before we go on to the demo.
Cisco CloudCenter Suite
Cisco CloudCenter Suite is a solution that helps the IT organization to enable developers and lines of business to deploy and operate a large number of applications and middleware platforms, made more complex by the availability of different possible targets (private and public clouds for running VM and containers).
CloudCenter Suite is a single tool that simplifies multicloud management by enabling organizations to design, deploy, and optimize infrastructure and applications across clouds by automating application deployment and consuming resources and services from any cloud. It helps to enforce a single governance model including cost control, approval processes, security policies and consistent architecture across different clouds.
The benefit is that you don’t have to learn and use the different tools from cloud providers, or replicate the automation blueprints using the native automation technologies in each cloud (e.g. Cloud Formation for AWS, Heat for Openstack, Powershell for Azure): you only create a single model and CloudCenter Suite translates it into a call to the specific API exposed by each cloud, including public, on-premises and Kubernetes clusters.
Everything you do in CloudCenter Suite can be done through its API, making it easier to orchestrate it externally (e.g. from Jenkins, through a plugin that Cisco ships so that you can insert multicloud deployments in your CI/CD pipeline).
The current version of the CloudCenter Suite also includes additional modules like the Cost Optimizer and the Action Orchestrator: a useful enhancement to create a governance model and make operations easy in a heterogeneous multicloud environment.
Cisco Container Platform
Cisco Container Platform is another software product from Cisco, that Operations teams can use to create and manage enterprise-grade Kubernetes clusters. It deploys, fully configures and manages (upgrades, scales, monitors) Kubernetes clusters on-premises and in the public cloud for you – it also supports additional native integration with AWS’s EKS. It takes care of all the complexity of integrating with networking (options offered out of the box are Calico, Contiv and Cisco ACI), storage, security (SSO and RBAC are added to Kubernetes) as well as centralized monitoring and logging (Elasticsearch, Fluentd and Kibana) while shipping 100% open source binaries from the upstream repositories. With Cisco Container Platform, DevOps teams can now extend their deployment environments to include Kubernetes-based containers, without the complexity of having to actually deploy and maintain it themselves.
Link to the demo
The second post in this series shows the implementation of the DevOps scenario in our lab and gives you all the insights about technology and products.
You can read it at https://blogs.cisco.com/cloud/devops-with-cloudcenter-suite-and-kubernetes-in-a-multicloud-environment-part-2.
Credits
The demo lab described in the post has been built with two colleagues and friends, that I want to thank here: Stefano Gioia and Riccardo Tortorici.
References
Recording of my session at Cisco Live Barcelona.
Great article, in the graph of IBM has a service called
IBM private Cloud that is mapped to on-premise.