devopsy.kinsta.cloud

Tag: automation

The Automation Continuum
The speed of innovation these days is often influenced by the speed of adoption of new and exciting tools, and specifically open source tools. Open source projects have been growing at an exponential speed over the course of the past few years; however the process for exploring, testing, configuring, and ultimately integrating these in production often times is still quite complex and time consuming. In many cases, this process is still done manually. Like with all DevOps processes by automating this, we are then able to adopt new tooling much more quickly, and with less human error in the process.

The Open Source Revolution

The friction in this process is due, in large part, to the fact that each of these stages from exploration through POC and testing, integration and then management, many times requires the use of very different tools for each stage, on top of a completely different setup and environment. This means that every time you want to move from exploration to testing, for example, you have to basically rebuild the entire system. This can become quite frustrating and, as mentioned above, time consuming.

What if we could streamline this process and explore tens and even hundreds of projects quickly, thereby enabling us to seamlessly increase our innovation?

How this could work – the flow:
1. Exploration: Explore the product without having to install any software at all. This could be through a click of a button on Github, and seeing the product in action. This would enable you to play with it without having to download, configure, or set up any machines.
2. Testing: When we move to trying it out, we want to use the same model as in the exploration phase. We’d like to try it out also on a SaaS basis, but this time with more control. By this I mean testing with real clusters & machines, in a more high performance, and production-like environment.
3. Development: At this stage, we want to be able to test it with our actual stack, and plug it into our project quickly. Then, eventually at a later stage download it and run it in our own environment.
What’s Needed

With a unified tool for all of these stages, the majority of the friction in the process can be diminished. One way to achieve this is by running the project as a service or in our environment, with an orchestration engine that can basically be used to take us through all these stages.

By wrapping the entire project into an uber-launcher [which with Cloudify we call it “the widget”] that any open source project can plug into – like an app store or repository, and any user can start using immediately without necessarily having to know how exactly it runs or works.

The nice thing is that we can eventually take the software from that app catalog or store, since it’s not packaged as a black box but rather as a blueprint or script. We can then fork it and customize it to our needs. Because of this, we can actually use the same tools through the entire cycle and break the friction completely.

So what it all boils down to, is the basic principle of combining the power of SaaS and cloud orchestration to avoid complexity of installation, use a script-based model to make the packaging of software generic – but still customizable, and use a cloud abstraction to move environments without having to change recipe. This is what we call the automation continuum, and we’ve been using to demonstrate how to take the power of any open source project to any cloud.
March 25, 2014
Config Management & F***ing Shell Scripts

Joke tech projects pop up all the time. Some, like the lamentable titstare, should never have seen the light of day. Others, like Mark Zuckerberg’s Facemash start out as a joke and grow into something that is anything but. Most come and go without anyone really noticing.

Whilst their lives are typically short we often learn more from people’s reactions to these projects than we do from their use of them. An excellent example of this popped up recently when a couple of frustrated Chef and Ansible users came up with a simple configuration management alternative, the regrettably named F***ing Shell Scripts (FSS). As they explain it, as in “Why can’t we just use f***ing shell scripts?”.

Whilst usability issues with configuration management tools – particularly in the Enterprise – is a topic close to my heart, I would not normally have had much more than a passing interest in FSS. What grabbed my attention was the reaction it elicited when posted to Hacker News. With over 150 comments FSS clearly touched a nerve.

Now to clarify, the authors of the project were quite definitive in assuring the mob that they had created FSS as a joke:

We wrote it literally in an afternoon, and were giggling like schoolgirls the whole time.

People either missed this, or chose to ignore it:

“This is simply brilliant! I’ve dreamt about such tools.”
– artellectual

“I’d love to see a tool like yours be brought to full maturity, then I think I’d love to use it.”
– sdegutis

It provided a perfect platform for many to voice their frustrations with current tools:

“Even for an experienced sysadmin, using Puppet and Chef to do even a trivial project (replacing a ~10 line shell script) took a painful couple of days.”
– mattjaynes

“In my experience, there’s a huge amount of work involved in just getting Ansible (and other CM systems) to work right in the first place”
– s_kilk

“We’re using Chef right now, and evaluating other options. They seem to either be between way too over-engineered, or not flexible enough, but nowhere in between.”
– sdegutis

“Keep it simple. puppet/chef have horrendous DSL’s that make it really complicated to reason about.”
– sp1982

In the interest of balance I should point out that there were some voices of support amongst the crowd. Ansible in particular won praise for the effort its team has put into simplifying things.

Overall though I was still blown away with the level of frustration being expressed. Automation tools have been around for years now; CFEngine, the grandfather of the modern tools was created in 1993. Despite this, a tongue in cheek project suggesting ditching them all in favor of the technology they set out to replace (or at least abstract away), shell scripts, is considered credible. For me this is akin to people ditching virtualization for physical boxes. It just doesn’t make sense.

Unless of course something is still fundamentally broken in the approach the current set of tools is taking; that they are still too hard; that they still fail to address key prerequisites like visibility and accountability. I believe that this is the case because I’ve experienced it first hand; I’ve seen it a hundred times in businesses I’ve talked to, and threads like the Hacker News one mentioned above leave little room for alternative interpretations. Heck, we’ve based our product GuardRail on this entire premise; these are not empty words on my part.

Incremental improvements such as those offered by Ansible are a good thing, but what people seem to be searching for is a step change. As things stand this is less likely to come from the current batch of tools, and far more likely to come in the form of a new approach. Docker anyone?

March 24, 2014
What “Programmable” Means

One of the most often used words these days to describe emerging architectures and technology is (drum roll please) “programmable.”

Now, from my used-to-be-a-developer-and-architect-turned-infrastructure-geek perspective, I know what that means. It means I get to write code. But to what purpose that code is put to is a question that’s rarely answered. So today we’re going to answer it because, well, my used-to-be-a-developer-and-architect-turned-infrastructure-geek persona likes to talk about code.

When you hear the term programmable used in the context of Software-Defined Networks (SDN) they’re talking about the same things that “programmable” means in the context of Devops: programmatic control of both the data and the control path.

The easiest way to visualize the difference between these impressive sounding terms is to recognize that the data path is inside and the control path is outside.

What that means is if you’re interacting with the data path, you are participating in it. You can inspect it, evaluate it, and transform it and, perhaps more importantly, you can make decisions based on data in flight. That’s powerful for the network, because a variety of Devops patterns are based on this very concept and require the network for implementation. Consider, for example, the implementation of an A/B testing pattern. The basic premise of the pattern is that somehow the identity of a user is known and, based on their membership in a defined group (beta testing customers, roles within the organization, volunteers from the community, etc…) they are routed to different versions of the same application to determine how differences in the UI impact behavior.

Notice the term routing, which implies it is a function of the network. The reason programmability is critical is two-fold: one, you must be able to identify the user as belonging to a specific group and two, you must be able to dynamically route based on that information. The former, identification, could ostensibly be accomplished using fixed lists IFF (If and Only If) it is possible to map a user to some variable readily accessible to the network, which traditionally means things like IP and MAC addresses and TCP ports. Most folks will immediately recognize that today this isn’t enough (and actually it hasn’t been enough since the days of the mega-proxy, but I digress). The information that’s needed is much higher in the networking stack at the application layer, aka in the OSI model as Layer 7. Which means you’re probably going to have to dig into HTTP headers and maybe the payload to get the data you want. That requires programmability in the data path, inside.

To really make the pattern scale (and to make it flexible enough to support a phased approach to beta testing) you probably don’t want group membership to be a static, fixed thing. So now you’re going to want to extend your implementation to include making a call to a database or identity store (LDAP, AD, etc…) to get current information. That requires programmability in the data path, inside.

So what programmability in the data path means is the ability to use code to direct the behavior of some “thing” in the network, be it an application proxy or a load balancer or what have you. You can’t easily do this through configuration-based proxies because they don’t allow for the execution of the domain logic necessary. There are a limited number of interactions you can achieve with configuration-based systems because of the logic they’re hard-coded to execute,and most of them don’t include calling out to a data store to look-up arbitrary information.

Data path programmability = Code in Flight. So you now you know where the name of the blog came from. This developer-and-architect-turned-infrastructure-geek finds the intersection between programmability and networking irresistible.

Okay, so that’s data path programmability. What about control path programmability?

Well, that’s the easy part. Control path programmability is on the outside. It’s the APIs that enable automation and orchestration of provisioning and configuration. Control path programmability is how you integrate infrastructure into command control systems like OpenStack, Puppet and Chef. Infrastructure comes with varying degrees of API-enablement, some extremely granular and others less so, depending on the particular function and maturity of the vendor.

So what you can do with the control path depends on the API, but in general it enables things like provisioning new services – think configuring a new virtual server in Apache and all the settings that accompany it – or start up and shut down functions that enable rolling maintenance across a set of devices or servers to avoid downtime.

But all control path programmability is on the outside, enabling integration and management without having to learn a CLI or configuration file syntax.

SDN and Devops use both programmability to reach relatively the same goals: scale of operations, rapid provisioning of services, to decrease the possibility of human error (the fat finger factor) and to introduce flexibility into systems that were previously bound to fixed processing and configuration-based paradigms.

Programmability in the network is going to enable a variety of new patterns, processes and services and as traditional infrastructure becomes more and more programmable through the adoption of architectural approaches like SDN, Devops is going to see more and more opportunity to apply its maturing expertise in leveraging programmability to a much wider audience.

March 24, 2014
Don’t let automation be the tail wagging the dog

There is quite a bit of talk right now about DevOps and how important automation is. This could be compared to GM in the 1980s when the company tried to transform the way they built cars through automation and robot. In the early 1980’s GM spent $90B dollars in an attempt to speed up the way cars were delivered to the market. This failed with famous stories of robots painting each other and others welding doors shut. Ultimately this project failed and the robots were scraped. It was later reported that the money lost on the project could have been spent to acquire both Toyota and Nissan at the time.

Automation dominates the conversation when it comes to DevOps. If you do not learn how to build cookbooks you are not doing DevOps. I fear this is going to set companies trying to transform IT off on the wrong track, focused on the outcome and not on the scientific process to get there. Alan Sharp-Paul recently wrote that you cannot automate what you don’t understand. The best way to understand it is in two key ways, change and performance.

Let Science set you free

This was the secret that Toyota used to dominate the automobile industry. They were able to transform all of their employees into little scientist. Constantly tinkering to squeeze our inefficiencies in the system. Every worker was empowered to think how things could be done better.

At the heart of the agile and DevOps processes is the practical application of the scientific method. Think back to your 8th grade science fairs. No not the volcanos but the ones that won best of show. These had a clear hypothesis that stated what they were going to try and prove. They were able to understand what they were going to change and measure the difference between the before and after. They could clearly state what changed and if it was a successful experiment or a failure.

This thinking is key for companies trying to transform to a DevOps IT organization. If a company does not understand the experiments that are running and what the outcomes should be then automation will just make the problem worse. That is why change management and performance management are foundational for transforming to a DevOps culture.

Tracking your experiments

Any good scientist knows exactly what he is working on. He knows every experiment that is running anticipating the outcome. He knows all the details about each change that has been made to see how they impact the outcome. This is the same way that IT should be tracking every change happening.

Every change done in IT is a scientific experiment running. Tracking every change allows for understanding of the outcome of changes within the application. Developers and Operations will be more informed about the cause and effect of their changes. There are multiple different ways that you can track changes but the key is that you are doing it very well before you start to apply automation.

Measuring the outcome

There is no need to track the experiments if there are not being measured. A scientist is very deliberate in how they measure the outcomes. Good enough just does not get this done. This is beyond just monitoring. Monitoring in a lot of cases is after the fact, in production. This is about measuring the difference for every experiment regardless of where it is being tests. This creates the need to test changes all the way to when the first functional tests are done, measuring the changes of every code update. Following it through all of testing and to production. Understanding how each experiment impacts the system as a whole.

Efficiency through automation

Once there is good understanding of all the experiments and a standard platform for measuring the outcome then automation starts to return exponential benefit. Because every experiment it known the lower priority ones can be identified and automated. Risk is better assessed. Processes can start to speed up because there is visibility and accountability. Applications are no longer classified as high risk or low risk only change is classified that way. Determining what can be automated just becomes another experiment that is tried and measured for success and and failure. Automation becomes just another outcome of DevOps to the business and not the route to achieve it.

March 21, 2014
Survey Says: Positives and Negatives of DevOps are Two Sides of the Same Coin

Isn’t that the way it always works? A person’s strength can also be their weakness. A company’s killer product becomes their Achilles heel as the market shifts. As more and more companies make the shift to DevOps, it’s interesting to learn what’s working, what the opportunities are, and what the impediments are. As many of you know, my company, JumpCloud, along with SoftLayer hosted the 2013 DevOps Conference in Boulder, CO. We had over 200 amazing people in the room – developers, ops folks, managers, execs, CEOs, and founders. Really, the whole gamut was represented in some way. It was an intense day full of presentations and panels, but with lots of time for discussion – with the audience even participating numerous times during talks!

As part of the conference, we surveyed the audience on a number of topics related to DevOps. The results of the survey are here and the press release announcing the results with some analysis is here as well. As I sat back to take in the data, the most significant learning for me was that the movement to DevOps is constrained by time, first and foremost, and one of the opportunities of DevOps is automation. Let me say that again a different way: the very thing that companies are trying to solve – moving faster, is the thing that is preventing them from getting there.

Lack of time is nothing new for IT people. We have been hearing that for decades. For some reason, the IT organization has always been crushed with the amount of work that they have and the resources available. Perhaps it is that they are involved in just about everything going on in an organization, or as is the case today in many businesses, the IT organization is the business. As a result, it is even harder for organizations to find the time to do the very things that will make them more efficient. Unfortunately, the cycle becomes a self-fulfilling prophecy and as organizations get more busy, they find less and less time to ‘fix’ their business.

The survey data from the DevOps conference showed that there are any number of opportunities to automate tasks. The group gravitated to a few – deployment, patching, user management, and log analysis – but there were many more. Each organization has their list of tasks that need to be automated that they never get to. The lost productivity from those missed opportunities is likely staggering. Automation is hard and painful. Especially when you are trying to run the day-to-day business. As one of my marketing friends liked to say, we are rebuilding the car while it’s going 60 MPH.

It’s easy to say that the solution to this is just to spend some time automating. Allocate more hours to it and put it into each sprint. Yes, that is easy to say. Unfortunately, that rarely works. The pressures of the business take over and move automation back down the list very quickly. After all, features need to be built, bugs need to be fixed, and performance issues need to be resolved. All higher priority items than automation when you are in the crucible.

The focus on automation has to come culturally to work long-term. There needs to be recognition from all levels of the organization that automation will take precedence over other tasks. Without that perspective, automation will almost always be pushed down the priority stack. Automation is a long-term play, not a short-term gain. Band aid fixes are quick and get you back to your task list. Automation takes deliberate time, effort, and focus to happen, and then the benefits are only seen afterward. Of course, the benefits are subsumed by other tasks until they too are automated, so it’s hard to see them for long, but they are there. And, in fact, as more and more becomes automated, a company starts to see their velocity increase dramatically. They’re not focused on manual tasks, they’re focused on driving new innovative features.

The DevOps survey really said it all – organizations that can figure out how to get off the hamster wheel of manual tasks, will automate and build high-velocity organizations. Unfortunately, that is easier said than done.

March 17, 2014
Let the Code do the Heavy Lifting

One of the first jobs I had when I started in IT was as the IT administrator for a dot.com startup. IT admin at a smaller company like that was typically an umbrella term used to describe a one-man IT department, which is essentially what I was.

The company was growing exponentially—both in terms of customers and revenue, as well as traffic to our website. What that meant for me was a steady stream of UPS shipments from Dell, and a virtually full-time job of mounting servers on racks in the data center, getting them properly configured, and deploying them to the network.

Dealing with 50 or 100 hundred servers in 2000 was a daunting task, but dealing with hundreds or thousands of virtual servers in 2014 is—for all practical purposes—impossible. That is, it would be all but impossible doing things the old-fashioned way. However, the DevOps revolution changes the rules of the game because it uses code to do the heavy lifting, and automate those tasks which can be automated so the IT admins of today are free to engage in more productive tasks.

If we were still dealing in physical servers, the benefits of automation that you get in a DevOps environment would still not be possible. What allows so much of the traditional “racking and stacking” today to be automated is that we are dealing primarily with virtual servers. Although a virtual server may act like a server, and fulfill the same duties as a physical server, it is essentially just a software program. The fact that a virtual server is comprised of nothing more than code means that virtual servers can be created, configured, and deployed automatically through code as well.

It’s a good thing, too. The fast pace of a DevOps culture would be challenging to maintain without the efficiency of automation. The ability to create, provision, destroy, or move virtual servers around on a whim is part of what facilitates agile development and accelerated execution by DevOps teams.

There are also some adverse consequences of automation. People have lost their jobs in manufacturing plants as machines have come along to automate tasks they once performed. There is a risk that automating many of the routine tasks normally delegated to IT personnel could result in fewer people being necessary, but that is not a reason to not embrace automation. Automation enables people to develop more advanced skills and focus on more important tasks—those functions that can’t be easily automated.

One of the primary aspects of functioning in a DevOps environment is a faster development cycle, and more frequent deployments. Traditional organizations might deploy updates once a quarter, or once a month, but DevOps teams often deploy updates at least daily—sometimes multiple times per day. Automation reduces the possibility of error—it is a simple, repeatable process that works reliably and predictably.

A survey of DevOps Conference attendees published by JumpCloud and SoftLayer found that about 75 percent of the respondents use a configuration automation tool such as Puppet or Chef. More than half use scripts of some sort to execute tasks, and about one-third reported using a patching tool of some sort. Many of those surveyed admitted that they have the tools they need, but there simply isn’t enough time to get things done.

Perhaps that explains why 82 percent of survey respondents plan to automate more. Breaking the data down a little farther, nearly a third are looking to increase automation of configuration and deployment, and about 10 percent want to automate user management, and a variety of tasks like log management, scripting, testing, patching, and monitoring all came in around five percent or below.

It’s still possible to create virtual servers, and configure them manually one at a time. That may work if you’re bored, or nostalgic for the “good ole days” of IT, but it’s impractical, and frankly just dumb. It’s also possible to cut your lawn with a pair of scissors, or paint your walls with a Q-tip, but it is highly inefficient and ill-advised.

Don’t waste time and resources performing tasks that can be automated. Identify the functions you routinely perform that are consistent and repeatable, and embrace automation to take care of those things for you so you can focus on more important things.

March 13, 2014
Step One Of DevOps Ignores Technology

I’ve spent a bunch of time talking with Adrian Cockcroft, former cloud tzar at Neflix, and listening to his various talks and presentations. I’ve also spent a bunch of time looking around the various rooms within which he presents and seen the dazed look of attendees who have rightly assumed that just seen a picture of the way organizations should be. Netflix is unquestionably an exemplar for IT reinvented – where innovation, agility and developer enablement are natural parts of what they do.

But then I’ve seen these new disciples of the “Netflix way” write a list of the technologies that Cockcroft detailed and attempt to shoehorn those same approaches into their own organization. All to often the result is disappointment, failed projects and a swing back to the traditional rigid ways of doing things.

These thoughts struck me then I hear about this new masthead and its aim of creating a hub for DevLops thought leaders – surely giving IT practitioners a good place to find the latest tools and techniques will help spread the DevOps gospel?

Well yes, and no. You see I’m a firm believer in the viewpoint that DevOps has very little to do with products, processes and policies, and instead is a direct result of a particular type of culture. On the one hand you have Netflix, clearly a cultural outlier with its openness, willingness to experiment, embracing of failure-driven iteration and aim of planning for failure. On the other hand you have traditional IT shops that are top-down, driven by a rigid policy framework and consider the “operations department” and the “developer team” as two distinct entities.

This was a topic that Christian Reilly (he of the sartorial elegance and funny accent tendencies) and I discussed a couple of years ago, before the DevOps hype had really started to hit. In the video, he reflected directly on his organization, Bechtel, as an outlier at one end of the spectrum, while Netflix is an outlier at the other. It’s a somewhat dated video, and talks about public/private cloud, but the themes in terms of organizational readiness hold true for DevOps as well.

[youtube http://www.youtube.com/watch?v=gVG1Pj4cW-g&hd=1]

So my aim in my regularly irregular DevOps column in here is to talk about everything but the technology. And where better to start that the first step towards DevOps which is, I believe, all about building cultural bridges rather than making technology choices. It should be a natural concluding that, since DevOps is all about bridging the developer/operations span, that perhaps getting people in a room to talk about their particular drivers and metrics would be a good idea. But alas most people go from talking about DevOps to deploying their choice of automation tool.

There’s so many things to think about in embarking on this process – over on the ScriptRock blog Alan points out that visibility is a key first step before automation is embarked upon. While I agree with him that visibility is key, for me the money quote comes in his post where he writes:

Don’t automate what you don’t understand

But to then suggest that the first step should instead be a visibility tool does little to improve the outcomes – unless both sides fo the organizational divide are in the same room and accepting a common lingua franca and viewpoint on the data – visibility achieves little. So takeaway #1 focus on the culture. There’s lots of ways to build the bridges needed to change the way an organization looks – I’m going to cover some of that stuff over time.

March 12, 2014
Ops is dead, long live DevOps

Yes, that’s a bold statement, but if the vibe at the recent AWS re:Invent conference was any indication there are a number of methodologies, technologies, and companies working to make that a reality. This article isn’t focused on whether this is a good or bad thing (my personal belief is that ops will always be a critical part of the IT delivery process). Regardless, it is critical for IT operations personnel to understand the implications of this tectonic shift. As Marc Andreessen, founder of the venture capital firm Andreessen Horowitz, has said, “software is eating the world.” As a result, ops professionals must have the ability to automate tasks that used to be managed manually. Whether or not you think that is the death of ops as we know it I will leave to you, but it does mean we will live in a world where DevOps will offer distinct advantages.

Before we dive into what this change means to ops personnel, let’s review the underlying assumptions. The fundamental driver at the a high level has been the DevOps movement. Yes, DevOps is quickly becoming the buzzword dejour, but the underlying principles are lasting and changing IT to its core. DevOps is about integrating the various functions that it takes to release software or applications: software development, quality assurance, operations, and security among many others and rapid iteration. The process of integrating these tasks is accomplished through new processes and automation. Different functional areas such as development and operations are brought into the process earlier, and their processes are automated to the extent that they can be. This results in fast cycle times, increased quality, and hopefully increased innovation for the business. All of this is accomplished through software – at each functional level.

Some technologies that have enabled this massive shift include Infrastructure as a Service (IaaS), Platform as a Service (PaaS), automated configuration management, server management tools, virtualization, and software defined networking. IaaS and PaaS offerings are eliminating the need for organizations to procure, provision, and deploy servers. Further, this class of technology is also dramatically reducing the need to deal with the network layer. This allows organizations to concentrate on their applications and development, and focus less on their infrastructure. The amount of time and effort spent on server and network configuration is minimized. Configuration management solutions are enabling the automation of server setup. An organization’s technology stack can be pushed, pulled, cloned and copied versus manual configuration thereby saving time and adding consistency. Top performing organizations employing DevOps go a step further and automate the scaling of capacity based on utilization. To reduce day-to-day operational activities and costs, organizations are also automating the management of servers, including users access, patches, security, and other areas through both traditional written code and SaaS solutions. Another area changing the game for ops personnel is software defined networking (SDN), which is effectively morphing data center and hardware functions into software programs.

In short, DevOps and associated innovative new technologies are driving a paradigm shift in the way operations is done. No longer are ops personnel required to manually provision, configure, and manage the network, servers, and application stack. Combining technologies from organizations such as AWS, Rackspace, and SoftLayer along with configuration tools such as Chef and Puppet drives the provisioning and configuration of applications through software automation rather than manual effort. Once applications are deployed, the underlying infrastructure can be managed with tools such as my own company, New Relic, this author’s own JumpCloud, and others. Ops personnel have more companies than ever focusing on helping them automate the tasks that they need to deliver applications for their organizations.

The result from all of this effort is that ops as we know it won’t exist in the future. The network operations wizard that could manually troubleshoot routing and switching issues, provision servers quickly, and tweak configurations will be tasked with automating those tasks through software. Some of that automation will be through code that ops person writes herself, some delivered by third party providers, and other portions delivered by open source or SaaS-based solutions. But, don’t shed tears for the forced obsolescence of the IT ops people. They will still exist and perhaps be more important and powerful than ever. In fact, because of DevOps ops personnel will in essence be set free from mundane, repetitive “busy work” to perform higher value tasks as well as managing over the software and systems at work. The black magic of enabling different layers of the stack to function together will be less about art and more about science, or rather good software. Solutions will be engineered to work together and be tied together through code. Caveat: yes, service providers and some large enterprises will still run their own data centers and networks, but the same reasons that DevOps works in IaaS or PaaS will apply to private data centers or private clouds as well.

If all of this trends toward being true as we see it happening today, what are the opportunities for ops personnel to be at the forefront of this shift? Beyond embracing DevOps – which many operations personnel are doing already – learning to code is the most critical step that ops professionals can take. Many ops professionals already know how to script which is absolutely a minimum, but many will need to go further. Embrace the DevOps movement and push further towards the development side by learning how to code. There are any number of amazing services to teach us how to code or code better. Take the step. It may be the difference between a vestige of the old school versus driving the new world in your organization. The second significant step you can take is to automate your job. Leverage the very best automation tools to code your network, server, and application infrastructure. Not only will you spend less time on these tasks manually, but you will increase availability, reliability, and performance. In most organizations, that’s more than a gold star. Finally, make the mental shift that operations in the future will be less art and more science. DevOps is driving action through data, and the technology stack is responding to this demand with more telemetry than ever. Problems are now solved through understanding performance, availability, and other metrics. And code.

DevOps is the future. Automation is key. Code is the answer. Developers and ops are in it together for the good of their organizations. Ops pros that embrace this will win! Ops is Dead, Long Live DevOps!

March 12, 2014
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….

March 11, 2014