“DevOps is a lifestyle, not a title.” This is a quote from Ron Melanson, of Amazon, and I hope he won’t mind me sharing it here. It struck a chord with me, and this blog explains why.
I have spoken about DevOps on a few occasions. Some audiences are not from a development background, so I explain the “why” of DevOps to them to help set context.
Chances are you are past the “why” stage and into the “how” stage. Even so, it is always useful to think about the “why” part, or even to revisit it—it is important to make sure you really are getting what you want from the DevOps journey.
In my DevOps presentations I vary between the transactional aspects of the “why” and the emotive aspects of the “why.” The transactional aspects are what the tooling can help with, and so that matters to a degree. However, since emotions influence us the most, especially from a lifestyle perspective, it is the emotional aspects that I want to focus on here.
The picture below captures, for me, the essence of why people care about DevOps: they want to be happy at work, and to sleep soundly at night. If you are not where you want to be with respect to those things, then you need to change the way you lead your life.
The DevOps lifestyle is a virtuous cycle
I highlight the “change the way you lead your life” aspect to illustrate contrasts among the differing approaches to DevOps that I have witnessed.
Now that DevOps has grabbed the popular imagination, it is quite common to see job advertisements for people to be part of a DevOps team.
One ex-colleague of mine, hired to lead a DevOps team, expressed some concern about whether that notion actually made sense. He saw his team off in a corner focused on tooling and processes, i.e. the transactional, while everyone else in the organization seemed to be doing what they always did.
When his team suggested a change to a process, or tried to explain how a tool could be adopted, they often were at a disadvantage. The people in development and operations, whose working practices would be affected, had not actually bought into the whole idea in practice, and/or simply did not have the bandwidth to think about it.
Consequently, with little or no time to pay attention to what the DevOps team were doing, there was no engagement from the people for whose supposed benefit the DevOps team was laboring. Thus, there was no driver for changes in behavior. They were all missing the emotive “why” part.
The challenge my colleague faced is common. Hiring someone to do DevOps does allow you to focus on getting people with the skills and experience for the transactional and technical aspects of DevOps. That is necessary, but it is far from sufficient.
If the benefits are to accrue to the people working in development and operations—and, indeed, the wider company and business they serve—then it is those people who have to own the idea, top to bottom.
Owning the idea means rethinking what you are doing, and why—in other words, changing your lifestyle. At least at work, anyway.
Venrock Leads the Round; Doug Dooley Joins Board; Jeff Williams Leads Sales
DUBLIN, CA–(Marketwired – April 28, 2016) – Evident.io, the leading provider of cloud infrastructure security and compliance automation, announced today that they completed a Series B funding round with Venrock valued at $15.7 million. Venrock is a premier venture capital firm with an impressive portfolio of companies including Checkpoint, Imperva, CloudFlare, PGP, Vontu and Niara.
“Venrock is one of the most successful and well respected venture capital firms in the technology sector,” said Tim Prendergast, cofounder and CEO of Evident.io. “Their support affirms our company’s high value pedigree and validates that our solutions are truly defining a new era for cloud infrastructure security, incident response, and compliance.”
Evident.io enjoys a unique competitive advantage in the market by providing organizations with unparalleled continuous monitoring and remediation capabilities by way of an agentless vulnerability and configuration management solution that automates security and compliance requirements.
As organizations of all sizes are continuing to accelerate the adoption of public cloud offerings, there is increasing demand for innovative cloud-native tools to manage an entirely new category of risks. The investment by Venrock will empower Evident.io to expand on its current offerings as well as develop new capabilities for securing sensitive workloads while satisfying compliance demands on multiple cloud platforms, all through a single solution.
“Effective security orchestration and management of public cloud infrastructure requires new technologies that are not only designed in the cloud, but also specifically for the cloud,” said Justin Lundy, cofounder and CTO of Evident.io. “Our team’s extensive history of being on the front lines of security for Fortune 500 companies combined with our passion for innovation allows us to accelerate the development of the advanced security capabilities organizations need today.”
Venrock’s investment, along with those made previously by Bain Capital and True Ventures, allows Evident.io to expand this unique offering beyond Amazon Web Services (AWS) to include other leading cloud provider platforms, enabling organizations to better protect their increasingly diverse workload deployments in spite of a serious cloud security skills shortage.
“Two of the biggest challenges businesses face in information security are a lack of security talent and the risks associated with migrating sensitive data to cloud environments, and Evident.io has delivered a security platform that address both of these challenges,” said Doug Dooley of Venrock. “The depth of visibility through automation provided by Evident.io represents a significant force multiplier for existing security talent, and the breadth of risk management capabilities that the team has developed is nothing less than impressive.”
Dooley will join the Evident.io Board of Directors, which includes Bain Capital’s managing director and former Symantec CEO Enrique Salem, and True Ventures partner Puneet Agarwal.
“Evident.io has emerged as the clear leader in cloud infrastructure security, with plans to grow and expand far beyond their current value proposition,” said Agarwal. “We’re thrilled to continue our support of the Evident.io team as they continue to innovate around cloud security and compliance.”
Evident.io also announced that veteran security executive Jeff Williams, Operating Partner at Bain Capital Ventures, has joined the company’s executive team as interim Senior Vice President of Sales to lead sales strategy and execution globally.
Well-known for his success at FireEye, IronPort Systems (acquired by Cisco in 2007), IntruVert Networks (acquired by McAfee in 2003) and GlobalCenter (acquired by Exodus Communications in 2001), Williams joined Evident.io as part of a strategy for pursuing aggressive expansion commensurate with the rapidly growing Cloud Infrastructure Security market.
Williams’ expertise focuses on infrastructure software and security, with more than 25 years of operating experience in assisting early-stage enterprise security companies to scale rapidly. He has assumed numerous board of director roles while partnering with management teams to develop aggressive go-to-market strategies and efficient sales engines designed to engage large enterprise customers.
“Evident.io is uniquely positioned to extend its leadership in public cloud security and compliance automation, with a value proposition that no other competitor can match,” said Williams. “With this new round of funding, and an expanded board of directors and executive team, we believe that Evident.io has the ideal combination of financial stability, leadership talent and exceptional technology to deliver tremendous value to the market.”
About Evident.io Evident.io is the pioneer and leader in security and compliance automation for public cloud. The Evident Security Platform (ESP) enables organizations of all sizes to proactively manage cloud security risk — minimizing attack surface and improving overall security posture, all from a single dashboard. ESP continuously monitors an organization’s entire AWS footprint, identifying and assessing security risks, providing security staff with expert remediation guidance, and enabling painless security auditing and compliance reporting. Built on Amazon Web Services APIs, ESP is agent-less and can be deployed to even the most complex environments in minutes. Evident.io is a privately held company based in Dublin, CA and backed by Bain Capital Ventures and True Ventures. For more information, please visit: www.evident.io. Evident.io is an AWS Advanced Technology Partner (the highest tier of partnership with Amazon Web Services), a corporate member of the Cloud Security Alliance, and a participating organization of the PCI Security Services Council (SSC).
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:
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.
The amount of testing you need to do is dependent on what industry you’re in and your specific use case.
Consider what level of test pass/fail you’re comfortable with, based on what you’ve done in the past.
Consider pre-commit or pre-flight builds to ensure your tests are more likely to pass once checked to Mainline
Define your requirements for each test cycle
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.
If you hire well and bring new skills to your team, your process will get better and faster.
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.
Automate manual steps that you take for granted to accelerate cycle times and improve productivity. Speed comes second.
Iterate on the testing process, and not just on the code itself. You should always be looking for new ways to test.
Test your test processes. Hold regular meetings with your team to reassess if your testing strategy is working for you.
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.
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.
DevOps and continuous delivery are the same thing, right? Far from it. We peer through the fog to understand the difference between the two related but distinct methodologies.
We live in an era of apps. More and more of our personal, social and work life is governed by apps—communicating with one another through social apps, booking cinema tickets through your mobile device or scheduling a business trip through the airline app. This digitization of services has arrived. Organizations that understand this sea change have a unique opportunity to jump ahead of their competitors, acquire customers more quickly and grow revenues.
The battleground for this service development is DevOps. It’s not a product, but rather a methodology for helping organizations build teams and build software. DevOps is a culture, movement or practice that emphasizes the collaboration and communication of both software developers and other IT professionals while automating the process of software delivery and infrastructure changes. It creates a culture and environment where building, testing and releasing software can happen rapidly, frequently and more reliably.
Organizations are marching with their feet. According to a recent study, market demand for DevOps skills is growing, and DevOps engineers are among the highest paid IT practitioners today. And it looks set to stay that way. Research in the U.K. shows that 30 percent of 300 organizations surveyed in the run up to the 2015 DevOps Summit had either started to implement a DevOps strategy or had already merged Dev and Ops, with another 13 percent planning to go down this route.
Two Related Children: DevOps and Continuous Delivery
So now we arrive at continuous delivery. If DevOps is about accelerating the delivery of new, high-quality services, surely continuous delivery is the same thing, isn’t it? In other words, ensuring a steady stream of new services? You might look at it as a manufacturing production line: DevOps is the machine that builds the service, while continuous delivery is the conveyer belt that rolls the services off the production line—one big unified service development cycle.
That’s not the case. Although the distinction between DevOps and continuous delivery can be a little grey and cause confusion, there is in reality clear water between the two. Continuous delivery has become an essential ingredient for teams doing iterative and incremental software delivery. It is an approach whereby teams ensure that every change to the system can be released, and that any version can be released at the push of a button. Think of it this way: Continuous delivery aims to make releases dull and reliable, so organizations can deliver frequently, at less risk, and get feedback faster from the end users until deployment becomes an integral part of the business process and competitiveness of the enterprise.
Continuous delivery and DevOps do share common traits, though. Both methodologies are aimed at agile and lean thinking: each delivers small and quick changes; each relies on tight business an IT collaboration; and each share the common goal of faster time to market for new services.
However, the goal of DevOps is merge dev and ops roles together—and the processes they manage—to achieve business goals. It’s all about a common, shared culture and enhanced collaboration. About clearly defined business processes.
Automation has an essential role to play in both DevOps and continuous delivery. Automating DevOps helps your organization manage and secure continuous delivery to the business and IT users. The result is a faster, low-risk migration to a new world of composite applications, faster business innovation and better support for rapidly changing business process needs.
If you ever wanted to learn about Rugged DevOps (some call it DevSecOps), sit down for a spell with Shannon Lietz, Ian Allison and Scott Kennedy from Intuit. We discussed a number of important topics including internal war games, culture hacking, gamification of Rugged DevOps and starting as a small team. There are 100 gold nuggets in this conversation for novices and experts alike.
Derek Weeks: I have some of the Intuit DevSecOps team here with me today. We’re going to talk to them a little bit about Rugged DevOps and how things work over at Intuit. Let’s start with some introductions.
Allison: I’m Ian Allison. I help run the Red Team at Intuit, which is, I guess you’d say, an interesting way of taking control of security at our company. We try to get ahead of the attackers by basically being the attackers. We’re essentially ethical hackers. We go after all of our own stuff to make sure we can find where the deficiencies lie in all of our software.
Lietz: I’m Shannon Lietz. I’ve been working at Intuit 3 1/2 years and helped to found the 24×7 DevSecOps capability at Intuit, leading the Red Team, our security operations capability, our cyber SOC, and what we also consider “blue teaming”: being able to hunt for defects.
The organization has really had to transform how we do software development because we’re a 30-year-old software company. We are now seeing the traditional way of putting together software really embracing DevOps. For us, it’s been exciting to really work in the industry with Rugged DevOps, trying to help build security into the DevOps movement.
Kennedy: I’m Scott Kennedy. I run the forensics and threat intelligence part of cyber work.
Weeks: Shannon (@devsecops), tell me a little bit about software supply chains and how that vision of software development has impacted the way you see things at Intuit.
Lietz: That’s really a great question. It was interesting when Josh Corman and I first talked; we had a lot in common. One of those things was the software supply chain. What I really love about the concept is being able to have processes driven a certain way so that you can reduce defects.
Having worked for Toyota in the past and understanding the supply chain mentality, you get a sense of how you could put something together better, incrementing on it, figuring out how to share that process, and then really figuring out what things are important. Having that notion of fewer, better suppliers was really a core concept.
I love the idea of transparency, building things a certain way, and really getting into continuous improvement. You need to look at things from an opportunities perspective—making sure you’re not just looking to make things perfect. You’re looking for those opportunities to improve over time.
https://www.youtube.com/watch?v=nRaURhaTH9o
Weeks: As we think about Rugged DevOps within your security team, how do you measure the success of what you’re doing? What kind of metrics are you looking at that matter to the business?
Lietz: We measure everything. For example, mean time to remediation (MTTR). Once somebody finds a defect, we analyze that defect from the time it got into the supply chain to when it actually gets resolved. We track everything from mean time to remediation to when the ticket was created, to being able to look at when the code actually got published, to when it actually got found, and then we work on those things over time. We really try to uplift.
____
Once somebody finds a defect, we analyze that defect from the time it got into the supply chain to when it actually gets resolved.
____
We leverage JIRA [Software] just like a software development team does. We register our defects and figure out how to get development teams to take responsibility for those ideas. It goes through their process of release and regression testing. As part of that, we look back to see where our opportunities are.
As an example, we started out where things may have taken weeks. We then reduced it down to days and ultimately got it down to hours. We’ve seen defect resolution where it’s now minutes. When it’s something we’ve discovered that was just a mistake by an engineer, we realize “mistakes do happen.” We found that our cycle times also help us to find fault stack vulnerabilities in real time because we get to do end-to-end testing more aggressively utilizing this method.
Weeks: How has consistency in your operations helped with Rugged DevOps and has it fragility within the organization?
Allison: One of the things we do is to utilize a golden image for all of the AMIs (Amazon Machine Image) we use, for all of our customers, and we require everybody to use these AMIs. We’ve also built some really interesting automation around scanning these AMIs. So one thing we realized quickly when we first started native U.S., when we try to do full vulnerability scans against another system, if it’s set up to autoscale, we all of a sudden have 50 systems. Right? We can’t … it’s really hard to do a full vulnerability scan right against the system, so we came up with a way to share back all of the AMIs with a special account. Then we bring those up and we scan them. Then we grade them.
Based upon the vulnerabilities that are found, you’ll get a letter grade, like A through F, based upon the system you have. While we always strive to have our base image be an A, people continue to run on older images. But they get graded, and those grades get pushed up, so everybody in their org structure gets to see what the grade is for their account. I think by being a little standardized, basically with these images, lets us know what’s in everything, and we have a grade for everyone. It helps everyone have a really good idea of where they stand when it comes to a security standpoint.
____
Based upon the vulnerabilities that are found, you’ll get a letter grade, like A through F … so everybody in their org structure gets to see what the grade is for their account.
____
Weeks: That’s not only a grading but a policy enforcement governance kind of role that grading plays. How rapid is the feedback loop in that grading system for the teams that you’re working with?
Lietz: It’s really quick, and we’ve discovered through some science that having component-based resources like AMIs provides us with an advantage when doing things like remediating vulnerabilities. Using AMI-based resources, we have seen that when there’s a defect in it, we can find and remediate all of the defective AMIs quickly. That improves everyone’s security across the company.
So if you’re just picking out really good components, keeping track of those components and adding security into them, then you’ll actually see a different effect across our pipeline. A single change can actually have a dramatic effect on reducing the problems within the pipeline.
Allison: It’s really interesting. This morning I got an email from somebody that said, “Why did our baseline AMI go from an A to a C today?”
We had just received notice of a new vulnerability. Our stuff caught it, we scanned it, and we pushed the grade out to our portal where all our customers go to look at the grades. Our customers were able to see that change quickly.
They could now say, “Wow, it changed from an A to a C in less than 12 hours.” I think the feedback is really important. The other important thing is that we have people going and looking. I wouldn’t be getting emails about why has this changed if people aren’t actually looking and wanting to make their grades better.
Weeks: You mentioned customers. Are these internal customers?
Allison: Internal.
Lietz: Yeah, for our development teams, we as a security team really have changed how we think about things. It used to be that the security team would go out and govern. Basically, you got the fear of the security team coming in, descending upon you.
We’ve really changed how that happens within our organization. We grade our resource components, and we grade the way in which our applications come together. That changes how developers want to operate because they really want to figure out how to get better grades in security. And it creates a learning dynamic that incentivizes somebody to improve continuously.
___
That changes how developers want to operate because they really want to figure out how to get better grades in security. And it creates a learning dynamic that incentivizes somebody to improve continuously.
___
Weeks: Does it create a competitiveness or gamification of who has better grades?
Lietz: Absolutely, which is why we did it in the first place. To your point there, gamification is something where when you start to grade components like that, you can actually start to leverage a leaderboard concept. We do have leaderboards as part of this. We have APIs where you can actually pull down your grades and include them in your automation. With these, you can make governance decisions.
If you sort of have that “game afoot,” right, your leaders can then ask for specific grades within their pipeline. That up-levels the system, and you just see a continuous improvement lifecycle come to bear. Ultimately, you see fewer defects, and ultimately, you get to the notion of Six Sigma in our way of thinking. DevOps is really about continuous improvement and embracing automation. Embracing that concept allows us to get to fewer defects faster.
___
DevOps is really about continuous improvement and embracing automation. Embracing that concept allows us to get to fewer defects faster.
___
Weeks: As you embraced continuous practices and DevOps practices, were there points when you realized certain old ways of doing things weren’t going to enable you to move forward?
Kennedy: In looking at the progression of what we’ve been doing, one of the decisions that was made in Intuit and one of the things that I saw was really unique was the way they decided we were going to migrate into AWS. Our idea was to have the chaos team be the first people out, and that’s the security team. So the security team was the one that was going out and finding out how to use each of the products that AWS has and creating the concept of whitelisting. Each product was rated as to whether or not it met security’s requirement.
Therefore, no team can go ahead and pull down this new cool tool that AWS released yesterday and use it in production because it’s not been “whitelisted.” That can go into their scoring. Their scoring is not only used by the development teams but also is useful when reporting to the board. When the board asks, “How are we doing as a company across the entire organization?” we can say that product A got a lower score than product B, and then they turn to the VP in charge of it and say, “Well, why?”
___
When the board asks, “How are we doing as a company across the entire organization?” we can say that product A got a lower score than product B, and then they turn to the VP in charge of it and say, “Well, why?”
___
We decided to not rush into the cloud but to take a careful, considered approach and migrate in a very intelligent and well-thought-out way. At the same time, we gave the chaos team the ability to make the mistakes and grow and learn, so they can immediately turn around and share the mistakes with everyone else. They could say, “Hey, these are the things that didn’t work for us. We came across a lot of problems, especially when you look at things like accounts and account roles.”
How do you control when you have thousands of accounts and you need to have some sort of administrative control?
You can either have a gigantic effort to force your namespace and your Active Directory to be the source of control. Or you can use the vendor-specific tools like IAM and have each account have their own separate islands, but with the concept of cross-account roles, you can then do remote administration from a centralized account. You have it locked down. You have the capability to have a restricted group and be able to remotely go in and do the necessary actions.
That also gives you an audit trail. That also gives you multifactor built in because the AWS products get those things added to them.
Lietz: I think when it comes down to it, I think culture-hacking your environment can have a profound effect, especially when you’re going through a DevOps transformation.
Weeks: What is culture hacking?
Lietz: That’s a great question. We use it when really trying to figure out how we as a security team can change and transform. A lot of the things that take place in a company are really based on traditional processes: What has worked before, and why would we change something that is working, right? If you’re really going to go into an innovative frame; if you’re really going to get into that next-generation innovation; if you are trying to figure out what’s going to work in that … it’s never going to be the thing that is working. It’s going to be the thing that you’re going to learn as you go to that next step.
Culture hacking is really about looking at the people who are operating right now and trying to figure out how you’re going to help them go from A to B, making that change. What is that the experience going to be like?
What we have done, to Scott’s point, is we’ve forced our security team to have empathy for the DevOps teams. We go through the process of developing something in the cloud, utilizing it as a method of taking their paranoia and trying to balance the notion of getting something done within a specific time frame. We try to really wrangle what it takes to do those things securely and safely but, ultimately, still be able to deliver for the business.
I think that culture hacking really comes into play when you’re trying to figure out how to move somebody from the rock they’re on to the rock you need them to be on and trying to figure out what those mechanisms are.
___
Culture hacking really comes into play when you’re figuring out how to move somebody from the rock they’re on to the rock you need them to be on.
___
Weeks: Part of your security practice is looking at open source and third-party components and your own binaries. Can you shed some light on how Intuit is using Sonatype solutions to better manage those vulnerabilities?
Lietz: Yeah, Sonatype Nexus is a fantastic platform. We love the Nexus repositories. We love how you guys put together a community. We learn a lot.
A lot of our DevOps practice is working together with it. We’ve put together our Nexus repositories to do code signing and figuring out how to really secure our pipelines a certain way. We are taking advantage of the fact that we can pick up components, track them and then scan them [for known vulnerabilities].
That’s allowed us to reduce the defect count that goes to production. Actually scanning and looking for vulnerabilities within our components and our open source libraries allows us to make better decisions about what we’re including in our software.
Weeks: When you govern what open source, third-party or proprietary components are being used by developers, is there any kind of feedback from the teams saying, “Hey, you’re restricting my behavior, not improving my innovation”?
Lietz: What we’ve found is that the notion of security approvals, exceptions and gates really doesn’t work. Quite often, you just create a culture where developers are going to go out and do it, and then you’re going to find out about it. When it comes to really partnering and being boundary-less about how you think about security in your business, it’s all about transparency. It’s all about benefits. It’s creating things like a security markdown file within your repository manager. It’s about taking responsibility and accountability for the things that you’re doing from a security perspective in your development process. It’s ultimately having an attacks.md file, keeping track of what’s out there, keeping track of your open source, understanding what components you’re leveraging, and why you made the decisions that you made to bring those things into your project.
___
It’s about taking responsibility and accountability for the things that you’re doing from a security perspective in your development process.
___
At a top level, all of those things work. But really having tools that can help the decisions that were made by some of the other open source programmers that you’re getting contributions from is really necessary. All of the things that they might be deciding are also part of your decision tree, and ultimately, you’re rolling all of that and bundling it together. The attack surface is not just the decisions that your team is making, but the ones that you share across the code base that you’ve got.
Weeks: Your practices are very mature. You’ve clearly developed them over a long time, and some people watching this might think, “Well, Intuit’s a huge organization,” and it may be daunting to them if they haven’t started down the path of Rugged DevOps. Can you be a small team and have success in these kind of practices?
Lietz: We’re not exactly a huge organization, but we are relatively large in size now. When we got started, I believe I was one of maybe three people that started this, only a couple years ago. We have hired into our group pretty extensively to help grow it, and some of the things that we’ve done have really allowed us to operate differently, to bring in people and have them immediately be successful. Our practices allow someone “day one” to be able to work with the environment, to be able to develop code, to be able to contribute code that week.
We do things like weekly demos, where we actually do video demos. A person has to come in, program something, secure something, operate it and create a demo, all within their first week. So having the right bar for those folks is really important, but more importantly, our Red Team leader here (points to Ian), he came in and just is amazing, has created a Red Team pretty much out of thin air. So is having somebody from forensics, who’s just done an incredible job to help us, to make it so that we have a life cycle where we can snapshot something and be able to learn from it when it’s actually offline.
___
A person has to come in, program something, secure something, operate it and create a demo, all within their first week.
___
Those are the types of practices where you start to extend yourself past the normal baseline practices of processes today and really think past that about how you’re going to support innovation. You get into it very quickly. You get a learning culture. You get people who know that making mistakes—and figuring out how to learn from them—is okay. That’s a really important part of that actual culture that you’re putting in place.
Allison: Yeah, I was going to say, it’s all about iteration, right? We started small, and we just continually iterate on what we’re doing to try to get better and be better at what we all do.
When I first started this journey, I was a security guy—a pen tester. It was always the developer’s fault. Developers always made the mistakes. I always had to clean up after them. But after six months of developing Ruby APIs and Ruby and working my butt off in code, the empathy was there.
I really understand what the developers are going through and why they make the choices they do. But I think by allowing us to help them, by creating tooling that allows them to self-serve, to understand it without making them … helps them make themselves more secure without them having to become a security professional. I think that’s kind of our ultimate goal.
Shannon: Being friendly hackers, right? Basically going out and attacking them so their applications don’t get attacked by external attackers is really part of that frame.
Kennedy: The Red Team shift at the company has been profound because you see how people react. When the Red Team started, it was not as well shared, and a lot of people suddenly were very upset that they were attacked by the Red Team. But when it was pointed out, “Well, what would you rather have happen? Would you rather have somebody in China do this to you, that didn’t work with you, didn’t sit next to you and help you fix the product, or would you like to have a friend who, by the way, their job is to attack?”
When we went through several drills and actually practiced the muscle of defending the company against an attack, people were upset. “Oh, I had to do all this work.”
My response to them: “Well, you did the right work.”
“You did the right thing. You saw something bad. You did it. You did good. You practiced the muscle. Now when it happens again and it’s not the Red Team, I know that you’ll know what to do. You know that the process works, and we can actually defend the company faster and more securely.”
___
You know that the process works, and we can actually defend the company faster and more securely.
___
Weeks: Yeah. That’s an incredible story. Thank you for sharing it.
My final question: If you could pick a superpower in dev, security or ops that you would have in the organization, what would it be?
Allison: To me, they’re all alike; they’re the same, right? That’s what we do, DevSecOps, right? We try not to actually separate them out because I think once you start to separate them out, you start to lose perspective.
Kennedy: Yep.
Allison: There’s a good thing about having them all be one thing, so I’d choose them all.
Kennedy: It’s been pretty consistent. DevSecOps is the answer. What was the question? (Laughter)
Lietz: I think the reason we went out and created DevSecOps was just simply to change how we thought about doing development and technology—and to really to get ahead of it, to realize that attackers weren’t setting up appointments or meetings to help you figure out how they were going to attack your software, and so then why were we? Why were we operating at a fragile level?
I think that the superpower that I would like to have is DevSecOps because I know that we are going through the process of creating a less-fragile capability in security that will allow us to get ahead of attackers, make it much harder for them to go after the software that gets built, and we’re seeing those improvements. That’s actually a great thing.
Weeks: It sounds really exciting, and it’s very cool, so thank you all very much. I really appreciate it.
All: Thank you.
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 7 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.”
Leading Infrastructure Software Vendor Further Strengthens Solution Set to Help Customers Build and Deploy Business Applications and Services Faster, with Greater Reliability and Less Risk
ROCKVILLE, Md., March 22, 2016 /PRNewswire/ — Micro Focus announced today its intent to acquire Serena Software, Inc., a leading provider of Application Lifecycle Management (ALM) software, in a transaction valued at $540 million. The acquisition is expected to close in early May 2016, subject to receipt of competition clearances in the US and Germany.
“Today’s announcement marks another significant milestone for Micro Focus, bringing together two highly complementary solution sets that enable customers to build better applications, adapt to changing business conditions more rapidly and maximize the value of existing investments to drive further innovation within their business,” said Stephen Murdoch, CEO, Micro Focus. “With Serena, we are further positioned to deliver richer solutions for the complex business demands customers are solving today – with greater reliability, predictability and less risk of failure.”
Enterprises globally have increasing demands to build and deploy high-quality business applications to support employees, customers, partners and other third-parties. They require solutions that help them increase the quality of their applications and speed the delivery of change. The combination of Micro Focus and Serena allows companies to better:
Design and build business applications and services with greater accuracy, reliability and predictability;
Continuously deploy existing core business applications on a wider variety of platforms to meet changing business needs; and
Improve the speed and efficiency of new business services through automated release and deployment solutions.
Serena has extensive expertise in software application development; software configuration and change management; and business process management. Additionally, Serena is a pioneer in processes and solutions that bridge application development and operations to create true DevOps, an increasingly critical area of focus for enterprise customers looking to develop applications and services faster, with greater accuracy and agility that fully meet business demands.
“This is an exciting announcement that promises to offer substantial value to Serena customers and partners,” said Greg Hughes, president and CEO of Serena. “Our complementary strengths in software development and IT Operations will only serve to provide a stronger foundation for the next-generation of applications and services they require to meet ongoing business demands.”
About Serena
Serena is the largest independent Application Lifecycle Management vendor with more than 2,500 enterprise customers. Serena helps the highly regulated large enterprise move fast without breaking things – increasing velocity of the software development lifecycle while enhancing security, compliance, and performance. More information is available at www.serena.com.
About Micro Focus
Micro Focus (LSE: MCRO.L) is a global enterprise software company helping customers innovate faster with lower risk. Our software helps customers build, operate and secure IT systems that bring together existing business logic and applications with emerging technologies to meet increasingly complex business demands. For more information, visit: www.microfocus.com.
I believe that 2016 will be the year that DevOps takes mainstream foothold in the enterprise. And I base this assertion on seven sweeping changes that — from my vantage point — are taking hold and dramatically changing the digital world.
The Job of IT Will Change From Infrastructure to Innovation. In the past, IT has been about providing compute infrastructure and applications to run the internal workings of a company. But this has been radically shifting as digital transformation penetrates nearly every company of significance across the globe. As a result, IT is increasingly about driving innovation and customer value through software. We see this every day from our work with large enterprises; indeed, almost half of the global 500 use Chef in some manner. And, in our interactions with enterprise customers, over 75 percent cite innovation, velocity and agility as top priorities for IT — and the company. The common ingredients behind this are almost always automation, cloud and DevOps. In fact, while these three elements are, in many ways, distinct, they form a magic IT trinity in service of innovation-led organizations. If you need further proof that IT is on its way to becoming the pointy end of the innovation-creation spear inside large-cap companies and organizations, just look at the auto industry, where CES may actually be more important than the Detroit Auto Show, where GM is investing in Lyft, and where Google is doing state-of-the-art R&D on a self-driving car.
Continuous Delivery (CD) Will Become Ubiquitous. CD is the practice of rapid software development and iteration through fast, small-batch releases. In its purest form, developers can drive small, incremental software releases quickly, sometimes as often as every few minutes for some very well known Web sites. Not long ago, CD was exclusively the domain of big Web innovators such as Facebook, Amazon, Google and Yahoo! Not long ago, making even several releases a day sounded insane. And not long ago, a CIO told me that it was ridiculous to contemplate bringing CD into the enterprise. All this has changed, and today it makes absolutely no business sense to shy away from CD because it’s one of the keys for unleashing an organization’s software development innovation engine. The point is that the whole stack — infrastructure, compliance, security, microservices and applications — is being expressed as code now, and it’s the same as you deliver with work-flow. In the end, whether your company needs to release frequently all the time, or not, every aspect of IT is charged with a business requirement to do something quickly some of the time. CD is a very important piece of the puzzle.
The Public Cloud Will Triumph in the Enterprise. You may think the cloud is old news, but it’s not. In 2016, the enterprise is going to move beyond public cloud experimentation and project-based work and start migrating entire data centers to the public cloud. We’re also going to see more hybrid cloud initiatives (whatever the composition) because dual adoption helps companies avoid vendor lock-in. As for private cloud projects, there are definitely some good teams and technologies out there. But, having said this, I believe that the public cloud will win out. Many of the lingering public cloud issues, like security and governance, have begun to evaporate. And the ease of use, affordability and effectiveness of the public cloud will simply triumph in the enterprise over the next 12 months at the expense of the private cloud.
We Will Enter a New Era of System Administration. The world of systems administration has changed forever. In the IT world that I grew up in, a human being logged onto a system to manage, update or fix it manually. Since then, compute scale has grown exponentially for most organizations, thanks, in part, to both server virtualization as well as the cloud. Most of our enterprise customers have, excluding desktops, tens of thousands of compute nodes. Some have over 100,000. A few have over 1,000,000. Administering systems manually by having humans act on systems is no longer viable or tenable. In the new era, humans act on code and code acts on machines. In fact, code is the system. In other words, humans act on compute resources through code. And this reality creates a whole new universe for the world of system administration. The bottom line? The job and role of the system administrator will change significantly. Watch this trend play out in 2016.
Peace Will Break Out Between Developers and Security / Compliance Officers. This has been a long-running battle inside the enterprise, and there are several theories behind the conflict. One is miscommunication — the security team doesn’t think the dev team gets it, and the dev team doesn’t think the security team gets it. Another hypothesis is that developers just want to be left alone to write code for the business, but the business is increasingly worried about security — not just IT security. And, lastly, there’s this explanation for the hostility — developers want to go fast, and security teams want to slow everything down to a safe speed. Whatever the reasons, I believe that developers and security / compliance officers will find much more common ground in 2016 because we’re learning that compliance and velocity aren’t necessarily in conflict with each other. In fact, high-velocity IT organizations can deal with security threats more quickly by assessing vulnerability, creating a fix, testing it and then deploying it rapidly before the damage is done. We’re also seeing the early beginnings of what I believe will be a very important trend in our industry: compliance defined as code. Today, compliance is all too often defined in binders or text documents; what’s a developer going to do with this? But we’re seeing a new idea emerge: define compliance — either to your own security standards or external, regulatory standards in code. If you can define compliance as code, you can then use that code to create a test that can simply be moved into the software release process and managed like any other automated test. Forward-leaning compliance officers will shift their gaze and embrace their developers because it’s through their software developers that they’ll be able to take their craft to a new level. Keep an eye on this in 2016.
Executives Will Move Into the DevOps Tent. The DevOps tent will expand to include the executive suite in 2016, and executives are excited to join the practitioner-born DevOps movement. “DevOps” makes one think of only “development” and “operations,” but it’s really a movement focused on how we build and operate high-velocity organizations. Frankly, DevOps is meant for the entire enterprise. The results are both clear and definitive. Mature DevOps organizations see increases in both innovation and quality that flow through to business results, including profit and shareholder value — and, quite possibly, security and safety as well. Executives have seen what code can do, and they’re fervently embracing the far-reaching organizational changes that have accompanied this technology revolution. The good news for DevOps practitioners is that they’re going to find strong support in the executive suite and many will see good things happen to their careers in 2016
Container Technology Will Be Improved and Grow Even More. Containers — which bundle entire run-time environments into packages that make it much easier to move applications from a developer’s laptop to the test, production and end-user stages — are becoming invaluable, especially in homogeneous green-fields, because they abstract so many problems away. But most enterprises aren’t homogeneous green-fields, so the challenge is how to deal with a variety of legacy technologies without re-writing all the applications that run. I believe that this problem will be addressed in 2016, and container usage will expand by leaps and bounds as a result.
There will be other big changes in IT during 2016, but, when combined, I believe these seven represent a truly significant tipping point that will catapult enterprises toward the future with a velocity and vigor that can only enhance and enrich growth.
Abouth the Author/Barry Crist, CEO, Chef
Barry Crist is CEO of IT automation company Chef. Barry has more than 20 years of experience in driving enterprise customer success and adoption with both open source and DevOps software solutions. Prior to joining Chef, he was CEO of Likewise, a company with a strong open source to enterprise go-to-market model that had wide industry reach including OEM agreements with VMware, Dell, HP, Riverbed, and EMC. Likewise was acquired by EMC Isilon in September 2012. Prior to Likewise, Crist served as Vice President of the Application Management group at Mercury, now a division of HP, where he grew North American sales from less than $1 million to more than $75 million. Crist led enterprise sales organizations at Network Associates (now McAfee) and was in various sales, technical, and international roles at Apple.
Industry’s Most Advanced Workload Automation Solution Adds Capabilities that Cut Workflow Development Time in Half
MORRISTOWN, NJ – (January 26, 2016) – Advanced Systems Concepts, Inc. (ASCI) today announced the availability of ActiveBatch Version 10, a major release of the company’s leading Workload Automation and Job Scheduling Software focused on improving IT performance despite the operational and business complexities impacting today’s IT organization. ActiveBatch Version 10 contains multiple new features that increase efficiency and reduce cost, while also meeting the intensifying demands for improved agility and bimodal deployment.
“Most IT organizations are facing unprecedented challenges due to the rate of production growth, changing business requirements, stagnating budgets, and a shortage of skilled professionals,” said Jim Manias, Vice President of Sales and Marketing at Advanced Systems Concepts. “Our release of ActiveBatch Version 10 redefines IT automation with new automation capabilities that help IT professionals easily handle the core functions they are supporting, which in turn enables them to adapt to new requirements faster and more reliably.”
Built with an understanding of common business functions, ActiveBatch Version 10 introduces new capabilities that can cut workflow development times by as much as 50%. The benefit of these innovations allow DevOps teams to refocus on critical IT business and operational processes, thereby reducing delays, decreasing errors, and improving the speed at which tasks are released into production.
Closing the IT Resource Gap
Among its many improvements, Version 10’s innovative Integrated Jobs Library includes hundreds of production-ready, templated Job Steps that are self-documenting. The library allows developers to assemble jobs and workflows faster with pre-built logic that eliminate time spent on researching, writing, and testing code. A new Check-Out | Check-In with Collaboration capability lets multiple developers work on the same object(s) simultaneously; upon Check-In, authors can address conflicting changes with ActiveBatch’s built-in Conflict Resolution tool. Pairing this with v10’s new Simulation Mode, developers
and operations can simulate workflow logic and execution for testing without incurring delays imposed by actually running the job payload.
Five new views in ActiveBatch Version 10 speed time-to-insight by quickly visualizing activities.
The newly designed Map View, for example, offers a real-time graphical display and development environment with all workflows and object relationships, while Machine Load View displays a visual heat map to identify heavily used, lightly used and available systems. Gantt, Forecast, and Workflow Optimizer Views also help shorten development time and improve workflow quality. Finally, an upgraded Dashboard provides dynamic visualization of KPIs as well as real-time and historical progress of business and IT workflows.
Reducing Automation Complexity
Most organizations struggle with a combination of three to eight separate automation tools. ActiveBatch Version 10 helps reduce that number to one, due to its cross-platform architecture and robust Jobs Library. Furthermore, its innovative predictive analytics and intelligent automation technology lets it anticipate upcoming computing needs, then assemble and later disassemble the exact mix of real, virtual and cloud resources required for the task, on the fly.
To further simplify developer workloads, ActiveBatch Version 10 now offers REST support in addition to other API Interfaces. This makes it easier for users to create lightweight, dynamic and end-to-end workflows across mobile apps, social networking sites, mashup tools and automated business processes.
Availability
ActiveBatch Version 10 is now available for licensing as well as by automatic upgrade for companies participating in ASCI’s ActiveBatch Version Upgrade program. For more information, log on to www.advsyscon.com.
About Advanced Systems Concepts, Inc.:
Founded in 1981, Advanced Systems Concepts, Inc. has developed cutting-edge products across the breadth of customer markets for over 30 years. Advanced Systems Concepts offers many software products and options for users of Windows, UNIX, Linux, HP OpenVMS and NSK systems as well as IBM z/OS, AIX, i5OS and SCO UNIX. With a worldwide base of customers in over 46 countries, Advanced Systems Concepts helps companies respond to increasingly complex business needs with a leading edge IT Automation solution that improves business performance and IT operations.
As wider adoption of DevOps methodologies continues to foster demand for new tooling to help streamline evolving workflows, at least one vendor is attempting to address the growing need for related monitoring capabilities.
Librato, a San Francisco-based provider of Amazon AWS applications performance monitoring (APM) services, claims that it is finding favor among the rapidly expanding DevOps community driven by its ability to inject critical visibility into the engineering lifecycle.
Acquired by Austin, Texas-based SolarWinds in January for a lofty $40 million and renamed Librato SolarWinds Cloud, the company is touting its recent adoption by well-known providers such as Slack for monitoring of DevOps-centric applications performance and health metrics.
“At its core, DevOps is destroying conventional wisdom around ritualized processes and the need to perform them, mostly in the domain of scale,” said Dave Josephsen, Developer Evangelist at Librato. “By attempting to include monitoring as a key element of the development lifecycle, this has created a whole new range of challenges, and opportunities.”
By providing a centralized Web interface and open API to help create visibility into critical applications engineering requirements, Librato maintains that it is creating the tooling necessary to empower integrated development and deployment processes, such as continuous change control.
“There are a lot of disparate tools for monitoring individual engineering tasks, but there hasn’t been any practical way to bubble up that data for efficient monitoring,” Josephsen said. “Within the context of DevOps, change control is a ritual that we’ve abandoned as we’ve embraced test driven development and automated away the human element, so there’s a distinct need for monitoring of feedback and metrics.”
For example, cloud-based productivity messaging specialists Slack are using the Librato “StatsD” lightweight daemon process to stream business and app-health metrics regarding PHP applications into the monitoring platform. Slack also leverages Librato to chart data regarding connect, query and fetch latencies for its server clusters, and to monitor internal metrics about overall system health.
“Having those graphs side-by-side lets us clearly see and compare the effects of network latency on one of our new services, and that’s very cool,” Richard Crowley, director of operations at Slack, wrote in a recent testimonial posted to the Librato Solarwinds blog.
Industry experts agree that broader adoption of DevOps strategies will continue to drive demand for relevant monitoring tools, with solutions such as Librato seeking to deliver “modern stack architecture for looking at the modern stack.”
“I think that APM is always interesting because it’s always new,” said James Governor, industry analyst with RedMonk. “The pace with which we’re building new architectures to deliver services to end users is increasing all the time, and with every new wave of technology, we tend to get new and associated models of APM tooling.”
Librato is taking advantage of the need for a system that brings together the elements necessary for cloud native monitoring, and in an agentless manner different from other competing tools such as New Relic, the analyst noted.
However, whether or not the platform is able to break down traditional engineering siloes to enable more efficient DevOps management, as Librato officials claim, remains to be seen, he said.
“Each wave of technology has promised to do this, to remove the inherent finger pointing, and each has always made the same claim to break down organizational firewalls,” Governor said. “DevOps hasn’t boiled the ocean in this manner yet, but there are some unique opportunities; unlike previous waves, where automation was intended to replace humans, this is now about augmenting people, and we are seeing that teams are choosing new tools from which developers can truly derive value.”
Anders Wallgren is chief technology officer at 
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.
Barry Crist is CEO of IT automation company 