devopsy.kinsta.cloud

Tag: orchestration

  • The DevOps value stream is not SOP

    The DevOps value stream is not SOP

    #devops #lean Don’t confuse doing something faster with greater efficiency.

    Much of the focus on DevOps remains at the implementation level – on gaining efficiencies through automation of tasks and orchestration of processes. While this is not a bad thing, such a micro-focus on the moving parts can result in the loss of efficiencies to be gained at the macro-level.

    One of the biggest inhibitors of a timely release cycle is not the moving parts, but rather the process in which those moving part are executed. It’s not necessarily the actual push into production that’s problematic, but the length of time it takes to accomplish certain tasks when they cross internal organizational boundaries.

    For example, many years ago we began the process of pushing a new application into production – a web application. This required, perhaps obviously, changes to the corporate firewall. The “process” for accomplishing this change – essentially opening a port on the firewall for the intended public IP address – required no less than five different signatures across networking, security and architecture teams. There were only two security roles allowed to approve such a change, and the process was noted as taking up to 15 days to get a signature on a piece of paper and subsequently a rule change.

    err is humanThis was not a task level problem. It was not implementation issues. It wasn’t even difficulty in making the change on the firewall. It was all about the process. Scheduling a release meant taking into consideration not only the readiness of the application itself, but its supporting services – including networking.

    This is why DevOps should start with a review of the processes used to release an application into an environment (whether test, QA or production). Mapping out the process is the first step to finding where the bottlenecks might be that are causing delays in moving that application to the next phase of its lifecycle.

    Simply automating an existing process may not provide the value expected or touted by DevOps supporters, because if the process is poor, you just end up doing something poorly much faster.

    In other words, the value of DevOps is not necessarily in simply automating SOP (Standard Operating Procedure).

    The initial Value Stream Map captures the current process as it exists.  This is known as the “As Is.”  It is the actual process flow and should be created through observation of the current flow and with participation of those who are in the process.  Do not make the mistake of pulling a process map from the procedural manual (SOP).  The best technique for mapping is to be the unit (the “thing”) coming through the process. For example, in the insurance industry it might be the policy.  In the auto industry, it may be the car.  In each instance, the Value Stream Map begins with the request for the unit i.e. insurance policy or car.  [emphasis mine]

    http://www.goleansixsigma.com/how-to-visualize-a-process-with-a-value-stream-map/

    For application deployment, the “thing” is … an application, and the process should be mapped based on what’s actually happening. Only when you have the process mapped can you evaluate it for bottlenecks and understand the steps of the process at which each group adds value. Value is defined as any step that moves the thing (the application” toward the end goal. Efficiency is then measured as a percentage; specifically it’s the value added time as a percentage of the total time it takes to complete the process (the cycle time).

    Don’t confuse doing something faster with greater efficiency. If every step of the cycle is automated, the actual process efficiency hasn’t changed. The ultimate goal of DevOps should be about improving the efficiency of these processes, not just doing what’s always been done faster.

    Some of the opportunities for improvement in efficiency that will surface is certainly interfaces with other organizational groups. Perhaps it’s that a process step might not take as long if you had relevant data or information up front. If you’re wasting time waiting for some piece of information, that’s not value added time. It’s just cycle time. More cycle time reduces the efficiency of the overall process by overloading it with wasted time. Better information gathering up front can help reduce the wait time and immediately provide greater efficiency of the process.

    It is these opportunities for improvement that will be particularly helpful in the enterprise arena, where the issue is not so much attempting to hit ten deploys a day, but rather the predictability and efficiency of the processes that enable teams to hit a specified change window as desired.

    DevOps is not about the tools, or the automation of manual tasks. It’s about the big picture, and that means gaining greater efficiencies through process re-engineering and orchestration as well as automation. Focusing on the micro aspects of DevOps will only ensure that if you’re doing it wrong, you’re doing it wrong faster. Step back and look at the big picture, and find those process steps that are really causing inefficiencies in your organization.

  • Avoiding Parrot Processes

    Avoiding Parrot Processes

    One of the things devops practitioners are tasked with is the provisioning and configuration of all sorts of infrastructure.  Application servers, web servers, load balancers, proxies and database servers are among the lengthy (and no doubt growing) list of “boxes” devops needs to get up and running to support just about any given application today. One of the key value propositions of a devops approach to operations is that it can reduce the time it takes to get applications to market by getting them up and running in production faster. That’s increasingly important as we move into the Era of Things, driven by extreme connectivity of everything, because all those “things” need are going to need to be talking to applications on the back side.

    parrot-proceses

    So speed is of the essence, but not at the cost of accuracy. We’re encouraged, then, to automate tasks and orchestrate processes to achieve that speed. The side effect of codification of tasks is higher accuracy (aka fewer mistakes).

    So far so good.

    But you may notice that I have (and will continue to) clearly delineate between “automate” and “orchestrate”, between “task” and “process”.

    The reason for that is that, simply, they are not the same thing. We should strive not to confuse these two because while the two share some benefits, there are other benefits that are achievable only by one or the other – or the combination thereof.

    Process optimization, for example, can’t be achieved by simple automation. Automation is concerned with a single task – launching a web server, configuring a web server, stopping a service. Orchestration, however, is concerned with automating, if you will, the execution of a workflow – of a process. A provisioning process may be comprised of multiple tasks and involve multiple systems. An “application” is not just a single server, after all, it’s likely several servers – web, app and database in a traditional three-tier architecture.

    The goal of orchestration is not just to automatically execute a service, which brings speed to the deployment process and gets applications into production faster. It also affords an opportunity to streamline – to optimize – those processes for even greater gains in deployment velocity.

    One of the simplest ways to optimize a process is to eliminate repetitive steps. This entry on Vagrant explains it fairly well :

    “We could just SSH in and install a webserver and be on our way, but then every person who used Vagrant would have to do the same thing. Instead, Vagrant has built-in support for automated provisioning. Using this feature, Vagrant will automatically install software when you vagrant up so that the guest machine can be repeatably created and ready-to-use.” [emphasis mine]

    — Vagrant Docs “Getting Started | Provisioning”

    Now certainly the step of installing a web server on a new box with vagrant is hardly all that time consuming, it’s just a single line of text. But every line of text must be manually typed, and that introduces the possibility of fat fingering the command, which either consumes time in fixing it or introduces an error into the system. Neither are desirable results.

    Ensuring that the process is repeatable and orchestrated by automating all the tasks that comprise that process can optimize it by eliminating redundancy. That results in greater deployment velocity.

    So while you’re “doing devops”, remember to evaluate the processes and consider whether or not they’re repetitive, and how you might be able to eliminate that repetition through more modern architectures or toolsets.

  • Automation versus Orchestration

    Automation versus Orchestration

    Yes, Virginia, there is a difference.

    One of the things devops practitioners are tasked with is the provisioning and configuration of all sorts of infrastructure.  Application servers, web servers, load balancers, proxies and database servers are among the lengthy (and no doubt growing) list of “boxes” devops needs to get up and running to support just about any given application today. One of the key value propositions of a devops approach to operations is that it can reduce the time it takes to get applications to market by getting them up and running in production faster. That’s increasingly important as we move into the Era of Things, driven by extreme connectivity of everything, because all those “things” need are going to need to be talking to applications on the back side.

    So speed is of the essence, but not at the cost of accuracy. We’re encouraged, then, to automate tasks and orchestrate processes to achieve that speed. The side effect of codification of tasks is higher accuracy (aka fewer mistakes).

    So far so good.

    But you may notice that I have (and will continue to) clearly delineate between “automate” and “orchestrate”, between “task” and “process”.

    The reason for that is that, simply, they are not the same thing. We should strive not to confuse these two because while the two share some benefits, there are other benefits that are achievable only by one or the other – or the combination thereof.

    Process optimization, for example, can’t be achieved by simple automation. Automation is concerned with a single task – launching a web server, configuring a web server, stopping a service. Orchestration, however, is concerned with automating, if you will, the execution of a workflow – of a process. A provisioning process may be comprised of multiple tasks and involve multiple systems. An “application” is not just a single server, after all, it’s likely several servers – web, app and database in a traditional three-tier architecture.

    The goal of orchestration is not just to automatically execute a service, which brings speed to the deployment process and gets applications into production faster. It also affords an opportunity to streamline – to optimize – those processes for even greater gains in deployment velocity.

    One of the simplest ways to optimize a process is to eliminate repetitive steps. This entry on Vagrant explains it fairly well :

    “We could just SSH in and install a webserver and be on our way, but then every person who used Vagrant would have to do the same thing. Instead, Vagrant has built-in support for automated provisioning. Using this feature, Vagrant will automatically install software when you vagrant up so that the guest machine can be repeatably created and ready-to-use.” [emphasis mine]

    — Vagrant Docs “Getting Started | Provisioning”

    Now certainly the step of installing a web server on a new box with vagrant is hardly all that time consuming, it’s just a single line of text. But every line of text must be manually typed, and that introduces the possibility of fat fingering the command, which either consumes time in fixing it or introduces an error into the system. Neither are desirable results.

    automate-orchestrate

    Ensuring that the process is repeatable and orchestrated by automating all the tasks that comprise that process an optimize it by eliminating redundancy. That results in greater deployment velocity.

    Recognizing that processes should be comprised of composable tasks offers a higher degree of reuse across operations. The task of provisioning and configuration a web server with the appropriate base software means consistency, aka standardization, across all applications. Processes that take advantage of standardization result in greater infrastructure stability, another benefit often cited by organizations that have adopted a devops approach to operations.

    iweek-devops-stability

    The key here is to recognize the difference between automation and orchestration and how they relate to one another. Automation is about codifying tasks and orchestration is about codifying processes. Orchestration takes advantage of automation by reusing these basic building blocks.

    There is a difference, and done right, the two play off one another to result in streamlined, more accurate execution of operational processes that speed up successful application deployments.

  • Partnership Between Tufin, Puppet Labs Indicates Need for Security Baked Into DevOps

    Partnership Between Tufin, Puppet Labs Indicates Need for Security Baked Into DevOps

    A recent partnership between the IT automation developers at Puppet Labs and the security policy orchestration gurus at Tufin Technologies could start setting the pace for how orchestration of security policies can more easily be baked into DevOps practices. Announced at last month’s RSA Conference, the partnership yielded an integration between Puppet Enterprise and Tufin Orchestration Suite. This will make it possible for joint customers to streamline the configuration and provisioning of security policy changes to iptables, a host-based firewall commonly found on physical and virtual Linux servers.

    “We expect Security Policy Orchestration to become a core requirement for our customers,” says Nigel Kersten, CIO at Puppet Labs. “Integrating with Tufin enables our customers to quickly and effectively address connectivity requirements across the enterprise without compromising security.”

    The integration is an indication of the market’s need for better tools to help DevOps shops speed up the pace of application and network changes while maintaining a strong security and compliance posture. Today’s firewall and security policy changes are often handled in a manual, error-prone process—even at some of the largest enterprises.  A recent survey commissioned by Tufin found that the vast majority of IT professionals reported having to correct 20 percent to 60 percent of security policy changes in their organizations after the fact.

    “This is incredibly useful to our customers and ensures that security is woven into the server’s connectivity requirements,” says Reuven Harrison, CTO of Tufin. “As the convergence of security and network operations continues, this module enables our customers to manage change with automation that delivers tangible business value.”

    According to Harrison, firewalls play a dual role in network operations, both providing security through network segmentation and connecting applications to the network across multiple touch points.

    “It’s the latter that makes them relevant to DevOps folks,” he says. “Firewalls see the both application and the network, which makes them an ideal source of information for modeling applications.  Load-balancers are also good for this.”

    This is why the industry is starting see a convergence between these two technologies, and also why Tufin has pushed for an evolution from firewall management into the sphere of security policy orchestration.

    “Security policy orchestration aids with use cases for firewalls and other network infrastructure as they relate to applications,” Harrison says. “It ensures security policy changes are automated and account for security and compliance considerations not just for network access but also for application connectivity.”

    Harrison believes that while security may not necessarily be the chief selling point for evolving to DevOps practices at some firms, the movement could present opportunities to more closely fold security into a more rapid application release cycle. He believes it will be an imperative in complex cloud environments.

    “As cloud infrastructure matures and gains acceptance from larger and more traditional companies, security will have to be baked into the application release process,” he says. “That means securing not just the application code but also the infrastructure on which it resides.”

    As things stand, Harrison believes that security is typically split into two distinct layers. There’s the application security layer, typically dominated by code security and penetration testing and then network security that is preoccupied by zone segmentation, encryption, authentication and the like.

    “Eventually these two layers, along with some emerging technologies such as virtual networks, will converge,” he says, “and DevOps will handle it end-to-end.”

  • Why Baking Security Into the DevOps Framework is Vital to Its Success

    Why Baking Security Into the DevOps Framework is Vital to Its Success

    I attended my first official DevOps conference in Israel in September 2013.  But I was initially introduced to DevOps by my customers – firewall and network managers who, through their efforts to automate  security policy management, found themselves dealing with a new and like-minded set of IT stakeholders  –  DevOps teams.

    They said DevOps was also all about automation – automation that allowed IT to increase their business contributions by enabling new applications and other IT services to be rolled out faster with greater control and efficiency.  

    Conceptually, it was clear to me that the DevOps value proposition is just as relevant to Security as it is to Operations and Development groups, especially since Security teams apply automation with the same fervor as DevOps.  

    In fact, using automation to accelerate IT has caught hold in the network security world to fuel a new movement and class of solutions, called Security Policy Orchestration.  As the CTO of Tufin, a Security Policy Orchestration company, I could not help but recognize the synergies.  I was (and still am) intrigued by DevOps, so when I heard about the conference, I decided to go.

    And I am so glad I did.

    The alignment between DevOps and Security Policy Orchestration is obvious. They both champion the use of automation to accelerate the pace of business. We Security Policy Orchestration folks are just coming at it from a different area within the organization.  Kindred spirits, right?

    In theory, absolutely, but in reality…not so much.

    The conference as a whole was great.  It completely validated my theories regarding the synergies between Security Policy Orchestration and DevOp.  But what surprised me was that security was a topic that was not being discussed at all at the conference.   Maybe a hat-tip to application security, but network security was not even on the DevOps radar, at least not at this particular conference.

    It needs to be.  For DevOps, to really be able to move the needle, we have to work together.  If history has taught us anything, it’s that when new applications and services are not created or rolled out with security in mind, at some point we will have to go back and retrofit it back in.

    Envision the typical experience:   the development team builds a new application, brings IT Operations in to implement it.  Once that is done, IT Ops prides itself on all the corkscrewing it took to make the application work on the actual infrastructure.  Except for once the app is in production, it doesn’t work.  The troubleshooting begins.  Invariably, issues of network connectivity come up.  Solving them requires app, dev and security managers to break down the cultural and organizational barriers that exist within their organizations to work together to ensure the application is architected correctly into the network.  This starts and the process of change requests between AppDev and IT to get the app up and running. 

    If that process is not automated, it can take months longer than it needs to resolve everything.   Not to mention any company subject to PCI has to consider terms like secure zoning, a concept that is not second nature to DevOps folks.   If PCI is not an issue, there are plenty of other internal and regulatory mandates and security –related considerations that, if for no other reason than common sense, can exponentially reduce the chances of a company ending up in the headlines due to an APT.    

    These are just a couple of many scenarios that can be avoided if development, IT and security work together from the get go.

    The net/net is that Dev and ops have the same goal but they are siloed, which is slowing down the pace of business – inhibiting it.  Collaboration is not some warm and fuzzy team-building thing – it is a fundamental business requirement.

    And that’s why I am so excited to have the opportunity to do this blog.  I think I can add a unique perspective on how DevOps and Security can work together to reach our common goals.

    My next post will explain will dig into what Security Policy Orchestration actually is, so we can begin to tease out the similarities and determine how to build on that to true alignment and partnership. 

    Stay tuned as the drama unfolds! This should be fun….

  • Tufin Partners with Puppet Labs to Automate and Orchestrate Security Policies for Host-Based Firewalls

    Joint Customers Can Now Increase IT Agility and Improve Security Through Central, Automated Management of iptables Firewalls

    Published: Tuesday, Feb. 25, 2014 – 5:08 am

    MORRISTOWN, N.J., Feb. 25, 2014 — /PRNewswire/ — Tufin Technologies, the market leading provider of Security Policy Orchestration solutions, today announced an integration that enables Tufin customers to leverage the IT automation capabilities of Puppet Enterprise, Puppet Labs’flagship commercial product, to configure and provision security policy changes to iptables, a host-based firewall commonly found on physical and virtual Linux servers. The ability to automate and orchestrate iptables policy changes improves collaboration and information sharing across server, application and security operations teams and ensures that network connectivity changes for iptables-protected servers are implemented securely, accurately, and at the pace of business. Concurrently, Tufin is also announcing new security, automation and orchestration capabilities as well as the results of a recent survey that underscores the need for automation to effectively manage change in today’s highly complex, dynamic and distributed network environments.

    “This integration enables our customers to leverage Puppet Enterprise’s automation prowess to automate application connectivity in both on-premise and previously uncontrolled environments such as cloud deployments and virtualized environments,” said Reuven Harrison, CTO, at Tufin. “This is incredibly useful to our customers and ensures that security is woven into the server’s connectivity requirements. As the convergence of security and network operations continues, this module enables our customers to manage change with automation that delivers tangible business value.”

    The Tufin Orchestration Suite™ enables organizations to increase automation and accelerate the pace of network infrastructure changes while maintaining security and compliance. Puppet Enterprise provides system administrators the operational agility, efficiency and insight they need to proactively manage a dynamic infrastructure, scaling from tens of servers to thousands on-premise and in the cloud.

    “This integration gives joint customers the ability to provision changes to iptables security policies,” said Nigel Kersten, CIO at Puppet Labs. “We expect Security Policy Orchestration to become a core requirement for our customers, and integrating with Tufin enables our customers to quickly and effectively address connectivity requirements across the enterprise without compromising security.”

    About Puppet Labs Puppet Labs, Inc. is the leader in IT automation. Puppet Labs’ software provides system administrators the operational agility, efficiency and insight they need to proactively manage dynamic infrastructure, scaling from tens of servers to thousands, on-premise and in the cloud. Thousands of the world’s leading organizations use Puppet Labs’ software to configure and manage their IT infrastructure, including Citrix, eBay, NYSE, Cisco WebEx, Salesforce, Bank of America and PayPal. Based in Portland, Oregon, Puppet Labs employs more than 250 people. The company is backed by investors Kleiner Perkins Caufield & Byers, Google Ventures, VMware, Cisco, True Ventures, Radar Partners, and Emerson Street Partners. To learn more, please visit www.puppetlabs.com.

    Puppet Labs and Puppet are trademarks of Puppet Labs Inc. All other company and product names mentioned are used only for identification purposes and may be trademarks or registered trademarks of their respective companies.

    About Tufin Technologies Tufin® is the leader in Security Policy Orchestration, automating and accelerating network infrastructure changes while maintaining security and compliance. By improving network change processes, organizations using the Tufin Orchestration Suite™ will have a positive impact on the business by reducing the time and cost spent implementing network changes by up to 80 percent. Taking a holistic view of IT, the Tufin Orchestration Suite helps organizations automate security and efficiency into day-to-day operations, enabling them to be more agile and leverage technology to gain a competitive advantage. Founded in 2005, Tufin serves more than 1,300 customers in industries from telecom and financial services to energy, transportation and pharmaceuticals. Tufin partners with leading vendors including Check Point,Cisco, Juniper Networks, Palo Alto Networks, Fortinet, F5, Stonesoft, Blue Coat, McAfee and BMC Software, and is known for its technological innovations and dedicated customer service. For more information visit www.tufin.com, or follow Tufin on:

    Twitter: http://twitter.com/TufinTech