DevOps.com

  • Latest
    • Articles
    • Features
    • Most Read
    • News
    • News Releases
  • Topics
    • AI
    • Continuous Delivery
    • Continuous Testing
    • Cloud
    • Culture
    • DevSecOps
    • Enterprise DevOps
    • Leadership Suite
    • DevOps Practice
    • ROELBOB
    • DevOps Toolbox
    • IT as Code
  • Videos/Podcasts
    • DevOps Chats
    • DevOps Unbound
  • Webinars
    • Upcoming
    • On-Demand Webinars
  • Library
  • Events
    • Upcoming Events
    • On-Demand Events
  • Sponsored Communities
    • AWS Community Hub
    • CloudBees
    • IT as Code
    • Rocket on DevOps.com
    • Traceable on DevOps.com
    • Quali on DevOps.com
  • Related Sites
    • Techstrong Group
    • Container Journal
    • Security Boulevard
    • Techstrong Research
    • DevOps Chat
    • DevOps Dozen
    • DevOps TV
    • Digital Anarchist
  • Media Kit
  • About
  • AI
  • Cloud
  • Continuous Delivery
  • Continuous Testing
  • DevSecOps
  • Leadership Suite
  • Practices
  • ROELBOB
  • Low-Code/No-Code
  • IT as Code
  • More
    • Application Performance Management/Monitoring
    • Culture
    • Enterprise DevOps

Home » Blogs » Doin' DevOps » Think the Developer Tool Market Is Annoying? Just Wait…

Think the Developer Tool Market Is Annoying? Just Wait…

By: Chris Riley on July 31, 2014 3 Comments

I recently attended the Velocity Conference and DevOps Days in the Bay Area. While I usually pride myself in being “in the know” of what is available and possible. It never fails that every time I do a search on some aspect of the development process, or attend events like these, I’m shocked to discover at least three new tools I have not heard of. “What’s this… yet another functional testing tool? Let me guess, you do performance monitoring? System alerts by carrier pigeon? Cool, configuration management that also repairs your TV.”  There are so many tools and their competitive advantages are usually so specific you really have to work for the company to understand them. So how do you possibly make sense of this space? And what is next?

Recent Posts By Chris Riley
  • Using Incident Response for Continuous Testing
  • What Is Resilience Engineering?
  • Moving from NOC to the SRE Model
More from Chris Riley
Related Posts
  • Think the Developer Tool Market Is Annoying? Just Wait…
  • DevOps Debates: The Benefits of Tool Standardization
  • 9 Open Source DevOps Tools We Love
    Related Categories
  • Blogs
  • Doin' DevOps
    Related Topics
  • developer tools
  • developers
  • market
Show more
Show less

DevOps Connect:DevSecOps @ RSAC 2022

The problem is, I like almost all of these tools! I genuinely get excited when I test each one. But unfortunately the vast majority of them will not survive. However there is a benefit of so many existing and new tools coming into the market, when observed holistically, you can see the trends of the market at large. Thus the trends in development process improvement. It’s a barometer of where software development is going.

The reason the space is getting so crowded is because we all believe software is eating the world, and developers are the masters. If you are an entrepreneur and do simple math on 20 million professional developers, the outcome looks good. But when you get into the details of the number of tools, the way development teams pick tools, and the shift of power to front-end developers. It gets sticky.

Focus on the categories of tools

The key is, don’t get caught up with one tool, rather the category of tools. There are several listings of categories out there, but LeanStack.io is my favorite. If you are just trying to learn the market, always keep in mind how fast it’s changing. While the general categories of tools remain the same, the tools themselves are in flux. Just pick a vendor site and watch it over a six-month period. My guess is you will encounter four different versions of messaging and value propositions. That is because they, like you, don’t even fully understand the market. Part of the problem is we are all guilty of getting caught up in the terminology, over the solution. The term DevOps is guilty of this as well, but heaven forbid they start talking about the Internet of Things (IoT) or NoOps.

Are they all going the same direction?

What has been very interesting is that many tools in the market are actually converging on the same point in space and time. For example, you would not think that a cloud IDE is in the same ballpark as a configuration management tool, but when you look at their roadmap and strategic vision, they are.  Many of the cloud IDEs are incorporating configuration management like functionality such as pre-configured VMs, and the ability to replicate those VMs by using Docker containers.

To extend it even further; the cloud IDEs like Cloud9 and configuration management tools like Ravello and VisualOps.io are converging with cloud monitoring tools like DataDog,  PaaS tools like OpenShift, and IaaS tools like CloudShare. It seems that what they are building is essentially a hub for all your development, monitoring, and dev environments. A one-stop shop for all the stuff around your DevOps process. PaaS services specifically are trying to be the Chinese menu of development tools, frameworks, and processes. Just look at how fast Azure and AWS are adding new services, as specific as machine learning. The eventually will compete with everyone listed above.

I suspect that the ISVs do not realize the point they are converging. It is common for ISVs to understand very well how their tool fits in their slice of the development process, but not how they fit in the entire process. And they certainly are not aware of each other’s roadmaps. It would be a full time job just to understand this. And many of the tools that do not compete today, might very well be soon.

Better Quality, Better Problem Solving

The good news for you is in this hodgepodge of stuff, eventually you will have fewer, very awesome, choices. The competition is fierce, which is forcing the vendors to focus on quality of product, UX, and solving real, not imagined, problems. After all once you subscribe to their vision, you have to do something with the tool. When the rubber hits the road is when tools win or lose.

To help you make better sense of what is going on, it is useful to think about all tools from the point of view of “what problem does it solve?” Instead of feature and functionality first. You will then understand how tools compete on value, not  feature-by-feature, which is a dangerous trap in the procurement process. And many of these tools can also be used outside of their specific value, so it can be confusing where they actually fit.

For example, I can use a log analysis tool like LogEnteries to set up alerts for system outages, but it is not a system alerting tool like VictorOps. When you do this, then you are measuring the complexity of using a tool slightly outside of what it is built for against the added benefit of using a tool built for the specific task. However, LogEnteries specifically has integrations with alerting tools, and took the additional step of bridging the gap for you. This is very important, which is my next point.

Find a vendor that has solved real problems, an spent the effort to understand the market and delivery pipeline, outside of their specific scope. In my opinion these are the vendors that will be around for the long haul because they are focused on customer results versus selling only a vision.

Too much of a good thing?

The developer tool market is an example of too much of a good thing(s). For organizations this quickly leads to analysis paralysis and pure frustration, to the point that organizations end up doing nothing. This is the most dangerous thing to do. The world is changing fast, and it will change you against your will, unless you move with it. I also do not recommend that organizations fall into the “buy IBM trap”. Sticking with large enterprise tools just because they are safe. These vendors know this habbit, and focus more on what portion of your budget they can get, over providing value. Nor do I recommend getting the latest thing that just appeared out of nowhere just because their concept just might be that magic bullet. Rather I would set all focus on integration and problem-solving. Does a tool solve a clear problem, and does it seamlessly integrate into the flow you designed? Do not expect the tool to design the flow for you.

Just this week a new APM tool appeared on my radar, and tomorrow I’m sure there will be a new testing one. Don’t pound your head against the desk just yet. Just remember you already have a system in place so most of the time there is no rush. Be proactive not reactive, and be deliberate not accidental about your tool selection. In all reality your biggest problem is not going to be the tool you choose. It will be the people and processes you put the tool around.

 

Filed Under: Blogs, Doin' DevOps Tagged With: developer tools, developers, market

Sponsored Content
Featured eBook
Hybrid Cloud Security 101

Hybrid Cloud Security 101

No matter where you are in your hybrid cloud journey, security is a big concern. Hybrid cloud security vulnerabilities typically take the form of loss of resource oversight and control, including unsanctioned public cloud use, lack of visibility into resources, inadequate change control, poor configuration management, and ineffective access controls ... Read More
« DevOps’ weakness and what it does best
Mobile App Development Will Soon Grow More Enterprise-Focused »

TechStrong TV – Live

Click full-screen to enable volume control
Watch latest episodes and shows

Upcoming Webinars

Closing the Gap: Reducing Enterprise AppSec Risks Without Disrupting Deadlines
Thursday, June 30, 2022 - 11:00 am EDT
Automating the Observer: Lessons From 1,000+ Incidents
Thursday, June 30, 2022 - 1:00 pm EDT
Continuous Deployment
Monday, July 11, 2022 - 1:00 pm EDT

Latest from DevOps.com

Moving From Lift-and-Shift to Cloud-Native
June 30, 2022 | Alexander Gallagher
The Two Types of Code Vulnerabilities
June 30, 2022 | Casey Bisson
Common RDS Misconfigurations DevSecOps Teams Should Know
June 29, 2022 | Gad Rosenthal
Quick! Define DevSecOps: Let’s Call it Development Security
June 29, 2022 | Don Macvittie
Chip-to-Cloud IoT: A Step Toward Web3
June 28, 2022 | Nahla Davies

Get The Top Stories of the Week

  • View DevOps.com Privacy Policy
  • This field is for validation purposes and should be left unchanged.

Download Free eBook

The State of Open Source Vulnerabilities 2020
The State of Open Source Vulnerabilities 2020

Most Read on DevOps.com

Cloudflare Outage Outrage | Yet More FAA 5G Stupidity
June 23, 2022 | Richi Jennings
Developer’s Guide to Web Application Security
June 24, 2022 | Anas Baig
What Is User Acceptance Testing and Why Is it so Important?
June 27, 2022 | Ron Stefanski
Chip-to-Cloud IoT: A Step Toward Web3
June 28, 2022 | Nahla Davies
DevOps Connect: DevSecOps — Building a Modern Cybersecurity ...
June 27, 2022 | Veronica Haggar

On-Demand Webinars

DevOps.com Webinar ReplaysDevOps.com Webinar Replays
  • Home
  • About DevOps.com
  • Meet our Authors
  • Write for DevOps.com
  • Media Kit
  • Sponsor Info
  • Copyright
  • TOS
  • Privacy Policy

Powered by Techstrong Group, Inc.

© 2022 ·Techstrong Group, Inc.All rights reserved.