Tag: devops

  • DevOps Leadership Series 2015: Women & Diversity

    DevOps Leadership Series 2015: Women & Diversity

    Many of the leading minds and practitioners in the DevOps movement are women.  I hope that comes as no surprise to you.  DevOps has always embraced a diversity of thought and contribution.  Case in point, close to 50% of the presenters at this year’s DevOps Days Boston event were women.  

    In this episode of the DevOps Leadership Series, we caught up with Jennifer Davis, co-author of Effective DevOps (O’Reilly 2015, $31) and software engineer at Chef.  Jennifer discusses a greater diversification of what DevOps means.  She sees more explicit efforts to expand DevOps into QA, security, DBAs, and other functional teams across the organization.  Jennifer also discuss the benefit of re-setting one’s expectations on the meaning of certain words (e.g., agile, test driven development, audit driven development) to accelerate progress and remove roadblocks:

     

    https://www.youtube.com/watch?v=B-zONUI5KQ4

     

    We then sat down with James Meickle, Site Reliability Engineer at Harvard and member of the organizing committee for DevOps Days Boston.  James witnessed distinct growth over last year in the diversity of companies in attendance —  both from a size and industry perspective.  James also discusses the importance of diversity that the organizing committee insisted upon as they planned for the event.  If you are organizing your own DevOps Days event, be sure to have a listen:

     

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

     

    If you missed part one of our series from DevOps Days Boston, be sure to watch these interviews from Beno Chapman of Constant Contact, Anthony Spring of Yieldbot, and Jeremiah Sullivan of Puppet Labs.

    Want learn more from the leading minds in DevOps?  You can find the entire library of 21 videos from this series on YouTube.

    Screen Shot 2015-09-30 at 5.40.06 PM

    Special thanks to my colleague, Mark Miller for capturing these videos for us at the event.

  • The business benefits of DevOps

    The business benefits of DevOps

    As DevOps has become more of a mainstream concept it seems like there’s less need to define what it is or explain what it does. As prevalent as DevOps is for those of us who work in the world of DevOps or organizations that have already embraced DevOps there are still many businesses out there muddling along the old-fashioned way and wondering why they should care about DevOps.

    The simple answer is that not caring about DevOps may be suicidal. The 2014 State of DevOps report found that organizations successfully implementing DevOps tools and practices lead competitors in almost every relevant metric. Two statistics that stand out from that report are that companies using DevOps are twice as likely to exceed profitability, market share, and productivity goals, and had 50 percent higher market capitalization and growth than rival businesses.

    Why is that, though? What is it about DevOps that leads an organization to be more profitable and productive? It’s a combination of three things, really: faster delivery times, greater stability / reliability, and freeing up time to focus on value.

    Let’s break those down some. DevOps is an evolution of the Agile development methodology. In fact, I’ve asserted in the past that DevOps is really just a matter of taking Agile principles and applying them to the rest of the company outside of software development. Whether Agile or DevOps the result when it comes to developing software is faster, more frequent delivery.

    Next we have greater stability and reliability. It might seem that the traditional linear method of developing software and releasing it on a pre-defined schedule is more stable. Developers and the rest of the organization have plenty of time to refine the code before it’s deployed, they know exactly when it will be deployed, and they know it basically won’t change for another year or so when the next major release is scheduled. The reality is the complete opposite in many cases.

    Developing with a rigid process methodology like waterfall means that only the changes and features identified at the beginning of the project are included in the release. As the need for improvements or additional features is identified during development those things are sidelined and added to a list to be pursued in the next release cycle. By the time the software is developed, tested, and deployed it is already out of date to some extent and bugs or issues that are identified take longer to address or get pushed to be handled in the next major release.

    The whole process is slow and results in less stability and reliability. DevOps yields greater stability and reliability because the faster development and more frequent release schedule enables organizations to identify and resolve issues immediately.

    Those two things combined mean that developers and others throughout the organization have more time available to focus on improvements and innovations that contribute to the bottom line. Organizations that have embraced DevOps also generally have tools in place to automate routine tasks which enables individuals to dedicate more time to growing the business and less time to pissing on fires and maintaining the status quo.

    DevOps has come a long way in just a few short years. There may still be companies out there trying to figure out why they need DevOps, but those companies won’t be around long. They’ll either figure it out and jump on the DevOps bandwagon or they will no longer exist to worry about it.

  • Native Integration of APM Driving DevOps Maturity

    Native Integration of APM Driving DevOps Maturity

    With applications performance monitoring established as one of the fundamental cornerstones of today’s DevOps methodologies, it’s easy to overlook the reality that effective instrumentation of such tools remains extremely difficult. Specifically, the biggest challenge remains creating performance metrics that address both IT and larger business initiatives.

    There’s no question that APM is one of the most widely adopted and deeply embedded elements in today’s DevOps world, serving as the critical source of measurement that enables more transparent and agile applications. Yet, despite the fact that performance monitoring solutions, and their respective providers, are considered to be among the most mature on the DevOps landscape, customers still struggle to optimize the systems to meet their specific requirements.

    However, as the market continues to advance, specifically via direct integration of widely-adopted APM tools with other strategic applications management systems, such as e-commerce platforms, organizations are finding a faster path to success, and bigger-picture DevOps benefits. One such partnership, announced in late August, saw market leader New Relic expanding integration with e-commerce platform provider Magento, owned by eBay.

    Jon Azrielant, director of marketing at online retailer Jewelry.com, a Magento customer, said that his company initially ran into significant obstacles in adapting New Relic’s APM capabilities to its processes, despite the comparative strength of the tools.

    “We had a really difficult time implementing New Relic initially, it was a painful process,” Azrielant said.

    While the APM tools provided Jewelry.com with the data necessary to generate vital alerts, along with more agile sysadmin and operations monitoring, the more silo-based, fragmented approach that it employed could not empower the retailer to circumvent traditional walls between apps support and service support teams, Azrielant said.

    Leveraging the extension of New Relic’s Software Analytics Cloud within Magento, the company has created more advanced instrumentation to inform critical business decisions. Among the most helpful of these measurements are those relating directly to customer experiences, while correlation of such metrics with Jewelry.com’s bottom line has also advanced executive decision-making, he said.

    “The critical result of this integration is more complete visibility across applications and business performance, importantly tied to the actual business ramifications,” said Doug McIver, director of product for Magento. “In the past, merchants had to do a lot of difficult integration to use these systems together, so obviously this is a hugely valuable capability for us to be able to offer, especially to customers with highly performant site requirements.”

    Moreover, Magento claims that it is growing its own customer base by tying APM more closely to its platform. Likewise, New Relic officials concede that to help advance crucial DevOps workflows, it must partner with such platforms to deliver APM data within the context of business requirements.

    “If we’re talking about how to win in world where we’re iterating the end users’ experience on a regular basis, we have to put performance metrics within context of the UI, and the business results; working from the same data sets and getting people on the same page is incredibly important,” said Abner Germanow, senior director of solutions marketing at New Relic.

    While pure performance stats are “near and dear” to New Relic for obvious reasons, the solutions provider is also attempting to advance a broader array of information that drives closer collaboration through new “iteration and experimentation”. New Relic is also focused on further developing the specific types of information most critical to key constituents such as e-commerce platform users. The need to create a common language for those DevOps efforts is amplified by the fact that development and operations officials are often unsure which metrics are critical to the business, and vice versa.

    “Instrumenting code has always been a challenge, and we’ve worked very hard to ease that pain across a lot of different platforms; there’s always another language where work can be done, and we look to our customers to help lead us into the next phase of instrumentation,” Germanow said. “We’re seeing a lot of pressure around the need for constant change and iteration in industries where it’s truly a matter of survival, such as e-commerce, publishing, digital governance and finance – places where the industry is behaving very differently now than it has over the last 50 years.”

    This work, and the subsequent APM integrations offered via platform providers such as Magento, have allowed end user organizations to remain focused on customer experience and sales, the ultimate goal of DevOps, said Jewelry.com’s Azrielant.

    “In terms of how this relates to the DevOps revolution, this is the advancement that is bringing everything together and allowing everyone to look at the same numbers, to share common APIs, to streamline reporting and event response, and define everything in uniform terms,” Azrielant said. “Ostensibly, the most basic tenet of DevOps centers around the unification of these disciplines, and you can’t support that without the unification of this information.”

  • “Culture” isn’t a swear word

    “Culture” isn’t a swear word

    7889902_orig

    I’ve heard a number of lazy criticisms of DevOps recently particularly where individuals talk about culture and that gets my goat.
    “It’s fluffy”
    “It’s in-actionable”
    “DevOps is just automation”
    “Cultural change isn’t relevant in a bank – its a term used by the Facebook’s of this world”

    I think part of this is the continuing confusion over what the term means, along with DevOps being used as an umbrella term for a dozen different other things (Continuous Delivery being the most prevalent).

    I’ve talked at length about what DevOps is to me in my blog so I’m not going to cover that again. However, I am going to talk about this wholly word “culture”.

    Let me start with a great definition of what culture is (it’s not my quote but I wish it was) – apologies I forget the source.

    “Culture is what you do when there is no one around to tell you what to do”

    I think that’s brilliantly simple and bang on the money.

    DevOps is concerned with bringing two disparate groups together (unsurprisingly Developers and Operations) and encouraging empathy and collaboration between them.

    Nothing in that talks about automation.

    The companies with the right culture between Dev and Ops might land as automation as a solution to curing some of the challenges of unshared incentives and goals.  However, it doesn’t predicate it.

    A strong DevOps culture might turn to Continuous Delivery as a process solution to meeting their demands for an increased pace of change. But again it doesn’t predicate it.

    Its really important that people understand the differences and goals between DevOps, Agile, Continuous Delivery etc.

    They all very closely relate and link but they are different things (take a look here for a glossary).

    Back to those criticisms…

    “It’s fluffy” – Culture is closely linked to human behavioural patterns and humans are very different. So its a fairly loose term but does it make less important? Not for me. How your employees and colleagues behave and interact is THE most important thing in a company. There are a squillion clichés out there about how your employees are the most valuable asset but its absolutely true. Great people and accomplish great things. Great technology is nothing without great people.

    “It’s in-actionable” – again this is a very lazy criticism. Culture is actionable its just hard to change. Changing the way you recruit, sitting people together in cross-functional teams, not micro-managing, encouraging lunch & learn presentations etc are all actionable ways of affecting culture.  Culture is hard to change though as we are dealing with people. People have different reactions to change and are sometimes difficult to second guess. It takes time and effort but that doesn’t make it in-actionable.

    “DevOps is just automation” – think I’ve done this to death but for clarity…the right culture could well lead towards automation as a solution.

    “Cultural change isn’t relevant in a bank – its a term used by the Facebook’s of this world” – why is having high performing people in a high performing environment only relevant to the unicorns of this world (i.e. Netflix, Facebook etc)? Its a daft comment in my eyes.

    Besides who are the companies earning the big bucks these days? Oh yeah its not the banks it’s Facebook, Google etc…

    Characteristics of a DevOps culture

    Here are my top twelve characteristics of a DevOps culture. How far are you off?

    • Measure everything, always
    • Individuals have empathy for the rest of the team (i.e. they don’t pass the buck)
    • Shared goals and incentives
    • Don’t reward the fire fighter, reward the fire preventer
    • Reward innovation and challenging the status quo
    • Don’t punish people when they try something new but fail
    • There is no IT and “business”. IT as much “the business” as the sales people.
    • Seek to break down silo’s
    • “It’s not my job” doesn’t exist
    • “Its my server/code/network/database” doesn’t exist
    • Individuals are empowered to make decisions
    • Top-up management rather than top-down
  • Upcoming SANS Webinar: Orchestrating Security in the Cloud

    Upcoming SANS Webinar: Orchestrating Security in the Cloud

    Organizations are increasingly migrating to cloud-based services to handle sensitive data and business processes, meaning security teams need to carefully review and understand what security controls are available to help protect them.

    Given the pace of cloud adoption, security teams need to increase security automation efforts and employ tools that can better secure their cloud assets through improved visibility.

    SANS is hosting an informative webcast on Wednesday, September 23, at 1:00 PM EDT (17:00:00 UTC) to present the findings from a new survey that examines the organizational use of public and private clouds and outlines best practices for assuring a robust security posture.

    The webcast is scheduled in conjunction with the release of the highly anticipated SANS whitepaper on cloud security titled Orchestrating Cloud Security (PDF), written by analyst and network security specialist Dave Shackleford.

    The whitepaper presents the results from a survey 485 IT professionals who use different cloud providers and service models for a variety of business needs, including collaboration services, email, managed services, backups for disaster recovery, and other common use cases for cloud services.

    Although cloud services provide the functionalities businesses need today, the survey reveals that they also come with inherent security risks.

    The SANS survey found that 40% of the respondents acknowledge they process sensitive data in the cloud, and are facing increasing challenges related to access control, configuration management, compliance demands, overall visibility, and the implementation of security controls.

    New technologies are emerging as part of the security-as-a-service (SecaaS) model, which are security-oriented cloud-based services that integrate with provider platforms to protect data in cloud ecosystems.

    “Although many controls are still managed internally, SecaaS is emerging as a viable means to enhance security in the cloud environment. Security teams should start considering the use of SecaaS options when designing and architecting cloud security models,” the SANS survey notes.

    In the upcoming webcast, Shackleford will be joined by myself (Evident.io’s Andrew Maguire), Intel Security’s Margaret Diego, CloudPassage‘s Sami Laine, and Mark Painter from HP Enterprise Security to discuss:

    • How organizations use the cloud
    • What types of information they store in the cloud
    • What concerns they have about data security
    • How much they rely on cloud service providers and what difficulties they face
    • What security and data protection technologies they use in the cloud environment
    • How they manage cloud users
    • And much more

    The SANS survey clearly highlights and validates the challenges of cloud migration across companies of all sizes. Organizations moving workloads to cloud architectures such as Amazon AWS understand the flexibility and cost efficiencies gained – but often struggle with new best practices and the shared responsibility needed to maintain a secure cloud-computing environment.

    The porting of traditionalsecurity technology and Agent-based solutions used in the past do not translate well to cloud environments, leaving customers with too much data and poor visibility into critical service configuration or controls that could eventually lead to compromise.

    Webcast attendees will be among the first to receive the whitepaper. Join us Wednesday, September 23, at 1:00 PM EDT (17:00:00 UTC) for this timely and informative webcast!

  • Are we really back to “just reboot it”?

    Are we really back to “just reboot it”?

    The server infrastructure management style of pets vs cattle was originally coined by Bill Baker of Microsoft though Randy Bias of CloudScaling further popularized it in 2012 and revised and clarified in this presentation. Essentially the original “pets” style of server management has mainly hand-built, named, and configured servers that are heavily cared for as much time has gone into their setup while the newer cloud style of “cattle” management has servers that are often numbered and created and scaled via automation and simply removed from service in the case of any issue. Colloquially the removal is termed “shoot the offending node in the head (STONIH)”.

    In the past due to poor practices or OS service instability (NT4 comes to mind), sysadmins and developers often did not bother to figure out the root cause of issues and simply made reboots part of standard operation procedure. In the times before 24/7 global customer bases and always on broadband and smartphones it may not have even been a big deal.

    On the surface cavalierly destroying and refreshing machines misbehaving in some way seems eerily similar to reboots. It’s different this time. Really.

    Virtualization

    Virtualization itself can cause a special class of issues that are out of your control. Noisy neighbor problems, underlying VM infrastructure/network or other issues can often only be resolved by starting a fresh node (possibly in a different logical area).

    High Availability (HA)

    HA has become more ingrained in systems architecture. For most instances, without inordinate effort you should be able to smoothly take out a bad server out of a cluster or load balancer with no or minimal downtime so you’re not making your users suffer and in fact will be giving them a better experience than potentially landing on a server with intermittent or worse issues.

    Following a few proper procedures provides some important differentiation and further opportunities to investigate compared to simple reboot techniques.

    Automation and Configuration Management

    Solid automated provisioning allows you to bring up the EXACT same machine configuration, put it in a different network subnet, or tweak it to have newer OS patches or software versions for testing if needed. Recreation is not a binary choice. You have options on how you do it and opportunities to learn from it.

    Centralized Monitoring

    Monitoring has come a long way from simple CPU/Disk/Memory and service uptime. Many vendors offer deep views into your application through application performance management (APM). It’s also easier to historically dig into not just that a CPU spike occurred but which processes were hogging cycles at the time to get at a root cause. You can more readily identify if an issue lies with your application or some supporting/OS services and with good automation simply spinning up a new server to test a theory is easier than excessive pondering.

    Centralized Logging

    Centralized logging can allow easier further log inspection after the node is removed and with much better search, analysis, and correlation capabilities than opening each file in a text editor on the machine itself.

    See you later, not farewell…

    The node often doesn’t have to be destroyed. It merely can be pulled out of service or stopped. It or its virtual disks can be examined further at a later time if needed. Exercise caution with spinning up a node again if it has any behavior to auto-join a cluster/farm or will start processing jobs, sending e-mails, etc on its own. Having a practiced isolated network environment can be handy for further analysis and can double as a test bed in the case of potential security breach analysis.

    Herd away

    By following the guidelines above, STONIH will minimize the time any misbehaving nodes affect your user experience. Just don’t forget to follow-up on a root cause especially if patterns or recurrences start!

  • The 3L rule, a general piece of advice

    The 3L rule, a general piece of advice

    What I am going to describe will sound elementary to most of you, even trivial but I know that there is a difference between being aware of something and actually doing it.

    I have been working hard to spread the DevOps word these last few years and through experiences, project, conferences and articles I have come up with my very own little personal piece of knowledge; what I call the 3L rule.

    Learn from the world.

    This is the easiest of the three. Use Bing, Yahoo, Google, blogs like www.devopsy.kinsta.cloud, specialized websites, books and everything you want. The world is now at your reach, thanks to the internet and the wide spreading of smartphones. How many persons in the bus or metro around you are watching a screen nowadays? How many of those are actually watching the screen and learning something new? I know I see many playing cwazy cupcakes or any other game that is a time killer. However, they are exactly that, time killers.
    Why would you want to kill time when your brain is most likely craving new knowledge, begging to use it for more than just identifying a simple pattern on a screen, dodging monkey poop or even cutting fruits? On a personal note, if you really feel like a samurai, go cut some fresh fruits and make yourself a nice juice.
    The internet is available to you at all times with an almost infinite amount of information to collect. I am not telling you to stop playing, I am a hardcore gamer myself, but for your brain’s sake, you have to diversify activities. Do not always play, your brain is a sponge, make it absorb data or it will go dry.

    Learn from those around you.

    This one is a bit harder; it requires a couple of things:
    – Some attention span: it is not always easy to be ready to listen to someone when you reach your tenth hour of meeting of the day (but then maybe you should learn to better plan your days) but try to make an effort. Many might disagree with that but most meetings have a message to convey. It might not be the main topic but a well-driven meeting can be a valuable source of information. To figure it out, the only way there is, is to actually listen to the person talking.
    – Empathy: some persons struggle to get their message through, not matter how important it is. That is where you should try to demonstrate what might be a new skill: empathy. Instead of watching the speaker desperately and painfully trying to make a point, why don’t you try to help him/her. Do not jump in with what you know, that is stealing the light, instead why don’t you ask a question to put him/her back on track? It’s super easy and by making a human contact (mute people in meetings can be scary), you create a link with the presenter and might relieve some of the stress.
    – Capacity of analysis: people do things around you, all the time. They work, they speak; they create value. If you are at the office right now (you should not be reading this but please continue), look around you. Take a quick break and go ask one of your teammates what he/she is doing and why. You might actually learn something. Do this repeatedly until you got the whole picture of who does what. Then try to wonder why and repeat the process many times until you reach the big bang. Through every single iteration, you will most likely learn something new. Forest Gump used to say: ”life is like a box of chocolate: you never know what you’re gonna get”. I prefer to think that life is like a puzzle, it is up to you to put the pieces together.

    Learn from yourself

    The hardest of the three rules.
    You are flawed. Humans are flawed and make errors. What makes us worth something though is that we can actually learn from our mistakes. Once again, the big question you should ask yourself when facing an error is why.
    Why did that happen? Was there an error in the process? Did I misunderstand something? Do I lack knowledge or skill to perform that task? Did I not get enough time to perform that task? Ask yourself all the questions you need until you can come up with a definitive answer.
    When you do, that is where the tricky part starts. If you are to blame for the problem, make sure that if you were to redo the same task there would be no chance of the same error happening again. Fix the process, correct the documentation, train yourself, speak up! If this is someone else’s fault, do not point fingers, you are not in third grade anymore, instead help that person to do a better job so that, in turn you can perform your task as expected. Who knows, that very same person might help you one day.
    The problem with that rule is to admit that you might make mistakes. Once again, humans are flawed and it is only normal to fail every now and then. Some of the greatest things were invented by mistakes: the tarte tatin, corn flakes or even the microwave oven. Maybe you will create something life changing too.

    While that 3L rule should not surprise anyone, especially people in IT where learning is key, I find it a good reminder and always recommend everyone to apply it. It works very well in our domain since it is evolving so fast but it can be applied to everything really. Try the last rule with your better half for example, this might prevent conflicts to come like another fight about why you washed a pair of black jeans with his/her white underwear.

    Good learning!

  • Why I became DevOps Certified

    Why I became DevOps Certified

    I usually do not care too much about diplomas or certifications. To me, one’s value isn’t reflected by a piece of paper but rather by his or her actions, dedication, motivation and efficiency. And yet, I decided to become DevOps certified and furthermore, become a teacher for that very same certification. Have I gone insane or did I make a choice based on reasons that could appeal to you? Read further to find out.

    Set up a standard.

    I have been advocating DevOps for years now, reading everything I could about it when it was just a fun word created by Debois and recently writing quite a lot and giving conferences about it too. One thing that always strike me is that, no matter the context, no matter the experience of the people I’m speaking to, there is always one person asking me: “but can you tell me what exactly is DevOps?”.

    DevOps strength is also its weakness. By not defining a manifesto, a chart of good conduct or even a clear definition, DevOps leaves room for improvement over time but also creates what it tries to break down: silos. By being so undefined, you end with people “in the know” and the others who are desperately trying to get a grasp of an idea that’s clear to many.

    A certification, while arguable, brings exactly that level of standardisation we needed. By enabling me to have a clear definition of what DevOps is, it gives me the opportunity to spread it further but not only that, I also finally talk about the same thing as others around the globe. Gone are the days where you would see a new definition a minute, now that we all know – and agree on – what we are talking about, we can finally start to actually do it.

    I could have stopped here, taking the certification, being all knowledgeable about that topic but it would have been a bit against DevOps’ philosophy. Sharing is caring and if I get people to understand at least the basics of I what I preach, then we understand each other better and I make others better at their job (hopefully). And that’s exactly why I became a teacher: to spread the word and get people who don’t know to finally know. People over everything else, right?

    The DevOps Institute.

    Ok this part will sound a bit like a commercial but I’m just going to explain the reasoning behind my decision to go with that one.

    There are many certifications about the topic popping up these days so it was not necessarily an easy decision to make. After all, since we are still discussing whether or not to have a certification on that specific field, nobody was more legitimate than another. And then I read this article by our dear Alan Shimel: here.

    The fact that his name was associated with a certification intrigued me and I went to check it out. Then I realized that names I was already familiar with were also a part the institute (Lisa Schwartz and Jayne Groll) which made me think I was actually facing serious people.

    I read a bit more about them and discovered that both Gene Kim and Sanjeev Sharma, two persons I highly respect and read a lot from, were part of the institute’s board.

    That was it! It all went super-fast after I took contact with the institute. I filled up the usual forms and in no time, I was in the program, training myself to become the trainer, reading even more about DevOps, learning some new things and exchanging with brilliant minds before taking the final exam.

    What it all means

    While it won’t change your life, those of you who wanted to become unicorns still have to buy a costume for that, becoming a certification trainer gives you the opportunity to meet and help people who want to know more. Whether or not they take the actual test does not really matter. What matters is that you hold the same speech as others around the world and that people who come to you with questions might leave with a bit better understanding of what it is that you talk about.

    Before comments rain down on me, telling me that this is heresy and that I should be condemned to watch Nyan cats for 48 hours non-stop, I just want to precise that I do not have any interest in anything other than my job. I am just advocating for a certification and explaining why I took this one more than another.

     

  • Impacts of DevOps on Testing

    Impacts of DevOps on Testing

    DevOps

    I always come across a standard question from testers in any DevOps related presentation. “Will DevOps remove the need for Testers?” A simple answer is “No”. DevOps is not going to replace Testing as a discipline. Firms implementing DevOps have a vision for better product quality workable by brilliant Testing.

    DevOps is an enabler for the following.

    • Reduction in IT Budgets
    • Efficient end-to-end delivery
    • Lean delivery framework
    • Working end-to-end automation framework

    Successful businesses today are design thinking driven. Businesses have a strong sense of urgency, aided by innovative software engineering practices. Businesses today need to have a working continuous delivery practice in place. Continuous delivery also mandates better product quality and zero touch end-to-end delivery. Automaton is key to success across DevOps processes.  Delivery by co-located, integrated teams using innovative tools prevents collaboration and communication issues.

    Manual errors, Stove-piped communication issues get sorted with a good DevOps Governance model.

    DevOps mandates “Fail Fast, Fail Often” driven by “Test First” concept. This means that testing is a continuous process and more extensive in nature. Testing allows for cohesiveness between various teams, automation of everything possible. Testing also allows for continuous improvement in test process delivered via iterations. Intelligent test automation, improved regression, continuous test augmentation are some benefits delivered by DevOps.

    • Key benefit delivered byDevOps is the cost reduction in end-to-end delivery.Businesses achieve cost reduction by Automation, manual error reduction and reduction of duplicate effort.
      • Continuous delivery enables streamlined governance and reduces time-to-market.
      • With fail-first, fail-fast, fail-often philosophy, shift-left testing is a reality. With early defect identification, product quality increases. With increased automation, continuous testing is a feasibility.
      • With co-location, productivity of DevOps teams (design, test, operations) improves.

    Implementing DevOps could be tricky in organizations having monolithic systems and processes. Culture change is critical for successful initiation of DevOps and Continuous Delivery.

    From a testing standpoint, DevOps addresses the following key testing challenges.

    • Test Environment – Virtualization, Automated Deployment, Automated build and configuration management, data refresh and maintenance becomes simple
    • Continuous Integration, Automation and Verification – Test First centric test driven development, behavior driven development concepts allow test processes to improve in a DevOps Model

    As per a report published in 2002 by NIST – Cost of Poor Quality (in US) was $59.5 Billion per year. Cost of poor quality is higher in large organizations running legacy infrastructure. By some industry guesstimates average cost of a production bug is about $7000. Customer experience and agility for quick delivery takes a hit if the organizations aren’t quicker. DevOps becomes a positive catalyst here.

    Some skeptics may say “DevOps looks easy on paper but difficult to put in place”. Any innovative change is difficult to implement at first. It takes discipline and drive to run the operations watertight to achieve the goals.

    Some key factors to implement for Successful DevOps are

    • Cohesive, One Team mentality between teams
    • Implementation and Use of Tools that take away manual effort
    • Continuous Delivery Phases
      • Superior, Automated Configuration Management Approach
      • Continuous Improvements across phases
      • Continuous Automation
      • Continuous Integration
      • Continuous Testing
      • Continuous Monitoring

    Use of tools is key to success of a DevOps program. Plethora of tools are available to support automation. Tools are available for Environment Build, System Configuration, Application Build, Database Setup, Artifact/Document Generation, Testing, Requirement Management, Collaboration, Production Monitoring, and Reporting across DevOps activities.

    Like Agile Delivery Programs DevOps needs a strong Team Cohesion to be successful. A DevOps team need to have a Product Life-cycle Management mindset as well. This also means that team needs to unlearn standard SDLC processes.  This means, DevOps team should have a clear vision. Vision to Ideate, Implement, and improvise and retire the product. An integrated DevOps team with clear vision will make DevOps projects successful.

    Conclusion:

    DevOps testing needs to address the need of Business and Technology needs. Automation plays a major role to achieve this aim. DevOps in principle has a goal for better product quality albeit the need for faster delivery. Terms such as “Shift-Left”, “Fail-First, Fail-Fast, Fail-Often” will be regular vocabulary in DevOps. DevOps Test team comprises of Cross Functional Specialists and Testing Purists. A Performing Testing Practice for DevOps will take some time. Testing as a practice has matured over the past two decades and is well equipped to support DevOps. Use of automation and productivity enhancement tools helps testing move faster.

    Successful DevOps implementation in large firms with legacy processes and technology is a challenge. A big culture change is the only way to achieve success in such firms. It will be a hybrid DevOps Model as purist implementation will be a challenge.

     

  • Librato Seeks to Unlock DevOps Application Monitoring

    Librato Seeks to Unlock DevOps Application Monitoring

    As wider adoption of DevOps methodologies continues to foster demand for new tooling to help streamline evolving workflows, at least one vendor is attempting to address the growing need for related monitoring capabilities.

    Librato, a San Francisco-based provider of Amazon AWS applications performance monitoring (APM) services, claims that it is finding favor among the rapidly expanding DevOps community driven by its ability to inject critical visibility into the engineering lifecycle.

    Acquired by Austin, Texas-based SolarWinds in January for a lofty $40 million and renamed Librato SolarWinds Cloud, the company is touting its recent adoption by well-known providers such as Slack for monitoring of DevOps-centric applications performance and health metrics.

    “At its core, DevOps is destroying conventional wisdom around ritualized processes and the need to perform them, mostly in the domain of scale,” said Dave Josephsen, Developer Evangelist at Librato. “By attempting to include monitoring as a key element of the development lifecycle, this has created a whole new range of challenges, and opportunities.”

    By providing a centralized Web interface and open API to help create visibility into critical applications engineering requirements, Librato maintains that it is creating the tooling necessary to empower integrated development and deployment processes, such as continuous change control.

    “There are a lot of disparate tools for monitoring individual engineering tasks, but there hasn’t been any practical way to bubble up that data for efficient monitoring,” Josephsen said. “Within the context of DevOps, change control is a ritual that we’ve abandoned as we’ve embraced test driven development and automated away the human element, so there’s a distinct need for monitoring of feedback and metrics.”

    For example, cloud-based productivity messaging specialists Slack are using the Librato “StatsD” lightweight daemon process to stream business and app-health metrics regarding PHP applications into the monitoring platform. Slack also leverages Librato to chart data regarding connect, query and fetch latencies for its server clusters, and to monitor internal metrics about overall system health.

    “Having those graphs side-by-side lets us clearly see and compare the effects of network latency on one of our new services, and that’s very cool,” Richard Crowley, director of operations at Slack, wrote in a recent testimonial posted to the Librato Solarwinds blog.

    Industry experts agree that broader adoption of DevOps strategies will continue to drive demand for relevant monitoring tools, with solutions such as Librato seeking to deliver “modern stack architecture for looking at the modern stack.”

    “I think that APM is always interesting because it’s always new,” said James Governor, industry analyst with RedMonk. “The pace with which we’re building new architectures to deliver services to end users is increasing all the time, and with every new wave of technology, we tend to get new and associated models of APM tooling.”

    Librato is taking advantage of the need for a system that brings together the elements necessary for cloud native monitoring, and in an agentless manner different from other competing tools such as New Relic, the analyst noted.

    However, whether or not the platform is able to break down traditional engineering siloes to enable more efficient DevOps management, as Librato officials claim, remains to be seen, he said.

    “Each wave of technology has promised to do this, to remove the inherent finger pointing, and each has always made the same claim to break down organizational firewalls,” Governor said. “DevOps hasn’t boiled the ocean in this manner yet, but there are some unique opportunities; unlike previous waves, where automation was intended to replace humans, this is now about augmenting people, and we are seeing that teams are choosing new tools from which developers can truly derive value.”