devopsy.kinsta.cloud

Tag: devops

Rugged DevOps: Making Invisible Things Visible

You might already know them from theagileadmin.com, but let me introduce you to two of the leading minds in the Rugged DevOps movement: James Wickett and Ernest Mueller. Both James and Ernest are active leaders in the DevOps space, in addition to helping organize events such as DevOpsDays Austin and LASCON. Our conversation covered a lot of bases from the founding of Rugged DevOps to aligning organizational silos to lessons learned from W. Edwards Demings.

Wickett: Hi, I’m James Wickett. I work over at Signal Sciences. I’ve been doing stuff in the DevOps space for quite a while and am interested in security as well.

Mueller: Hello, I’m Ernest Mueller. I work at AlienVault. I’ve also been in the DevOps world for a long time. James and I have worked together a lot in the past, and we blog together at the agile admin.com.

Weeks: There is a lot of conversation going on around Rugged DevOps. Is this the end of traditional security as we know it, or is there a place for what security has been doing all along to coexist with some new ways?

Mueller: Certainly. Every field has to continue to innovate to survive. And InfoSec is no exception. IT operations is no exception. The reason that we attend the RSA Conference and that there is a DevOps track is because IT infrastructure operations and systems professionals have the same issues. Right? The long lead times, bottlenecks, not being well-aligned with your customers. And we managed to find a way out of that using leading principles, using agile principles, to where we could improve the state of things.

Can the old coexist with the new? It certainly can for a time. I think, though, there is an extent to which the new modes of thinking in the end have to be adopted or you die out, right. You’re still doing your core thing. You are providing IT operations or you are providing security, but the way you do that has to change and keep pace with business demands.

___

Every field has to continue to innovate to survive. And InfoSec is no exception. IT operations is no exception.

___

Wickett: We talk about this in our presentation on lean security here at the conference. It is not so much of a question of “replacement” or “is traditional security going to be around longer?” It is just going to look a lot different.

The really cool thing (and what Ernest mentioned as well) is we both worked together in operations shops in the past. That was five or eight years ago when operations was then where security is now. Operations today looks dramatically different than it did 10 years ago. I think the same thing is going be true about security. (See slides from Ernest and James.)

https://www.youtube.com/watch?v=D6TnKUWPqvg

Weeks: When I talk to a security audience about how they interact with development, they are like, “Ah, we have no access to development.” When I speak to development communities about security they are like, “Ah, don’t let those guys in the room.”

Part of the Rugged DevOps conversations is not only how do you bring security into development, but how do you bring it in early enough into the development life cycles. How have you been able to bring security in and bring it in early?

___

Operations today looks dramatically different than it did 10 years ago. I think the same thing is going be true about security.

___

Mueller: Again, this is one of the core problems that DevOps faced at its initiation, where that exact same dialog occurred between developers and operations.

There are a number of techniques you can use. But what you have to understand is that you are looking at an underlying culture change. There is no silver bullet for that, and so it can take years. But aligning both the people that are trying to do the work and the management that is trying to organize it to understand—that sort of close collaboration throughout the entire pipeline is what’s important.

And there are some times where you have to power through it. I remember early on in our DevOps implementation at National Instruments. We had started having design reviews with developers and operations personnel that were in the same room. The application architect approached me and said, “These guys keep asking us questions that we don’t really even understand or know the answers to about capacity or about reliability. Maybe we should just have separate reviews.” I said to him, “Well, you have two options. We can continue to do them separately, and we can continue to not understand each other. Or, we can do it together and power through it. And it really shouldn’t take all that long before we do start to understand each other because we all have the same goal, which is to ship these products.”

___

I said to him, “Well you have two options. We can continue to do them separately, and we can continue to not understand each other. Or, we can do it together and power through it.”

___

So we powered through it, and it really didn’t take that long for everybody to finally get to a good point where they could understand and collaborate with each other. But it took determination to get there.

Wickett: I think that was really, really well said. We are having that conversation where we’re saying we do need to shift left. We are saying we do need to make it earlier. We’ve kind of seen the writing on the wall. How do we get there?

I think there are some practical approaches. We are just taking small steps. I have seen people do this at different organizations. There have been a lot of talks on this. But when putting security into your continuous integration in your delivery chain, I think there is a huge gap.

I work at Signal Sciences so it is one of the things we do. But there is a huge gap in the operations knowing whether we are under attack, why are they attacking and what are they trying to do. Right? And I am not saying you need to buy our product to get that done but there is …

Lean Security from SeniorStoryteller

Weeks: I’ll say it. You do need to buy his product.

Wickett: Good, please, say that.

But it’s amazed me how often shops have no idea what’s actually going on. They don’t really know what parts are being attacked. They don’t know what’s happening on their site. They don’t have any sort of security operational telemetry coming back to developers or to management.

As we’ve seen in lean, those are the invisible things. You’ve got to make them visible. I don’t know what that’s going to mean for people’s organizations. I could make a bunch of random recommendations, but take the principle of making those invisible things visible and start trying to apply it.

___

Take the principle of making those invisible things visible and start trying to apply it.

___

Weeks: Building on that: Part of the whole discussion around DevOps is rapid feedback loops. How do you get information from people as quickly as possible so that they can be informed and take action on that?

Mueller: Absolutely. Well, I think we’ve seen a lot of fledgling successes in that area. James is the core contributor to an open source product called Gauntlet that introduces security testing into continuous integration processes. We’ve seen presentations at other conferences, from Twitter and from Etsy, where they’ve built these security warning systems very, very early on that notify the people that are actually creating the flaw as they are creating it.

W. Edwards Deming said that we can’t ensure quality by mass inspection after the fact. We have to build integrity into the product as we create it. Unfortunately, a lot of security thinking today is built around mass inspection after all of the mistakes have already been made and then trying to go back and get somebody to do rework of a product that has already shipped, that’s already making money, that’s already out there in customer deployments, whatever. That’s always inherently going to be a much more difficult route at ensuring actual security.

___

We can’t ensure quality by mass inspection after the fact. We have to build integrity into the product as we create it.

___

Wickett: In some ways, we’ve built this problem ourselves. We do compliance on an annual basis. Compliance is built around the waterfall mechanism, and security is a function of compliance or something that they try to accomplish. It’s very antithetical to fast feedback loops. It’s very antithetical to rapid cycles. So we need to find ways to break that down into more discrete chunks that can happen on a daily or weekly or hourly or per-code-commit basis.

Weeks: How did the rugged DevOps movement originate?

Wickett: Rewind to 2009 or so, and there are the first signs of DevOps kind of coming through. There is the agile operations thing. People were talking about velocity that year. The first DevOpsDays by Patrick Dubois happened. Flickr says that we’re doing 10 deploys a day. And just everybody loses it.

At the same time, Josh Corman came out with the Rugged Software Manifesto in 2010. I read that. And Ernest and I were both latching onto DevOps at that time, and we were trying to do some cloud-based implementations but really focused on the DevOps-centric vision around that.

We told ourselves, “We can’t just stop at Dev and Ops. We have got to have security.” And this is while we were taking a lot of telemetry data from Internet of Things (IoT) types of devices and thinking that’s going to need to be secure if we ever wanted to get a customer on that. So we really started to try to put that together.

___

We can’t just stop at Dev and Ops. We have got to have security.

___

We stumbled across the rugged stuff, and at the same time, we just really felt like rugged and DevOps were two things that were moving in different tribes. They were both trying to accomplish very similar-type missions. In Austin, we run the DevOpsDays event there. We have a lot of security folks in the Austin area. It’s the capital of Texas, so there are a lot of folks related to that.

It seems like the DevOpsDays we’ve had there have a very security-focused push every year, and the rugged language really struck more of a cord than security. To me, that’s a rough brief history of how that’s come about.

Weeks: James, you also run LASCON in Austin, which is a great security conference. It has a DevOps track where security and development or DevOps come together.

You are both thought leaders yourselves. But who else do you listen to? If you could tell someone reading this, “Here is someone that you should see at a conference or look for their video on YouTube,” who would you recommend?

Mueller: Obviously, the list of presenters here at the Rugged DevOps Summit is a litany of many of the best-in-class people to hear speak, whether it’s Josh Corman, John Willis or Damon Edwards. I could list the entire set. People that aren’t here, like Pete Cheslock, have done a lot in merging both DevOps and security.

Wickett: Throw in Nick Galbreath who I work with now. I really kind of saw him doing some of the same stuff, and I really dig that. Gene Kim, of course, would be a good fit.

I love learning from Patrick Dubois. When he speaks on anything, I am really interested in what it is. He is doing more mobile stuff these days but always good stuff there. Anybody else?

Zane Lackey, too. I also work with Zane.

Weeks: That’s a great list. Thanks!

Hey, DevOps Austin is coming up in the beginning of May. Is the call for papers still open?

Mueller: That’s right, the 2^nd and 3^rd of May this year.

The DevOpsDays Austin call for papers is open, call for sponsors is open, and tickets are being sold, although early birds are sold out already, so I recommend that people move quickly.

We’re in our fifth year. The last couple of years, we have been filling up our venue at 500 people. We have actually moved venues to the University of Texas Darrell K. Royal-Texas Memorial Stadium this year, so we have a little bit more space, and we’re riding on more tracks. We’re riding on a hack-a-thon actually.

It’s interesting. One of the things you have to be careful about in this whole thing is not losing the developers.

___

One of the things you have to be careful about in this whole thing is not losing the developers.

___

People that were very involved in OWASP for a long time saw that started off as a developers and security sort of thing. And over time, unfortunately, that relationship was lost a little bit, and they’ve had challenges as a result.

Now we are like, “How do we get the developers back collaborating with security?” We’re trying to make really sure that there is a lot of interest in DevOps out of the operations space, and so that can sometimes start to push out the content the developers find compelling.

We’ve added a content tract and a hack-a-thon to try to make it super compelling to developers this year.

Weeks: Excellent. James, I think you guys just secured a Series A. Is that right? Should we tell people you are hiring at Signal Sciences? Is AlienVault hiring too?

Wickett: Yes, I think Signal Sciences is hiring both in the L.A. area and across a lot of remote positions. The engineering team has a number of remote members.

Mueller: Absolutely, we are hiring too. We have teams in Austin, out here on the West Coast and in Ireland. Our original office was in Madrid, Spain. So we have a lot of folks there if we have any international readers on the blog.

Weeks: Excellent. Perfect. I appreciate you guys spending time with me. Absolutely enjoy the conference, and we’ll point people to the recording of your session as well.

Wickett: Cool.

Mueller: Super.

Wickett: Thanks, Derek.

Weeks: Thank you very much.

If you loved this interview and are looking for more great stuff on Rugged DevOps, I invite you to download this awesome research paper from Amy DeMartine at Forrester, “The Seven Habits of Rugged DevOps.”

As Amy notes, “DevOps practices can only increase speed and quality up to a point without security and risk (S&R) pros’ expertise. Old application security practices hinder speedy releases, and security vulnerabilities represent defects that can leave a company open to cyberattacks. But DevOps practitioners can leap forward with both increased speed and quality by including S&R pros in DevOps feedback loops and including security practices in the automated life cycle. These new practices are called Rugged DevOps.”

April 19, 2016
The New Age of “Operations” in a DevOps Enterprise
My encounters with commercial clients in the DevOps space have been exciting, curious, political, and challenging. What most don’t realize is that DevOps is not just about infusing tool automation into a delivery pipeline, but it also has to do with re-mobilizing and challenging the status quo when it comes to “who does what”. As teams become more tightly integrated, functional lines blur, and uncertainty may set in.

I find more and more, that clients and colleagues want to know:
- What happens to the operations/run tower people if tools like UrbanCode Deploy automate the promotion of applications and releases to run-time environments?
- What happens to our system administrators and “build out” teams, if tools like Chef, Puppet, Vagrant and pattern-based provisioning systems like IBM Cloud Orchestrator and UrbanCode Deploy with Patterns can perform solution stack build outs with minimal custom network, hardware, software, and middleware configurations?
- If developers can provision and deploy their own apps, what do the sys admins do?
- Will Operations Staff be replaced by tool automation?
The truth is, now, more than ever, a savvy, astute, and innovative operations staff is essential to successfully execute effective DevOps within the enterprise.

As development and test teams are being empowered to deploy their own applications with tool automation, Operations will need to shift the focus to enabling and empowering these teams with standardized, reusable automation assets. Design, development, maintenance and management of these automation assets will be the core foundation of DevOps success within the enterprise. A corollary to this is a set of standards and policies must be clearly defined and adopted as a framework for implementation.

Standardization is paramount to making DevOps successful on a wide scale in the enterprise. If we were to think of our applications as a “solution stack” of network, hardware/virtual machine, operating system, middleware, and custom application components, standardized assets in each of the solution layers would enable faster assembly, development, test and delivery of a solution.

When it comes to effectively enabling the enterprise for DevOps, you must become a hater of snowflakes. Snowflakes can be elegant, but they are unique and difficult to automate with tools. Examine applications and systems for uniqueness…and ask, can it be standardized? Typically, snowflakes occur higher up on the solution stack at the Application or Middleware layers. Network teams are not likely to implement new security policies for each application. However, moving up to OS and middleware, uniqueness is more likely to occur (OS release versions, MW versions and packages and so on).

Once opportunities have been identified for standardized assets, operations teams must mobilize to enable the enterprise for automation:
- Encapsulate enterprise policies in standardized automation assets (which can be reused across the enterprise).
- Centrally manage and maintain automation assets within the enterprise (to maintain standard and policy compliance).
- Evangelize, encourage, and incentivize the use of automation assets in delivery of applications.
- Provide a continuous delivery pipeline tool set (preferable, as a service) providing an infrastructure to enable the automation assets for development and test teams
Automation assets can occur at every layer in the solution stack, providing an opportunity for the new Operations team to inject enterprise influence and compliance at every level. This approach ensures standards and compliance, but also relieves application development and test teams from worrying about whether their application violates any corporate policies.

Examples of automation assets and some enabling technologies are shown below, but this is obviously not an all-inclusive list (even a hardened shell script can be an asset). The point is, for each layer in the solution stack, assets and corresponding enabling technologies can be chosen to invest in. Some technologies can address multiple layers in the solution stack.

There is clearly a lot of good, solid, critically important work for the new age Operations team to manage and maintain. Interfacing with enterprise architecture and corporate standards groups are essential. However, the focus remains largely around empowering and enabling delivery using standardized assets.

You can also watch this short video that I recorded recently. Please do share your feedback on this blog and how you see the evolving role of IT Operations in a DevOps Era.

https://www.youtube.com/watch?v=TRlbiPcFOxc

About the author

Andrea Martinez is the DevOps Solution Leader for Cloud Services in IBM. Andrea’s mission is focused on delivery of DevOps solutions in cloud and traditionally hosted environments. Andrea has lead the solution architecture, implementation and initial adoption of one of IBM’s first DevOps Deployment Offerings. As a member of the IBM Academy of Technology, and a certified Thought Leader in application architecture, Andrea is keenly interested in enabling and empowering practitioners with innovation and technology to deliver solutions faster.

Connect with Andrea LinkedIn | Twitter
April 18, 2016
Test Better, Test Faster, Test Smarter
How do you balance the need to “go fast” with the need to test everything and deliver high-quality software?

With applications the driving force in today’s economy, the quality and release cadence of your software are critical to your business and your bottom line. You want to get software updated in the hands of your end users as quickly as possible. However, even the fastest release cycle wouldn’t make a difference if your product ends up being buggy or malfunctioning, resulting in a bad user experience or service interruption.

I want to take a look at one of the most important (if not the most important) aspects of the software delivery process: testing! As software teams become more mature in their implementation of DevOps and continuous delivery to streamline their software delivery, testing takes a central role as a prerequisite to these practices.

You need to have testing on your mind from the very beginning, and plan your testing as part of the initial stages of designing your software—mapping your test procedures, infrastructure configuration and acceptance criteria. As you design and develop your app, you also need to think about how you’re going to test it. The more testing is on your mind, the more you’ll have a solid understanding of what you need to test, what’s the definition of “done,” and the faster, more streamlined, your overall process will be.

Let us review four questions every development or QA team should consider when planning their testing, as they try to balance quality with speed—managing and accelerating their testing, while ensuring a reasonable time-to-market.

How Much Testing is Enough?

The age-old question: How much testing do I really need to do? Unfortunately, there is no concrete answer. But with a bit of initial legwork, you can get a good feel for how much testing is necessary.

The amount of testing that is necessary is influenced largely by the industry you’re in. If you are testing mission-critical aircraft software, let’s hope it’s very thoroughly tested! On the other hand, if you’re building a game app, the amount of necessary testing may be lower. The truth is when you run tests, the success rate is usually not 100 percent. Therefore, the key is to define what, for your specific piece of software, can reasonably be considered “done.” Instead of arbitrarily deciding at some point that your release is ready to ship, make the decision before the fact: What are we going to accept? What level of pass/fail are we willing to roll out with? What are we comfortable with based on what we have done in the past?

The amount of testing required can sometimes be a fluid thing. A good way to measure your comfort level with your testing procedures and the amount of testing you’ve done, is to ask yourself, “If it was now 11 o’clock at night, and I needed to ship this code to my end users, am I sufficiently comfortable rolling this out, or am I not sure how it’s going to behave in the wild?” If you’re leaning toward the latter, than it’s probably an indication that you should have done some more testing. That’s a gut feeling and depending on the industry, the point at which you’ll fire off a release and not have any worries can vary greatly. And, obviously, for some regulated industries, you’ll need to prove compliance and ensure you’ve recorded that all tests were successful before you can even start thinking about releasing anything.

What Kind of Testing Should You Invest in?

Decide what kinds of things you really care about and what you need to verify and test for. What are the requirements that we expect from the application, and from the different stakeholders in this project?

Every piece of software needs to be tested differently. Because of this, you have to plan what the testing will be. You can’t just say, “I’m going to unit test the heck out of my code, each and every time, no matter what.” Sometimes, unit testing isn’t the most important test you need to be running.

The investment has to be in automation. No matter what type of tests you decide are most functional and relevant to your project—whether you’re doing a ton of unit testing or a bunch of functional stress tests—it needs to be automated.

Particularly, as you open up your services to the world, you need to put into place the relevant performance and reliability tests so that if suddenly your load increases by 200 percent, you have a plan for how to handle that. Are you going to autoscale? Can you autoscale? And finally, do you even need to auto-scale?

All of those questions need to be answered as part of your development cycle. Automating your tests will let you not only create tests for these scenarios, but it will let you run those tests over and over. By automating your tests, you can establish a baseline and see where you deviate.

It can also be helpful to think of testing in a different way. Don’t look at testing as a tool to validate technical requirements, but as a way to make your customers happy. You want to make sure your tests are directly contributing to your customer’s overall experience. So start with the highest-level tests that look at things such as overall business functionality—and make sure the software works at the business level.

How Can You Make Testing Faster?

Automate, automate, automate! That might seem obvious, but try to think outside the box. Find things you thought couldn’t be automated and wrangle them into shape. Remember that every minute that one of your developers is sitting there running a test that could be automated, it is costing you time (and money) that he or she could have spent on more productive things. In the long run, not automating can cost much more than making the commitment to doing it right.

Other simple things you can look at to increase the speed of your testing is to make sure your development environments are mirror images of your production environments, and that you have fidelity of configuration throughout the lower and higher environment.

It is also helpful to make sure you’re defining user requirements that are thin vertical slices, instead of trying to test huge cumbersome pieces of functionality. The ideal situation is if you can run only tests against components that have changed. Componentization of both your application and your testing procedures is critical because you do not want to have to rebuild and re-test everything all the time. Remember, also, that if you make incremental changes to your code and frequently release them to your users (Agile, anyone?), you will get just enough feedback to improve quickly and reliably. Be cognizant of not biting off more than you can chew.

Segregating the tests to several phases is a good way to accelerate your CI and test cycle—but make sure that both your application, build and test batteries are designed for that. With this approach, you are essentially running multiple phases of CI, starting with the fastest cycles that require the smallest build(s), with minimal dependencies, and move on to the outer/cascading cycles of tests. Following a submit, run a minimal build, so that you do not need to wait—sometimes many hours—to run an extensive set of all your tests with every single commit to see if it passes. Start with unit tests to minimize the build and provide fast feedback, then in various junctions incorporate additional tests, such as integration tests, installers and usability and performance tests.

Another way to streamline your testing process is to take a look at the entire scope of your build and test cycle and go after the most inefficient stage. After automating your manual processes, look at the bottlenecks and what takes the most time and figure out how you can optimize that specific process. Often the answer is parallelization, but other times it is hardware. Iterate on your process and figure out where you can gain the most ground!

Lastly, parallelization and distribution of the build and tests provide a huge time saver, so consider running tests across a cluster of CPUs to cut down the run time.

Where Do You Start if You Want to Make Sure All Your Builds Are Green?

Ask yourself, What are you trying to achieve? Is it a process where you can release code more quickly? Or where you can address bugs more readily? Then make sure you’re intimately aware of what you have in place. You need to know every step, task, process and tiny bit of your testing procedures and supporting infrastructure. Draw your entire end-to-end workflow on a whiteboard and find the bottlenecks that are slowing it down.

Once you’ve defined your objectives and are aware of your current state, you can put the relevant tools in place—from development environment to your testing frameworks all the way to post-dev tools such as your analytics tools—design the right testing pipelines and hire the relevant people with the relevant skills. Don’t insist on making all the mistakes yourself (tongue firmly in cheek), but find folks who have already made the mistakes and learned from them—and hire them!

Also, give your team a great system that gives feedback fast. Do frequent code reviews so there is accountability and a constant learning process.

Consider the following best practices for improving your testing processes:
1. Be sure to plan what your testing approach will be ahead of time if possible. When you’re designing your software, designing how you’re going to test it is important.
2. The amount of testing you need to do is dependent on what industry you’re in and your specific use case.
3. Consider what level of test pass/fail you’re comfortable with, based on what you’ve done in the past.
4. Consider pre-commit or pre-flight builds to ensure your tests are more likely to pass once checked to Mainline
5. Define your requirements for each test cycle
6. Segregate your tests to “fast” and “slow” and decide which battery of tests you need to run every time, and which processes you only need to run at certain junctions.
7. If you hire well and bring new skills to your team, your process will get better and faster.
8. Consider what problems your customers are facing and perform an analysis. Use whatever tools are best to test your software like a customer would to achieve the highest end user satisfaction.
9. Automate manual steps that you take for granted to accelerate cycle times and improve productivity. Speed comes second.
10. Iterate on the testing process, and not just on the code itself. You should always be looking for new ways to test.
11. Test your test processes. Hold regular meetings with your team to reassess if your testing strategy is working for you.
12. Enact code reviews so that there is accountability with the rest of the team.
As you map, design and optimize your tests, remember that your testing policies don’t need to be set in stone, and that you can—and should—adjust and tweak as you go.

Happy testing!

About the Author/Anders Wallgren

Anders Wallgren is chief technology officer at Electric Cloud. Anders has more than 25 years’ experience designing and building commercial software. Prior to joining Electric Cloud, he held executive positions at Aceva, Archistra, and Impresse and management positions at Macromedia (MACR), Common Ground Software, and Verity (VRTY), where he played critical technical leadership roles in delivering awardwinning technologies such as Macromedia’s Director 7. Anders holds a B.SC from MIT. He invites you to download the community edition of ElectricFlow to build your pipelines and deploy any application, to any environment for free.
April 18, 2016
State of DevOps Survey – The Ultimate Feedback Loop

If there’s any consistent criticism of the larger DevOps movement, it’s that the talking heads and industry gadflies are driving the conversation, not the people in the trenches.

All the thought leadership panels and “how-to” content (including the written and AV materials on this very site) make for great watercooler discussion, but lack the input of those dev, ops and IT management pros who are actually living the DevOps experience, some critics have said.

Well, fair enough. Talking heads are paid to talk. Thought leaders are chosen to lead the debate at conferences and on webcasts. Bloggers blog. Reporters report. This is simply the way of the world. Certain voices are heard via the channels they frequent. It is, as so many people are fond of saying these days, what it is.

So what about everyone else? What of the people reading this stunning prose and listening to these talks while rolling their eyes based on the connectivity of it all to their real-world experience? How can their voices be heard?

Independent of jumping into the blogsphere or applying to speak at said industry events – which you should, btw – there’s one significant opportunity available to anyone who cares to take the time – participating in industry research.

Over the next few business days, citizens of the DevOps world will have their last chance to contribute to the industry’s most widely read and respected research project, the State of DevOps Report.

If you haven’t done so already, take the time to fill out this year’s survey, and make sure that your voice is heard when the subsequent report is published in June. Sure, it takes a little time, about 15-20 minutes; but that’s because it goes to the trouble of exploring the real-world issues that weigh most heavily on today’s practitioners.

Why is this particular project so important, or even credible? Consider that the minds behind the survey and analysis resulting in the 2016 State of DevOps Report are those authors and talking heads that actually get the most respect.

Backed by DevOps Research and Assessments (DORA), the independent think tank operated by a partnership of Jez Humble, Gene Kim, and Nicole Forsgren – perhaps the most respected voices on the landscape, along with Nigel Kersten, the project is categorically aimed at surfacing the truth about DevOps adoption today – not merely promoting the interests of vendor sponsors.

Like previous iterations of the report, the 2016 edition will focus on topics including IT performance, technical practices, culture, lean management, and organizational performance. This year’s survey also examines several new areas, including the ROI of IT performance, security and compliance, and containers.

To further entice participation, project leaders are also offering free tickets to the DevOps Enterprise Summit, along with forthcoming books from some of the industry’s leading advocates to a lucky few who take the time to get involved.

DevOps success is fundamentally based on the notion of increased collaboration and continuous feedback among the people scattered across the SDLC. Likewise, the legitimacy of this research project is utterly dependent on the input of as many real-world practitioners as possible.

If you’re one of those individuals, and you really care whether or not everyone else involved in the advancement of DevOps understands what this all means to you, do yourself a favor and participate.

Much like an application being built using DevOps practices, this quality of this project will be directly determined by the degree to which anyone with insight is willing to get involved and build toward optimal results.

Take the 2016 State of DevOps Survey… today!

April 15, 2016
Threat Stack Announces Webhook API Integration Capabilities
Customized Workflows Enable Collaboration to Streamline Security

BOSTON – April 14, 2016 – Threat Stack, a leader in cloud security management and compliance, today announced its webhook API integration capabilities to reduce security and operations workflow challenges. This capability allows Threat Stack customers to enable a webhook API to build custom workflows based on security alerts. These custom workflows extend the Threat Stack Cloud Security Platform ^TM (CSP) and help customers to further integrate security into their existing monitoring operations.

Security concerns continue to be a challenge for IT leaders and CISOs facing increased threats daily. It is more important than ever that departments within organizations collaborate to streamline and automate processes. Threat Stack’s webhook API integration makes it easier for security and operations teams to automatically trigger alerts and remediation to speed time to resolution.

“In cloud environments, automation is key when it comes to monitoring for and resolving incidents. Threat Stack’s webhook API integration takes automation past a simple alert and actually quarantines the instance until it can be addressed,” said Venkat Pothamsetty, vice president of products and customer advocacy at Threat Stack. “These types of capabilities have a measurable impact on internal team efficiency and is one of the many ways that Threat Stack has developed automation to improve time to resolution.”

Threat Stack customers using webhooks can now more easily and efficiently:
- Integrate the Threat Stack Cloud Security Platform with custom internal applications
- Integrate with other monitoring platforms to more easily identify issues
- Build new escalation and/or remediation workflows based on Threat Stack alerts
Threat Stack users can custom configure their own webhook integrations to subscribe to specific, prioritized events. When an event is triggered, the webhooks integration sends a summary of alert information in JavaScript Object Notation (JSON) format, and every alert results in a separate call to the webhooks API. Users are then able to interpret their alerts and take actions based on their unique needs.

Examples of custom workflows for cloud security teams include:
- Generating a custom AWS Simple Notification Service (SNS) notification based on severity 1 Threat Stack alerts
- Creating a Jira ticket from a severity 2 Threat Stack alert
- Archive severity 3 Threat Stack alerts into a S3 bucket for long-term storage
The cloud native, fully-integrated Threat Stack webhook API integration enables collaboration to drive faster mean time to resolution of critical security events. Threat Stack customers across healthcare, fintech, SaaS fields, and other industries benefit from greater efficiency, streamlined services, and the automated integration of security events from across the infrastructure.

For more information on Threat Stack, please visit www.threatstack.com.

About Threat Stack

Threat Stack enables growth-driven companies to scale with confidence by identifying and verifying insider threats, external attacks and data loss in real-time. The only fully integrated, cloud-native continuous monitoring solution that gives customers instant visibility and automatically responds to changes in their environment, Threat Stack provides the coverage needed to run secure and compliant, in all environments, without sacrificing speed and efficiency. For more information, or to start a free trial, visit threatstack.com.
April 15, 2016
Rackspace Becomes AWS DevOps Competency Partner

SAN ANTONIO, TX–(Marketwired – April 14, 2016) – Rackspace® (NYSE: RAX) has achieved Amazon Web Services™ (AWS) DevOps Competency within the AWS Partner Competency Program, which recognizes members of the AWS Partner Network who have completed a rigorous third-party audit demonstrating their expertise in DevOps practices, tools, and proven customer success. Customers can access this expertise and 24×7 operational support through Fanatical Support® for AWS architects and engineers, who collectively hold over 270 AWS Professional and Associate certifications across the globe.

Historically, the process of deploying and managing applications has been manually intensive and customized. Manual deployment and management of applications generally leads to outcomes such as fewer release cycles, longer lead times, and unpredictable quality, all of which impact time to market and stable operations. Applying those manual and custom practices in a cloud environment negates the inherent advantage of software defined infrastructure. DevOps is the use of practices, tools and automation that can improve the efficiency of how businesses run applications in the cloud.

Fanatical Support for AWS provides businesses access to certified AWS experts who can help implement and operate workloads on AWS using DevOps practices and tooling, both from AWS and leading 3^rd parties. Rackspace DevOps expertise can help customers improve the speed, frequency, and quality of their software deployments and the accompanying operational processes. Customers using the Aviator™ service receive ongoing support for native AWS DevOps tools such as AWS OpsWorks, AWS CloudFormation, AWS CodeDeploy, AWS CodePipeline and AWS CodeCommit. As an additional service, Rackspace engineers can utilize a broad range of leading third-party DevOps tools, such as Chef™, SaltStack, and Ansible to help ensure that customers have choice around their preferred DevOps toolset.

“Rackspace has been active in DevOps practices since 2012, working to help customers increase speed and consistency in their operations. We are excited to be recognized by AWS and to apply our knowledge to customers working on the AWS platform,” said Chris Cochran, senior vice president and general manager of AWS at Rackspace. “Not all customers start with a high degree of expertise in this area, but Rackspace can help these businesses continually improve their efficiency with running apps in the cloud.”

For more information about Rackspace’s achievement of the AWS DevOps Competency, please visit http://blog.rackspace.com/rackspace-achieves-aws-devops-competency/.

For more information on Fanatical Support for AWS, please visitwww.rackspace.com/aws.

About Rackspace
Rackspace (NYSE: RAX), the #1 managed cloud company, helps businesses tap the power of cloud computing without the challenge and expense of managing complex IT infrastructure and application platforms on their own. Rackspace engineers deliver specialized expertise on top of leading technologies developed by AWS, Microsoft, OpenStack, VMware and others, through a results-obsessed service known as Fanatical Support^®. The company has more than 300,000 customers worldwide, including two-thirds of the FORTUNE 100. Rackspace was named a leader in the 2015 Gartner Magic Quadrant for Cloud-Enabled Managed Hosting, and has been honored as one of Fortune’s Best Companies to Work For in six of the past eight years. Learn more atwww.rackspace.com.

Forward Looking Statement
This press release contains forward-looking statements that involve risks, uncertainties and assumptions. If such risks or uncertainties materialize or such assumptions prove incorrect, the results of Rackspace Hosting could differ materially from those expressed or implied by such forward-looking statements and assumptions. All statements other than statements of historical fact are statements that could be deemed forward-looking statements, including any statements concerning expected development, performance or market acceptance associated with Fanatical Support for AWS; anticipated operational and financial benefits from Fanatical Support for AWS; any statements of expectation or belief; and any statements of assumptions underlying any of the foregoing. Risks, uncertainties and assumptions including the possibility that expected benefits from Fanatical Support for AWS may not materialize because this product is not generally accepted in the marketplace, which could occur due to certain factors including (i) a failure to market the product cost effectively, differentiate the product from competitive products or communicate differentiations effectively, (ii) the reliability, quality or compatibility associated with the product, (iii) changes in technology which adversely effect the product’s benefit, (iv) slowdowns in the general economy or technology industry that impact consumer spending habits, (v) internal strategy decisions that impact the product, and (vi) other risks that are described in Rackspace Hosting’s Form 10-K for the fiscal year ended December 31, 2015, filed with the SEC on February 26, 2016. Except as required by law, Rackspace Hosting assumes no obligation to update these forward-looking statements publicly, or to update the reasons actual results could differ materially from those anticipated in these forward-looking statements, even if new information becomes available in the future.

Media Contact:
Brandon Brunson
brandon.brunson@rackspace.com
210-312-1357

April 15, 2016
Optimizing an Effective CI/CD Pipeline
Continuous integration and continuous delivery (CI/CD) are often cited as pillars of successful DevOps. To establish and optimize the CI/CD development model and reap the benefits, companies need to build an effective pipeline to automate their build, integration and testing processes. This requires architecting CI/CD with five key ingredients which, when combined effectively, operate as a successful cornerstone of DevOps and provide myriad bottom-line benefits.

Building the Pipeline

Let’s first take a look at the five essential ingredients needed for a healthy CI/CD architecture, following up with a discussion of their benefits to the business:
- Micro-agility in the form of testing and committing code frequently: The development life cycle begins with a request to development, which then takes the request and designs a solution, codes it, tests it and commits it a code repository. From here, the code is tested by QA and then deployed to production. While each step is important, we begin here, as local testing occurs most frequently and bugs found at this stage of the process help avoid the large expense of bugs found in production.To achieve micro-agility, developers must have a clear understanding of where they are expected to commit their code after changes are made and they should be expected to test and update their code frequently—many times a day. This means development testing should be easy to run locally and is a subset of QA. The result is that code pushed by development is by definition QA-ready.
- Automated QA: In my work I see many organizations whose QA team is one of the largest bottlenecks in the process. It’s not for a lack of skill, but too few staff who spend a good portion of their time waiting on the QA test environments they need to do their work. To avoid this situation, the QA process should be fully automated, from QA ready code coming in the door to one-click promotion on the other side. In between the two, QA should have a constant feedback loop with development where communication about—and tracking of—bugs is clear and easy to follow, allowing development to easily repair issues and recommit the code for further testing. Moreover, automated QA in a CI/CD environment should focus on microcycles consisting of small test batches rather than weeklong macro tests. Automation and communication are the overriding imperatives here, exhibited by reports to developers that are communicated immediately and code commits that are fail-rejected automatically.
- Production-like environments: To increase efficiency and effectiveness, development and testing environments should mirror production as closely as possible. They should follow the PRQ rule, as I like to call it—production-like, repeatable and quick. Specifically, it should be fast and easy to set up new environments, to the point where developers can, with the push of a button, deploy new environments for their development and testing needs. Doing so allows developers to fail fast, breaking and re-creating environments without fear as they know they can easily recreate the same environment every time. I often recommend using tools such as Jenkins to help with this process; if developers and IT operations use the same tool, it makes it that much easier to streamline the CI/CD process and achieve the promise of DevOps.
- One-click promotion: As I alluded to earlier, a well-architected CI/CD pipeline provides one-click promotion to production. This ensures changes are seamlessly moved to the overall production environment with the least amount of friction possible between development and operations. To that end, this reduction in friction should occur across all the steps of the process, with efficient code delivery pipelines that are designed to balance security and agility from the outset. Cloud infrastructure coupled with container technology and automation can easily optimize the process across teams and throughout the DevOps journey.
- Fully automated deployments: The last factor of an efficient CI/CD pipeline is full automation of deployment. Any configuration changes made by development and accepted by QA should automatically be applied. Continuous integration in this way helps avoid system downtime and human errors are decreased greatly. Deployments also should be continuously monitored so that IT is the first to learn of potential problems. This helps nip issues in the bud, allowing for faster rollback and return of code to development to fix anything that may not be functioning properly. Catching issues before customers do helps ensure customer satisfaction and strength of reputation.
Benefits of the Pipeline

In addition to these benefits, when combined effectively, these ingredients minimize the time and cost of local test, QA and production processes; reduce the time it takes to identify problems and their causes; and accelerate delivery of production-ready code. We can see this throughout the CI/CD pipeline:
- Developers have greater control over the process and can respond more quickly to market demands by quickly bringing up new environments, testing against them and easily starting over, if need be. Moreover, developers can quickly adjust to new environments—an approach that has proven to decrease failures and resolution time when they do occur.
- Operations benefits as reduced friction in the CI/CD pipeline created by automation decreases repetitive, manual work and with it the opportunity for “fat finger” mistakes and the greater opportunity to introduce inefficiency into the process.
- And, less manual, repetitive work provides everyone in the process with more time for strategic work, which provides direct bottom-line value to the organization.
CI/CD is a pillar of successful DevOps and according to research by CA, organizations that apply DevOps discover an 18 percent reduction in time to market of new applications and a 21 percent increase in delivering new software that they would not otherwise be able to complete. Teams that master an efficient CI/CD pipeline deliver faster, higher-quality applications to market bringing with it a 19 percent increase in revenue. Mixing these ingredients together results in an efficient, streamlined CI/CD pipeline that serves as a fundamental pillar of DevOps success that, when mixed together, delivers direct business benefits.

About the Author/Aater Suleman

Aater Suleman, CEO & co-founder at Flux7, is an industry veteran in performance optimization on servers and distributed systems. He earned his PhD at the University of Texas at Austin, where he also currently teaches computer systems design and architecture. As a faculty member at UT-Austin, Mr. Suleman focuses on optimizing DevOps architectures involving the AWS cloud. Along with the Flux7 consultant team, he works at every step of the dev flow, from creating local developer environments using Vagrant and Docker, to continuous integration and continuous delivery using Jenkins or RunDeck, to configuration management using Chef/Puppet/Ansible, to creating efficient systems for deploying new code from Git using Capistrano/Fabric/bash. His background is as an architect, and he has experience with both hardware and software. This combination brings a unique perspective and broad view to development and operations.
April 15, 2016
Carwash Success: New DHS Privacy Policy Requires Carwash for all Mobile Applications

Carwash is a Rugged DevOps SaaS solution developed by Blackstone Technology Group and the Department of Homeland Security. The new DHS policy requires all mobile application developers to use Carwash when proposing, developing, implementing or changing any OHS Mobile Apps

Arlington, VA (PRWEB) April 13, 2016

Blackstone Technology Group (Blackstone), in partnership with the Department of Homeland Security (DHS), is proud to announce that Carwash has received the DHS Chief Privacy Officer’s seal of approval and is now required for all mobile application development.

Carwash provides a standardization of mobile application security across DHS. Blackstone and DHS’ partnership to design and build the application security framework has resulted in a valuable shared service to the DHS Enterprise that focuses on delivering secure and compliant applications to the Federal government and saves individual DHS agency components the time and expense of running their own security testing environment.

Carwash was initially developed in 2013 by Blackstone Technology Group in partnership with DHS to serve as a cloud-enabled framework for developers and teams to deploy safer applications. The solution reduces time to market and increases the security of applications by providing scan results to development teams throughout the SELC lifecycle. Identifying application vulnerabilities and issues early in the lifecycle reduces the risk of deployment delays and costly re-work.

“This is the first centralized mobile application scanning resource across DHS. There is a huge opportunity for security teams to use Carwash, and to share evaluations across organizations through the reciprocity report,” says Chris Drew, Senior Manager at Blackstone.

According to the new DHS policy, mobile app developers are responsible for, “Engaging and coordinating with the OCIO Carwash team to ensure that OHS Mobile Apps are sent through OHS Carwash process when proposing, developing, implementing or changing any OHS Mobile Apps.”

The Rugged DevOps solution Carwash is built on is capable of scanning more than just mobile apps and continues to evolve to include the latest technology and potential threats. Blackstone can tailor the framework to any app and just rolled out the ability to scan 3rd party Java libraries. “We have recently integrated this scanning solution within a pre-existing development process for two DHS agency teams,” says Anthony Glynn, Blackstone Architect and Carwash lead. “This empowers development teams to modify the version of their libraries to reduce vulnerabilities of the application and risk to the enterprise.”

Blackstone Technology Group (http://www.bstonetech.com) is a privately-held, global IT services and solutions firm founded in 1998 and headquartered in San Francisco, California. Influenced by disruptive technology of Silicon Valley, Blackstone Federal Services helps clients adapt to the demands of a digital world.

Established in Arlington, Virginia in 2002, Blackstone Federal Services has grown to over 100+ employees. With a specialization in Cloud, Cyber Security, Agile and DevOps, our experienced technologists bring digital expertise and innovative technologies to clients, faster.

Blackstone Federal has a proven track record of delivering results for many U.S. Federal Agencies such as Homeland Security, civilian and healthcare agencies. Our team members have received the Industry’s top certifications including AWS, CISSP, SAFe, PMI-ACT and PMP.

April 14, 2016
DevOpsDays Returns to Washington DC

DevOpsDaysDC returns to Washington DC June 7 and 8, 2016. Come share ideas on high velocity IT with peers in private sector and government; Call For Presentations on Continuous Improvement Extended to April 18.

WASHINGTON, DC (PRWEB) April 14, 2016

DevOps Days will return to the DC metro area, June 7 and 8, at the United States Patent and Trademark Office (USPTO) in Alexandria, Virginia. This event will bring together a diverse audience of professionals and industry leaders from the public and private sector who are adopting DevOps practices and principles.

The deadline for proposals to present on Continuous Improvement and better collaboration has been extended to Monday April, 18, 2016, just like the Federal Tax filing, to give you three days to get your returns filed and talks submitted.

“A house divided against Itself cannot stand,” this year’s theme, will be exemplified through two days of scheduled presentations, ignite talks, and open space conversations. This event is designed for executives, program managers, and engineers considering or actively implementing DevOps at their organization.

The second annual two-day event is sure to invite many in-depth discussions on how to continuously improve DevOps practices across the businesses and missions of attendees serving both private and public sector. Organizers are encouraging attendees, speakers, and sponsors of the event to openly discuss the successful milestones and changes their organizations are implementing along their path to DevOps.

DevOpsDays events bring unbelievable value for the $100 ticket price that covers both days and evening social events. Its aim is to bring together practitioners to share immediately useful insights and practices. What’s it like to attend DevOpsDays? See last year’s talks online at:http://www.devopsdays.org/events/2015-washington-dc/program.

“Last year had over 400 amazing attendees and DC area companies and federal agencies have continued to adopt the faster, more collaborative, delivery-oriented DevOps culture. We are really excited to see and share the latest developments in this adopt or be left behind space.”, stated Nathen Harvey, Conference Chair, DevOpsDays DC and Community Director, Chef Software, Inc.

Event Details:

● Dates: June 7 and 8

● Location: United States Patent and Technology Office (USPTO), Alexandria, VA

● Registration is open at http://www.devopsdays.org/events/2016-washington-dc/

● Call for Presenters (CFP) is open through April 18, 2015

https://devopsdaysdc2016.busyconf.com/proposals/new

● Follow us online at @DevOpsDaysDC, #DODDC

● Additional sponsorships are available at:

https://devopsdaysdc2015.busyconf.com/bookings/new?discount=SPONSOR

Early registrants include professionals from organizations such as the US Patent and Trademark Office (USPTO), Fannie Mae, CSC Global, and US Department of Justice (DOJ). DevOpsDays DC is honored to have these sponsors: USPTO, Excella Consulting, Pivotal, GlobalTech, Capital One, Cloud Passage, Netuitive, Solar Winds, Chef, CSRA, Docker, Comcast and Sonatype.

About DevOps and DevOps Days

DevOps (a portmanteau of “development” and “operations”) is a software development method that stresses communication, collaboration (information sharing and web service usage), integration, automation and measurement of cooperation between software developers and other information technology (IT) professionals. DevOps acknowledges the interdependence of software development, quality assurance, and IT operations, and aims to help an organization rapidly produce software products and services and to improve operations performance.1

DevOpsDays is a technical conference, aimed at developers, sysadmins, architects and anyone else involved in technology, whether expert or beginner. The term “DevOps” was popularized through a series of DevOps Days starting in 2009 in Belgium. Since then, there have been DevOpsDays conferences held in many countries worldwide.2http://www.devopsdays.com

About USPTO

The United States Patent and Trademark Office (USPTO) is the federal agency for granting U.S. patents and registering trademarks. The USPTO advises the president of the United States, the secretary of commerce, and U.S. government agencies on intellectual property (IP) policy, protection, and enforcement; and promotes the stronger and more effective IP protection around the world. The USPTO furthers effective IP protection for U.S. innovators and entrepreneurs worldwide by working with other agencies to secure strong IP provisions in free trade and other international agreements. http://www.uspto.gov

For More Information

Nathen Harvey

(202) 368-7264

nharvey(at)chef.io

April 14, 2016
Release Automation: Bigger than DevOps
Why DevOps is not for everyone and how release automation helps in bimodal world

So am I really going to write a blog calling DevOps a big hoax?

Well, not exactly, but as a follow-up to my previous blog on the difference between DevOps and Continuous Delivery, I want to alert you to a few key facts:
1. DevOps is not always the right methodology for developing and delivering software.
2. Agility and speed can be achieved even in a waterfall method if the right tools are in place.
3. Release automation is bigger than DevOps (yeah, I said it!).
Say No to DevOps?

Okay, so here goes: Why is DevOps not always the right way to go? Simply because not all systems are born equal. For a back-end master customer data system, stability trumps iteration. Fail fast and roll forward simply aren’t sustainable in many of today’s most core business applications such as banking, retail, media, manufacturing or other industry vertical. Clearly, these enterprises still need to innovate and provide new and exciting ways for their customers to engage through web and mobile, but not at the risk of a terminal business failure at the back end.

Delivery capabilities for these back-end systems need speeding so they don’t become the bottleneck for the entire business. However, restructuring teams and changing development along with test and release into tens and hundreds of small/tiny parallel updates cannot be supported by a legacy technology stack (say Siebel or SAP at the back end). It is likely not even advisable at all.

This doesn’t mean we should accept the realities of the last century, resort to the status quo and leave our release cycles to once or twice a year for key applications. Slowly and surely we would lose any competitive edge.

Luckily there is a middle ground, and this is why I believe release automation is bigger then DevOps. That middle ground is release automation. I will explain why, but I need to start by examining DevOps a little more first.

What is DevOps?

At its core, DevOps aims to get new ideas and functionality into the hands of users quickly and iterate fast. It achieves this by fixing two traditional weaknesses in the software delivery life cycle, namely “overhead” and “rework.”

Overhead is anything that developers do that isn’t directly related to developing new features or improving existing ones (manual deployments would be a big item in the overhead column for sure, as would debugging production deployment issues or handling configuration problems).

Rework occurs anytime developers have to go back over a piece of code they already have worked on. However, this does not include bug fixing, so rework occurs when test cycles take a long time and developers already have been working on new functionality, which now needs to be reworked to address a newly found problem.

DevOps tackles these challenges by attempting to shorten the cycles—for example, by adding smaller changes that developers and testers can test in real time or by using tools such as Puppet or Chef for provisioning quickly to test while ensuring consistency across systems.

This relies on Devs owning updates and rollouts across the life cycle, including production, which challenges everything in the way enterprise teams are traditionally organized. It calls for completely new processes, which often are a great fit for newly developed applications and modern architectures, but can be a complete misfit (and regulatory obstacle) for so many other core systems.

I’m sure you can see where I am going with this. Much like the story, “The Emperor’s New Clothes,” DevOps isn’t what people believe it is.

Why Release Automation is Bigger Than DevOps

The goals of DevOps are sound, however, which leads me to my last point: Release automation is bigger than DevOps. Done right, release automation can accommodate diverse organizational needs and different types of applications in this new, bimodal world. It improves the software delivery process and its final product by rooting out manual work, improving cycle times, reducing overhead and rework.

Crucially, release automation enables incumbent businesses to stay competitive and ensure survival without forcing them to completely abandon their DNA across the board in a “big bang” fashion. Such a process could put the very existence of a large enterprise at risk.

Before signing off on this blog entry I want to make one last thing clear: The argument I am raising here isn’t trying to downplay the benefits of DevOps as a valid methodology. Nor am I denouncing any of the DevOps tool chain technologies out there, which are all welcome advances, of course. This year, 2016, is (according to most industry experts) the year in which DevOps adoption goes mainstream, and I fundamentally believe that it is release automation that drives this adoption, not just pure DevOps conversions.

Stay tuned!
April 13, 2016