staging-devopsy.kinsta.cloud

Category: Application Performance Management/Monitoring

  • Testing Automation has Become a Necessity – Techstrong TV

    Testing Automation has Become a Necessity – Techstrong TV

    Guljeet Nagpaul, Chief Product Officer for ACCELQ, explains why automating testing has become a necessity. The video is below followed by a transcript of the conversation.

    Mike Vizard: Hey, guys. Thanks for the throw. We’re here with Guljeet Nagpaul, who is chief product officer for ACCELQ, and we’re talking about all things related to testing. Guljeet, welcome to the show.

    Guljeet Nagpaul: Thanks, Mike. Thanks for having me.

    Mike Vizard: Do you think the whole testing focus has increased somewhat in the last few months with the whole shift to digital transformation, and people are trying to develop more applications than ever? I think it’s kind of critical to get it right the first time these days. I think the tolerance for experimenting on end users, especially in a digital business context, is a lot lower, but is there some sort of fundamental shift going on with testing that you’re seeing?

    Guljeet Nagpaul: Yeah, both things you mentioned, Mike, are right on. The digital transformation has clearly been on steroids almost now for the past couple of years, since we’ve seen the world kind of changing around us with remote work. A lot of processes which were even in healthcare and financial space, which were kind of buried with red tape, all of them have been kind of almost on steroids to become more automated, and organizations have had to kind of put their transformation objectives much more on a fast track. That, like you rightly said, automatically leads to having to ship the applications must faster to their customers to run their businesses faster. The need for automated testing for shipping their software faster gets kind of even more critical.

    Mike Vizard: Where is that automation taking place? Are we automating tests for the developer as we shift things left, or is the automation more in the CI/CD DevOps platform, and we’re trying to automate it there because that may be the place where the application itself comes together; otherwise, each developer is testing a small piece of something but maybe not the whole thing and then?

    Guljeet Nagpaul: That’s exactly right. We live in a world where there is an app for everything. That has been true from a consumer perspective, but now, interestingly, that is more so true on our enterprise application side. Back in the day, if you remember, we had a couple of ERPs and then we had some homegrown systems, and that’s kind of how the IT landscape of organizations looked. But now, with the onset of cloud apps, with packaged applications, with vertical applications, there is an app for everything for enterprises to be able to go more automated. What that translates to is a highly-integrated enterprise application ecosystem. What that means is unit testing or just shifting left in terms of automation is not going to be enough.

    You would really need that end-to-end validation, and each app has at least five upstream and five downstream integrations, which means the real automation, and the real customer experience in terms of your end-to-end workflow has to be automated across the board. That DevOps CI/CD pipeline you talked about, that gets even more kind of focused in terms of being able to validate that end-to-end workflow. That is kind of where we are really seeing the need for automation, more than kind of what we would have thought from a shift-left perspective. That’s absolutely necessary because you want to build a stronger product. You don’t want to be reactive in building a strong product, you want to bake quality into the product, but then downstream, you want to make sure your end-to-end workflows work as designed in terms of an integrated end-to-end system.

    Mike Vizard: How far down the path are we to achieving that goal, because I think somewhere along the line everybody maybe thinks that testing is somebody else’s job, but what’s the maturity level of testing these days in terms of automation?

    Guljeet Nagpaul: Yeah, like with a few different functions within our IT, we kind of see kind of a full circle come back, right? A lot of testing was starting to get perceived as commoditized, and we saw a lot of testing kind of getting shifted from that perspective as a cost function. But, quickly, organizations realized that without continuous testing, there is no continuous delivery, and that’s really the crux of it, that if you can’t have a dependable, reliable, continuous test automation to bridge that gap between your dev and ops, there is no DevOps, because that’s the key bridge between your dev and ops, right? With that notion, the testing maturity level has struggled.

    To be honest, a lot of automation approaches, and I spent over a decade with HP, a lot of traditional automation tools and approaches have focused more on silos because our app ecosystem was not that integrated back in the day, right? It used to kind of have integration, but not at the level that you’re seeing today, so the need for an automation approach that can span across these technology stacks is now kind of more new and is now more critical. The testing maturity in terms of what approaches are out there has struggled, but we are now starting to see customers really needing that across-technology-stack approach, and that’s kind of where ACCELQ has a sweet spot.

    Mike Vizard: Do you think the rise of micro-services is forcing the automated testing issue because we’re reaching a level of complexity that can’t really manually test all these things?

    Guljeet Nagpaul: I would say yes. Just in the last five years, interestingly, Mike, we have seen API testing as part of critical proof-of-concepts to when customers come and try a platform like ACCELQ out in terms of seeing whether it’s fit for their needs or not. Just in the last five years, we have seen at least three times the interest in making sure that APIs can be validated apart from their UI. But, like I said, it’s really more about how that validation can be done across the technology stacks. To give you an example, a healthcare customer of ours, one of the top five companies in the world, they had a use case where a patient walks into a pharmacy to put in their prescription, but now with COVID and everything, the automation is kind of boosted.

    Now they can key in their prescriptions directly through their mobile apps connected to their healthcare providers. Once that prescription is keyed in, there are at least 20 downstream processes that are kicked in, including mainframe systems, micro-services, a database that’s maybe sitting on a cloud, but then coming back to a pharmacy system which is still living in an old-school desktop world. The real demand, what we are seeing is kind of this across technology side, because that’s what the user experience is.

    Mike Vizard: How smart can testing get? We hear a lot about artificial intelligence these days. Will the whole thing become automated or what will be the role of the tester, per se?

    Guljeet Nagpaul: Yeah, that’s a great question. AI unfortunately gets thrown around very loosely these days, especially more so with talking about how AI is the platform. We have looked at it always as a tool in our toolkit. Ever since the inception of our platform, we have always looked at how we can leverage AI to make things more efficient as opposed to saying AI is the platform. We have always looked at it more realistically. If you forget AI for a second, that’s kind of how as people we have embraced technology. In various aspects, technology has enabled us to increase our throughput regardless of which process area are we picking, and that is kind of how we see AI. If it’s leveraged accurately, it’s going to increase the throughput of our test engineers. It is going to increase the throughput of our automation engineers. At various process areas that then test automation life cycle, that’s kind of how we’ve looked to leverage AI.

    Mike Vizard: Do you think we’re approaching a point where the number of applications being built is overwhelming the testers that are out there, and the pace of that work is getting to a point where they become a bottleneck?

    Guljeet Nagpaul: Yeah, I was having a discussion on the same lines with our Forrester analysts, and one of the interesting discussion points around that was we all as testers within the DevOps space have to almost take a step back and understand what needs to be tested before going about kind of in the traditional manner testing it. Yes, it can be overwhelming with so many apps coming together so quickly in terms of being able to serve our businesses, but a lot of these apps which are getting shipped for our businesses, for these organizations are cloud apps, or maybe packaged apps, vertical apps. All they need is configuration and integration with other apps, and then they can kind of start doing the job in terms of the outcome that the businesses are expecting. It almost needs some level of refactoring, a new mindset when you think about in this new world of facts, how should you be testing and what you should be testing to get the maximum bang for your buck, so it’s easy to get overwhelmed. But, with automation and the right approach to what needs to be tested, you can kind of be more efficient with your efforts.

    Mike Vizard: Who writes the tests these days? It seems to me a lot of time and effort has been spent on creating the tests, and, as we automate that process, can we get to the point where the machines can create the tests? I mean, to what degree do I need to create the tests versus run the tests?

    Guljeet Nagpaul: Yeah, that’s an interesting point. The way we look at it is, unfortunately, the way testing and automation specifically has evolved, the traditional approaches I talked about, they have lived on two ends of the spectrum, Mike, one end of the spectrum being very record-and-playback oriented. But, we have seen in the past 20 years that automation is not new; it has been around for at least a couple decades. Back when we released Windrunner, and I don’t know if that rings a bell, I was part of the original Windrunner team, at one point we had about 70 percent market share, and record-and-playback was the thing automation. But, in the last ten years, there have been a plethora of tools which have come on the same lines of record-and-playback but we have seen that they just are not scalable enough to deal with the changing technology stack. They are just not real-world enough to work across technology stacks, and a lot of other things in terms of design challenges and so on.

    The other end of the spectrum that we live in is open source, and you kind of pointed to how testing had been shipped out as a cost function, and open source made a big kind of wave into the test automation area, but that became a specialist function. The reason this is important, to your point of the question, is when automation has become a specialist function, because we have seen about 60 to 65 percent market share ‒ Gartner did a survey of open source taking over a lot of kind of testing and automation approaches. But, when you see that, basically it becomes a specialized function, and all my testing team is a mixed bag of testers, maybe some automation engineers, but a lot of business subject matter expertise. If you really want a strong test approach, you need to make the subject matter experts people who understand business rules.

    That needs to be validated as part of the automation, and that’s kind of where both ends of the spectrum have to meet, where a non-technical, non-specialized tester should also be able to be part of that automation. That can only become if our platforms are smarter, right? Maybe depending on that suite to be adaptable, maybe bridging machine in certain cases, to your point, to be able to write smarter test cases, to basically have your automation more leaner and meaner so that it can do more with kind of less in terms of authoring and design changes and change with so many releases happening, so absolutely. I mean, testing has to get out of the specialized function role.

    Mike Vizard: All right. We hear a lot of focus these days on security, of course. Do you think that security ultimately will become part of a quality assurance testing process, because it’s not clear to me that those are two distinct functions anymore. They might be joined at the hip in some fashion.

    Guljeet Nagpaul: I sure hope so. The strongest of the software and the organizations just in the past one year, we have seen outages which we would have never imagined, right? AWS went out a few times, Facebook, Meta, went out a few times, and you name it. Security has to become an integral part, and we are seeing this more and more. As part of functional regression tests, customers want to have those security regression tests. Security lived in two worlds until now. One was static code analysis, which is, “Let’s do static code analysis,” which is good, it’s kind of like shifting left to your unit tests. Yes, you’ve got to find your vulnerabilities right when your code is written, but, once the code is in action, what vulnerabilities come can be a different game.

    Static code analysis is where security lived, and, like you said, that’s why it was a little bit in the different world. Then, you had dynamic security firewalls, which are kind of more glorified firewalls. But, in the middle, that functional testing, leveraging security validation is a gap in the industry right now, and we are certainly looking to fill that gap. We have already helped a lot of Fortune 100 customers, including certain financial services customers, fill in that gap, leveraging the functional automation approach because they’ve had some solutions around these two things but functional is where it needs to get seated into, right? Like you said, it has to become mainstream into the testing and function automation space.

    Mike Vizard: All right. Other than hanging out on your website, what is your best advice to folks about how to get to this continuous testing nirvana, I guess, because, ultimately, time is money, so every time an application has a disjoined experience, somebody is losing money somewhere, right?

    Guljeet Nagpaul: Totally. Automation first. Automation first is the key. A lot of traditional mindset still remains at, “Let’s write my manual tests and let’s write the manual tests them into convert them into automation.” The mindset has to change. The organization approach has to change to automation first. For automation first, you can only do automation first if it’s not a specialist function. Don’t get caught up in getting buried into a technical debt. You don’t want a million lines of code to test a million lines of code, right? Figure a more robust solution and go automation first, and that will set you on the right path.

    Mike Vizard: All right. Guljeet, thanks for being on the show.

    Guljeet Nagpaul: Thanks, Mike. Thanks for having me.

    Mike Vizard: All right. Back to you guys in the studio.

  • Heat Cooks Twitter DC | AI Will Kill All Humans | Patreon Layoffs, CSAM Claim

    Heat Cooks Twitter DC | AI Will Kill All Humans | Patreon Layoffs, CSAM Claim

    Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.

    This week: Twitter is in a “non-redundant state” thanks to a hot summer, AI is likely to eliminate us, and Patreon fires 80 staff amid nasty allegations (TW: Child safety). (more…)

  • New Relic Survey Unearths Observability Challenges

    New Relic Survey Unearths Observability Challenges

    A New Relic survey found only 27% of respondents have achieved full-stack observability with only 5% claiming they have a mature observability practice in place. A third (33%) of respondents also said they still primarily detect outages manually or based on complaints, the survey found.

    The global survey polled 1,614 respondents, including 1,044 practitioners and 570 IT decision-makers and was published today by New Relic.

    On the plus side, the survey also found nearly three-quarters of respondents said C-suite executives in their organization are advocates of observability, and more than three-quarters of respondents (78%) saw observability as a key enabler for achieving core business goals.

    However, more than half (52%) of respondents said they experienced high-business-impact outages once per week or more and 29% said they take more than an hour to resolve those outages.

    Peter Pezaris, senior vice president for strategy and user experience at New Relic, said a big reason it takes so long to resolve issues is the time required to determine the root cause of issues using multiple tools. A full 82% of respondents said they use four or more tools to monitor the health of their systems. Only 7% said their telemetry data is entirely unified and only 13% said the visualization or dashboarding of that data is entirely unified. Nearly half of respondents (47%) said they would prefer to have a single, consolidated observability platform, but only 2% said they currently used one tool for observability.

    New Relic, of course, is making a case for a single observability platform that spans both the application environment and the underlying infrastructure an application depends on. Today, most IT teams are using a wide range of tools to monitor infrastructure and applications.

    Nearly all respondents said by 2025 they expect to deploy capabilities like network monitoring, security monitoring and log management, as well as Kubernetes monitoring. More than a third (36%) believe observability increases their productivity and enables them to find and resolve issues faster. Just under a third (32%) said observability enables cross-team collaboration, while more than a quarter said observability improves their ability to innovate.

    Nearly three-quarters (72%) expected to maintain or increase their observability budgets next year. More than half (52%) of respondents, including 57% of C-suite executives, expected observability budgets to increase over the next year. A total of 14% of all respondents and 16% of IT decision-makers expected to increase observability budgets significantly or extensively. IT decision-makers anticipate needing observability most for artificial intelligence (51%), internet of things (48%), edge computing (38%) and blockchain (36%) in the next three years.

    It’s still early days as far as the adoption of observability platforms is concerned, but it’s apparent that as application environments become more complex the plethora of monitoring tools that DevOps teams rely on will need to be streamlined. Observability platforms promise to unify logs, metrics and traces in a way that makes it simpler to launch queries to identify the root cause of an issue.

    The rate at which DevOps teams will embrace observability will naturally vary, but the biggest obstacle might not be the platforms themselves. Instead, the issue is understanding what queries can help DevOps teams better understand the root cause of an IT issue before there is a major disruption. In the long term, it’s expected that machine learning algorithms will leverage the data collected by observability platforms to automatically identify issues that might lead to a disruption long before it actually occurs.

    In the meantime, the hope is that monitoring tools will give way to observability platforms that will make managing complex IT environments much simpler for all concerned.

  • How’s Facebook Work? They Don’t Know! | Cali. Pay Law | NASA RISC-V Launch

    How’s Facebook Work? They Don’t Know! | Cali. Pay Law | NASA RISC-V Launch

    Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.

    This week: Facebook engineers admit they’ve no idea what Meta stores (or where), California requires job ads quote salaries, and RISC-V will power future NASA spacecraft. (more…)

  • Study: Real-Time Data Has A Transformative Effect

    Study: Real-Time Data Has A Transformative Effect

    We all know that data is the heart of the modern digital business. And real-time data is arguably the next evolution—having up-to-date data can empower energy savings and optimizations to reduce cost. Real-time data processing also aids fraud detection and improves health care responsiveness.

    Especially in DevOps, access to real-time data is necessary to reduce incident response time and inform ongoing SRE objectives. Leveraging performance data can also empower future decision-making and open new revenue opportunities. In essence, real-time data can have a transformational effect on the operations of a digital business.

    DataStax and ClearPath Technologies recently released the 2022 State of the Data Race Report. The study found that the majority of data leaders are using real-time data to create additional value. The report also suggested that working with cutting-edge real-time data technologies increases developer experience, which is good to maintain amid ongoing talent shortages.

    Below, I’ll review the key findings from the study to infer how organizations can effectively use these technologies and how they can mitigate roadblocks that arise throughout the process.

    The State of the Data Race

    Simply put, customers expect real-time experiences. And it’s not only the end consumers—developers are also increasingly accustomed to building in this modality. This is evidenced by the recent rise of asynchronous, event-driven architectures. The survey depicted how fundamental real-time data is to modern software, finding that 78% of respondents agreed that it is a “must-have,” not just “nice-to-have.”

    The investment appears to be paying off. A full 71% of all respondents said they can directly tie revenue growth to real-time data. Not only does it seem to have a transformative impact on revenue growth, but it enhances productivity, too—66% of real-time data-focused companies agreed that developer productivity has improved. Naturally, the report found that developers are the ones most likely to be working with real-time data.

    Although modern databases and real-time data processing tools are more readily available these days (and open sourced), the maturity of data handling is not homogenous. Based on the classifications of this report, “data leaders” made up only 10% of respondents.

    Roadblocks to Value

    The road to data maturity has a few obstacles that could limit adoption. First is data complexity—33% said this is one of the biggest barriers to leveraging real-time data. This was closely followed by controlling data costs (32%), data accessibility (30%) and available skillsets (28%).

    Most notably, a skills gap continues to be a commonly cited hindrance throughout industry reports and across technology niches. Interestingly, a lack of in-house talent rises slightly higher in organizations with a high real-time data maturity. Those surveyed in this category said that their top barrier is finding the appropriate skills in their business unit.

    Cybersecurity is also a top concern—51% say security challenges are a big concern when it comes to the use of real-time data. As the report surmised, the business-critical nature of real-time data raises its worth as a commodity and area for attack. Furthermore, amid new data sharing regulations, IT departments are now under more pressure than ever to uphold data security and avoid the leakage of sensitive personal information.

    Unlocking Real-Time Data

    This area has a lot of potential; 86% of developers at organizations with a strategic focus on real-time data said that the “technology is more exciting than ever,” the report found. Real-time data is beginning to be applied at the edge, where AI/ML can be trained to give a more responsive advantage to modern applications. Yet, organizations must prioritize its adoption and mitigate the roadblocks mentioned above to unlock the benefits of real-time data.

    Prioritizing real-time data will take more than tools—it will take vision. According to the study, those who created more value with real-time data initiatives were found to:

    • Have clear product owners
    • Have business unit accountability of data
    • And have department representatives working together in a cross-functional team.

    As you can see, these foundational goalposts have less to do with technology and more with lucid leadership and collaboration. That being said, an investment in the appropriate tooling is undoubtedly required to achieve real-time data.

    For example, this tooling might encompass NoSQL databases optimized for real-time or Apache Cassandra for high throughput. The transition to real-time will likely require streaming and messaging technologies as well. Less obvious, however, is an API layer to sit between the applications and the database. This element could greatly help open data accessibility in a standardized fashion.

    The State of the Data Race: Final Thoughts

    Working with real-time data can be a differentiator and have a transformative impact. As a result, most developers and leaders see real-time data as an exciting area. Yet, organizations must reduce data siloes to open up data access to realize its benefits. It will also take collaboration between data scientists and business divisions to construct meaningful outcomes.

    The State of the Data Race report surveyed 500 leaders across various industries. Above, we’ve summarized the key points from the survey. Readers are encouraged to pick up a copy for more nuanced data points and further commentary.

  • Lightstep Extending Beyond Observability with Lightstep Incident Response – Techstrong TV

    Lightstep Extending Beyond Observability with Lightstep Incident Response – Techstrong TV

    Ben Sigelman and RJ Jainendra discuss ServiceNow’s latest announcement that Lightstep is extending beyond observability and creating a differentiated portfolio for app development with the general availability of Lightstep Incident Response, helping make organizations’ digital products and services more reliable and resilient. The video is below followed by a transcript of the conversation.

    Alan Shimel: Hey, everyone. Welcome to Techstrong TV’s segment today. We’ve got some breaking news I wanna bring to you, and I’m really happy to be joined by two gentlemen who are gonna tell you the news. I’ve had the pleasure of having them on before.

    They’re two really bright guys from ServiceNow. Let me introduce you to Ben Sigelman and RJ Jainendra from ServiceNow. RJ, I think I left out an “N” somewhere in that second or third syllable, but we’ll let you correct it. I’m gonna ask you to go first, RJ. Introduce yourself to the audience.

    RJ Jainendra: Hey, Alan, good to see you again. And no, you got it right, RJ Jainendra. I’m a VP and GM at ServiceNow, unlocking product growth at the company. It’s great to be here.

    Alan Shimel: Excellent. It’s good to see you again. And of course, RJ, you’re general manager, but you’re the portfolio you are GM with includes observability. I believe it includes value stream as well, yeah?

    RJ Jainendra: So, ServiceNow does have offerings for value stream management, which brings together a number of different product lines. Our IT business management, which we recently rebranded as Service Portfolio Management, SPM, that’s one. The second is it also brings in elements from devops and ITSM offerings to provide a value stream management.

    But I’m here today to talk about Lightstep Incident Response. That’s the product line that we’ve been building out for a little while now, and ready to launch here today.

    Alan Shimel: Absolutely, so, we’re gonna talk about Lightstep. Gotta have Ben here. Ben, welcome. Why don’t you give people a little bit of – give the folks a little bit of your background?

    Ben Sigelman: Yeah, thanks, Alan, for having us. So, I’m Ben Sigelman. I was one of the cofounders at Lightstep and was the CEO up through last year, when we were acquired. ServiceNow wasn’t willing to let me remain the CEO of ServiceNow after the acquisition, so now I’m also a VP and GM, along with RJ. 

    Lightstep’s brand and certainly our products and many aspects of our culture have actually been intentionally retained as part of the acquisition, and the brand has actually been expanded to be a multi-product brand, which is what we’re talking about today.

    Most of my day-to-day is spent doing a combination of thinking about the product vision for observability specifically within Lightstep as well as the longer-term strategy within ServiceNow, and what we can do for our customers by unifying the world of ServiceNow with the world of high-volume customer-facing applications that Lightstep tends to play in.

    Alan Shimel: Absolutely. I think the ServiceNow team already has a pretty good guy in its CEO, but hey.

    Ben Sigelman: I actually, when I talked to Bill during the acquisition, I told him he had my condolences for being a CEO of a much larger company. I knew how stressful it was for Lightstep, so I can only imagine what it’s like for him. But he’s a fantastic guy.

    Alan Shimel: Absolutely. Yes, until you’ve been a CEO, and I don’t care whether it’s a really, really big company or a really small company, yeah, it’s a lot. Anyway, guys, let’s talk Lightstep, observability. Let’s talk about the expansion. Just to level-set things – you both referenced it – Lightstep was one of the leaders in this observability revolution or wave that we saw overtake the industry, let’s say, in the last three, four years, certainly, it really caught fire.

    Lightstep, Ben and your two cofounders, I believe, all came from Google, and really in many ways helped initiate the whole observability revolution there. Then leveraging open source and working with open source, open telemetry, et cetera, really built quite a community and following.

    ServiceNow, one of the most dynamic companies in our industry, recognized this and made Lightstep and observability an important part of the ServiceNow offering. But from what I’m hearing and reading between the lines is why stop there, right? There’s more.

    There’s more that the marriage of ServiceNow’s know-how market intelligence and skill set, and the Lightstep platform can do more, and today marks a significant expansion of that. So, you’re both GMs. Who wants to go first to talk about what this new expansion is?

    RJ Jainendra: So, I can talk a little bit about what the expansion is, and Ben can, I think talk through why it makes a ton of sense, what we’re doing. The thing that we see that’s happening in the market is just the amount of investment going into what’s been called digital transformation.

    It’s just increasing significantly, and I think by some accounts, IDC forecast, it’s gonna be something like north of $10 trillion cumulative by 2025. So what Marc Andreessen said a long time ago, I think it has come to pass, which is every company is a software company, and increasingly, with the adoption of cloud, organizations are prioritizing cloud operations and software development teams they build, and they run these millions of new customer-facing, revenue-generating applications and services.

    So from that perspective, the SREs and developers who really are responsible for keeping applications reliable and resilient, they really start impacting the business outcome. That’s where if you have incidents that occur, maybe it’s a bug or some sort of an outage or poor performance, it has a major impact on revenue, on customer loyalty, on the brand perception.

    That’s why you see the option in the market to introduce a new offering around incident response, which really leverages the power of the ServiceNow platform, but then it brings together the observability capabilities that Lightstep has into sort of a holistic offering that we can bring into market to help customers become more proactive and more effective in addressing issues. Ben, do you wanna add to that in terms of your perspective from an observability side?

    Ben Sigelman: Yeah, for sure. I think the way I’d explain it is observability, Alan, I would agree with you that it’s the wave, but it’s a very confusing, diffuse – it’s a body of water right now that can be hard to wrap your head around, and you frankly have a lot of what I would call legacy observability companies trying to take what they have and call it observability, because that’s easier than reforming it.

    So, it might be helpful to spend just one very quick, 30 second snippet talking about what observability actually is, architecturally. You have some layer at the bottom of integrations and data acquisition. You mentioned Open Telemetry earlier. The Lightstep Incident Response product that we’re announcing today also has an integration ecosystem built around it.

    But you have the acquisition of data, you have some kind of data platform where you store that, which I’m not gonna talk about in detail right now but I think is an interesting topic, slightly far afield. Then you have workflow been made with your full knowledge and workflow built on top of that, and that’s where the actual value is delivered.

    A lot of the conversation around observability today is that you have a silo for your metric system, a silo for your logging system. Maybe you tack on some kind of tracing or PM system, and then you integrate them in the browser.

    Then you also have this Incident Response thing over there. That’s some other vendor, and it does not make any sense. When we talked with our customers, the three things they are prioritizing are overall performance, velocity, and actually, most importantly, incident response and timed resolution.

    It’s the most important thing for observability. Then you have not just a separate tab, but a separate product to do incident management and incident response, which is not sensible from a workflow standpoint.

    So, for the brand, this is a very obvious and natural thing, to have incident response and observability integrated into a single experience, especially incident response where seconds matter, and a context switch like that is very expensive. So, anyway, that’s why this makes a ton of sense to us.

    It goes right at the heart of the MPTR problem, to have a single platform to manage the full lifecycle of incident management on the observability side and on the incident response side.

    Alan Shimel: Absolutely, and you know, Ben, to your point – well, first of all, I think you call them “legacy observability vendors.” Really, they’re APM, application performance management vendors who – 

    Ben Sigelman: Or infrastructure monitoring vendors, more to the point.

    Alan Shimel: Right, or infrastructure – 

    Ben Sigelman: It’s not the –

    Alan Shimel: You know, everyone loves a good name.

    Ben Sigelman: Right.

    Alan Shimel: A company I had started, we had come out with a product that Gartner would later name the category NAC, network access control. We had some stupid name for it before, but Gartner, you know, did that.

    All of a sudden, out of the woodwork, all these people who were doing totally different things started calling what they do NAC. A very similar thing happened with observability, right?

    Ben Sigelman: Yeah.

    Alan Shimel: Anyone who’s doing monitoring, all of a sudden it was observability. But I think, also to your point, was that observability got siloed into just observing. Almost by definition, observing, observability, is not actionable. It’s almost like observability is a passive word, where actionable is active word.

    Ben Sigelman: You’re exactly – that’s a very good point. If you go – I tend to be a little academic, but I think this is an interesting point. Observability really originates from control theory in the 1960s, and it was this smaller, kind of lesser cousin to controllability, which is kind of what you’re talking about.

    Controllability is really the thing that matters. If you can control a system, there are scientific ways of talking about that. Mathematical ways talking about that. To a certain extent, you can think of incident response as being the controllability side of what we’re talking about here.

    It’s like we’re making insights from observability actionable with the Incidence Response product, and that’s a really important part of actually closing the loop on the control theory of modern distributed systems. That’s a great insight that you’re making, Alan.

    Alan Shimel: Yep, thank you. Every once in a while, even a blind squirrel finds something, right? So, RJ, let’s talk about this. ServiceNow is not a trivial size company. To decide that – you didn’t really have an incident response solution in market prior to this, as far as I know. I’m not an expert on everything ServiceNow, but I’m not aware of it.

    To say okay, we are going to build this in as the logical next step in the Lightstep platform, just the inertia sometimes in an organization your size, it’s difficult. Let’s hear from your point of view what it took to make that happen, turn that ship.

    RJ Jainendra: Yeah, so, Alan, we actually do have capabilities in the ServiceNow platform through our IT Service Management and IT Operation Management products, around things like event technology around event correlation, being able to take large-scale number of events from the observability tools and bring them in and understand what those events mean.

    We also do have functionality in ITSM around notifying the right person. But really, the ServiceNow technology, we have great adoption with IT organizations and a large number of customers. But what we’re seeing really is as our customers are going through the digital transformation, they’re reorganizing, and the product teams that are out there are the ones that are sent to adopt these technologies on observability. 

    That’s why we felt that we wanted to bring an offering into market that could be adopted by teams. So, the entire experience for Lightstep Incident Response is as a modern SaaS application. If you’re a developer on the team – and what we’re finding right now is a lot of our initial customers are smaller companies.

    They’re early growth-stage companies that are post-revenue. They have customers, they wanna make sure that their systems are highly available for them. So, what we’re finding is that they can come online, they can sign up, and within a few seconds get access to the system, start using it, and if they see value, then they can swipe the credit card and they’re off to the races.

    So, very much a different motion, really suited to how teams out there in smaller companies are adopting technology. And of course, the startups of today are the ones that become the unique ones tomorrow, so that’s what we’re doing that’s a little bit different. But for ServiceNow customers, they need to have those capabilities within the ServiceNow platform.

    Alan Shimel: Excellent. So, guys, let’s talk – if you don’t mind, I gotta do a little meat-and-potatoes here. You guys announced this today. Is it available? When will it be available?

    RJ Jainendra: It is available today on Lightstep.com. So, we have had the product in the market for a little bit. We did a soft launch earlier last year. So, it’s been battle-tested, and we have a number of customers that have come online. They’re using it in production. So, it is available today, and it doesn’t take more than an email to sign up and get going.

    Alan Shimel: What’s the offering? How is it priced? If you’re an existing Lightstep or ServiceNow customer, how do you – firing off an email, yeah, but how do I – what’s this gonna set – you know, what’s involved here?

    RJ Jainendra: Yep, so, actually, it isn’t a whole lot more complicated than what I just said, which is just as you sign up for a lot of consumer-type services online, developers and SREs can get started with an email. We do have a couple of different tiers. So, we do have a free tier, where if you are just getting started and you may have just a couple of services that you’re monitoring and addressing issues for with Incident Management, that’s free.

    Now, if you’re gonna start scaling up and you have more than two, that’s when the pricing kicks in. We are taking an innovative approach in terms of pricing, which is it’s based on usage. So, we look at the number of active services that a team has, and then we charge by the number of active services, which is very different than some of the other solutions in the market, which charge by the number of developers that you have in the system.

    We really think that we wanna align to the value that our customers are trying to deliver, which at the end of the day, if you’re a developer or if you’re an SRE, your goal is to deliver these resilient, reliable services. So, we feel that aligning to the services – and no matter whether you wanna bring in your whole team or maybe you also wanna bring in sort of extended folks into the solution to be able to collaborate and figure out what the problem is.

    So, we don’t wanna let the number of seats become an impediment. We really would like to have our customers drive this notion of service ownership across the entire team, as opposed to being owned by a few key people, because there’s a lot of burnout that happens.

    So, there’s different models, but after a 30-day free trial, if customers see value and they have these active services, that’s when the billing kicks in. It’s all done by credit card, so it’s a fairly streamlined experience.

    Ben Sigelman: I will add that Lightstep observability experimented with seat-pricing several years ago and abandoned it, because it’s very important for us to deliver value to our customers, and there’s nothing quite as frustrating as hearing people say, oh, we really wanna be using this, but we don’t wanna add another seat license and blah, blah, blah.

    I think especially in large organizations, for incident response, it’s just immensely frustrating to be kind of wanting to use something, like, sporadically, maybe once every couple of months, and then being blocked out of the application because of concerns over seat licensing.

    So, with Lightstep Incident Response, there’s really no restriction on that. You can have a thousand-head engineering organization and put them into the product, and that doesn’t change your bill at all. The pricing is more correlated to the value that we believe we’re delivering, and the resiliency of the services themselves.

    Alan Shimel: Sure. So, I’ve gotta ask the question. I’m gonna ask it of you, Ben. This is a step of taking observability down the control, as you mentioned, the control path, for full control. What’s next?

    Ben Sigelman: That’s a good question. We’re gonna move into crypto. No, I’m just kidding, we’re not.

    RJ Jainendra: Join the crowd, yeah.

    Ben Sigelman: I’m not here to talk about specific products, but directionally for Lightstep as a brand, I think that we see there’s an entire ecosystem out there of – I think you can kind of extrapolate from where I was going with the workflows.

    I think where we – actually, Lightstep and ServiceNow are incredibly similar in our belief in workflows being paramount, and there are a number of other workflows where people have to do a major context switch when they’re involved with the work of making reliability and velocity happen for cloud-native applications and for customer-facing applications. That’s kind of a hint as to, I think, where we’re headed with future products. But this certainly isn’t the last one yeah.

    Alan Shimel: Great. Guys, we’re way past 15 minutes, but for people who wanna go get Lightstep and Lightstep observability up and running today, where do they go?

    RJ Jainendra: www.Lightstep.com.

    Alan Shimel: That’s what I was looking for, RJ. Hey, gentlemen – Ben, RJ – thanks so much for coming on and breaking this exciting news and offering, new offering from the Lightstep/ServiceNow team. Keep us posted, best of luck with it. It sounds like a winner. We hope to hear more soon.

    RJ Jainendra: Thanks, Alan.

    Ben Sigelman: Thank you, Alan.

    Alan Shimel: Thank you, guys. All right, go check it out, Lightstep.com, their new observability and incident response now as part of it, from ServiceNow. We’re gonna take a break. We’ll be right back.

  • TidalScale Enables Hot-Swapping of Failed Servers

    TidalScale Enables Hot-Swapping of Failed Servers

    TidalScale has updated its namesake software for automating server management to include the ability to detect and prevent impending failures and enable IT teams to hot-swap another server.

    Version 4.1 of TidalScale also adds server wear leveling and preventative health checks that identify servers that should be replaced based on their remaining estimated life span.

    TidalScale CEO Gary Smerdon said that capability is especially critical given the high rate of DRAM memory failure that results in a high rate of downtime caused by server failures. The latest update to the company’s software-defined server management software reduces the failure rate in on-premises or cloud computing environments by a factor of 100 to ensure 99.999% uptime, he said.

    The company also announced that its software is now available on the Amazon Web Services (AWS) Marketplace.

    TidalScale employs machine learning algorithms to aggregate and virtualize CPU cores, memory and I/O across servers to present operating systems with a single software-defined server. That makes it possible to hot-swap individual servers to ensure availability.

    The single biggest cause of downtime in IT environments is memory failures; they are now 100 times more likely than they were a decade ago, noted Smerdon. In most cases, the root cause of the issues is the demands of modern applications running on legacy infrastructure that was not intended to support the latency requirements of those applications, he added.

    That issue can be especially acute in cloud computing environments where infrastructure is often shared by multiple applications, said Smerdon.

    It’s not clear at what rate cloud service providers are replacing legacy server infrastructure, but the ability to determine when to replace infrastructure gives IT teams an added measure of control over servers regardless of where they are deployed. The biggest issue, of course, is not so much replacing a server as it is determining which one actually failed. It often takes longer to identify a failed server than it does to bring a new one online.

    TidalScale is made available by both cloud service providers and manufacturers of servers used in on-premises IT environments, but it needs to be configured and deployed by an IT team. The overall goal is to not only increase system availability but also reduce the total cost of IT by managing infrastructure more efficiently across the life span of a server, said Smerdon. Some IT teams routinely replace servers at specified intervals, regardless of actual usage, to avoid downtime. TidalScale enables IT teams to determine which servers to replace based on the actual wear within the context of a self-healing server farm, he noted.

    Given all the things that might potentially go wrong in an application environment, not having to worry about server failures should enable DevOps teams to spend more time optimizing application performance.

    In theory, of course, modern applications based on microservices should be able to reroute calls to application programming interfaces (APIs) anytime a server becomes unavailable. However, over time it’s not uncommon for single points of failure to emerge as applications are updated. In the meantime, the majority of applications running today are based on legacy monolithic architectures that are much more susceptible to server failures that, unfortunately, are still far too common.

  • Plutora Releases Test Environment QuickStart Bundle – Techstrong TV

    Plutora Releases Test Environment QuickStart Bundle – Techstrong TV

    Bob talks about Plutora’s new “Test Environment QuickStart Bundle”. It provides an easy, immediate fix to the Achilles’ heel of software development: environments that cause delays, produce bugs, and waste time and effort. The video is below followed by a transcript of the conversation.

    Alan Shimel: Hey, everyone. Welcome to another Tech Strong TV segment. I’m really happy to be joined today – I don’t know if he’s actually been on Tech Strong TV with us, but I’ve spoken to him many times; it’s my friend Bob Davis from Plutora.

    Hey, Bob, how are you? 

    Bob Davis: I am great, Alan. It’s so good to be here. I haven’t had the pleasure of being on the Tech Strong TV spotlight and it’s great to be here.

    Shimel: Fantastic to have you. So, Bob, our audience has been fed a steady diet of Plutora for years already, right? So most of them know Plutora, one of the leaders in the value stream management space, a DevOps pioneer leader. But I don’t know if they really know you. I’d like to introduce them to Bob Davis. 

    So why don’t we start there? Give them a little bit of your history, Bob.

    Davis: Sure thing. Alan, I’ve got a few years under my belt, and I started in the semiconductor business back at Intel as a chip designer. And I ultimately said, “Gee, you know, I think I understand why I want to build things bigger, better, faster and cheaper, but I don’t understand the business.” So I went and got an MBA and I moved into more of a product marketing orientation, and from there became a serial entrepreneur. 

    This is, Plutora is my tenth startup. I never joined another large company after I joined Intel, but I found my way into some through acquisitions and so forth: Novell, CA. Always on the software side, always on the, you know, typically the infrastructure, you know, a lot of enterprise IT, networking, compression, security, a lot of that, and ultimately back up in recovery and continuous data protection and those kinds of things, which ultimately led me to really understanding, wanting to understand more about the developer side. 

    And so about five or six years ago I found my way into Plutora and I became chief marketing officer and away I went. Along the way I became a pilot, I play golf, and love the water. So I’ve got a lot of things. And six grandchildren, so good stuff.

    Shimel: Six children. God bless you, man. Whoo. You know, I’ll tell you off camera; I don’t even want to get into it now.

    But anyway, that’s great, man. It’s great to have you here. And it’s interesting, ’cause you know what, a lot of people will hear “Bob Davis, CMO Plutora” and say, “Ah, he’s a marketing guy.” Well, yeah, but you’re a marketing guy who started off designing chips at Intel when a lot of people watching this were playing computer games, not even computer games, Show & Tells or whatever the heck they were. Right?

    Davis: Yeah. Well, I’ve always been on the product side and I’ve always been more on the “What’s the next idea?” In fact, the best example of that was right around 2000 – you know, we started Kaseya. 

    Shimel: Oh, I remember that.

    Davis: So I was the original founder of Kaseya and started that in my kitchen and it’s …

    Shimel: Really?

    Davis: Yeah. To being what it is today. And there wasn’t even a managed service provider market at the time.

    Shimel: No, I remember that early on. Because I had started a company called StillSecure and in 2005 we pivoted into MSSP. ‘Cause I just thought MSSP was the way to go. It was too hard for too many companies; they needed an MSSP. Actually Kaseya bought friends of mine, Carl and Billy Austin, they’re serial entrepreneurs as well. They were acquired by Kaseya. And then of course Kaseya was acquired, what was it, a year or two ago maybe? 

    Davis: Yeah, Inside Venture Partners bought Kaseya in 2013, which is when I left actually.

    Shimel: Right. Oh, okay.

    Davis: That’s when the new management came in. And we sold the company and kind of went off on our own journeys. I went to a company called Atlantis, which we were doing hyper-converged storage, and then ultimately Dalibor Siroky, CEO of Plutora, found me and brought me over to Plutora in 2017. 

    Shimel: Very cool. So, Bob, we were talking off camera a bit. We’re at an interesting sort of boundary layer here again. I think many of us are let’s call it cautiously optimistic that we are going to emerge from our kind of COVID cocoons and venture out again en masse. 

    Davis: Yes.

    Shimel: Many of us are already.

    Davis: Yes. 

    Shimel: The interesting thing is the world we left two years ago is a different place today than it was two years ago. We’ve learned a lot of things, we’ve experienced a lot of things. Digital transformation – no pun intended – has transformed many a business – many a business model. For us in the tech industry, for our audience, you know, the way they shop for products, try products, use products, measure flow in terms of value stream and stuff like that, it’s really changed in two years. They’re different. You can’t put your foot in the same water twice, right? And so companies like Plutora – someone once said that, I’m pretty sure. 

    But companies like Plutora, they’ve had a change. You’ve had to adapt. And you guys have. You have that sort of a whole new program you’re coming out in market with. Let’s talk about it.

    Davis: You bet. You know, in the beginning, right in the beginning of the pandemic, early pandemic, early 2020 we saw as the world was trying to find its axis again we saw an incredible increase in people wanting to learn. So they spent the first part of that 2020 just in this learning mode. And value stream management was one of the things that people were really focused on learning. And the notion of being able to say “Wow, if I could really see a pipeline, a value stream from the beginning to the end and understand if I’m getting better.” And that was really the question that the CIOs were asking, “I’ve spent millions of dollars on these tools. Am I getting better?”

    The point I’m making is that everybody was trying to understand how they could tell if they were getting better. And all these flow things became almost an MBA project or a PhD-type project to really understand all that’s possible. And that was awesome and we got a lot of interesting traction from that. 

    What we found, however, is that that transformation is a daunting transformation and the world changed around everybody. We went from distributed teams to distributed teammates. So now that autonomous team was distributed in and of itself, and the communication and collaboration became very difficult to achieve. So processes, organizations were changing. So many things changing all at once that people were really slowly doing like they’d be happy to go to an event, sit on a virtual show. What do I need to understand to get better?

    That’s not what’s happening today. Some of it, sure. Some of it still happens. But people are moving to more execution. They want to get value. They want to start seeing the value of that journey and they want to see the value in real-time. They don’t want to see it a year from now; they want to see it right now, this year. So we have seen our customers struggle with saying “How can I get started in value stream management? I may not even want to go all the way to the end of the value stream management journey, depending upon my specific tastes.”

    So we’ve developed an entire program around doing just that. How can we get people into a value stream process mentality, into a value stream platform, and do so quickly so that they can value right away. And so we have this program called the Quick Start Program and we released in January the first of several Quick Start products. This one is on environment management, which is a core component of value stream platform that Plutora sells. And in so doing we’re able to provide people solutions to a very complex test environment problem in three or four weeks, whereas today it can take 30 days just to configure and make an environment available on some of the prospects that we’re talking to.

    So in the time it takes to get an existing manually configured test environment ready for a test event you can have a full test environment management program and go from manual management of test environments to an automated process very quickly. Now I see value. Now I can see value in terms of the efficiency of utilization of expense and test environments. I can see better quality. I can see saving tons of money. 

    We find that people with average levels of releases, well UMA did a study and they came out and said the average number of releases in an enterprise environment was 76 a year. That was in a survey. They did a survey and they came back and said that was the average. There was certainly a distribution, but that was the average. And if you’re manually managing your test environments you’re losing money. They determined based on all the issues of managing these things almost $1.5 million a year you’re wasting. 

    And so we can save you that with a product like this. So imagine I’ve got a bottleneck in my DevOps tool chain, the Achilles’ heel of my tool chain is waiting for test environments as I shift left and try to test earlier. I solved that problem, I removed the wait states there, I become more efficient, I save money, and I can do that in about three to four weeks worth of setup. And now I’m rolling. Wow, I’m getting value. Now I go to the next problem and so forth. And I get quick starts, I can come into the platform pretty soon. I’ve got a full value stream management platform down the road. I’ve gotten value every step of the way and I never had to really think about the prospect of doing the whole thing. It’s like one step at a time; every journey is one step. So it’s like let’s give people the ability to get value in that same way, one step at a time. 

    And that’s really, it’s been met with tremendous success already. We’ve seen a lot of responses, a lot of people wanting more information, and our SDR team is very busy fielding calls on it. So it’s been a real successful launch so far.

    Shimel: That’s great. You know, Bob, I think part of the reason for its success is there’s two kind of trends you’re riding there. First of all it’s this, I call it “deliver delight,” but I mean that’s just two words, right? It goes to when I was an entrepreneur founder of companies we were hiring enterprise salespeople who sold to the C-levels and all that stuff. In today’s world we hire DevRel evangelists, and the idea is get the software into the hands of the people who are going to use it, deliver delight, and if it works they’ll tell their bosses and so forth to buy it. So it’s a different sales model. But it’s become dominant, especially in DevOps cloud native, you know, the kind of markets we play in. So this really is kind of playing into that. 

    Davis: Totally.

    Shimel: It’s delivering delight. Because synonymous for delivering delight is delivering value. 

    Davis: Yes. Well, that’s the point, right? Now it’s the whole point of value stream management in the first place. You know, it’s interesting; it’s really an agile approach to delivering the value stream management solution. There’s a parallel there. You know, saying “I’m going to buy a value stream management platform and implement it” is a little like deciding I’m going to build a waterfall process. ‘Cause it’s everything at once, this is what I want to do.

    Shimel: No, it’s like trying to eat an elephant.

    Davis: Exactly. 

    Shimel: You’ve got to eat it one bite at a time. [Laughs] That’s the only way you can eat it.

    Davis: Right. Well, you’re crossing – you know, by the very definition value stream management embraces both, you know, everything from the ops person on the far right to the strategic planning office on the far left, and so you’ve got lots of people, you’ve got lots of moving parts. It’s hard. We actually have found hard when we market the product we get the interest from the pain point, I’m having trouble. In this case I’m having trouble managing my environment. If you’re selling the entire platform that environ manager, in order to take advantage of that feature, has to sell the platform to the planning person, to the ops person, ’cause they’re all going to get affected. 

    There’s value there, but they’re like, “Show me.” Now we’re giving them a tool they can do that. It’s an on ramp into the platform, a smaller bite of the apple, as you said, an agile approach to delivering value stream management and value at the pain point level. And so we’re doing everything around it to make it super-clear if you have this pain, this is what it looks like in our product when you solve it, and you can get there by the end of the month. Does that sound reasonable? And it’s way cheaper.

    And so that’s the other thing, these platforms can be expensive. But what if I can buy something that’s in my sign-off authority, so it’s more approachable to me? The whole notion of S-a-a-S is all about product life growth and let me get something in my hands for free and try it out and then I can grow from there. That’s the beauty of what so many people have enjoyed with S-a-a-S-style software products. 

    Value stream management is hard in that sense, ’cause it’s complicated. There’s integrations into the tool chain, there’s process changes as people evolve from more legacy processing to DevOps tool chains and DevSecOps tool chains and so forth. There’s that. There’s organizational change, budget-holder changes, people moving from silos and project-oriented things to product-oriented things. So we’ve run into prospects that get so frustrated, they want the solution but there’s a lot going on in the organization. We’re answering that question.

    You can each have had a success, show the value, and go from there. It’s a great on-ramp. It’s a freemium approach almost in a complicated environment and its value stream management, and we think it’s really going to be awesome when people can have multiple. We’ll do probably deployment, we’ll have a quick start for master deployment plans. You know, Jeff was on in November talking to you about our progressive release management and some of the new stuff that we did with the Insights dashboard. That’s another screaming for of Quick Start, “Hey, wouldn’t it be cool if you could get this up and running very quickly?” 

    So all of those things is where we’re headed. We started with environment management and it was made available on the 18th of January and it’s already in the market, so we’re excited about it.

    Shimel: So no pun intended, but where can we get a quick start on this Quick Start? [Laughs] Where can we go, Bob? 

    Davis: Well, we have, there are online demos. You know, there are all kinds of spots on our website. We have a spot where you can say “Talk to me and you can sign up for that and have it by the end of the month.”

    Shimel: So just go to Plutra.com and check out the stuff for Quick Starts. 

    Davis: Yep. There’s a banner right on the top of the home page that will take you right to the information on it.

    Shimel: Love it. Good stuff.

    Davis: Yep. It’s all right there.

    Shimel: Hey, Bob, we’re about of time. I want to thank you for coming on and telling us about the Plutora Quick Start program. You know, the first one, as you mentioned, came out the 18th. Any timeframe on subsequent quick starts?

    Davis: We’re going to bring out the next one in the beginning of the next quarter, so right around April. 

    Shimel: Excellent, man.

    Davis: So you heard it here first, Alan. 

    Shimel: Well, that’s why we’re here. Thank you for letting us know. We’ll be watching. Good luck with this one. Maybe we’ll see you show up on one of the Plutora webinar workshops that you guys do with us so often. Love to have that.

    Davis: We’re going to do that.

    Shimel: Cool stuff. All right. Bob Davis, CMO Plutora here on Tech Strong TV. We’re going to take a break right now. We’ll be right back with our next guest. 

  • Free Dev Tools! But What’s the Catch?

    Free Dev Tools! But What’s the Catch?

    Software companies, especially young startups, are always in a development race – by definition, they are trying to maximize achievements and minimize their burn rate. That means development teams naturally face an internal tug-of-war. On one hand, they seek to use the newest dev tools that the market can offer, targeting their applications to become better (more secure, more efficient and compliant with the latest standards). On the other hand, they cannot spend money on such tools since they need to save every penny. With the current economic climate, many new investments are being delayed or, at minimum, double-checked. 

    To appeal to developers, many vendors and software development tool companies offer freemium programs. Some are driven by the spirit and the goodwill of open source and community; others are business-to-developer (B2D) companies relying on the product-led growth (PLG) mode. If developers see value in the free tools, they are more likely to become paying customers later on to get access to more features.

    Here, we’ll review the common parameters of popular free developer tools and distinguish their services between the free tier (aka the community tier), the entry-level paid tier and other paid program offerings. We’ll look at tools for observability, logging, vulnerability scanning, compliance, authentication and VPNs.

    1. Volume Threshold

    Logs are considered to be one of the three pillars of observability and are the bread and butter of troubleshooting and debugging. The more code lines you have in your product, the more loglines you collect, store and aggregate. Logs accumulation can quickly get out of hand and become very heavy on the budget. One logs aggregation vendor, Sumologic, provides a freemium offer that allows log collection up to one gigabyte per day. If you need more volume, you can move to their paid tier that allows for higher volumes or pay more for no limits at all.

    2. Transactions Threshold 

    Transactions and tests are probably the most imperative features of a freemium offer. It involves the core offering with a quantity limitation, giving you a chance to try the product through practical use, but you’ll probably have to move up quickly into the first paid tier. Snyk.io, for example, will help you scan your open source software for flaws alongside container vulnerabilities as early as code creation, with up to 200 open source tests and 100 container tests per month.

    3. Certified: Security and Compliance 

    It’s one thing to play with, say, a free AutoCAD seat that doesn’t involve sensitive data and another thing entirely to draft the next-generation design that must not leak to your competitors. Security and compliance certification is often included in the freemium tiers; more detailed reports and analysis of security and compliance are for the paying tiers only.

    4. Availability and SLA Support 

    Having a free tool is great–but if this tool is bound to a proprietary service, then you should probably demand these tools meet the same standards and SLAs that you are offering your customers. Observability platform Rookout offers 24/7 support and dedicated account managers and tools for enterprise customers in all tiers.

    5. Legal Aspects 

    One key aspect of free tiers is the legal aspect of using the tool. The dev tool may interact with sensitive data, not only in your own dev environment but also with your customers’ environments. Your customers may require your dev operations to meet specific criteria, making the free tier a potential legal issue. For example, if you use the free tier of JFrog to manage your supply chain, you won’t be able to use Artifactory to publish data to third parties; should you want to do that, you will have to move to one of the paid commercial programs.

    6. Usage Threshold

    Some free tools operate based on a usage model—you are entitled to a free tier until a certain amount of users or actions is reached. Auth0, for example, a user authentication solution (now part of Okta), provides their service free of charge for up to 7,000 users (generous!) but should you grow beyond that, you’ll need to graduate to a paid tier and be charged according to your monthly usage.

    7. Speed Threshold

    Some free and freemium offerings are tempered based on connectivity speed, bandwidth and even VPN. Today, you can even get a secure VPN for free, but only to a specific threshold. For example, ProtonVPN will provide you with a free VPN at a medium speed, if you move to the highest speed VPN, you’ll need to move to a paid tier.

    In most cases, the freemium tier will limit a dev tool’s usage according to one or a few main characteristics but will allow you to perform the basic actions and enjoy the essence of the tool. Some parameters may be trivial, like volume of tests, while others require developers and DevOps teams to carefully monitor usage. There’s a lot of value in free and freemium dev tools—but make sure you read the fine print.

  • Agile Sucks (Redux) | Plus: DevOps on Mars

    Agile Sucks (Redux) | Plus: DevOps on Mars

    Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.

    This week: Agile is bad, but “Wagile” is worse.
    Plus: This prod is even worse than yours. (more…)