staging-devopsy.kinsta.cloud

Category: DevOps Toolbox

  • Virtual Instruments Extends Scope of AIOps Platform

    Virtual Instruments Extends Scope of AIOps Platform

    Virtual Instruments has extended the reach of its AIOps platform to add application service assurance, predictive capacity management, workload infrastructure balancing and problem resolution and avoidance capabilities.

    Based on a combination of machine learning, statistical analysis, heuristics and expert systems technologies, VirtualWisdom is designed to enable DevOps teams to be able to apply analytics to resolve issues in near real time versus having to convene a “war room.”

    Len Rosenthal, chief marketing officer for Virtual Instruments, said the whole war room concept has become antiquated in the age of DevOps. Instead of wasting time having individual departments within an IT organization coming together to defend their innocents every time an issue arises, VirtualWisdom identifies the likely source of the problem instantly.

    The latest release of VirtualWisdom adds to that a predictive capability that identify workload balancing opportunities intended to prevent problems from arising in the first place, he added.

    As part of an ongoing effort to infuse AIOps into DevOps processes, the latest release of VirtualWisdom also adds integration with application performance management (APM) tools from Dynatrace, in addition to enhancements to existing support for APM tools from AppDynamics, a unit of Cisco.

    VirtualWisdom is also now able to collect Linux and Windows operating systems along with metric generated on Amazon Web Services (AWS) or Microsoft Azure. There also a now iSCSI wire data monitoring support in the NAS Performance Probe, which complements existing NFS and SMB monitoring capabilities.

    Rosenthal said the rate at which applications are being developed and deployed soon will force the AIops issue in most organizations. As those applications become more distributed across hybrid cloud computing environments, it’s become impossible for any single IT team to manually keep track of all the dependencies that could adversely impact all their applications, he noted.

    While increased reliance on artificial intelligence (AI) is all but inevitable at this point, it’s less clear to what degree IT organizations themselves will be reorganized as a result. Most organizations have embraced DevOps to bridge the divide between their IT operations and application development teams. But many of the silos within their IT operations teams soon may be automated out of existence as the need for dedicated compute, storage and networking specialists declines. In some instances, developers are already taking advantage of application programming interfaces (APIs) to assume control over IT infrastructure end to end. That scenario may become even more common as AI continues to automate more of the rote IT operations tasks.

    None of that means there won’t be a need for someone to architect the IT operational workflows required to support applications at scale. But it does mean many lower-level administrator tasks soon might be sharply reduced or eliminated altogether. The challenge IT organizations soon will face is retraining those administrators to handle tasks beyond what’s possible to automate using AI.

    In the meantime, organizations will continue to experiment with AI. Not every organization is comfortable enough with AI to turn over control to what many still view as a “black box” that doesn’t provide any visibility into those processes being automated. But as more of that visibility is provided, it’s now only a matter of time before AI platforms take move control of the IT environment.

    — Mike Vizard

  • CircleCI Automates Configurations Across CI/CD Platform

    CircleCI Automates Configurations Across CI/CD Platform

    CircleCI has unveiled what it describes as the first package manager designed specifically to address configuration tasks involving software delivery automation.

    Matt Wyman, vice president of product for CircleCI, said the Orbs package manager condenses commands, executors and jobs into single, reusable lines of code that automate tasks on the continuous integration/continuous delivery (CI/CD) platform the company provides as a cloud service. The initial set of Orbs being made available by CircleCI are focused on automating more than 25 different cloud deployment scenarios to enable organizations to employ DevOps processes at scale, he said, noting those Orbs can then be validated and shared via an Orbs registry that CircleCI is making available.

    CircleCI is also launching a technology alliance program through which Jfrog, Twistlock, Anchore, Aqua Security, Cypress, Postman, Coveralls, datree, Rollbar and Codacy have committed to building Orbs.

    Wyman said shareable Orbs that require only a few lines of code to develop makes it possible to share configurations across multiple CI/CD workflows. Those Orbs then can be integrated with any number of third-party tools.

    CircleCI is making a case for a CI/CD platform delivered as a managed cloud service that eliminates the need for DevOps teams to set up and manage on their own. Open source CI/CD platforms can be too complex for the average IT organization to set up. Alternatively, CircleCI makes available a version of its CI/CD platform that organizations can deploy behind their own firewall. The CircleCI approach is designed to enable DevOps teams to flexibly create workflows that can be executed sequentially or in parallel.

    There are 12 million builds a month being generated by more than 300,000 developers taking advantage of the CircleCI cloud service to build applications, Wyman said. One of the primary drivers of that success is a cloud service that allows organizations to apply more of their limited resources to developing applications versus managing CI/CD infrastructure, he noted.

    Most IT organizations have yet to standardize on a specific CI/CD platform. Competition between providers of CI/CD platforms has never been more fierce as more enterprise IT organizations embrace DevOps. As DevOps processes continue to mature, it’s also clear that DevOps processes will need to be extended across multiple clouds in addition to on-premises IT environments.

    In general, CI/CD platforms are initially set up by developers who have embraced DevOps processes to accelerate development and deployment of applications without sacrificing quality. The most widely used CI/CD platform is the open source instance of Jenkins. Developers often can adopt Jenkins on their own without requiring anyone to sign off on a purchase order. But as organizations move to scale up their DevOps processes, CircleCI is betting interest in a commercial service that can be easily accessed across an entire enterprise will increase as organizations move to standardize their CI/CD environments.

    In the meantime, pressure to increase the rate at which applications are built and deployed is only going to increase as organizations become more aggressive about digital business process transformation. The issue now isn’t so much whether they will have a CI/CD platform, but rather to what extent—and, in some cases, how many.

    — Mike Vizard

  • Back to DevOps School: What Tools are in Your Backpack?

    Back to DevOps School: What Tools are in Your Backpack?

    The 2018-19 school year is in full swing, and just like the kids are going to the bus stop with their new backpacks and shoes, it’s time to refresh your DevOps tool chain and look to the future. Remember, just like education, DevOps never ends. It’s a lifetime pursuit that constantly improves your life.

    The DevOps tool chain of the future must include:

    Trunk Releases

    Time to get your branch and merge skills down pat. Git is the best source code control to offer this to development teams. Companies should be actively moving to git to allow their development teams isolated feature development with pull merges and pushes to the trunk for releases.

    If you are not using git, it’s time to start justifying why you are not. Given the speed at which businesses are moving, it is time eliminate blockers for development to release features. Git is built for speed and large numbers of dispersed developers. Remember: it was built by Linus Torvalds to support Linux kernel development.

    Database Development Tools

    When planning for your DevOps tools, seriously consider database development tools as well. But, if you want comprehensive results when developing your database, you need tools with a DevOps flare.

    If we didn’t have the efficiency and speed that we got from Agile software development, we wouldn’t have created DevOps. So, bringing Agile to database development was a must for database DevOps to solve problems. One tool in particular that we use supports some incredible features for Agile development. A database is different than an application; because of this, a database will have state. So, having a database instance we can compare to with our team is critical. The tool we use has this functionality, which has allowed us to thrive. It also lets users work with existing source code control along with a live database to help database developers. Because of this, users can execute this functionality against database objects such as stored procedures and tables.

    Application Release Automation

    Application software can be difficult to manage. Often, they have too many components to manage easily, which is where automation can help. Application release automation helps your team move from learned and taught processes to basic scripts that are easily scalable and can help deploy applications rapidly. If you’re working with a team that cares about data and DevOps, Application release automation is a critical tool.

    Test Data Management

    No matter how rapidly you are able to deploy applications, you’ll need to test. The faster you deploy, the more tests you will need to run. But a massive problem with testing can be the lack of quality. Many applications pivot functionality depending on the data stored in a datbase. So, providing data that is or, at least, matches the production data is critical to guarantee high test quality. Without the right data, you could be running massive amounts of tests that are also providing bad/false results. And, with DevOps, you’re committed to improving your software and working to enable more testing for that software.

    Don’t Forget the Database

    A key finding of the “2018 State of DevOps Report” is that integrating database change management into your DevOps toolchain early in the process drives higher performance.

    This is obvious to anyone that has released software before. However, for large siloed enterprises, this is non-obvious. For too long, we have been told to leave the database to the DBAs. Well, it turns out that approach (though sensible in the ’90s, when we started it) is no longer working for us.

    Your application will not run without database schema and logic changes about 80 percent of the time. So, there is no reason to have a separate manual process. Here’s someone saying that exact same thing in 2017: https://www.youtube.com/watch?v=DDZIiGT3jzs

    Now What?

    Having all the right tools is a necessary first step, but it doesn’t stop there. To fully succeed with these tools, a few key strategies must be put in place as well:

    One Ring to Rule Them All

    DevOps has taught us to break down silos. Yet, we see silos now being created based on tool choices. Companies should standardize DevOps tools across the entire value chain. If some parts—say Dev and Test—are using Artifactory, for example, the operations team should also use it and not rely on the release teams to put the release on a shared network drive. Ops should use Artifactory, too.

    This will require some horse-trading. Some teams will dig their heels in on a tool because it provides value specifically to them. Well, so be it. As one of my favorite Venture Bros. character, Dr. Henry Kissinger, says, “Compromise, my friend, is the essence of diplomacy, and diplomacy is the cornerstone of love.”

    Cloud First

    When I hear “cloud” from IT leaders, I immediately think of Inigo Montoya from “The Princess Bride” when he said, “You keep using that word. I do not think it means what you think it means.”

    The National Institute of Standards and Technology has defined cloud computing to have five essential characteristics:

    1. On-demand self-service
    2. Broad network access
    3. Resource pooling
    4. Rapid elasticity or expansion
    5. Measured service

    Your DevOps tools should also have these characteristics. Specifically, if you are not allowing external teams to utilize your tools and require someone to make a request via ticket first, you are doing it wrong.

    Time to learn how to offer DevOps as on-demand self-service.

    — Robert Reeves

  • How GitOps Can (Sometimes) Save DevOps

    How GitOps Can (Sometimes) Save DevOps

    A lot has been written about GitOps since its release by Weaveworks more than a year ago as a “single source of truth for the whole system” for using Git for Kubernetes deployments on the cloud.

    Aptly described by Alexis Richardson, Weaveworks co-founder and CEO, as “90% best practices and 10% cool new stuff,” GitOps largely offers a framework for DevOps CI/CD deployments on Kubernetes. This was something very often seen as missing among the many Kubernetes management distributions on offer—hence, its popularity.

    The tool is obviously not of use for organizations that have not adopted Kubernetes, but in many ways has enabled organizations’ DevOps to more efficiently take advantage of Kubernetes by running Git in a more disciplined and focused way.

    “The idea behind GitOps is to maximize the time developers spend on productive coding versus worrying about working with the latest source code, merging their saved code back into the repository and continuously supporting problems that come up during the application build process,” Torsten Volk, an analyst for Enterprise Management Associations (EMA), said.

    GitOps offers DevOps a way to use its version control capabilities to archive changes to application deployments in a way that allows them to be recalled at a later time. This can come in handy when an architecture fails and it is necessary to access and reinstate a previous version of an application deployment or update prior to the incident. All changes are tagged and archived in a way that each developer knows when and how their changes to an application were changed.

    “Ideally, each developer would check in their code and receive a link to the running application with his or her latest changes applied, as well as with all the other changes that were checked into the repository,” Volk said.

    The Adoption Checklist

    Volk offered the following elements he said DevOps should have in place before adopting GitOps:

    — All infrastructure and application configurations, including databases, middleware and machine learning models, need to be defined as code, Volk said.

    “Everyone must accept the basic concept that code is only complete when all components for a successful build are checked into Git,” he said. “CLI-driven, ad hoc deployments are no longer acceptable.”

    — The DevOps group has to be able to detect changes to application code that previously might have been able to bypass Git. There must be thus be a process in place to bring these changes back under GitOps control, Volk said.

    “The IT Ops/DevOps teams need to make operational changes to the app exclusively via changes to the code checked into Git,” he said. “This means that tasks such as scaling, failover, creating maintenance windows, etc. as well as urgent troubleshooting tasks have to run through Git. The latter is especially tricky, as the enterprise will not accept longer mean time to detect (MTTD) and mean time to repair (MTTR) due to GitOps.”

    — Declarative management practices have to be used in Dev and Ops. “This has proven to be a critical roadblock,” Volk said. “Kubernetes developers, as part of Dev and Ops, still often prefer the control of imperative management over the promise of defining their desired end state and letting the software deal with how to get there.”

    For DevOps teams that have the prerequisites in place as described above to use Git to run Kubernetes deployments on the cloud, then GitOps deserves at least a look. However, for those organizations that adopt GitOps for the right reasons, it is not designed as a one-size-fits-all solution and organizations will need to modify it to fit their needs. Its implementation, for example, will almost certainly different compared to how Weaveworks described its functioning after using it for two years to run Kubernetes and Prometheus telemetry databases on a cloud platform.

    DevOps will, thus, need to be actively involved in GitOps deployment and maintenance to make sure it meets organizations’ individualized needs. When first describing GitOps, Weaveworks’ Richardson wrote: “Fair warning: this is what works for us, and dear reader, you may disagree.”

    — B. Cameron Gain

  • Unlocking the Power of AIOps

    Unlocking the Power of AIOps

    AIOps is becoming quite the hot topic lately. It seems as though everyone is realizing that Ops is difficult. As we have to deal with more big data at greater velocity with more automation and complexity, there is no way humans alone can tame the beast. AIOps seems to be the answer.

    I recently sat down with Dave Link, CEO and founder of ScienceLogic to discuss how to unlock the power of AIOps to empower IT ops. We video taped the conversation, along with some accompanying slides that help explain what the challenges are that ops faces and what are some of the ways to tackle this using AIOps.

    I should mention that Dave and I are old friends, having worked together 20-plus years ago at a dotcom era company called Interliant. Since 2003 or so I have watched Dave build ScienceLogic into the powerhouse it is today. I couldn’t be more happy and proud of him.

    ScienceLogic has been named by EMA as a top vendor in the AI/ML for IT Operations. Dave gives us a good background on ScienceLogic as well as a good background on the use cases and challenges that IT Ops faces that AIOps seems to be the answer for.

    Dave also talks about the differences between AI and machine learning or ML. This seems to be an area of confusion today as well.

    The video is about 30 minutes and excuse Dave and I reminiscing, but there is some really great information here.

    Video on AIOps

     

    — Alan Shimel

  • Chef Extends Scope of Compliance Automation

    Chef Extends Scope of Compliance Automation

    Chef has extended the reach of its InSpec compliance automation framework by adding a plug-in architecture that makes it easier for developers to programmatically generate compliance controls that can be applied to automation frameworks. The Terraform configuration management framework developed by HashiCorp is the first framework supported via the plug-in architecture. InSpec previously was integrated with the open source Ansible automation framework.

    Julian Dunn, director of product marketing for Chef, said the plug-in architecture supports multiple communications protocols to extend it to multiple frameworks beyond the Chef IT automation framework.

    InSpec 3.0 also makes it easier to describe new resources that can be tested in addition to a stable application programming interface (API) that enables DevOps teams to modify how tests are conducted. Improvements to a packaging mechanism for profiles will also make it easier for developers to more easily iterate on InSpec profiles with dependencies.

    Finally, InSpec 3.0 adds a key value-based description interface to enable more fine-grained reporting as well as de-duplication of controls that satisfy one or more compliance regimes. This allows organizations to create their own custom metadata categories.


    In general, Dunn notes that application development and deployment, thanks to the rise of DevOps, is moving at a pace that exceeds the ability of those tasked with compliance to keep pace. As a result, responsibility for compliance needs to shift left along with other aspects of cybersecurity, said Dunn.

    Dunn conceded it is still early days in terms of making that shift. But as more organizations discover that the rate at which applications can be deployed is being held up by compliance audits, the more incentive there is to enable developers to programmatically insert the appropriate controls into their applications. Once those controls are in place, InSpec then generates human-readable code that serves to reduce the amount of time required to pass an audit before and after an application is deployed in a production environment, said Dunn.

    Of course, passing a compliance audit doesn’t mean the application is secure. But it does at the very least provide a baseline for what’s required to make an application nominally secure. In fact, the path of least resistance to any shift toward embracing DevSecOps might be automating the processes for putting compliance controls in place.

    While there are hundreds of regulations requiring various levels of compliance, it turns out most of them require the same types of controls to be in place. Once organizations begin to programmatically embed those controls within their applications, the speed at which those applications are certified to comply with multiple regulations should increase. There will be less reason for developers to skip a compliance control to meet an application development deadline when that control can be integrated automatically.

    None of this means that people with risk management backgrounds will be participating in DevOps processes anytime soon. But it does means that the output from DevOps teams won’t be stacked up waiting to pass a compliance review because all the applications in front of it are missing one key control or another.

    — Mike Vizard

  • Akamai Further Extends Reach into DevOps Realm

    Akamai Further Extends Reach into DevOps Realm

    Akamai is extending its campaign to make content delivery networks (CDNs) a natural extension of DevOps processes by adding more application programming interfaces (APIs) and other automated functions to simplify a variety of tasks.

    Specifically, Akamai has added an Akamai Sandbox that makes it simpler to conduct tests within the context of the Akamai continuous integration/continuous deployment (CI/CD) framework.

    In addition, the company now makes it possible to cache GraphQL responses using the Akamai application programming interface (API) gateway, which provides a more efficient mechanism for caching REST APIs using the Akamai Intelligent Edge service.

    Akamai is also making it possible to run a series of what-if analyses using the mPulse metrics it exposes now all the way down to specific resource levels. That real-time and historical data can be employed within the context of A/B testing on the CDN platform. Akamai has also made available Single Point of Failure (SPOF) protection within the Ion Script Management tool, which makes use of real user performance data to identify problematic first and third-party scripts on a user’s site. SPOF can automatically defers or blocks any scripts that don’t meet standards for performance.

    Finally, Akamai has added an API for securing entire web application footprints within a Bot Manager tools, in addition to support for OAuth protocols for securing API calls.

    Ari Weil, vice president of product marketing at Akamai, said the CI/CD framework that Akamai provides makes it possible to push updates to multiple CDNs. Akamai obviously would prefer all those CDNs to be provided by Akamai, but it recognizes that, in many instances, organizations will be taking advantage of CDNs provided by cloud service providers alongside Akamai, he said.

    Weil noted that Akamai is trying to position its CDN as the first tier on which a wide variety of applications will be deployed and secured. Rather than deploying those applications on a local web server, the Akamai CDN provides a layer of isolation between cybersecurity attacks aimed at web applications and the infrastructure the rest of the enterprise relies on, said Weil. As part of that effort, Akamai has been exposing its CI/CD platform with the CDN, which organizations can employ to apply DevOps processes to applications that are deployed and updated on the Akamai CDN.

    Many of the DevOps motions these days assume the application will be deployed either on a public cloud or in an on-premises IT environment. Akamai contends that a CDN not only provides a better platform for deploying and managing distributed applications, but those applications will be inherently more secure as Akamai absorbs the brunt of a distributed denial of service (DDoS) attack, for example, and less costly as the amount of data that needs to be moved in and out of a public cloud sharply declines.

    Naturally, not every developer may fully appreciate the role CDNs can play within the context of a larger set of DevOps processes. But as applications become more distributed, there may come a day when the CDN service chosen winds up being a lot more relevant than any of the platforms being connected to the web.

    — Mike Vizard

  • Adobe Looks to Drive DevOps Adoption via the Cloud

    Adobe Looks to Drive DevOps Adoption via the Cloud

    Adobe has been building out a managed service that includes continuous integration/continuous development capabilities on the Adobe cloud service. Now Adobe is extending the DevOps processes enabled by its CI/CD platform to make them more customizable in addition to expanding the scope of the application development tools it provides to include support for single page application (SPA) JavaScript frameworks.

    Haresh Kumar, director of strategy and product marketing for mobile and connected experiences at Adobe, said DevOps processes are now an integral part of how Adobe enables customers to build a custom application experience using low-code tools it provides in Adobe Cloud. In the case of Adobe, that DevOps framework is made available via Cloud Manager, a feature of Experience Manager Managed Services that enables the streamlining of code development across staging and production environments in addition to providing code inspection, security validation and performance testing capabilities. Developers can now customize their CI/CD pipeline within Cloud Manager against specific key performance indicators (KPIs) they define.

    Meanwhile, Kumar said the SPA Editor that Adobe provides is unique because front-end developers can preview a SPA to view JavaScript code and edit content including images, video and text. With this new capability, SPA content can be more easily edited and managed within the context of a business process, he said. The SPA Editor provided within Adobe Experience Manager currently supports the React and Angular frameworks, with plans to extend its reach to other frameworks underway.

    While most IT professionals tend to think of DevOps processes only applying to large-scale applications, Kumar said it turns out that as organizations rely more on cloud services, vendors such as Adobe are exposing customers who want to create applications to a variety of best practices related to DevOps embedded within the cloud service. Many of the developers creating those applications may not recognize they are participating in a DevOps process, but Kumar noted that as more custom applications get developed on the Adobe platform, the number of web developers and content authors being exposed to DevOps process is starting to increase exponentially. It’s even probable many of those developers will be first exposed to DevOps processes within the context of a cloud service long before they encounter them within the context of their internal IT environments.

    Kumar said a DevOps process managed by Adobe is enabling many organizations to smooth out what otherwise often can be a choppy digital business transformation. Building a new generation of customer experience applications requires access to modern tools that can transcend organizational silos spanning data that resides in sales, marketing and financial applications. Last month, Adobe announced it is acquiring Marketo, a marketing automation platform to facilitate that transition. Once that deal is closed, the DevOps framework Adobe has developed in the cloud will be extended to include the Marketo platform.

    It’s hard to say to what degree Adobe will be able to drive adoption of DevOps processes across the Adobe Cloud platform. What might be even more interesting to see is how many of the organizations that rely on Adobe Cloud to develop applications will even realize they made the transition to DevOps.

    — Mike Vizard

  • OutSystems Infuses DevOps Processes into Low-Code Platform

    OutSystems Infuses DevOps Processes into Low-Code Platform

    OutSystems has turned its low-code platform into a framework for generating microservices that can run on-premises or in a variety of public clouds.

    Mike Hughes, senior director of product marketing at OutSystems, said applications generated using OutSystems 11 now can be deployed on both platform-as-a-service (PaaS) environments and container-as-a-service (CaaS) environments, including Amazon Web Services public clouds and the Pivotal PaaS based on open source Cloud Foundry software and CaaS platforms such AWS ECS, Azure Container Service, or as a set of Docker containers running on-premises.

    In addition, OutSystems 11 includes a set of monitoring tools capable of identifying issues emanating from within the applications and external dependencies, as well as a set of impact analysis tools that identify issues before an application is deployed. Those tools are critical elements of a concerted effort to apply DevOps practices and principles to the development of applications created using low-code tools, said Hughes.

    OutSystems 11 also now includes an entitlement model for controlling who can create and manage services and who can consume them, using a full entitlement model that extends to all applications and services.

    Finally, OutSystems has added support for automated risk assessments, granular access controls and activity monitoring of supplemental manual processes along with a revamped user interface.

    IT organizations of all sizes are trying to cope with a growing application development backlog by embracing low-code tools that can be employed either by professional developers to accelerate development or so-called citizen developers to create applications on their own. Legacy approaches to application development have created a gridlock issue that organizations are not going to be able to break without embracing a more modern approach to application development that combines the best of low-code application development platforms and DevOps practices, said Hughes.

    Hughes noted that more organizations than ever are trying to accelerate application development at a time when digital process transformation has become a much high priority. The rate at which new applications can be built, tested and deployed has a direct impact on an organization’s ability to compete, he said. The challenge organizations face is that much of the subject matter expertise required to build these applications resides in business units that have limited application development expertise. The central IT organization, conversely, typically has a limited number of developers available to work on applications at any one time. Rather than simply providing citizen developers with low-code tools, OutSystems is making a case for an approach to rapid application development that provides guidelines for citizen developers in a way that doesn’t create the equivalent of a black box that professional developers can’t later drill down into to determine how an application is behaving.

    It may take a while for low-code application development and DevOps processes to meld within enterprise IT organizations. But the more DevOps tools that come included with the application development frameworks being provided, the greater the chances DevOps processes eventually will pervade the enterprise.

    — Mike Vizard

  • DevOps Dozen 2018: Nominations Deadline Approaching

    DevOps Dozen 2018: Nominations Deadline Approaching

    The last day to submit your nominations for the DevOps Dozen 2018 awards is Oct 10. Click here to vote.

    This year’s awards will include 12 categories, with a winner chosen from each. The top four to six nominees in each category will become finalists, who will be selected based upon the number of nominations they received. You can nominate up to two entrants in each category; however, you can make only one nomination per person. In addition, everyone nominating will be required to provide their name and email address; while that won’t thwart any ballot-stuffing, we hope people will be trustworthy during the nomination process. The winners will be selected by our panel of judges.

    Who are the judges? This was tough. We couldn’t have anyone who might be eligible for an award. That disqualifies vendors, practitioners and many others. However, I think we have four great judges:

    1. Alan Shimel, founder and editor in chief, staging-devopsy.kinsta.cloud
    2. George Hulme, longtime tech journalist and editor at staging-devopsy.kinsta.cloud and Security Boulevard
    3. Jayne Groll, CEO and co-founder of the DevOps Institute
    4. Helen Beal, DevOpsologist at Ranger4.

    So what are the dozen categories for the DevOps Dozen this year? That you can get on the site itself, but here they are as well:

    [su_custom_gallery source=”media: 125437,125438,125439,125440,125441,125442,125443,125444,125445,125446,125447,125448,” link=”custom” target=”blank” width=”400″ height=”200″]

    Thank you again for your enthusiastic response to last year’s awards. The full list of 2017 finalists and winners are available to view here.

    There are so many great companies and people involved in DevOps that it’s always difficult to pick the winners. We know some worthy choices will not be voted tops in their category; however, acknowledging them in our awards process helps show how important they are in the DevOps space.

    As stated earlier, the top four to six nominees in each category will be designated as finalists, who then can submit a presentation on why they deserve the award to judges@devops.com. Finalists will be announced the second week of November and the winners, who will be chosen by our panel of judges, will be announced in December.

    If you have questions, send them to DD@devops.com. Voting for finalist nominees is open for three weeks, so don’t waste any time—nominate your favorites today. Good luck to everyone vying to be one of the DevOps Dozen 2018!

    — Alan Shimel