staging-devopsy.kinsta.cloud

Tag: devops

  • What to Expect: DevOps Enterprise Summit London

    What to Expect: DevOps Enterprise Summit London

    After the success of the first two years of the U.S. DevOps Enterprise Summit, people have been asking us to host a similar conference in other locations, specifically in Europe. This summer, we’re hosting our first DevOps Enterprise Summit in London!

    This conference is for technology leaders who are driving transformations in large, complex organizations. These are successful enterprises that have been around for decades (and, in some cases, for centuries!), with thousands (or tens of thousands) of employees, and billions of dollars in annual revenue. These are organizations with massive and complex daily operations, and all the resulting processes and bureaucracies that come with it. In many ways, these complex operations and bureaucracies are the very things that create the worst-case conditions for DevOps transformations!

    We’ve heard amazing case studies from Barclays Capital, GE Capital, Disney, Marks & Spencer, Bank of America, Capital One, Telstra and many more, where leaders have created amazing DevOps outcomes that are more typically associated with organizations such as Google, Amazon, Facebook and so forth.

    For this inaugural year of DevOps Enterprise Summit London, we’ll be bringing some of our “greatest hits” from the United States, but the rest of the programming will feature DevOps transformations in organizations residing in the U.K. and continental Europe. (And we’re still holding the DevOps Enterprise Summit in San Francisco, so feel free to join us there as well!)

    New World and Old World DevOps

    The speakers at DevOps Enterprise are pioneering the practices of how large, complex organizations transform and deliver software. It’s my belief that these principles are universal, regardless of what continent or country the organization resides in.

    One of the biggest surprises from co-authoring “The Phoenix Project” has been how many people have told me that the book describes their organization, seemingly independent of company size, industry vertical, for-profit or nonprofit or the continent they’re writing from. This validates that the problems that result when Dev and Ops can’t get along are universal.

    The good news is that the DevOps solutions we deploy to fix the problems also have lots of commonalities!

    It’s always inspiring to hear how these leaders have overcome the challenges they faced. I see our speakers as genuine heroes who have put themselves in personal jeopardy, often risking their careers and livelihoods, to achieve something they believe is genuinely important. They  possessed the clarity and conviction that the capabilities they were creating for their organizations were needed to win in the marketplace—or maybe even just to survive.

    I think one of the interesting statistics is that more than 25 percent of DevOps Enterprise speakers have been promoted in the last two years—some more than once! It’s a fantastic testament that the organization values the contributions they have made, and their risk-taking and heroism paid off.

    The DevOps Movement Matures

    Every year at the DevOps Enterprise Summit, I have asked all speakers to share what problems they didn’t know how to fix or the problems that they were looking for help on. What I’ve found is that the answers have evolved. From year to year, we are seeing trends on the obstacles facing the DevOps Enterprise community.

    In 2014, attendees’ stated problems were about needing better strategies and tactics for creating automated tests for legacy applications, as well as the culture and leadership aspects during transformation, information security and compliance practices and identifying metrics to best improve performance with DevOps initiatives.

    In 2015, the problems were focused on people and organizational design. Examples included the need for effective strategies and methods for leading change in large organizations. Speakers and attendees also wanted to know what the organization charts looked like for organizations successfully adopting DevOps. What were the respective roles and responsibilities, and how had they changed from more traditional IT organizations?

    Now, as we approach DevOps Enterprise Summit 2016, we are seeking to address the next phase of challenges facing the community: What are the modern architectural and technical practices that every technology leader needs to know about? What are the technology practices for managing infrastructure, environments and automated testing? And what are the transition patterns to get there?

    From the HR perspective, how do you go about reskilling the workforce and employing these new design patterns? Lastly, we are seeing compliance and security discussed more often, including: What are concrete ways for DevOps to bridge the information security and compliance gap to show auditors and regulators that effective controls exist to prevent, detect and correct problems?

    The programming committee always invites a handful of speakers to return from year to year. While to some this might appear redundant, it’s actually quite fascinating to witness their journeys unfold. It’s like an episode of, “Where Are They Now,” and the speakers never cease to amaze!

    Solving Problems Together

    As a vendor-neutral conference, DevOps Enterprise Summit curates stories that are from the enterprise point-of-view. Most of the presentations follow a very specific “experience report” structure—speakers describe their organization and their industry, the business problem they faced, where they started their transformation, what they did and the business outcomes. It’s a simple format but very powerful because it helps other people facing the same problems learn how other people solved the problem, and it often reveals practices that can be used in other contexts.

    I’m so excited to share some of the initial speakers we have slated for DOES London:

    • Chris Jackson, Director of Cloud Product Engineering at Pearson
    • Robin Hughes, Head of Development Services at LV=
    • Justin Dean, SVP, Platform and Technical Operations at Ticketmaster
    • Jeremy Waite, Chief Digital Strategist at Salesforce
    • Gareth Rushgrove, Senior Software Engineer at Puppet Labs, Inc; ex-UK GDS
    • Antony Collard, Deputy Director at HMRC
    • Finbarr Joy, Group CTO at Lebara
    • Amy Philipps, Head of Test at Songkick
    • Jason Cox, Director, Systems Engineering at The Walt Disney Company
    • Rosalind Radcliffe, Distinguished Engineer, Chief Architect for DevOps for Enterprise System at IBM

    What also amazes me about DevOps Enterprise is the concentration of talent in the technology leaders who attend—they’re all people who are passionate about technology and helping teams win, and willing to do disruptive things to get there.

    Ross Clanton from Target (a large U.S. retailer) told me he valued being surrounded by people who were not only trying to solve the same problems that he was facing, but were the best in the game—and there’s a huge intrinsic value of being surrounded by those kind of people. I can definitely relate; I learn something in every one of my interactions at the conference, and I have no doubt that the practices this group is pioneering will be commonplace within a generation.

    Like in any aspect of life, peers are important. As Buzz Aldrin said, “Show me your friends, and I will show you your future.”

    DOES is a unique opportunity to meet some very talented and inspirational new friends who can help shape your career path. We hope you’ll join us in London.

    DevOps Enterprise Summit London

    June 30 & July 1, 2016

    Hilton London Metropole

    225 Edgware Road, London, UK

    @DOESsummitEU

    Early Bird £600 +VAT (ends May 2)

     

    DevOps Enterprise Summit San Francisco

    November 7–9, 2016

    Hilton San Francisco Union Square

    333 O’Farrell Street, San Francisco, CA

    @DOESsummit

    Early Bird $1,450 (ends May 16)
    Check out videos from previous DevOps Enterprise Summits on YouTube.

  • IT Revolution Announces First Speakers For DevOps Enterprise Summit London 2016

    Technology leaders from Disney, IBM, Ticketmaster, Pearson and Salesforce among the first to join the premier DevOps Enterprise event speaker lineup

    PORTLAND, Oregon, April 20, 2016 /PRNewswire/ — IT Revolution (http://itrevolution.com), the industry leader for advancing DevOps, today announced its first round of speakers for DevOps Enterprise Summit London (DOES16), the premier industry conference for the leaders of large, complex organizations implementing DevOps in the UK and Continental Europe (http://events.itrevolution.com/eu/). Tickets for the conference, which is scheduled for June 30-July 1at the Hilton London Metropole, can be found at: (http://bit.ly/doesldnreg). Early Bird registration ends May 2 and is highly encouraged, as the popular DevOps Enterprise Summit San Francisco event has sold out the past two years, while doubling in attendance.

    Logo – http://photos.prnewswire.com/prnh/20160322/346968LOGO

    The first speakers to be included in the DOES16 London program include:

    • Antony Collard, Deputy Director at HMRC
    • Jason Cox, Director, Systems Engineering at The Walt Disney Company
    • Justin Dean, SVP, Platform and Technical Operations at Ticketmaster
    • Robin Hughes, Head of Development Services at LV=
    • Chris Jackson, Director of Cloud Product Engineering at Pearson
    • Finbarr Joy, Group CTO at Lebara
    • Amy Philipps, Head of Test at Songkick
    • Rosalind Radcliffe, Distinguished Engineer, Chief Architect for DevOps for Enterprise System at IBM
    • Gareth Rushgrove, Senior Software Engineer at Puppet Labs, Inc; ex-UK GDS
    • Jeremy Waite, Chief Digital Strategist at Salesforce

    “The speakers assembled at the DevOps Enterprise Summit are technology leaders who are pioneering the practices of how large, complex organizations transform and deliver software,” said Gene Kim, founder of IT Revolution and co-author of “The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win.” “They have all overcome immense challenges to help their organizations win in the marketplace, and we can all learn from their experiences.”

    IT Revolution and Premier Sponsor HPE Software are excited to present the inaugural DOES16 London event this summer. As a vendor-neutral conference, DevOps Enterprise Summit curates stories from the enterprise point-of-view. Most of the presentations follow a very specific “experience report” structure—each speaker describes their organization and their industry, the business problem they faced, where they started their transformation, what they did, and the business outcomes. It’s a simple yet powerful format that reveals solutions to shared problems and new practices that can be used in other business contexts.

    For more information about DOES16 London, please visit: (http://events.itrevolution.com/eu/).

    Share This: DevOps Enterprise Summit Announces Invited Speakers http://bit.ly/doesldnreg @DOESsummitEU #DOES16#DevOps

    About IT Revolution
    IT Revolution assembles technology leaders and practitioners through publishing, events, and research. Our goal is to elevate the state of technology work, quantify the economic and human costs associated with suboptimal IT performance, and to improve the lives of one million IT professionals by 2017.

    Contact:
    Jeremy Douglas
    Catapult PR-IR
    303-581-7760, ext. 16
    jdouglas@catapultpr-ir.com

  • Cohesion Critical in a Successful DevOps Team

    Cohesion Critical in a Successful DevOps Team

    In the push to adopt DevOps among enterprise IT organizations, cohesion has been one of the biggest challenges in collaborating effectively. Historically, departments within a business existed in disparate locations, or silos. Marketing, IT and operations all had their own teams and their own communication channels, which made it difficult for members of separate teams to work successfully with one another despite the fact that they were working toward a common goal.

    However, with the continuing adoption of DevOps, IT admins are finding that projects are easier and more well-executed when all the parts of the development cycle—creation, coding, testing and deployment—are working in tandem. Therefore, it’s becoming ever more critical that agile product teams are on the same page when it comes to their DevOps projects.

    Cohesion Matters

    Why is it so important to have a development team that coheres as one entity and communicates effectively among all its members? Let’s take a look:

    Quicker feedback cycles

    When team members are working as one unit instead of disparate entities, testing and development cycles don’t have to be long, drawn-out affairs. One of the biggest benefits of DevOps itself is the ability to shorten time to market and deploy code more quickly, with fewer errors—so enabling teams to communicate can only enhance that benefit.

    According to staging-devopsy.kinsta.cloud contributor John Balena, facilitated collaboration allows teams to achieve continuous testing goals and streamline processes. This can lead to a continuous delivery cycle, which is the goal of DevOps in the first place.

    “DevOps can best be realized when IT operates in a social, collaborative environment that ensures all groups are working with a visual model in their context with the necessary information from downstream and upstream teams, as well as in collaborating with relevant experts at the moment when clarifications are needed or issues arise,” Balena wrote.

    Shared responsibility

    With a collaborative DevOps culture, no one person or group of people is responsible for the entire project. It is a team effort that doesn’t rest on anyone’s shoulders unnecessarily. This makes the project more of a shared endeavor, which everyone is invested in and cares about. With silos, when something goes wrong, members of different teams may try to lay blame on one another, which lowers morale and may defeat the entire purpose of DevOps. But when teams are communicating effectively, they can share blame—but they also share success.

    This mindset enhances the teamwork aspect of software development and can help get rid of the culture of fear, according to staging-devopsy.kinsta.cloud contributor Claire Agutter. When teams work together within a blameless culture, they can more quickly see and learn from their mistakes.

    Common goal

    Throughout all of the steps of the software development life cycle, another important advantage of teams working together is that they share a common vision of how the company should progress. Business needs and customer satisfaction are both critical factors in the DevOps cycle, and team members should all be on the same page when it comes to these goals.

    In all, it’s critical for IT managers to support a culture of collaboration and communication if their DevOps endeavors are going to succeed. You need the right tools for the job, but you also need to have the right attitude.

    “Culture is like quality,” DZone contributor Jim Bird wrote. “You don’t build culture, or quality by talking about it. You build it by doing things, by acting, by making things happen and making things change, and reinforcing these actions patiently and continually over time.”

    A collaborative DevOps culture can improve project success.

    About the Author/Sanjay Zalavadia

    SanjayHeadShot (1)As the VP of Client Service for Zephyr, Sanjay brings more than 15 years of leadership experience in IT and Technical Support Services. Throughout his career, Sanjay has successfully established and grown premier IT and Support Services teams across multiple geographies for both large and small companies. Most recently, he was Associate Vice President at Patni Computers (NYSE: PTI) responsible for the Telecoms IT Managed Services Practice where he established IT Operations teams supporting Virgin Mobile, ESPN Mobile, Disney Mobile and Carphone Warehouse. Prior to this Sanjay was responsible for Global Technical Support at Bay Networks, a leading routing and switching vendor, which was acquired by Nortel. Sanjay has also held management positions in Support Service organizations at start-up Silicon Valley Networks, a vendor of Test Management software, and SynOptics.

    Connect with Sanjay:

    Facebook: https://www.facebook.com/getzephyr?_rdr=p

    LinkedIn: https://www.linkedin.com/in/sanjayzalavadia

    Twitter: https://twitter.com/yourzephyr

    Google+: https://plus.google.com/+Getzephyr/about

  • Threat Stack Secures $15.3 Million in Series B Funding to Drive More Efficiency for Cloud Security Teams

     

    Scale Venture Partners Leads Round; Market Demand and Rapid Customer Growth Key to Series B Funding Round

    BOSTON – April 19, 2016 – Threat Stack, a leader in cloud security and compliance management, today announced it secured $15.3 million in Series B funding, led by Scale Venture Partners (Scale), with participation from all existing investors, including Accomplice and .406 Ventures. Threat Stack today also announced that Ariel Tseitlin, a partner at Scale, will join the company’s board of directors. The latest round of funding brings total investment in Threat Stack to more than $26 million.

    Threat Stack Series B funding comes on the heels of the company’s record year of customer growth in 2015 and the launch of the Threat Stack Cloud Security Platform™ (CSP) in early 2016. The new capital will be used to double headcount in the next year, bolstering sales, marketing and engineering to further enhance product capabilities and user experience. Threat Stack will also use funding to support expansion into a new Boston headquarters in the coming months.

    “We are thrilled to bring Threat Stack into our strong portfolio of cloud businesses. Threat Stack’s rapid quarter-over-quarter growth and industry-leading approach to cloud security made this a compelling investment for us. There is a big gap in the security needs of cloud-native application and the capabilities of security tools in the market, and Threat Stack fills that gap with a unique product that’s easy to use and scale,” said Tseitlin. “I look forward to Threat Stack’s further expansion in the market as enterprises of all sizes continue to build rapidly and securely in the cloud.”

    “Threat Stack’s Cloud Security Platform has enabled us to grow faster by replacing point tools and using security resources dedicated to our cloud environment more efficiently,” said Jarrod Sexton, senior security engineer for Interactive Intelligence. “By enabling us to more quickly and cost-effectively identify and resolve security issues, Threat Stack has proven to be an invaluable partner.”

    The cloud-native, fully-integrated Threat Stack Cloud Security Platform supports security insight across all environments, cloud security providers and containers, eliminating the need for fragmented solutions and reducing the complexity of security concerns facing IT leaders and CISOs. With integrated security data from all aspects of the cloud environment, customers achieve a faster time to resolution and an overall lower total cost of ownership. Threat Stack’s CSP is used by companies in the healthcare, fintech and SaaS sectors, among others.

    “Since I joined Threat Stack a year ago, we’ve experienced incredible business momentum. Our growth is not only across our customer base but also as a team working passionately to build a security and compliance solution that meets the growing needs of modern cloud infrastructure,” said Brian M. Ahern, chairman and CEO, Threat Stack. “This latest round of funding validates our approach to the market, and will fuel further enhancement of Threat Stack’s Cloud Security Platform to improve operational efficiency, while resolving security and compliance challenges for customers across all industries.”

    Today’s fastest growing companies are relying on modern cloud infrastructure to fuel speed to market, innovation and scale. Resources are at a premium while security risk is greater than ever. According to a recent Enterprise Strategy Group (ESG) survey of cyber security and IT professionals,“34 percent said their organization finds it challenging to monitor workloads across clouds. This could be related to workloads within hybrid clouds, or it could indicate monitoring challenges with workloads across heterogeneous private or public cloud infrastructure.”

    For more information on Threat Stack, please visit https://threatstack.com.

    About Threat Stack

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

     

  • Mesosphere Democratizes the Container-Based Datacenter with DC/OS Open Source Project; Backed by Accenture, Cisco, Equinix, Hewlett Packard Enterprise, Microsoft and Many Others

    More than 60 leading technology companies collaborate to deliver first 100% open source datacenter-scale operating system for running containers and distributed apps in production.

    SAN FRANCISCO — (Marketwired, April 19, 2016) — A broad alliance of leading companies today joined forces with Mesosphere to unveil the beta release of DC/OS, the first open and comprehensive platform for building, running and scaling modern enterprise applications. Derived from Mesosphere’s revolutionary Datacenter Operating System, the 100 percent open source DC/OS offers powerful capabilities for container operations at scale and single-click, app-store-like installation of 20+ complex distributed systems (called DC/OS “services”), including HDFS, Apache Spark, Apache Kafka, Apache Cassandra and more. DC/OS lets every company deploy the automated infrastructure powering applications at some of the world’s largest technology companies.

    “The world needed a better architecture for all modern apps, not just containers,” said Florian Leibert, CEO & Co-Founder of Mesosphere. “DC/OS represents a major industry transformation, delivering today’s enterprises an open source datacenter-scale operating system that pools compute resources into what looks like one big computer, running containers, microservices, big data systems and other components of modern applications with ease. The open source community has come together around DC/OS to deliver an amazing ecosystem of products and datacenter services.”

    More than 60 partners— including Accenture, Cisco, Hewlett-Packard Enterprise and Microsoft — have had early access to DC/OS leading up to its launch and have pledged to help grow and shape the project through technology integrations and open source software contributions. DC/OS brings the industry’s most proven approach for container operations, and its Universe “app store” brings single-click deployment and simplified operations for the latest generation of services designed to run in distributed environments.

    View a list of supporting quotes from DC/OS launch partners.

    “DC/OS is the inevitable next step for Apache Mesos,” said Benjamin Hindman, Co-Creator of Mesos and Mesosphere Chief Architect and Co-Founder. “Organizations that run Mesos quickly discover they need all of the components we’ve built into DC/OS. DC/OS will democratize large-scale distributed systems and the applications they power, building on the work of the Apache Mesos kernel. By open sourcing DC/OS we’re enabling organizations of all sizes to harness the same computing infrastructure as the Twitters and Apples of the world.”

    Organizations and individuals are invited to join the DC/OS community at dcos.io. The DC/OS name and trademarks are attached to the open source community, and Mesosphere is committed to working with the community to determine the right long-term home for the project.

    Read more about DC/OS on the Mesosphere blog.

    Partners Driving Deployments

    One of the earliest DC/OS collaborators—Microsoft—announced today the general availability of Azure Container Service, including support for DC/OS. First announced in September, Azure Container Service is a completely open-source-based, production-ready container service. Azure Container Service is the easiest way to get started with DC/OS and is uniquely designed to give customers flexibility and easy deployment while taking advantage of proven technology and vibrant community support. DC/OS is also available for cloud deployment via the Azure Marketplace.

    “DC/OS takes an open source approach ideally suited for applications that will define the next decade of business,” said Mark Russinovich, Microsoft Azure Chief Technology Officer. “Microsoft selected DC/OS for the Azure Container Service so our customers can easily build, deploy and manage modern applications on our enterprise-ready Azure cloud platform, as well as in private and hybrid cloud environments.”

    Read Microsoft’s blog post about why it supports DC/OS.

    Other DC/OS partners from across the IT spectrum are already delivering strong integrations between DC/OS and their products and services. These include industry leaders such as Accenture, Equinix and HPE, as well as many innovative enterprise IT startups.

    “DC/OS is specifically designed for organizations seeking highly scalable, agile application development with continuous improvement and robust, reliable deployment,” said Edy Liongosari, managing director, Accenture Labs. “Accenture is mature in its ability to implement container-based solutions and DC/OS is a powerful underlying technology that will provide us with the implementation agility needed for custom development projects. We look forward to continuing our participation in the DC/OS open source project and supporting the evolution of the ecosystem.”

    “Hybrid and multi-cloud deployments are the new reality,” said Ihab Tarazi, CTO of Equinix. “We see DC/OS as a critical part of the true hybrid cloud. Equinix is home to 1,100 network providers across 145 datacenters in 21 countries and we will be using DC/OS to form the foundation for an open source ecosystem that innovates around multi-cloud and IoT. We believe that DC/OS, combined with other initiatives like Open Compute, will drive rapid innovation in the manageability, performance, security, and reliability of modern applications in hybrid environments.”

    “Businesses want to accelerate the development and delivery of secure and scalable cloud native services,” said Manoj Nair, Vice President, CDI Converged Product Management, Hewlett Packard Enterprise. “HPE is excited to partner with Mesosphere to simplify this process for customers by bringing together container orchestration, big data, and composable technologies for modern data centers.”

    Read HPE’s blog post about why it supports DC/OS.

    A Universe of Services

    DC/OS Universe, an app-store-like experience for exploring and installing services, is a built-in component of DC/OS. The Universe provides an open catalog of services built to run on DC/OS. making it easy for developers and operators to install and run complex distributed systems like Spark, Cassandra, Kafka and NGINX—the building blocks of modern applications—with ease. The DC/OS Universe simplifies packaging and delivery of its services for use in datacenter and cloud environments and provides a low-friction distribution path for ISVs that is analogous to app stores on desktop and mobile devices. With a single command or click within the DC/OS CLI or GUI, users can install services on the DC/OS. Any software developer can build services that run on DC/OS and publish them to Universe—thus inheriting the scalability and high availability of DC/OS.

    “We’re excited to join the DC/OS community in this launch, as developers and operators can now easily access and deploy NGINX as part of their DC/OS environment through Universe,” said Gus Robertson, CEO of NGINX, Inc. “NGINX is one of the most widely deployed application tools in containerized environments, enabling organizations to confidently build and deliver their next-generation applications at scale. We see a huge opportunity for the DC/OS Universe to bring plug-and-play services and apps such as NGINX and NGINX Plus to the distributed enterprise.”

    The Open Source Community Behind DC/OS

    DC/OS is an evolution of the Apache Mesos technology originally developed at the University of California, Berkeley, in 2009. Mesos was inspired by the types of systems that manage datacenter resources for companies such as Microsoft and Google, and simplifies the work of managing datacenters and the process deploying modern datacenter-scale applications. It works essentially by aggregating datacenter resources—tens of thousands of servers in its largest deployments—into a single logical computer on which many workloads (Docker containers, Hadoop, Spark and Kafka, to name a few) can run simultaneously.

    “Using new architectural principles such as containers at carrier-scale, Verizon is taking new applications from idea to production with greater speed than traditional deployments,” said Larry Rau, Director of Architecture & Infrastructure, Verizon Labs.  “Combining resources from the greater open source community and DC/OS technology, Verizon will be able to better standardize operations and maximize efficiencies across multiple datacenters. The launch of the DC/OS open source community is another step toward accelerating innovation in the datacenter.”

    “At Cisco we are interested in using DC/OS to deliver Mantl (mantl.io), our batteries included end to end solution for your microservices infrastructure,” said Ken Owens, Chief Technical Officer, Cloud Infrastructure Services at Cisco Systems. “The design point for Mantl is to focus a community around an end to end solution, not around an individual component; designed to solve business and team challenges, one glue, improved by the community, tested everywhere. We are very excited to be working with Mesosphere on DC/OS as this project that will greatly improve the stability and reliability of the microservices platform deployment and runtime.”

    The DC/OS platform, originally developed by Mesosphere, includes Apache Mesos as core technology (or kernel) but adds significant functionality above and around Mesos. Marathon is the native container-orchestration engine for DC/OS, and already runs large-scale Docker environments and other long-running applications at many large companies. DC/OS packages for Spark, Kafka, Cassandra, HDFS, Jenkins and other distributed systems increase operational simplicity and flexibility beyond what’s possible running them on non-Mesos platforms. Other DC/OS components—there are more than 30 overall, ranging from the build kit to the user interface—make it simpler than ever to install, run and manage modern applications on a wide range of platforms.

    “Yelp is a heavy user of DC/OS technologies for managing a large Docker environment that spans our private datacenters and the public cloud,” said Michael Stoppelman, Senior Vice President of Engineering at Yelp. “We even built our in house PaaS—PaaSTA—on top of DC/OS’s Marathon. Adopting these technologies has given Yelp’s developers and operators remarkable agility, and we believe DC/OS can bring the same results to all companies as they embrace technologies such as containers and cloud computing.”

    DC/OS is currently v1.7 and in beta. Based on the community’s confidence in the code, Mesosphere expects it to transition to general availability (GA) by Q3 of this year.

    DC/OS Founding Partners

    10th Magnitude (www.10thmagnitude.com), Accenture (www.accenture.com), Alluxio (www.alluxio.com), ArangoDB (www.arangodb.com), Autodesk (www.autodesk.com), Avi Networks (www.avinetworks.com), Big Industries (www.bigindustries.be), Big Switch (www.bigswitch.com), Buoyant (www.buoyant.io), Cake Solutions (www.cakesolutions.net), Canonical (www.canonical.com), Capgemini (www.capgemini.com), Cervoo (www.cervoo.com), Chef (www.chef.io), Cisco (www.cisco.com), Citrix (www.citrix.com), Cockroach Labs (www.cockroachlabs.com), Confluent (www.confluent.io), Container Solutions (www.container-solutions.com), Data Art (www.dataart.com), Data Dog (www.datadog.com), Data Fellas (www.data-fellas.guru), Datera (www.datera.io), Dynatrace (www.dynatrace.com), Element Analytics (www.elementanalytics.com), Elodina (www.elodina.net), EMC (www.emc.com), Equinix (www.equinix.com), HPE (www.hpe.com), Iguaz.io (www.iguaz.io), InfoSiftr (www.infosiftr.com), Ishi Systems (www.ishisystems.com), Joyent (www.joyent.com), Kovarus (www.kovarus.com), Lightbend (www.lightbend.com), Linker Networks (www.linkernetworks.com), Magnetic.io (www.magnetic.io), MapR (www.mapr.com), MemSQL (www.memsql.com), Mesosphere (www.mesosphere.com), Metaswitch (www.metaswitch.com), Microsoft (www.microsoft.com), Miracl (www.miracl.com), NetApp (www.netapp.com), NGINX (www.nginx.com), Offscale (www.offscale.io), OpenCredo (www.opencredo.com), Packet (www.packet.net), Puppet (www.puppet.com), QCT (www.qct.io), Quobyte (www.quobyte.com), Redapt (www.redapt.com), Samsung SAMIIO (www.samsungsami.io), SolidFire (www.solidfire.com), Sumologic (www.sumologic.com), Sysdig (www.sysdig.com), Vapor.io (www.vapor.io), Verizon (www.verizon.com), Weaveworks (www.weave.works), Xentaurs (www.xentaurs.com), Yelp (www.yelp.com)

    Additional Materials

    About Mesosphere

    Mesosphere (Twitter: @Mesosphere) is leading the enterprise transformation toward distributed computing and modern applications with its Datacenter Operating System, and is the principal founding member of the DC/OS open source project. DC/OS is a production-proven datacenter-scale platform for container operations and simple installation of complex distributed systems—including HDFS, Apache Spark, Apache Kafka, Apache Cassandra and more. Mesosphere was founded in 2013 by the architects of hyperscale infrastructures at Airbnb and Twitter, along with the co-creator of Apache Mesos.  Backed by A Capital, Andreessen Horowitz, Data Collective, Fuel Capital, Hewlett Packard Enterprise, Khosla Ventures, Kleiner Perkins Caufield & Byers, Triangle Peak Partners and Microsoft, Mesosphere is headquartered in San Francisco with additional offices in New York and Hamburg, Germany.

    In March, Mesosphere announced that it closed $73.5 million in a Series C funding round led by Hewlett Packard Enterprise, with Microsoft joining as a new strategic investor. The round brought Mesosphere’s total funding to date to nearly $126 million and supports the company’s accelerating growth as DC/OS becomes the de facto standard for enterprises operating containers and distributed systems in production.

  • Rugged DevOps: Making Invisible Things Visible

    Rugged DevOps: Making Invisible Things Visible

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

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

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

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

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

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

    ___

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

    ___

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

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

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

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

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

    ___

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

    ___

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

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

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

    ___

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

    ___

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

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

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

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

     

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

    Wickett: Good, please, say that.

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

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

    ___

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

    ___

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

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

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

    ___

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

    ___

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

    Weeks: How did the rugged DevOps movement originate?

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

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

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

    ___

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

    ___

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

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

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

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

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

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

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

    Zane Lackey, too. I also work with Zane.

    Weeks: That’s a great list. Thanks!

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

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

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

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

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

    ___

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

    ___

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

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

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

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

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

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

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

    Wickett: Cool.

    Mueller: Super.

    Wickett: Thanks, Derek.

    Weeks: Thank you very much.

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

    Untitled2

    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.”

  • The New Age of “Operations” in a DevOps Enterprise

    The New Age of “Operations” in a DevOps Enterprise

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

    I find more and more, that clients and colleagues want to know:

    • What happens to the operations/run tower people if tools like UrbanCode Deploy automate the promotion of applications and releases to run-time environments?
    • What happens to our system administrators and “build out” teams, if tools like Chef, Puppet, Vagrant and pattern-based provisioning systems like IBM Cloud Orchestrator and UrbanCode Deploy with Patterns can perform solution stack build outs with minimal custom network, hardware, software, and middleware configurations?
    • If developers can provision and deploy their own apps, what do the sys admins do?
    • Will Operations Staff be replaced by tool automation?

     The truth is, now, more than ever, a savvy, astute, and innovative operations staff is essential to successfully execute effective DevOps within the enterprise.

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

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

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

    Once opportunities have been identified for standardized assets, operations teams must mobilize to enable the enterprise for automation:

    • Encapsulate enterprise policies in standardized automation assets (which can be reused across the enterprise).
    • Centrally manage and maintain automation assets within the enterprise (to maintain standard and policy compliance).
    • Evangelize, encourage, and incentivize the use of automation assets in delivery of applications.
    • Provide a continuous delivery pipeline tool set (preferable, as a service) providing an infrastructure to enable the automation assets for development and test teams

    Automation assets can occur at every layer in the solution stack, providing an opportunity for the new Operations team to inject enterprise influence and compliance at every level. This approach ensures standards and compliance, but also relieves application development and test teams from worrying about whether their application violates any corporate policies.

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

     img

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

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

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

    img2

    About the author

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

    Connect with Andrea LinkedIn | Twitter

  • Test Better, Test Faster, Test Smarter

    Test Better, Test Faster, Test Smarter

    How do you balance the need to “go fast” with the need to test everything and deliver high-quality software?

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

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

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

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

    How Much Testing is Enough?

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

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

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

    What Kind of Testing Should You Invest in?

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

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

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

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

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

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

    How Can You Make Testing Faster?

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

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

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

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

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

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

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

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

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

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

    Consider the following best practices for improving your testing processes:

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

    As you map, design and optimize your tests, remember that your testing policies don’t need to be set in stone, and that you can—and should—adjust and tweak as you go.

    Happy testing!

    About the Author/Anders Wallgren

    Anders HeadshotAnders 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.

  • State of DevOps Survey – The Ultimate Feedback Loop

    State of DevOps Survey – The Ultimate Feedback Loop

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    Take the 2016 State of DevOps Survey… today!

  • Threat Stack Announces Webhook API Integration Capabilities

    Customized Workflows Enable Collaboration to Streamline Security 

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

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

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

    Threat Stack customers using webhooks can now more easily and efficiently:

    • Integrate the Threat Stack Cloud Security Platform with custom internal applications
    • Integrate with other monitoring platforms to more easily identify issues
    •   Build new escalation and/or remediation workflows based on Threat Stack alerts

    Threat Stack users can custom configure their own webhook integrations to subscribe to specific, prioritized events. When an event is triggered, the webhooks integration sends a summary of alert information in JavaScript Object Notation (JSON) format, and every alert results in a separate call to the webhooks API. Users are then able to interpret their alerts and take actions based on their unique needs.

    Examples of custom workflows for cloud security teams include:

    • Generating a custom AWS Simple Notification Service (SNS) notification based on severity 1 Threat Stack alerts
    • Creating a Jira ticket from a severity 2 Threat Stack alert
    • Archive severity 3 Threat Stack alerts into a S3 bucket for long-term storage

    The cloud native, fully-integrated Threat Stack webhook API integration enables collaboration to drive faster mean time to resolution of critical security events. Threat Stack customers across healthcare, fintech, SaaS fields, and other industries benefit from greater efficiency, streamlined services, and the automated integration of security events from across the infrastructure.

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

    About Threat Stack

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