Category: Features

  • DevOps Chats: Mobile, Monoliths & Microservices, With LightStep

    DevOps Chats: Mobile, Monoliths & Microservices, With LightStep

    Daniel “Spoons” Spoonhower made a bit of a name for himself while he was at Google, as did his two co-founders of their latest company, LightStep. All three were there at the birth of the microservices wave that has swept through the software world.

    They left Google and started LightStep to help all developers build better, more scalable applications.

    With its new release, LightStep has pushed the bar higher. In this DevOps Chats podcast, Spoons tells us what they are doing and where he sees things moving.

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

    Transcript

    Alan Shimel: Hey, everyone, it’s Alan Shimel for DevOps.com and Container Journal. You’re listening to another DevOps Chats. I’ve got a great guest to talk with today, I hope you’re going to enjoy it. I’d like to introduce you to Daniel Spoonhower, better known as Spoons. Spoons, welcome to DevOps Chats.

    Daniel Spoonhower: Hi, great to be here.

    Shimel: So, Spoons, you are CTO and Co-founder of LightStep, and though some in our audience are probably familiar with LightStep, being that this is the first time we’ve had someone from LightStep on our podcast, I’m gonna ask you to kinda do some of the heavy lifting here and kinda—

    Spoonhower: Sure.

    Shimel: – tell our audience a little bit about LightStep and what you guys do.

    Spoonhower: Sure—sure, sure. So, LightStep provides simple observability for deep systems. We think observability is more than just metrics, logs, and traces, it’s really about being able to navigate from effect to cause. So, whether you’re pushing into deployment, you’re on call and you got paged or you’re just trying to improve performance, observability tools like LightStep should be able to give you the insights that you need to understand what’s happening in your services and across your system.

    Shimel: Excellent. And just by way of, again, giving the audience the background—Spoons, why don’t you tell them a little bit about your own personal journey? You are a Co-founder and CTO, but there was life before LightStep.

    Spoonhower: True, yeah. So, yeah, I’m Co-founder and CTO and LightStep, but we have three—all three of the Co-founders are technical, and so, we all have done technical things and we all have done a lot of non-technical things, too, which has been pretty fun for me just to learn about finance and about commercial real estate—who knows what.

    Shimel: Yeah.

    Spoonhower: But yeah, I’m an engineer by training. Before this, I was at Google for a while. I worked both on their internal infrastructure team, which was super interesting, as well as on the cloud platform. And I have various other experiences at big and small companies. I was at grad school for a while doing academic stuff, so—yeah, a lot of different things.

    Shimel: Excellent. Alright. So, before we—I know you guys have some new product announcements coming up, but you know, LightStep is, as I mentioned, new to our audience here on the podcast, but it’s been around five years, right? And I think you gave everyone kind of the—you know, the brief elevator pitch about it. But it really, you know, in an age where even just since I’m doing DevOps.com, right, Spoon, we’ve seen APM turn into AIOps and companies go public in this space and everything, several. But yet, you know, the need to kinda monitor, manage, see what’s happening is still here and I don’t wanna say it’s getting easier or—you know?

    Spoonhower:  [Laughter]

    Shimel: Because I think it’s just, you know, natural. Things get more complex as we continue to build and so forth, and I guess that makes the monitoring easier, but when does it get simpler?

    Spoonhower: Well, yeah, so I think the situation has gotten a lot more complex. That might be because of things like microservices or serverless or things like that. I actually think a lot of complexity comes from the fact that we no longer run our whole applications. Like, we use DynamoDB, we use third party fraud detection service, right? There’s a lot of pieces of our software that are not even ours any more, so that adds a lot to the complexity.

    Shimel: Yeah.

    Spoonhower: I think the simplicity has to come from focusing more on the use cases. Like, what are you as a developer actually trying to get done? And then, I mean—I think this is where people kind of get into things like AIOps is, like, using software to sort of harness the data that we have to help you in that task. I think that can be a real-really nice as a developer, right, to not have to understand all of the depths of what’s going on underneath the hood.

    Shimel: Sure. I mean, I just find it somewhat ironic that, you know, we’re gonna break down silos, we’re gonna break up this monolith and go to microservices so that we can deal with smaller, more easily digestible threads, and then we’re gonna orchestrate all of this with a great tool like Kubernetes. And then I look at it, and I’m not the developer you are—I’m not claiming to be, or the technical person—but damn, it gets…it’s just the nature of the universe, at some level.

    But anyway, you guys are well aware of this. It’s acute. This is the world you play in. You’ve got some new product announcements. Let’s talk about ‘em.

    Spoonhower: Yeah. That’s right, yeah. So, I mean, the history of LightStep a little bit is that we started as a tracing tool, collecting data sort of—exactly to address the situation you’re talking about. You’ve broken your application into some pieces and you want to be able to understand the big picture, right, and put them back together.

    And what we’ve done actually is to continue to integrate additional data sources into that, so that we can provide sort of more user-centric things. So, what we’re rolling out right now is a couple different pieces. One is error analysis, so being able to understand, you know, you have a spike in errors in your service, harnessing that data, whether it’s traces or logs or metrics, to understand what the cause of those errors are. We have a detailed rollout analysis, so even if you’re in the middle of a rollout, so you’re saying you’re gonna canary or blue-green or something like that and you wanna understand what’s happening, we’ll do that analysis for you and do a side by side to tell you what’s different about the new release.

    And one thing that’s pretty exciting is that part of this is integrating metrics into the platform. Metrics are a tool that everyone has been using forever and ever and ever, but you know, there’s a lot of metrics out there, and part of what we think is important is that we’re able to focus on the right metrics, the metrics that are actually able to explain what’s happening right now.

    Shimel: Absolutely. So, this new release, April 2nd, is the key day?

    Spoonhower: Yeah.

    Shimel: So, people listening to this can go check it out right now at LightStep.com.

    Spoonhower: That’s right. We’ve got a free developer tier that you can try. We also have a really cool sandbox that’s sort of, it’s a sort of interactive playground where you can check out features and you can basically walk through one of these scenarios. So, say you’re doing a release, say you’re trying to debug an error or something like that. It’s not—you know, it’s not totally constrained, but will kind of show you along and give you a bit of a guide that you can still explore the rest of the product while you’re there, but really trying to help people kind of put two and two together and understand what’s happening.

    Shimel: Yeah, no, I love that, man. Because I gotta tell ya, we’ve been experimenting with something like that for a project we’re doing on DevOps.com where, you know, we want to have web people do a little bit more hands-on playing with different vendors’ tools and so, we’re trying to give them a sandbox, right, where they can go in and do these things.

    Because, you know, we were talking off mic, right? Originally, this was gonna be an announcement around KubeCon which, unfortunately, you know, got pushed. And, you know, not getting into the whole politics and the whole thing around Coronavirus and all this stuff, but certainly, we need—we need more ways, we need more diverse ways of allowing people to see what kind of new products, what new technologies, how can they get it under their nails a little bit and really—

    Spoonhower: Yeah.

    Shimel: – kind of see if it’s for them?

    Spoonhower: Yeah, absolutely. I mean, I think people learn in lots of different ways, right? Some people wanna read, some people wanna watch a video. I personally really like doing this stuff. Like, until I’ve made it, coded it, whatever, I never remember it, so.

    Shimel: Absolutely. And you’re not alone. I do think specifically for technology vendors, having those kinda hands on that people can actually go in and we see it even on our webinars, man. If we do a webinar where the vendor’s doing a real live demo that people can follow along, we get insane numbers of people signing onto that, versus someone just talking, you know, and that doesn’t work.

    So, let’s talk a little bit about what was driving this, for you guys.

    Spoonhower: Yeah. I think, you know, we—so, I should say, when I say “we,” it’s me and one of the other Co-founders. Ben and I spent a while at Google, and Google—it’s a weird place, in a lot of ways, but there are some advantages. Like, there were ways in which being at Google is a little bit like seeing the future, and they weren’t called microservices at the time, but there were a lot of teams that built software that all had to stack together.

    And we saw, you know, sort of firsthand the problems that they had in terms of like, okay, I’ve broken this thing into pieces and now how do I understand that bigger picture? We saw a lot of arguments among those teams, like, you know—“Oh, no, it’s your fault,” “No, no, it’s your fault”—and needing some data to actually kinda resolve that.

    And so, I think, for us, you know, we saw the rest of the industry starting to adopt these things through different technology, maybe, but the same idea that you can have teams work independently and deploy independently yet still build a single application. And so, the motivation was really to try to help those folks to understand what’s happening and, you know, we see LightStep being used by individuals, but actually more and more by teams. We see it used in operational review so, you know, you’re doing a post mortem, you wanna show people what happened. LightStep is a great tool to help facilitate that conversation.

    And for us, this is really about being able to help those folks deliver software more confidently and then, you know, get back to building new features and doing all the fun stuff that they’re doing.

    Shimel: Yeah, yeah. I mean, wouldn’t it be great if we just, all we did was the fun stuff all the time? [Laughter] Some of us are lucky enough to do that, me included. But this thing, these are important things that need to get done and, you know, and LightStep is following that up.

    I wanted to return to the KubeCon thing if we can, for a second, Spoons. Not KubeCon itself, but rather the Kube community, right? And you know, look, Kubernetes itself comes out of Google, right? I’m not gonna say the Google people invented microservices, but certainly a lot of very foundational work was done there, right?

    When you are out and about or you see how this community has grown and the enthusiasm for things like LightStep, right—I mean, how does that, you know, kinda give you a warm fuzzy inside to say, hey, man, this is a whole—there’s this humongous community of people who kinda share our visions or our outlooks, and it’s a lot easier to sell to, and I don’t mean that you’re a salesperson, but it’s a lot easier to sell those solutions, right, than it is—you know, it’s not like pushing rope uphill.

    Spoonhower: Yeah, yeah. I mean, I think [Laughter]—yeah, I mean, Kubernetes is a result of a lot of mistakes that were made the first time around. [Laughter]

    Shimel: Yeah. [Cross talk]

    Spoonhower: So, I think a lot of people would admit that. No, but I think the community is really great. I think the thing that’s pretty exciting to me about it is really thinking about things like infrastructure as code, about, thinking about automation, about—and, you know, these things which we kind of think of historically as, you know, maybe more of a craft actually can be an engineering discipline, and I think that’s a lot of that community. It’s actually really great whenever I’ve been to KubeCon to see the range of folks there from, you know, sort of platform folks all the way up to people that are just building features and shipping code, that they’re also excited about those tools. That’s really, for me, makes a big difference, just to see that it’s not a niche thing so much, right, that it’s really a broad community that’s excited about it.

    Shimel: Oh, yeah, no, it’s broad. Me personally, I have 20 years in the security InfoSec space. I get excited when I see all the security people there about it, because I really feel like maybe this time we’ll do better, right? [Laughter]

    Spoonhower: [Laughter]

    Shimel: And we got out in front of this and where, you know, security is really kinda—it’s not the caboose on the engine, per se, it’s like, people care, and not just the security people care, the community cares.

    Spoonhower: Yeah, yeah.

    Shimel: And that’s important. So, you know, in today’s world, right, this isn’t this year’s release, this is just the April 2nd sort of new feature. So, what—and one builds on the next, right? So, what’s next here?

    Spoonhower: Yeah, so, I think we’re continuing to think about how we can do automated analysis. So, we have a future in the product already called correlations which, essentially, you know, you pick out some effect you think is important, you know? Errors went up, speed went down, whatever it is, and LightStep will find the things that correlate with that within sort of the set of requests that you’re looking at. So, we have a bunch more features related to that coming out later this year.

    So, this is kind of how I—I don’t know. When people say AIOps, I always gotta roll my eyes a little bit, but this is kinda how we think about, you know, bringing artificial intelligence to DevOps, right, is that it’s really through sort of putting the right clues in front of you, right? It’s not about providing 10,000 clues to solve a mystery, it’s about 5, right?

    Shimel: Right.

    Spoonhower: So, a bunch of stuff around that, and then—I mean, the other place that we’re thinking about is how do we get more proactive, right? How do we get in front of you and help you anticipate when these things are gonna be happening as well?

    Shimel: Absolutely. So, I suppose one day you’re gonna grow old and you’ll be on this side when—so, I’m no longer building products or founding companies that are building products, and I hear public lands come up with all these…and I don’t wanna say it’s just some marketing term, but—

    Spoonhower:[Laughter] You can definitely say that, that’s fine.

    Shimel: You know, I will tell you, the first time I heard AIOps, too, I said, “What?” You know? But, you know, I’ve been in technology long enough where—look, just don’t call me late for dinner, right? I don’t really care any more what you call it. And also on the media side of it versus on your side of it, I just report the news, you know, theoretically, right? We don’t—if you wanna call it, you know, if it quacks like a duck and it walks like a duck, it’s a duck.

    But in any event, I do hear you about that. And, you know, you wanna talk about an overhyped term? AI?

    Spoonhower: Yeah. I think in the world of—in DevOps, I think it’s actually, there’s some—

    Shimel: It’s overhyped, itself.

    Spoonhower: Yeah, there’s some [Cross talk] though, I think, because you know, if you’re talking about, like, I don’t know, ad placement or something like that, no one really cares about why, right? Like, you put the ad and someone clicks—nice job, right? Like, good job, robots.

    But like, you get paged and something’s like, “It’s that service over there, you should definitely roll it back.” And you’re like, “Yeah, but why?” Like, I’m not just gonna start rolling back things because robots tell me to.

    Shimel: Yeah, “I said so, that’s why.”

    Spoonhower: Right. [Laughter]

    Shimel: [Laughter] But I hear you, man, it’s out there. Well, listen, I told you, the time goes really quick here, and I think we’re about out, man. But Spoons, it was great having you on here. Good luck with this new release. I would say I look forward to seeing you at the next KubeCon. Let’s hope there is a next—

    Spoonhower: That’s right. I’ll see you somewhere, and if not, online.

    Shimel: Yeah. Otherwise, we’ll have you back here on the podcast, man.

    Spoonhower: Cool.

    Shimel: Alright? Hey, that was Daniel Spoonhower, Spoons, CTO and Co-founder at LightStep. He was just our guest on DevOps Chats. This is Alan Shimel for Container Journal, DevOps.com, Security Boulevard. You’ve just listened to another DevOps Chats. Have a great day.

    — Alan Shimel

  • The Linux Foundation to Award 500 Training Scholarships

    The Linux Foundation to Award 500 Training Scholarships

    The Linux Foundation this week announced it will make up to 500 training scholarships available this year.

    Clyde Seepersad, general manager for training at the Linux Foundation, said the number of Linux Foundation Training (LiFT) Scholarships being made available is being increased because of both the demand for individuals with particular expertise such as Kubernetes and the fact that more people are spending more time at home. As such, many IT professionals have more time available to advance their skills, said Seepersad.

    Unfortunately, there are going to be many more unemployed IT professionals as the COVID-19 pandemic wreaks havoc across the global economy. Many of those individuals will need to attain additional certifications to compete in an IT job market that suddenly has much less demand and a pool of job candidates that has increased seemingly overnight.

    The scholarships being made available by The Linux Foundation are designed to encourage individuals with varying types of backgrounds to develop open source software expertise. They include:

    Open Source Newbies
    Teens-in-Training
    Women in Open Source
    Software Developer Do-Gooder
    SysAdmin Super Star
    Blockchain Blockbuster
    Cloud Captain
    Linux Kernel Guru
    Networking Notable
    Web Development Wiz

    Since 2011, more than 100 training and certification scholarships valued at more than $220,000 have been awarded by The Linux Foundation. The deadline for applying for the latest round of scholarships is April 30.

    The Linux Foundation is also making available its entire catalog of paid eLearning and certification exams available at 30% off through April 7.

    Seepersad said all the courses made available by The Linux Foundation are accessible online. Each exam administered is also recorded. Interestingly enough, Seepersad said the number of potential cheating incidents is far less online than in classrooms mainly because each individual taking an exam is recorded. There’s also more opportunity to potentially share answers in a traditional classroom setting, he noted.

    It’s unclear precisely how the COVID-19 pandemic might impact demand for IT skills going forward. While it’s clear there will be fewer IT professionals employed, there may be an actual increase in demand for individuals with open source expertise. During the last economic downturn many organizations adopted an “open source-first” philosophy to acquiring software as part of an effort to reduce IT costs. Many of those organizations determined they would rather allocate their much-reduced IT budgets to retaining IT staff than paying for commercial software, even if that meant the time and effort required to implement and manage that software was higher.

    At the same time, it’s worth noting many organizations may need to accelerate the rate at which they are modernizing their IT environments. Now that most employees and end customers are spending most of their time at home, many organizations are finding their existing portfolio of applications do not lend themselves easily to being remotely accessed. Some might even take advantage of open source container technologies to lift and shift entire existing legacy applications into the cloud because their IT staff may not be able to physically access a local data center for more than a month.

    Whatever the ultimate outcome, the one thing that is for certain is working in enterprise IT environments will never be the same again.

    — Mike Vizard

  • DevOps Institute Upskilling the Enterprise

    DevOps Institute Upskilling the Enterprise

    DevOps Institute released its annual Upskilling the Enterprise survey and the results are as interesting as last year. The organization of DevOps teams and its interaction with speed/success was one area that intrigued me, and sent me off looking for more information on the topic. This led me to this interesting site that does a great job of delving deeper than “We’ve all heard of Conway’s law.”  Good descriptions there on what works and why that will be useful to many organizations. The only true weakness in the content that I found was the “vacuum syndrome” that doesn’t delve deeply enough into what’s right for your organization, which certainly impacts your choices.

    DevOps Institute’s discussion of soft skills and DevOps roles being hybrid is also interesting. It creates a bit of a conundrum. We all wish the technical genius was also a charming personality, but often that is not the case. In the end, our job is technical, and we need to deliver technical solutions. There is a balance between making the genius more personable and finding personable people capable of achieving the goals. Considering that hiring is currently a struggle, we often do not get to choose. Training can help a lot, and in the end, finding a balance that works for a given organization is going to be a bit of work for management.

    What comes as no surprise is the finding that CI/CD are the entry level required skills for DevOps. No matter how far along on your DevOps journey you are, CI and CD are core to the job at this point. Expect that to change over time as deployment and security become more core and commonplace. In the end, great CI/CD is not much help if deployment and monitoring are weak, so the tools that win these battles will rise in importance over time without taking away from CI/CD.

    Their idea of the E-shaped human is interesting, but in diagramming, some detail is lost in the abstraction.

    I once worked with a super-genius DBA that could do anything with the database. We (managers) met with him on issues and let him tell us how impossible it was and that we were destroying the enterprise’s data integrity. Then gave him a day and let him tell us how it would get done effectively without major disruptions. Only after we’d met with him the second time did we move forward with the project, talking to business owners. Essentially, we became the wall between him and anyone who would be put-off by his face going red and his angered declarations. It was an acceptable arrangement, and he never let us down. I worked with him on dozens of projects, and only once did I see him exposed to outside consultants (against the wishes of several of us), it was ugly, and they pegged him as a stone-waller. He wasn’t, just needed to vent first.

    This person was responsible for the stability of our data, for upping the volume of throughput when needed and for making sure SQL didn’t get past DBAs without being safe. Would we have liked him but with a sunny disposition? Sure, but given a choice, I for one was happy with him and an angry disposition. I worked other places I wished I had someone with his unparalleled skills on the DBA side. So, all of IT needs to get better at interpersonal communications in a DevOps world, but “better” is relative. I’d still keep him in the back, making sure our systems got what they needed.

    The survey head-nods to this reality where soft-skills came in third as important skills. Still high on the list because it is important, but it shows that technical skills are why we have the job. Soft skills are how we do the job with less friction.

    Considering that I am the communicator/negotiator, it might sound strange for me to stand for tech skills first, but that is who we are–technicians. Highly skilled and highly compensated, but technicians. There are few (as a percentage) people who can handle both technical and communications, but by the same token, there are few people who can be an absolute boss at their technical responsibilities and see each unexpected event as a challenge to be overcome. I love to learn new things, and at that job I learned a ton of Oracle stuff from our tech genius. But I would be foolish to believe I’d ever match him in both domain and tech knowledge when it came to databases and our employers’ needs.

    Anyway, I picked three of the points that interested me to expound upon. The entirety of the report is definitely worth a read to get a feel for where others are on their DevOps journey and offer some ideas for yours.

    Meanwhile, keep kicking it. We’re in the midst of COVID-19, and I hear you, some of you are simply buried in organizations that weren’t prepared, others are suddenly looking for work because your previous employer is suddenly not a viable business. Here’s hoping it gets better for each of you, while the rest of us struggle on.

    — Don Macvittie

  • DevOps Chats: CloudBees Remains at Top of DevOps Market

    DevOps Chats: CloudBees Remains at Top of DevOps Market

    In this special DevOps Chats video edition, we speak with Sacha Labourey, CEO of CloudBees. From the very beginning of the DevOps movement, CloudBees has been one of the companies at the top of the DevOps market and, based on its latest business metrics, the company remains there.

    Being the enterprise Jenkins company helped CloudBees early on to be a leader at the top of the DevOps market. But with Jenkins and Jenkins X handed over to the Continuous Delivery Foundation (CDF), CloudBees can no longer count on its Jenkins connection to stay on top.

    Sacha, like any good CEO, did not allow CloudBees to rest on its laurels. An aggressive acquisition strategy including acquiring Electric Cloud, Rollout.io and others, has kept CloudBees on top. At the same time, Sacha has led the product and engineering teams as they roll out a new generation of DevOps products and services including the upcoming Software Delivery Management (SDM) and Software Delivery Automation (SDA).

    In this video, Labourey lays out what the past year has seen for CloudBees and what the coming year could bring. Of course, with Covid19 everyone is sailing into unchartered waters. But Sacha has the course in mind for CloudBees to follow.

    Have a listen to our conversation with Sacha to understand CloudBees’ plan to stay at the top of the DevOps market.

    [video src="https://videos.files.wordpress.com/TNgFIQ9x/2020-03-19-interview-with-sacha-labourey-1_hd.mp4" /]

    — Alan Shimel

  • We All Have to Have Standards

    We All Have to Have Standards

    I was working on an e-book recently about the state of the market for certain DevOps toolsets, and got really interested in how standardized organizations are becoming. We have been on this roller coaster of changing technology and different teams making different choices in language, libraries, platforms and toolchains. We all knew that couldn’t go on forever, but I started to really get into the idea of “How much standardization is being introduced?” While talking with vendors about their experience, it seems that enterprises are finally attempting to standardize, at least in the platform and toolchain areas.

    Not the type of “technology by edict” standardization we used to see, but a checklist of “If your project fits these criteria, use this platform. If it fits those criteria, use this toolset for your build chain.” Which is a good compromise between the days of “We’re a Cisco shop” or “We’re an Oracle shop,” and the days of “Yeah, first developer on a project chooses the language, database, etc.” You limit the amount of technical debt and vendor/OSS project dependency, while offering teams options for how best to get the job done.

    I’m excited about the change, and it is one of the things driving much-needed consolidation in core DevOps markets. I won’t go beyond that, as you’re supposed to read the e-book when it gets released, but it’s an exciting time to be in DevOps. We’re getting more and more tools, better integrations and even some full lifecycle toolsets starting to become clear.

    Our shop is small, and we’ve exercised standards all along, just because we don’t have the time for everyone to train on five different CI products, so we use one. But for larger organizations with more diverse needs, standardization will offer savings in both maintenance and cross-training.

    Consider that at one point there was no standardization on vehicles–everything from tires to engine oil was custom to the brand you owned. Now, it is quite often the case that the engine in your vehicle is the same engine as in a competitors’ vehicle (VW using Saab engines for years is a good example), and that means maintenance is streamlined. Tooling with onboard computers makes maintenance even faster, much like tooling monitoring/reporting is doing for the DevOps iteration. It’s a good time to be in the field, watching as things unfold.

    Stay aware of what your vendors are doing, and what their competitors are doing. One of the reasons DevOps exploded is because tools and processes became static and weren’t as productive as they could have been. Don’t repeat that mistake, keep an eye on rapidly changing developments and adopt what suits your organization. You’re rocking it now, take a bit of time to make sure it stays that way.

    And consider standardizing some of your toolset. The fewer tools to maintain, the more time to work on productive issues. And the fewer toolchains a DevOps team member has to know to be productive on multiple projects, the more productive they can be. Agility applies here also.

    — Don Macvittie

  • Coronavirus Economic Shutdown: Analysts Hit the Brakes on Global IT Spending Estimates

    Coronavirus Economic Shutdown: Analysts Hit the Brakes on Global IT Spending Estimates

    By most accounts, 2020 was set to be a pretty good year for U.S. gross domestic product and enterprise IT budgets. That was before the novel coronavirus, and the subsequent economic shutdown that is designed to blunt its spread and avoid overwhelming the nation’s health system. Analysts are now slashing their economic growth rates and enterprise technology spending estimates.

    Previously, research firm IDC estimated that real GDP in the U.S. would reach 2.4%, but downshifted that to a “pessimistic scenario” of 1.4%. While IT spending dropped from an expected 5.1% year over year growth to a pessimistic scenario of 1.3%. The base scenario for GDP growth is now 2.0% and for IT spending 4.3%.

    “The pessimistic scenario is not a worst-case scenario,” said Stephen Minton, vice president in IDC’s Customer Insights & Analysis group. “Things are moving so quickly that we need to constantly recalibrate our assumptions and expectations, but the pessimistic scenario reflects an IT market in which weaker economic growth translates into weaker business and consumer spending across all technologies over the next few quarters. Things could get worse, but hopefully not.”

    Earlier this month, Forrester analyst Andrew Bartels wrote in this post that the U.S. and global technology market spend will slow to 2% this year.

    “That assumes the U.S. and other major economies have declined in the first half of 2020 but manage to recover in the second half. There is also a 50% probability that U.S. and global tech markets will decline by 2% or more in 2020 if a full-fledged recession hits,” Bartels wrote.

    Not all areas in technology will be impacted equally. Forrester expects there will increased demand for cloud infrastructure services, specialized software, communications equipment and telecom services for remote work and education.

    However, Forrester expects computer and communications equipment to potentially decline 5% to 10%, while technology consulting and systems integration services spending could be flat to down 5%, should companies really belt-tighten.

    “Software spending growth will slow to the 2% to 4% range in the best case and will post no growth in the worst case of a recession. Tech outsourcing and telecom services will hold up better, though contract revisions could cause spending to go down, as well,” stated Bartels.

    S&P Global Ratings also predicts slowing IT spend. According to its update, Global IT Spending Set To Slide As Coronavirus Hits Hardware Sales, S&P Global economists cut their global GDP growth rate by more than half to 1% to 1.5% from 2.8%—in just two weeks.

    “We believe the spread of the coronavirus will hurt enterprise and consumer IT spending across the globe with particularly bleak ramifications for the hardware and semiconductor segments. However, we expect some of the deferred spending to return gradually in the latter half of this year through heavy government stimulus in the U.S., China, and elsewhere,” wrote S&P Global Rating Analyst Andrew Chang.

    S&P Global Ratings anticipates IT spending to decline 3% year over year, compared their prior estimate of 2% to 3% growth. S&P Global Ratings expects some of the biggest hits to hardware, with smartphone revenue falling to negative 9% from up to 2% growth, and PCs to negative 9% from a previous range of negative 3% to a positive 4% growth.

    While enterprise technology budgets are being slashed, the need for business-technology isn’t going away. In fact, it’s accelerating as more knowledge workers shift to working from home, more remote collaboration and keeping legacy systems running and moving forward with digital transformation efforts.

    — George V. Hulme

  • Startup Aims to Manufacture Ventilators Using 3D Printers

    Startup Aims to Manufacture Ventilators Using 3D Printers

    A startup company is in the early stages of building a proof-of-concept that would allow local hospitals to employ 3D printers to manufacture ventilators and other medical equipment to help combat the COVID-19 pandemic.

    Veritx president James Regenor said company executives have already been involved in use cases in which the military has used 3D printers to create replacement parts on aircraft carriers at sea. That same concept could be applied to medical equipment using any number of 3D printing services that now operate in most municipalities. In fact, some hospitals attached to universities already probably have access to 3D printers.

    Veritx is in the process of looking for funding to help create a proof-of-concept (PoC) around an electronic file that would contain the schematics for printing out the parts that make up a ventilator. Those parts could then be assembled near a medical facility to provide a steady source of ventilators as needed, said Regenor.

    Those printers could also be employed to create splitters that would enable multiple patients to share the same ventilator or, if need be, convert other devices for pumping oxygen, such as scuba equipment, into a makeshift ventilator, he said.

    Regenor estimates a local 3D printing service could manufacture more than 1,000 ventilators a day. Alternatively, medical facilities could use 3D desktop printers to fill an immediate need.

    The issue that 3D printing could solve is that ventilator manufacturing is currently dominated by a handful of companies. As demand for ventilators escalates, many of these companies are having issues scaling up their manufacturing. That shortage of ventilators has resulted in a wide range of companies, including Ford and General Motors, offering to use their manufacturing lines to build ventilators. However, it may be months before any ventilators that might be manufactured by those companies become available because of the need to retool manufacturing lines. Ventilators created using 3D printers could, in theory, be available within hours or days of being ordered, at a much lower cost.

    The ventilator shortage is already a chronic issue in areas such as Italy and New York, where the COVID-19 pandemic is now raging. It’s likely to become an even bigger problem as the virus spreads to more rural areas where hospitals don’t tend to keep many ventilators on hand. State governments naturally will do their best to acquire as many ventilators as possible; however, competition is now fierce, with individual states and governments around the world outbidding each other for ventilators. The chances that smaller states will have the financial resources necessary to compete for ventilators are slim.

    It’s too early to say to what degree the current pandemic may be one of those seminal events that winds up boosting an emerging technology such as 3D printing. The one thing that is certain is manufacturers of 3D printers have a role to play in the current crisis that could transform the medical equipment industry in a most unexpected way.

    — Mike Vizard

  • COVID-19 Reaction: Massive Spike in IT Incidents

    COVID-19 Reaction: Massive Spike in IT Incidents

    A report published this week by PagerDuty, a provider of an incident management platform, finds organizations that rely on the platform to manage IT issues are managing on average double the number of incidents since the start of the COVID-19 pandemic.

    In some industry segments, such as online learning services, travel and entertainment services, the number of incidents has increased 11-fold, the report noted.

    Rachel Obstler, vice president of product for PagerDuty, said with more people at home, online services that are seeing a spike in use while at the same time deploying new code to drive additional services are clearly stressed. Enterprise IT organizations, meanwhile, are now dealing with large numbers of employees trying to remotely access a wide range of applications simultaneously. Incidents now range from relatively simple authentication issues to accelerating the rollout of a digital business initiative to help maintain business continuity, she noted.

    Many of those organizations were already short of staff before the COVID-19 pandemic so longstanding challenges in many cases are now being further exacerbated, added Obstler. In addition, organizations that are rushing to deploy applications to enable their organizations to maintain business continuity are likely to not have tested those applications as thoroughly as they once might have. Inevitably, that decision will result in more IT incidents as issues are discovered after those applications are deployed in a production environment.

    Naturally, there may be a temptation to suspend rollouts of new applications. However, with millions of individuals now required to work from home for an indefinite amount of time, digital business applications may be the only way to engage those individuals. In fact, Obstler noted that as working remotely becomes the new normal, many people are about to become a lot more proficient at both working and shopping from home. As such, digital business applications may soon become the primary medium through which organizations engage their end customers.

    On the plus side, Obstler said it’s now relatively simple to deliver IT services from anywhere in the world, so there is an opportunity to bulk up existing IT support staff. Of course, the pool of IT professionals who are available to hire should also increase as vertical industries such as the travel and hospitality sectors essentially shut down.

    It’s too early to say precisely how the COVID-19 pandemic will impact the IT sector. While there will certainly be layoffs, many organizations will be loath to let go of IT staff who will be difficult to replace once the immediate economic recession ends. Countries around the world are also making funds available to companies on the condition they keep layoffs to a minimum.

    Regardless of how many IT people are retained, however, the remaining IT staff will continue to be stressed. Many organizations are going to have to re-engineer IT processes by, for example, embracing best DevOps practices on the fly to adjust to a new reality. Many of the IT issues about to be encountered might not always be within the control of IT teams to address. However, business leaders will expect that one way or another those IT staff will come up with the innovative workarounds needed to enable the business to continue to survive and thrive.

    — Mike Vizard

  • How to Properly Approach Automation

    How to Properly Approach Automation

    Imagine if you backed out of your driveway, tapped the gas and BAM! You are at work. Nothing to worry about along the way, no traffic congestion, no other cars to worry about, etc.

    That is, unfortunately, how many of us approach automation. “Fire and forget” is real, until a problem crops up. I could talk about some complex environments, such as ARA, in a containerized environment with multiple languages, accessing mobility-limited databases and targeting several client platforms, for example.

    But we’ll keep it simple, and I’ll make an admission. Backup was one area where we at Ingrained Tech fell into the fire-and-forget trap. One part of our backup system runs desktops out to a server, the server (and other servers) out to a NAS and the NAS out to the cloud. I don’t think our security peeps will freak out if I mention we use duplicity for this backup and Backblaze for our backup cloud. Backblaze is a dream to use compared to others we’ve looked at, and the pricing is competitive, so it suits our needs well.

    A few weeks ago, we realized that while backups were completing successfully and verification was fine, it was taking nearly the entire week to do our weeklies. That’s bad news. We back up terabytes of data, but this is 2020, and our drive IO/Network can handle it. We started by looking at both of those things, and sure enough, it was drive IO causing our problems.

    Unsurprisingly, reading the disk and creating a collection of encrypted tarballs (a super-simplification of what duplicity does, but gets the point across) on those same disks was causing problems. After investigating, the one build that occurs on that server was suffering from backups stretching out, too. We had seen occasional issues with the build, but nothing jumped out as the source, and it was only one night every month or two. It was on our list. You know, the same prioritized list you have. And this build wasn’t nightly-critical. You get the idea.

    This was a relatively urgent problem, as soon as last week’s backup would not be complete when this week’s tried to start. Not good.

    We took our DevOps mentality to the problem and discovered a simple solution that solves the issues. The backup NAS is RAID 50, so it can handle a lot more abuse than the server that was slowing down backups. So, we took the simple expedient of rsyncing the source server to the NAS, then using duplicity to tar and encrypt before sending it on to the cloud buckets. Internally, we do not believe we need to encrypt backups because if someone is in our network, all of that data is laying around. By putting duplicity and both the tar function and the encryption function onto the backup NAS, we moved it to a far less busy system. Backup times dropped from days to hours instantly, and our unrelated build problems went away.

    We have to rework the automation somewhat to make sure validation is, well, actually validating the data is correct. But we’re well on our way to having a stable, faster system.

    How does this fit with DevOps? We see the same thing happening often in the automation rush of DevOps. Yesterday’s best solution is not necessarily tomorrow’s best solution. “Automate and watch” should be the catch-phrase. Improvement comes from both DevOps culture and paying attention to changes in the tools market.

    As Alan pointed out, someone will eventually win the end-to-end DevOps rush—since I feel the urge to inject my opinion on who stands the best chances, expect a blog on this topic soon. Until then, knowing what your options are and how to best achieve your goals–even on problems that were “solved” last year–is your best path for continued improvement. Yes, it means rework, but just like reworking your code, the point is to streamline things, get closer to your organization’s goals and keep improving after the low-hanging fruits of DevOps have been gathered. The rate of improvement in several areas of DevOps is stunning, so you may find you actually like a new tool better than the one you chose a couple years ago. And remember, knowledge is power.

    — Don Macvittie

  • Digital Transformation Efforts Hindered by Lack of Upskilling

    Digital Transformation Efforts Hindered by Lack of Upskilling

    There’s no digital transformation without a staff transformation. The people skills that helped bring successful enterprises to where they are today won’t be the skills that will make them successful tomorrow. Fortunately, Leadership Suite readers are well aware at how important it is for the success of their organizations to close the gaps between the skills their employees have today and the skills they need to carry the enterprise forward.

    According to the Upskilling 2020: Enterprise DevOps Skills Report from the DevOps Institute, based on 1,300 respondents, more than 50% of enterprises find challenges with all aspects associated with managing the people, processes and technologies that make DevOps possible.

    The report found 58% of enterprises have a tough time actually finding those with the right DevOps skills and 48% said it’s difficult to retain skilled DevOps professionals.

    With that in mind, it’s no surprise the report found DevOps salaries on the rise. According to the Robert Half Technology 2020 Salary Guide, salaries for experienced DevOps engineers can reach beyond $179,250. Survey respondents said that the skillsets necessary for DevOps practitioners skillsets should be multifaceted, including process skills and knowledge (69% of respondents), automation skills (67%) and interpersonal skills (61%). The 2019 survey found automation skills to be the top skill, followed by process skills and knowledge.

    The survey contends that successful DevOps professionals will have expertise that consists of both breadth and depth of knowledge, along with tangible and intangible skills that help them both dive into the details of a situation while also understanding the big picture. The 2020 Upskilling survey cited three highly sought horizontal skill categories: automation, functional knowledge and technical skills.

    A second grouping of skills—process and framework skills—is a vertical skillset which focuses on flow and understanding of different practices and methods such as scrum, agile development and value stream mapping. Another vertical skill category focuses on human skills such as collaboration and interpersonal skills.

    “People, process and technology have always been the trifecta needed to execute DevOps successfully,” stated Shawn Ahmed, senior vice president and general manager of the Software Delivery Automation business at CloudBees. “As we strive to enhance the culture needed to predictably deliver better software faster at CloudBees, it’s been important for us to identify which skills are considered ‘must-haves,’ which are ‘nice-to-haves’ and which are ‘not important’ across teams, roles and regions.”

    “As the report underscores, upskilling is now more important than ever to enable meaningful collaboration between all teams to truly deliver software at an elite level,” said Ahmed.

    The survey also found that adoption for Agile is at 81%, DevOps 75% and ITIL is at 25%. Organizations that employ SRE rose to 15% this year from 10% in 2018.

    — George V. Hulme