Tag: ChatOps

  • Everything Ops: Are DevOps Principles Being Applied Too Broadly?

    Everything Ops: Are DevOps Principles Being Applied Too Broadly?

    From big data to storage to security, the DevOps concept is being applied to every field of IT operations under the sun today. This “Everything Ops” movement reflects the popularity of DevOps—but is it also diluting DevOps’s significance?

    DevOps itself focuses on software delivery. It’s about designing, building, testing, deploying and managing software applications.

    If you follow the DevOps conversation, however, you know that DevOps principles are now being extended to lots of niches that don’t have much or anything to do with software delivery chains. Consider these examples:

    • DataOps: DevOps principles for data analysts.
    • ChatOps: The idea that chat tools should be integrated into workflows.
    • SecOps (or rugged DevOps, or DevSecOps, or whatever else you want to call it): DevOps practices for security teams.
    • Storage Ops: The insertion of DevOps practices into storage.

    The list could go on. Taken together, these many flavors of DevOps reflect what I like to a call an “Everything Ops” tendency. Fans of DevOps want DevOps to take over the entire world of IT.

    Benefits and Drawbacks of ‘Everything Ops’

    If you believe that DevOps represents a better way to deliver software, then the Everything Ops movement is a positive thing. It’s a way to help people who work in areas of IT other than software delivery to innovate as well by taking cues from their DevOps colleagues.

    But there is also a danger that Everything Ops can be applied too broadly. You can’t fit every single thing in the IT universe into the DevOps mold. For example, CloudOps (the DevOps-related way of managing cloud infrastructure, not the company of the same name) just doesn’t make a lot of sense. It’s basically just a reiteration of the ideas that are already at the core of cloud computing: Scalability, agility and location-agnosticism.

    Concepts like ChatOps can also be problematic because they refer to a specific way of using a particular type of technology, whereas DevOps is about cultural practices. ChatOps is a fundamentally different sort of thing from DevOps.

    Conclusion

    In short, by overextending the DevOps conceptual framework, you run the risk of diluting the importance of DevOps itself—and of losing your focus on software delivery, which is the area that DevOps benefits most.

    This is not to say that we shouldn’t extend DevOps to other fields. We certainly should. But we should be careful when doing so. Don’t try to make DevOps eat the entire IT world, because that just doesn’t make sense.

    — Chris Tozzi

  • 4 Essential Practices to Succeed at ChatOps

    4 Essential Practices to Succeed at ChatOps

    We know enterprises are embracing messaging apps and incorporating so-called “ChatOps” into their workflow. ChatOps is, potentially, a powerful way to facilitate more swift decision-making and problem-solving and to receive quick, expert guidance. “With the rise of cloud services that can be easily deployed, and increased awareness and importance given to productivity and collaboration within the workspace, enterprise chat is gaining priority,” says Narain Muralidharan, a market analyst at online customer support software and help-desk software maker Freshdesk.

    As most readers are aware, ChatOps has been fueled by the growth of tools such as HipChat, HuBot, Slack and others for chat-style and instant collaborative software development and project management. But these tools also execute scripts and automate tasks and get workflow approvals to deploy code, kick off software tests and more. As an added bonus, within the chat application exists a clear record of all discussions and scripts executed—something very handy for root cause analysis and troubleshooting.

    With all of that in mind, how are enterprises embracing chat?

    Chatting Down Silos

    “At Threat Stack, we’ve long embraced Slack as a collaboration tool that removes silos within the organization and helps busy operations teams to move quickly and have a fully informed view,” says Pete Cheslock, senior director of Ops and Support at Threat Stack. “We’re seeing this migration toward ChatOps with our customers.”

    Bhaskar Roy, head of growth at Workato, sees chat being embraced at companies ranging from small businesses to Fortune 500 firms. “There are groups in large enterprises who are adopting different chat products and are always looking for what they can do to make chat the center of all communication. When we talk to these companies we find that they believe that chat is a more natural, human, fast way to communicate—which can help in getting things done faster,” Roy says. Chat, he adds, is becoming a “command center for business apps. [Organizations] are using chat to get information from various applications and are looking for ways where they can easily interact with the application from the comfort of their chat/conversational interface.”

    According to the most recent VictorOps State of On-Call survey, ChatOps continues to grow, with 40 percent saying they practice ChatOps during event remediation. That’s up significantly from 28 percent last year.

    Getting the Most Out of ChatOps

    With the tremendous growth in ChatOps, what practices have enterprises learned to bring the most success? Below we list the four essential practices that will help organizations succeed in their ChatOps engagements:

    Embrace adoption: “The main problem that enterprises have in chat penetration internally is adoption. People are resistant to change, and it is usually difficult to change user behavior, especially in the way people work every day,” says Muralidharan. “Some practices are set in stone, like emailing or the good old face-to-face meetings. Start small with pilot teams, get buy in, and create evangelists within the company. A lot can be gained by having a top-down approach to adoption; hence, management buy-in is very crucial.”

    Fine-tune notifications: “The biggest problem that we see is that bots and app notifications that are being pumped into the chats today are making things very noisy, resulting in loss of productivity overall,” says Roy. “What we believe is needed is utilizing bots to enhance the overall individual productivity, where people are notified only for things that are urgent, relevant and something that they need to act on right away. And bots are intelligent so that they understand and learn based on user interactions and are proactively prompting / helping as and when required.”

    Adopt a DevOps mentality: Eric Sigler, head of DevOps at PagerDuty, suggests that “to make the most of chat within your enterprise, it is important to adopt a ‘DevOps mentality,’ where individual teams are more responsible for, and empowered to maintain, their own services. Without this, it’s too easy for teams to ‘throw things over the wall’ and for ChatOps-based tooling to remain restricted to a limited set of users.

    “Existing infrastructure teams need to be a part of this ride as well,” he adds. “If they don’t take the time to understand how their engineers—their user base—want to interact with the tooling and invest in ‘making the easy things easy, and the hard things possible,’ then ChatOps-style tools will get relegated to shiny demos with little practical utility.”

    Avoid DevOps fatigue. Chat alerts can be nagging distractions throughout the day, sucking worker concentration and clamoring for their time. “Customizing notification preferences in your chat client can help enterprises reap the benefits of chat. By personalizing notifications, it ensures that they see the most important chats and are accessible when it matters, but still have the ability to focus without being disrupted by constant pings,” Sigler says.

    What Does the Future Hold for Enterprise Chat?

    What does the future of ChatOps look like? Most of the experts we spoke with say it’s bright. “In an age of digital transformation where slow is the new down, conversationally driven interaction with software is going to play an important role for collaboration and increased agility,” says Sigler. “Overall for founders, hackers and investors, there’s room to innovate when it comes to humans and bots, and there’s a lot of really poor user experiences and bad workflows out there that can be improved by thinking about them through the constraints chat provides.”

    — George V. Hulme

  • Continuous Delivery: The Atlassian Way

    Continuous Delivery: The Atlassian Way

    Sonatype’s Mark Miller (@TSWAlliance) caught up with Ian Buchanan (@devpartisan) for our 2016 DevOps Leadership Series. Ian discussed his experiences at Atlassian, including continuous delivery, ChatOps, and use of tools such as Bamboo, Nexus, Puppet and Datadog.

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

    Buchanan: I’m Ian Buchanan. I’m a Developer Partisan at Atlassian, which is developer advocacy for our developer tools.

    Miller: Ian, most people know Atlassian from solutions like JIRA and Bitbucket.

    Buchanan: Yeah, I focus mostly on Bitbucket and Bamboo. Bamboo’s our continuous integration and deployment tool.

    Miller: Good. One of the subjects we talked a little about at dinner last night is how Atlassian is using Nexus. Can you give us some background on that?

    Buchanan: Yeah, that’s right. Well, we’re a big Java shop. We have been for a very long time and have a lot of Maven dependencies for external reasons; we also store a lot of our own internally developed libraries in our Nexus repository.

    _________________

     We’re a big Java shop. We have been for a very long time … we store a lot of our own internally developed libraries in our Nexus repository.

    _________________

     Miller: As far as a binary repository, are you using it for anything other than components?

    Buchanan: Not that I’m aware of. I know that we’ve recently started to get into Docker quite a bit and Nexus is a good fit for that as well. I don’t know the extent which we’re using Nexus for that purpose yet, as Docker’s still quite new for us.

    Miller: What does your continuous integration pipeline look like?

    Buchanan: It certainly varies by product in the details. Of course, we have our own continuous integration product, Bamboo. Bamboo is the most pervasive tool we have.

    For the Java stuff it’s pretty simple pipeline where libraries get built and published into Nexus so that they can be used downstream. We also have some interesting, newer cloud products that are built with Python. A lot of the deployments, whether they are Java or Python stuff, are handled by Bamboo’s deployment projects. They pull artifacts from Nexus and put them into production.

     _________________

    A lot of the deployments, whether they are Java or Python stuff, are handled by Bamboo’s deployment projects. They pull artifacts from Nexus and put them into production.

     _________________

    Miller: Are you guys using continuous delivery in house for your workflow?

    Buchanan: We’re in an interesting position that I think I see a lot of companies in. We have some behind-the-firewall products (our server products) and then we also have cloud products. In the cloud side, continuous delivery is used when we want to go very fast. But we also have to balance that with the approach we take for our server products so that they don’t fork terribly. We have continuous delivery up until there’s a product delivered. At that point, there is another kind of pick up—where the cloud products engage with other things like Puppet and Ansible to configure the environments with products that other people can pick up and run on premises.

    Miller: I was talking to your team in San Francisco. How are you guys using ChatOps with HipChat?

    Buchanan: I’ve been talking about ChatOps for quite some time. We do a lot of very interesting things with ChatOps. They play a very important part of our continuous delivery pipeline in that we publish build results in there. People can see when pull requests are ready and check those out. We get to see what’s happening from production as well. We have integration with Datadog; it tells us some of the monitoring things that are going on. It’s not just information coming into the chat room. There are also commands that folks can issue to make the continuous delivery pipeline move along. There are certain stages where you can type a command to our ChatOps and they will perform the necessary actions. Much of the deployment and change management happens in a ChatOps context.

    _________________

     There are certain stages where you can type a command to our ChatOps and they will perform the necessary actions. Much of the deployment and change management happens in a ChatOps context.

     _________________

     Miller: Anything coming up in the future you guys are working on that’d be fun?

    Buchanan: Well, a lot of the innovation really happens at our quarterly “Ship It” events. That’s where our developers spend 24 hours doing whatever kind of innovation interests them. A lot of time is spent scratching an itch they have. Some of the things that I saw there were about having more information coming back upstream, not just into the chat rooms, but into JIRA where more of the longer-term tracking is going on. They’re experimenting a lot with putting more information into JIRA.

    Miller: Nice. Final question, if you were going to be a superhero, would it be Dev, Sec or Ops?

    Buchanan: I’ve played Dev roles and Ops roles and I almost feel like I know those much more. But from a lot of the sessions at DevNexus, I have to feel like Sec is the superhero. They’re the superheroes because they solve some unsolvable problems in a lot of ways. But I don’t feel ready to play that role at the moment, myself.

    Miller: It’s interesting. I agree with you that they are unsung heroes. Most of the time they just get hammered for what they’re doing.

    Buchanan: That’s true. Yesterday I was in a session about securing REST endpoints. The speaker went through problems with BASIC off , DIGEST off and J2EE—all of these things which we use in our products. At the end we’re left with, “What is the answer?”

    Well, the answer is that for each of these, there are different problems. So we have to identify the right context. We have to understand where some things are broken, know that those things aren’t perfect, and design for that imperfection. That’s a mindset that we have to carry through dev, ops and sec. I hope more security folks step up and start telling those stories.

  • In-App Messaging: The Key to a Better User Experience

    In-App Messaging: The Key to a Better User Experience

    As the mobile device obsession grows, enterprise IT departments are learning the hard way that today’s Web applications, will in fact, not live forever. Enterprise developers are now forced to turn their focus to mobile app development – not just repurposing a Web API for mobile, but embracing what is inherently different about the mobile platform.

    Mobile isn’t just a smaller screen size, but for companies, it’s a whole new device for interacting with stakeholders in real-time. With in-app messaging, brands now have a powerful new channel to foster a private conversation between themselves and their customers. Further, companies can leverage data directly from interactions in the app to create more authentic and beneficial messages for the customer.

    Using in-app messaging has a big pay-off for brands, too. According to a June 2015 report from app marketing and analytics firm Localytics, apps engaging in messaging have a two to three-and-a-half times higher retention rate and more uses per month than apps not using in-app messaging.

    But for even the most experienced enterprise developer, integrating new features in a mobile application can be a tough process. The technical challenges alone can be too much for an in-house IT department, and developers could be stuck scratching their heads due to a lack of replicable use cases. We believe there are three simple steps that a developer can start with to incorporate in-app messaging to help build the foundation for a dramatically improved and far more engaging mobile user experience.

    1. The simplest in-app messaging application is using chat as a help feature. Imagine on-demand customer service from the palm of your hand – in store or in the comfort of your home. Think about how direct communication can improve customer experience. Is there a glitch in the app hindering the use of a feature? A question about an in-app purchase or pricing on a product in store that can be answered in the moment? There are many current scenarios that could be supported by using chat as a help feature, but the real possibility is in things that aren’t common today. Picture connecting chat to an in-store server, and joining a real customer service specialist to a customer needing assistance within minutes. Perhaps one day, in-app messaging could replace customer service calls all together.
    1. Another great way to utilize in-app messaging is by using chat as a way to share announcements. Instead of focusing on creating a private conversation between just two parties, sharing an announcement via chat is great way to spread communications to a group of people within an app. Share information about an upcoming event or sale, or send a cancellation update immediately (eliminating the frustration from those who didn’t check their email or voicemails!). And think outside of the box – these announcements don’t need to be text string, but rather HTML, JSON or images. Think about this as a push notification, but more personal and intuitive. However, while you may want to share announcements with all users, like a push notification, be aware that these messages can seem less targeted, like getting spammed. Alternatively, use a messaging platform that can sift through backend data to grab the intel required to customize announcements to specific audiences, all on its own.
    1. Finally, evolve your messaging a bit further by sharing images or content through chat. Facebook and WeChat are great examples of how to create more context within in-app messaging: share a link using in-app search or send animated emoticons to create sentiment. And again, think beyond a personal conversation, but how to engage a whole group. Perhaps you drop a pin on Google Maps and direct a group to a certain location or share a digital coupon to a set of customers. And while smaller images can be sent as binary payloads across the messaging transport, developers should consider size and performance implications and may want to use a different approach. There are even ways to use a URL in the message payload to transfer any kind of file (including an image!). The key to engaging customers with this feature is with powerful insights: integrate with different workflows and data using an end-to-end tool to deliver meaningful content to individual users.

    These use cases could seem like simple additions or advanced ideas depending on the current state of your mobile app, but either way, they’re just the tip of the iceberg.

    The ever-evolving mobile world full of consumers seeking cooler, better, faster mobile experiences means one thing for enterprise developers: change. We must move beyond the traditional thinking to consider not only app design, but how users want to interact with their apps, and what value new features add for customers.

    Whether you’re starting out with chat as a help feature or shooting for the stars with another intuitive messaging tool on the horizon, it’s safe to say the future of in-app messaging will be transformational for user experience.

    About the Author/Shannph Wong

    UntitledShannph Wong is the Head of Engineering at Magnet Systems. Magnet Systems is powering the next generation of mobile applications with an open architecture to enable businesses and developers to create more engaging and productive enterprise-class mobile applications.

  • The Pros and Cons of Remote Work in Ops

    The Pros and Cons of Remote Work in Ops

    Remote work in Ops is divisive. The perks of working from home, your local coffee shop or wherever can be quite obvious to engineers and contributors. But some team leaders and company execs aren’t buying into it. One faction sees it as a way to do better quality work. Another has watched deadlines and motivation fall by the wayside because of unresponsive remote workers.

    What are the advantages and disadvantages of remote work? What should you consider before you take the plunge into flexible hours and asynchronous communication?

    Why Do Companies Go Remote?
    Company leaders worry that remote work erodes culture. Workers fret that colleagues and reports don’t get enough done outside the office. And team leaders lose sleep chasing down time-sensitive updates and deliverables.

    Remote work can definitely present some challenges. So, why do companies go remote? Several find it can provide serious benefits when implemented properly.

    By considering remote workers, businesses are able to attract high- quality talent from a larger pool of candidates – that’s especially important in the technology and software world where recruiting top-notch engineers is often a company-level initiative. If your company is based in a geographically competitive market, this opens doors and extends your reach to premier candidates outside of that area. It also goes the other way around – engineers who don’t live in tech-focused cities are given opportunities to be a part of those companies and cultures and aren’t penalized simply for where they live.

    Some contend remote policies produce better work. GitHub argues that code doesn’t follow a 9-to-5 schedule. Remote work can enable engineers to write great code during their peak hours of energy, focus and productivity, rather than on a set schedule that doesn’t play to their strengths. Because all employees – and engineers – are different, remote work provides the option to hone that creativity and focus outside of normal working hours.

    Since we’re so used to operating online, both in our work and personal lives, remote work embraces that to make employees more efficient. Remote workers communicate asynchronously.In other words, they respond to messages and transcripts when it makes logical sense, without interrupting serious tasks or disrupting intense focus. Another plus taking communication online is that it naturally leads itself to fewer meetings, and more doing. You’d be surprised how much you can cover in a three-minute chat via Skype, Slack, Campfire or another communication tool.

    That’s to say nothing of fostering a more enjoyable work environment. Plenty of people believe remote work improves morale. Who doesn’t want to work flexible hours and code when they’re in the zone?

    Finally, remote work supports inclusivity and diverse teams. What are the chances that every single person who can meaningfully contribute to your company just happens to live within a short commute? Not only do distributed teams open up opportunities for skilled workers who live outside of tech hubs, they also make it easier for people to work around family and other obligations.

    For some close-knit teams, there’s no difference between chatting in Google Hangouts and meeting on-site in a conference room. Going remote helps everyone get more done, more efficiently and on their terms.

    How Do You Get Started?
    Remote work may not be for every company. Your business needs or culture might not work best in a distributed environment. But if you do want to give it a try, there are some basic ways to start.

    Using the right tools is key. 37signals, the company behind Basecamp, literally wrote the book on remote work, and most of their team works remotely, using the company’s Campfire chat client to aggregate company communications and keep everyone on the same page. Email works for some conversations, but project management tools like Asana, Trello, Basecamp and JIRA let you add state, metadata, and delicious permalinks to everything that needs to get done.

    Be judicious about which tools you pick, though. Text, video and voice all have pros and cons. You’ll need to use communication channels that make sense for your company’s work style. For instance, when teams that are used to face-to-face stand-ups switch to typed messages, there can be miscommunication and misinterpretation. You’ll get more value out of the tools that enhance your in-office interaction methods. You might have to adopt several tools for your needs: The developer team at Hanno, a user experience company, uses nine different tools to work remotely, including Basecamp, Slack and Google Hangouts.

    While tools are important, they’ll only take you so far. You need to develop strong foundational relationships among teams, colleagues and management before implementing remote work policies. In-person relationships set the tone for remote ones. Try to grab a beer or lunch with your colleagues – it will help form healthy relationships and ensure remote work is truly effective. If your team is completely distributed, try to get together once every quarter or two to reconnect, put faces to Slack handles, and build culture. The plane tickets and hotels may seem a little pricey, but they’ll pay off in productivity and morale.

    And as with many other tests, start small first. Maybe you have a smaller engineering team that’s used to working this way already – let them test drive with a couple days per week so one piece of the company has a chance to hash things out before rolling out more widely. As GitHub points out in this post on how the company works remote, if something doesn’t work, just ditch it in favor of something that does.

    What Should You Consider When You Go Remote?
    Just because everyone’s excited to go remote doesn’t mean you have a bright out-of-office future ahead. Remote work comes with its fair share of challenges and considerations.

    If remote work isn’t ingrained into company culture, problems won’t be far behind. Projects can be delayed because dispersed teams aren’t used to communicating in a timely fashion with out-of-office colleagues. Discontent might simmer if in-office workers view remote teams as slackers. Subcultures can also easily form among remote and non-remote employees.

    Communication presents another daunting obstacle. Teams outside the office might over-communicate, while on-site workers bristle at a deluge of messages. Conversely, remote workers might fail to communicate enough, furthering the perception they’re not getting much done. As mentioned at the USENIX LISA 14 conference remote work panel, refrains of “your team’s never in the office” might become all too common.

    In the end, interpretation matters. For remote policies to work, employees in-office and outside need to understand that they’re both working hard toward a common goal, even if their methods differ. But that doesn’t happen on its own: you need to implement the tools, processes and culture to make it a reality.

    The bottom line is that remote policies work for some organizations and not others. What matters is finding a sustainable organizational culture that leads to business success, whether you do it from behind a desk or at home in your pajamas.

  • eHarmony finds its perfect match with PagerDuty and DevOps

    eHarmony finds its perfect match with PagerDuty and DevOps

    Did you know that 4% of all marriages in the US are the result of people “finding their perfect match” on the eHarmony service? Keeping the systems that are making all of those matches up and doing it 24/7/365 is no easy task. Especially at peak load times like Valentine’s Day for instance. The pioneer in making online relationships relies on many DevOps tools including PagerDuty to minimize downtime and keeps its relationship science systems humming along.

    1672a00I had a chance to speak with Hav Mustamandy, Director of System Operations at eHarmony. Since Hav joined the team there about 7 months ago he has been busy modernizing the eHarmony network using a lot of tools that you would expect. They are a big Chef shop for example. PagerDuty is another tool they lean on a lot. More than tools though Hav has been instilling a sense of team between his Dev, Ops and QA teams.  In a short period of time, Hav has made tremendous progress in making the eHarmony IT business more responsive, reliable and faster.

    Frankly, why shouldn’t eHarmony act more like a Unicorn anyway? After all they are a web based business like many of the companies that we think of as being so successful. But before Hav came it was not necessarily so.

    Upon arriving he had to evaluate everything and everyone and start doing things differently. One of those things was the way they use PagerDuty. More than just an update to the old pager, Hav realized that PagerDuty could help him automate their incident resolution processes. Additionally using PagerDuty’s advanced analytics reporting, Hav was able to pinpoint problem areas in both systems and people. With the problem systems he was able to upgrade or change them. With people he realized where re-training was required.

    As a result Hav has seen some amazing results. The uptime of eHarmony’s systems even during peak load times has improved significantly.  Technical issues are identified and dealt with before they rise to critical levels.

    By leveraging APIs that PagerDuty makes available Hav has integrated several of his other systems into PagerDuty so he can gain insight into their performance as well. To him this is the future. Event management with PagerDuty at the core is what he is aiming for.

    For me PagerDuty and ChatOps applications biggest advantage is the ability to move inter-team communications into hyper-speed. If you are relying on email for communication it is probably not fast enough to keep up with your business.

    We have been using Slack here at devopsy.kinsta.cloud for ChatOps and I can tell you that our communication now moves so much quicker than it did when we communicated strictly through email. However, the discussion I have had with my team is if we are just chatting, what is the advantage of Slack to just google messenger or something like that?

    I think the answer lies in integration. Using APIs we should see more than just chatting going on with ChatOps. Systems will communicate with us in real time as well. This is so much more than chatting on a messenger client.

    The name of the game whether it is the dating game, the online media game or whatever game you play is doing it faster, better and with less downtime. For eHarmony it looks like they have “found their perfect match”.

  • Confident Financial Solutions is cutting edge with ChatOps for log monitoring

    Confident Financial Solutions is cutting edge with ChatOps for log monitoring

    cfs-logo-retina-c0cdab06f0c380b5877a5bf0c779acafIf I told you a company named Confident Financial Solutions is on the front line of adopting DevOps methods to better serve their customers you might say, “Come again?”  Let’s face it Confident Financial Solutions doesn’t sound like the type of company that would be stretching the envelope of technology. But don’t let the name fool you.  Confident Financial Solutions is a web-based SaaS auto repair loan company and part of the Boulder startup scene. Tech is in their DNA as much as finance and cars are.  So the fact they are using ChatOps to monitor and alert based on their logs should not be suprising.

    What CFS does is offer consumers instant approval on auto repair loans. If your car breaks down and the bill is more than what your budget can handle right now, they allow you to finance the repair. Using a web app interface the entire process is handled online. In that regard they are no different than many other SaaS based apps. So why shouldn’t they use the latest and greatest tools.

    Among the tools they use are Slack for ChatOps and Logentries for log and analytics. Using Slack really sped up the communication among the team according to Kyle Lamy, lead software engineer at CFS. So much so that the email alerts and information generated by their cloud based log management system actually slowed the team down.

    Lamy says that communicating via email versus Slack was just dragging everything down. Email with its long threads and back and forth was just not operating at the speed that CFS business demands. Also switching back and forth from email to Slack was a major time drag. He lobbied both Slack and Logentries to integrate.

    Slack and other ChatOps programs of course recognize that the value they deliver is tied to APIs and integrating with 3rd party tools. Otherwise they are little more than instant messengers.  That is the real pay off for ChatOps. Slack is hard at work with API development as well as acquiring new features.  They just announced that they have acquired Screenhero, a YCombinator spawned screen sharing app that will be integrated into Slack. At virtually the same time it was announced by Logentries that they were now integrating with Slack as well.

    In my conversation with Lamy he said having Logentries alerts and analysis in Slack allowed the team to stay in one tool and more importantly put the responsiveness of his team up to warp speed compared to email.

    Kyle says he sees even more ways that ChatOps applications can integrate with other tools to continue to accelerate team performance. He has already given both Slack and Logentries suggestions on things to do to make the integration even better.

    Based on Kyle’s recommendation I signed up and have set Slack up here for our devopsy.kinsta.cloud team. Being virtual and spread out ChatOps has immediately helped. I set up several different groups so as not to overload the entire team and we are already using it. For ongoing communications it is just so much more efficient than long email threads. It really is a no brainer.

    So if you are not using ChatOps at your company what are you waiting for? Go download Slack for free and give it a try. If you don’t see how it helps please tell me why not.