CI Tools and Best Practices in the Cloud

Continuous Integration

Subscribe to Continuous Integration: eMailAlertsEmail Alerts newslettersWeekly Newsletters
Get Continuous Integration: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


Continuous Integration Authors: Stackify Blog, Aruna Ravichandran, Plutora Blog, Dalibor Siroky, PagerDuty Blog

Related Topics: Continuous Integration, DevOps for Business Application Services, DevOps Journal

Blog Post

Practical APM & DevOps By @SolarWinds | @DevOpsSummit [#DevOps]

DevOps is a development methodology based on continuous integration and continuous delivery

A Practical Approach to Application Performance & DevOps

Considered by many as the next step beyond Agile, DevOps has proven to be effective at accelerating development cycles, improving performance, reducing bugs and overall improving the innovation and velocity of development teams.

There are a couple ways to look at DevOps: first, DevOps is a development methodology based on continuous integration and continuous delivery supported by set of configuration management tools such as Chef, Puppet, Salt and Ansible. We can also think of DevOps as a simpler set of principles that guide development and deployment practices - automate everything, monitor everything and log everything. All with the goal to get visibility into how every change in a fast-paced iterative process impacts performance.

The challenge - aside from the complexity involved in implementing these tools, building scripts and morphing the entire development process - is that DevOps requires a culture change and a new set of skills. The key question then is: Where to start? How can teams start enjoying the benefits of DevOps without having to wait months or years for new skills, tools and processes to be in place and for a new culture to take root?

The Basics
Maybe the best place to start is with the basics. The fundamental idea behind DevOps is that developers and operations teams must work together, collaborating in real-time to provide developers with information about how applications run to improve performance as these applications are built. Thus, a key aspect of establishing a DevOps culture is providing development and operations teams with visibility into application execution and performance bottlenecks. Every great leader understands that teams work well together when they have a shared purpose and a shared understanding of reality. What this means in the realm of application development is that for DevOps to have an impact, everyone must be on the same page with a single version of truth that provides that common understanding of what is working and what is not.

While this sounds simple, the reality is that more often than not, the different teams working on applications are organized in silos, with each team running their own dashboard and having their unique view into their particular portion of the application stack. The result is finger pointing and issues that hide in the space between silos and the interdependencies between components of the application stack.

A powerful first step towards DevOps is working toward providing a single version of truth for these teams - a common framework where all team members can understand what goes on in the application, database, OS, hypervisor, host server and storage systems. Such a system eliminates finger pointing by making it very clear where issues are, in a way there is no more ambiguity, just action.

How to Implement
With this in mind, here are five recommendations to implement a DevOps culture in your organization:

  1. Give developers direct monitoring visibility into production, staging and test servers. Until a developer sees the real behavior of the code hitting loaded databases, they have no sense of how the application will really behave.
  2. Make teams self-sufficient in their performance observations by eliminating gatekeepers and performance information silos. When developers get direct insight to the performance, their interaction with DBAs and operations will be constructive, rather than one of begging for information.
  3. Make performance a stated requirement up front. For too long, performance has been an afterthought, addressed only after the functional specs had been addressed. Making specific performance requirements an essential part of the design process, with testing and evaluation of performance early in the development cycle, ensures it will not have to be tacked on later.
  4. Establish shared metrics so development, production and management have a basis for comparing results, evaluating progress and tracking change impacts. When the software and system engineers have a common basis for discussion and progress evaluation, they'll be in better shape to work towards the same goal.
  5. Focus on the end user experience, whether the end user is an external customer or an application owner in an internal business unit. When IT takes a service orientation, the service level delivered to the customer is really the only important metric on which to evaluate the IT department. With a common goal of responsive, predictable service for end user applications, both production and development can collaborate to meet the common target.

But That's Not All
There are two important additional considerations. First, monitoring tools alone are not enough. Health-based monitoring provides up/down status, usually focusing on green, yellow or red status indicators for dozens or hundreds of components. They are useful to identify when something is broken, but they are very limited in identifying the root cause of problems and the correlation between components. A system can be massively inefficient and yet the monitoring dashboard can show all lights as green, as nothing in particular is broken. This is why it is important to look at a system with a performance orientation, to understand the wait times and bottlenecks.

Second, many DevOps teams try to monitor everything. The result is gigabyte-plus logs that require advanced tools and lots of time to analyze. While the graphics produced can be very cool, their usefulness is limited to their ability to produce insights. A terabyte of log data is useless unless it can pinpoint what is wrong with the system.

In the end, development and operations teams can work better together when:

  • They share the same view into the system that provides visibility across the stack layers and dependencies between them
  • They have a performance orientation focused on finding bottlenecks and insights that result in action

Even without the complexity of a full-blown configuration management system, having the right goals and effective performance tooling can get you one step closer to DevOps nirvana, which means faster applications and innovation.

More Stories By Gerardo A Dada

Gerardo A Dada is Vice President of Product Marketing and Strategy for SolarWinds’ database and applications business globally. He is a technologist who has been at the center of the Web, mobile, social and cloud revolutions at companies like Rackspace, Microsoft, Motorola, Vignette and Bazaarvoice. He has been involved with database technologies from dBase to BTrieve to SQL Server and NoSQL and DBaaS in the cloud.

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.