Category: Features

  • Top Pressing Concerns for CI/CD in 2020

    Top Pressing Concerns for CI/CD in 2020

    The tech landscape is changing rapidly. With the need for increased development velocity, CI/CD has become ubiquitous among most organizations. Yet, with the growing number of microservices, CI/CD may be tough to wrangle without the right strategy.

    At the same time, it’s difficult to keep pace with the constant evolution around CI/CD. So, what is the state of the CI/CD space in 2020, especially in these turbulent times? What do stakeholders see as top pressing concerns companies should consider to advance their release fluidity?

    For this article, I interviewed two stakeholders on the latest trends and industry cooperation around CI/CD. Read on to discover what two CI/CD thinkers, Tracy Miranda, board chair, Continuous Delivery Foundation (CDF), and Lachlan Donald, CEO, Buildkite, see are pressing concerns for CI/CD in 2020.

    More Microservices, More Problems

    With the number of microservices rising to the hundreds (or thousands) for some enterprises, maintaining consistent release strategies across the board could easily become a nightmare. If the goal is to replicate a unique CI/CD pipeline per microservice, pipeline automation and configuration management become top concerns.

    “Automation will be key,” said Miranda. “We can no longer afford to be writing each CI/CD pipeline by hand; we will need new approaches.” She added that recent industry discussion shows “configuration management is a top concern for CI/CD practitioners.”

    Tools like Jenkin X could enable this sort of automation, she noted. Companies should consider evolving their CI/CD pipelines with better configuration management.

    Platforms Must Evolve

    The recent “State of the Cloud Report” from Flexera found 39% of IT leaders saw implementing CI/CD in the cloud as a top priority. According to Miranda, the global crisis seems only to accelerate the need for cloud and CI/CD automation.

    But, traditional CI/CD platforms aren’t always suited for modern development workflows with numerous pipelines. For Donald, an evolution in new tooling is absolutely necessary to help companies keep pace.

    “We’re at a point where organizations need to completely rethink their approach to CI/CD,” Donald said. “Traditional CI/CD platforms are not suited for modern development workflows.” He cites slow speed, unreliability, scalability limitations and security risks as common hangups among many CI/CD tools.

    Lack of Clarity in CI/CD Market

    The market has expanded significantly to address the gap in CI/CD tooling effectiveness. According to Miranda, this has led to a continuous deployment tooling ecosystem wrought with interoperability and competing styles.

    “My biggest concern is the proliferation of tools and platforms with a lack of interoperability and lack of clarity of how to best use them or whether they are fit for purpose,” Miranda said.

    These differences make it difficult for developers to find the right integrations that work for their environments, leading to wasted time and effort. “Developers will experience growing pains with their CI/CD platforms as they work to keep up with the constant demand for quality software,” acknowledged Donald.

    Lack of Standards

    Part of the lack of clarity resides in the fact that there are little to no standards emerging in the CI/CD space. Aside from Accelerate rising as the “bible” for software delivery, Miranda sees a lack of standards in the CI/CD space.

    “Not having standards or de facto standards is a problem,” she said. “For example, why is there no de facto standard for reporting pipeline test results?”

    Advancing Open Source CI/CD Tools

    To improve Interoperability throughout the CI/CD industry, bodies such as CDF are working on setting general guidelines. Miranda described how CDF is accomplishing this, by supporting a CDF Interoperability working group, sharing CI/CD practices and maintaining open source CI/CD projects. Two CDF projects she finds quite compelling are Tekton, a pipeline execution engine, and Jenkins X, a new CI/CD platform for pipeline automation.

    Cloud vs. On-Premises: A False Dichotomy?

    In analyzing the CI/CD tooling ecosystem, Donald recognizes a recurring dichotomy; that companies must choose between the security of on-premises and the speed of cloud-native. In reality, this dichotomy may be false.

    “It is possible to have the best of both worlds,” he said. “A hybrid strategy [is] the solution for testing and deploying software at scale without compromising security or performance.’

    As opposed to cloud tooling, self-hosted CI/CD control planes could grant developers more code control and help meet security standards. “I believe self-hosted agents are always a good idea,” Donald said.

    As we recently covered, a hybrid cloud approach is picking up steam. Similarly, Jenkins X is designed to run on any Kubernetes cluster, regardless of on-premises or cloud, demonstrating industry movement toward tooling neutrality and hybrid motivations.

    Moving Beyond PASS or FAIL

    There is a reductive tendency in CI/CD to simply check whether a build passed or not. But, this mindset misses an enormous amount of useful information and undervalues the test and release suites themselves.

    “Teams should get granular about what worked and what didn’t,” Donald said. DevOps teams must evolve beyond a “PASS or FAIL” mindset to analyze more minute aspects of the build process itself.

    For Donald, this also means shifting to treat test code performance “as a first-class citizen, applying modern development and scaling practices to it and allocating the necessary resources to it.”

    Future Evolution: Progressive Delivery and Hybrid Approach

    In closing, I asked Miranda and Donald their thoughts on the future CI/CD evolution. They shared their perspectives on where CI/CD needs to evolve.

    Miranda views progressive delivery as the next milestone. With progressive delivery, teams deploy services in a staged manner, she said. “Tools, technologies and processes that fall under the ‘progressive delivery’ umbrella will be the next milestones for improving deployment speed and efficiency.”  Building blocks such as services meshes could help advance this process, she noted.

    Donald stressed the need for a hybrid approach to CI/CD. A neutral control plane could grant better control and future-proof continual release strategies.

    Assessing the CI/CD Landscape

    In summary, our panel shared thoughts on the top concerns for CI/CD in 2020:

    • Platforms must evolve: Teams should rethink their approach and emphasize automation in pipelines.
    • Lack of clarity: There are few standards and a lack of clarity among tools. This confuses developer adoption.
    • Interoperability: A focus on interoperability is critical toward advancing the industry.
    • Unhelpful dichotomies: The cloud-native versus on-premises divide may not be helpful for a hybrid strategy; thus, it’s recommended to seek out platform-neutral tools.
    • Move beyond PASS or FAIL: Switch the mindset to “Test code = application code.”

    High performant organizations must scale their technology tremendously. With this desire comes a mounting strain on how companies adopt a continuous deployment strategy. Without a proper CI/CD plan, business agility is sacrificed.

    As an ending note, I absolutely love Donald’s statement: “A good litmus test for how well a company is run is their approach to CI/CD.” Perhaps what all can agree on is that companies must prioritize CI/CD, as it is now business-critical. Otherwise, deployments may be numbered for those organizations that don’t adapt.

  • Upcoming Event: DevOps India Summit 2020

    Upcoming Event: DevOps India Summit 2020

    DevOps experts and business leaders from across the globe will come together to share their thoughts on DevSecOps, security and governance in DevOps during the third edition of DevOps India Summit (DOIS). Presented in a virtual environment, DOIS20 will take place on Sept. 9, at 9 a.m. IST.

    At DOIS20, attendees will have the opportunity to interact with industry experts and learn how they have successfully implemented DevSecOps practices. The DevOps practitioners will share their experience and expertise, focusing on their company’s transformation to DevSecOps.

    DOIS20 features an exceptional lineup of more than 35 DevOps thought leaders, including:

    • Mark Miller, senior storyteller and DevOps advocate at Sonatype (keynote speaker)
    • Piotr Lewandowski, senior staff site reliability engineer at Google Cloud (keynote speaker)
    • Alan Shimel, founder and CEO at MediaOps (keynote speaker)
    • Mirco Hering, global DevOps practice lead at Accenture (keynote speaker)
    • Rosalind Radcliff, distinguished engineer and chief architect for DevOps at IBM
    • Dr. Niladri Choudhuri, founder and CEO at Xellentro
    • Hasan Yasar, technical director at Software Engineering Institute
    • Sanjeev Sharma, co-founder and principal analyst at Accelerated Strategies Group and author of “The DevOps Adoption Playbook” and “DevOps For Dummies”
    • Vandana Verma, Global Board of Directors at OWASP Foundation
    • Ramesh Pasapula, assistant vice president at Wells Fargo
    • Sailaja Vadlamudi, director of security and data privacy at SAP Labs and WiCSP founder

    The online environment at DOIS20 features a lobby, an expo hall lined with booths full of downloadable resources and an auditorium where attendees can watch sessions from 8 a.m. to 6 p.m. IST. The expo hall will be open throughout the event, giving attendees the opportunity to chat with vendor sponsors and download information.

    All registered attendees will have the chance to participate in contests and win incredible prizes, attend Q&A sessions with the speakers and will also receive a link to access the virtual summit on-demand.

    For more information and to register, visit the DevOps India Summit 2020 website.

  • DevOps Chat: ASG State of Software Delivery Management Report

    DevOps Chat: ASG State of Software Delivery Management Report

    Accelerated Strategies Group has just delivered its “State of Software Delivery Management Report,” commissioned by CloudBees. In this DevOps Chat, we speak with Mitchell Ashley, CEO, founder of ASG, about the report and why it is important for everyone managing software delivery today.

    As usual, the streaming audio is immediately below, followed by the transcript of our conversation.

    Transcript

    Alan Shimel: Hey, everyone. This is Alan Shimel, and you’re listening to another DevOps Chat. I have a really great chat lined up for us today because I’m joined by my partner, Mitchell Ashley, founder, CEO of Accelerated Strategies Group. Mitchell, welcome to another DevOps Chat.

    Mitchell Ashley: Well, very nice to be here. It’s great to be on this side of the microphone for a change. [Laughs]

    Shimel: It is kind of. I mean, Mitchell, before we jump into the report out of Accelerated Strategies Group we want to talk about, just as little history for our audience. Mitchell and I have been doing podcasts together now –

    Ashley: Oh my.

    Shimel: Fifteen years?

    Ashley: At least. 2004 or ’05, something like that. Yeah.

    Shimel: So it’s still secure after all these years.

    Ashley: I was waiting for the,”This is Alan Shimel and this is Mitchell Ashley.” [Laughs]

    Shimel: Exactly. Do you remember those days? Oh my goodness. You know what’s old’s new. It’s good to have you on with me, Mitchell. You know, as you said you’re often on this side. You and I kind of split up our hosting duties for DevOps Chat. But we’re here today because Accelerated Strategies Group just dropped a report on the state of software delivery management, SDM.

    Ashley: We did.

    Shimel: And the report was commissioned by our friends at CloudBees but it really is the independent analysis and research of you, Sanjeev Sharma, principal analyst at Accelerated Strategies Group, and the rest of the Accelerated Strategies team. So, you know, we’ve done a little video on this, Mitchell, but I’m going to assume our audience listening here on DevOps Chat maybe didn’t see the video.

    Ashley: Okay.

    Shimel: Why don’t we start off – when we talk about SDM, what are we talking about here?

    Ashley: You know, we used to – we’ve had all kinds of names for methodologies, you know, software development lifecycle management, blah, blah, blah. You know, what I think it’s really about, software delivery management is about the whole delivery, the end-to-end process of how do you manage the software process from here’s money, we’re going to invest in something that we think is going to be created through software; how do you know through the whole machinations it goes through to actually create the software that you know where you are and what you think you’re going to be getting? And then when it’s all done how do you know that you got what you thought you paid for? To think about is sort of as a business view into managing the software process.

    So not just IT and product teams but also the executives, senior leaders, can find out what the heck is going on and how well – it’s really about how well do we develop software and how well – our ability to manage it.

    Shimel: Yeah. I agree. You know, we had this discussion earlier with Sanjeev as well, correct, and, you know, in my mind it’s about how do we manage the factory rather than how do we work on the assembly line? A lot of software today, especially in the DevOps world, is about how do we work on the assembly line? And that’s a noble, worthy thing to do.

    Ashley: It’s important, yeah.

    Shimel: Right. That software delivery pipeline, that factory, you know, assembly line as we move software left to right. But, you know, someone needs to be managing the controls, right? And are we doing it just in time? Are we using lean? And if so, how? You know, even lean you always need to be turning a dial and checking things out.

    Ashley: Exactly.

    Shimel: I’d like to talk a little bit, Mitchell – well, let me – let’s first start with this.

    Ashley: Sure.

    Shimel: Of course the mantra at Accelerated Strategies is information wants to be free, and in that vein this report is free and open to anyone – anyone – who’d like to download it, right?

    Ashley: It is. That’s our belief. I mean that’s really what we founded and you were part of founding Accelerated Strategies group two, is let’s do something disruptive in the analyst industry. You and I have paid an awful lot of money to analysts for sometimes questionable [laughs] – what are we getting for it? – but we have to do it, right?

    Shimel: Well we paid for access.

    Ashley: We paid for access even though that’s – you know, everyone says it’s not true –

    Shimel: [Inaudible comment]

    Ashley: – but it is. I mean let’s be honest about it. I think it is anyway. With Accelerated we said, “Look, we’re not going to pay –” you know, every time you touch an analyst you had to pay him. Every time you said something to him you’re like dropping in another coin. And let’s do this the right way. Let’s do this – when you’re working with us, engaging us to do something for you, you know, do some research, assess the market, advise you, do a strategic project, do some competitive analysis, all of those things for a research report, that’s when we’ll make our money. You are welcome to distribute that as freely as you like.

    We’re not going to hold you behind a paywall and subscription fees and licensing. The customer’s give us all that information. Why don’t we give it back to them in some meaningful way [laughs] instead of making them pay for it? That’s –

    Shimel: You know what, Mitchell? I think back to the days where we would pay, you know, a certain large analyst company to send an analyst out to spend the day with us, and we’d pick them up at the airport and get them breakfast and lunch and, you know, keep – wine and dine them all day while trying to get him to understand our point of view, and when I drop him back off at the airport, I’ll be honest with you, I felt a little dirty.

    [Laughter]

    Ashley: And it kind of felt like, why do I feel like we know more about this space than the analyst?

    Shimel: Yeah, there was no doubt that I felt like I knew more about that space, but, you know – and I’m not – look, everybody needs to make a living and there’s the oldest professions in the world, but I really felt like I – I didn’t like paying for it. You know what I mean? And there was definitely some of that involved. But enough about the analysts. _____.

    Ashley: We could do, like, three podcast episodes on that or more.

    Shimel: Yeah. We can go off on that. What I want you to talk about though, Mitchell, is would you share with our audience a little bit of insight? How was the research done here, the analysis? I know Sanjeev Sharma, principle analyst, was lead author on this report, but give us an idea of, you know, the ASG methodology, if you will.

    Ashley: Well really any research has to start out with some hypothesis; what do we believe about the market or what do you think we believe about the market? And really the hypothesis here was around what’s the maturity level of our ability to manage the entire software delivery process? Connecting it to the business, not just inside of IT. So we started with that and we have a target audience who we’re trying to talk with, both individual contributors, leaders in the software development part of this but also executives, product people, CIOs. So we really tried to cast a big enough net but not so broad that it all got watered down and you couldn’t tell who said what.

    We really spent some time focusing on who we wanted to talk to. And it wasn’t a short survey but it wasn’t a long one. There were really some insightful questions around do you know what your backlog looks like and what it costs you to delay a release or to trade something off one feature for another? Do you really know when you’re going to get the release or the functionality that you’re paying for so you can move the business forward based on those plans, or are you kind of shooting in the dark and you’re just hoping that it comes out sometime in the next quarter and we’re good and then we’ll kind of get everything running from there? So we did a survey, but we did a lot of kind of research going into it, talking to different people in those roles before we ever built the questionnaire.

    So it’s not just a research firm that says, “Okay, what do you want us to ask? Let’s build you a survey.” You know, Sanjeev and the other analysts with Accelerated Strategies Group are all practitioners. They’ve done this, they’ve worked in this field, they’ve led software teams, projects, companies, they’ve consulted with big enterprises, small startups, medium-size companies. So all that to say it was really, you know, our best attempt at let’s get the best information we can when we go out and ask people for where they think they are with their maturity curve and where they really see the challenges, and we got some fantastic results. It was super, super insightful and kind of exciting to see, you know, what things we thought were true and what maybe some things were, hm, that’s a little bit of a surprise.

    Shimel: Yeah. Okay. I guess you kind of opened that box now.

    Ashley: Did I set it up well enough?

    Shimel: Yeah. I think you got it. So let’s start with the surprises.

    Ashley: You know, so one of the biggest things that everyone – I don’t want to say everyone – one of the biggest outcomes of this research was around everyone’s ability to understand the value they’re going to get from their investment, right? Spending how much money on this software IT organization, product team whatever, and what am I really going to get at the end? So it’s very clear it’s very unclear to the people funding the work, that they essentially understand what they’re going to get. You just can’t get to that information or get a straight answer.

    We aren’t connected well enough into it to really understand it, which kind of goes to the second key finding was the communications around the whole software creation process is broken. It may work within a development team that’s really functioning tightly together or an Agile team with a product leader that they’re working with day to day, but outside of that, both kind of horizontally but also vertically in the organization, the perception at senior leader levels versus the individual and the team levels that are building software can be much, much different. So can you imagine making – well, we’ve done this right, Alan? – making multimillion, maybe much, much, much larger decisions based on what you think is going on and that’s not really true.

    So that’s a huge issue. If we really believe in software is leading the world, that all businesses are software companies, you have to be – you’ve got to fix that. That’s got to be taken care of. And then the third area is basically all the way through the delivery pipeline and understanding the value flow. Where are you creating value and where are you actually spending energy and not getting value? Maybe getting the wrong output out of the software process. Because an example I like to use is software teams like to measure how many releases we get out per day, sometimes per hour. I mean that’s a great thing. It sounds like a really awesome thing to accomplish. But if it’s the wrong thing, wrong software, it doesn’t matter if we’re releasing it a million times an hour. I’ll take one release a month if it’s the right thing instead of a million releases every day and all of them aren’t hitting the mark.

    Shimel: Yeah, I agree.

    Ashley: That’s an extreme, but that’s really what it is, is understanding through that whole – and again, we’re talking about not one pipeline of work, one value stream of work; it’s across multiple, because almost every app touches all kinds of systems, data, you know, especially in a large enterprise – mainframe, stuff in the cloud, stuff that’s maybe kind of the older client server but still around, whatever it might be. So those are the three key areas that we identified that if you can assess where you are and how well you do that part of the software development, that will make the biggest difference in sort of upping your game and your ability to deliver software.

    Shimel: Agreed. Agreed. You know, I guess I’m not surprised but I am surprised in that, you know, the first thing I learned about DevOps was it’s about breaking down silos, bringing dev and ops together. We’re going to break those silos. Kind of like the Macintosh 1984 commercial, remember?

    Ashley: [Laughs] The girl and the hammer, yeah.

  • Documenting: Don’t Build Your Replacement’s Nightmare

    Documenting: Don’t Build Your Replacement’s Nightmare

    Want to reduce headaches tomorrow? Document everything today

    About once a year I feel the need to remind you that you are creating technical debt. DevOps is good stuff, and most shops got over the “whatever a given project team decides” multiplication of services pretty quickly, but every line of DevOps code you write is creating technical debt.

    There is no way around this fact. You are writing code (scripts, if you prefer) and developing configs that make assumptions. Those assumptions will change—products will get incompatible upgrades, vendors will go under, libraries will become outdated … the list goes on.

    We have a long history with technical debt. DevOps partially grew out of the need to spend less time maintaining and more time releasing features, and yet we’re re-creating technical debt; in some cases at a much larger scale. It is unavoidable but can be managed. Keep a reference list of assumptions—“This app assumes environment contains X,” or “This app supports Cisco Network APIs version X.Y”—so you know where to look when things inevitably go wrong. The list conveniently doubles as a handy reference to what needs updating when you find out your middleware vendor is going under or that MySQL is out and MariaDB is in.

    The more cutting-edge tools you use, the more likely that you are baking future problems into your environment. This is not advice to avoid cutting-edge; it is advice to recognize reality and keep closer track as you move new things into your environment that might be half-baked or whose market is destined for consolidation.

    Our IT environment has become super-complex. DevOps helps us manage that complexity but discourages adequate documentation. We’ve all heard, “It’s self-documenting” (no, it’s not) or “There is basic documentation” (basic almost always means, “We scratched some notes when it was first set up”… and haven’t touched them since). Don’t do that. Make sure that the new guy after all of you have left can figure out what is going on in this highly complex environment. It is not up to new people to be super-learners with mind-reading skills; it is up to implementors to make certain new people can figure out what is going on without wasting 5,000 hours pawing through scripts.

    It does not take much time to document dependencies. It doesn’t take much more to document relationships. Future you will be grateful when they walk in and need to come up to speed in a short amount of time. Because it doesn’t matter how automated it is when the automation breaks—it matters how quickly staff on hand can fix it and get things going smoothly again.

    You’re keeping the world running. Take a second and make sure the next person can, too. And keep rocking it.

  • State of Software Delivery Management Report 2020

    State of Software Delivery Management Report 2020

    Accelerated Strategies Group conducted the State of Software Delivery Management 2020, surveying software delivery practitioners and key industry leaders to assess the current state of software delivery management (SDM) and examine the impact of SDM adoption as a capability. The primary research, commissioned by CloudBees, was published on Tuesday, July 21.

    The State of Software Delivery Management Report 2020 defined SDM as “a core competency for any organization or team responsible for delivering business value via software applications and systems.” The report studies the impact of SDM and how it helps organizations accelerate their digital transformation by providing the necessary tools to effectively and efficiently deliver software.

    The report identified three key SDM capabilities to help organizations increase their software delivery efficiency and effectiveness:

    • Organizations must quantify the impact of their investment in software delivery.
    • Organizations must enhance the ability of software delivery teams to communicate and collaborate.
    • SDM can provide end-to-end visibility into the value flow of their software delivery streams.

    Based on the results of the research, adopting SDM strategies can help mitigate major challenges faced by software delivery practitioners, IT management, product stakeholders and executive leadership, and improve an organization’s ability to deliver software in a lean and agile manner. SDM capabilities provide businesses the ability to effectively make decisions on where in the value stream to invest, and to quantify the impact of their investments.

    Download the State of Software Delivery Management 2020 to learn more about SDM and to get insights and access to all the data Accelerated Strategies Group gathered from one-on-one interviews with key industry experts.

  • Google Exposes Old Wounds in Open Source Community

    Google Exposes Old Wounds in Open Source Community

    Things boiled over a bit last week with the announcement that Google launched the Open Usage Commons (OUC) consortium (see Mike Vizard’s article here). The announcement and subsequent angst it has caused has upset what had been a pretty stable environment that helped open source software become the dominant force in development and IT. While on its face OUC is about trademarks and usage guidelines, but make no mistake: This is about Google (and perhaps others) disagreeing with the management and direction of The Linux Foundation/Cloud Native Computing Foundation (CNCF).

    Hand-in-hand with the OUC, Google also announced it was making changes in the board composition of the Istio project. A new formula based on code contributed by companies, as well as community seats selected by the community of other contributors, would determine who governs the project.

    Together, this represents a clear bifurcation of managing the code of a project and the trademarks/IP of the project. This is not a new concept in open source, but in recent years has been seldom used. In probably the most famous example of this setup, Linus Torvalds controls a company that still owns the Linux mark, which the Linux Foundation manages it for him. It is separate from the Linux project itself, though.

    The concept of the code being open and free while the project owners retaining the IP and trademarks was very much the norm in open source years ago. However, it led to many companies’ reluctance to contribute code to projects for which they had no say in the governance or usage of the marks. One of the benefits of the foundations such as CNCF, Cloud Foundry, Eclipse and others was that under their model, everyone had access to the same code base and mark usage rules. What you did on top of that was up to you. Ironically, this is the same argument we are hearing now regarding the changes to the Istio governing board and the OUC.

    Perusing the Twittersphere on this subject turns up a few other issues that may be at play here:

    • The CNCF and the Linux Foundation, by implication, may be a victim of its own success. The amount of money they have generated and their “marketing” profile seems to have turned some people off.
    • The CNCF/Linux Foundation model of allowing major corporate contributors to, in essence, buy board seats and having just a minority of “at large” seats open to the community favors the big, rich vendors over the rest of the pack.
    • New leadership at Google and Google Cloud are having second thoughts about turning over the fruits of their work to foundations that they eventually lose control over. Recent former Oracle management is being rumored behind this, though that is not confirmed. In this scenario, second doubts about Kubernetes and other Google-donated projects that are now out in the market without a Google edge are causing them to rethink their approach.
    • Companies that rely on these open source projects and historically are decent corporate members, such as IBM, have been caught in the open here as evidenced by their reaction to the Istio affair.

    What I do know is that the loser in all of this will be the community. Open source works best when there are stability and predictability over its future and governance. The broader the base of management and ownership of a project, the more willing corporate contributors are to participate and contribute. I would hate to see us return to the maze of the Cathedral and the Bazaar. I sincerely hope we are not seeing the end of the golden age of open source software.

  • Time Series Virtual Summit Speaker Spotlight: Jon Herlocker and Miroslav Malecha

    Time Series Virtual Summit Speaker Spotlight: Jon Herlocker and Miroslav Malecha

    The Time Series Virtual Summit will bring together InfluxData community members for a unique learning experience focused on the impact of time series data. Presented in a virtual reality environment, the event will take place on July 16, at 10 a.m. EDT.

    Miroslav Malecha
    Jon Herlocker

    Jon Herlocker, president and CEO at Tignis, is one of the speakers that will be presenting at the Time Series Virtual Summit.

    Jon invites anybody who has the responsibility to turn large quantities of sensor data from physical plants or manufacturing lines into business value to attend his session, “How an Analytics Platform Detects Reliability Threats and Eliminates Obstacles Impeding Results Using InfluxDB.”

    “Viewers will see Tignis’ unique physics-driven approach to machine learning for physical plants and manufacturing lines,” said Jon. “We’ll also share our approach to using InfluxDB to accelerate delivery of our solution to our customers.”

    Jon will discuss how Tignis uses IoT sensors to reduce unexpected downtime at manufacturing plants and school campuses. Attendees will learn how by using a time series database they can improve their competitive advantage and accelerate their go-to-market strategy.

    “Time series data from physical plants and manufacturing lines can be turned into significant business value, and we have proven that InfluxDB can be an effective component of that,” said Jon.

    Another time series specialist that will be sharing his knowledge and his experience with InfluxDB is Miroslav Malecha, director of product management at Bonitoo.

    In his session, “Using Time Series for Geo-Temporal Analysis,” Miroslav will discuss how to use InfluxDB’s Flux for Geo-Temporal analysis. He’ll briefly cover what Flux is, how to use specific Flux geo functions and finish with a quick demo of how to use InfluxDB.

    You can hear from Jon, Miroslav and more time series experts at the Time Series Virtual Summit. To check out the agenda, the full lineup of speakers and to register (for free), visit the Time Series Virtual Summit website.

  • Time Series Virtual Summit Speaker Spotlight: Al Sargent and Samantha Wang

    Time Series Virtual Summit Speaker Spotlight: Al Sargent and Samantha Wang

    The Time Series Virtual Summit will bring together InfluxData community members for a unique learning experience focused on the impact of time series data. Presented in a virtual reality environment, the event will take place on July 16, at 10 a.m. EDT.

    Samantha Wang
    Al Sargent

    Al Sargent and Samantha Wang of InfluxData are on a mission to help developers understand how time series databases provide real-time observability and monitoring.

    “The best software engineering teams in the world understand that time series data is different; it can’t be managed using a traditional database, and requires a purpose-built database,” said Al Sargent, senior director of product marketing at InfluxData.

    Al will be the first speaker to take the virtual stage at the Time Series Virtual Summit. During his presentation, he will explore the unique challenges of managing time-series data, why time series data needs to be treated differently than other data types and what to look for in a time series database.

    Any developer that’s building applications using time series data (or planning to), such as data from IoT sensors, monitoring data or customer usage data will benefit from Al’s educational session.

    Another great session you must definitely attend is “Monitor your Cloud Metrics with Time Series” by Samantha Wang, product manager at InfluxData.

    Samantha will discuss the importance of time series data for cloud monitoring, and how you can view your metrics in real time with InfluxDB Cloud.

    “I will walk through how to write metrics into InfluxDB Cloud using Telegraf and how users can take their analysis one step further with Flux,” said Samantha. “Lastly, I will review InfluxDB Templates, one of our newest community InfluxDB products, that provides a packaged solution for various common monitoring use cases.”

    Join Al and Samantha to learn more about time series databases and understand how InfluxDB Cloud can be your end-to-end solution for writing data to monitoring and alerting — all optimized for time series data.

    You can hear from Al, Samantha and more time series experts at the Time Series Virtual Summit. To check out the agenda, the full lineup of speakers and to register (for free), visit the Time Series Virtual Summit website.

  • Time Series Virtual Summit Speaker Spotlight: John Gleeson and Benjamin Sirb

    Time Series Virtual Summit Speaker Spotlight: John Gleeson and Benjamin Sirb

    The Time Series Virtual Summit will bring together InfluxData community members for a unique learning experience focused on the impact of time series data. Presented in a virtual reality environment, the event will take place on July 16, at 10 a.m. EDT.

    Benjamin Sirb
    John Gleeson

    John Gleeson and Benjamin Sirb of Storj Labs, will be at the Time Series Virtual Summit to discuss how the InfluxDB contributes to Stroj’s decentralized cloud storage platform.

    “Our team uses time series data to operate our decentralized cloud storage platform, which provides enterprise-grade object storage and is the largest of its kind,” said John Gleeson, vice president of operations at Storj Labs.

    Tardigrade, powered by Storj Labs, offers decentralized cloud storage that is automatically encrypted, easily implemented, highly performant, very economical and resilient. By equipping their customers with fast, secure and fully distributed storage, their users no longer need to manage their infrastructure. The Storj platform enables applications to store and share data across a distributed network with end-to-end encryption.

    In their talk, John and Ben will dive into:

    • Storj’s redefinition of a cloud object storage network.
    • How InfluxData fits into Storj’s Open Source Partner Program.
    • Collecting and managing high volume real-time telemetry data from a distributed network.

    “Attendees can expect a deep dive on how time series data allows for real-time analysis of a highly complex system, which operates in a low trust environment while maintaining industry standard SLA’s for data availability and durability,” said Benjamin Sirb, senior data scientist at Storj Labs.

    As vice president of operations, John is responsible for direct sales, partnerships, customer success, community, product management and data science as well as growing the international presence for the Storj decentralized and distributed cloud storage network. He is responsible for operationalizing core processes to ensure the business scales as the company and network grow.

    Ben joined Storj Labs in 2018, bringing six years of experience in academia, research and consulting to his role as senior data scientist. Drawing from his knowledge of probability theory, Ben has been instrumental in researching the theoretical foundations and practical applications of decentralized networks at Storj.

    If there is one thing they both would like the audience to keep in mind is that “the data science behind distributed and decentralized cloud storage is intense!”

    Join John and Ben to discover how InfluxDB is a component to Storj’s Tardigrade service and workflows.

    You can hear from Ben, John and more time series experts at the Time Series Virtual Summit. To check out the agenda, the full lineup of speakers and to register (for free), visit the Time Series Virtual Summit website.

  • DevOps Deeper Dive: Google Roils Open Source Community

    DevOps Deeper Dive: Google Roils Open Source Community

    Google this week agitated the bulk of the open source community by launching the Open Usage Commons consortium to protect the trademarks of open source projects, starting with the Istio, Angular and Gerrit projects it launched.

    Launched in collaboration with SADA Systems and some independent contributors, the stated goal of the Open Usage Commons is to help open source projects assert and manage their project identity through programs specific to trademark management and conformance testing.

    Istio is a service mesh that runs on top of Kubernetes, while Angular is a web application framework. Gerrit is a code collaboration tool.

    Unlike previous open source projects that Google played a major role in developing such as Kubernetes, Google has yet to contribute these three projects to an open source consortium. That decision has members of the open source community now questioning Google’s commitment to open source software.

    In fact, IBM, which launched the Istio project in collaboration with Google, this week said the Open Usage Commons does not meet the level of open source governance IBM expects. Originally, IBM said the expectation was that Istio would be contributed to the CNCF once it achieved a level of maturity. That contribution would include Istio intellectual property and the trademark. Now IBM is encouraging Google to reconsider its Open Usage Commons approach.

    If Google continues to hold on to the intellectual property rights for open source projects such as Istio, those projects will become little more than a community project that Google exercises control over, said Priyanka Sharma, general manager of the Cloud Native Computing Foundation (CNCF), which oversees the ongoing development of Kubernetes, among other open source projects.

    “It’s not in the spirit of open source,” said Sharma. “I don’t think you can even call it open source.”

    Other open source initiatives will be hesitant to build on top of projects such as Istio if the intellectual property belongs to a single vendor, added Chip Childers, executive director of the Cloud Foundry Foundation (CFF). The trademark is never the main issue, he said.

    “The trademark is only part of the consideration,” said Childers.

    In the case of Istio, the decision to launch Open Usage Commons might also draw more attention to a Service Mesh Interface (SMI) project being advanced under the auspices of the CNCF. That interface promises to make it easier to rip and replace one service mesh for another.

    In the meantime, Google may be trying to maximize its investments in open source projects that until now have tended to benefit rivals more. In terms of consumption of cloud services based on Kubernetes, Google is a distant third at best to Amazon Web Services and Microsoft.

    In general, there are more open source projects than ever. However, some of the entities that launch those projects have complained that cloud service providers simply turn those projects into cloud services in a way that consumes most of the revenue opportunities any open source project might generate.

    Google now appears to be exacerbating those tensions further by trying to retain control over the open source project it leads, while selling services based on other open source software projects. It’s not clear to what degree this rift might drive a wedge between multiple open source factions. Google with this move may just drive more members of the open source community into the arms of AWS and Microsoft. However, for the moment at least, none of the projects covered by the Open Usage Commons trademarks are so critical that they could not be replaced by any one of several alternative projects that are truly open source.