devopsy.kinsta.cloud

Category: DevOps Culture

  • TechStrong TV: strongDM Helps Kustomer Go Remote

    TechStrong TV: strongDM Helps Kustomer Go Remote

    For a procurement process to be effective, the relationship between the customer and the product team is almost as important as the functionality and features of the product itself.

    During this interview for TechStrong TV, strongDM CEO Elizabeth Zalman and Steve Flinchbaugh, senior SRE at Kustomer (a customer support CRM platform for managing high support volume effortlessly), talk to us about the strong bond between the Kustomer team and the support team at strongDM.

    Steve explains how Kustomer uses strongDM to empower its remote teams, how it fits into their development workflow and how strongDM has made his and his team’s lives easier.

    strongDM allows remote teams to easily manage access to databases, servers, Kubernetes clusters and web apps.

    Check out the interview below and follow along with the transcript to find out more.

    Transcript

    Alan Shimel: Hey, everyone, thanks for joining us for this next session here on TechStrong TV. This is gonna be a really good session; it’s something we haven’t done before. I have two guests, which we’ve done before, but we’re really gonna zero, we’re gonna take two different companies and see how they interact and how that helps, especially given everything that we have going on around us.

    Let me introduce my two guests to you first. First of all, we have Elizabeth Zalman. Elizabeth is the CEO of strongDM. We’ve done—I think we’ve done at least a podcast and so forth with strongDM before. Liz—hey, welcome, thanks to TechStrong TV.

    Elizabeth Zalman: Thanks, Alan. Nice to be here.

    Shimel: Thanks for joining us. Okay, and then joining Liz and I is Steve Flinchbaugh. Steve is with a company called Kustomer, and that’s spelled with a K, and he’s gonna tell us about it, as well as his position and background there.

    Steve, why don’t we start off with you, okay? Kustomer with a K—what do you guys do, and what do you specifically do at Kustomer?

    Steve Flinchbaugh: Sure, Alan. Thank you for having me. So, I’m a senior SRE at Kustomer, and what Kustomer is, is a CRM for customer support. And we really are built off of our platform. There’s a lot of intelligent automation that allows our customer service teams, our customers, to give the best possible customer experience they can and accomplish their customer service goals through, ideally, less staff and less effort using our platform.

    My goal as the senior SRE is to ensure the reliability of our platform, the kind of implicit trust that everyone expects, and to make the job for our developers as easy and seamless as possible.

    Shimel: Cool. So, a real, live SRE right here on our show—very cool. You know, there’s a lot—I don’t know if you guys have seen, there’s been a lot of articles written lately in the press around, you know, are we overblowing the whole SRE thing, right? And is it real, how real, and where does it fit in and all of these other things.

    But anyway, Liz, we gave Steve a good chance to tell us about Kustomer with a K. Let’s give you your chance—tell us about, remind our audience about strongDM.

    Zalman: Yes. Steve is one of my favorites, by the way—so is Kustomer with a K. They’re one of the most forward thinking customers with a C that we have. [Laughter]

    Shimel: Okay. Very good play on C/K, there. [Laughter]

    Zalman: strong is a—it’s a proxy, it’s a control plane, it’s insert whatever word you want there and it lets you manage and audit access to servers, to databases, to Kubernetes clusters, to whatever infrastructure you’re running that is firewalled. So, typically, that access is managed by hand, or keys are sitting in a box or a vault somewhere, and we let you collapse all of that down into a single control plane for both the management and auditing of that access

    Shimel: Yep. And I just—look, I feel like we have to mention that, you know, given the whole COVID situation and working from remote, you know, strongDM has been a real godsend to a lot of companies who had to kind of flip a switch and empower remote people to have access and stuff that, you know, from a different place on different machines, devices than they had before.

    So, though strongDM had a great case before COVID, right, a great use case, post-COVID, Liz, how many—you know, I’m not asking for the amount of customers, but I mean you’ve seen a lot, I imagine you’ve seen a lot of activity from customers who are, have switched to remote and need help with that.

    Zalman: Yeah, certainly, it was challenging before. I think most companies today have remote workers, anyways, or multiple office locations. With the lockdown with COVID, I think what ended up happening is, for companies who rely on the corporate network itself as the perimeter within the building, that perimeter is now gone, and so, what do you do? If you’re using something that’s IP-based, all of a sudden, your IP surface area went from, like, two to 5,000 if you’re an enterprise.

    So, we certainly saw a doubling down of existing customers and an increase in interest in the product. I might ask Steve, like, could you have imagined what—I mean, what was it, like, you guys have an office in New York…do you guys have remote workers? I don’t—yeah.

    Flinchbaugh: Yeah, so, we have an office in New York and we recently—that’s our headquarters—and we recently acquired some office space down in Durham, North Carolina. That’s kind of our first official outpost, and that was kind of our introduction to people outside of New York, and it was—this was after we had adopted strongDM, and I have to say, it was entirely seamless. And ever since the pandemic began, I know it’s good because I haven’t thought about it that much. strongDM is—

    Shimel: That is always the sign. You know what—sorry—I was in security for 20 years. They didn’t call it cyber then, it was InfoSec, but we always used to say, “If they didn’t think about it and it didn’t hit anyone’s radar screen that they—you know, that was a good thing.” When people hear about security stuff, it’s because something bad happened.

    But I wanna make a point here, though, and that is—Steve, it’s my understanding you guys didn’t, you’re not a Johnny come lately to strongDM. You guys were using this well before COVID and the present situation. Talk to us—let’s go back in time to then, it was about a year and a half ago, right?

    Flinchbaugh: Yeah. And actually, if you don’t mind, I’d like to go even further back in time, about four years ago—

    Shimel: Be my guest.

    Flinchbaugh: – when I joined Kustomer.

    Shimel: Okay.

    Zalman: You joined it four years ago?

    Flinchbaugh: Four years in September.

    Zalman: Wow! How big were you then?

    Flinchbaugh: I was, I think, employee number 16. We were still in stealth mode, we weren’t charging our customers yet, and Steve comes into Kustomer bright-eyed and bushy-tailed. But at this time, we were running agents on our servers to provide SSH access to our engineers, and I was charged by the CTO to stand up a VPN, which I had never done. And this came in the form of open VPN, and I had to manage the certificates and the log-in and the users and every employee that joined the company, I had to on board them and configure a profile.

    And then, fast forward to, I think it was about a year ago, where the CTO again came to us and said, “Hey, there’s a really cool company that I think we should take a look at. We have a mutual investor, and they have a lot of cool features that we haven’t had for the past three years.” So, we had a couple really cool meetings with Liz and her team. I could immediately tell that we were working with a team that knew what they were talking about, they were technical, they were fun to work with and they kind of just got what we needed out of the tool.

    And now, today, there are so many things that are taken off of my plate in addition to more features for security and making developers’ lives easier that strongDM now gives us.

    Shimel: Very cool, very cool. Alright, now, we can fast forward to Durham and how strongDM helped with the rollout there of a new—I don’t wanna call it a remote office, but I think you used the term outpost?

    Flinchbaugh: Yeah, so, it’s definitely, like, our—we call it HQ2, I believe, but we’ve got a fully functioning, we call it squad, so we kinda have self-sufficient and cross-functional teams out there, and everywhere across the country, but Durham was our first remote squad, if you will.

    And the neat thing about strongDM is, I don’t necessarily have to say when a new user joins, when someone joins the company, there’s not necessarily a task in my to-do list. It’s so self-service with our Okta configuration, a user can go in and say, “Hey, I wanna start using strongDM, I’ve heard all about it. How do I get access to our data storage and our private resources?” And at that point, I get an e-mail, I can add them to a roll, to a group, and they’re happily on their way. So, I don’t need to configure a profile, I don’t need to do anything special for these individuals. So, from my perspective, it’s incredibly easy to onboard new and remote folks.

    Shimel: That sounds like too good to be true. Is it true, Steve?

    Flinchbaugh: [Laughter] It does feel too good to be true sometimes.

    Shimel: Okay, and you’re saying you guys use Okta for a lot of your IAM and stuff like that?

    Flinchbaugh: Yeah, part of our maturation as a company, you know, back in the day, we had, of course, authentication and identity all over the place and now it’s much more unified. All of our tools that can integrate with Okta, it just makes it that much easier. And again, it’s just things that I don’t have to think about as often

    Shimel: So, Liz, let me throw something back at you. Again, the whole IAM space is something I’m somewhat familiar with—how important is it for strongDM to integrate with an Okta or ADs or other kinda directories and stuff like that

    Zalman: It’s critical. It’s one of the core principles of the business. I think, you know, I’m guessing, Steve, the customer made the decision to buy Okta well before strongDM.

    Flinchbaugh: I think it might have actually been around the same time—but yes, I think Okta was shortly before strongDM

    Zalman: Yeah, so, you have to start with the question of, “What is my identity store? What controls identity, and then how do I integrate that identity store with everything else?” So, strong has integrations with all of the SSOs—because I don’t want to reinvent the wheel. Steve’s already invested a bunch of money in Okta. He’s already reinvested a whole bunch of money in whatever he’s using for automation, Terraform or otherwise or an Amazon tool. Most companies have already invested a whole bunch of money in Splunk or Sumo Logic or QRadar, whatever they’re using for logging, I don’t need to reinvent the wheel with logging and alerting, I just need to make sure there’s a connector between the two.

    And so, honoring what people have already invested a whole bunch of money in and sort of bet the farm on already is critical.

    Shimel: Yeah, you know, Steve, you’re an SRE, so you live this every day. But it’s something—I’m an observer now. My days of those battles are over, right? But as an observer, it’s still, I shake my head sometimes, because so many companies like Kustomer, right, have kinda made their bets on the tools that they use, right? They’ve put together an identity in access management, but it’s not log management, cloud platforms—you know, your whole tool set. But yet, there are still plenty of companies who are trying to say, “No, no—you should use us for everything, right? We can sort of do what strongDM does.” You know, and you know the old saying with this, right? They try to give you 80% of the functionality for 40% of the price, and if that’s good enough for you, it’s good enough, right?

    And I was never a fan of that model—Liz, you’re laughing; what do you think? I mean, we see this still, and I don’t—you know, I assume some companies go for that, you know? But I can’t imagine it really works out. You just don’t get the function—we live in a great time where there’s so much available to us to try to make lives easier for people like Steve, for the SREs of the world and the Ops folks. You know, why would you try to just shove everything into one vendor and do, and put up with less than.

    Steve, what do you think?

    Flinchbaugh: So, it’s definitely, when you’re a smaller company, it’s, of course, much easier to adopt and drop and try new technologies and vendors. But, of course, as we’ve grown, that cost becomes higher and higher. So, when I first joined Kustomer, we could try new things whenever we wanted, but I can already see in the couple years that I’ve been with the company that implementing something like strongDM would be almost exponentionally more effort now, because I’d have to go through different departments and accounting and finance and communicate with the team, and developers just wanna know, “How do I do my job? Like, just tell me what to do.”

    Shimel: Mm-hmm.

    Flinchbaugh: And more than the functionality and the features of the product, I truly feel like we have a relationship with the strongDM team, and that’s almost just as important to us. We know that they are responsive, that they’re gonna listen to us, that they’re gonna help us out—and they have, you know, literally weekly.

    And that is so important to us as customers that, if someone came along and said, “Hey, we’ll charge you 50% of the price that strongDM does,” I don’t think I would be too tempted to consider that right away.

    Shimel: Yeah. But I think that goes to the model today, right? It’s part of this whole cloud native, open source, freemium core, open core, whatever you wanna call it, which is—the key is not to go hire some enterprise sales guy who comes by and wines and dines people. It’s about—hey, here’s the product. Let me get the product in your hands, right? Let me deliver delight, as they say, right, with that product, and the bonds that are formed from that type of relationship, right, it’s—if you wanna call it DevRel, you know, a lot of people call it developer relations and community relations—those sort of bonds are much stronger than the old sort of sales game that I grew up in, for instance.

    Elizabeth, with what Steve is saying, is that sorta news to you that it’s much easier to get in and kinda grow with these customers than it is to kinda come in when they’ve reached a certain scale and it’s a lot harder to get adoptions done

    Zalman: Certainly, it’s easier when a company is young—50, 100, 150, even 200—to get implemented. I think to Steve’s point, eventually,  you have a procurement department, and then you have to go through the traditional, like, “Oh, that’s the price? Okay, we’re gonna knock it down by 50% now,” right, and that’s just how the operate.

    Shimel: Right, yeah. Mm-hmm

    Zalman: And certainly, there are much longer sales cycles in the enterprise side, with a company of Kustomer’s size. Even the size today, you know, two week POC and you can play with it enough, to your point, Alan, where you decide if it’s right for you, if it fits enough of your requirements.

    With larger enterprises, it’s—and again, to Steve’s point, it’s not…you do have to go team by team, right, at a larger enterprise and say, “Okay, we’re gonna do the finance team now, and then we’re gonna do the engineering team, and then we’re gonna do the DevOps team.” And it’s sort of rinse and repeat and you get the hang of it after a while, but it’s bite sized chunks, always, whether the bite sized chunk is the entire company at once, or work group by work group.

    Shimel: Yeah. And I think that very much mimics the whole DevOps adoption pattern as well, right? You don’t go in and just turn on a large enterprise to DevOps, you do it bubble by bubble, team by team, right? And quite frankly, the other thing is, though, is I will tell you that sometimes that procurement process and all the b.s. that goes with it is why developers or DevOps people will whip out a credit card and just do it, right? And you get the whole shadow IT thing or whatever you wanna call it, but it’s like, who wants to—you know, I gotta sit and explain to this person why strongDM makes my life easier? You know, I mean, it’s—especially someone who has no technical background, it’s like, you know, where do I begin?

    But, you know, nevertheless, you guys got a year and a half of history here. Steve, where do you see the first squad’s in Durham, I assume that means you guys are planning second and third squads and maybe outside the U.S. and what have you—is strongDM tied, I imagine, tied into that as the roll out moves along here

    Flinchbaugh: Yeah, of course. It’s become the way that we access our resources across all of engineering. And we actually acquired a Spanish company, Reply.AI, a month back.

    Shimel: Oh, very cool.

    Flinchbaugh: Yeah, so—

    Zalman: Congratulations

    Flinchbaugh: Thank you. So, I’ve been having some conversations with the Reply engineers, and I can already tell that they’re impressed with how we use strongDM and how it kind of fits into our development workflow. And so, that would be interesting, because they have infrastructure of their own, infrastructure that we haven’t used before, so it would be a cool opportunity to say, “How does this plug into strongDM?” And I really have no concerns that that would be the case, but it’s gonna be a fun task to get all of that in the same kind of workflow that all of our Kustomer engineers use today.

    Shimel: Excellent. When you say Spanish, like in Spain—they’re based in Spain?

    Flinchbaugh: Yeah, they’re based in Madrid. I believe they’re a fully remote company, though, throughout Spain. So, they kinda have that remote culture, already, so it’s perfect for us right now, and of course, their AI expertise is nice to have, as well.

    Shimel: Absolutely.

    Zalman: Steve, where is their infrastructure? Like, is it in the U.S. in AWS or is it in something sitting in Europe?

    Flinchbaugh: I can’t say too definitively, but I do know that they have a mix of AWS and Heroku right now.

    Zalman: Interesting.

    Shimel: Really?

    Zalman: So, you’ve got a distributed team in Europe and now, effectively, multiple data centers if you’re talking AWS and Heroku that aren’t merged with Kustomer as well—

    Flinchbaugh: Yes, indeed.

    Zalman: Yeah, I see.

    Flinchbaugh: That’s right.

    Shimel: Sounds like an opportunity, Liz. [Laughter] Liz, let me ask you a question—how many, I mean, what I’ve always loved about the Internet is, it knows no borders, frankly, right? I remember the first time I put up websites and I started seeing hits come in from around the world. This is, like, 1996, and I was like, “Wow, we’re global!” Not at Media—you know, not this company, obviously.

    But what is the customer mix at strongDM? Is it international or is it mostly U.S., or—if you know?

    Zalman: Yeah, it’s heavily international. We’ve got, actually, a big contingent in Australia, we have Europe, we have Asia. Our large enterprise customers all have offices in India, whether they’re using contractors as a work force or an actual office there, you’ve got the U.S., you’ve got Canada, you’ve got South America.

    Oh, and you know what? Actually, I was just gonna say we’re not in Africa—we’re totally in Africa, so it’s everywhere. And then even, we’re not in the Middle East, I don’t think. But even more interesting, I think, than where the people are, it’s where the data centers are. You’ve got this crazy Cartesian product of people trying to connect to stuff, and most companies—we’re in China, I mean, we’ve got people on, we have workers on factory floors in China who need to SSH into infrastructure.

    Shimel: Very cool.

    Zalman: And so, it’s crazy to think about all of the networking going on, the latency, and how to make that connect, and it’s just personally fascinating to hear the new use cases that come up. I was like, when I heard factory, I was like, “Wow!” And then I started thinking of, like, Tesla. I was like, “I wanna be on the factory of Tesla,” but no.

    Shimel: Yeah. That could be in China, too. You know, it’s funny you bring it up, I actually interviewed a CEO of a company maybe last week who, they are instrumenting manufacturing factories, because a lot of that machinery was not connected that you can, you know, you had visibility, and they actually put things on to machinery that allow you to instrument them and monitor and stuff. There’s amazing things going on. And by the way, each one of those add-ons to the manufacturing machines has to have a certificate, an identity—you know, there’s a whole piece of this, too, and I just think it continues to go on.

    Steve, we don’t have a lot of time left. How has the COVID thing kinda affected you guys?

    Flinchbaugh: So, personally, I feel incredibly fortunate to say that my work has changed almost not at all. I think my position and a lot of our department is very remote friendly, and even though we weren’t set up, really at all, for remote before the pandemic, the transition has been relatively seamless—obviously, from a strongDM perspective, it is seamless.

    But overall as a company, I think—of course, there’s a ton of adjustments with different departments and some are having it easier than others. But I actually think engineering is, our efficiency and output and how we’ve put out features since the beginning of this has actually increased just a little bit.

    Shimel: That’s great to hear, man. Really good. Guys, we’re about out of time. I want to thank both of you—both of you coming at us from New York, today, I should mention, so thanks for joining us. Liz, any last thoughts, comments you want to add?

    Zalman: Nope, I don’t think so. I wanted to say thanks to Steve, and I appreciate the comment on relationship. It’s so important, as I say—you know, at strongDM, everybody touches the customer equally. It doesn’t matter if you’re in account management or support or engineering that I joke that if we were to ever have commissions at the company, which we don’t, I would give support the commissions, because they’re that important.

    Flinchbaugh: As a support company, somewhat as an employee there, I can very much appreciate your support team as well, Liz, and it’s not an exaggeration to say it’s the best support that I’ve received from any vendor, ever.

    Shimel: Very cool, very cool. That’s a good way to end it. Alright, Elizabeth Zalman, CEO, strongDM; Steve Flinchbaugh, SRE at Kustomer with a K—thanks for joining us on TechStrong TV. This is Alan Shimel. We’ll be right back with our next guest.

  • Operationalizing Kubernetes Virtual Summit Speaker Spotlight: James Strachan, Liz Rice, Priyanka Sharma and Tim Hockin

    Operationalizing Kubernetes Virtual Summit Speaker Spotlight: James Strachan, Liz Rice, Priyanka Sharma and Tim Hockin

    The Operationalizing Kubernetes Virtual Summit will bring together Kubernetes and cloud-native community members for a unique learning experience focused on the tools and best practices you need in order to successfully secure and manage Kubernetes. Presented in a virtual reality environment, the event will take place on Oct. 1, at 10 a.m. EDT.

     

    Operationalizing Kubernetes Virtual Summit - keynote speakers - James Strachan, Liz Rice, Priyanka Sharma, Tim Hockin

    The Operationalizing Kubernetes Virtual Summit is a free, interactive virtual conference featuring a stellar lineup of Kubernetes and cloud-native experts, including keynote speakers James Strachan, Liz Rice, Priyanka Sharma and Tim Hockin.

    James Strachan, distinguished engineer at CloudBees, is one of the four brilliant keynote speakers presenting at the virtual event. James is co-founder of Jenkins X, an open source project that helps developers automate their CI/CD processes for cloud native applications. James is also the creator of the Apache Groovy programming language and the Apache Camel integration framework.

    In his keynote session “Using Jenkins, Jenkins X and Tekton with GitOps,” James will demonstrate how Jenkins, Jenkins X and Tekton can solve all of your cloud-native CI/CD requirements using a simple GitOps approach that is easy to set up, use and manage from Git.

    AWS Container Hero, Liz Rice, will also make an appearance at the virtual conference as keynote speaker. Liz is vice president of open source engineering at Aqua Security, where she works on container-related open source projects, and she’s also chair of the CNCF’s Technical Oversight Committee.

    The author of “Container Security: Fundamental Technology Concepts that Protect Containerized Applications” will review what you do and don’t need to worry about when running your cloud native applications during her session, “The State of Kubernetes Security.”

    Another CNCF member joining as keynote speaker is Priyanka Sharma, general manager at CNCF. Priyanka was previously the director of Cloud Native Alliances at GitLab, where she built the developer evangelism team that participates regularly in the cloud native community. Priyanka has contributed to several CNCF projects such as Jaeger and Vitess and was a founding team member of the OpenTracing standard.

    During her talk, “What 6.5 Million Developers Have in Common: Kubernetes,” Priyanka will share some interesting findings from research done by CNCF on the cloud-native ecosystem and will also discuss Kubernetes and cloud-native trends and best practices.

    Last but not least, Tim Hockin, principal software engineer at Google, will be interviewed for the keynote session “Operationalizing Kubernetes: Interview with Tim Hockin.” Tim works on the Google Kubernetes Engine (GKE) and is co-founder of the Kubernetes project. He has also worked on Google’s Borg and Omega projects as well as the Linux Kernel.

    As Kubernetes keeps gaining traction in mainstream IT environments, the next big challenge IT teams will face is operationalizing the platform at scale. But, is the Kubernetes ecosystem mature enough to operationalize at scale? Attend Tim’s keynote session to find out.

    Join this interactive, multi-track virtual conference and learn how thought leaders are embracing containers and microservices environments, leveraging cloud native technologies and enabling digital transformation with Kubernetes.

    You can hear from these keynote speakers and more than 30 other expert speakers at Operationalizing Kubernetes Virtual Summit. To check out the agenda, the full lineup of speakers and to register (for free), visit the Operationalizing Kubernetes Virtual Summit website.

  • Low-Code: An Oasis During Developer Drought

    Low-Code: An Oasis During Developer Drought

    Key insights from Mendix’s 2020 Developer Drought Index

    You may have heard that Silicon Valley is in the midst of a developer drought. But the Valley is not alone; developer talent across the U.S. heartland has dried up. In fact, the top 10 U.S. counties with the highest developer demand per capita aren’t even in California.

    A recent report by Mendix identified new hiring hotspots and a changing U.S. map for tech talent. States in the U.S. heartland are actively seeking developer talent, though some are slow to adopt 100% remote work. In the wake of COVID–19, many are reassessing work-life opportunities, leaving densely populated cities to work and live in more rural areas.

    I recently had a great discussion with Sheryl Koenigsberg, head of global product marketing at Mendix, to make sense of the “Developer Demand Index” findings. Below we speculate on the future of developer work, and how low-code platforms may be the oasis many talent-thirsty companies seek.

    ‘Developer Demand Index’ Study

    The “Developer Demand Index” sought to identify locations where developer talent is needed the most. The process involved a geographic analysis of 2,000 of July 2020’s job ads for U.S. software developers.

    The study found high developer demand and short supply in middle America; South Dakota, Nebraska and Utah were among the top states with the lowest supply to demand.

    At a county level, the highest developer demand was in Cumberland County, New Jersey; Minnehaha County, South Dakota; and Pontotoc County, Mississippi.

    The study demonstrated how more established tech hubs—Silicon Valley and Austin, for example—have a better balance of talent demand and supply.

    “The study confirmed unpopular theories that I had,” said Koenigsberg. “Developer drought is not a Silicon Valley or coastal-only problem; smaller metros throughout the country are experiencing the same problem.”

    Conditions for a Drought

    Why do states in the nation’s heartland have a developer drought to begin with? I assumed that a lower average salary in middle America would deter developers, but Koenigsberg said the conditions are more complex.

    “I don’t necessarily see a correlation between average salary and developer drought,” she said. Rather, new tech hubs continue to form wherever larger enterprises can get tax breaks. Other regional perks could include local government startup incentives or university partnerships.

    Tech certainly has a history of revitalizing less dense areas with new hubs. Take Google’s expansion into Austin, Amazon’s takeover of Seattle’s South Lake Union neighborhood or SpaceX’s remote Starship site in Boca Chica, Texas. Naturally, these areas attract the requisite talent and encourage other companies into the fold as well.

    For example, the report speculates South Dakota state could be a new Silicon Prairie hotspot. “A vibrant tech & startup scene, local talent, and the lowest COVID–19 rates are all driving the economic surge in this state,” read the report.

    With remote work and social distancing brought on by COVID–19, technology companies are adapting and the urgency to cluster in certain locales may dissipate.

    COVID–19 and Remote Work

    Software was already eating the world. But with COVID–19, it’s eating physical reality itself.

    With COVID–19 forcing many companies 100% online, the need for new software is skyrocketing like never before. Google, Facebook and many others have enacted stay-at-home plans for most of 2021. After the crisis, remote work will be a more permanent reality for many.

    While COVID–19 benefited tech, many brick-and-mortar businesses were less prepared. We’re now seeing the frailties of old systems, described Koenigsberg, and the need to replace paper-based or manual operations with digitized versions. Consumer-facing companies that did not vigorously embrace digital transformation before COIVD–19 are now in a tight spot.

    Low-Code Waters Fill a Developer Drought

    According to Derek Roos, CEO of Mendix, “the ‘Developer Demand Index’ shows that companies need to think differently about how and where to engage skilled tech workers in 2021 and beyond. Traditional development paradigms basically fall apart when you’re dealing with mobile or remote workflows.”

    As I covered recently, COVID–19 is only one of many factors spurring a low-code revolution. By utilizing visual-based models, “citizen developers” can construct applications. This enables a business analyst, for example, to string together an internal application without jumping through the traditional IT hoops. Koenigsberg identifies other low-code benefits:

    • Hire Local: If tools are less impenetrable, companies can retrain local employees, helping recover the developer gap and negating the need to hire externally.
    • Collaboration: Low-code aids remote work, enabling pair programming where teams work on the same model simultaneously.
    • Domain Expertise: Citizen developers with niche domain knowledge can better optimize applications to their industry needs. Knowing a factory production yield, for example, can help better construct a manufacturing application.
    • Women in Tech: Koenigsberg notices significantly more female involvement at low-code themed events. Hopefully, low-code can have a balancing effect on gender participation in tech.

    Final Thoughts

    The Mendix “Developer Drought Index” revealed areas of high demand and short supply throughout the U.S. Interestingly, 92% of the job ads analyzed in the study required a specific location. Regardless, the report concludes there are compelling “opportunities for companies and individuals to decentralize talent away from established tech hubs using virtual teams and cloud technology.”

    Low-code seeks to democratize software development to keep deployments on pace with the intense demand for software. Of course, low-code is no cure-all, and Developer Drought locations will likely still seek external or offshore hiring to supplement. However, low-code may offer the respite needed during uncertain times.

  • Survey Surfaces Impact of COVID-19 on DevOps Teams

    Survey Surfaces Impact of COVID-19 on DevOps Teams

    A survey of 500 IT and engineering professionals across software and finance industries published today by Harness, a provider of continuous integration/continuous delivery (CI/CD) platform, suggests there is significant room to improve application development processes now that most DevOps teams are working from home due to the COVID-19 pandemic.

    The survey finds only 43% of developers said development velocity has increased since COVID-19, while just over half (52%) said they are happier in their roles since the pandemic began. Ravi Lachhman, a developer evangelist for Harness, said as velocity increases so does the need to automate DevOps processes across a distributed application development team. The level of automation achieved, in turn, has a direct impact on developer satisfaction.

    Despite any productivity concerns, however, nearly three-fourths of developers (74%) said their organization plans to keep a remote or distributed workforce following the pandemic. That compares to only 2% who said their teams were fully remote prior to the pandemic.

    On the plus side, developers are overwhelmingly satisfied (94%) with their employer’s investment in employee growth and development, and two-thirds (66%) said they value their companies even more than they did before the crisis. However, only a little more than half, (52%) said it was unlikely they would change jobs within the next year. Among developers who make less than $75,000, 54% said they are at least somewhat likely to change jobs, compared to 46% of those making more than that.

    Compensation was the most-cited priority for switching jobs. Over a third (35%) said that if they were to look for a new employer, their top priority would be better pay. That compares to 27% who would prioritize more opportunities for career and professional growth and 20% who would switch for the ability to work remotely. Another 13% would leave for better benefits, while 5% cited shorter hours.

    Almost two-thirds (60%) anticipated that further salary cuts or layoffs for their development teams are at least somewhat likely. So far, 28% of developers reported there have been layoffs at their organizations, with 22% saying those layoffs included members of their teams. Only 29% of developers said they have seen an increase in developer onboarding since the pandemic began, compared to 42% who saw a decrease. Another 29% saw no change.

    Nearly two-thirds of respondents who earn $150,000 or more are happier in their roles since COVID-19 began (64%), while 44% of those who make $75,000 or less are happier.

    Among developers over the age of 55, almost three-quarters (70%) said they are either less happy or their happiness has not changed. Interestingly, that compared with 43% of millennials. The report also noted both men and women feel they are compensated fairly, at 81% and 82%, respectively.

    The so-called “new normal” that DevOps teams are adjusting to is clearly taking a toll. For the most part, the transition to working from home full-time has not been as disruptive as many initially feared. However, it’s also clear many organizations will need to revisit how their DevOps workflows are constructed to accommodate the fact that most DevOps teams won’t be returning to an office anytime soon.

  • Managing Remotely: 6 Ways to Support Engineers

    Managing Remotely: 6 Ways to Support Engineers

    Managing remote engineers effectively comes with a host of considerations. Here are six to keep in mind

    Dear 2020, we’d like our deep work back.

    Our shift to remote work in 2020 moved the majority of face-to-face interactions into screens. Although initially we assumed this shift was a temporary adjustment, most of us now realize it’s just the opposite. Twitter, Facebook, Shopify, Slack, Box and more have publicly declared remote work is here to stay and they are not alone—84% of businesses now report they will increase remote work post-COVID-19 pandemic.

    With our new reality came next-level distractions—homeschoolers, playful pets, social unrest and, oh yes, a scary global pandemic. Moreover, the lockdowns rewired our collaboration habits, stretched our bandwidth, and threatened our ability to focus on our best work.

    As a result, managers—the forgotten middle of the workforce—are emerging as quiet heroes fighting to protect team effectiveness. At Uplevel, we’ve worked with engineers nationwide and have learned the top ways that managers can help their engineers empower their best work:

    Mind the Meetings

    Engineers want their managers to protect their time for deep work. They are constantly bombarded with changing priorities that require endless meetings, crushing their ability to dive in, solve problems and innovate. How bad is it? Of the 250 engineers and managers we interviewed, 50% of individual contributors reported that more than twice a week they don’t have enough time to do their work, with 19% of engineers reporting it’s an issue every day. Bottom line: If a meeting “coulda been an email,” make it so.

    Say No to Micromanagement

    Nobody likes the helicopter parents of work. The constant hover erodes trust, destroys morale and slows down otherwise efficient, effective people. Top performers will tell you, autonomy contributes to their overall happiness at work, and research continually tells us that happy employees are more productive and they stick around longer. Instead of spinning on the minutia, make it your mission to block distractions and tackle bottlenecks for them so they are empowered and available to do their best work. More than one-third—39%—of engineers are blocked on issues they can’t unblock themselves at least once a week. That’s a weekly chance to free your team to do their best work.

    Embrace Flexibility

    For the sake of protecting “the flow,” it’s a good time to go with the flow, too. Overly structured, old-school project management must give way to the fluid, flexible tools empowering us to get work done anytime, anywhere. Embrace a project management style that is as fluid as your team’s changing priorities and consider light-touch micro check-ins that leave room to revisit the game plan weekly.

    More Comms, Not Less

    Right now, it’s easy for individual contributors to feel both socially and professionally isolated. As a result, their confidence waivers and paranoid flares as they question whether their contributions make an impact or get noticed at all. Now is not the time to back off of communications. Don’t confuse this with “respecting personal boundaries.” If you’re worried that communicating will somehow exert unintended pressure, simply establish clear expectations and model them by example. A simple way to lean into communications is to make them more frequent, much shorter and less formal. By acting more like a coach than a manager, you’ll not only keep the team focused on the right tasks but you’ll also show them you care about their well-being beyond “the work.”

    Lead By Example

    The quickest way to zap trust and kill morale is by ignoring your own rules. Engineers want their managers to lead by example and consistently exhibit the same behaviors they expect from their teams. If it’s respecting work/life balance (and refraining from midnight emails), don’t hit the send button until it’s time. If it’s a commitment to stay present during group meetings, stop multitasking. If it’s a promise to wear pants on Zoom calls, put your pants on. You get the point: Don’t create rules for remote teams that you’re unwilling to follow yourself.

    Create Opportunities To Connect

    You’ve heard it time and again since March: We’re in this together. It’s true. No one rolled into the pandemic with a playbook; managers and their teams are winging it. Forced isolation is not a normal human state and it shows. Across the country, doctors report more cases of depression, domestic violence and substance abuse. In fact, a poll by the Kaiser Family Foundation shows the pandemic is taking its toll—45% of adults say this pandemic has affected their mental health. Another study by mental health provider Ginger found 69% of employees admit this pandemic has been the most stressful time of their career. How can you help? Use this collective behavioral beta test as an opportunity to show empathy and connect. Are team happy hours gone? Replace them with the dogs and cats of Zoom at the beginning of your weekly meeting. Are team lunches no longer doable? Have virtual outdoor picnics and encourage your team to get some fresh air. Be creative—it’s a great time to rally around the things that connect us as humans, not just teammates.

    Thanks to the COVID pandemic, 64% of us now commute from our beds to our home office (or the kitchen table, or sofa). That’s a ninefold increase in four months. As it turns out, many of us don’t mind the change. A full 60% of us would actually prefer to keep it this way. If our engineering teams stay virtual, it’s our job to empower them so that remote work can still bring about their best work. As we embrace this ever-changing world, now is the time to tap into our empathy and communication and leverage the data and technology available to us to ensure we turn hardship into innovation.

  • Did Your Last DevOps Strategy Fail? Try Again

    Did Your Last DevOps Strategy Fail? Try Again

    Let’s get one thing out of the way. DevOps isn’t a panacea—it isn’t magic, it isn’t a requirement for any enterprise and it won’t work for every team in every situation. Above all, it isn’t a yardstick by which an outsider can measure great operations, development or IT. And if anybody tries to tell you it is, feel free to say thanks and politely change the subject. You’re the one responsible for delivering the services your business depends on, and if the way you do it meets the needs of your business and the team is happy, stick with it.

    But if you’ve tried adopting DevOps methodology, it’s likely because your business needs to substantially alter itself to meet specific goals. And DevOps has demonstrated the ability to help many organizations. Unfortunately, just as many seem to abandon DevOps initiatives and roll back, sometimes more frustrated than if they hadn’t tried it in the first place.

    IT might be the team responsible for reliability, but this is a big challenge in an increasingly “fail fast” era. Many businesses are encouraging their departments to experiment, learn from their mistakes and keep trying until they deliver business-transforming innovation. But in IT, the high visibility of issues—even those initially within the accepted risks of a new project—seem to be treated differently. Even minor and expected teething pains can be judged as failures in hindsight. And many of us have seen instances in which attempting something new and encountering difficulty seems to make it five times harder to get off the ground on the next attempt.

    DevOps is a prime example. As its culture and practices gained popularity, companies were quick to jump on the bandwagon—only to stumble in the execution or not deliver anticipated “transformation” or measurable ROI. It’s not uncommon for these companies and decision-makers to be left with a bad taste in their mouths. They may be reluctant to revisit DevOps and try again, even with the gained value of previous investments and lessons learned.

    This isn’t much of a surprise: Humans don’t like to investigate public failures, and everything in IT is public, assessed in binary absolutes. It either works or it doesn’t, apps are up or down, and everyone in the company can see them. It’s also natural for businesses to switch their focus to the next potential success if personal political capital was part of a DevOps project. And as engineers, looking forward is in our DNA. We’ve built our careers around finding new and better ways to meet customers’ needs, solving novel challenges, and permanently squashing nagging issues to make room for new technology. The trick is to avoid considering DevOps a passing fad.

    There’s significant value to be gleaned from any investment in DevOps—a better understanding of the human dynamics of your organization, at a minimum. If your team tried to implement some of the processes of DevOps or took the advanced step of adopting DevOps culture, don’t forget you did it for a reason. Go back and review what led you to consider DevOps in the first place. Chances are the business needs behind it haven’t changed and may have even expanded.

    Outline those earlier reasons—they’re likely still there, even under novel circumstances such as shifting the team to work from home. Did your DevOps effort meet its original objectives, regardless of any rear-view assessment? Drill into the details where it didn’t. Was it due to culture, communication, risk reassessment or operations challenges? Did your team end up building something different than what you intended—a compromise not meeting the business’s needs? Take your time; you likely had many good people on the effort who are eager to share what they learned. A previous misstep could be due to a skills gap, software, management support or something as basic as infrastructure. The first step in taking another swing at DevOps is analyzing the previous attempt with data instead of opinions.

    And there’s a good reason you’re likely planning to try again: The stakes are high. According to Forrester, 80% of revenue growth will depend on digital offerings and operations by 2022. Organizations will survive and grow depending on their ability to design and deliver technology services, respond to issues and meet growing user expectations. At the same time, considering the environment brought on by COVID-19, IT teams are seeking new ways to sustain operations and use the time to build a head start for when business picks up.

    With this in mind, here are a few ways businesses can approach evaluating the execution of a first DevOps attempt to inform a successful second try.

    First: Deputize an Investigator

    You’ll need a deputy to help you conduct a forensic analysis and your QA team might be an unexpected place to find the right candidate. QA likes many of the outcomes of DevOps practices because they’re often suffering horror-show weekends at the hands of big-bang monolithic deployments at several companies. If you don’t find a detective there, empower someone who focuses on quality service and considers it a peer to availability, security and resiliency.

    Your first job will be to demark the fault lines. Remember, the task isn’t to assign blame and a good admin-side manner is required to prevent this. Remind the team the mission is to avoid making the same mistakes, not to point fingers. Perhaps you originally had fantastic buy-in but everyone got caught up in the wrong details. Was the problem operational? You’ll need to know.

    Second: Admit Mistakes and Ask for Feedback

    Once you’ve conducted your analysis, you’re ready to take it to the next step: humanizing past technical actions. Consider what the previous attempt might have been like for different teams and people. Remember what it was like when you rode the help desk, when you were sitting in the data center on a weekend or when you were working as a dev lead under an impossible deadline. Chances are you’ll remember the common frustration was external direction not taking people into account. DevOps success is primarily about people. Align your DevOps reboot with the humans on your team and the processes will follow.

    For instance, your company may have hired outside consultants to “rub a little DevOps on it,” and it’s possible they evangelized a lot of dogma. “Do exactly these things, this exact way, or you’ll fail at digital transformation,” they might have said. There may have even been FUD and frightening charts. Perhaps they said everything would be neatly wrapped up in six months and you’d achieve a high-performing, blended, and fully active nirvana within a year. “You could be the next Netflix!” You’ve probably heard this story several times by now, and if it’s happened to you, know you’re not alone.

    But your approach this time will be different because it will be yours. You will have noted sharp edges needing to be filed down. The broader team will be integral to conversations from the get-go. Internal champions won’t be under the influence of ballyhoo, fancy decks or hard sells. Your team will have a list of concerns but also possibilities reflecting a shared interest in modernizing operations. One look at salaries for job postings with “DevOps” in the skill set has likely piqued more interest from your team than a year ago.

    Open conversation has always been the hallmark of good forensic analysis. Express what you think went wrong the last time and encourage frankness. Acknowledge concerns—previous outcomes may have validated many of them. Your team will be looking for proof you’ve given thought to a process that might—in extreme circumstances—temporarily affect availability or lead to a security concern. Maintain an open invitation for everyone on the team to be a part of the conversation and hear their concerns. And wherever possible, lean toward person-to-person communication. You’re changing hearts and minds, not reviewing governance policy.

    Third: Unite Your Team by Confronting Obstacles Together

    Don’t perform a shotgun wedding between ops and dev. Administrators and developers are drawn to their technology foci for personal reasons and interests. One of the most cited reasons for unsuccessful DevOps plans is a directive to homogenize the team, followed by shock this didn’t work. Developers are attracted to and rewarded for innovation and building new things, while admins take pride in finding ways to migrate the mission-critical apps everyone forgets about onto new hosting platforms. They’re complementary, integrable engineers, but they’re not interchangeable cogs.

    Contrary to popular opinion, telling developers they’re going to carry a pager for escalation doesn’t magically improve code quality and can slow innovation. They may even quit, even in this chaotic economy. And telling ops they need to learn code patterns, git merge and dev toolchains will be an unwelcome distraction not related to keeping their business running or meeting their personal review goals. They also may quit.

    It might be helpful to share with your team the simple idea you embrace: Unfounded stories of friction between dev and ops aren’t about the teams. They’re usually someone else’s war story about the organization, technology or process obstacles dividing them. At its heart, DevOps is about clearing these obstacles, not replacing them with new ones.

    By 2020, you’ve likely met someone from a team who had an opportunity to work based on tenets of DevOps, and they likely have no intention of going back. They’ll tell you they built or modified interaction models and evolved their deployment methodology organically. They streamlined the way code is built, improved testing at the bench level, staging and production. Even some companies needing to maintain specific waterfall processes for business or regulatory reasons may benefit if the transition is organic and incorporates their specific needs.

    Fourth: Set Your Plan in Action

    The last step—and this time, hopefully, the easiest—is to set your plan in motion, especially if you’re doing so at a smaller scale with better instrumentation than before. Ops teams and developers are people of action. We like to research, test and discover, but we’re happiest when our work sees production and we have a positive impact on the business. And often with initial forays into DevOps, stymied progress is what makes teams give up. By tracking ops and business metrics together, all the stakeholders will be able to share a sense of progress toward the overall goals, even when you break a few things along the way. Think of it as fail fast insurance.

    For example, consider adding development metrics and business metrics alongside your traditional infrastructure data. Track rate of change, error rate over time, deployment events and PR requests to get a measure of release times. Share your application performance management (APM) metrics with the whole team—real-time user-to-app-code-to-infrastructure-to-resources data sparks insightful cross-team conversation. But you should also track metrics affected by ops quality, including visitor time on site, page abandons, service desk ticket rate and CSAT. You likely already have the data you need, but perhaps it’s siloed in different systems. If your dashboards combine data mirroring the mix of teams and infrastructure flying in formation, it’ll be much easier to identify issues, evolve your initial plan to suit your unique environment and improve overall DevOps collaboration.

    And this time, you’ll be able to see code check-ins, unit tests, builds, pipeline progress, deployment to staging and prod, and follow-through on performance, issues and anomalies. If the team gets nervous trying something new, you’ll have actionable data, the production feedback loops developers crave and common charts everyone agrees on. It’ll be easier to know your DevOps effort is working and to keep pushing forward as you address unexpected challenges.

    You’ll Know It When You See It

    I made a joke in a talk once that DevOps is a lot like being in a relationship: You kind of fall into it. You learn about it, adopt some of its practices and enjoy the experience when it works. You don’t set out to “get in love” and likewise don’t set out to “get in DevOps.” Rather, you find yourself in a situation developed with experience over time, and you wake up one day and realize, “Hey, we’re a DevOps shop!” That’s why you can’t buy it in a box, and nobody else’s will be like yours. It’s not about the technology, it’s about the humans working together to manage it.

    Maybe this is the best reason to give DevOps another shot. It didn’t spring from a consulting team as a framework to drive engagement or from a vendor with an appliance requiring admins to bend to arcane workflows. It came from people; from developers and administrators who fought the same operations challenges we all have and who wanted to share what they learned. And this is why, outside of a bit of time investment from your team, DevOps is free. It’s made to help, not to sell you anything.

  • Skills Every DevOps Professional Needs to Succeed

    Skills Every DevOps Professional Needs to Succeed

    At organizations of all sizes, DevOps is becoming immensely popular to harmonize operations between IT and software development units. The digital world is progressing rapidly, and with that, the need to upgrade skills has become a necessity.

    Based on research from Allied Market, the DevOps market worldwide revenue was $3.36 billion in 2017 and is forecasted to reach $9.4 billion by the year 2023. This has given rise to employing in-demand DevOps skills to streamline the operational business processes.

    Essential Skills in DevOps

    The current COVID-19 pandemic has brought about a significant increase in the demand for IT professionals who are well-versed with DevOps skills. Organizations operating remotely need engineers who can manage their ultra-advanced business automation software. For that reason, here are the must-have skills you need to work on to get an edge in your career within DevOps.

    Security Skills

    Acquiring security skills is imperative for DevOps engineers to comply with standard clean-code practices. Hackers are continually seeking new ways to breach security, and your system code is one way to attack your crucial data.

    Besides, to avoid data breach issues, you need to operate your system using a VPN and advanced security protocols. Moreover, learning to write secure code is essential as the operating system code is vulnerable to cyberattacks.

    Being well-versed in making secure code enables you to instigate a defense mechanism in your operating system, which further leads to lessening the chances of being hacked by unwanted malware attacks. Hence, DevOps engineers with proficient security skills are much more sought-after by companies looking to hire.

    Collaboration

    Becoming a well-equipped DevOps engineer requires you to master the skills of collaboration with IT operations and software development teams. The concept of working in association with other groups is vital to the practical implementation of the DevOps concept.

    An engineer who is adept at working in a cross-functional team will be more competent in managing DevOps processes seamlessly. Therefore, engineers must have to practice working in teams to gain an edge.

    Infrastructure Automation Tools

    In the tech industry, the concept of automation has revolutionized the traditional DevOps working system. Nowadays, manual tasks are replaced by automation tools to speed the development process.

    Getting a command on scripting languages such as Ruby, Bash, Python, Javascript and Node.js is essential for a seamless automation experience. Be it any stage of DevOps, an engineer of this field must be proficient enough to use it as necessary.

    Flexibility in Working Patterns

    DevOps requires an adaptable approach toward coding integration. Because coding is an ever-evolving process, an agile approach is necessary. To be a veteran engineer, the applicant must have the potential to keep learning how to integrate high-tech operations into the system code.

    Being flexible in your working patterns is now an essential skill. Additionally, engineers need to be able to work proficiently in each phase, including the integration of systems, testing codes and releasing to the deployment stage.

    Swift and Rational Decision-Making

    Working on code can be a daunting task to perform as it includes managing multiple technicalities simultaneously. In case you have to modify the previous system code, you need to make logical decisions on the spot to avoid any unwanted errors. The best DevOps engineer candidates possess the ability to make quick decisions to harmonize with ever-changing coding development practices.

    The Right Skills: Bottom Line

    Mastering DevOps skills is crucial to success in the highly fierce digital arena. Engineers need to ensure they continue to learn advanced technological frameworks and hone their expertise. Candidates with the right blend of technical and soft skills needed to tackle challenges are rare; however, today’s technological environment requires multi-faceted DevOps skills for greater success.

  • Upcoming Event: Operationalizing Kubernetes Virtual Summit

    Upcoming Event: Operationalizing Kubernetes Virtual Summit

    As Kubernetes keeps gaining traction in mainstream IT environments, the next big challenge IT teams will face is operationalizing the platform at scale. On Oct. 1, at 10 a.m. EDT, leading Kubernetes and cloud native communities will come together at the Operationalizing Kubernetes Virtual Summit to explore the tools and best practices you need in order to secure and manage one of the most powerful, yet complex IT platforms in the world.

    Today, organizations are managing not just one or two Kubernetes clusters, but entire fleets as their infrastructures increasingly depend on Kubernetes for automating deployment, scaling and operations of applications. As such, operationalizing Kubernetes is paramount to a successful environment.

    The free, interactive virtual conference brings Kubernetes technologists, DevOps and cloud-native experts together to share their knowledge and insights with the community. Attendees will find out how organizations such as AWS, Microsoft, CloudBees and many others are embracing containers and microservices environments.

    Operationalizing Kubernetes Virtual Summit features an exceptional lineup of industry leaders, including:

    • (Keynote speaker) James Strachan, distinguished engineer at CloudBees
    • (Keynote speaker) Priyanka Sharma, general manager at CNCF
    • (Keynote speaker) Liz Rice, vice president of open source engineering at Aqua Security
    • Tracy Miranda, director of open source community at CloudBees
    • Michelle Noorali, senior software engineer at Microsoft
    • John Willis, senior director of the Global Transformation Office at Red Hat
    • Bob Reselman, analyst at Accelerated Strategies Group
    • Prashanto Kochavara, director of product at Trilio
    • Pankaj Gupta, senior director of product marketing at Citrix

    The virtual environment features a lobby, an expo hall lined with booths full of downloadable resources and an auditorium where attendees can watch the sessions by industry experts. Attendees will have the opportunity to interact, in real time, with speakers and sponsors, and will have the chance to participate in contests to win incredible prizes.

    Stay tuned for speaker announcements and more summit details. For more information and to register, visit the Operationalizing Kubernetes Virtual Summit.

  • Government Has a DevOps Lesson for Private Sector

    Government Has a DevOps Lesson for Private Sector

    The missions of government organizations and DevOps are well-aligned, according to F5 system engineer Scott Van Kalken, who works with many organizations at various levels of government around Australia.

    That’s because government organizations provide services to the community, and DevOps is about providing services to a community of users.

    He sees more use of DevOps in the government sector than in corporations.

    Increasingly, DevOps is embedding security from the start of a project. “That’s really exciting for me,” he said, as it shows DevOps is working and allows faster iteration with security issues being picked up earlier.

    For example, the COVID-19 pandemic has resulted in more people working at home. That makes security considerations even more important than ever.

    All levels of government have seen massive increases in remote working capacity and functionality. Applying DevOps principles to security practices has allowed them to adapt rapidly to those increased levels of working from home.

    One large department took just three or four days to go from 1,000 to 20,000 people working from home. Van Kalken said this was possible partly because they “automate absolutely everything they are doing,” allowing rapid implementation of security policies. They quickly stood up additional cloud infrastructure with the right security settings by using DevOps practices. Similarly, DevOps teams can use APIs to easily and quickly apply security policies to SaaS applications.

    Cross-disciplinary Cooperation and Coordination

    One government department that Van Kalken is involved with was new to DevOps but very good at getting representatives of the relevant groups into the same room. They all focused on reaching the desired outcome with “no turf wars” and agreed that establishing appropriate security policies was part of that process.

    In his experience, the private sector tends to be more siloed, which can make it more difficult to make the right security-related choices from the outset.

    For government organizations with more mature DevOps practices, “it’s just an incremental ramp-up,” he said. The collaboration between the various functions makes a big difference to successful outcomes.

    So the role of the security organization changes from being akin to a nightclub bouncer (“No, you can’t”) to that of a partner in the delivery of services.

    The private sector can learn from this, Van Kalken suggested. Government organizations have a “laser-like alignment” on service delivery. In contrast, the differing and competing objectives of various departments or functions within corporations may be a handicap.

    Most organizations have adopted one of the published security frameworks, but project teams have the responsibility to decide how to comply with them. Government entities are different, he said, in that they must at a minimum meet the requirements of the Australian Government Information Security Manual (ISM). That leads to more alignment between departments and functions within the organization.

    DevOps and Security Hygiene

    From a more general security perspective, “governments are targeted in various ways” as they increasingly make services available online, he said.

    “Government is no different to every retailer, every bank, and so on,” in the sense that all the usual threats apply, said Van Kalken. But some players specifically attack government organizations because of the types of data held about individuals. Fortunately, DevOps practices assist in responding rapidly to changing situations.

    As a simple example, organizations can quickly deploy new policies to distributed firewalls by using DevOps principles including automation. That gives skilled individuals more time to deal with any exceptions that occur.

    Organizations can apply similar practices to improve security hygiene by more quickly rolling out new versions of commercial software.

    “That element of speed is something very new to the security space,” he said.

    Recommendations

    Van Kalken’s recommendations are:

    • Get all the right people—including security—together in the project team from the outset.
    • Ensure they all understand the objective.
    • “All swim in the same direction.”
    • Make sure everyone continues to work collaboratively.

    The rest “will just happen if you do these things,” he said.

  • Upcoming Event: GitLab Commit Virtual 2020

    Upcoming Event: GitLab Commit Virtual 2020

    For the first time ever, GitLab’s annual user conference will take place in a virtual environment on Aug. 26, bringing together DevOps luminaries from around the globe for a free, interactive learning experience.

    GitLab Commit Virtual is a 24-hour virtual event that provides attendees with the opportunity to join DevOps discussions, demos and presentations, and network with thought leaders from the industry’s top companies, such as Microsoft, Google, Hubspot, Forrester and many more.

    Speakers will showcase the power of community and share DevOps best practices through strategy and technology discussions, lessons learned, behind-the-scenes looks at the development life cycle and more.

    The agenda for GitLab Commit Virtual features a mix of topics, including technical sessions, live coding, deep-dives and case studies covering DevSecOps, containers, Kubernetes, CI/CD, open source, all-remote and more.

    The virtual environment features a lobby, an expo hall lined with booths full of downloadable resources and an auditorium where attendees can watch sessions by industry leaders.

    This year’s GitLab Commit features more than 40 sessions from some of the most brilliant DevOps experts, including:

    • “DevOps Works! Why Hasn’t Security Kept Up?,” a keynote session by Joni Klippert, StackHawk.
    • “DevSecOps in Government and Highly-Regulated Industries,” a keynote session by Nicolas Chaillan, U.S. Air Force.
    • “Real World DevOps,” by Abel Wang, Microsoft.
    • “Why Your Organization Should Embrace the Community Model,” by Karl Cardenas, State Farm.
    • “Getting Fuzzy: Blurring the Lines of Traditional QA and Security Testing,” by David DeSantos and Sam Kerr, GitLab.
    • “How the U.S. Army Cyber School Created ‘Courseware as Code’ with GitLab,” by Ben Allison, U.S. Army Cyber School.
    • “Measuring DevOps,” by Nathen Harvey and Dina Graves Portman, Google.
    • “How To Create an Equitable and Inclusive Culture That Transcends Physical Walls,” by Eimear Marrinan and Meaghan Williams, HubSpot.

    By visiting the expo hall, attendees will also be able to interact with sponsors, including AWS, Google Cloud, Lightstep, HashiCorp, Red Hat, VMWare Tanzu and WhiteSource.

    Attendees will get a deep dive into how enterprises are transforming DevOps at an organizational level and how they can implement similar practices in their own organization.

    To see the full agenda and to register, please visit the GitLab Commit Virtual website.