devopsy.kinsta.cloud

Category: DevOps Practice

  • Will Devs Return to the Office?

    Will Devs Return to the Office?

    Charlene O’Hanlon and Michael Davis, CRO at Rollbar, discuss findings from a recent developer survey exploring how devs feel about the return to the workplace. The video is below, followed by a transcript of the conversation.

    Announcer: This is Digital Anarchist.

    Charlene O’Hanlon: Hey, everybody. Welcome back to TechStrong TV. I’m Charlene O’Hanlon, and I’m here now with Michael Davis, who is the CRO at Rollbar. Michael, thank you so much for joining me. I appreciate it.

    Michael Davis: Thank you, Charlene. Great to be here.

    O’Hanlon: Well it’s great to have you here. I am really fascinated about a recent developer survey that you guys came out with regarding their attitudes toward going back into the office, and that’s always a hot topic among organizations no matter what they do. A lot of companies are grappling with just the aftermath, if you will, of the pandemic and the return to the workplace. If you rewind about 12 months ago, we were hearing stories about companies deciding that they were never going to have their employees come back and they were going to work remotely 100 percent all the time.

    And a lot of organizations, or a lot of employees I should say, kind of took those cues and decided that they just were going to go and move wherever they wanted to. And so now a year later companies are saying, “Well maybe we should come back into the office at least part time.”

    Davis: Yeah. Right.

    O’Hanlon: So there have been a lot of kind of ping-ponging I guess, for lack of a better term, and I truly believe that the rest of this year there’s going to be a lot of fallout from organizations dealing with employees who are no longer able to come into the office because of their location. But I’m interested in finding out what you guys found in your survey regarding that and some of the other findings that maybe surprised you.

    Davis: Yeah. That’s a great intro, although I might push us back even before COVID. I think this is especially relevant for a lot of the software development teams that we work with. If you go back before COVID, we had customers where their entire teams of developers didn’t even own a laptop. They were literally in the office all the time, every day. And so not only are companies now wrestling with this transition post COVID, but they had a huge transition they went through pre COVID, right? And that certainly put a lot of stress and strain on the companies, but more importantly on the actual developers themselves.

    And so here we are now coming to the end of this, as you’re describing, and we’re going through another transition. And I agree, I think what the survey starts to show is that this is not going to be black or white type of thing. It’s not going to be all of one or the other for many of the reasons you already mentioned. The survey was very clear in that first off it said 77 percent of developers were definitely significantly impacted by COVID and what this meant for them, and now as you start to interview folks and do the surveys you find that it’s a real mixed bag. You have folks who’ve enjoyed the freedom, enjoyed that flexibility, and have started to adjust to that to some extent.

    But I think one of the most interesting findings is that they’re missing that face-to-face component of their work. And if you think about developers and what they do, this is a team sport, right?

    O’Hanlon: Right, right.

    Davis: They’re really missing that day-to-day, face-to-face interaction, and especially given the sort of raised stakes, which is another thing that came out of this survey. What we found was sort of this external pressure on development was even raised higher. Why? Well, because customers are needing to interact with companies through software. So there’s even more pressure on building more software faster. So these are some interesting things that we saw sort of pulling against each other.

    O’Hanlon: So what do you think is the answer here? I understand that developers crave that face-to-face. I also see people who are now dealing with a level of social anxiety that maybe they never had dealt with before in their life. If you’re a year away from somebody or large groups of people it can be tough to reintegrate yourself into that environment. And as much as we all say I can’t wait for things to get back the way that they used to, we can go to concerts, we can go shopping and not have to worry about wearing a mask or whatever, you put people in some of these situations and it’s difficult for them. Some more than others.

    Some are just like, yeah, whatever, you know, let’s just go back and it’ll be fine the way that it was. But I’m not sure when people say I want to work with all these people, I want to get back into the scrum, I want to do this and do that, I’m just not sure when they actually do it that that’s really what they wanted. Do you think that there’s going to be maybe buyer’s remorse if you know what I mean?

    Davis: Yeah, there could be. My guess – and again, it’s based on some of the survey data we’re seeing – you do have this mixed feeling about your sort of life balance isn’t necessarily all you thought it would be by being home all the time. But I think you’re going to see the same thing. If we went back full time in the office people would be feeling that same kind of pressure around the commute and the things that go with that. So my gut says that now that companies have adjusted and people have adjusted more to being away, we’re going to see this hybrid environment.

    You’re going to see more of an environment where people are going to be in the office at certain times, but they’re going to have the ability to work from home at certain times, which again, carries its own set of things. We’ve seen lots of investment in tools, Zoom being one of them we’re on right now, but there’s a long way to go. Because the other thing the survey showed was that by having these distances it’s harder to get those answers, let’s say, as a developer that you might need in the moment. When someone’s not two cubicles away from you, you have to hope that they’re on Slack. And if they’re not, then you’ve got a delay and a problem.

    So I think the next thing we’re seeing is we’re seeing more investment in additional tools, in additional types of processes that help this hybrid environment more.

    O’Hanlon: Do you think that we’re going to see an increase in these distributed workforces on a full-time basis either as a direct result of the mass exodus during the pandemic or just because they can, that they’re recognizing that maybe we don’t have to be in the office all the time? Or Joe left and he can do it full time, so I’m going to do the same thing and what are they going to do?

    Davis: Right.[Laughs]

    O’Hanlon: Take away my birthday? It’s going to be one of these – I think there’s going to be this push-pull. And so I’m wondering do you agree with me? Is this something that very might happen? And what do you kind of see? How can organizations – how do you expect them to react to that?

    Davis: Yeah. And I would add to the points you made one other thing, which is companies I think have learned that once you remove this need for everyone to be in the office all the time this also starts to free up your ability to recruit more broadly and it gives you flexibility to bring on the type of people you want wherever they sit, right?

    O’Hanlon: Right.

    Davis: So I think that’s going to play in as well, and that’s why I think it really will be this hybrid environment. So what can they do about it? Well, they’ve got to be really mindful about how people work and they’ve got to be investing. Companies have to be investing in the right kind of tools. I’ll toot our horn a little bit here. Rollbar is about this sort of platform that gives you visibility across your teams on specific errors that you have in your code.

    That’s one example. If companies have tools like that in place, now you don’t have to be sitting two cubicles away. You’ve got the data you need right in front of you, real time, to be able to make those kind of decisions. That’s one example. There’s many, many more, but it’s going to be thinking about these workflows somewhat differently and making sure you have the right processes and data so people can operate more efficiently.

    O’Hanlon: Yeah. It’s going to be an interesting year I think as we do kind of transition back to life post COVID or even the final throes of COVID, because so much happened over the last 12 years and it was a lot for all of us to process. And now for us to kind of quote/unquote go back to the way things were I just don’t think it’s ever going to happen. I don’t think that we’re ever going to be back the way things were before COVID, and so that means a lot of changes within organizations and among employees and their understanding of work and how they approach it on a day-to-day basis. I think there’s going to have to be a lot of giving in, if you will for companies, that they’re going to have to take a brand new tack when it comes to hiring and retaining their employees.

    But employees also need to kind of understand that at the end of the day there’s a job that needs to be done and sometimes the best way to go about doing that job is to maybe be in the office or be face to face. So there is no one-size-fits-all solution here. Michael, great results. Were there any other things that popped out of the survey regarding developers and how they view work or work/life balance or salary or anything like that that you guys covered in this survey?

    Davis: We didn’t really touch on salary so much. I think the big takeaway points were just how pervasive the impact was on developers and what they were trying to do. That was the first thing. The second thing then was this notion that a lot of that sort of stress and strain that was associated with this was, one, just a normal transition, but also this higher demand for software, which I don’t think necessarily any of us really predicted, and that is added to what’s already software in the world. Every company is a software company kind of thing, right? So that’s the challenge, and that’s the challenge that Rollbar and other companies are working to help this community with, because it’s tough. It’s a tough job.

    O’Hanlon: Yeah. And to your point, I don’t think anybody expected it, but do you think that it’s going to be sustainable? I mean, is this something that’s going to be kind of the new normal, if you will? At least not may necessarily from a product – well, even from a productivity standpoint, but do you think the demand is going to remain as high as it has been over the last 18 months or so?

    Davis: I just have no doubt about that. I mean, there was already an incredible pressure on the system. These teams are already feeling lots of external pressure about being able to deliver features and functionality faster, right? We’re all hearing about iteration speed. And so I don’t have any question now that – again, I think companies have learned that maybe they don’t need the same kind of retail presence to serve their customer base. Which again, puts just more pressure on the need for software.

    So yeah, this all feeds into I think even a more challenging environment, but certainly a rewarding environment because these people are at the center of the epicenter right now of everything.

    O’Hanlon: Yeah. But I do worry about burnout. I do worry about the fact that – I think a lot of people really rose to the occasion at the beginning of the pandemic and all throughout it because they did recognize that there was a value to it. They could actually see how their work was impacting their company. And I’m not sure that once we go back to kind of whatever, whatever we’re going to call it, that that is going to sustain, and it’s really going to give developers and other employees for that matter kind of the push that they need. And it does concern me that we may very well see mass burnout among developers, and that could be bad for everybody.

    Davis: You’ve given me a great transition to one thing I wanted to mention, which is the next thing we’re going to be working on is some analysis around developer productivity. So I think you’re right on, spot on. I think that’s the next concern. I mean, it’s already a concern, but now it’s even more accentuated. DevOps was already a mixed bag in terms of developer productivity. I won’t spill anything, but we’re going to do a deep dive there and hopefully we’ll have some more great data for you.

    O’Hanlon: Well, come back and have the conversation with me when that’s ready, because I would love to continue this conversation. There’s a lot going on in the space right now and it’s got so much more to do with just business, the business side of things. There’s a real human element to all of this and I think it’s very important that organizations keep that in mind at the end of the day and so much more. But Michael, thanks for talking to me about this survey and the results of this one.

    Fascinating stuff, and it’ll be interesting to see how the rest of the year plays out in terms of everything that we’ve discussed today. So thanks again for your time. I appreciate you being here.

    Davis: Thank you. Thanks for the chance to talk to you. Bye-bye.

    O’Hanlon: Alright. Alright, everybody. Please stick around. We’ve got lots more TechStrong TV coming up, so stay tuned.

    [End of Audio]

  • Graph CDN for GraphQL APIs

    Graph CDN for GraphQL APIs

    Alan Shimel talks with Max Stoiber from GraphCDN, the CDN for GraphQL APIs. GraphCDN is now available to everyone with edge caching, query analytics, error tracking and protection from malicious queries for your GraphQL APIs. A video is below followed by a transcript of the conversation.

    Announcer: This is Digital Anarchist.

    Alan Shimel: Hey, everyone. Thanks for joining us on another Tech Strong TV segment. My guest for this segment is Max Stoiber—and if I mispronounced that, Max, I apologize. I did my best, but why don’t you say it correctly?

    Max Stoiber: Stoiber, but it doesn’t really matter. I’m really excited to be here—thank you for having me.

    Shimel: Oh, it’s our pleasure to have you on. But you know what, it does matter—names matter, right? My mom taught me that and somewhere, your mom or dad or both, their name and—they deserve to have it pronounced right, as well.

    But anyway, Max, thanks for joining us. Maybe more important than your name is the name of your company, so why don’t you start off with sharing that with our audience?

    Stoiber: Absolutely. So, I am the Co-founder of GraphCDN, which we just recently announced is now publicly available for everybody. And so, that’s sort of the reason I’m here is to tell you a little bit about that journey and how we got here.

    Shimel: Absolutely. So, GraphCDN—I mean, we’ve seen so much news coming out of kinda graph databases and graph data, and it really gives us a new way of looking at, I guess it’s part of nature, right? Things get more complex and bigger as we go on, and so you need new technologies to help you get your arms wrapped around it. And certainly, graph technology is a real up and comer, if you will, in terms of helping us wrap our heads around stuff like this.

    So, you know, why don’t we start with a little bit of background? Like, what does the company do, what’s the problem you’re solving—that kind of thing.

    Stoiber: Absolutely. So, GraphCDN is a GraphQL CDN. And GraphQL is a technology, in case you’re not familiar with it, that was invented by Facebook back in, I want to say 2014, maybe ’15. It’s been a while. And they use it—it’s basically like an API framework that lets people build very strongly typed APIs to communicate between their servers and their clients. And Facebook invented that, and open sourced it. And a lot of other companies started adopting it, because it feels very nice to use for developers.

    And so, we provide, similar to how other CDNs provide features for websites to make them faster, more secure, think, like, Fastly cloud there, we do the same thing for GraphQL APIs. And we do that for everybody, not just Facebook who has technology like this internally, of course, we do it for all the other companies that aren’t Facebook and don’t really have the time to build all this technology themselves.

    And we came to that whole thing because when we built our last status, me and my Co-founder Tim, we were using GraphQL and we had huge scaling problems. We were growing like mad, but we couldn’t just cache our GraphQL API, for example, because none of the existing CDNs support GraphQL. They can’t cache any of the data that goes through it.

    And so, we struggled with this and we built terrible solutions internally at our past companies, trying to solve this as best as we can. And then now, we got together and we said, “Hey, we just gotta solve this,” right? It’s almost, excuse my language, stupid that nobody’s done this, because it’s such a clear need.

    And so, we sat down, and it turns out it’s quite hard to solve, which is why it took us a while, but we finally got there and now we’ve got GraphCDN, and it does a lot of things for people that have GraphQL APIs. That’s sort of the broad strokes overview, I would say.

    Shimel: Absolutely. Max, you know what, you mentioned a little bit here and there, but let’s talk about your background and your history.

    Stoiber: Absolutely. So, I am, I would say, most widely known in the engineering community for having invented a bunch of open source projects, particularly in the front-end web development space. About 1 to 1.5 percent of all websites on the planet are powered by technologies that I invented, mainly by styled-components, which is one of the biggest ones.

    And so, I’ve sort of amassed a large following of engineers and designers and other tech people following me for my open source work. And then, I’ve previously co-founded a startup with two friends from California where we were building sort of a modern forum, in a way, sort of a mixture between WhatsApp and traditional, you know, the forums of the past where we used to hang out and have friends.

    That was then acquired by GitHub, and turned into GitHub Discussions so that the engineers on GitHub can then sort of hang out. And then I had a stint at GatsbyJS, another startup, that was building a JavaScript framework, or is still building a JavaScript framework, and I left that at the beginning of this year to focus on GraphCDN and really build that out with Tim. And sort of, that’s my background.

    Shimel: Very cool, and congratulations. Very, very impressive.

    Stoiber: Thank you.

    Shimel: Thank you. You know, look, I’ve worked with enough engineers and software developers to know that nothing is ever truly done, right? There’s always more we could do, right? Why GA now, why kind of emerge from Stealth, if you will—you know, why now?

    Stoiber: That’s a great question. It’s funny, because we debated this for a long time internally, because we felt like we were GA ready two or three months ago, right? We sort of had the basic set of features where we thought we could cover common needs, almost all of the common needs that we wanted to cover. We were ready or people, but also, GraphCDN, because it is a CDN, is critical infrastructure. If we’re down, our customers are down. And we take that responsibility incredibly seriously.

    Now, we’re based on Fastly’s edge computing technology. So, the infrastructure underlying GraphCDN is actually very solid. But we wanted to make sure that our part of that infrastructure was as solid as it could be. And so, we gradually on boarded early access customers, including the biggest rugby site in Australia and a bunch of others, to make sure that our infrastructure could really handle the load. And after we proved that out for the last two, three months, we said, “Okay, we are confident in our systems, we’ve found all the bugs we’ll find before with GA.” Of course, you can never find all of them. That would be—I think any engineer that says that is lying. But we found most of them, the ones that really mattered, and then we said, “Okay, it’s good enough, let’s have people sign up and really get this into people’s hands.”

    Shimel: Excellent. And let’s talk about the model for the company. I mean, with your open source background, I’m gonna assume, is there an open source graph?

    Stoiber: There actually isn’t.

    Shimel: No?

    Stoiber: The open source part of it is the GraphQL part, the framework that Facebook open sourced. But our infrastructure is fully proprietary. There’s actually—there’s sort of two schools of thought, right? You have companies like Sentry doing all of their core work in the open source and then providing hosting or other services on top. And I think that model can work quite well, but for us, because we’re critical infrastructure, we knew that we needed to be in people’s critical path and we knew we needed to be reliable, and that just takes a team, right? There’s no way that you can just run this on the side, you know, have it running in the background and not worry about it. It needs to be maintained. Somebody needs to sit there 24/7 on call and pay attention that this thing keeps running, just to make sure nothing goes wrong.

    And so, open source just didn’t feel like the right fit for that, because honestly, we’re gonna sit there 24/7 and make sure that our infrastructure stays up and doesn’t have any down time. And so, we did not go open source and instead have—we have a very generous fee plan, but beyond that, believe it or not, people pay us for the thing we provide. Which, of course, sounds ridiculous, because that’s what businesses do, but as an open source developer, that’s actually less natural to me than you might think. But it feels very nice, I have to say. We’re very appreciative of our customers for helping them scale and secure their GraphQL APIs. And so far, over the past months that we’ve had customers, everybody has been very happy that they have us and that’s very gratifying to see from our side, of course.

    Shimel: Agreed, agreed. When you say GA, I’m assuming GA, people can go buy and use this right now.

    Stoiber: Correct. Absolutely.

    Shimel: But is there a free trial, is there—

    Stoiber: Yes.

    Shimel: You know, because you know how software is consumed today, right? You gotta get it in people’s hands and deliver delight, right?

    Stoiber: Absolutely.

    Shimel: And if it’s good and they like it, they buy it.

    Stoiber: Absolutely. That’s the exact model we follow. We have a very, I would say, generous free plan. You can use us for free for up to, I think, 5,000,000 requests per month, which covers a lot of early stage startups, we’ve realized, maybe even more than we would’ve liked. It’s definitely a very generous free plan, is what we’ve learned, which is a good thing, because we wanna provide that value, particularly to those growing companies. And then eventually, when they hit the scale where they have more than 5,000,000 requests, it starts costing $10.00 per 1,000,000 requests. And so, it’s sort of, the pricing scales with your usage.

    In theory, you can throw as many requests as you want at us, since we’re based on Fastly and they handle a lot of traffic, I’m not very worried about not being able to handle scale. And we have—it was actually funny, after we GA’d and we announced that this is now available to everybody, of course, people signed up and then suddenly started deploying this thing to production and our traffic just 10X’d overnight, and we didn’t even notice. Like, we just looked at our graph, like, we woke up the next morning, we looked at our graphs, at our internal dashboards and we realized, “Hey, a site just enabled us overnight and 10X’d our traffic, and we didn’t even realize,” right? And they’re just—they were just like, “Yeah, this works, we’ll use it—perfectly fine.” And that just kind of keeps happening and it’s very, very interesting to see. I love it, I have to say.

    Shimel: You know, that’s one of the—so, I’ve been in the Internet business since ’96, ’95, and that truly is one of the remarkable things about the Internet is yeah, people, you know, if you put your shop out there, you put yourself out there, people come by. And they could be from anywhere, whether they’re from Australia, Japan, Korea, you know, Amsterdam, London, or next door, it makes no difference, they’re on the Internet. And all of a sudden—boom, you know, it lights up and it’s like, “My goodness, you know? We were hoping for this, but who”—you know, you never know. That’s fantastic.

    So, what are plans going forward? Have you guys announced fundraising, is that in the works, or—you know, where’s the continuing journey, here?

    Stoiber: We raised a round of funding a couple months ago from some well-known industry people, mostly friends of ours, like Guillaume ________, the CEO of Versel; Tom Preston-Warner, one of the Founders of GitHub; Jason Warner, the current CTO of GitHub. A bunch of friends that we knew from the industry that we also knew loved GraphQL and that they knew what it was about and they immediately got what we were working on.

    And so, we raised enough funding to sustain us for a couple years, and now we’re gonna use that funding to build a small team to help us maintain this, because right now, it’s just me and Tim—or has been just me and Tim for the past months, and now we’re starting to hire and on board the first people to help us really take this to the next level. Because it’s a lot of work, it turns out. [Laughter]

    Shimel: Yeah, I know, yeah.

    Stoiber: Building a great product is a lot of work.

    Shimel: Well, you know what they say, Max, if it was easy, everyone would do it.

    Stoiber: Exactly right. [Laughter] Absolutely.

    Shimel: But it’s fun work, right? There are people who really work for a living versus people who love what they do.

    Stoiber: Yeah, absolutely.

    Shimel: You know what we didn’t do, though, Max, we never gave anyone, like, the URL, where could they get more information, where can they download it? Where can they go?

    Stoiber: The URL and the home page is at GraphCDN.io, and it just has—as any website, it has a massive sign up button that you can click, and then you’ll be redirected to GitHub and you can sign up and just try it out. You don’t even need a GraphQL API, we have this sort of flow where we’ll give you a demographical API, just so you can get a feel for what it does and how it works. So, yeah, go to GraphCDN.io and try it out.

    Shimel: That sounds like a plan. Hey, man, you gotta come back and keep us posted of progress here, okay?

    Stoiber: I will absolutely do that. Thank you so much for having me.

    Shimel: Oh, it’s our pleasure. Max Stoiber, Co-founder, GraphCDN, it’s at GraphCDN.io—right, Max?

    Stoiber: That’s it. That’s the one.

    Shimel: Yeah. Go check it out. Seems pretty cool. This is Alan Shimel for Tech Strong TV, we’re gonna take a break and we’ll be right back with our next guest.

    [End of Audio]

  • Will Splunk be Gobbled up by Cisco?

    Will Splunk be Gobbled up by Cisco?

    Word on the street is that Cisco and Splunk are in discussions about a possible acquisition. Splunk, the technology monitoring, search and analytics company could be acquired by Cisco—originally a networking company but now a complex hardware and software conglomerate.

    Splunk has generated quite a reputation as a ‘dealer’ over the years. The company, much like a drug dealer, gets you hooked and then, when you can’t live without what they’re selling, makes you pay. The difference is that what they’re selling is insight and visibility into your own data.

    For many years, Splunk’s pricing model was simple—customers paid for the amount of data that was ingested. Splunk didn’t invent this type of pay-for-what-you-use-and-consume model. For mainframe workloads, IBM has long charged clients based on millions of instructions per second, or MIPS. Likewise, the entire cloud computing business model is based on a pay-for-what-you-use model. If, for example, you leave an AWS experimental instance running over the weekend or while you’re a vacation, you’re going to pay for it (many of us have learned that the hard way).

    So why am I picking on Splunk for being a dealer? The whole value proposition of Splunk is that the more data it ingests, the more useful the software platform can be. Splunk can help operations and security teams connect disparate data points to uncover potential emerging problems or greatly reduce the time it takes to resolve an incident. However, to unlock the power, you need to push more and more (and more and more) data into Splunk.

    But here is where Splunk gets down and dirty: Like any dealer, Splunk will give teams free trials and the ability to ingest data from new areas of your business for free. Once a team starts to see the value and is hooked on the software, the Splunk sales team is right there to take your money.

    Splunk now offers other pricing models, but the stigma sticks.

    Splunk Customers are the Company’s Best Salespeople

    Splunk has done an excellent job at creating evangelists out of their existing client base. I’ve attended a lot of vendor conferences, and my experience is that Splunk’s customers are some of the most enthusiastic I’ve ever encountered. What does user enthusiasm tell me about a vendor’s product? It is either that the product is making that employee a superstar within their company or making that employee highly desirable across the broader technology market.

    At Splunk events when I have candid conversations with customers, the adoption pattern follows a fairly standardized script. The IT operations team adopted Splunk. IT operations had a ton of success and shared that with the rest of IT. Security saw ops’ success and wanted to try Splunk out for themselves. In many cases, the cybersecurity use case within the company became the bigger Splunk deployment once the platform’s capabilities were understood.

    So Why Would Splunk Sell?

    Customers like Splunk and they’re obviously seeing value. So, why would a company like that ever sell? Well, first of all, the SIEM 2.0 market vanished; security log data analysis is table stakes. What do I mean by that?

    So Long, SIEM

    The idea of security information and event management (SIEM) hasn’t gone anywhere, but now security vendors need to do more than just SIEM.

    It wasn’t long ago that those of use following the security industry tracked RSA Netwitness, Logrhythm, IBM Qradar, HPE ArcSight, RSA Archer, Carbon Black and other SIEM vendors. The reality is that all of these companies have gone through massive transformations. Those of you reading this article might be surprised by the companies that now own many of these SIEM vendors!

    Splunk is no longer unique in its approach to applying machine learning and artificial intelligence to security log data.

    AIOps—The Company Lost its Focus

    Splunk cut its teeth with operations teams. The company helped ops teams quickly find the root cause of disruptions and spot problems before the pain was felt by customers. However, operations isn’t sexy. Rather than doubling and tripling down on operations, the company expanded to security. It made sense; security organizations deal with huge amounts of complex data.

    However, as DevOps rose to prominence, Splunk has been widely left out of the conversation. DevOps teams need software tools that can normalize data across job function-specific software platforms. This would have been a perfect opportunity for Splunk—however, new competition stepped in to fill this gap.

    The World Evolved—Businesses Need Observability

    SIEM 2.0 was hot—“was” being the operative word. Today, DevOps and DevSecOps teams are looking for observability offerings. Observability tools provide teams with the ability to understand and see what is going on within systems and software from a variety of perspectives. Observability platforms can view system and cloud health and resiliency, but can also give operations teams container-level data.

    Enter the Observability Vendors

    By no means is this a comprehensive list, but my colleagues at Techstrong Research and I have come up with a list of observability vendors you should be paying attention to. Some of these vendors are pure-play observability companies while others, like Splunk, have a variety of offerings.

    •   Splunk
    •   Sumo Logic
    •   Logz.io
    •   StackState
    •   Lightstep (acquired by ServiceNow)
    •   Dynatrace
    •   App Dynamics
    •   VMware – Tanzu
    •   AWS CloudWatch
    •   Azure 
    •   Honeycomb.io
    •   Grafana Labs

    Acquisitions

    •   IBM acquired Instana for observability and Turbonomics for AIOps
    •   Cisco acquired Epsagon
    •   Cisco acquired AppDynamic for $3.7B for application performance management/monitoring
    •   VMware acquired Mesh7
    •   GitLab acquired observability distribution Opstrace 
    •   NewRelic acquired CodeStream
    •   Splunk acquired SignalFX, FlowMill and Omnition
    •   ServiceNow acquired Lightstep

    Within the observability space, there is also a tremendous amount of open source. Many vendors are coalescing around the OpenTelemetry project, for instance, that focuses on collecting data. This type of open source use makes sense—vendors should focus on areas of differentiation and customer value rather than just data collection.

    Open Source related projects

    • Prometheus
    • OpenTracing and OpenCensus from Google (folded into OpenTelemetry)
    • Zipkin (Twitter) one of the first open source tracing projects

    Why Would Cisco Want Splunk?

    Splunk’s stock has been in decline since its CEO left in Q4 of 2021. Like other technology companies, inflation and a general technology sell-off is further impacting its stock price. In addition, the company is transitioning clients to cloud-based offerings, which is often a painful process for public companies (many companies have gone private to eschew Wall Street’s prying eyes).

    Cisco has, historically, occupied the network layer. Splunk understands network data and can offer many benefits to Cisco clients.

     Splunk is an enterprise software vendor that can scale in a non-linear way if Cisco can add stability to Splunk’s leadership and vision.

    Now, will the deal for Splunk get done at $20 billion? No. But a possible acquisition is very possible, especially given the fact that Splunk’s runway is short and getting shorter.

  • Dependability is Crucial for Real-Time Experiences

    Dependability is Crucial for Real-Time Experiences

    Millions of people around the world experienced a major disruption after an October 2021 outage saw Facebook, WhatsApp and Instagram go offline. A few days prior, the popular workplace collaboration platform, Slack, also went down for some users. And in the last few weeks of 2021, Amazon’s AWS caused considerable global chaos after significant networking issues in its busiest data center, US East 1, disrupting streaming services such as Disney+ and Netflix.

    Downtime can be costly, causing organizations to lose $5,600 per minute and up to $300,000 per hour, on average, according to Gartner. But it’s not only financial and reputational loss that businesses need to worry about. Outages also seriously downgrade—and in the case of real-time experiences, completely disrupt—the customer experience.

    At a time when consumers are demanding more live and interactive digital experiences, organizations can ill afford disruption or downtime, as customers quickly move to other services that ‘just work’.

    It’s not just the capacity within a real-time system that matters, but also globally distributed failover capabilities when something does go wrong. While organizations could try to build their own failover mechanisms, it’s extremely difficult to failover so services continue seamlessly, regardless of the status of its underlying infrastructure. Simple failover systems not only take longer to resume but typically suffer data loss during the time that a region is disrupted. Businesses need to know that even if, say, AWS suffers an outage, they won’t be affected.

    This is why it’s vital that organizations get it right when looking to develop their own real-time infrastructure. Managing tens of thousands if not hundreds of thousands of concurrent connections while synchronizing data in real-time means that if anything does go wrong it’s immediately obvious to users. If tech behemoths like Amazon and Facebook can’t get it right, what chance do organizations with far fewer resources have when building and managing their own real-time infrastructure?

    The Steps to Success With Real-Time Infrastructure

    Regardless of whether it’s for synchronized multi-user collaboration, audience engagement or instant updates, developers have a hard enough time developing even the most basic of real-time infrastructure, let alone making sure it’s dependable. There are four key elements to achieve dependability: Predictable performance, data integrity, reliability of service and high scalability.

    • Predictable performance: When we think of performance we usually imagine more computing power or speed. But when it comes to real-time, it’s not just about minimizing latency and bandwidth, it’s about having a predictable system. If developers have global latencies and bandwidth within certain operating boundaries, it provides certainty in uncertain operating conditions. This makes it easier to design, build and scale features around this certainty.
    • Data integrity: As we all know, the internet can be an unreliable network. Users abruptly disconnect and reconnect all the time, resulting in data that gets lost, is delivered in the wrong sequence or that is sent multiple times. As a result, organizations must ensure their infrastructure can guarantee high integrity without sacrificing anything else.
    • Reliability of service: The live nature of delivering updates in real-time requires total reliability. Outages can cause distrust and annoyance from users. Organizations could find their reputation taking a hit or customers quickly jumping ship if reliability proves to be a recurring issue. To prevent this, organizations should develop infrastructure that’s fault-tolerant and redundant at both a global and regional level so they can deliver a great experience even if there are multiple failures.
    • High scalability: More often than not, delivering an experience in real-time can result in unpredictable traffic; for example, a huge number of people wanting sports updates for a World Cup game. If thousands of devices connect over a short period of time but capacity can’t scale up quickly enough, then an outage will occur. To avoid this, developers must use infrastructure that can be elastic and meet changing levels of demand. Otherwise, the user experience is seriously affected and real-time capabilities crash when the network is swamped with connections it can’t cope with.

    While organizations often build their own infrastructure with the best of intentions, it’s easy for them to run into trouble. Most lack the internal expertise, resources and time; plus, going it alone often results in a huge technical debt. It’s also a massive undertaking, due to the amount of ongoing complexity and cost involved.

    Third-Party Partnerships Enable Dependability

    Unless organizations have the resources, finances and expertise of the likes of Amazon or Google, then building your own real-time infrastructure is just setting yourself up for failure. Instead, they should save on development cycles and focus on generating revenue more quickly by offloading their real-time infrastructure needs to a third party. This will mean organizations can design without limitations and focus on solving the challenges that really matter to them while putting in place real-time infrastructure that is as dependable and future-proof as possible.

  • Using Data Fabric for Real-Time Processing

    Using Data Fabric for Real-Time Processing

    Charlene O’Hanlon and Scott Gnau from InterSystems talk about silos in organizations and how data fabric enables organizations to process, transform, secure and orchestrate data from disparate sources in real-time. The video is below followed by a transcript of the conversation.

    Announcer: This is Digital Anarchist.

    O’Hanlon: Hey, everybody, welcome back to Tech Strong TV. I’m Charlene O’Hanlon, and I’m here now with Scott Gnau, who is the VP of Data Platforms at InterSystems. Scott, thank you so much for taking the time and getting on the call with me, I really appreciate it.

    Gnau: And likewise—thanks for having me. It’s great to be here.

    O’Hanlon: Alright. So, tell me a little bit about InterSystems.

    Gnau: InterSystems is a creative data technology company, we’re based in Cambridge, Massachusetts. We’ve been around for about 40 years, and we actually build data integration, data platform technology that’s used by a lot of very sophisticated applications around the world—in fact, more than half of medical records in North America go through our systems, 15 percent of global equity trades touch an InterSystems data platform or interface along the way.

    So, we’re known for solving very large, complicated, business critical problems that are centered around data.

    O’Hanlon: Well, data is the new oil, right, is that what I’ve heard? Time and time again, so many companies now rely on the data to make their business decisions and find areas of opportunity and so much more just, you know, ways to do their business better. So, data—you guys are definitely in the right space, for sure.

    Gnau: Absolutely.

    O’Hanlon: [Laughter] So, let’s talk a little bit about, then, the issue of silos when we’re talking about data and access to data, especially when we’re talking about things such as customer experience or uncovering those opportunities within the business, whether it’s improving internal processes or external applications and issues and things that do touch end users.

    So, we’ve been talking for a long time about breaking down silos when it comes to data, but do you think that that’s something that’s feasible or do you think that it’s kind of one of those wishes that will never really come true?

    Gnau: [Laughter] I’ve kind of given up on the breaking down the silos, and I’ll back into that with, you know, I’ll hit on a couple of things that you said. Because I think some of the things you said are actually really, extremely relevant, right? Data being the new oil and, you know, people have been saying that, and it’s absolutely the case. If you look at the wealth that was created in the 18th Century, it was railroads, and if you look at the wealth that was created in the 20th Century, it was energy and oil, right? Look at the wealth that’s been created in the last 20 years. It’s all about data centric kinds of companies, right?

    O’Hanlon: Right.

    Gnau: And that’s a really cool thing. And the difference really is, you know, companies can leverage that data not only to understand their business and have a rearview mirror view of what happened in the business and be able to make better decisions about it, but actually synthesize that data into building new businesses for themselves and new ways to interact with customers and so on. So, it’s absolutely critical and important.

    And sadly, I’ve been in industry, I guess, about 35 years. It feels like just five, but a long time. And throughout that career, we’ve been talking about how do we break down silos in data and silos in data processing? And, you know, silos crepe up for many different reasons. They can creep up because you’ve deployed an application that’s very specialized to go solve a problem that’s extremely important and the data that gets collected is kind of in that application and not shared easily, and that becomes, eventually, a silo in and of itself.

    Certainly, there are business model and political silos that get created, right? I’ve got a business unit model and the mortgage folks don’t wanna talk to the consumer lending folks don’t wanna talk to the deposit folks and so on. And it’s also very easy for silos to build up because of geographic differences in the business, right?

    O’Hanlon: Mm-hmm.

    Gnau: And so, this has been going on for a long time, and for a long time, we in technology have tried to solve and advise our clients, “Hey, don’t let silos control you.”

    O’Hanlon: Right.

    Gnau: I would say that the problem of silos and how they come up has actually gotten larger and is increasing at almost an unimaginable pace. Certainly, with the advent of the cloud and microservices and easy to spin up applications, more and more silos can come up very, very quickly. The fact that data and relevant data, the oil of our businesses used to be created inside the business, inside the firewall by our application, so we actually had some semblance of control over it. Now, a lot of the data that we need to use, understand, consume, and drive decisions from may live its entire life cycle outside the firewall of our business and out of our control.

    So, you think about one of the drivers of silos, and it just has now gone kind of exponentially very different.

    O’Hanlon: Mm-hmm.

    Gnau: Certainly, the pandemic has created more geographic silos, but also, the need to be able to deploy data and decision making very quickly as many of us have been remanded to our home offices and trying to manage customer relationships and run our businesses remotely in a new and a different way.

    So, I think kind of the drive for silos is going to continue to increase. And so, I think it’s also then unimaginable to think that we will live in a world without data silos. So, if that were the case, it’s kinda like, how do we come up with an approach that lets us leverage and build beyond that?

    O’Hanlon: Yeah. So, you know, it’s a very good point that you make, the fact that we’ve had so many silos, the number and the velocity of silos has increased multifold, I would imagine, since the onset of the pandemic. And with this remote and hybrid work environment that we’re now entering into, I don’t think those silos are gonna be going away.

    So, short of I don’t know what, short of whatever an organization needs to do to break down those silos, how can an organization work effectively to access that information and to get the information they need and really kind of make the most of it without being able to break down those silos? Is there a way that they can still utilize that information as effectively as they could if there was—you know, if everything was kinda linear and they could just kind of skip across the data meadow, if you will, and kinda pick the flowers as they went along? I don’t know where that analogy came from, but [Laughter].

    Gnau: Well, listen, it would be less interesting if it was equally kind of a serial thing when you go pick up those flowers.

    O’Hanlon: Right, right.

    Gnau: And certainly, we talk and work with our clients, really, about this concept that we call the data fabric and a lot of technology ins and outs and all that kinda stuff with data fabric, which we probably won’t get into a lot today, but it’s almost at a mindset. And the way I describe it, being a pilot myself, is—think about being able to have a control tower kind of impact to how you manage and integrate your silos.

    So, think about control towers in flight, right? What is the purposes of having control towers? Well, obviously, the mission is to provide safe flights. How do they do that? Well, they connect different kinds of data together and synthesize that data for decision making, right? They don’t consolidate it, they don’t fly the planes, necessarily, but they collect that data and then disseminate it in a way to kind of control and coordinate the flow.

    O’Hanlon: Right.

    Gnau: They also, it’s not a single point of contact kind of consolidation, right? There’s a control tower at every airport, right? And they connect to each other as well to manage traffic between their segments and sectors in that grid. And so, the notion of control tower is a way to think about, how do you apply that technologically speaking into thinking about your infrastructure more as a data fabric and the things that are necessary from a mindset—again, not a specific technology or a vendor, necessary—but just a mindset of how to manage through the notion of silos.

    And so, the first thing, really, is something that’s also kind of nontraditional in data processing, at least during my career, it’s all about connecting data and not consolidating data, right? And for many years, it was like, “How do I consolidate all this stuff into one place to make it more manageable to take cost out?” and all that kinda stuff. Again, in a cloud-centric world, almost unmanageable.

    O’Hanlon: Mm-hmm.

    Gnau: So, instead of thinking about consolidating it, really think about how do you connect the different data across different places? And that obviously becomes a key part of your data fabric—the connectivity, the pipes, and the widgets, and how they fit together. Connectivity isn’t enough without context.

    O’Hanlon: Mm-hmm.

    Gnau: So, data that’s created in the silo may have a certain context inside of the silo, but that context needs to be reflected externally just like the control tower needs to understand what kind of plane you’re flying, because they’ll understand the operating capacity of that plane—how fast does it go, how high can it go, and what are its maneuvering capabilities, right?

    Same kind of thing in a control tower kind of aspect to data fabric—connect the data and provide context for the data so that, as the data get connected, there’s some relevance to what is happening and something could actually be derived from it.

    O’Hanlon: That makes a whole lot of sense, and to your point, having the data remain kinda siloed and just being able to kinda select the data that you’re looking for, you know, that’s most relevant to you at that time, I imagine actually, is a little bit easier than kinda sifting through an entire haystack for one little needle. So, that’s a really interesting concept.

    Is this a technology that is currently being used within the data management space, the data science space?

    Gnau: You know, there are more and more people talking about it, and I’m sure there’s some folks that maybe have different words to describe it. We’re thinking, and some of the analysts that we work with as well, are talking about the data fabric. I’d say first and foremost, it’s a mentality, but like I said, connect, don’t consolidate. Provide the context. Have the control towers communicate amongst themselves so it’s not a single control tower but multiple different control towers for the context or the application that’s required and kinda think about the network effect of being able to build that out.

    Once you have that mentality, then it comes down to a checklist of, you know, certainly a list of what is the existing technology that we have and what is the existing technology that we use, how are the data created, how are the data stored—you know, kind of just a roadmap of what ya got. And then, think about the connectivity and the context provisioning that you want to create and look at other technologies that might need to be added to the mix to make that work in an end to end state.

    So, it’s a mindset first, and then it’s a collection of some technologies to enable that, and it’s a combination of the existing stuff that you’ve got, and certainly, an application that’s been deployed in a business-critical nature, you’re not gonna yank that out for some technology decision. So, again, it’s all about that connectivity and fitting it together and piecing it together.

    The other thing that most of the clients that we’re talking with about this are very pragmatic, it’s not a—like anything ever really should be, it’s not a 10-year plan, but it’s an, okay, how do I map this sector? How do I put a control tower at this airport and this airport and how do I leverage that, right? So, how do I go connect this silo and that silo, and then let’s go get the next silo and let’s go get the other business unit and figure out how to kinda build that out over time.

    And what’s really cool is, the value accelerates as you start to collect more of these things together. And, you know, you’ve got three or four and then you add the fifth one—the value doesn’t go up 20 percent, the value actually, of what you can do with that can go up dramatically, much higher, because of being able to understand all of the customer interaction points and create new programs, or leverage that data to actually go build a new line of business that your customers weren’t expecting.

    O’Hanlon: Mm-hmm. Right, right. Interesting. That’s really, really fascinating to me. Now, does this also kinda democratize the data? Does it enable other parts of an organization to access the value from a lot of this data by using this data fabric without the need for maybe a data scientist or somebody who’s a specialist in this in an organization?

    Gnau: Yeah, absolutely, absolutely. And again, it’s a mentality and needs to be kind of thought of with a design going in, right?

    O’Hanlon: Mm-hmm.

    Gnau: So—right, in today’s world, thinking about security and privacy on one plane and then democratization of data on the other plane, they’re almost kind of at odds. So, there needs to be some forethought that goes into what is appropriate for the appropriate eyeballs in these different spaces, and then again, making sure that the technology stack that’s been built out has the capability to deliver that. But certainly, companies that—in my experience, at last, companies that have the most success in kind of refining their oil, their data, are the ones who are actually getting data anywhere that the data need to be for a decision that’s local, right?

    So, you know, people talk about real time decisions and real time AI models and all that kinda stuff. All really compelling, all really valuable, but all completely worthless if you can’t leverage that to deliver a yes to a customer when the customer asks a question, right? And so, democratization and the architectural democratization of the data is an important key component to making your data fabric really successful and really showing up with a lot of value for the business.

    O’Hanlon: And I would imagine that AI, machine learning—you know, those technologies can actually add a whole lot to making this a much more intelligent way of gathering data as well.

    Gnau: Yeah, and it’s a symbiotic relationship, right? So, you know, machine learning and AI are all the rage and all really good stuff. A lot of the math behind it is not particularly new. What’s interesting is, the math behind it dictates that the more data you add to the model, the more accurate the prediction becomes, right? And that is very different than some of the previous kind of data mining and data science stuff that went on.

    And so—okay, that means you need lots of data. How do you get lots of data? Well, you don’t if it’s in a bunch of silos that don’t talk to each other with no context and no connectivity.

    O’Hanlon: Right.

    Gnau: So, I actually think they’re kind of symbiotic in that an effective data fabric could actually enhance the capabilities of your AI programs, and your AI programs can actually enhance the value of your data fabric in return.

    O’Hanlon: That’s really, really fascinating. [Laughter] I love this topic. I think this is definitely something that more organizations should be considering, because you know, especially if you think about just the sheer volume of data that’s out there and, I mean, really, what organization today is not basically putting their entire business on the shoulders of data without having that information that they need to make those business decisions to uncover those opportunities to just basically survive and thrive in today’s environment. I really—short of having that data, I just don’t know how organizations today can do it.

    So, I think anything that’s going to make it easier for them to uncover those areas of opportunity and find those nuggets of information that’s in all of that data, I think, is gonna be a huge, huge value add for organizations.

    Gnau: Yeah. I mean, and the last piece, really, of success for a data fabric and why I think data fabric is so important—I tried to come up with something that started with a C, because I said connect and then context. But the last one really is lineage, because lineage creates trust.

    O’Hanlon: Mm-hmm.

    Gnau: So, you know, it’s interesting, the other interesting thing about some of the AI models out there is that the answers they create are actually sometimes not intuitive.

    O’Hanlon: Right.

    Gnau: And as human beings going to execute these things, we’ve gotta really trust that the models and the data are effectively connected, so that we’re gonna risk our business on these decisions, right?

    O’Hanlon: Yep, yep.

    Gnau: And so, you know, connectivity, context, and ultimately lineage or trust of the data are kind of the three key components, again, of the mentality. Nothing to do with technology, but you’ve gotta kinda build in what’s your framework, what’s your appetite in your business for these pieces and then go look at the technology landscape to start building it out.

    O’Hanlon: That’s a very intelligent way of going about that, too, so—I love that. Scott, thank you so much for having the conversation with me about data fabrics. I know we’re gonna be hearing more about it in the future. I think it’s a great mindset and a great way to approach data access and data use in an organization. So, thanks again for your time and your expertise, I really do appreciate it.

    Gnau: Thank you.

    O’Hanlon: Yeah. Alright. Alright, everybody, please stick around, we’ve got lots more Tech Strong TV coming up, so stay tuned.

    [End of Audio]

  • DevOps for Customer Experience

    DevOps for Customer Experience

    Charlene O’Hanlon and Amy Hudson of Cyara discuss the concept of DevOps for customer experience, which takes DevOps methodology and focuses it on CX software. But there are pitfalls DevOps teams face when dealing with customer experience software. The video is below followed by a complete transcript of the conversation.

    Announcer: This is Digital Anarchist.

    O’Hanlon: Hey, everybody, welcome back to Tech Strong TV. I’m Charlene O’Hanlon, and I’m here now with Amy Hudson, who is the VP of Global Center of Excellence at Cyara. Amy, thank you so much for taking a couple minutes and talking with me today—I really appreciate it.

    Hudson: I’m happy to be here.

    O’Hanlon: Great, great. So, Amy, tell me a little bit about Cyara to start off.

    Hudson: Oh, absolutely. Cyara has been around for about 10 years at this point, but we really focus on what we call customer experience assurance. Companies spend a lot of money in designing the right customer experience and all the technology that supports it, and Cyara is in the business of making sure that you are getting the experience you’ve invested in. And if you are, how do we help you continue to innovate and double down? And if you’re not, how do we help you fix it very quickly so you can stay ahead?

    O’Hanlon: Alright. That sounds great, and I imagine your business has been booming over the last year or so, because customer really came to the forefront for a lot of organizations as they kinda had to double down on their digital transformation efforts just to stay alive over the pandemic, over the last year and a half or so. And some of them have done it really well and others have not done as well.

    So, what are you guys seeing in the market right now as far as customer is experience is going?

    Hudson: Yeah, no, that’s a great question, because it has changed a lot in the last year, with the pandemic. I mean, listen, customers have historically always been demanding, right? That’s in our nature as customers. But now, with their hands on the technology, customers have very high expectations right now. And switching costs are low. So, if a customer doesn’t get what they’re looking for out of an experience, you may lose them.

    And so, the importance of having a good customer experience and staying ahead of it is at an all-time high from our perspective.

    O’Hanlon: So, we’ve been, obviously, you know, through DevOps.com, we focus on the benefits of going with a, kind of a DevOps methodology and mindset and culture shift and all that good stuff. And we’ve seen kind of that whole premise of DevOps kind of shifted to other parts of an organization as they recognize the benefits of kind of blending two different maybe mindsets and areas of an organization together to kind of streamline operations and actually build a better product in the long run.

    I imagine customer service is not—has not been left out of the conversation when we’re talking about organizations adopting those DevOps principles for customer experience.

    Hudson: Yeah, that’s right. It’s interesting. So, about four or five years ago at Cyara, we started seeing DevOps fold into the contact center/customer experience space, but it was a little bit more of a rarity then. DevOps hadn’t necessarily intersected with customer experience yet at that point, but over the last three couple years or so, we’ve really seen DevOps become much more commonplace in the customer experience space. Which I think is a good thing, because, exactly what I mentioned before—you need to stay ahead. You need to be able to innovate quickly for customer experience, and I think these companies are starting to see that.

    So, we’re starting to see DevOps adopted almost universally. Either somebody has started it or is halfway through or a little more mature, but it’s in the conversation with almost everybody we talk to these days in terms of customer experience.

    O’Hanlon: That’s great. That’s really great to hear, because there are certainly a lot of benefits to DevOps in the customer experience space, you know, not the least of which is being able to service the customer much more effectively and quickly.

    But it’s not kind of a one to one adjustment, though. You know, it seems like, especially since, when we’re talking about DevOps, we recognize that each DevOps implementation and each DevOps experience, if you will, is different. You know, everyone is kind of a snowflake.

    So, how does that equate to the customer experience and how might that actually kinda trip up organizations if they’re looking to kind of add DevOps to their customer experience?

    Hudson: Yeah, absolutely. So, when I first started at Cyara, I led a very small strategic consulting group, and we worked with customers on how Cyara can help them through any major transformation. And because of the shift of the industry, it ended up being a lot of DevOps transformations. And so, we’ve seen customers at multiple different points in the journey, and the struggles that they’ve bumped into. And I think there are a number of different kind of pitfalls if you will, or lessons learned from that.

    And, you know, one of the first things—and we can go into as many of these that are of interest, but one of the first things and most important that pops out at us is that leadership level cultural shift. I think, so frequently—and I’m leading with this because if you don’t get this part right, it’s really gonna hold you up. But so frequently, DevOps is viewed as a technical or process change and so, it happens at the day to day level. But really, it is a mind shift, cultural shift, has to be top down, has to be embedded in the culture, and it has to be leadership driven.

    O’Hanlon: Mm-hmm, yeah. I agree, agree, and that goes across an entire organization, no matter where they’re implementing DevOps, whether it’s in IT or if it’s in the back office or marketing. Because we’re seeing this blending of so many different disciplines in an organization these days as ways to advance and accelerate just their ways of doing business.

    But to your point, if we don’t have, or if an organization doesn’t have that buy-in from the top, no matter where they’re implementing DevOps in an organization, it’s doomed to failure.

    Hudson: That’s right, that’s right. And it’s, you know, and it’s not just the kickoff, it’s not just somebody at the C level saying “rah rah” at the beginning.

    O’Hanlon: Right.

    Hudson: This is, like, through the process, embedding into how you motivate, incentivize, how you reward people, how you—you know, in your regular cadences. It’s everywhere. It needs to be treated as a cultural shift.

    O’Hanlon: Yeah, yeah. I totally agree. Now, what about, you know, beyond kind of that initial, as organizations start to kind of adopt this mindset and these principles, what are some of the things that maybe we call it kinda DevOps Phase Two or DevOps 2.0, the Second Day DevOps—what are some of the things that you guys are seeing that organizations need to be very mindful of to make sure that they are successful?

    Hudson: Yeah, another thing that we’re kinda bumping into at more of the kind of operational level is, as you know, the importance of flow in DevOps, right?

    O’Hanlon: Right.

    Hudson: You don’t wanna disrupt the flow. And to do that well, you have to think about automation, right? It’s just—it’s a no-brainer. It’s a pillar, right? And to me, when I think about automation, there’s a lot of different pockets you can automate. But for me, I think primarily around deployment automation and testing automation.

    We did an interview—or I did an interview with a consulting, one of the big four consultants with the DevOps expertise and a customer. And both of them agreed that automating the testing, while it’s not always completely simple or straightforward, it is, they would almost consider it the low hanging fruit, right? Get the testing automated so you can just kind of plug and play that part of it, don’t disrupt the flow.

    From a deployment perspective, there’s a number of different environments, right, to get something into production. So, the more you can automate from that perspective, the more you can continue to push things out and learn fast and fail fast, if you will.

    And so, finding those pockets of automation and having a strategy on how you can automate as much as possible as to not disrupt the flow is something that we’re really recommending to folks to realize the total benefit of the transformation.

    O’Hanlon: What about from a people perspective? You know, DevOps is as much about culture, as we know, as it is about the processes and the technologies. So, are there ways that organizations—maybe they’re not thinking about particular things when it comes to culture and people in their adoption of DevOps specifically for customer experience?

    Hudson: Yeah, sure. So, I would answer that a couple different ways. The first one I would talk about is essentially around—this is, again, it’s a culture thing. One of the pillars of DevOps is to create an environment that encourages learning and a safe place to fail. And so, you want your teams to be encouraged to fail if they have to and learn from it and get better the next time and feel safe doing that. So, that’s one from a person perspective.

    The other thing I would mention is just around measuring, key performance indicators, right? You can’t know if you’re successful without measuring, right?

    O’Hanlon: Mm-hmm.

    Hudson: And then publishing those KPIs so they’re transparent. Transparency is really important, so everybody is charging towards the same goal, and everybody feels like they are part of achieving that goal. So, let’s get the performance indicators out there, let’s be clear what we’re trying to achieve, let’s make people feel safe in that process. And, you know, that’s kinda the culture you wanna build around it.

    O’Hanlon: So, when we’re talking about customer service applications and software versus, say, an internal process or internal DevOps process or an internal application that is being advanced by these DevOps processes, what is the difference when we’re looking at what may be what those KPIs are or what the service level objectives are, things like that? Are there certain things that an organization needs to be more mindful of when they’re working on a customer experience type software rather than maybe more internal focused or maybe other customer that’s not maybe customer facing, end user customer facing?

    Hudson: Yeah, I think that’s a great question. And what we’re trying to do within our industry is create this mind shift where you are thinking about the end customer all the time—not just in the production environment, you are always thinking about the end customer experience through every step of the journey.

    And I’ll give you an example of what I mean by that. Traditionally, the contact center space, how they would monitor things in testing or production is kind of server loads or capacities, right? If it’s reached capacity, it’ll set off an alarm and that’s a problem, right? You don’t want it to be at capacity.

    Great, but you might not know what the customer experience is if that server is at capacity, right?

    O’Hanlon: Mm-hmm.

    Hudson: And so, at Cyara, what we’re trying to do is say—absolutely, that server might be at capacity and that’s a problem, but what is the customer experiencing in the moment right now in production? But we also wanna test in Dev and QA and UAT and performance testing, what the customer experience would be. So, if there’s an issue that comes up, you know it could be a pretty serious one, it could be calls being disconnected. If, in your revenue generating phone lines or chat windows, customers can’t get through—you wanna know that before it gets into production.

    O’Hanlon: Mm-hmm.

    Hudson: You don’t wanna know necessarily that—or it may be less helpful to know if a certain piece of technology is at capacity. What’s most valuable is to know what the customer would experience in that moment, even before it gets into production, if you can do that.

    O’Hanlon: Interesting. You know, it’s really fascinating to have the conversation about DevOps in different vertical markets, because everybody’s got something different that they’re really, really focusing their efforts on, but at the end of the day, it really is all about just making sure that the end user experience is the best it can be, and that the application is working as advertised and certainly that there’s a level of security as well within that application.

    So, I do imagine that security is also a big part of the equation, especially with the customer experience and the amount of sensitive data that a lot of contact centers, to your point, that they’re dealing with on a regular basis. So, heavy emphasis on Sec on DevSecOps?

    Hudson: Oh, absolutely. And that’s really from two ends. One is that customer data, right? There’s—you have to protect that. There are sensitivities, and those need to be protected, and we need to invest in those, and you need to be able to test that in production or prior to that if possible, right?

    But the other side of it, too, is around the regulatory requirements, right? Customers will—our customers, large companies—will get fined if certain requirements aren’t met, right? And so, from a pure business perspective, you’re motivated to make sure the customer is experiencing that requirement. But then from their own protective perspective, you’re also motivated.

    And so, DevSecOps, we really encourage people to fold security in very early in the discussions. It’s often one of the last things to come up—“Oh, wait, did we talk about security, did we bring in that team?” Fold them in early, complete transparency, get the conversations in and weave them into the process, because it’s critical.

    O’Hanlon: Excellent, excellent. Amy, this has been a great conversation. I’ve really, really enjoyed it, and would definitely love to have future conversations with you about other topics related to DevOps and the customer experience, because I really think that this is something that is—it’s not gonna be a one and done conversation. It’s like DevOps. Customer is an evolving conversation.

    But for now, thank you so much for taking the time and having the conversation with me. I do appreciate it.

    Hudson: Thanks for having me. It’s a privilege to be here.

    O’Hanlon: Alright, great. Alright, everybody, please stick around. We’ve got lots more Tech Strong TV coming up, so stay tuned.

    [End of Audio]

  • Credit Karma Looks to Open Source Distributed App Platform

    Credit Karma Looks to Open Source Distributed App Platform

    Credit Karma has launched an application platform, dubbed Talon Polly, that makes it simpler to deploy microservices across multiple runtime environments.

    Richard Pounder, principal software engineer at Credit Karma, said the consumer financial services provider expects to make Talon Polly available as an open source project next year.

    Written in the Rust programming language, Pounder said Credit Karma created Talon Polly to provide its developers with a language-agnostic platform for building and deploying applications. Talon Polly can be deployed as a sidecar using containers or as a process running within a software environment.

    While there is no shortage of frameworks for building and deploying software, Pounder said Talon Polly is designed to make it easier for development teams to reuse code and components across multiple applications using, for example, a contract-based library included in the framework. That approach also enables Credit Karma to ensure a common set of security policies are enforced across those application environments, he noted.

    Ultimately, the goal is to enable developers to spend more time writing business logic rather than mastering the nuances of multiple application development frameworks created for specific application environments, said Pounder.

    It’s not clear to what degree other frameworks may emerge to address the same issues at Talon Polly. Odds are good that other organizations that need to deploy distributed applications built using multiple programming languages have faced similar challenges. The Cloud Native Computing Foundation (CNCF) has also adopted Dapr, a set of application programming interfaces (APIs) created by Microsoft that are deployed as container sidecars to make it simpler to build distributed applications, as an incubating project.

    Regardless of approach, the rise of distributed microservices-based applications is creating a significant management challenge for DevOps teams. Each microservice is built by different development teams that prefer one programming language over another for any number of reasons. Deploying and updating those microservices across a distributed computing environment requires more sophisticated orchestration of workflows, given all the dependencies that exist between microservices.

    Of course, it’s not quite clear yet the degree to which microservices-based applications will supplant legacy monolithic applications. Most new applications are being constructed using microservices to make applications more resilient. However, the number of legacy monolithic applications running in existing IT environments means it could be years before microservices-based applications will ever outpace them. As such, DevOps teams will be managing a mix of monolithic and microservices well into the second half of this decade.

    The paradox is that while microservices-based applications are more resilient because calls to services can be rerouted in the event of a disruption, the overall application environment becomes more complex as the dependencies between distributed microservices increases. As such, many organizations are opting to use microservices to build applications only when a certain level of resiliency is required or it’s been determined that a function likely to be used by multiple applications is more easily accessed via a microservice that has its own API.

    One way or another, going forward, it’s not so much a question of whether microservices will be employed but rather to what degree and across how many applications.

  • Great Resignation Spurs Interest in Tech Certifications

    Great Resignation Spurs Interest in Tech Certifications

    It has been almost a year since the phenomenon known as the Great Resignation started appearing in national news. The reports showed millions of U.S. workers leaving their jobs each month to look for something better. This trend, according to the latest news, is not going away.

    While labor experts have provided a steady stream of speculation about why people are leaving their jobs, from frustration with pay to fear of COVID-19 to a desire to find positions that are more meaningful, they have yet to arrive at a consensus as to what those who are now out of work are doing with their time.

    In the world of IT and tech, it appears that those who joined the Great Resignation are spending their spare time growing their skills and improving their resumes by pursuing tech certifications.

    Tech Courses Surge in Popularity in 2021

    According to Class Central, a search engine and review site for free online courses, the top online courses for 2021 were tech courses, many of which are offered by Google and provide the type of certifications that look great on a resume. Here are some examples of the top courses:

    • Foundations of User Experience (UX) Design, which is the first in a series of seven courses on the topic.
    • Data Analysis With R Programming, which provides training on how to “clean, organize, analyze, visualize and report data in new and more powerful ways.”
    • AWS Cloud Technical Essentials, which presents the fundamentals of AWS.
    • AWS Cloud Practitioner Essentials, which explores “fundamental AWS Cloud concepts to help you gain confidence to contribute to your organization’s cloud initiatives.”

    Certifications That Pay Dividends

    In general, certifications provide a boost to job seekers. They communicate a commitment to professional development as well as provide a reliable catalog of the skills that one will bring to a position. For those looking to stand out, certifications can definitely increase the chances that you’ll get an interview.

    However, it is critical to think of the opportunity cost of an individual’s time. While we love free certifications, many of the free certifications are unlikely to help someone start their career. In many cases, after the person spends months achieving these free certifications, they will need to spend additional time getting new certifications to ensure that they have the specific certifications that employers desire. When you consider the salaries some of these tech positions command, spending months on the wrong free certifications can cost someone tens of thousands of dollars in lost earnings.

    While the following certifications may be more difficult to achieve and might not be available for free, they definitely make a difference in terms of preparing IT workers for the most desirable jobs:

    • Networking – Cisco Certified Internet Expert (CCIE) and Cisco Certified Networking Professional
    • Cloud Computing – Azure Expert, AWS Certified Solution Architect Professional and Google Professional Cloud Architect
    • Security – Certified Information System Security Professional, Certified Information Security Manager, Certified in Risk and Information Security Control, or CRISC (Note: these certifications required documented experience)
    • Cloud DevOps – AWS DevOps Engineer Professional

    Adding Soft Skills to Certifications

    The certification process can provide the technical skills for which many IT employers are looking. And promoting certifications on your resume can significantly increase the chances that you’ll be called in for an interview. However, in my experience, landing the job is one thing; thriving in it requires a different set of skills that fall outside the realm of IT certifications.

    Soft skills are not the skills that allow you to do your job, like coding or engineering. They are the skills that define how you do your job. They include people skills like networking, communication and conflict resolution, as well as creative thinking and time management. When applied to the world of IT, I like to think of them as “certifications plus.”

    While IT workers often overlook the value of soft skills, I can assure you that IT employers definitely do not. With the fierce competition that exists for IT work, IT providers need every advantage they can get to acquire and retain clients. If their workers do not have people skills to pair with their tech skills, companies lose that advantage.

    For those looking to boost their appeal to employers by acquiring certifications, take some time to get certified in soft skills. The courses exist and they will pay you great dividends both before and after you land the job.

    Bringing an End to the Great Resignation

    For IT companies, the growing popularity of certification courses may offer some insight on how to bring an end to the Great Resignation, at least within the IT sector.

    Recent research showed that IT “resigners” are wrestling with many of the same employment issues as those in other industries, including frustrations with salary and the desire to have more work flexibility. However, tech workers also cited some issues that indicate that certification training, provided before employees resign, might be enough to keep them at their desks.

    For example, the top reason cited by workers at tech, IT and software development companies for wanting to leave their job, other than salary and benefits, was limited career progression. In addition, nine out of 10 said they “would like to get more learning and development opportunities from their company.”

    For tech workers looking for a job, “skills development” was the second-highest criteria they considered behind salary and benefits when selecting a company. More than 60% also reported that “more learning and training opportunities would make them more motivated at work” and 75% felt that their companies focused more on attracting new employees than they did on investing in existing employees.

    Could it be that retaining IT employees and filling the positions left open by the Great Resignation is as simple as making certification training available to employees?

  • The DevOps Journey: Continuous Mindset Starts With Cultural Change

    The DevOps Journey: Continuous Mindset Starts With Cultural Change

    DevOps is not just about technology. In many ways, the technology aspect of DevOps is finite but the people, organizational and cultural aspects are infinite. We see many clients get so focused on the tools and technology that they forget about the impact beyond the technology. An important part of building a world-class DevOps process is understanding the cultural and organizational changes that are required to be successful and making those a priority, as well. 

     Many organizations have still either not started their DevOps journey or are in the first generation of DevOps, which is creating a greater gap between elite and low performers. The business changes and delivery cycles are coming faster than ever, making it critical to use world-class DevOps. Pushing toward continuous flow requires technical, process, people and cultural evolution to keep pace. To achieve continuous flow, we need a continuous mindset. A continuous mindset requires new skills, new ways of thinking, new cultural norms and new responsibilities.

    Continuous Mindset, Continuous Flow

    Most companies don’t realize the cultural impact a fully automated pipeline and continuous flow will have on development and operations (and beyond). Change can be difficult and organizations are often met with FUD: Fear (automation brings fear that jobs will be automated away), uncertainty (the unknown creates anxiety) and doubt (needing to employ new skills and new ways of thinking can create doubt about whether resources can adjust).

    The rapid pace of business change requires more nimble, flexible and lean approaches to DevOps to meet tomorrow’s demands. This requires changes to structures, interactions, control, processes and expectations. All of these impact the culture and connections within the organization.

     Let’s start by defining a few terms:

    Continuous integration: The practice of merging all developers’ working copies to a shared mainline several times a day. Grady Booch first proposed the term in 1991, although he did not advocate integrating several times a day. Extreme programming (XP) adopted the concept of CI and did advocate integrating more than once per day—perhaps as many as 10 or more times per day. Common continuous integration practices include maintaining a code repository, automating the build, making the build self-testing, testing in a clone of the production environment and more.

    Continuous Delivery: The official definition is, “A software engineering approach in which teams produce software in short cycles, ensuring that the software can be reliably released at any time and, when releasing the software, doing so manually. It aims at building, testing and releasing software with greater speed and frequency. The approach helps reduce the cost, time and risk of delivering changes by allowing for more incremental updates to applications in production. A straightforward and repeatable deployment process is important for continuous delivery.”

    Continuous Deployment: A strategy for software releases wherein any code commit that passes the automated testing phase is automatically released into the production environment, making changes that are visible to the software’s users. The logical next step after continuous delivery: Automatically deploy the product into production whenever it passes required validations.

    Continuous mindset is intertwined throughout all three of the above approaches. To reach the maximum value in each area, a continuous mindset needs to be enabled, matured and applied to disciplines in other DevOps areas. The changes are across people, processes, technology and culture. Like DevOps, gaining a continuous mindset is a journey that will take time, many steps and constant learning.

    Continuous mindset changes the way people achieve outcomes for your business. This requires an emphasis on changing the way people think at every level of the organization, the way people are connected and the way they work. Achieving true continuous mindset ROI requires significant cultural adoption and collaboration. A key component is leveraging strong organizational change management (OCM). Six OCM steps to achieving the cultural shift to a continuous mindset include:

    • Change management and readiness: Share with internal stakeholders where we are going and how we are going to get there. Set expectations.
    • Sponsorship: Create clear alignment and engagement at the executive level.
    • Stakeholder engagement: Get everyone on board. Identify who is impacted as well as who is responsible and accountable. Understand reactions and resistance and provide support.
    • Communication: Get the right information to the right people at the right time. Move stakeholders from awareness to buy-in, commitment and readiness. Communicate messages to multiple levels of the organization.
    • Capability development: Provide the education and training needed to be successful in the new culture.
    • Organizational alignment: Align roles, structure, processes, policies and systems with changes and desired business outcomes.

    Shifting Responsibilities

    Ultimately, a continuous mindset changes the organizational engagement model and requires organizations to align on how and when they will work together. This requires shifting responsibilities and empowering teams/individuals to contribute to the improvement of DevOps capabilities. Learning and knowledge transition is an important element to enabling the team long-term.

    The organization will need coaching as they begin to understand the concepts and adjust the way they work. Different approaches can be used depending on the overall needs. This purposeful DevOps learning approach will provide DevOps coaches to engage with teams along with DevOps subject matter experts to provide input in the preparation activities. Another option is to provide less formal DevOps coaching to engage with targeted teams. This approach is less structured and primarily relies on direct engagement with less focus on the training and scaling project approach.

    Transparency is Fundamental to a Continuous Mindset

    Part of creating a continuous mindset involves an environment where transparency is fundamental; where everyone feels committed to the results takes ownership and responsibility for improving them. Successful DevOps transformation requires a holistic approach that includes people, processes, technology and culture. Working in cross-functional agile teams; working with small batches; working in sprints; communicating and collaborating all provide the strong foundation necessary to create a solid continuous mindset. If done correctly, breaking cultural changes down into smaller changes can ensure a certain level of quality in the long term. 

  • Irreconcilable Differences: DevOps Grapples With Issues

    Irreconcilable Differences: DevOps Grapples With Issues

    DevOps issues can be a thorny subject. The coming together in harmony of Dev (developer) and Ops (operations) represents an arranged marriage of sorts that, for some, will never have a ‘happily ever after’ ending as both parties ultimately grapple with irreconcilable differences.

    But despite the naysayers, the very existence of DevOps as a portmanteau (and perhaps sister labels like DevSecOps, to form a security sandwich) is, in many ways, a validation of the need to form a bond of tighter unity and harmony between two factions that have often been at odds with each other over the years.

    Even with the popularization, extrapolation and democratization that DevOps has enjoyed through the last decade, not everyone will be convinced of its worth and/or its effectiveness—some even doubt its very existence. Some say that DevOps already existed without a formalized label if you look at the software development practices IBM championed a quarter-century ago.

    One thing we can be certain of is that DevOps almost always throws up a few meaty bones of contention. Let’s take a closer look at these issues in the hope that we can harness some of the angst and turn it into positive energy for a DevOps-enriched future. If we are to analyze the most contentious and sensitive DevOps issues in this space, what should we be aware of and how do the big issues break down?

    Is it a Bird? Is it a Plane?

    Arguably, the biggest problem DevOps faces is categorizing it. Some call it a methodology for software application development. Proponents of ‘classic’ software methodologies disagree with this idea as, for the purists, a software methodology can only be Agile, waterfall, extreme, rapid, joint or Scrum.

    These semantics mean that many people would prefer DevOps to be classified as a culture, a workplace ethic, a technique, a culture and/or a mindset or, perhaps in the vaguest terms, an approach. To be truly successful with DevOps you must take a holistic approach and look at the entire development cycle from beginning to end. Closely evaluate the processes that go into development to find bottlenecks and roadblocks to productivity. By finding the areas where your current processes come up short, you will be able to identify the areas to emphasize when implementing a strong DevOps strategy.

    Cloud-Native DevOps

    Anyone who hasn’t been living in a cave since the turn of the millennium will know that cloud computing has grown, faltered occasionally and, ultimately, blossomed to become a new standard barometer for all organizations on their journey toward so-called digital transformation.

    That’s the good news. The not-quite-so-good news is that cloud (and the contemporary drive to go cloud-native) is still complex from initial deployment to ongoing maintenance, management and reporting.

    Taking DevOps into the world of cloud-native will ultimately pay off, but first, there will be challenges as teams get used to the new shape, form and function of the altogether more abstracted and virtualized software toolsets.

    The key to getting cloud-native DevOps right will be a prudent approach to monitoring and observability. As cloud-centric DevOps teams ingest the logs, metrics and traces they need to perform solid and dependable system observability, they will need a consistent set of tools to monitor and observe systems in the long term. Within this practice, it will also be important to remember that monitoring shows you lower-level granular information related to system performance. Observability includes all the information gleaned from monitoring and also includes higher-level tools, some of which will be data visualizations for DevOps practitioners to use. When the two are combined for cloud-native DevOps, system health can be optimized, preserved and maintained while any debugging or root cause analysis is executed at the lower level.

    Machines in the Application Loop

    With machine-to-machine events now happening more prevalently inside the internet of things (IoT), the need to capture, integrate and analyze the event streams that go on outside of the human loop and bring those log metrics back closer to the sphere of ‘human’ software engineering is not a plug-and-play quick fix.

    Getting machines to play nicely and be a part of expansive and progressive DevOps teams should be a given. After all, they’re just machines. In reality, there will be specific skills needed and human DevOps personnel will be required to get used to updates and other alerts that they have not considered before.

    AIOps and Automation Limits

    Related to our last point on machine events, we need to think about AIOps. When we build AI-driven DevOps and create AIOps, we will need to stop and question where we set limits on process automation and where the wider elements of automation hit the limiter/restrictors. To know just how far we should build out our AIOps practice, exhaustive auditing and analysis must to be carried out; the whole technology proposition here is no simple point-and-click affair. Even when we do establish workable AIOps, know that there will be perimeters.

    Add all that to the fact that some AIOps implementations will require what we like to call ‘human handoff’ support when the AI intelligence engine doesn’t know what to do next and needs additional data and training—only then can we start to appreciate that AIOps itself is no simple plug-and-play affair.

    Lift and Shift Doesn’t Scale

    One of the unfortunate truths in too many real-world IT shops today is that, where the cloud is used, it is used poorly. Too many technologies are unceremoniously lifted and shifted to cloud instances that an organization procured. This makes cloud-centric DevOps harder to achieve. But why?

    Because what happens back down in terrestrial (i.e., non-cloud) programming is the development of individual cross-functional software teams. This silo-based approach happens due to corporate legacy structures, company management systems and, sometimes, for personal, parochial or cultural reasons. When different teams are all reinventing wheels (running diagnostics tests, setting up CI/CD pipelines, delivering upgrades and so on) that should be shared and accessible to all, a natural level of inefficiency surfaces.

    DevOps Issues: Conclusion

    These are the five most contentious DevOps issues in the near term, and it would, of course, not be too hard to find and categorize even more. In the future, we might even need to argue over which developers should be categorized as core devs and which core members of the operations department to include.

    For software developers, software architects—really, all the software engineering professionals who work in systems administration, database admin, testing, security and all other forms of operations—there’s quite a lot at stake and quite a lot to fight over. And if you ask me, that’s what makes DevOps great.