devopsy.kinsta.cloud

Category: Features

Survey: DevOps gaining mainstream traction in IT today

New survey results released last week shows just how thoroughly DevOps has captured the mindshare of enterprises. Commissioned by Rackspace, the global Vanson Bourne survey showed that more than three-quarters of IT decision-makers are now familiar with the term DevOps and well over half of them have already implemented DevOps practices to some degree or another. And by 2017, that figure could go up by another 31 percent according to survey respondents’ plans.

“This survey shows a real appetite for the kind of development and operational processes today’s digitally-focused businesses need,” said Chris Jackson, CTO of DevOps Services at Rackspace.

Among those who have chosen the DevOps route, nearly half have already fully integrated their development team with their operations team and 38 percent say that integration is in effect for all of their applications. For the most part, the ops team has been the primary champions for these projects. Approximately 43 percent of respondents with DevOps programs in place report that IT operations have driven them and 32 percent say either the CIO or the CTO have driven the program. Just 16 percent say developers have been behind their DevOps transformation.

As expected, among respondents who have deployed DevOps, 57 percent have already experienced faster delivery of new features and 46 percent have a more stable operating environment. Additionally, 43 percent reported increased innovation and 32 percent have even reduced their IT costs.

However, it is the business upsides of respondents’ DevOps adoption that are really eye-opening. The speed and innovation seems to have directly translated to improvements in the business as a whole. Over half of companies that have implemented DevOps report an increase in customer conversion and satisfaction and 43 percent say they’ve seen an improvement in customer engagement. As a result, DevOps is stimulating topline revenue growth, with 38 percent of respondents reporting an increase in sales as a result of their revised IT approach.

“DevOps is empowering IT functions to make a real impact on the business,” Jackson said. “It is also finally an opportunity for IT to be recognized for having a central part to play in delivering great customer experiences and ultimately increasing sales.”

However, deploying DevOps has not always been easy for these organizations. Approximately 37 percent of respondents who’d embraced DevOps reported internal resistance from ops teams and 32 percent said developer resistance posed problems. Fortunately, less than a quarter of wider business stakeholders stood in the way of DevOps adoption. Nevertheless, among all IT decision-makers, 41 percent still said they had other more urgent IT priorities that kept them from the DevOps journey.

“DevOps is all about encouraging innovation and streamlining processes to help ensure development and operations are working hand in hand to deliver business objectives,” Jackson said. “While, the findings suggest that the DevOps journey is already becoming well established in many organizations, there is still a job to do in articulating the benefits to all groups involved for them to accept and drive through this change.”

November 5, 2014
Automating Away the Regulatory Compliance Myth

At the recent DevOps Enterprise Summit, we had a chance to sit down with Justin Arbuckle and discuss his concept of “compliance as code” and why it’s so important that security and compliance tests be built into DevOps practices at large enterprises. Recently, Arbuckle was chief architect at GE Capital where he introduced and sponsored DevOps at that organization – so he certainly knows about what it takes to “do DevOps” in large, highly regulated environments.

Currently, Arbuckle is the vice president of EMEA at CHEF and also chief enterprise architect there. If you watch his talk from the DevOps Enterprise Summit, Hunting the DevOps Whale, you’ll see that he is passionate about the transformative potential of DevOps in large enterprises.

At CHEF, Arbuckle is in helping large enterprises understand how to “de-risk” their migration to cloud with automation. We caught up with him at the DevOps Enterprise Summit to ask why that is so important. Here’s what he had to say.

devopsy.kinsta.cloud: When it comes to DevOps and regulatory and security concerns, many people say, “Well, just automate those tests.” What does that mean, to you? How do you “automate in” security and compliance?

Arbuckle: I think, in terms of the specific issue of regulatory compliance, a lot of what we think of as the being compliant process today is a complete myth. There is just so much detail that needs to be checked that the organization is always in a position where they have to trade off against, “It’s good enough, we’re ready to go” versus, “We’re not going to go anywhere until we’ve literally crossed every T and dotted every I.”

The reality is that a lot of the regulations, Dodd-Frank is a good example, are getting to a level of detail where they’re beginning to talk about process. They’re beginning to talk about how you design product. They’re getting very deep indeed.

So the organization that has to govern that, can’t do it based on just this idea of oversight at particular points in the life cycle. Because if you’re going to do it properly you literally slow your velocity to zero, and so you’re making a trade-off between compliance and competitiveness.

The way to break that cycle is to, and this is a big paradigm shift for regulators, a big paradigm shift for compliance people inside organizations, you have to start being able to express those compliance requirements in a form that’s codable. Using something like Chef for instance what we’re able to do is we’re able to specify a particular policy in a way that is automatable. In a way that we know is always going to be implemented every single time.

devopsy.kinsta.cloud: Would that include input from security people, compliance teams, design teams, system architects?

Arbuckle: Absolutely. Honestly, in my experience I think the number of organizations that can count fully detailed, fully implementable — and that’s the key word — security policy by their infrastructure people is countable on one hand.

Generally speaking, there are many obvious guidelines that are standards-based. But as the security organization tries to keep up with security threats, they’re obviously learning as they go. In this way policy always lags. And the only way for the organization to catch it is through this process of documentation, policy, and checks. And through it all they know that the standard is nonsense because it’s out of date by definition. So they have to create a point-in-time review. And these point in time reviews bring velocity to a halt.

devopsy.kinsta.cloud: Yes. Especially when something is wrong. They hit a red button and everything stops coming off the assembly line.

Arbuckle: That’s right. The approach that we have to get to is the idea of policy as code. But you are not going to be able to, on the first go, be able to codify everything. Very often with automation, based on my experience, is that the difficulty at large enterprises has actually less to do with the tools and more to do with knowing what you want to automate. Knowing what you actually want to put in infrastructure as code.

It’s the same thing with security teams. Ask them to go through the most important things that need to be tested in automation, and getting them to go through that process. It’s often difficult because they are not development people typically. They’re not infrastructure people, And they’re not operations people.

They’ve kind of created their own “securocracy” if you like.

What security teams have to do is understand their work is subject to source control as well. Their work is subject to variation and evolution over time and we should write tests to ensure that the following policies are being applied consistently.

DevOps: And I assume these tests are designed over time, as one goes along? For example, if there’s a new malware or regulatory beast that you haven’t seen before, you can design a test and then implement that as part of the life cycle?

Arbuckle: That’s exactly right. And the great thing about tests is they are additive. You’ve got a test that tests for the range of ports that are open on the operating system and then you add another test, maybe testing for the types of applications that are installed on the box. They are two separate tests and they are additive. So as you continue, you build up your library of tests.

And for most organizations going through the adoption of test driven development, as an example, they have to do it that way. A large application that is beginning to develop in an agile way is going to have a lot of tests. If you take a typical large core banking application, for instance, it will probably have something in the region of about 5,000 use cases. That’s thousands and thousands of tests. Let’s just agree that in no short period of time are you going to write those tests.

devopsy.kinsta.cloud: That’s an enormous catalog of tests. How do you keep them up to date and fresh? I imagine as security changes, regulatory compliance changes, you may have to tweak these tests as you go along. How do enterprises keep up?

Arbuckle: Like any requirement you have stakeholders that are responsible for those requirements. In just the same way, if you had for instance a mobile application and you have a product owner for that mobile application and that product owner is prioritizing feature sets you should also have a product owner for compliance.

And the product owner should be detailing what the set of compliance requirements are for the product.

Essentially compliance is embodied in the tests that are run against the appropriate applications. And so to manage automation and compliance as code, you need to have a product owner for compliance. And compliance as code, or automation, is the way it has to be in order for compliance to actually be true and consistent, as opposed to a myth.

November 4, 2014
Microsoft determined not to get left behind by DevOps

Microsoft is a massive company—a behemoth with a lot of inertia, and a lot of bureaucracy in place that make it difficult to adapt quickly. Under Satya Nadella, however, Microsoft is striving to re-invent itself, and—to the extent that it is possible—become more agile. For evidence of Microsoft’s new philosophy, look at how Microsoft is aggressively embracing concepts like open source and DevOps that used to be viewed as pariahs.

I wrote recently about the partnership between Microsoft and Docker. Microsoft added support for Docker containers in the Azure cloud platform within Linux virtual machines earlier this year, but then it upped the ante by announcing that it will support Docker natively in the next version of Windows Server, and that it is working closely with Docker on an open source project to drive development of the Windows engine for Docker.

“An important aspect of this announcement is the noticeable speed we are observing Microsoft move to implement open source technologies,” explained Al Gillen, an analyst with IDC, in a report about the relationship between Microsoft and Docker. “The company appears to be determined not to be left behind as the velocity of open source developer technologies accelerates. The company appears to be willing to integrate competing technologies, or technologies from competing ecosystems at a faster pace and with less hesitation.”

Docker isn’t the only piece of the puzzle, either. Earlier this year Microsoft joined forces with Chef and Puppet Labs, and integrated both of those popular DevOps platforms into Azure as well. Incorporating Chef and Puppet Labs gives IT admins more flexibility to deploy, configure, automate, and manage VMs in Azure.

What the new philosophy really represents is a realization. Nadella’s Microsoft sees the writing on the wall, and understands that it’s a new world. Technologies have changed, and the way companies and individuals use technology has changed, and the days of dominating the tech universe as a virtual monopoly are gone. The two choices facing Microsoft were to either stubbornly cling to its former glory and die a slow, painful death, or adapt and embrace change in order to remain relevant, and continue to play a vital role. Thankfully, it seems Microsoft has chosen the latter path.

What does embracing change look like? Microsoft appears to be taking a two-pronged approach. On the one hand, Microsoft is changing internally to shed some of its entrenched bureaucracy and enable it to function with more agility. It is also striving to keep up with new technologies itself—buying Nokia to bring smartphone manufacturing in house, developing the Surface tablets, rolling out the Microsoft Band wearable health tech, and other initiatives demonstrate that Microsoft is working hard to break free from the shackles of its own past, and find ways to keep up with the changing tech landscape.

The second—and arguably more important—prong is how Microsoft is addressing the new multi-vendor, cross-platform world we live in. Microsoft recognizes that it is not the only game in town, but it has a vested interest in ensuring that customers continue to rely on Microsoft tools no matter what platform they choose. To that end, Microsoft is doing a much better job of offering its own products and services across a wider range of devices and platforms.

The new Microsoft represents a win-win-win scenario. It’s a win for Microsoft because it enables the company to shift and evolve to stay relevant with a rapidly-changing tech landscape. It’s a win for open source and DevOps because companies of all sizes are built around Microsoft operating systems and applications, so incorporating support for open source and DevOps tools exponentially increases the potential customer base. Finally, it’s a win for the customers themselves because they get to maintain their existing investments in a Microsoft infrastructure, while also gaining access to new tools that enable greater automation and efficiency.

November 3, 2014
How to Enhance DevOps by Supporting the Work of the Build-Release Engineer

Support Through Freedom

As we’ll see, supporting the work of the build-release engineer enhances DevOps by adding consistency, easing minds, and freeing DevOps teams to do more. To support the work of the release engineer, the enterprise must set them free as well, by letting them automate everything, treat manual interventions as process failures, and configure the target deployment machine and its monitoring context.

Enable the Release Engineer to Automate Everything & Treat Manual Interventions as Process Failures

One of the best ways to support the work of the build-release engineer is to encourage them to become actively hostile to manual interventions, says Robert Fischer, VP of Engineering, Webonise Lab www.webonise.com. Release engineers should shoulder the responsibility for putting manual interventions out of reach.

An enterprise’s internal DevOps community should empower the release engineer to automate as many steps as possible, which may require the enterprise to give them programmatic access to environment credentials, says Fischer. “For the internal DevOps community, the reward for permitting this risk is that they will have a cleaner environment that everyone understands better. This will make it easier for them to respond correctly in stressful situations,” says Fischer.

“So, let’s say you have some Linux VMs spinning up as part of the release. The release engineers could be tempted to use some kind of global SSH key for accessing these VMs, which they would install nicely on their laptops or workstations,” starts Fischer. Unfortunately, this will make it easy to add undesirable and unnecessary manual steps such as “‘Log in and set this IPTables value’ or ‘Log in and manually determine this hostname’”, says Fischer.

And while it would be easier to enable and apply these changes in the short run, it would leave a monkey wrench under the hood of automation and discombobulate the efforts of DevOps true believers in the long run. And it would all start simply by enabling the global SSH key and making these manual steps possible.

These kinds of manual processes also crop up in branches in the release logic: ‘Login to the server and see if packages X, Y, or Z are up-to-date in the image. IF they aren’t, THEN…’ All of that needs to be automated. “If the release engineers make it hard to implement manual steps, then they are more likely to A) notice and B) avoid these manual dependencies,” clarifies Fischer.

Instead of making manual steps possible, the release engineer should create active blocks for manual intervention, such as putting virtual machines within a virtual private cloud or making them only accessible using the automation tools’ SSH keys, says Fischer. This will actively impede manual interventions like those first cited herein and force the release engineer to think. “The result is that you are more likely to build the appropriate automation steps and error handling instead of creating a dependency on manual intervention,” says Fischer.

Empower the Release Engineer to Configure the Target Deployment Machine and It’s Monitoring Context

Another way to undergird the work of the release engineer is to open up the target deployment machine and monitoring context configurations to them. To enable the release engineer to configure the target deployment machine, make tools like Docker www.docker.com available. To enable them to configure the monitoring context, automate the configuration of the virtual machine platform (e.g.: AWS http://aws.amazon.com security groups, load balancers, etc.). “This allows for tuning to be a part of the release planning,” says Fischer.

The enterprise DevOps folks can still make manual adjustments if they must, but they should resist the impulse to use that option, except when handling anomalies. “Leaders in enterprise DevOps approaches can audit these deployment instructions for sanity and compliance, of course,” says Fischer.

As is the case with automating otherwise manual processes, the enterprise DevOps team should have a lot less to worry about once they set the release engineer free to configure these things. “This should give them more time to tackle the hard and interesting problems instead of performing repetitious and error-prone manual interventions by letting the computer handle the brain-dead computational and rote part of DevOps, which is what computers are good at,” says Fischer.

October 30, 2014
Capacity planning isn’t dead, but it’s not about supply any more

DevOps, flexible cloud architectures and continuous delivery have all simplified a lot of equations in IT today, but there is one element that’s grown infinitely more complex: capacity planning. With the ability to spin up new environments on a dime through services like Amazon and Rackspace, the bucket of potential IT supply has grown infinitely more flexible. Meanwhile, as DevOps practices helps organizations speed up the continuous delivery cycle of designing, building and running new application instances, the demand for computer power and storage space is constantly changing. This week at Camp DevOps Houston (link), Steve Wilson with VMTurbo will explore what this means for capacity planning in his talk “Is Capacity Planning Dead?”

“In this cloud day and age, it really isn’t about capacity anymore, because capacity becomes a figurative thing with IT borders and the data center really just melting away,” Wilson says. “I can rent if I need to. Really this idea of capacity goes away, and what you really want to understand is where’s the cutoff where I stop buying and I start renting?”

Wilson believes that while capacity planning isn’t necessarily DOA in today’s DevOps world, it does need to be completely turned on its head. Rather than focusing on supply-side issues, planners need to concern themselves much more with demand.

“For eons and eons, we have been really good at managing supply—because it never changed. It was finite. It was like ‘OK, I’m going to put alerts, and I’m going to put thresholds, and I’m going to set the bar, because I know that when my supply runs out, that’s bad,’” Wilson says, explaining that capacity planning was all about moving thresholds to ensure IT never ran out of supply. “But now, if it’s a truly software-defined data center, it’s no longer defined by your infrastructure. So what if I could actually manage demand — not supply.”

The idea, he explains, is to gather a deep and continuous understanding of what demand is in order to buy infrastructure for the average demand and then ‘rent’ cloud infrastructure to soak up the peaks of demand when they present themselves.

“If I understand demand, I can buy for my 50th percentile plus maybe one or two standard deviations, and then rent above that and scale out,” he says. ” then all I really want to do is collapse that line of getting a good understanding of where that financial line is where it is economical for me to extend CapEx internally, and then that tipping point where it’s actually cheaper for me to extend OpEx to handle the peaks.”

With DevOps, he believes it may be easier for organizations to truly understand the demand profile of different applications, due to greater collaboration between developers and operations staff. The trick is to ensure that capacity planners are roped into the design, build, run cycle from the beginning, as they are currently operating in the fringes, frequently using spreadsheets that are outdated as quickly as they are made when an organization is delivering continuously.

“Suddenly, every time you try to make a change, you try to deploy, you’re playing whack a mole, and then you start to break down. One place you’re hot, the other place you’re cold, and you don’t understand the demand workload and you can’t move it around and you’re just managing supply,” he says. “If I can always understand and map demand properly, I can automate the crap out of that, because now I’m basically creating just-in-time compute. If I can run computes super lean, then at peak I can just rent.”

October 28, 2014
Separation Anxiety & the Leap from Dated IT Approaches to DevOps

Never ASSUME!

I assumed that the drag on moving from IT as we knew it to a DevOps approach (with its continuous software deployment and other advantages) was due to the separation anxiety and fears of loss or change on the part of enterprises on the whole. As you may know from the 70’s TV show, The Odd Couple and its character Felix Unger, played by Tony Randall, you should “Never ASSUME, because when you ASSUME, you make an ASS of U and ME.” *

And so I was mistaken, but not far off from the truth. “I don’t think that enterprises as a whole fear change so much; what I think happens is that individuals fear change and erect a number of barriers to change,” says Alan Baker, President and Chief Consultant, Spitfire Innovations (link), a business process optimization consultancy. Let’s investigate some of those fear-based barriers.

Barriers to DevOps, Based in Fear

The first barrier is resistance due to a loss of knowledge. “There are individuals within IT who have built their careers around the current practices and approaches,” says Baker. These IT professionals have developed reputations as subject matter experts, which they truly are. This enhances their value, but only so long as the current subject matter retains its value. By moving to DevOps and making material changes to the way developers and IT operations accomplish their work, the enterprise will diminish their knowledge as well as perhaps their status and their usefulness to the company. They have a vested interest in the status quo. They would have to have more to gain by joining DevOps than by opposing it in order to move to a more progressive approach to change management, according to Baker.

The second barrier is political; it’s the loss of control. IT professionals who shoulder accountability for operations day in and day out are typically averse to loosening their grip on how change is introduced into their environment. “That’s understandable, because once something is productionized it’s their responsibility; they want to be completely sure that the deliverables are defect-free,” says Baker. For this reason, these individuals are going to need assurances that the new processes will maintain the integrity of the deliverables, says Baker.

The third barrier is structural. In an environment where some form of management by objectives is practiced there is typically little alignment of objectives between different groups. “Day-to-day operations typically have objectives relating to efficiency (such as throughput), whereas development objectives are driven by dates and cost,” says Baker.

Reaching for Change

If the enterprise is going to break down these barriers and change its practices, all the stakeholders need to come together and agree on a plan of action. The stakeholders, including anyone tempted to resist DevOps, need to fully and collectively develop the future state of the enterprise, focusing on shared objectives. “All groups that are concerned need to have a set of common goals to work towards that satisfy all stakeholders,” says Baker.

There also need to be necessary supports. A DevOps approach requires increased integration and communication between all of the stakeholders. The walls need to come down. “This openness doesn’t necessarily come naturally to all IT staff; the organization will need to invest in the appropriate education and expert guidance (as well as some patience) to ensure that the cultural change has a chance to take root,” says Baker.

The final item consists of two value propositions. These value propositions give the organization the opportunity to demonstrate its vision, transparency, and resolve. The first concerns the need of the organization for someone to take an approach that answers the who, what, when, where, why, and how questions surrounding DevOps activities and responsibilities, and then to clearly articulate all aspects of the change to everyone. It’s a necessary step in order to get the buy-in. The second value proposition is directed at the individuals impacted by the change. Help answer the question ‘What’s in it for me?’, particularly for those individuals working themselves out of a role.

*It was one of the show’s funniest and most memorable lines and is repeated to this day. Though proper attribution for the original comment may ultimately be out of reach, see http://en.wikipedia.org/wiki/Jerry_Belson for the Television Writer who placed it in the Odd Couple episode.

October 26, 2014
Eight critical DevOps practices: innovate, deliver, repeat
DevOps has been garnering a lot of interest for some time. Discussions and debates on forums like devopsy.kinsta.cloud are improving our collective understanding of the right approach and now we are seeing concrete proof points of fast-movers applying DevOps practices to disrupt entire industries with rapid-fire, digital-innovation based on Cloud, Big Data and Mobile technologies. I have personally been part of this transformation at IBM for several years and would like to reflect on what we have learned, and also share with you results of a recent study from Forrester Research.

DevOps helps organizations address a critical business challenge – that of continuously capturing and responding to feedback (both internal and external) so we can rapidly and repeatedly turn innovative ideas into highly relevant, and desirable, products and services. This involves not only development and operations, but all aspects of the organization, as it entails the collaboration across the entire organization including business and supply chain. Compared to single-direction, traditional models, DevOps is bi-directional and is based on not just pushing something out to the customer but also on getting their feedback to make improvements.

In a recent webcast, I discussed eight DevOps practices that speed up software delivery with Kurt Bittner, Principal Analyst at Forrester and a leading expert on agile and iterative software development. This webcast highlighted a recent Forrester survey on DevOps practices, cycle times and where enterprises are in terms of the maturity of DevOps practices adoption.
You can watch the webcast replay here to know more – ibm.biz/Forrester-talk

Their survey of 600 IT professionals with application development responsibilities found that about a third of teams consistently deliver at cadences of one to three weeks and that the fastest teams generated higher business satisfaction than slower teams, an indication they don’t sacrifice quality to deliver fast. The study reveals how these teams did it: by adopting the following eight DevOps practices:
1. Minimum Viable Product – Deliver the smallest viable product or application and then improve it in subsequent rapid releases, based on feedback, and delivering value incrementally.
2. Dedicated Teams – Form dedicated, cross-functional teams, avoid over-specialization and ensure they are not interrupted by side projects.
3. Loosely Coupled Architecture – Use loose architectural coupling within and between applications to reduce complexity and enable delivery in small increments.
4. Minimize Hand-offs, Maximize Flow – Eliminate unnecessary steps, delays and friction between steps to increase the flow of work.
5. Deliver in Small Batches – Deliver in smaller batches helps to expose the most uncertain issues first and enables feedback on the most valuable usage models earlier.
6. Transparency – Transparency into progress helps everybody to see where you are at any point in time and also visibility into risk without decreasing productivity.
7. Eliminate Overhead –Eliminate the overhead of periodic and manual status reports and status meetings which absorbs valuable time and distracts focus from delivering value.
8. Automate Testing using APIs – Shift away from heavy manual testing to improve delivery speed, quality, and testing accuracy, and dramatically reduce cost.
The study refutes the myth that releasing fast requires you to sacrifice quality and accept higher risk. Adopting these eight DevOps practices, especially automated testing and delivering in small batches, does exactly the opposite: small incremental releases are more thoroughly tested, more stable and lower risk.

The best part about DevOps adoption is the flexibility to choose which practices to adopt first, based on each organization’s priorities, and then to incrementally adopt the rest of the practices as needed to optimize the software delivery lifecycle and accelerate innovation.

To learn more about the survey and the eight DevOps practices, download the Forrester study along with the approach that you can follow to adopt these as per your organization’s current state of delivery cycles.

About the Author

Ashok Reddy is responsible for Product Management & Strategy, product Design/user experience and Business Development for Rational Software Division of IBM Software Group and for the IBM DevOps portfolio. He is based in Raleigh, NC, USA. Ashok’s role involves all aspects of global product delivery including setting product strategy and for product line management, establishing product roadmaps and partnerships for IBM DevOps portfolio.
October 22, 2014
4 themes to expect from DevOps Enterprise Conference

The next few weeks are busy ones for the DevOps conference circuit. In just a week, devopsy.kinsta.cloud will kick off another one of its intimate Camp DevOps gatherings in Houston, with talks lined up on everything from the evolution of DevOps to mythbusting DevOps fallacies. Meanwhile, another worthy show kicks off from San Francisco today: DevOps Enterprise. A product of collaboration between IT Revolution’s Gene Kim and Electric Cloud’s Steve Brodie, this week’s confab sold out with 500-attendees, and its own program is jammed with a slate of speakers passionate about agile development, continuous delivery and DevOps. devopsy.kinsta.cloud caught up with Kim and Brodie before the show to learn a little bit about what’s on tap. According to the pair, there are four key trends and themes that seem to weave themselves throughout the conference’s programming:

1. DevOps Is About Normal Organizations Doing Heroic Things

According to Kim, the stories being told by the program speakers are as “heroic and amazing” as anything you’d hear from the outlier “unicorn” companies like Google, Amazon, Etsy who are setting the pace for the DevOps movement.

“And they are not only replicating the results you’d typically see from these unicorn Internet companies, they’re doing it inside organizations that have perhaps decades of low-trust, command-and-control bureaucracy,” he says.

2. Chief Architects Are The Newest Actors in the DevOps Cast Of Characters

Not only will the storytellers include ops leadership, dev leadership and executive leadership, there’ll also be a strong contingent of chief architects stepping in to discuss continuous delivery.

“Architects are often the first people to see the problem because they see the end-to-end BLANK stream,” Kim says, “and architects are in a very powerful place to affect change that spans dev, test and operations.”

3. DevOps Spans Across More Industries Than You’d Think

While there will be speakers from the type of usual suspect companies one would expect to be practicing DevOps—Web, IT, software and so-on—the range of types of companies represented by the speakers shows the surprising reach of the movement across industries, Brodie says.

“DevOps is relevant across sectors,” Brodie says. “We have presentation from companies you’d expect, but also, for instance, government, and organizations doing embedded systems development. Sometimes people think of DevOps as big data center-centric, but it is relevant with the Internet of Things and in this mobile world.”

4.Security Is Possible Through DevOps

“The number one objection that comes up over and over again in terms of why we can’t do DevOps is information security and compliance,” Kim says. But more than one speaker will explain why infosec is not only possible with DevOps, but actually stands to benefit. And that includes not only risk management, but compliance in highly regulated industries as well. “We have a whole panel on security and compliance, including James DeLuccia from Ernst & Young, describing how publicly traded, heavily regulated organizations are putting DevOps systems into place and still maintain compliance.”

Even though the conference is sold out, the entire DevOps community can benefit from the programming. The show is offering a live stream starting at 9 A.M. PT for those interested in viewing talks remotely.And if you’re still craving the benefits of networking in a conference hallway track, there’s still time to sign up for Camp DevOps Houston. Registration is still open and it is just $5.

October 21, 2014
Embedding security testing to avoid headline-inducing configuration fails

When news broke earlier this month about the nation’s largest bond insurer exposing sensitive account information to Google’s indexing spiders due to a server misconfiguration, many an IT professional wondered how such a massive fail could have been neglected for so long. Security experts called it out-and-out negligence by the company, MBIA. But the truth is that plenty of other businesses with traditional IT departments could have just as easily suffered the same fate. MBIA was just unlucky enough to have caught the eye of security researchers and inquiring journalists.

The fact of the matter is that most IT shops today still stink at configuration management. According to a survey out by Avaya earlier this year, 82 percent of organizations today still experience network downtime due to human error around configuration changes. In MBIA’s case, it wasn’t downtime but a data exposure that MBIA suffered as the result of a misconfigured Oracle Reports server tied to a web application. The issue allowed back-end data such as account numbers, routing numbers and other sensitive data to be indexed by Google, along with administrative credentials that would let attackers access any other data not already out there for the world to see. Avoiding these kind of blunders stands as one of the big value propositions of DevOps processes and the orchestration toolsets that support them.

“If they’d used DevOps, they’d probably have caught this issue much sooner,” says Rajat Bhargava, CEO of JumpCloud. “They should have controlled configs and change management, and DevOps is generally useful for those things. You make a change, you make it in code and theoretically people ought to be able to document these changes and then apply them across the board. So it is a little more controlled than someone going in manually and changing a setting and forgetting about documenting it.”

However, when it comes to reducing the overall risk posture of infrastructure managed by the constant flux of DevOps’ fast iterations, Bhargava believes many organizations could stand to take their practices to the next level. He says they can do that by better embedding security testing into the DevOps cycles.

“Clearly, DevOps shops are already doing automated testing around their code,” he says. “So there’s no reason why we can’t embed automated security testing just as we’ve automated QA and so on.”

This means not only testing the security of the code itself, but also of the configurations and overall system security once that code goes live. Doing so acts as a backstop to the already automated configuration management process, which can be huge since a human error at the top of the orchestration stack could prove even more disastrous than the kind of one-off configuration error that hurt MBIA.

“With great orchestration and configuration management tools, comes great responsibility. A simple misconfiguration of a system is only going to be compounded to the nth degree when you introduce DevOps configuration tools,” says Andrew Storms, a security and DevOps expert.

Just as DevOps can speed up update cycles for software and configuration, adding security automation and testing into the equation can speed up response to problems—whether they come from internal human error or news of new threats that need immediate attention from both dev and ops teams.

“For example, I know of companies that patched their entire DevOps enterprise for Heartbleed in a few hours,” Storms says. “Security best practices dictate that the security of systems be continuously checked in all environments — from early in the development process all the way into the production environment. Security is struggling to retool their processes and mold their staff to fit into the new ever changing DevOps world. It’s not just DevOps shops that need to do a better job at incorporating security into their processes. However, combining DevOps automation tools with security products is a true force multiplier that is our next best hope to get security right.”

Rich Mogull, CEO for analyst firm Securosis, agrees. He sees the kind of embedded security testing that Bhargava is advocating for as a huge opportunity for DevOps organizations.

“If you’re using the DevOps pipeline, to be able to go ahead and add security testing to that is a massive opportunity, and there are a bunch of tools out there to do some awesome testing (whose effect) would be extremely difficult to replicate using non-DevOps, traditional deployment testing,” Mogull says. “Not only is there an opportunity to get security engaged with automated testing, but you combine that with the building of a secure DevOps pipeline and I think we can wipe out entire categories of security issues.”
For example, at Black Hat Europe this week, Mogull says he talked to a company that no longer has to deal with the traditional firefighting exercise of patching machines.

“When they have to patch for something they actually just push the updated instances through their automation,” Mogull says. “So they’ll rebuild a new image and when they’re done with that, Jenkins will push it out into production and terminate the old instances.”

Mogull also believes that security testing of code is a big part of the value proposition of embedding security into DevOps. Security vendors like Veracode are now starting to tie into Jenkins to let developers know code has security issues and where to find those issues before pushing them into production. And tools like Gauntlt are making it possible to spin up cloud environments and automate vulnerability assessment, network scans and configurations and flag policies through a Jenkins plug-in. Additionally, in the same vein as the patching example, incident response to viruses can be completely rethought, because “if an instance gets infected or something along those lines, they blow them away,” Mogull says.

On a different security front, Mogull says the early adopter he spoke with at the conference also disabled SSH for admin log-ins to their production systems.

“Because, with DevOps, nobody should ever log into a production system,” Mogull says. “Any changes you make, you make at the beginning of your pipeline and then that gets pushed out and flows into production.”

October 20, 2014
Microsoft partners with Docker to bring containers to Windows Server

Docker has taken the DevOps world by storm, and that has caught the attention of Microsoft. Now, Microsoft and Docker are teaming up to bring native support for the container technology to the next generation(s) of Windows Server.

Docker is an open platform that enables organizations to run any application as a Docker container. The Docker containers can be implemented across virtually any infrastructure—delivering tremendous agility and flexibility for managing virtual applications. The container concept accelerates software development timeframes, and allows organizations to reduce costs and improve efficiency at the same time. It’s easy to understand why Docker is so popular.

There have been more than 21 million downloads of the Docker platform, and there are over 45,000 “Dockerized” applications available on the Docker Hub Registry, and 13,000-plus Docker-related projects on GitHub. Just last month Docker took in $40 million in another round of investment.

Major names in tech, like Rackspace, Google, and IBM have already pledged their support for Docker. Now Microsoft wants to bring the hot technology to Windows.

Docker Engine for Windows Server will allow customers to create Docker container applications that can run locally on Windows Server, or on virtual Windows Server instances in the cloud on Azure. In a blog post announcing the Docker partnership, Ross Gardler of Microsoft Open Technologies explains, “As part of this announcement, MS Open Tech is contributing code to the Docker client that supports the provisioning of multi-container Docker applications on Azure. This code removes the need for our cross-platform CLI to bootstrap the Docker host. In other words, we have taken a simple process and made it even simpler.

“This development is interesting because Docker has been a really fast moving technology having come out of almost nowhere a year ago to where now it is an incredibly widely supported technology,” stated Al Hilwa, an IDC analyst. “It is a bit of engineering but Microsoft wisely decided that they did not want to leave Windows developers out of the Docker party. This is good for Microsoft because those 45K ‘Dockerized’ applications will be able to run on Windows.”

To be fair, Microsoft isn’t completely new to Docker. Earlier this year it added support for Docker in Azure, but only on Linux. This new partnership launches an open source project to develop a Docker Engine runtime for building, running, and managing Docker containers natively within Windows Server. Docker Engine for Windows Server will be managed as a Docker open source project, but Microsoft will be a major contributor to the community.

The Microsoft blog post describes why Docker’s container technology is so important for the fast-paved development of a DevOps environment. “Containers do not include a full operating system, consequently rapid development and scaling of container-based applications is possible through very quick boot and restart operations. Furthermore, highly efficient creation of modified container images, by virtue of only capturing the differences between the original and new containers, enables improved management and distribution of containerized applications; the resulting images are both small and highly portable across almost any platform.”

Hilwa summed up with some thoughts about the new strategic vision of Microsoft. “What is even more interesting is that the work on the Docker engine in Windows is being done in open source—really showcasing the new Microsoft attitude towards open source (e.g. the open sourcing of Roslyn a few months ago). I really think we are seeing a faster and more open Microsoft, one that is more willing to integrate and collaborate with competing technologies without a lot of hesitation.”

October 16, 2014