Tag: enterprise

VictorOps Enterprise Edition expanded with Incident Automation Engine
VictorOps helps the most innovative companies bypass traditional Network Operations Centers in order to proactively ingest, transform, route, and solve problems using end-to-end automation.

BOULDER, Colo. – June 22, 2016 – VictorOps, the real-time incident management company for DevOps teams, announced the Incident Automation Engine, a set of cutting-edge features for on-call teams to automate their way to faster MTTR through use of intelligent alerts, sophisticated routing, and smarter system outputs.

Unlike other incident management tools that focus on triaging alerts and notifications, the VictorOps Incident Automation Engine offers a truly innovative combination making system inputs intelligent and relevant outputs fully actionable. The Engine automates human behavior in order to quiet the noise of unnecessary alerts, deliver real-time remediation solutions, and provide visibility and documentation into all communications and actions that took place during an incident. Additionally, through the use of outbound webhooks the entire VictorOps solution can now be configured to send information to other tools, take automatic actions, and sync with other alert sources and reporting systems already in place. The combination providing unsurpassed control and insight throughout the incident lifecycle.

“With the Incident Automation Engine our customers are are now better empowered to resolve and even prevent future incidents, thereby protecting revenue loss, driving customer satisfaction and maintaining brand reputation,” said Todd Vernon, VictorOps CEO and co-founder. “More and more the best way to speed organizational innovation is through enabling developers to move quickly. When it comes to a company’s uptime this same concept applies. Today valuable time is lost with archaic alerting systems and manual processes. The Engine now becomes a foundation to automate out these inefficiencies, gain clearer access to actionable information and to continuously evaluate and improve the inputs driving on-call processes.”

Key features of the Incident Automation Engine include:
- Alert Transformations– Quiet unactionable alerts and automatically route specific alerts to the correct team members
- Alert Annotations– Automatically append alerts with runbooks, monitoring graphs and other relevant information, giving the alert recipient immediate remediation steps
- Outbound Webhooks– Extend VictorOps platform data into other systems and integrate VictorOps incidents into other service dashboards
- API– Leverage the VictorOps API to extend VictorOps to existing legacy tools and reporting systems
- Post-Mortem Report Generator – The ability to automatically pull a snapshot of all activities (alerts, conversations and remediation actions) associated with an outage. This information translates easily into SLA reporting and the facilitation of team retrospectives.
Organizations of all sizes are increasingly looking to adopt incident management solutions in order to reduce the impacts of IT downtime. According to Gartner, the potential cost of downtime for organizations can approach $540K an hour. If reduced, mean time to resolution (MTTR) can prevent a modest 300 minutes of downtime in a single year, and businesses could save upwards of $2.5M.

“Visibility at velocity is very important to us so engineers know what needs to be addressed from problems identified in production. [The] VictorOps Incident Automation Engine is allowing us to inform more team members in a timely fashion. We are lowering our MTTR and increasing the reach of our incident alerting audience without waking up everyone for the wrong reasons,” said Mike Perttula, DevOps Specialist at Signiant.

For more information about the Incident Automation Engine, visit [URL].

About VictorOps

VictorOps is the real-time incident management platform focusing on incident lifecycle management and collaboration for IT and DevOps teams. The solution combines the power of people and data to solve IT problems in real-time. The VictorOps platform seamlessly orchestrates team situational awareness, incident creation, escalation, notification, and remediation with team members regardless of physical location or time of day. Privately held, VictorOps is backed by Costanoa Venture Capital and Foundry Group. For more information, visit www.victorops.com and follow the company on Twitter @VictorOps.
June 22, 2016
REP SPOTLIGHT: TaUB Solutions
DevOps Institute: Tell us about your organization.

TaUB Solutions: TaUB Solutions is a consulting-cum-training organization based in Bangalore India. Our vision is to take the customers beyond the existing state of maturity to envisioned business outcomes.

We serve a lot of customers in southeast Asian region by delivering consulting assignments on ITSM, IT governance, project and program management and business relationship management. This also includes delivering business simulations on the respective domains and make our customers gain benefit from learning by doing.

DOI: What other topics do you teach or consult?

TaUB Solutions: ITSM, IT governance, agile, DevOps, business relationship management, cybersecurity, project and program management and ISO standards (20000,27001, 22301)

DOI: What type of interest in DevOps are you seeing in your region?

TaUB Solutions: At the moment, we have successfully delivered around 11 batches of DevOps Foundation and Certified Agile Service Manager courses. We appeal to our customers because of the practitioner focus that we bring to the table and take them through case studies to understand the end-to-end value chain. Our current run rate indicates a strong pipeline of interest in southeast Asian countries who want to apply the DevOps principles and philosophy in their workplace. We also see great traction from Indian corporates to plunge in to the DevOps journey to serve their respective customers better.

DOI: How do you think DevOps contributes to the business’ value stream?

TaUB Solutions: One of the things that appeal most to me is the ability to articulate the end-to-end value chain. Business today does not care about which framework or methodology you adopt for the customers. All that matters is to deliver an end-to-end value chain and get a common understanding among different functions and leverage the best across the enterprise. I see tremendous value of leveraging agile, ITSM and lean principles with culture and tool chain to demonstrate key business value.

DOI: What topic area in DevOps excites you the most?

TaUB Solutions: There are three things:
- Culture change
- Power of automation using tool chain
- Business KPIs and Common Metrics across the organization
DOI: Why should enterprises and individuals consider formal DevOps Training?

TaUB Solutions: Today, DevOps is still at its infant stage and has not yet been codified. So people have their own perspectives, thoughts and misconceptions. So in order to be certain with the path they traverse, it is increasingly important to step in the right direction. This is where a formal DevOps training from DOI can help people to understand fundamentals and DevOps trends from practitioners.
June 22, 2016
DevOps Matchmaking: APM + CI = A Perfect Marriage

As anyone who has ever been set up on blind dates by friends can attest, finding the right match in today’s world is a tricky feat.

There’s a lot of evidence suggesting that the frantic pace of life makes such matchmaking more difficult than ever. That said, when the right set of complimentary traits exist and there’s a willingness to find common ground, things can work out.

Spike Jonzian-notions of artificial intelligence aside, certain technological partnerships are increasingly being perceived as “a perfect marriage” within the context of DevOps automation.

Register today for the upcoming webcast: “Using APM to Turbocharge Continuous Integration”

These technological matrimonies closely support the underlying tenets of DevOps methodology—collaboration, experimentation and increased velocity. In fact, it’s easy to wonder why no one ever conjoined them before. But we were using traditional waterfall development and operations and so couldn’t conceive of such a thing. On the other hand, emerging availability of tooling supporting new integrated workflows represents a significant catalyst.

Finding the Perfect Fit

One such DevOps confederation getting a lot of attention is the matchmaking of continuous integration (CI) and application performance management (APM) technologies. Tying together these once-disparate systems makes a lot of sense, despite the fact that few tools would seemingly appeal to more (traditionally) polarized constituencies.

Continuous integration has been a staple of the development community for many years. It emerged as teams evolved the practice of long build times into more frequent check-ins to deliver code and look for potential errors more quickly. Today, with the rise of CI tools such as the Cloudbees Jenkins platform, some development teams are touting tens of thousands of builds per day.

On the other end of the spectrum, squarely on the turf of IT operations, APM has been evolving rapidly over the past few years as organizations have sought to improve use experience and applications reliability via dedicated monitoring. Enabling this ability to identify and address emerging issues has resulted in APM becoming the fastest-growing segment in the IT ops management market, according to Gartner.

DevOps matchmaking factors in when you bring these tools together to create an automated workflow that spans their respective use cases. A cross-functional team can leverage APM-level monitoring and KPIs within the domain of CI and testing to identify potential performance obstacles introduced in new code. Doing so then rather than waiting to respond later in the applications life cycle benefits everyone.

Reaping the Benefits

For example, say an e-commerce applications developer has implemented a new inventory search functionality—something considered a key differentiator by business management. The developer knows this feature could rely heavily on some back-end database system and wants to ensure it’s tested properly, even as the code is being introduced.

Integrating APM and CI allows the entire team to monitor the process and test various conditions related to the update, tracking multiple builds and looking out for related performance issues. Such integration also allows for centralized tracking of other key attributes such as build number, status and build date, to further ease management.

Most importantly, by tying these two critical aspects of the applications delivery life cycle together, the collaboration and feedback loops required to truly embrace DevOps methodology become ever more valuable as these core Dev and Ops functions become intrinsically linked.

If this type of DevOps advancement gets your heart pumping, you’re not alone. Later this month, we’ll host a webcast here on devopsy.kinsta.cloud featuring experts from CA Technologies and Cloudbees. They’ll be discussing the benefits of matchmaking with APM + CI integration. They’ll also detail real-world benefits organizations leveraging integration of our respective technologies (CA APM and Cloudbees Jenkins) enjoy.

We obviously feel that this is a DevOps tooling marriage that will mature, change and stand the test of time. We’d love to garner your questions and feedback on the topic.

Which is all good, because thankfully there’s no such thing as Tinder for DevOps … yet.

June 21, 2016
Tales of DevOps Discovery Part 2: Definitions Matter
Definitions Matter: Step Two in a DevOps Transformation

The first post in this series on DevOps Discovery discussed the importance of asking fundamental questions of stakeholders to facilitate alignment on priorities and establish a mission statement when beginning a DevOps transformation. Part 2, below, reviews definitions of common DevOps-related terms and provides examples of how failure to agree on such terms can hinder your transformation.

The industry is full of terms such as continuous integration, agile, continuous delivery, DevOps, etc. The practices described by these terms often are defined differently by various industry “experts,” resulting in stakeholders in the software delivery process having different understandings of what constitutes these practices. Some will state they are already following the practices; others will state they do not. Some will believe the objectives unachievable, while others will be bullish on the prospects; differing interpretations blocking agreement on the organization’s current and target states. If stakeholders cannot agree on the current state (or the start point) and the target state (or the destination), it is impossible to “map a route” for the journey to DevOps.

For example, let’s look at how some define continuous delivery:

Continuous Delivery – Definition 1:

A software engineering approach in which teams produce software in short cycles, ensuring that the software can be reliably released at any time. It aims at building, testing and releasing software faster and more frequently.

The approach helps reduce the cost, time and risk of delivering changes by allowing for more incremental updates to applications in production. A straightforward and repeatable deployment process is important for continuous delivery.

Source: Wikipedia

Continuous Delivery – Definition 2:

Continuous Delivery is a software development discipline where you build software in such a way that the software can be released to production at any time.

[Continuous Delivery Blog Post by Martin Fowler]

You may read the above and initially think there is no difference in the definitions but, note that the first definition addresses deployment of software with the statement: “A straightforward and repeatable deployment process is important for continuous delivery,” whereas the second definition addresses deployment of software with the statement: “Build software in such a way that the software can be released to production at any time.”

This distinction may seem trivial, but it is the often the source of confusion between the practices of continuous delivery and the practice that is commonly called continuous deployment. In contrast to continuous delivery, which states that every software build “could be released,” continuous deployment is loosely defined as “the practice of releasing every good build to users.”

When establishing your target state for the DevOps transformation a seemly slight confusion such as this can result in pushback from stakeholders concerned that continuous deployment is unachievable or too disruptive. These sentiments include:
- Business: “We cannot gather, spec and track our requirements at that rate.”
- Operations: “There is no way we can support daily delivery into production, ensure security, uptimes and perform our day-to-day work. It takes us an entire weekend and multiple attempts to deploy today.”
- Customers: “Our compliance team needs three months to review and approve every new version of our accounting system.”
The confusion and potential pushback exemplify the need for establishing baseline definitions and alignment at the start of a DevOps transformation, and doing so in the specific context of your organization. The importance of points such as how far it deploys varies with the organization—some organizations can support continuous deployment to production multiple times a week or even multiple times a day, such as Netflix does. Other organizations, such as providers of critical financial systems, may never pursue this cadence of deployment. Be sure to apply these industry practices pragmatically as fit for your organization, not dogmatically based on generic industry definitions.

Let’s look at a couple of definitions of DevOps:

DevOps – Definition 1:

“DevOps (development and operations) is an enterprise software development phrase used to mean a type of agile relationship between Development and IT Operations. The goal of DevOps is to change and improve the relationship by advocating better communication and collaboration between the two business units.”

[Webopedia]

DevOps Definition 2:

“DevOps (a clipped compound of “development” and “operations”) is a culture, movement or practice that emphasizes the collaboration and communication of both software developers and other information-technology (IT) professionals while automating the process of software delivery and infrastructure changes. It aims at establishing a culture and environment where building, testing, and releasing software, can happen rapidly, frequently, and more reliably.”

[Wikipedia]

Like the example with continuous delivery, these two definitions also are very close. Yet on detailed observation, it is clear the first definition describes DevOps as being focused on relationships (i.e., culture and collaboration). The second definition extends this to include the “automating the process of software delivery and infrastructure changes,” giving consideration to tools and technical practices such as continuous delivery.

Does this matter? Yes. Often if the executive sponsors and key stakeholders do not account for the need to establish tools and technical practices and only focus on relationships, there is a high chance for unrealistic expectations for timeline, budgets and results. Conversely, if the need for changes in culture and process are not considered and the DevOps transformation focuses only on tools and technical practices, the efforts are also unlikely to yield the expected results. A DevOps transformation must account for the trinity of “People, Process and Tools.”

When considering DevOps, it objectives and the objective of its component practices it is useful to establish a clear idea of the relationships between theses practices. It is often useful to visualize them as below:

The DevOps Transformation Triangle

DevOps is the “What,” the target state as defined by a set of guiding principles. Agile development, continuous integration and continuous delivery are the “How,” a collection of process, practices and tools that together build the foundation for a sustainable DevOps implementation.

In the next section, we will review some of the initial discovery questions asked when beginning on a DevOps transformation, provide real-world examples of answers from various stakeholders in real organizations, and analyze those answer to better understand the journey to DevOps.
May 27, 2016
Echidna Takes DevOps to E-Commerce Site Creation

The Echidna e-commerce firm installs and evolves e-commerce platforms, providing ongoing development so its clients can leverage e-commerce experiences to the satisfaction of their customers. “We apply carefully selected user experience technology, marketing and analytics abilities to our clients’ strategic goals to do this,” taking what it calls an “anti-Big Bang” approach to continuous deployment, says Mike Pierce, CTO of Echidna.

“Traditional e-commerce deployments were often Big Bang deployments that people developed on the basis that they had to pressure the business leaders into feeling like they had only one chance to pack as much scope as possible into a large software development project. That approach voids any practical innovation,” says Pierce. With that mindset, it can take years to finish e-commerce sites, and e-commerce companies can go out of business by the time they actually finish such a site, since it would be far out of date by then.

Echidna sees continuous deployment as one piece in a much larger agility play designed to ensure that businesses compete in digital economies, now and in the future. Continuous deployment is the ultimate goal of DevOps, an approach that enables the business to innovate fast enough to maintain the business’ sharp marketplace edge through acute, turn-on-a-dime competitive dexterity. “In order to do this, continuous deployment helps companies learn to develop high-quality software and deploy it on a rapid, reliable and repeatable schedule,” says Pierce.

Continuous Deployment Timelines and Challenges

Depending on the client, its needs and the features in the pipeline, Echidna deploys software to each e-commerce platform from monthly to daily, and at intervals in between those extremes. Echidna seeks to increase the degree of automation of each deployment over time. The challenge is that with so many different clients and platforms, Echidna must achieve its automation victories for each customer individually, solving similar and unique issues. “We are finding our greatest success using PaaS (platform-as-a-service) e-commerce platforms like Four51 because it eliminates a lot of the administrative overhead that is typical with deployments to on-premise platforms,” says Pierce.

The development model Echidna follows to deploy e-commerce sites affects each software component, even though components deploy at different times. “Payment system modifications require significantly different testing—more testing—and we must deploy them much less often than other components. Marketing components don’t need as much regression testing as other software modules and so we can deploy them much more quickly,” he says.

The most difficult software to move into continuous deployment in an e-commerce platform are the components that integrate deeply into enterprise systems. That is why Echidna advises business customers to use DevOps methodologies to deploy their enterprise production software at accelerated rates. When they do this, Echidna potentially can speed its deployment of the e-commerce platform components that are enmeshed with those production systems.

The Four51 Path, Through Jitterbit

Echidna connects Four51’s OrderCloud to the Jitterbit iPaaS integration server platform, a point-and-click integration tool. “This enables us to streamline further integrations and data exchanges with many of the disparate systems in an ecosystem,” says Pierce. Echidna sees increasing continuous deployment orchestration opportunities as more and more third-party application vendors become compatible with these kinds of integration tools.

Four51 enables an ecosystem of connected digital services and applications where e-commerce uses numerous disparate systems that exchange data and facilitate work streams in the enterprise in question, Pierce says. “As these systems eliminate disparities and we align them on the central integration and deployment standards that we use, there will be increasing opportunities to introduce clients to lean development practices like continuous delivery and continuous deployment.”

Conclusion

Continuous deployment is miles apart from what information technology is used to, especially where manual change management and change control are concerned. But once Echidna exposes its customers to continuous deployment, their managers, C-levels and boards soon begin to witness the accelerated software innovation continuous deployment provides and how this makes information technology—and the business—more nimble, both technologically and competitively.

May 25, 2016

Electric Cloud Announces Four Events To Advance DevOps Release Automation In The Enterprise

SAN JOSE, Calif., March 29, 2016 /PRNewswire/ — Electric Cloud (http://electric-cloud.com), the leader in DevOps Release Automation, today announced four upcoming industry events taking place in April and early May. These events focus on advancing DevOps and Continuous Delivery in the enterprise by discussing tips and learnings for implementing modern IT practices across a wide range of industries and organizations.

Event #1:	Live Video Podcasts: Continuous Discussions (#c9d9) Episode 38: CI Acceleration
	Continuous Discussions is a live video podcast for discussing Agile, DevOps and Continuous Delivery. Each episode focuses on a different topic relating to modern software delivery, and features different speakers from the DevOps community.

	Join us on Tuesday, April 5, to discuss tips for accelerating your CI efforts.

	•	Tuesday, April 5, 2016 at 10 a.m. PT
		https://plus.google.com/events/cp4f4ch4f7iijfo5nskm1bgr2n4

Event #2:	Avantika Mathur to speak about strategies for managing Microservices at scale at MERGE 2016
	At MERGE 2016, the Perforce Conference, over 400 developers, executives and thought leaders will come together in San Francisco to discuss the future of DevOps. During three days of breakout sessions, speakers and lively discussions, attendees will learn about the current state of the industry and discuss where DevOps is headed.

	Join Electric Cloud’s Avantika Mathur as she discusses strategies and best practices for managing Microservices at scale. Using a real use case example and a live demonstration of Perforce Helix, Docker and Selenium, Avantika will share patterns and tips for enabling a robust, scalable and extensible pipeline to support today’s modern app delivery with microservices.

	•	Thursday, April 14, 2016 at 3:40 p.m. PT
	•	Ballroom III – Level 4
		Parc 55 – A Hilton Hotel
		San Francisco, Calif.

Event #3:	Live Video Podcast: Continuous Discussions (#c9d9) Episode 39: CD Automation
	On Tuesday, April 19, join DevOps experts to discuss tips for automating your CD pipelines.

	•	Tuesday, April 19, 2016 at 10 a.m. PT
		https://plus.google.com/events/cuj348ss8l75d4u572e7h9l9qec

Event #4:	Anders Wallgren to speak about patterns and processes for Continuous Delivery of Microservices at Continuous Lifecycle London
	Continuous Lifecycle London brings together experts and decision-makers in Continuous Delivery and DevOps to help reveal the potential and scope out the obstacles ahead of time. The conference’s holistic approach addresses concepts, processes and tools that are essential to Continuous Delivery and DevOps, as real world experts share their practical experience with attendees.

	Join Electric Cloud CTO Anders Wallgren as he outlines modern requirements for creating, deploying and managing multiple microservices both independently and as a collection in order to satisfy end user requirements and allow for Continuous Delivery.

	•	Continuous Delivery of Microservices: Patterns and Processes:http://continuouslifecycle.london/sessions/continuous-delivery-of-microservices-patterns-and-processes/
	•	Tuesday, May 3, 2016 at 11:40 a.m. BST
	•	30 Euston Square
		London, U.K.

Share:	Tune in for new #c9d9 episodes at 10 am PT on 4/5 & 4/19 @electriccloud http://electric-cloud.com/c9d9 #DevOps #CD #automation

	OR

	Attending #MERGE2016? Be sure to catch @avantika_ec‘s talk on managing#microservices at scale on 4/14: http://bit.ly/1VL08kt @perforce

	OR

	Join @anders_wallgren at @ConLifecycleLon as he discusses#ContinuousDelivery of #microservices on 5/3: http://bit.ly/1RnsJJ6

More Info:	For more information, contact Hilary Livingston at 303-581-7760 ext. 19 or via email at hlivingston@catapultpr-ir.com

About Electric Cloud
Electric Cloud is the leader in DevOps Release Automation. We help organizations developing enterprise web/IT, mobile and embedded systems applications deliver better software faster by automating and accelerating build, deployment and release processes at scale. Leading organizations like Cisco, E*TRADE, Gap, GE, HP, Intel, Lockheed Martin, Sony and Qualcomm use Electric Cloud solutions and services to boost DevOps productivity and Agile throughput, while providing a scalable, auditable, predictable and high-performance pathway to production.

Media Contact:
Hilary Livingston
Catapult PR-IR
303.581.7760 x19
hlivingston@catapultpr-ir.com

March 29, 2016

Chef Makes DevOps Workflow Faster and Safer for Enterprises Amid Rapid Business Growth
New Chef Delivery Product Enhancements Come as Company’s Annual Recurring Revenue Grows 94 Percent Year-Over-Year in 2015 and Chef Nears 1,000 Customers
SEATTLE, WA–(Marketwired – Mar 10, 2016) – Chef, the leader in automation for DevOps, today introduced Dependency Management, a new feature of its Chef Delivery product, that enables faster and safer developer collaboration by allowing Chef Delivery to know which services and applications in the pipeline depend on one another. With Dependency Management, not only must changes pass local tests, but related, downstream components or services must pass those tests, as well. Only service changes that pass are promoted, so deployments to production are safe. Dependency Management enables a reliable, repeatable and scalable process for cross-team collaboration in large enterprises. It doesn’t matter if there are two developers or thousands of staff — teams can create and safely deploy interconnected services on diverse runtime environments, including containers.

Chef also today announced enhanced capabilities for Chef Compliance to enable automated management of compliance policies that are based on the broadly used Center for Internet Security (CIS) benchmarks. Users can now implement CIS and other compliance policies as code, called “compliance profiles.” In addition, Chef Compliance offers an enhanced Windows experience by allowing users to import Windows policies from the Microsoft Security Compliance Manager.

By using compliance profiles in conjunction with Dependency Management, users can enforce these policies with Chef Delivery to ensure that changes to infrastructure and applications meet all requirements across the pipeline. Together these two new features enable users to easily input, track, and test service runtime dependencies. Simultaneously, users can incorporate CIS benchmarks profile into Delivery’s automated testing pipeline to create a foundation for meeting Payment Card Industry (PCI) standards.

Software is now the competitive currency of the enterprise. However, software is also becoming increasingly complex and composed of interdependent services that reside in the cloud. Businesses must be able to develop and maintain these intricate applications, along with the infrastructure that supports them, while moving at high velocity. It is critical that any changes to applications and infrastructure be versioned and tested before they are deployed to production. Because multiple teams often work on a single application, cross-team collaboration and transparency are critical to the success of a project. The DevOps workflow, which uses both culture and technology to foster these values, is becoming the most effective approach to developing software quickly and safely. Chef has distilled its customers’ successful workflow patterns into Chef Delivery, where service dependencies can be predefined and compliance requirements become part of the development pipeline. Chef Delivery eliminates silos and project segregation, enabling developers and operations personnel to begin committing code to the primary development pipeline in their first week on the team, instead of waiting weeks or even months in traditional environments.

“Enterprises need comprehensive solutions to safely implement DevOps in the push toward ever-greater development velocity. Unlike other frameworks and tools, Chef Delivery doesn’t just help you build a change management pipeline, it is the pipeline,” said Alex Ethier, vice president of product, Chef. “We’re committed to advancing our product in a way that enables developers, operations and IT to collectively manage the speed and scale of enterprise business.”

Company, Customer and Community Growth
The new product enhancements reflect Chef’s rapidly growing footprint in the enterprise. Today, more than 80 percent of the company’s revenue comes from enterprise organizations, and more than half of the Fortune 50 use Chef. Chef has tens of millions of machines under management on any given day. To date, the Chef client has been downloaded more than 27 million times, with more than 13 million client downloads in 2015 alone. Among the increased demand from the enterprise, Chef’s annual recurring revenue (ARR) grew 94 percent year-over-year in 2015.

Regionally, Chef’s EMEA business continues to rapidly expand. Q4 2015 was a record quarter for Chef EMEA, accounting for nearly 20 percent of the company’s total ARR for the quarter. Chef’s EMEA business now serves more than 150 customers and ARR for 2015 grew 91 percent year-over-year.

Chef is closing in on 1,000 customers worldwide, with Chef’s commercial offerings used by organizations including Nordstrom, Facebook, Disney, Target, Standard Bank, and Etsy.

Critical to Chef’s success is its open source community, which has more than doubled in size – at a clip of more than 100 percent year-over-year for three consecutive years – to nearly 70,000 registered members and thousands of active constituents contributing code daily. As adoption of open source technologies rise and more developers adopt Chef skills, the value of those abilities is reflected in enterprise careers. Dice recently noted that developers who cultivate Chef skills see return in a more than $130,000 annual salary.

Recently, Chef announced a new Partner Cookbook Program to allow even greater collaboration and integration for its open source community. Some of our partners include 3Scale, Alert Logic, CloudPassage, Dynatrace, Infoblox, and NetApp.

Availability
Chef Delivery’s new Dependency Management capability is now available to all current Delivery customers. Read more on accessing and utilizing this new feature. Register for a webinar demonstrating Chef Delivery with Dependency Management on April 7, at 10 am PT.

The CIS and Microsoft Security Compliance Manager profiles for Chef Compliance will be available on March 31 and demonstrated via a webinar that day at 10 am PT. Register here for this webinar and for more information on the profiles’ availability.

Additional Resources
- Learn more about Chef
- Learn more about Chef Delivery
- Learn more about Dependency Management
- Learn more about Chef Compliance
- Follow Chef on Twitter @chef
About Chef
Founded in 2008, Chef Software is changing the way companies build and deliver software to delight customers. Chef is the leader in automation for DevOps, empowering customers to build and operate high velocity organizations. Built on a strong open source foundation, we have distilled the proven patterns and practices for fast and scalable software development into our leading IT automation platform. Chef automates the continuous and unified delivery of applications and infrastructure, enabling enterprises worldwide to deliver software much faster with minimal risk. With hundreds of commercial customers and tens of thousands of open source community members, we are leading one of the strongest technology movements today. Our company is based in Seattle, WA, and financed by DFJ Growth, DFJ Ventures, Battery Ventures, Citi Ventures, Ignition, and ScaleVP. Learn more about Chef at www.chef.io.
CONTACT INFORMATION

Contact
Lucas Welch
Email Contact
206-745-0000
March 10, 2016
xMatters Boosts DevOps in the Enterprise with New Integration Platform
Next-Generation Intelligent Communications Technology Integrates Processes and Systems for Enterprise DevOps Stakeholders

London, UK. — 23rd February, 2016 — xMatters, inc., a leader in communication-enabled business processes, today announced the release of its integration platform – enhanced connectivity technology designed to help enterprises overcome key hurdles in DevOps adoption.

"IT support and service management tools are largely automated today for maximum efficiency, but ultimately people must be involved to move processes forward. Enterprises need to integrate real human activity into the service management and DevOps processes to continue to gain agility. To do that effectively, it makes sense to connect — in context — to systems that run these processes where people spend their time interacting. Using xMatters’ DevOps approach to integrate these systems with an intelligent communication platform will enable enterprises to achieve their business goals — by meeting SLAs and better time to value in deployments,” said Daniel Conde, analyst at Enterprise Strategy Group.

xMatters’ award-winning cloud platform accelerates business processes through intelligent communication. The technology pinpoints and proactively alerts the individuals, teams and external service providers required to work together to quickly manage any business scenario along with resolving incidents, such as service disruptions and technical issues that interrupt the flow of day-to-day operations.

Enterprises have long faced challenges in embracing DevOps – which Gartner defines as “a change in IT culture, focusing on rapid IT service delivery through the adoption of agile, lean practices in the context of a system-oriented approach” – because the agility of modern systems conflicts with the strict compliance, stability and reliability requirements of legacy systems.

Successful DevOps requires a wide range of stakeholders to efficiently communicate, collaborate and stay aligned with the business so they can build, test and release new software more rapidly, frequently and reliably. When companies engage in high-velocity software release cycles, it’s easy for key information to slip through the cracks or not get communicated to the right individuals, putting software delivery times or quality standards at risk.

"Intelligent communications is an essential part of an Enterprise DevOps toolset,” said Doug Peete, SVP of Product Management at xMatters. “As IT organisations embrace DevOps initiatives, they need to empower both technical and business constituents to drive key processes forward. As the leader in intelligent communications for the enterprise, xMatters is in a unique position to enable DevOps initiatives while still supporting the specific business needs of ITSM and major incident management.”

The xMatters Integration Platform connects modern and legacy systems and business processes to fundamentally alter the way development and operations teams work together in a DevOps environment. By doing so, standard IT service management processes can be managed in conjunction with DevOps processes.

The new technology operationalises, contextualises and automates communications within key DevOps processes to drive personalised communication at scale so individuals and teams can collaborate effectively and efficiently.

In September 2015, xMatters launched an expanded Global Partner Program designed to advance its platform for rectifying business disruptions in today’s always-connected enterprise. The company boasts more than 200 integrations and partnerships, including ServiceNow, Splunk, BMC Software, AppDynamics, New Relic, Salesforce and many more.

Supporting Partner Quotes:
“DevOps is an agile, collaborative approach to IT service delivery that brings together siloed teams, technologies and processes. xMatters’ new Integration Platform acts as a system of engagement, and helps empower enterprise IT teams to better manage communication and collaboration across these silos. It ensures the right information gets to the right people at the right time – and brings that information and context in Cherwell Service Management as the system of record. In that regard, intelligent communications driven by xMatters is an essential piece of the enterprise DevOps toolset.”
– Jarod Greene, Vice President of Product Marketing, Cherwell Software

"Moogsoft’s anomaly detection and event correlation across the production stack, combined with xMatters’ intelligently targeted alerting technology allows enterprise DevOps to identify and resolve incidents faster than ever before. This integration allows for better collaboration across DevOps teams through Moogsoft’s Situation Room and xMatters intelligent communication to engage the right resources with rich situational context."
– Stephen Hart, CTO, Moogsoft

"Our vision for New Relic is to be the first and best place to look to understand your digital business. Communications plays a huge role in delivering this experience and showing customers that everything is working – the health of the software, the quality of the customer experience and the business outcomes. We are excited about xMatters’ new Integration Platform which makes it even easier for New Relic customers to receive critical alerts, and also ensure that the right people are being notified on the right device with the right data at the right time.”
– Nate Heinrich, Product Manager, New Relic

“The xMatters Integration Platform is a welcome solution for enterprises that are aiming to adopt DevOps, but are struggling with the mammoth communications challenge inherent in rapidly delivering new IT services, while making sure everything is stable, reliable and secure. xMatters’ new offering makes it easy to connect with services such as API monitoring that are essential to maintaining platform health.”
– Neil Mansilla, Vice President of Developer Relations, Runscope

Resources
- Website: http://www.xmatters.com/
- Products: http://www.xmatters.com/products/
- Solutions: http://www.xmatters.com/solutions/
- Blog: http://blog.xmatters.com/
- Latest News: http://www.xmatters.com/company/press-news/
- Twitter: http://twitter.com/xMatters_inc
- Facebook: http://www.facebook.com/xMatters
About xMatters, inc.
xMatters’ cloud-based communications solutions enable any business process or application to trigger two-way communications (push, voice, email, SMS, etc.) throughout the extended enterprise during time-sensitive events. With over a decade of experience in rapid communication, xMatters serves more than 1,000 leading global firms to ensure business operations run smoothly and effectively during incidents such as IT failures, product recalls, natural disasters, dynamic staffing, service outages, medical emergencies and supply-chain disruption. xMatters is headquartered in San Ramon, CA with additional offices in London and Sydney.
February 25, 2016
An Engineering Think Tank to Change the World

In his famous book “Mythical Man Month,” Fred Brooks says, “Techniques proven and routine in other engineering disciplines are considered radical innovations in software engineering.”

While being very fond of engineering on the big scale, such as building millions of high-end and yet individually configured cars or double-deck aircraft or space ships, for example, I have always asked myself, why the most promising industry—software engineering—is so often not capable of doing engineering on that scale, too? Or, why are so many big enterprise IT projects painful in so many ways?

With these questions that nobody seemed to be really interested in on my mind, one day I met some higher corporate management, who wondered why the IT department would be so reluctant to follow their lean transformation advice and instead talked about some agile and continuous integration thingy.

From that moment, I understood that everything necessary to radically upgrade software engineering was already there! The biggest problem was that we do not communicate enough—and furthermore, there is no holistic view on the complete IT value chain.

By that I mean we need to create awareness for the value chain, starting with digitized formal models of business processes and written business requirements.

That was how the following chart came to existence, and I still love it. Apparently, most awesome things happen on the borders of separated knowledge domains; you need just to talk to colleagues from departments you’d never talk to! What if we would mix knowledge from big industry, best available process improvement and quality assurance methodology, and apply all this to how we design, build and deliver software?

At first I thought I had found a new perspective on DevOps, but now I believe there could be more to it. Well, now the door to the radical innovation is open! Just imagine: What if we would apply the Internet of Things approach to our industry? Maybe we could close the loop of process improvement in software development and test, moving it to real time and running optimization not by ambiguous frameworks but by hard facts coming from virtual sensors, with unprecedented levels of transparency?

This was how a couple of friends and I came to the idea of our foundation we call SIGSPL (Special Interest Group for Software Production Lines). This public organization is a non-profit think tank, built around three generic domains—Labor Automation, Analysis and Advanced Visualization—which we consider to be the three pillars of the upcoming convergent software engineering in the post DevOps era.

We are sure this sort of thing inevitably will happen, but our mission is to catalyze these processes to make radical innovation happen intentionally and faster, so we all can build information technology that rocks!

We are a small team of six with some infrastructure, publications at our blog and a well-established yet growing knowledge base. We would like to reach out to more like-minded people to let this idea grow and change the world. Our plan is to foster further exchange and discussions between DevOps experts and other specialists “unexpected” in this context, such as production lines and supply chain management experts, Six Sigma Black Belts, 3D artists, hackers, venture capitalists and many, many others.

Our proof that we are not ponding to nowhere is our magic triangle diagram, showing some well-known tools we map to the three generic domains, which are also of high interest for venture capital. Our question to the world is, What would appear in the middle of this triangle in, say, five years?

About the Author/Peter Muryshkin

Peter studied M.Sc. in Applied Computer Science and works in management consulting roles focusing on complex analysis and customer satisfaction, including IT Business Analyst and Change Manager. His current scientific research focus is digital transformation applied to the field of software engineering in large distributed organizations.

LinkedIn: https://de.linkedin.com/in/muryshkin
Team blog: http://sigspl.org/blog/

February 25, 2016
DevOps Debates: The Benefits of Tool Standardization
As my role demands, I work with various large enterprises looking at implementing DevOps to improve their software delivery cycle times. I have seen many strategies being adopted by them—some working, and some not working yet. I have pulled together some of the more common ones so we could debate them to see if these indeed are worth looking at. With that, I kick off my “DevOps Debates” series.

The first one on the list is a popular one: If you want to create anything in large volumes, you need to standardize the manufacturing process. That makes it easier to understand what is going on, control the quality and later change processes if necessary. This is happening in a similar fashion for software delivery processes and in DevOps.

Standardization techniques adopted in many large enterprises often include standardizing the toolset used by software developers. To do this, companies create a centralized tools group or software center of excellence (COE), which tries to find the best tool for the company and then implements and manages it for the teams. The intent is to streamline DevOps implementation across the board by having a common DevOps platform that hooks into these standardized tools, delivering common practices and reporting.

I have seen and heard a lot of emotional discussion on this. Here is my go, for and against the topic. Your thoughts are most welcome!

For Standardization:
1. Centralized teams can take a global view of how things are being used across the organization. As such, they are better placed to push best practices where necessary and learn best practices when they need to. This helps in picking the right set of tools.
2. Centralized teams can create a generic DevOps platform that can serve the needs of the organization across all groups. They then can help bring a DevOps focus and manage budget centrally.
3. Standardization helps organizations streamline license cost to optimize software use.
4. Small teams focusing on DevOps may not have the muscle power or the budget to create a momentum needed for adoption. Running a central body for such implementations helps.
Against Standardization:
1. DevOps is still evolving—standardizing may be detrimental to the innovation process that needs to happen within the tools and needs ecosystem.
2. Developers from various teams driving a DevOps implementation will be more successful; they can solve the issues “on the ground” rather than a central team trying to understand and then implementing a solution.
3. Some tools are good for a specific use and may not be used companywide. Standardization may reduce productivity.
4. Developers are the users of the tools—they need the freedom to choose what they want to use. Standardizing won’t allow them that freedom, which may upset them and, in turn, lead to decreased productivity.
Would that then mean,
1. While it is a good idea in the long run to standardize, is now too early to do it?
2. Would it be better to create a DevOps platform that can provide multiple tools support while standardizing the organization’s needs?
Thoughts?
January 20, 2016