Tag: devops

  • AWS Extends DevOps Ambitions via Managed Services

    AWS Extends DevOps Ambitions via Managed Services

    Amazon Web Services (AWS) is signaling its increased interest in providing managed services spanning multiple aspects of DevOps with the launch of service that promises to make it easier to set up development projects.

    At a recent AWS Summit conference in San Francisco, CTO Werner Vogels described AWS CodeStar as a means for building pipelines using templates that span more than 90 different AWS services. The templates currently support five different programming environments: JavaScript, Java, Python, Ruby and PHP.

    CodeStar automates configuration of a continuous delivery pipeline for each project using CodeCommit, CodeBuild, CodePipeline and CodeDeploy, as well as providing integration with Atlassian JIRA Software for tracking issues via the CodeStar console. There also is a preconfigured project management dashboard for tracking activities such as code commits, build results and deployment activity.

    Over the past couple of years, AWS has expanded the number of managed services it provides considerably, including databases and now various classes of machine- and deep-learning algorithms exposed as a service. In most of those cases, it is replacing a task that previously was performed by IT operations staff with an automated service. That may appeal to IT organizations that have standardized completely on AWS. But in a multi-cloud world where elements of applications are deployed both on-premises and across multiple public cloud services, it remains to be seen the degree to which organizations will want to employ managed services that only automate AWS processes.

    One thing’s for certain: DevOps processes across multiple computing environments are becoming more automated. As microservices architectures become more widely employed, many organizations in the months and years ahead will become a lot more comfortable mixing and matching various cloud services as they see fit. Within that context, automation of DevOps processes will need to be multiplatform almost by definition. As a set of services exposed via application programming interfaces (APIs), it may very well turn out that the automated managed services provided by AWS can be programmatically invoked by other DevOps management frameworks.

    Of course, there are plenty of organizations that, for now at least, have standardized on AWS. DevOps delivered as a managed service by AWS clearly has some appeal for those organizations. But as cloud computing continues to mature, the number of organizations employing only one cloud service is expected to decline.

    While the battle of control of the cloud has been mainly focused on developers, more attention now is being paid to how application development pipelines get managed in the age of the cloud. Each IT organization will have a unique set of processes and requirements for managing those pipelines. In fact, the issue going forward will be to what degree can cloud service providers (CSP) adapt to those processes versus making the IT organization adapt to the CSP.

    In the meantime, IT organizations would be well-advised to establish the roles and functions they need to manage those automated pipelines sooner than later.

    — Mike Vizard

  • CD 101 Podcast: The What, How and Future of Continuous Delivery

    CD 101 Podcast: The What, How and Future of Continuous Delivery

    Now that we’ve arrived at Episode 4 of our CD 101 Podcast, let’s address some basic concepts—like the what and how of it all and the future.

    Wait … perhaps we could—or should—have touched on these key topics earlier. Or not. At least not the future part? Anyway …

    While this (mostly) backwards-looking orientation may seem a bit odd, I’d argue that we’re actually navigating the conversation on precisely the correct path. Let’s rewind for a moment to look at where we’ve come from.

    Episode 1: We highlighted many of the fundamentals of this thing called CD, yet we did so from more of a conceptual and best-practices standpoint. While the ideas and processes involved do resonate in the real world, the topics we cover in this episode are bit closer to the water-cooler conversations we’re hearing about CD as it grows in practical adoption.

    In Episode 2: We covered the whole how do you “realize agility” piece of the conversation. This is important and a precursor to some of these other basic questions. The entire process of digital transformation begins with getting agile and you can’t truly adopt continuous delivery without doing so; therefore, this was another good place to feed today’s discussion.

    In Episode 3: We looked at the prospect of re-inventing the “Modern Software Factory” with agile development and continuous delivery. OK, so, perhaps we were getting a bit ahead of the basics here, but I’d maintain that this is an important piece to consider upfront that builds on these other building blocks. As with the topics covered in Episode 2, it is critical to understand the big picture challenges and benefits before you begin to get your hands dirty.

    And now for some nitty gritty.

    In Episode 4, we hear from Shamim Ahmed, CTO of Continuous Delivery Solutions at CA Technologies, as he answers the nine burning questions he most often hears in speaking to enterprise practitioners as they look to employ DevOps and Continuous Delivery practices in the real world.

    So, while these previous conversations were material, this is a crucial set of topics to consider as you invoke your own strategy, including:

    1. What is the difference between DevOps and continuous delivery?
    2. What are the key impediments/obstacles to achieving speed/quality in CD?
    3. How do we overcome these obstacles?
    4. How do we get started on the CD journey?
    5. What are the key top-level metrics you want to track in a CD program?
    6. What org changes do we need to make to implement CD?
    7. What the key capabilities we need to implement?
    8. How do we integrate all the different tools we have in our environment?
    9. How will the future of continuous delivery evolve?

    OK, that last part is a bit more postulation on our part—though we like to think on the practical side, based on the answers to all these other important real-world adoption dynamics.

    Tune in and hopefully learn a good deal about where your approach stacks up, and needs to evolve.

    As always, you can find said Episode 4 of the Continuous Delivery 101 Podcast by:

    • Listening to it on your computer on YouTube
    • Downloading it from iTunes store
    • Downloading it via the Podcast App by searching for “Continuous Delivery 101 podcast”

    Enjoy!

    — Scott Edwards

  • An Unanticipated Obstacle to Full Automation

    An Unanticipated Obstacle to Full Automation

    I’ve been concerned about the impact of automation on human employment for a while. My research activity started after November 2016, when I decided I needed to learn whether the much-touted phrase, “We’re bringing back the jobs,” was valid or not.

    While it is true that some jobs in the United States have been exported to other countries, a study coming out of Ball State University in Indiana asserts that 88 percent of the jobs lost by U.S. workers is due to automation. Combine this study with the one published in 2013 by Frey and Osborne out of Oxford University that says that 47 percent of the jobs in the United States are risk, then things don’t look so rosy. Martin Ford, in his book, “Rise of the Robots,” goes so far as to say that every occupation is at risk, not just low wage workers who are paid to do repetitive tasks that are easy to learn. Not only will we have machines flipping burgers, they’ll also be perusing volumes of legal documents during discovery processes, which is the type of work that now is done by paralegals and newly hired law school graduates.

    Machines are getting smarter all the time and they are getting cheaper. You can buy Baxter, a full fledged factory robot, for $22,000. Baxter can work 24/7 and is not subject to OSHA laws or workers’ compensation coverage.

    Software? That’s getting cheaper, too. Every day, another open-source project is made available on GitHub that allows anybody with a computer and connection to the internet to take advantage of the power of artificial intelligence and machine learning. You want Swift code for artificial intelligence? No problem. It’s on GitHub and available to all for free! Want to convert your English ReadMe into Japanese? Simple, just use an API such as Microsoft Translator or Google Cloud Translate.

    Given the current trends in technology, it’s not hard to imagine that within the next 15 years to 20 years we’re going to have a world in which fewer people are employed. This future scenario worries me.

    About a week ago I was sharing my concerns with Chris Surdak at Surdak and Company. Chris works with large corporations implementing robotic process automation (RPA). He is also on the board of the Institute for Robotic Process Automation and Artificial Intelligence. Chris is at the front lines of using robotics and artificial intelligence to increase commercial efficiency. He and I share a concern about the wave of worker displacement we see on the employment horizon. However, Chris has an interesting take: While he agrees that automation is going to cause significant displace of human workers, he sees an obstacle.

    Imagine you are an executive in a corporation and you have 5000 people under you. One day someone like me tells you that you can replace 80 percent of your workers, 4000 people, by streamlining your work processes using robotics and artificial intelligence. You should be ecstatic, right? That is a significant cost savings that is going to directly affect your bottom line.

    But, it doesn’t work that way because that is not how many corporate managers think. They want to keep their jobs and in order to do so they need two things: headcount and budget. So, if I come along and tell them that I can create an efficiency that is effectively going to cost them power (less employees and a smaller budget to manage) and maybe their jobs, do you think they are going to jump on board right away? Nope. In fact, they are going to do everything that can to slow down my work until they retire.

    Chris’s statement was a revelation to me. Previously, I thought corporations in their continual quest to seek greater profits will do whatever is required to reduce costs and increase efficiency. Most of us who do tech, particularly in DevOps, have embraced this notion. Automation is our friend. We’re lazy. We want the code and machines to do the heavy lifting. And, we’ve created environment where automation is necessary, For example, large-scale container deployment alone went beyond the capabilities of human management a long time ago.

    There is a good argument to be made that the factory floor has not had problems using machine automation to improve efficiency. Factories have looked for improved efficiency via tooling since before industrial textile mills used water wheels to power their looms. But, there are other industries that are risk-averse and slow to change; insurance, for instance. The virtue of an industry such as insurance is that it’s ingrained in its culture to manage risk and to be measured when considering change. After all, would you want your retirement annuity to be subject to the whims of a day trader? No. You want your money well-protected by a cautious steward. However, with such safety comes inertia. Thus, there is an intrinsic resistance to change in general and automation in particular. Add in a culture of self preservation on the part of management and … well, you get the picture.

    So there are industries that will be resistant—for a while, anyway. Then one of two things will happen. The companies that are not resistant to automation will enjoy the efficiencies the technologies bring. They will gain market share by providing a better product at lower cost and they will trample out the competition—think Uber and the taxi industry. Or, those resistant corporations will realize that to survive, managers who manage by “saving my job” will be given a golden parachute after revealing all the tribal knowledge hidden in their work groups. (Undocumented rules and processes are the bane of process engineers when implementing automation.) Either way, the march of automation will continue and workers will be displaced.

    Given the increasing rate at which jobs are being replaced by automation, will these displaced workers find other jobs? This question I leave to you to answer.

    — Bob Reselman

  • DevOps: The Innovation Power Couple

    DevOps: The Innovation Power Couple

    If “Dev” and “Ops” are the power couple of tech, “DevOps” is the holy matrimony that takes innovation from trainwreck to fast and repeatable. At most businesses, however, Dev and Ops still sleep in separate rooms and agree only on their mutual contempt.

    Dev (Development) and Ops (IT Operations) usually are divorced or ready to serve the papers because their incentives clash. In Ops’ opinion, Dev is an idiot—always out late drinking with friends, he comes up with wild ideas and wants to implement them immediately. Dev can’t make anything work on real servers and can’t write scalable, stable code.

    To Dev, Ops is a total code-blocker—she makes Dev go through “change management boards” and slows down progress. She lets the competition get to market first. So every day, Dev and Ops have an angry shouting match that ends in tears.

    I wish I were exaggerating. My coworker Brandon Cipes once walked into an interview for a product development position. The interviewer broke down crying because the relationship between Dev and Ops had gotten that nasty. They refused to meet with each other, let alone be in the same room.

    When Dev and Ops have a dysfunctional relationship, they struggle to communicate, collaborate and get results. Their organization will fail at innovation because it lacks the cultural, technological and procedural base to do otherwise.

    The missing base is DevOps. It’s a unified strategy for Development and IT Operations, and implementing it can have the following effects:

    1. Communication Becomes Unavoidable

    Normally, Dev and Ops play “telephone” because they’re physically separated and have too many points of communication. Emails, IMs, grudgingly accepted meetings and passing conversations ensure Dev and Ops never get the full message.

    DevOps fixes communication by assigning Dev and Ops personnel to the same teams. They sit in one room and work in a single squad (a.k.a. a pod or team) of no more than eight to 10 people. If they turn their heads, they see each other’s beautiful faces. Until promotions or career change do them apart, they can’t avoid talking and working toward common goals.

    In essence, DevOps puts “cross-functional” teams together and thereby eliminates hand-offs. Fewer points of contact, less telephone, better communications.

    1. Collaboration Gets Automated

    For many Dev and Ops teams, “collaboration” is another word for bureaucracy. It’s TPS report-ish stuff characterized by change review board meetings and laborious documents that tell Ops how to deploy new code. Dev and Ops might accidentally (or intentionally) withhold information from each other.

    In DevOps, collaboration is automated. Instead of change review board meetings, you use version-controlled software. The hand-offs from Dev to QA and QA to Ops are done by machine. A script deploys the code for Ops so there’s no risk of misfiring.

    “Collaboration” is no longer an ordeal or choice. Documenting and sharing the squad’s collective knowledge is wired into the process.

    1. Fast and Stable Releases

    Normally, a software deployment is like a sloth trying to cross US 101: slow, awkward and soon to be roadkill. That’s all thanks to bad communication and bad collaboration.

    With DevOps, you catch problems before they go live. Test automation prevents any need for manual checks. One person corrects the problem in a matter of minutes whereas before, a team of five might spend eight hours tracking down and fixing one bug. Ops feels confident that tested code won’t cause havoc.

    Thus, the upshot of DevOps is speed and stability. Before, Dev and Ops delivered maybe a few times a year and faced regular breakdowns. DevOps can deliver multiple times daily without a hitch.

    Say ‘I Do’

    DevOps is a cultural, procedural and technological transformation. As in a marriage, both partners are responsible for good outcomes. Linked as they are on one squad, Dev learns to care about stability and Ops begins to value innovation.

    If “agile” is about making businesses nimble and quick, DevOps is about applying agile principles to technological development and operations. Ultimately, it’s about beating your competition to the next big thing.

    Dev, easy on the drinking escapades. Ops, live a little. Tie the DevOps knot and make some innovation babies.

    About the Author / Zubin Irani

    Zubin Irani is co-founder and CEO of cPrime, a full-service consultancy that focuses on agile transformations and project delivery solutions for hundreds of software teams, including more than 50 of the Fortune 100. Connect with him on LinkedIn.

  • Applying AI to Root-cause Analysis Webinar

    RECORDING

    SLIDES

    [slideshare id=75243643&doc=webinarloomai1125-170420191116]

  • How Cognitive Bias and ‘HumanOps’ Affect Dev Teams

    How Cognitive Bias and ‘HumanOps’ Affect Dev Teams

    Does your team take into account how the human element can affect development practices? It’s often overlooked, but critical to consider. Jason Hand of VictorOps, devopsy.kinsta.cloud’s Top DevOps Evangelist for 2016, writes and speaks on this particular topic often. In fact, he will be delivering a keynote titled, “Cognitive Bias and Its Impact on Continuous Improvement,” at the upcoming SauceCon conference, to be held June 6-8 in San Francisco.

    SauceCon, the first-ever Sauce Labs user conference, is a three-day event filled with training, workshops, best practices and visionary content from the leading minds in automated testing.

    “Cognitive bias is an important topic that is often left out of the conversation. The ‘HumanOps’ side of DevOps is a fascinating area to explore and I’m excited to get the conversation going for those in attendance at SauceCon,” he said.

    Jason aims to help attendees understand the most important cognitive bias to watch out for, as well as ways to identify it in ourselves and others. Particularly when managing service disruptions and time-sensitive problems, understanding where we make common mistakes will go a long way to improving our response to outages, as well as continuously improving over time.

    Jason serves as a DevOps Champion and advisor at VictorOps, where he advises on the future functionality and direction of the on-call and incident management platform, counseling the team on modern DevOps principles and new methods of delivering reliable software at scale.

    In addition, Jason advises the growing worldwide community of IT professionals including Colorado’s front range, where he helps to organize DevOpsDays Rockies and the monthly DevOps meetups in Denver. Co-host of “The Community Pulse,” a podcast on building community within tech, Jason is dedicated to the latest trends in technology, sharing the lessons learned and helping people continuously improve.

    In 2016, Jason was named “DevOps Evangelist of the Year” by devopsy.kinsta.cloud. He is the author of two books on the subject of ChatOps and a forthcoming O’Reilly book on post-incident reviews, as well as a regular contributor of articles to Wired.com, TechBeacon.com and many other online publications.

    For more on upcoming SauceCon presentations or to register, visit the SauceCon website.

    About the Author / Rebecca Cramer

    Rebecca Cramer is a writer and communications strategist specializing in technology. With more than 20 years of experience across disciplines including marketing, internal and executive communications at companies such as Dell and Quest Software, Rebecca is passionate about creating and sharing good content of all kinds. In her spare time, she enjoys spending time at the beach and hiking in her native Southern California.

     

     

     

  • ‘Big Bang’ DevOps: Posting from the Professor

    ‘Big Bang’ DevOps: Posting from the Professor

    I learned about The Diffusion of Innovation Theory in a DevOps Foundation training course. I wanted to get my DevOps certification, but more than that, to learn about what makes a DevOps initiative successful. When I mentioned the Diffusion of Innovation Theory to a coworker, he said, “It sounds like Sheldon talking to Raj on ‘The Big Bang Theory’ television series.”  Although the name sounds “Big Bang”-ish, the usage of this theory could be the real difference for success in any transformational change including DevOps.

    Let’s begin with the definition of DevOps. DevOps is a professional and cultural movement that that stresses communication, collaboration, integration and automation to improve the flow of work between software developers and IT operations professionals. Improved workflows will result in an improved ability to design, develop, deploy and operate software and services faster. That’s where this “Big Bang” or Diffusion of Innovation Theory comes in. DevOps is a culture shift.

    DevOps requires us to shatter the silos and to quickly integrate our teams to increase the flow of work from idea to end of life for the strategy, development, deployment and the sustaining of service over their life. Adoption of a new idea, behavior or product (i.e., innovation) does not happen simultaneously in a social system. It is a process whereby some people are more apt to adopt the innovation than others. Researchers have found that people who adopt an innovation early have different characteristics than people who adopt an innovation later. Learning what those characteristics are and then how to apply the proper technique for each will help with the management of organizational change.

    The Diffusion of Innovation is a theory that seeks to explain how, why and at what rate new ideas and technology spread. While most of the general population tends to fall in the middle categories, it is still necessary to understand the characteristics of a given target population.

    When promoting an innovation, there are different strategies used to appeal to the different adopter categories:

    • Innovators – want to be the first to try the innovation. They are venturesome and interested in new ideas. These people are very willing to take risks and are often the first to develop new ideas. Very little, if anything, needs to be done to appeal to this population.
    • Early Adopters – represent opinion leaders. They enjoy leadership roles and embrace change opportunities. They are already aware of the need to change and so are very comfortable adopting new ideas. Strategies to appeal to this population include how‐to manuals and information sheets on implementation. They do not need information to convince them to change.
    • Early Majority – rarely leaders, but they do adopt new ideas before the average person. That said, they typically need to see evidence that the innovation works before they are willing to adopt it. Strategies to appeal to this population include success stories and evidence of the innovation’s effectiveness.
    • Late Majority – skeptical of change and will only adopt an innovation after it has been tried by the majority. Strategies to appeal to this population include information on how many other people have tried the innovation and have adopted it successfully.
    • Laggards ‐ bound by tradition and very conservative. They are very skeptical of change and are the hardest group to bring on board. Strategies to appeal to this population include statistics, fear appeals and pressure from people in the other adopter groups.

    When promoting an innovation to a target population, it is important to understand the characteristics of the target population that will help or hinder adoption of the innovation. The Diffusion of Innovation Theory could be the “Big Bang” that you are looking for to ensure the success of your DevOps initiative.

    — Alice Acedia

  • ITV, Allianz, UK DWP and 2 Authors Take a ‘Deep Dive into DevOps’

    ITV, Allianz, UK DWP and 2 Authors Take a ‘Deep Dive into DevOps’

    On the heels of our latest DevOps Enterprise Summit London speaker and programming announcement, I had the pleasure of being joined by Tom Clark, head of Common Platform at ITV; Andrea Hirzle-Yager, head of Department, IT at Allianz Deutschland AG; Mark Schwartz, CIO and author of  “The Art of Business Value” and “A Seat at the Table“; and Mayank Prakash, Chief Digital and Information Officer at Department for Work and Pensions for a live video chat—already our third installment for 2017! We huddled up for an hour and took a “deep dive into DevOps,” as my fellow panelists shared keen insights into their technology transformation experiences and leadership lessons learned from pioneering DevOps adoption in their own organizations. And as you’ll find out, these are all such great people!

    WATCH THE REPLAY

    [youtube https://www.youtube.com/watch?v=lwBneJ-KnkA?feature=oembed]

    For a limited time only, you can receive 20% off the ticket price for
    DevOps Enterprise Summit London with code DEEPDIVE20.

    REGISTER HERE 

    Lessons Learned

    Clearly, one of the responsibilities of technology leaders in DevOps transformations is enabling a culture of continuous and lifelong learning. In fact, this characteristic is one of the more profound conclusions after having seen nearly 200 leaders share their stories over the past four years. And holy cow, if there’s a great time to learn, it is now; personally, I can’t overstate how much I’ve learned since co-authoring “The Phoenix Project.” (For example, in Dr. Steven Mayner’s DOES16 San Francisco presentation last year, he confirmed that this seems to be a critical element of successful transformation—you can see what we learned about the role creating a culture of learning and transformation plays in successful Agile and DevOps transformations.)

    These were among several questions that I had to privilege of asking Andrea, Tom, Mark and Mayank.

    • What will you be presenting on this year?
    • What can you share about what’s happened in your own journeys since 2016?
    • What can you tell us about your DevOps journey and technology transformation?
    • Can you tell us about where you decided to start, and why you chose there?
    • It’s been observed that DevOps transformations are easier in smaller organizations—what are the toughest obstacles that you’ve overcome as leaders in your journeys?
    • What are your favorite lessons learned that you think would be applicable for all leaders endeavor in to do similar things in their organization?
    • What are your favorite resources you look to (past and present) for leveraging the best practices and principles—this could be in the form of research, books, events, articles, etc.
    • Can you share you impressions of your two days at DevOps Enterprise Summit London last year?

    It was fantastic hearing the specific lessons they’ve learned in their journeys that they thought would be  applicable for all leaders doing similar things in their own organizations. It was interesting to hear how books and conferences play such a critical role for them, as it has for me—and I always love getting a glimpse of the bookshelves of technology leaders, because certain books keep keep showing up up again and again

    Be sure to watch the video replay of the chat—there are some great nuggets of information about where these leaders are in their own transformation journeys and what you as DevOps Enterprise Summit attendees can expect at the event this June.

    DevOps Enterprise Summit London Update

    Plenty has happened since our previous live video chat with Jonathan Fletcher, Cornelia Davis and Jonathan Smart. The programming committee has made its final selection of speakers to round out the conference program, and we’re in the final planning stages for the event this June. One item on the agenda that I am particularly excited about is the “Ask the Speaker” portion of the program. This year, we are opening up an hour of time each day of the conference for question and answer sessions between our plenary speakers and conference attendees. It’s going to be a great way for attendees to pick the brains of the folks just coming off of the main stage.

    Additionally, we have added another format (tested during DevOps Enterprise Summit San Francisco last year) that we called “DevOps Workshops.” These are small-group discussions using the Lean Coffee format, with a small army of trained facilitators at each table.

    We’re expecting a phenomenal turnout for each of these sessions and we’ll have some world-class people helping to lead the discussions. More to come on that soon!

    Want to join us in London this June? Save 20% on tickets using code “DEEPDIVE20” today!

    REGISTER HERE 

    We look forward to seeing all of you June 5-6 at the QEII Conference Centre, an amazing venue in the center of Westminster in London. Stay tuned for all the conference updates online at http://events.itrevolution.com/eur/.

    — Gene Kim

  • Self-Healing Service Management and the Future of DevOps

    Self-Healing Service Management and the Future of DevOps

    How can DevOps teams take continuous delivery to the next step? Part of the answer lies in self healing, which could optimize performance management and monitoring and underpin the software delivery pipelines of the future.

    Self healing means the ability of systems or environments to detect and resolve problems automatically. It eliminates the need for manual human intervention, upon which most systems today still rely to fix issues.

    Self healing is better than depending on humans for several reasons:

    • Automated solutions are less likely to miss issues by mistake, or to make errors when resolving them.
    • Self-healing technology is better positioned to fix problems faster than humans because it can react instantly based on rules or machine learning. It doesn’t have to stop and think about the issue before taking action.
    • A self-healing environment can scale without limit. This is a key advantage over manually managed environments, whose scalability is limited in some respects by the availability of human admins.

    Self Healing and Continuous Delivery

    DevOps teams already take advantage of many other kinds of automated tools to help achieve continuous delivery.

    They use continuous integration servers to automate tests. They adopt release automation tools to streamline deployment. They implement orchestrators and scripted infrastructure to provision environments automatically.

    Yet, when it comes to performance management and monitoring, the typical organization is a far way off from achieving a fully automated process. Even the best application performance management (APM) tools of today are primarily capable only of detecting problems and displaying information about them. They depend on humans to interpret and react to that information.

    That dependency is a major obstacle for achieving fully continuous delivery. You can’t release code quickly if your process for finding and solving problems related to the code is mostly manual.

    By making better use of self-healing technology, DevOps teams can speed continuous delivery in the following ways:

    • Developers and admins can spend less time on monitoring and more time completing other tasks that can’t be automated.
    • Ideally, teams will be freer to switch between development environments and frameworks without having to establish a new monitoring workflow. Self-healing tools will adapt to whichever environment they have to work with.
    • Because problems can be found and fixed faster, infrastructure utilization can increase. The need for a buffer between average usage and overload can become smaller because automated healing solutions will be able to fix problems before they lead to failure.
    • Teams can establish better continuous feedback loops because, by removing the human element from performance and monitoring, incidents can be reported instantly, consistently and in a way that makes the data easily accessible to everyone on the team.

    To be clear, the technology for self healing does not yet fully exist. Developers over the past several years have made great strides in automating configuration, service discovery and environment provisioning, But perhaps it’s time to make them a more prominent focus. They’ll enable the DevOps innovations of the future.

    — Chris Tozzi

  • The devopsy.kinsta.cloud Application Performance Management Leadership Links Guide

    The devopsy.kinsta.cloud Application Performance Management Leadership Links Guide

    Businesses today are largely defined by the applications they run. And to stay competitive enterprises must continuously update their software and performance issues must be identified and solved swiftly.

    This drive toward more rapid software iterations and enterprise development and IT management efficiency is one of the biggest reasons why more companies have embraced DevOps and continuous integration and deployment pipelines.

    But how do enterprises make certain they can continuously deploy and delivery new software apps and features and not inadvertently impact user experience? Precisely how are mistakes and failures, or app performance issues quickly identified and remedied? How are application issues managed so that there aren’t costly outages or development teams aren’t getting texts in the middle of the night for emergency software change requests? This is where application performance management (APM) comes in.

    According to the market research firm Markets and Markets, the APM Market is expected to reach nearly $5 billion by 2019, up from $2.72 billion in 2014.

    There is a significant intersection between DevOps and application performance management. It’s also essential for application management teams, development teams and operations teams, and needs to be integrated in many DevOps processes. In this devopsy.kinsta.cloud Survival Guide, we provide resources to help you to get the skinny on using application performance management to help more tightly integrate Dev and Ops, find the right APM tools and successfully manage today’s more complex environments with application performance management.

    APM Prepares Prep Sportswear for Promising Growth – devopsy.kinsta.cloud

    In this story, David Geer looks at how custom sportswear vendor Prep Sportswear is using APM to prepare for growth

    14 Tools That Raise Web and App Performance – devopsy.kinsta.cloud

    Asaf Yigal lists his 14 Tools That Raise Web and App Performance

    Gartner Evaluates APM Tools for DevOps – devopsy.kinsta.cloud

    Grab this Gartner report on APM toolsets.

    5 Ways APM Can Solve Your DevOps Worries – devopsy.kinsta.cloud

    To have tight control over Devop’s environments we need APM at every step, contends this post by IBM’s Payal Chakravarty. APM can help break down the Chinese wall between Dev and Ops and eliminate the finger pointing that happens during outages. Here he lists five APM best practices to enable a smooth DevOps working environment.

    Continuous Monitoring: The Role of DevOps and APM – devopsy.kinsta.cloud

    IBM’s Arun Biligiri discusses the intersection of DevOps and APM.

    APM On-Premises or SaaS: What’s the Best Fit? – devopsy.kinsta.cloud

    Which APM deployment option makes most sense for your organization? There‘s no simple answer to this question. A lot depends on your environment and requirements. This post explores the points to consider in deciding between SaaS and on-premises monitoring.

    Webinar: Using APM to Turbocharge Continuous Integration – devopsy.kinsta.cloud

    Check out this Webinar with CA Technologies and CloudBees to learn how APM can Turbocharge CI.

    Can Your DevOps and APM Initiatives Increase Customer Loyalty?

    Can APM help to increase customer loyalty, CA’s Peter Waterhouse thinks so.

     

    — George V. Hulme