Public Sector IT organisations are weary of vendor lock-in. And rightfully so: it is hard to buy cloud services from any supplier you choose and then freely manage these services as if they were part of your own extended private cloud. Main reason: lack of ability to connect different clouds: private, partner, public, etc. Luckily, this barrier is vanishing…
Thirty years ago, Cisco pioneered a strategy to connect previously isolated, heterogeneous networks, which lead to the rise of the Internet as we know it. Now, Cisco is embarking on a journey just as ambitious: the connection of multiple isolated clouds, leading to the creation of the Intercloud: an interconnected cloud of clouds.
The Intercloud relies on a five key principles and technologies, summarised below:
Read More »
Tags: cloud, data sovereignty, devops, govcloud, government, InterCloud, transparency
In this Season Finale of Engineers Unplugged, Joe Onisick (@jonisick) and Michael Ducy (@mfdii) discuss GoatOps. Yes, you read that right. What is GoatOps? What does this have to do with DevOps? This is all about process and the necessary changes to make Enterprise workflow flow in modern IT. This is a can’t-miss episode!
Unicorn Challenge, Goat Edition, with Joe Onisick and Michael Ducy
This is Engineers Unplugged, where technologists talk to each other the way they know best, with a whiteboard. The rules are simple:
- Episodes will publish weekly (or as close to it as we can manage)
- Subscribe to the podcast here: engineersunplugged.com
- Follow the #engineersunplugged conversation on Twitter
- Submit ideas for episodes or volunteer to appear by Tweeting to @CommsNinja
- Practice drawing unicorns
Join the behind the scenes by liking Engineers Unplugged on Facebook.
Tags: business transformation, devops, goatops, workflow
DevOps is gaining momentum in many enterprises today. Customers are increasingly realizing the benefits of DevOps and how it helps in breaking down barriers and helps application agility. DevOps enables a constraint free development, continuous application delivery, collaboration and continuous monitoring throughout the Application Lifecycle from Dev to Test to production deployments. A CA led global IT survey in 2013 projects DevOps adoption in 39% of the companies surveyed and another 27% in process of adoption, further testifying the momentum.
At CA World this week DevOps related topics feature prominently. Cisco Insieme Business Unit and CA are featuring a breakout session DCT33S on Tuesday Nov 11, on how CA Release Automation and Cisco ACI joint solution helps bring accelerated application delivery with collaboration and efficiency from design to deployment.
CA Release automation and Cisco ACI joint solution is a perfect marriage and showcase for Enterprise DevOps strategy. CA Release Automation enables continuous application delivery by automating application release execution to any environment and on top of any infrastructure whether it is virtual, physical or cloud. Cisco ACI with its Application Network profile and policy model helps provide secure, multi-tenant and a purpose-built Nexus 9000 network environment for compliant applications, across Dev/Test/Staging/Production stages of the application lifecycle.
CA Release automation uses the Application layout and intent to create Application Network Profiles (ANP) in Cisco APIC and also copies/clones the ANPs to quickly create parallel secure/multi-tenant networking environments on the Dev/Test/production systems. As a result, it is easy for CA Release Automation (CA RA) to move application releases quickly across the Dev/Test/production systems in highly compliant type application environments. Besides, Cisco ACI also enables IT to continuously monitor the configurations and application performance on these multiple tiers to enforce SLA per contractual agreements. The interactions between Cisco ACI and CA RA are illustrated in detail below.
It is not my intent to capture the entire session detail via this blog. To learn finer details of the ACI-CA RA solution, I strongly encourage you to attend the session DCT33S on Tuesday Nov 11. See you at the show.
Tags: CA Release Automation, Cisco ACI, devops, Nexus 9000, Secure Multi-tenancy
[Note: This is the last installment of a four-part series on the OpFlex protocol in Cisco ACI, how it enables an application-centric policy model, and why other SDN protocols do not. Part 1 | Part 2 | Part 3]
As noted earlier in this series, modern DevOps applications such as Puppet, Chef, and CFEngine have already moved toward the declarative model of IT automation, so there is already some obvious synergy between DevOps and the Cisco ACI policy model. DevOps automation products are also optimizing application delivery processes and are designed to automate critical IT tasks to make the organization more agile and efficient.
In an early 2014 blog post, Andi Mann, vice president of strategic solutions at CA Technologies, wrote about the evolution to DevOps and the synergy with the Cisco ACI policy model:
Though the DevOps approach of today—with its notable improvements to culture, process, and tools—certainly delivers many efficiencies, automation and orchestration of hardware infrastructure has still been limited by traditional data center devices, such as servers, network switches and storage devices. Adding a virtualization layer to server, network, and storage, IT was able to divide some of these infrastructure devices, and enable a bit more fluidity in compute resourcing, but this still comes with manual steps or custom scripting to prepare the end-to-end application infrastructure and its networking needs used in a DevOps approach.
The drag created by these traditional application infrastructures has been somewhat reduced by giving that problem to cloud providers, but in reality this drag never really went away until Cisco innovated application-centric programmability with Cisco ACI. This innovative new solution is now poised to greatly benefit the whole application economy, especially management of the DevOps application environment…
Read More »
Tags: CA Technologies, CFEngine, Chef, Cisco ACI, devops, OpenFlow, OpFlex, ovsdb, Puppet Labs, SDN
[Note: This is the third a four-part series on the OpFlex protocol in Cisco ACI, how it enables an application-centric policy model, and why other SDN protocols do not. Part 1 | Part 2 | Part 4]
The Cisco ACI fabric is designed as an application-centric intelligent network. The Cisco APIC policy model is defined from the top down as a policy enforcement engine focused on the application itself and abstracting the networking functions underneath. The policy model unites with the advanced hardware capabilities of the Cisco ACI fabric underlying the business-application-focused control system.
The Cisco APIC policy object-oriented model is built on the distributed policy enforcement concepts for intelligent devices enabled by OpFlex and characterized by modern development and operations (DevOps) applications such as Puppet and Chef.
At the top level, the Cisco APIC policy model is built on a series of one or more tenants, which allows the network infrastructure administration and data flows to be segregated. Tenants can be customers, business units, or groups, depending on organization needs. Below tenants, the model provides a series of objects that define the application itself. These objects are endpoints and endpoint groups (EPGs) and the policies that define their relationships (see figure below). The relationship between two endpoints, which might be two virtual machines connected in a three-tier web application, can be implemented by routing traffic between the endpoints to firewalls and ADCs that enforce the appropriate security and quality of service (QoS) policies for the application and those endpoints.
Endpoints and Application Workloads Along with Tenants and Application Network Profiles Are the Foundation of the Cisco ACI Policy ModelEndpoints and Application Workloads Along with Tenants and Application Network Profiles Are the Foundation of the Cisco ACI Policy Model
For a more thorough description of the Cisco ACI application policy model, please refer to this whitepaper, or this one more specifically on Endpoint Groups.
For this discussion, the important feature to notice is the way that Cisco ACI policies are applied to application endpoints (physical and virtual workloads) and to EPGs. Configuration of individual network devices is ancillary to the requirements of the application and workloads. Individual devices do not require programmatic control as in prior SDN models, but are orchestrated according to the centrally defined and managed policies and according to application policies.
This model is catching hold in the industry and in the open source community. The OpenStack organization has begun work on including group-based policies to extend the OpenStack Neutron API for network orchestration with a declarative policy-based model based closely on EPG policies from Cisco ACI. (Note: “Declarative” refers to the orchestration model in which control is distributed to intelligent devices based on centralized policies, in contrast to retaining per-flow management control within the controller itself.)
Read More »
Tags: Chef, Cisco ACI, Cisco APIC, devops, Group Policy, Open Daylight, OpenStack, Puppet, SDN