devopsy.kinsta.cloud

Tag: devops

  • Q&A: Sematext’s Thies on Docker Monitoring, Part 2

    Q&A: Sematext’s Thies on Docker Monitoring, Part 2

    In part one of my conversation with Stefan Thies, Sematext DevOps expert. we spoke about Docker’s use of Sematext Logsene logging, anomaly detecting and alerting software and SPM monitoring software. Let’s continue the conversation.

    David Geer: What makes Logsene centralized? Where is it centralized a typical deployment? What are the advantages of it being centralized?

    Thies: Traditionally, systems store logs from multiple applications on every server. This makes it difficult to search logs for troubleshooting or auditing purposes. To find a relevant log entry, operators must log in to each server, find the right file on this server and search in this file for a relevant message.

    This can easily take several minutes. With systems storing logs on multiple servers, it is difficult to correlate data, so minutes can turn into frustrating multi-hour root cause-hunting sessions, often involving multiple team members. Logsene provides a central full text index for all log data coming from multiple servers and applications. There is no need to log in to multiple servers and search/grep multiple log files. All team members see all data at the same time and can collaborate much more efficiently.

    Having a central place for search makes it much easier to find logs quickly, run analytic queries or centralize alert rules in a single place.

    Geer: What is it about what Logsene does for Docker logging?

    Thies: Sematext Agent for Docker interacts with the Docker API to automate the collection, parsing and processing of logs, metrics and events. It detects containers automatically (no setup or configuration for a new container!) and supports many log formats for applications on Docker Hub such as Nginx, Apache, Elasticsearch, Solr, MongoDB, MySQL and many more.

    Geer: What does your statement mean, “Some DevOps engineers even think of Logsene as ‘ELK Stack on steroids’”?

    Thies: The ELK Stack is a combination of open source tools: Elasticsearch, Logstash and Kibana. These tools are very popular for log shipping (Logstash), indexing and search (Elasticsearch) and visualization (Kibana dashboards). However, these tools are missing many enterprise features like multiuser user interface, role-based access controls, secure transport of logs or out-of-the-box configurations and an easy query language to search logs. This is where Sematext Logsene adds the relevant enterprise features to these open source tools to make them easy to use and securely integrated into the enterprise information technology infrastructure.

    Maintaining Elasticsearch clusters is another problem for many people. It requires a lot of expertise. Using Logsene does not require this sort of expertise. The Logsene SaaS provides a managed solution where users don’t need to know anything about maintaining Elasticsearch clusters or the required infrastructure. Sematext takes care of that for them. Sematext customers can benefit from these managed services and pay a fraction of the cost compared to self-hosted ELK stacks, where storage, computing and networking infrastructure and manpower for highly skilled workers counts.

    Geer: What is Tutum? What is so important about ease of launching SPM and Logsene Docker on Tutum?

    Thies: Docker acquired Tutum in 2015. Tutum provides management of Docker containers as a cloud service. Tutum is a platform made to operate “Dockerized” application stacks. In the case of Sematext Agent for Docker, the Tutum integration deploys Sematext Docker Agent automatically to all cluster nodes in a few seconds. These nodes could run on different cloud platforms such as Amazon, Digitalocean, Rackspace or on premises. Again, a big time-saver for people running larger infrastructures or hybrid clouds. Supporting Docker products and having excellent integration with Docker products is important for Sematext.

    The Sematext Docker Agent runs on all solutions offered by Docker e.g., Docker Swarm and others such as Google Kubernetes, Google Container Engine, RancherOS, CoreOS, Amazon ECS or Hashicorp Nomad.

    Geer: Please discuss the Sematext Docker and Docker image?

    Thies: Sematext Docker image is available on Docker Hub, and we shared the Tutum Stackfile for Sematext Docker on Stackfiles.io. The easiest way to get it is to use Sematext, which generates the stackfiles for you, including tokens.

    Docker Hub is the central registry for public application images including related installation instructions. Docker users can find out quickly how to run a “Dockerized” application with the help of the instructions in Docker Hub. Typically, this requires a little configuration work before a container can be started with the right settings.

    Stackfile.io is the place where people share preconfigured application stacks (e.g., a web service together with the required database). Sematext provides a preconfigured setup for Sematext Docker Agent to monitor all containers in Tutum Cloud. This means one can launch Sematext Docker Agent and monitor all containers running in Tutum Cloud with just a single click for the chosen stack file and by entering a unique identifier (Token) for the application. That is really all it takes.

    When you log in to Sematext SPM or Logsene the general installation instructions have all required configurations displayed. Sematext users can simply copy/paste the relevant commands including unique identifiers (tokens) for their application to get the Sematext Docker Agent deployed. This, too, is a big time-saver for our users and it gets them up and running in just a few minutes.

  • RightBrain Networks Appoints Hemant Kishan As Chief Operating Officer And Dave Thompson As Chief Technical Officer

    RightBrain Networks, a software development and cloud consulting firm, today announced that Hemant Kishan has been promoted to Chief Operating Officer (COO) and Dave Thompson has been hired as Chief Technical Officer (CTO). Previously serving as CTO, Jamie Begin has assumed the CEO role and will continue to set the vision for the company.

    Ann Arbor, MI (PRWEB) May 06, 2016

    RightBrain Networks, a software development and cloud consulting firm, today announced that Hemant Kishan has been promoted to Chief Operating Officer (COO) and Dave Thompson has been hired as Chief Technical Officer (CTO). Previously serving as CTO, Jamie Begin has assumed the CEO role and will continue to set the vision for the company.

    Begin said, “Establishing an executive team is a significant step in our growth, and the fact that Dave and Hemant have chosen to continue their careers at RightBrain Networks is a testament to what we’re doing here.”

    Both Thompson and Kishan bring long and distinguished technology careers to RightBrain Networks. Prior to joining the company in May of 2015 as Vice President of Client Engagement, Kishan was the Director of Emerging Technology for General Motors, where he was responsible for enterprise strategy, IT transformation, and program management. Kishan’s previous experience also includes serving as early employee and eventual Vice President at Sapient and Senior Software Engineer at Digital Equipment Corporation.

    RightBrain Networks is also thrilled to welcome Ann Arbor native Dave Thompson to its executive team. Dave has a proven track record of building, motivating, and retaining top-performing systems engineering teams. Dave’s professional background includes increasingly senior roles at industry-leading tech companies including Netflix, where he was one of the first hires on their Cloud Operations and Reliability Engineering (CORE) team. Post Netflix, Thompson held senior technical leadership roles at several other high-growth startups.

    These changes establish an executive team for RightBrain Networks – just one sign of the company’s maturity. It is also experiencing record growth. At the end of 2015 RightBrain had 23 employees with a goal to reach 40 by the end of 2016. As of May 2, RightBrain has increased to 30 employees and is still actively growing with several vacant engineering positions. Begin now expects to exceed 40 employees by the end of the year.

    RightBrain, which was recently awarded Michigan 50 Companies to Watch by Michigan Celebrates Small Business (MCSB), attributes this phenomenal growth to the overall global adoption of the cloud. According to IDC, spending on public cloud IT infrastructure will increase by 14.1% in 2016 to $24.4 billion.

    “Our experience and expertise are also contributing factors, as our engineers have a diverse skill set and have built an excellent reputation executing many projects,” said Begin.

    RightBrain was among the first firms certified as an Amazon Web Services Advanced Consulting Partner and one of the first six, audited AWS Managed Service Partners worldwide. The firm is also a Microsoft Partner Silver Cloud Platform.

    About RightBrain Networks

    RightBrain Networks is an Ann Arbor, Michigan-based team of software engineers (development) and site reliability engineers (operations) building SaaS, infrastructure and managing applications for companies using public cloud platforms. The company’s DevOps philosophy, agile software development process and Cloud Development Life Cycle™ dramatically accelerate development and deployment cycles, resulting in faster time-to-market. RightBrain Networks specializes in Amazon Web Services cloud deployments and is a certified AWS Advanced Consulting Partner and Managed Service Partner, and Microsoft Silver Cloud Platform Partner. For more information visithttp://www.rightbrainnetworks.com.

  • CloudPassage Named “Most Innovative Cybersecurity Company”

    SAN FRANCISCO, CA–(Marketwired – May 05, 2016) –  CloudPassage today announced it has been recognized as the “Most Innovative Cybersecurity Company” in the 2016 Cybersecurity Excellence Awards, which are voted on by the more than 300,000 security professionals who participate in the LinkedIn Information Security Community. From nearly 200 cybersecurity vendors that were nominated, CloudPassage was selected as the winner of the mid-size company category, focused on the most innovative organization that has between 101 and 1,000 employees.

    “Enterprises are in the middle of a massive transformation of their IT infrastructure designed to let them move faster and stay competitive,” said Robert Thomas, CEO of CloudPassage. “Agile IT delivery models involve lots of automation, high rates of change, mixed environments and on-demand IT services. But traditional security tools don’t work with these modern IT environments. We’re winning recognition as a leader in the space because CloudPassage Halo is now a proven platform that enables this transformation.”

    CloudPassage Halo is an on-demand, security-as-a-service (SaaS) platform that deploys in minutes and automates a comprehensive set of security and compliance controls for servers in any combination of public cloud, private cloud or data center environments. The result is fast, effective security that solves problems of visibility, microsegmentation, compliance and speed of deployment.

    The 2016 Cybersecurity Excellence Awards honored individuals, products and companies that have demonstrated excellence, innovation and leadership in information security. Winners were selected based on the content of their nominations and the popular vote by the Information Security Community on LinkedIn, one of the largest online networks of cybersecurity professionals with over 300,000 members.

    As part of the company’s efforts to remain innovative, CloudPassage was recently awarded three patents that extend the scope of its original, agent-based, agile security model, making it the first company to obtain a U.S. patent for universal cloud infrastructure security.

    About CloudPassage

    CloudPassage® Halo® is the world’s leading agile security platform that provides instant visibility and continuous protection for servers in any combination of data centers, private clouds and public clouds. The Halo platform is delivered as a service, so it deploys in minutes and scales on-demand. Halo uses minimal system resources; so layered security can be deployed where it counts, right at every workload – servers, instances and containers. Leading enterprises like Citrix, Salesforce.com and Adobe use CloudPassage today to enhance their security and compliance posture, while at the same time enabling business agility. Headquartered in San Francisco, California, CloudPassage is backed by Benchmark Capital, Lightspeed Venture Partners, Meritech Capital Partners, Tenaya Capital, Shasta Ventures, Musea Ventures and other leading investors.

  • Why Is There No DevOps Manifesto?

    Why Is There No DevOps Manifesto?

    Let’s start with a brief story:

    There’s a scene in a movie called “A Few Good Men” in which a lawyer is questioning a cadet. The lawyer directs the cadet to turn to the page in the thick Marine Code Manual that explains where to find the canteen. And the cadet replies, it isn’t in there.

    And the lawyer says, “Well, you eat, don’t you?”

    And the cadet says, “Yes, sir, three times a day!”

    The meals for everyone aren’t served by the book because the canteen isn’t included.

    This isn’t a history for the term DevOps or of the many people who’ve led, presented, written and interviewed about the DevOps movement. I’ve got a footnote below with some pointers for that. This is simpler than that: It’s why today there is no DevOps Manifesto and why I don’t think there will ever be.

    Now, I think I understand the desire for a DevOps Manifesto. I’ve met a lot of folks, company executives and analysts, who still dis DevOps a bit because it lacks a certified definition, an official manual or a definitive statement. Basically, a manifesto; you know, a canonical thing you can put on a shelf.

    Manifestos can be nice. They lay down the vision, the intent, the mission. They can appeal to a wide range of people, from revolutionaries to functionaries to dignitaries. It isn’t for sparking conversations so much as for orderly setting down of intent. A manifesto can bake in the meaning and content of something.

    A manifesto has that “rule of law” book feeling to them. Manifestos also have provenance and pedigree—some group of some renown sat down to discuss some topic for some specific resolutions and wrote the sum of it up. Manifesto wording can be checked to ensure real-world compliance.

    You can almost slap a copy of a Manifesto on a table to settle an argument about the manifesto’s topic. And assuming the words were crafted carefully enough, it will be the end of discussion. And that’s exactly the problem with a manifesto with respect to DevOps.

    I say: That’s not what DevOps is about.

    DevOps begins with stopping the nightmare scenario pitting Ops against Dev—or any other part of the organization. But it comes so much further. It’s for a new age of computing at webscale, using tools, teamwork and techniques to get to better, happier, more engaged outcomes for customers. Some of it is so new we are still figuring out words for it.

    The DevOps movement isn’t slowing down, either. Analysis of the Google results page shows it:

    DevOps searches over time Sep2015

    In all of this time, no one of any significance in the community has attempted to create a “manifesto for DevOps.” I’d say the Godfather of DevOps himself, Patrick Debois, was super insightful on how he went about ensuring no official manifesto could get written. (I’m not going to review the lessons learned from “The Agile Manifesto,” although good lessons were learned from the things created in the wake of having an Agile Manifesto.)

    If you have a manifesto for something, then all conversation in the domain will, rather quickly, go back to the manifesto for resolution instead of everybody working together. That’s not handy in an ever-fluid, often on-fire, scale-up fast, resilience-oriented, rapidly changing and evolving IT situation.

    As Andrew Clay Shafer (@littleidea) said recently, DevOps is about optimizing for people. With the pace of IT and tech ever accelerating, no manual or manifesto could keep up. Which reminds me of one of my favorite quotes:

    Companies die because their managers focus on the economic activity of producing goods and services and they forget that their organization’s true nature is that of a community of humans.

    — Arie De Geus

    One thing you should know for sure about DevOps: The community likes to enhance, educate, enliven, inform and energize people. Basically, everyone is wide open to embracing anything that helps out because webscale is hard. So yeah, DevOps now aligns with “microservices” because microservices can further the DevOps cause. Just like kanban, Docker containers, automated configuration and InfoSec. And anything that enables Dev and Ops to deliver more, better, faster to customers. It’s about serving the customers.

    Meanwhile, if you’re looking for more, you’ll usually find a bunch of folks … figuratively speaking … over in the kitchen at the canteen, serving up awesome and working hard on doing it better and faster.

    And everyone interested is welcome to sit down and enjoy what’s served.

    Seriously. Join in. You do not need a manifesto to.

    P.S.  It was with deep hesitation that I wrote this. There are simply so many awesome people who’ve made all this happen and I am not one of them. Literally the finest collection of technologists—and in many cases, human beings—I have the honor to know who make this community what it is.

    You should check out, in no particular order:

    • The amazing (and amazingly modest) Patrick Debois
    • The writings and teachings of Mark Burgess (one of the most under-recognized geniuses I have encountered)
    • The CALMS write-ups by John Willis (@botchagalupe) and Damon Edwards (@damonedwards)
    • Damon’s five-minute video on DevOps history
    • John’s frank exploration of the issue of burn-out in IT (and that is directly related to why we are having DevOps conversations)
    • Mary Poppendeick’s lean development work
    • John Allspaw and John Hammond’s 2009 Velocity keynote that sorta kicked this whole thing off
    • Ben Rockwood’s (@benr) comprehensive LISA11 keynote
    • The many videos of Andrew Clay Shafer (@littleidea) and his brilliant guidance. Sometimes with katana and sometimes with gattling gun.
    • Jez Humble’s books (particularly “Continuous Delivery” and “Lean Enterprise”)

    And works from folks including:

    • Jeff Sussna (@jeffsussna)
    • James Turnbull (@kartar)
    • Adam Jacob
    • John Vincent (@lusis)
    • Bridget Kromhout
    • Adrian Cockcroft
    • Gareth Rushgrove
    • Kris Buytaert
    • J. Paul Reed
    • Ernest Mueller
    • James Wickett
    • Ines Sombra
    • Karthik Gaekwad

    I mean, this is a global phenomenon, were you expecting a short list? This isn’t even complete!

    Oh, and the VisibleOps guru Gene Kim, who came and showed us all a way to really blow the doors off the DevOps news.

    These people are helping all of us do better Dev, better Ops, better IT, better business so that you can have better customers. It’s amazing. It really is. And it’s wonderful.

    Also, if you get a chance to spend time at a DevOps Days anywhere, you should.

  • 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.

  • 3 Ways to Become a More Agile IT Organization

    3 Ways to Become a More Agile IT Organization

    In 1960, the average life expectancy of a Fortune 500 company was 75 years. Today, the average lifespan is just 15 years and declining further. So what gives? We only have to look as far as the “Uber-effect” to understand why so many companies fail. Uber very simply and quickly disrupted a centuries-old industry with the touch of a button—making cab service part of the On-Demand Economy, where consumers get what they want, when they want it, with no delays. Today, agile companies are winning.

    So, ask yourself, is your company a disruptor or a disruptee? The reality is, most companies are the latter, with IT organizations under more pressure today than ever before. Whether it’s the fear of being “ubered” by the competition, or business demands to pick up the pace, IT organizations face a balancing act of ensuring the operation of core applications and being innovative. But the truth is, innovation and maintaining the efficiencies of legacy systems can co-exist.

    While the prospect of competing with born-on-the-web companies such as Uber or Airbnb might seem daunting, there are a few things you can do to become a more agile IT organization:

    Automate manual processes

    How long does it take your organization to deliver a simple, new feature in an application? Two days? A week? A quarter? Traditional approaches to software delivery are too slow for today’s speed of business. These often-manual processes are fragmented, error-prone and time-consuming. A recent Forrester Total Economic Impact study revealed organizations that automated their app deployments experienced an increase in speed-to-market and reduced development cycle times up to 75 percent.

    Take a look at your delivery pipeline and assess where you’re testing and deployments could be automated. Are developers able to easily deploy applications to a test environment, or are they bogged down with unnecessary wait times and manual deployment and configuration steps that are susceptible to errors? If you’re facing a development-testing cycle of two to five days, that’s simply too long. Look to adopt DevOps by automating release and deployment processes wherever you can and aim for continuous delivery, so you can push apps out quickly and be more agile.

    Lean and Mean Equals Agile

    No company will risk its core systems of record for the sake of innovation. At the same time, you cannot invest in becoming innovative if the delivery and maintenance of your core systems are inefficient. The goal is to make these core systems as lean as possible by automating repetitive tasks, freeing resources that can be directed toward speeding innovation. Today there are cloud technologies and services and API management systems that can help organizations streamline the maintenance and operations of these core systems and expose their services as APIs for consumption by new applications.

    Create a multispeed IT process

    While you’re making your core systems as lean and agile as possible, create a second layer, where innovation and agility are the key focus. As your core systems are exposed as APIs, you can begin to use their business functions and services to experiment and innovate. Cloud-based development platforms allow organizations to stand up complete development, test and production environments quickly to incubate and deliver new, innovative applications that consume these services from the core systems, delivering new and innovative business capabilities in a fraction of the time traditional methods would take. These innovative apps can be delivered and decoupled from the speed of delivery of the core systems, enabling what is known as multispeed IT.

    While the status quo might seem like an easier option, by doing nothing, you risk not only being passed by the competition, but your line of business leaders may bypass you altogether, turning to “shadow-IT” and outside vendors to meet their needs. While this hypergrowth of the tech industry is unprecedented, it is not a fad. The pace of innovation will only get faster and your only options are to fail or adapt and be agile.

    About the Author / Sanjeev Sharma

    sanjeev-sharma

    Sanjeev Sharma, CTO and Distinguished Engineer – DevOps Technical Sales and Adoption, IBM Cloud Unit, is a 20-year veteran of the software industry with expertise in DevOps, mobile development and UX, lean and agile transformation, application lifecycle management and software supply chains. He is a DevOps thought leader at IBM and speaks regularly at conferences. He has written several papers and is the author of the “DevOps for Dummies” book.

    Connect with Sanjeev LinkedIn | Twitter

  • XebiaLabs Innovates Pipeline Orchestration, Adds New Release Dashboards and Introduces DevOps ChatBot

    New Version of XL Release Helps Enterprises Orchestrate and Control Large and Complex Releases, so They Can Produce Software More Quickly and With Fewer Errors

    BOSTON, MA–(Marketwired – May 3, 2016) – XebiaLabs, a recognized leader in DevOps and Continuous Delivery software tools, today announced the launch of XL Release version 5.0 as well as XL Deploy version 5.5 and a new DevOps ChatBot.

    XL Release allows companies to automate, orchestrate and gain visibility into their software release pipelines at enterprise scale. XL Release 5.0 simplifies the way stakeholders get insight into the software delivery process — from IT executives to program managers to developers. The new configurable dashboards and productivity features are designed to help manage complex, multi-level and interdependent software release pipelines.

    “As releases happen faster and pipelines grow more complex, enterprises know they need to do more than automate their release processes. Just as importantly, they need a way to understand, organize, manage and monitor large amounts of interdependent release information,” said Derek Langone, CEO at XebiaLabs. “We designed the new capabilities to meet the needs of large enterprises that are focused on achieving business results — whether they are working with existing middleware and big data systems, or implementing new container or IoT initiatives.”

    XL Release 5.0 Highlights

    • Customizable Release Dashboard: Release teams now have new, easy-to-use dashboards that show what’s in each release at a glance. The dashboards can be custom-configured to display a team’s most important status indicators and metrics, such as overall release progress, compliance and audit details, features delivered, issues found, and open tickets resolved. They can also show information from other tools that play a part in the software delivery pipeline, such as JIRA, Jenkins, XL Deploy or ServiceNow. XL Release’s new dashboards provide a new level of visibility to everyone who has a stake in the release, from the CIO to the Risk Management team to the Release Manager or the DevOps team.
    • Advanced Release Pipeline Orchestration: XL Release 5.0 delivers the unique ability to manage interconnected pipelines as a whole unit, so it’s easy to determine when a delay in one pipeline will affect delivery for an entire business feature.  New releases can now be automatically launched from within another release, releases become automatically linked and teams can quickly see how all releases fit together. This capability helps organizations manage more complex release patterns: they can automatically orchestrate dozens of related releases, manage dependencies between releases, group related releases, and easily divide the work between teams. XL Release 5.0 also adds a new expanded table view that lets teams better organize and manage complex, interdependent releases.

    Release Orchestration Delivers Business Results
    Unlike other release orchestration tools, XL Release 5.0 automatically tracks the impact of dependent releases on the current release, so delays at any level of the process can be quickly discovered and fixed.

    By automating even more of the release process and automatically managing dependencies, enterprises can release software faster, with fewer errors. Organizations get the detailed visibility they need to monitor the process and keep track of their features throughout the software development lifecycle with a unified view that spans third party tools. With XL Release’s added visibility and control, DevOps and Continuous Delivery initiatives become more effective and efficient.

    Enhanced Cloud Provisioning Options for XL Deploy
    In conjunction with XL Release 5.0, XebiaLabs also released version 5.5 of its popular XL Deploy product, which provides enterprise-scale deployment automation for any environment, from Docker to mainframes. The new version integrates provisioning of cloud environments as part of the deployment process, eliminating the need to wait days or even weeks to get the cloud resources that teams require. Developers can now more easily “self-service”: they can spin-up and tear down cloud environments as part of their automated deployment, and the system ensures that necessary controls are met. This capability helps teams save money by making the most efficient use of cloud resources. It also gives them deeper visibility into — and better control of — deployments for both applications and environments.

    ChatOps – a ChatBot for DevOps
    To help DevOps teams better communicate, XebiaLabs recently introduced a new ChatOps feature. Many DevOps teams already use chat tools extensively to work more efficiently and bring together distributed teams. The new plugin for XL Deploy facilitates communication and increases productivity by letting teams monitor deployment activity, trigger deployments and troubleshoot incidents from inside their chat tool of choice, such as HipChat or Slack. More details are available on the XebiaLabs blog at:http://blog.xebialabs.com/2016/04/22/xebialabs-launches-chatops-automation-software/

    XebiaLabs customers are eager to use the new product features. “The new version of XL Release offers interesting new dashboarding functionality that will help us see what’s in each release and get better visibility into release status. Also, the advanced release orchestration will let us automatically manage parent/child relationships between different releases,” said Sander Ettema, Manager, Linux Unix at Rabobank ICT. “These new features provide a lot of value in a complex environment like ours.”

    Availability
    XL Release 5.0 and XL Deploy 5.5 are available now. Download a free trial:
    www.XebiaLabs.com/XL-Release
    www.XebiaLabs.com/XL-Deploy

    About XebiaLabs
    XebiaLabs develops enterprise-scale Continuous Delivery and DevOps software, providing companies with the visibility, automation and control they need to deliver software faster and with less risk. Global market leaders rely on XebiaLabs to meet the increasing demand for accelerated and more reliable software releases. For more information, please visithttp://www.xebialabs.com.

    CONTACT INFORMATION

  • Putting the ‘Biz’ in DevOps

    Putting the ‘Biz’ in DevOps

    I was having a conversation with a client recently and we both came to the conclusion that DevOps, as used in some conversations, is misnamed. DevOps, by virtue of its name, implies that the focus of improvement is aimed at development and operations. While this is true, I believe that DevOps, at a higher level, is to improve the practices of getting business needs into production more quickly and reliably. The picture below illustrates this higher-level life cycle.

    pic 1

    The goal in any meaningful DevOps practice is to reduce the time and improve the efficiency in moving from the “Business Need” on the left to the “It’s Live!” on the right. This is why I’ve been such a fan of using lean approaches to improve the solution-delivery processes.

    So where does business get involved? Clearly, the business should be involved with the “business needs,” but organizations with good DevOps practices have the business working across the whole life cycle. The ability to do course correction and steering during the lifetime of a project is so important. We know that things change and what we plan on building may be different than what we actually deliver. Having the business in close affinity to the Development and Operations team is a good step to helping drive this alignment. If we get things right, we might be able to build a much simpler DevOps delivery cycle that looks like this:

    Pic 2

    It is also important that we should be measuring things that matter to the business. By doing so, this will also aid in improving the alignment across business, development, and operations. Below are few business oriented metrics that I have used to improve solution delivery processes for my clients. These might be good to put into your “BizDevOps” measurement strategy:

    Metric  Details Benefits/Impact
    Deployment Frequency  How frequently are new releases reaching your user? This metric should be stable release to release. Your end users should see a steady cadence of bug fixes, new features, etc., that build confidence in the products you deliver.
    Change Volume  How many new stories (or features) are in each release? Your end users should see new features being released consistently.
    Renewals, User Volume, New Users  Is your user base increasing, decreasing or staying the same? A growing user base shows if your product is being viewed as useful.
    Revenue per user  Is revenue or cost changing over time with your user base? This is another indicator that shows the value and economic impact of your product.
    Client Experience KPIs
    •  Customer Ticket volume
    •  Incident Severity Ratios
    •  Availability of Systems
    		 These metrics give you a perspective on the overall quality of your product.

    Adopting the right business-oriented metrics that are meaningful for your team and projects will help you expand your DevOps capabilities into a broader, more meaningful “BizDevOps” practice!

    For more information on metrics that are relevant, take a look at my blog, “How project managers can measure a cloud project’s success.” Also, refer to Forrester Consulting’s report on the Total Economic Impact of IBM UrbanCode at https://ibm.biz/BdXUjt 

    About the author / Rick Weaver

    Rick Weaver

    Rick Weaver is a Director in IBM Cloud leading the US East Cloud Advisors. Rick has extensive experience working with some of IBM’s largest clients around the world. Rick has led work in helping clients around the world improve their practices around DevOps, software engineering, agile adoption, automation and cloud implementation.  In prior roles, Rick has led Rational Lab Services for AP and China, IBM’s SOA Tool strategy, helped drive the internal transformation of IBM tool development and integration, and has led the worldwide technical sales team for WebSphere Tools. Rick lives in Dallas, Texas and has worked for IBM for 25 years.

    Connect with Rick LinkedIn | Twitter

  • DevOps by Osmosis — Is That Even Possible?

    DevOps by Osmosis — Is That Even Possible?

    “We don’t do DevOps. We can’t, as our development plans are agreed so far in advance and our priority from a production point of view is to keep our systems available 24/7.”

    I heard this comment from a pal of mine as we had a quiet beer over the weekend, but I’m sure this comment, or a variation on it, has been uttered many times in many places. Here’s the irony: I had met my pal, who works as a developer for a major financial services company, after he had had the week from hell. His group tried—and succeeded—to fix a major system issue that had come out of the blue. He had certainly earned the beer that week.

    So, I asked him: “How did you get the problem sorted in the end?”

    “Well, we had to form a Tiger Team,” he replied. “Pulled together some of the DBA team, the key developers and the Ops guys, worked throughout the night and managed to keep the systems up and running the next day, while we used that time to address the root cause.”

    “How did you get around the Governance guys?” I asked.

    “Well, we brought one of them into the team for a few hours, and she was able to get us past some of the key bottlenecks,” he said.

    “And how about QA?” I asked.

    “Oh, they knew this was a major issue and so we cut out a lot of the QA and just went ahead,” he replied. “It was a bit risky, but we had all the right guys in the room to fix anything that cropped up.”

    “So, you manged to get a major change through in a couple days, kept your systems up and running, kept your customers happy, and earned that beer,” I said.

    “Yep, that’s about it, alright,” he said.

    “So, that’s pretty much what DevOps is all about—minus the emergency element,” I pointed out. “Seems to me like you guys are already on the DevOps road.”

    It was about then that the penny dropped with my pal. He suddenly realized that yes, they could do changes quickly, yes, they could do them in an orderly manner and yes, they could keep their systems up and running while all that happened. But, as quickly as the penny dropped and the realization dawned on him, the light went out again.

    “There’s still no way we can do DevOps in our place,” he said. “There’s too many hurdles to overcome, too many guys used to doing things the existing way, which to be fair, has worked well for us. To be honest, there’s too many guys who would feel under threat if we suddenly changed how we do things.”

    And that, in a nutshell, sums up the major challenge facing people promoting a DevOps approach. I have spent many years in the IT industry; I go so far back that I wrote my first code using punch cards (look them up) so I’ve seen change come and go, and change has been the one constant. I think many people in the IT industry have become too focused, whether it’s on the latest tools in their area of expertise, or on the newest piece of kit that has been bought, or indeed on the latest problem the business has put in front of them. The industry has become mature—if we compare the IT world to a field such as medicine, you pay passing attention—if you even notice at all—to things outside your specialty field.

    Now that’s right and proper. I don’t want an orthopedic surgeon trying to fix the problem with my eye, and I don’t want a DBA to write me some code. But when something comes along that affects the whole industry, I want them to pay attention and not ignore it.

    Daysha ran a lunchtime seminar last week, and we titled it “BizDevOps – DevOps isn’t compulsory but neither is survival.” We wanted to use this seminar to engage business people who, let’s face it, are the people we support and who need to understand how IT can make things better. Somewhat disappointingly, while we attracted a great crowd, they were all IT people. No one from the business attended. Now maybe we advertised this event in the wrong places, or maybe we held it in the wrong place, but here’s the thing: We attracted IT people from major companies, and none of those IT guys said to their business people, “You need to hear about this, come along for lunch.” I hope that after our seminar they went back to their business people and said just that, and maybe the next lunch will have the business people in the majority.

    When PRINCE came out into the project management world, it was not bought into by a majority of project managers. The same happened with ITIL. And the same will happen with DevOps. It is fair to say that PRINCE and ITIL are pretty much standard on a worldwide basis. I am old enough to remember the time I first heard of them, and the time I did my first course and passed my first tests, but nowadays, they’re part of the furniture—taken for granted, and rightly so.

    I think people are a little bit afraid of DevOps, and I can see why this is the case. Think about it for a second: Someone is now saying that the way we have done things for years has to change. That we can do things better, faster, with higher quality, but we just can’t do the massive 12-month long project in the same way. We might need some new tools, primarily on the Ops side. We might need some new skills—again, primarily on the Ops side. But, by the way, we’re not going to do away with the Ops guys (so don’t expect to make major budget savings there). But here’s the thing: Our end customers will notice the difference, and so will not be tempted by the new kid on the block—who, as it happens, is probably using a DevOps approach to develop his application, which is threatening our business.

    Change is scary, it’s not easy, and making a major change while you’re still having to churn out the new business requirements, and keep the current systems running … now that’s really scary. But, like my pal whom I shared the beer with last weekend, maybe you’re not as far away from that change as you think you are, maybe it’s not as scary as you think it is, maybe it will affect people positively, maybe you just have to do it.

    About the Author/John Brophy

    eJohn Brophy is currently Head of Professional Services at Daysha Consulting in Ireland, where he leads a team of 25 project managers and business analysts working on projects in blue-chip clients. He is a 35-year veteran of the IT industry, starting out as a database systems programmer, moving onto leading a team of systems programmers looking after what were then called midrange systems. He then became a senior project manager with a global IT company and followed that up by running his own IT infrastructure support company for 6 years. His background is Ops – and he is proud of that!

  • Q&A: Sematext’s Thies on Docker Monitoring, Part 1

    Q&A: Sematext’s Thies on Docker Monitoring, Part 1

    Stefan Thies is DevOps evangelist Sematext Group. I recently spoke with him about Docker’s use of Sematext Logsene logging, anomaly detecting and alerting software and SPM monitoring software. Read on for part one of our conversation.

    David Geer: Technically speaking, for the purposes of this article, what is logging?

    Thies: Logging means to store the output of programs (applications, servers) running on a computer. Typically, log messages that software applications produce are stored in log files. However, software running in Docker containers writes its log messages to a virtual terminal (console). The Docker Daemon (the server process managing the containers) has several facilities to forward log messages via log drivers or the Docker API to external applications, which are responsible for storing the log messages. This is not the traditional way of working with log data. This changes the log collection and storage mechanisms and forces many organizations to change their workflows for log management by introducing new tools.

    Typically, you would use a service called syslog to receive and store log messages on servers, but this requires special configuration for all Docker containers. While Docker made it easier to deploy applications, the new technology made logging and monitoring much harder as you could not use the traditional tools apart from integration with Docker.

    This is where companies like Sematext provide added value, by enabling:

    • Integration into the Docker Ecosystem
    • Cloud storage for log files
    • Indexing for full text search, analytics, visualization and alerting on log data

    Geer: What has Sematext Logsene contributed to logging, technically?

    Thies: Logsene Log Management includes all required workflows and security procedures to handle log data. Logsene provides role-based access controls for access to log data. Logs are collected and shipped to Logsene servers (running in the cloud or on premises) where the data gets stored and analyzed.

    Other important features are:

    • Full text search
    • Analytics
    • Alerts
    • Anomaly detection

    Geer: In what way is Logsene/Sematext available to users and organizations that seek solutions to capture logging for monitoring their Dockerized distributed applications?

    Thies: Logsene is available on premises and as SaaS in the cloud. It fits in hybrid environments as well such as running the Dockerized application in-house on bare metal while shipping logs to Logsene SaaS. In this case, only Sematext Agent for Docker runs on premises.

    Sematext Docker Agent automatically detects running Docker containers and automatically collects logs from the containers. The Sematext Docker Agent can transform unstructured log messages into structured data for analytics. We do this with integrated parsers and a pattern library, which detects log formats to structure logs. The final task of Sematext Docker Agent is to ship the structured logs from all containers securely to Logsene, where indexing for full text search and analytics queries takes place. The Logsene user interface provides all tools for search, visualization, anomaly detection and alerts on log data.

    Geer: What is SPM for Docker? What role does it play?

    Thies: Both Logsene and SPM collect data via the Sematext Docker Agent. SPM is a performance monitoring, anomaly detection and alerting solution for many server applications like Web servers (e.g., Apache, Nginx), databases (e.g., Cassandra, MongoDB, HBase, MySQL, etc.), big data engines (e.g., Spark, Storm, Hadoop, etc.) and full text search engines (e.g., Elasticsearch, Solr). Sematext Agent for Docker collects not only container logs but also performance metrics of all containers at the same time, plus Docker events.

    SPM for Docker provides operational insights into application performance on the Docker platform. It is not limited to performance monitoring—it integrates with Logsene for log management in a single user interface. DevOps teams can find log messages in correlation with potential performance bottlenecks. Most organizations use different tools for performance monitoring and logging. Sematext has recognized that metrics and logs must be available in a single platform to provide detailed operational insights without having to switch between different tools and without overhead for things like integration of multiple tools, multiple user interfaces, logins managing access permissions for multiple tools, and billing or licensing from multiple vendors such as NewRelic or Splunk.

    Watch this space for part two of my conversation with Stefan Thies of Sematext.