devopsy.kinsta.cloud

Category: Blogs

  • Claim to Fame

    Claim to Fame

  • Security Policy Management and Hybrid Cloud with Tufin

    Security Policy Management and Hybrid Cloud with Tufin

    In this TechStrong TV / DevOps Chats interview, Colby Dyess, director of cloud product management at Tufin, joins Mitch Ashley to discuss security policy management across hybrid cloud, multi-cloud and cloud-native security. Recorded in late 2020, Colby shares some experience from working with customers during the rapid migration to the cloud in 2020.

    The video and podcast audio of the conversation is below, followed by the transcript. Enjoy!

    TechStrong TV Video

    DevOps Chats Podcast Audio

    Transcript

    Mitch Ashley: I’m joined today by Colby Dyess who is director of cloud product management at Tufin. Welcome, Colby. Welcome, it’s good to be talking with you. Would you introduce yourself, tell us a little bit about you and of course, tell us about Tufin.

    Dyess: Yeah, well, you’ve got my name and my title, so I’m dialing in here from beautiful Southern New Hampshire where it’s fantastic weather. So, I’ve worked for Tufin Technologies, Tufin is really well known in the industry for providing security policy management, mostly in the organizations like the Global 2000 complex environments where you need to make changes to the network environment and you need to be able to do it quickly, safely, ideally you do it automatically and it’s secure. The Tufin product suite helps organizations do that and we’ve done that in the traditional space. Of course, our customers have adopted cloud, cloud native platforms, Kubernetes, and we’ve been taking these same capabilities for securing the environments and bringing them into the cloud, so no matter where you put your workloads, we can help you, and that’s mostly what we’ve been focused on.

    Ashley: Good stuff. Boy, the center for the universe for a lot of folks. Kinda speaking of that and just thinking about the timing of where we all are, you know, there’s a lot of statistics. I run an analyst firm as part of MediaOps organization called Accelerated Strategies Group. Anyway, we have a lot of data showing some of the acceleration that’s happened, both in digital transformation and also move to the cloud, just in the last six to nine months. I don’t think that’s news to anybody, right? I don’t know if you need data to say that, because it’s happening probably in most people’s organizations.

    Dyess: Right.

    Ashley: If I put on my security hat for a moment, we always get plenty of notice when we’re making changes and doing new projects and accelerating stuff—sarcasm—so, I’m sure there’s a lot of security folks who are scrambling still just to not only keep pace, but make sure we’re all doing a good job of securing environments that our developers are taking this into, making sure we’re understanding the services we might be using now that we weren’t before, cloud services that we’ve been in. I’m sure you’ve seen a ton of that happening with your customers.

    Dyess: Yeah. It’s no surprise. Organizations have been moving to public cloud environments for a long, long time, at least, technically, for the past 15 years, they’ve been doing it, but it hasn’t always been sanctioned, right? Let’s say over the past five or eight years, organizations have really begun to intentionally adopt the cloud. And now this year, of course, everybody’s moved to the cloud about as quickly as they could.

    What we’re seeing, at least what I’ve seen a lot is, security is now scrambling to try and get ahold of some visibility—what’s really going on inside these cloud environments—and trying to put some sort of guardrails around the services that the Dev teams are using. That’s a real challenge because they’ve been focused so much on how to secure most of the on prem environment or use firewalls to protect the cloud space, but now they realize they’ve got to go a bit deeper, because the threats are pretty real out there and they’re really dynamic. And if you’re not sure how to secure the cloud environment, you’re going to leave yourself open to threats.

    So, security has really been spending a lot of time trying to learn more about cloud and cloud native security controls. We spend a lot of time helping customers figure out the difference between cloud native security controls and on prem stuff and then how to combine them so they can be assured it’s all secured. We see that a lot, yeah.

    Ashley: Well, you know, I mean, we’ve all been doing firewalls and intrusion prevention and access controls and the list goes on.

    Dyess: Yeah.

    Ashley: So, the topics aren’t new, but the environments are different and the services. It’s not like you can go into the cloud—no, let’s use all the things I’m normally using in my on prem environment. Maybe you can get some software versions of that. Sometimes it’s just better to use because it’s better integrated, you spend less time making the environment work by using what’s provided by the cloud provider.

    Dyess: Yeah. That pattern is the same everywhere. I’ve seen that you’re gonna go to a new environment, you wanna take some of the things that have worked for you in the past and carry them forward. And a lot of times, that makes sense as you try to move quickly into the cloud. If you’re not familiar with cloud native security controls, you probably think, “I’ll just use firewalls and the process for managing firewalls in the cloud.” And there are a lot of options to do that, a lot of the traditional vendors in that space have tried to make a pivot to offer their same services, same capabilities in the cloud environment. So, it’s no surprise that we see a ton of that.

    At the same time, those processes around managing all that stuff still takes too long. If you moved to the cloud, you went there for agility, right? You want to rapidly build applications and get them out into the market as quickly as possible. But if you’ve got to fill out a ticket to get a firewall changed and it takes three days for that stuff to be processed, you’re no longer as agile as you used to be when you could twiddle a little configuration in a Terraform template, redeploy, and—poof, you’re up and running all over again. That’s something that security teams—

    Ashley: If you take another two days to answer that ticket, you’re probably gonna have a fourth after your third _____ while you’re add it to the mix, right? Some developers are gonna be like, “I’m outta here, let me go set up the next environment.”

    Dyess: Yeah, it’s too difficult. You can’t wait. You don’t want to see shadow IT any longer, because IT was taking too long to respond, but you’ve got to respect that IT’s there, the security site of IT is just really trying to help protect the business.

    But you know, you also saw Amazon and AWS, they both announced their own firewalls, right? Azure did a little bit back and AWS just did within the past month. And I think that’s really just paying homage to the fact that those are really good technologies. Firewall technologies really are good stuff and it’s more than security groups or NSGs, it goes beyond that, and the businesses really need these. These do address customer problems. So, we’re seeing a lot of folks ask about how do they adopt those new to the cloud provider, new technology, and how do they integrate them into the very agile processes? And I expect we’ll see a lot more of that.

    In fact, what we are finding that we do often is try to help organizations see how they can get the most value out of the cloud native security controls, because these cloud environments are really, they’re pretty solid. And like you pointed out, the security controls are integrated into the services. So, it makes a lot of sense to use the services, they’re there to protect your assets and they’re so integrated in the services, you really should be trying to use them, but it’s a learning curve for security, so it means a lot to try and help them get the visibility and then start to affect control over that, so that they don’t have to slow down the rest of the business, swapping out, let’s say, a cloud native control with a legacy control [Cross talk].

    Ashley: Mm-hmm. It is that tradeoff, and I think that’s one of those where it’s sort of, I think it puts security teams in a position where, are we gonna stick to our guns of this is the environment we’re gonna have consistent across all of the environments we operate in, or for sake of speed but not sacrificing security, maybe we do look at some other options and can those integrate into the monitoring and management systems as opposed to using the same firewall in every environment that we take with us there, right?

    Dyess: Yeah, yeah.

    Ashley: Easier said than done. I appreciate it’s not an easy job.

    Dyess: Right. You know, whether you decide to use the cloud native security controls or use the traditional kinda controls, the virtualized versions of those or a combination of them, one thing I think we’re sharing is, we see a lot of conversations around how—which technologies to adopt and then how to actually manage those technologies.

    And from my point of view, it seems like we’re almost too focused on getting down into the weeds about the specific security control and, as a security person, I think it makes a lot of sense to step back a little bit and try and focus on what’s the overall security policy. Instead of thinking what firewall should I use, should I use one from the cloud or should I use from my traditional vendor, maybe a better question to help organizations remain agile is for security to be able to focus on what the security policies are, what the guardrails should be, and then begin to get the practice of checking cloud environments against those guardrails, against these policies as part of your CI/CD pipeline, the whole buzzword of shift left.

    That’s a real thing, right? That’s really important. That security can focus on defining security policies where they have the strength, but the actual implementation of enforcing the security policy is probably handled by the cloud operations or whoever actually twiddles the bits on the security controls. Like, if you can marry those two things together and you can do it in the CI/CD pipeline, then that’s a huge win.

    We’ve seen organizations move a lot faster because security focuses on what they do and they get it codified in a way that can play in a pipeline, and now the app teams, they can make changes to an application or a cloud Ops can change the configuration of an environment and get an alert saying it doesn’t comply with the security policy. That’s great. To step away from choosing which sort of security device you want to use and focus on do things comply with the security policy? That’s a major shift, and one that seems to be really hard for organizations to do. I think to kinda get away from security being hands on with the control and now focused on the policy—it’s trust but verify, I think.

    Ashley: [Laughter] Back to that old saying, right?

    Dyess: Yeah.

    Ashley: You know, in a way, it also comes down—you know, we’re used to, let’s first take an inventory and make sure we know what’s all out there that we’re trying to secure.

    Dyess: Sure, of course.

    Ashley: But it’s equally just as important to have, whether it’s change management practices or software that can help you with notifying when changes occur or understanding, so when a change occurs, how does that map back to policies that we have in place and are we still in alignment, are there gaps that we have to take care of? Because the environment isn’t—it isn’t an environment we control everything in any more. It changes by itself, because other people are changing it along with us. So, it seems like it’s a more dynamic environment than maybe what we had 10 years ago, if you reflect back a bit.

    Dyess: Intentionally more dynamic, right? Businesses have to move faster, we also have to react more quickly to customer demand or competitive threats or whatever. So, the fact that we’ve got these dynamic environments is just a reflection of what we actually needed to have built, anyway. And now, we need to find a way to incorporate that back into our regular practices.

    So, you made the comment about being able to track what’s changed and when and all that, but if you adopt more of an infrastructure as code model, you already have that. You don’t need a CMDB—maybe you do, but you don’t have to have a CMDB in place when you could go back to your Git logs and see, oh, here’s the pull request for the change that we made that allowed for this security group to be open or for this Azure firewall to have this particular rule. You can actually see that information, but these are, on the security side, these are new tools. As a security person, when was the last time you looked into a Git repo to see what the configurations were? [Laughter]

    Ashley: The repo—right, GitOps and security, right?

    Dyess: Right. Right, but we’ve got to get somewhere around there, as a group collectively, whether we’re writing the code or we’re managing the operations or we’re managing the security collectively, we’ve got to be able to collaborate and use these tools that I can’t say are merging, they’ve been around a long time. Terraform and Helm, Ansible, Chef, Puppet, the whole bit—these things have been around for a while, but to incorporate them now into our security practices is a pretty big leap for folks.

    Ashley: Mm-hmm.

    Dyess: So, we really try to encourage that the security team gets the visibility that they need, that’s the first thing, as you pointed out, right? You absolutely need to understand what’s deployed, what’s talking to what and whether or not things are properly segmented.

    You’ve got to first get that visibility, but I think before you start jumping into let’s throw a bunch of other control points in there, consider what resources are there and how can you, on the security side, participate in automation, participate in these flows that your CloudOps, DevOps, SRE, whomever had set up. Because there’s a really good opportunity now on security to be part of this agile process and to allow the business to be secure, but to do so in a way that won’t break the developer productivity.

    Ashley: Mm-hmm.

    Dyess: And that’s, it’s uncomfortable, because it’s a big change, but it’s a change that I know it can be done successfully. We’ve worked with companies that have done that, you know, make the conscious decision.

    Ashley: I almost wish we had stepped back and redefined shift left, because if, you know, I were king of the world for a nanosecond, I would think about it as, it’s not just about getting security people to work with the software teams earlier in the life cycle of software—yes, it’s that. But think about it this way of, the old world was, set the policies and then how do we implement the enforcement mechanisms, right, to make sure that those are being followed.

    Dyess: Mm-hmm.

    Ashley: I think in the world we’re in now, it’s, security people are, if you were gonna set up a security practice in an organization today, what I would do is, let’s start with how software is created, let’s work with the team about how the entire tool chain is set up, how that flow happens, both for application software, but also for the infrastructure and how that gets created where we’re talking about test environments and production environments and maybe you’re stepping into infrastructure as code if it really, truly is kinda dynamic Terraform or whatever kind of environment.

    But start there, because if you understand how that’s done, now you know how to secure it. You know how to work with teams to help them secure it, then the next layer would be getting into the software architecture itself around microservices and things that are more porous than we’re used to, kinda the hard outer shell of monolith applications of the past.

    That, to me, is the mental shift, the big mental shift for a security team to not necessarily be an expert at all that stuff, but understanding that’s what you’re really securing now.

    Dyess: So, two things that stand out, like responses I can imagine people having right now and that’s, I don’t have time to go and learn all that stuff. [Laughter] I’ve already got 20 other tickets for all high priority things. I’ve gotta get on that right now, so I can’t go and learn all that stuff. Valid, that’s definitely the case in a lot of organizations, yeah.

    And another problem related to this is security teams who maybe do want to know, maybe have some time to do that, but struggle that the application teams themselves don’t even know what makes up the application and what connections do they need. So, even the folks who you think would know because they built it, you’d think they would know the answers to some of these questions, but it turns out that they don’t—in a shockingly large number of scenarios, that’s the case.

    Ashley: Mm-hmm.

    Dyess: And so, if you’re gonna shift left, you’ve got to address not just the problem of the security team getting visibility in this—or maybe, actually, it’s the same thing. The application teams have to be able to come to the table to say, “This is what the application looks like. Here’s how it’s put together. Here are the resources it needs and here are the services that will rely upon it.”

    Ashley: Mm-hmm.

    Dyess: And so, if application groups can come to the table with that, then a security team can look at it usually very quickly, look at a map and say, oh, I can see where it needs to be segmented this way. I can see where he’s a resource that has too close of an access to PII, PCI, right? And so, that conversation could start a lot sooner if it’s part of your normal bill practices, you were generating these views, you had some way to produce an item that a network team or security team could look at, right? They don’t need to look at the source code, they need to look at your network topology, they need to understand what you’re connecting to.

    So, if you can bridge that gap, that goes a long way. So, to your point, it’s not just like, “I just need to check if it doesn’t comply with the policy.” Sometimes, it’s even just trying to define the policy at the outset.

    Ashley: Yeah, on what you’re trying to secure.

    Dyess: Yeah, but also, while security never seems to get the heads up about the things that are coming down, the joke that you made at the beginning, it’s also the case that when the application team is building something that they don’t really have all the rules, they’re not sure what all the restrictions are, and there are certainly plenty of guardrails, guidelines that they could have if you give them access that they could pull from an API to do their own checks.

    So, you know, there’s a model. We’ve done this before in the industry, back when I wrote code, we had a separate QA team, so we’d write code, we’d do a little bit of testing, but just enough, frankly, to get us through the build, right? And then we throw it over the wall and it went over to QA. And then thankfully, our development practices matured to a point where we realize we actually need to integrate testing as part of what we do. So, as developers, we had to own some of that testing, some more of the testing, but also importantly, the test team got involved earlier in the application life cycle, the model you were talking about. So, the QA teams could come in and learn a bit more and begin to set up some of the additional tests and participate in the build process, so what they did showed up in NMake.

    So, I think security is on a path like that as well. I think security, instead of app teams just throwing it over the wall and asking security to figure out how to lock it all down, I think we’re going to, and in some places, some customers for sure are moving to a place where security is part of the process earlier, and if they can say, “Here’s some of the tests,” so now the guardrails, they can contribute some of that and they can go into this build process, then now you’ve really begun to get that shift left.

    But I know this can happen. We’ve seen it happen before. Now QA is just integral to what we do. You can’t even imagine putting a product out without some part of QA being part of the build process and tests happening really early on, test planning happening early on. I imagine security just going in that same sort of loop.

    Ashley: Yeah, of course Tufin’s been in this space for a while, has built up, I’m assuming, a body of knowledge about this. If you were gonna advise maybe a new customer or an existing customer on—okay, we’re always playing catch up, we’re really playing catch up now with how much more cloud services that organizations are using in such a short period of time, what are some of the sort of best practices or recommendations of, “Here’s to sort of get the first thing established, here’s the next thing to work on, here’s the next thing to work on.”

    Dyess: Yeah.

    Ashley: Any suggestions about that?

    Dyess: Sure. We have this whole crawl, walk, run methodology, and it’s designed to help organizations take these small steps towards getting to really secured environments. And the first step right away is just to get visibility, which is kind of a “no, duh” statement, but it’s actually one of the big problems that orgs have. You’ve got to be able to see what’s deployed inside your cloud, what’s deployed inside your cluster, and which resources are communicating with each other, where are the dependencies.

    So, understanding that is a really major first step. It’s true for the application teams, but for the security, it’s to know are things properly segmented, where are the biggest risks? So, getting that awareness, that’s really the crawl phase. And in the walk phase, that’s where you take what you’ve learned about what’s deployed, what talks to what, and whether or not things are segmented properly and then you begin to isolate. Here are specific accounts that we need to tackle or here are clusters that we need to tackle—like, hone in on the higher priority items and begin to define a security policy for those cloud native environments.

    And as you develop the cloud native policies, which you then share with the application teams or the cloud operators, whoever’s responsible for configuring it. As you develop that sort of, that skill, you’ve gotta get to the run phase, and the run phase is when you begin to automate this. You automate generating security policies, you automate validating security policies, but at the very beginning, where most organizations are at right now is, first get the visibility and then the second step of defining a security policy. Not defining what is my security group definition, not defining what is my AWS firewall definition, but what is my security policy? What are the rules that should govern access to applications, assets, resources of certain categories? Those are two big steps to take right away.

    Ashley: I think that’s some great advice. I’m curious, any thoughts as we—I think we all want to turn the page on 2020 and kinda get to 2021, and hopefully, we’re looking at a different kind of a year. But one of the things about 2020 is, we’re not gonna go back, I don’t think. We’re not gonna go back to, let’s rewind to January and start working in that environment again, right? Everything is changed with remote work or how much we’re using the cloud.

    What are some things that you’re anticipating for 2021 as you look forward in the next 6 to 12 months. Do you kinda think it will be topics maybe not as talked about yet but will be more topical in 2021? I’m just kinda asking you—

    Dyess: Are you asking for predictions of 2021?

    Ashley: You know, I don’t see it, but I’m pretty sure, there might be a crystal ball right behind your chair, just look back a little bit there and kinda check back. [Laughter]

    Dyess: [Laughter] Well, I think, given the maturity of the market adoption of public cloud environments, I think we’re going to see more security teams getting their arms around how to help in securing these cloud environments without necessarily always relying on the traditional devices. We’re already starting to see that even now. So, I think we’ll see more of the cloud native security control adoption. I know organizations have seen the benefits of doing that to lower cost of operations, just total lower cost of ownership, plus the benefit of being able to say when there’s a problem, I can call my cloud vendor, I don’t have to worry about vendors poking at each other. So, I think we’ll see more of that.

    I think it’s the Kubernetes space that’s probably the most interesting, because it’s the least well known for most folks on the security side.

    Ashley: Mm-hmm.

    Dyess: So, I’d say maybe over the past year, there’s been a lot of emphasis, just like with cloud, slap a firewall on it and we’ll solve the problems of micro-segmentation later, but later is gonna happen real quick, and I’d expect in 2021, you’ll see securities start to get more involved in getting visibility into the clusters and then looking to define the security policies.

    And not—again, not to try and define the policy of an individual cluster, but just the general rules, because there’s no way we can keep up with what will really be thousands of services running inside of a cluster.

    Ashley: Yeah.

    Dyess: So, we’ll see that. I think we’ll see more organizations at the security side have to deal with the scale and the rate of change and begin to participate in the automation processes that the Dev teams are using to manage it.

    Ashley: Maybe that’s something we’ll hear more frequently. I wouldn’t be surprised if the—let’s think of it as cloud native security, not just as security, sort of think about it as one of you architectural approaches to how you do security.

    Dyess: Cloud native. The native controls of the cloud provider—yeah, that’s a big shift for folks, I think.

    Ashley: It is. We’ll see if something like that happens. And I think the things you said made a lot of sense. Well, it’s been great talking with you, it’s the first chance you and I have had to talk before, and—

    Dyess: Yeah, it was good to talk to you, Mitch.

    Ashley: – a lot of fun. Tell us a little bit about where folks can learn more about Tufin.

    Dyess: Yeah, of course, you can go to Tufin.com, that’s T-U-F-I-N dot com. On the cloud side, like what’s really relevant to what we’re doing here, we’ve got a lot of resources at Tufin.com/try-securecloud. It’s cloud native security controls. It’s really designed to help you get visibility and control the cloud native security components. Great stuff there, free to use product. There’s a great trial for people to give a go. Tufin.com would be the place.

    Ashley: Great. Perfect. Thanks. Well, we wish you the best and a even better 2021, we’ll look forward to that.

    Dyess: Yeah. From your lips, man.

    Ashley: [Laughter]

    Dyess: Good luck in 2021, everybody.

    Ashley: There you go. Hang onto that, hang onto that. Alright, well, take care. It was very nice talking with you, Colby—Colby Dyess from Tufin.

  • AppDynamics Survey Reveals High IT Stress

    AppDynamics Survey Reveals High IT Stress

    A global survey published today by AppDynamics, a unit of Cisco, suggests the last year took a substantial toll on IT teams at a time when many organizations either launched or accelerated digital business transformation initiatives.

    The survey, of 1,050 IT professionals in organizations with revenue of more than $500 million, finds organizations, on average, implemented digital business transformation initiatives three times faster in 2020 than they did in 2019 in response to the economic downturn brought on by the COVID-19 pandemic. That increased level of activity, however, appears to have come at a significant cost. The survey found 89% of respondents felt they are under immense pressure at work, with 84% admitting to having difficulty switching off after work.

    The survey also found stress levels are, not surprisingly, rising as well, with 81% of respondents experiencing increased frustration and 63% conflicting more with colleagues.

    The root cause of these issues cited most often include new sets of priorities and challenges (80%), technology sprawl and a patchwork of legacy and cloud technologies (78%), acceleration to cloud computing (77%) and multiple, disconnected monitoring solutions (74%).

    A full 85% also identified cutting through noise generated by increasing volumes of data to identify root causes of performance issues will represent a significant challenge in the year ahead. A total of 92% also noted the ability to link technology performance to business outcomes will be what’s really important to delivering on innovation goals over the next year.

    Three-quarters (75%) of respondents said they are already struggling to manage overwhelming “data noise.” Nearly three-quarters (73%) also noted they fear the inability to link IT performance with business performance will be detrimental to their business in 2021. Three-quarters (75%) of respondents also noted their organization needs to connect full-stack observability to business outcomes within 12 months in order to remain competitive. Two-thirds of respondents (66%), however, said right now they do not have the resources and support they need.

    AppDynamics regional CTO Gregg Ostrowski said the survey makes it clear that existing approaches to merely monitoring IT platforms are not going to be sufficient, at a time when observability across the full stack of IT platforms being employed is now absolutely essential. Rather than convening war rooms where IT teams responsible for different platforms compare reports in the hopes of identifying the root cause of an issue, Ostrowski said modern observability platforms provide a holistic view of IT environments that IT teams need to proactively resolve issues before they impact the business.

    That level of visibility will also play a crucial role in reducing the stress levels of IT teams that, in many cases, are now in danger of suffering from burnout, Ostrowski added. Of course, the more fatigued an IT team is, the more likely it is mistakes will be made.

    It’s not clear to what degree IT teams are embracing observability as a core IT management concept. The AppDynamics survey noted that 71% of respondents are wary of misleading claims from vendors who are re-labelling monitoring tools as observability platforms. Regardless of how observability is achieved, the general consensus remains: whatever observability means within the context of IT, most organizations lack it.

  • Test Automation University, the World’s Largest Free Online Testing Education Platform, Crosses 75,000 Student Mark

    Quickly becoming the industry standard for the software testing community, Test Automation University enables hiring managers to fill key roles and engineers to upskill and advance their careers

    SAN MATEO, Calif., February 23, 2021 — Applitools, provider of the next generation test automation platform powered by Visual AI and Ultrafast Test Cloud, today announced Test Automation University (TAU) has surpassed 75,000 students. This marks the single largest free online education community for test automation in the world. Since announcing its first course in January 2019, the program’s 39 renowned instructors have produced a curriculum of more than 50 courses and 12 unique learning paths.

    To join Test Automation University and start learning for free, visit https://testautomationu.applitools.com/

    As job insecurity became a reality for many due to COVID-19, new and seasoned engineers went looking to develop new skill sets and expand their careers. In fact, a recent study found that at least 80% percent of respondents experienced some degree of worry about job security due to the pandemic. TAU has quickly become the industry standard for the testing community, enabling hiring managers to fill key roles and new engineers to land their first job.

    “Recently we hired an associate tester who had no previous testing experience, but his passion and accreditation from Test Automation University landed him the job,” said Suman Bala, QA Lead at Sky.

    “Applitools has a great thing going, from their industry-leading platform to their Test Automation University that has landed me a job as an Automation Engineer!” said Adam Wood, Automation Engineer at ProAct International.

    Created as an expert-driven collection of free educational training resources for people interested in developing test automation skills, TAU helps people of all skill levels advance their careers. The instructors of TAU help guide students on their journey through the 50-plus courses available that cover web, API, mobile, Visual AI, and codeless automation frameworks and provide training in multiple programming languages, such as Java, JavaScript, C#, Python, Ruby and Swift.

    “The growth of Test Automation University has been astonishing. It’s been such a joy to witness the remarkable outcomes for our students,” said Angie Jones, Senior Director of Test Automation University, and instructor of five courses ranging from ‘Java Programming‘ to ‘Selenium Webdriver‘ to ‘Automated Visual Testing: a Fast Path to Test Automation Success‘ “During a very difficult time for many, the Test Automation University community grew stronger and generated inspiring stories of success and collaboration as a result of these courses.”

    Test Automation University is sponsored by Applitools. Contact us at (https://applitools.com/contact/sales) to learn more about modern software testing via Visual AI. 

    About Applitools

    Applitools delivers the next generation test automation platform powered by Visual AI and Ultrafast Test Cloud. We enable engineering teams to release high quality web and mobile apps at incredible speed and at a reduced cost.

    Applitools Visual AI modernizes important test automation use cases — Functional Testing, Visual Testing, Web and Mobile UI/UX Testing, Cross Browser Testing, Responsive Web Design Testing, Cross Device Testing, PDF Testing, Accessibility Testing and Compliance Testing — to transform the way organizations deliver innovation at the speed of CI/CD at a significantly lower Total Cost of Ownership (TCO).

    Hundreds of companies from verticals such as Tech, Banking, Insurance, Retail, Pharma, and Publishing — including 50 of the Fortune 100 — use Applitools to deliver the best possible digital experiences to millions of customers on any device and browser, and across every screen size and operating system.

    Applitools is headquartered in San Mateo, California, with an R&D center in Tel Aviv, Israel. For more information, please visit applitools.com.

     

  • Top 4 Challenges for Developer Teams in 2021

    Top 4 Challenges for Developer Teams in 2021

    As remote work continues into 2021, developer teams are still navigating the new landscape for working across distributed teams and how this new way of working affects product delivery. In particular, there are several key challenges that every developer must face this year, including adapting to new tools and workflows internally, balancing the prioritization of keep-the-lights-on initiatives with product initiatives, and understanding how to address emerging customer challenges.

    As developer teams are responsible for keeping both internal systems healthy and maintaining service uptime for customers, addressing these issues and implementing the strategies below will help ensure better delivery, easier deployment of application and software solutions and improved internal communication processes.

    #1 Get Better at Digital Experience Monitoring

    For businesses to survive in this current environment, neglecting to monitor a user’s digital experience across their life cycle can mean losing business to a competitor. At a bare minimum, developer teams must ensure that their application’s basic infrastructure is sound. This means monitoring key metrics like CPU load, memory load, memory used, disk space, queue lengths, API uptime or error codes returned.

    For a fuller user experience, developer teams should also monitor things like page or app load times, drop-off points in an app and crash logs. The third level of digital experience monitoring is keeping tabs on what your users are doing, such as skipping the onboarding flow, inviting friends to your app, posting content or how much total time they’re spending within the app. Robust digital experience monitoring will ensure that you are constantly measuring the quality of your users’ experience and making improvements along the way.

    #2 Expand Where and How You Gather User Feedback

    Beyond initial user monitoring, teams should continuously collect feedback to improve features and fix issues that might not have been discovered during testing. One natural way to do this is to aggregate user reviews and support questions to find common themes that may help product teams prioritize future releases. It is also critical to think outside of the box in terms of where and how feedback is collected. Teams can also collect feedback in other ways, such as conducting data analysis and user research sessions or having direct conversations with customers. Giving key beta users early access to a new release can also help developer teams understand whether their application is meeting users’ needs, and whether it is intuitive to use.

    Ultimately, by engaging with customers in extensive and real conversations, teams may learn where there are disconnects between users and the products, and what they can do to bridge this gap. Once the information is collected, teams should then prioritize what needs to be done first by ranking requests by frequency received, financial value of fixing the issue, strategic importance to the overall organization and engineering effort.

    #3 Prioritize Low-Code and Customer Self-Service Models

    Removing barriers to entry for customers is especially critical right now, as developers consider changing user needs, tighter budgets and fewer personnel to implement new code. Customers just don’t have time for entire enterprise sales and onboarding cycles to implement new solutions, so requiring less code is a great way to introduce a more self-service model. This model is also great for non-developers to implement and ensures that customers (whether fellow developers or even someone on a marketing operations or web team) can easily integrate new tools and software into their existing solutions. This is not only critical for those without a more technical background, but also valuable for time-strapped product teams who want to buy, versus build, a new feature.

    #4 Codify Hiring to Help Developer Teams Succeed

    During the pandemic, both large companies and small startups have pivoted significantly in the way they recruit and onboard engineering, DevOps and technical roles. Leaders of developer teams need to codify their hiring plans and put in place remote work strategies, especially with the hybrid working model that combines remote personnel with in-office staff.

    When hiring for remote teams, consider where individuals are located for both development and customer support purposes. Once you determine these core hubs, there should be guidelines in place to reduce the need for team members to work across major time zone differences. This can mean having a core software team in a centralized region that also overlaps with a major customer base, or having an engineering team located in a similar time zone to the design team for easier communication.

    Overall, the needs of each developer team will differ depending on the size of the company and the industry it serves. That’s why it’s critically important to adapt your systems and infrastructure accordingly. Furthermore, listening to and processing user feedback, building products that meet ever-changing customer demands and continuing to focus on team communications will help ensure long-term success in a post-pandemic world.

  • Survey: The State of Database DevOps

    Survey: The State of Database DevOps

    Enterprises are undergoing rapid changes. Throughout the past year, companies have been pressed to learn a diversified set of technologies and methods to remain agile in a changing economy. In this digital-first world, data plays a heightened role; in tandem, so does the delivery of data and the persistence of the database layer itself.

    Applying DevOps principles and automation throughout the software life cycle is critical to maintaining a high level of efficiency. As with application development, databases are not immune to the DevOps takeover. Database DevOps is a discipline that considers the processes used to automate database changes and deployments — a field growing in mindshare as databases diversify.

    Seventy percent of companies now use more than one database in their stack. Many organizations now use a blend of on-premises and cloud databases. Styles are diverging, too, as non-relational databases like NoSQL gain favor, and new open-source databases emerge to fit niche circumstances. All of this means database operators may require an increased emphasis on database DevOps to handle additional complexity.

    The 2021 State of Database DevOps report, conducted by Redgate, surveyed 3,200 database professionals on the general state of their DevOps adoption. The survey also inquired about database change automation and deployment and underlying database technologies. Now, five years in, the study continues to reveal shifts in practices across industries.

    Below, we’ll review the report’s main takeaways to see how companies implement database DevOps in practice.

    DevOps Adoption Increases Across Projects

    To meet pressing digital innovation needs, DevOps has surged in importance across all industries — 74% of organizations have adopted some form of DevOps, and 26% of respondents reported applying DevOps practices across all projects — a significant uptick from previous years. The report acknowledges a slight increase in DevOps adoption among larger company sizes.

    So, which DevOps practices are companies employing the most? Well, in terms of DevOps for application development, the majority of organizations (50% or above) have adopted version control, automated builds, monitoring, automated unit tests, static code analysis and semi-automated deployments in production. Only 41% of organizations surveyed have fully automated deployments to production. These methods can be viewed as a basic benchmark for modern DevOps.

    The study demonstrated that in most organizations, DevOps is a communal undertaking. More respondents reported adopting a community of practice, rather than relying on individual decision makers, to disseminate DevOps strategies and direct planning. According to the report, a community of practice is a group of people that “makes decisions, provides recommendations, or is consulted.”

    Lack of Skills Tops DevOps Obstacles

    The pressure is on engineers to produce to meet digital transformation demands. However, organizations experiencing a developer drought may not possess the talent to introduce DevOps practices. It’s no surprise that the common obstacle hindering DevOps adoption was a “lack of appropriate skills in the team.”

    Other cultural barriers to DevOps adoption include disruption of existing workflows and a lack of alignment between teams. Interestingly, a lack of executive support was cited as the lowest hurdle to DevOps adoption, indicating universal consensus on DevOps goals. If we consider what technical barriers prevent improved software delivery and operations, 41% noted insufficient automation in release processes and 39% expressed hindrances due to legacy code.

    Continuous Delivery For Databases Increases

    Database DevOps appears to be growing in production use too. For the purpose of this study, Database DevOps is defined as “automating the delivery of database changes.” According to the report, 51% of respondents are already automating some parts of their database deployment process.

    Though growing year after year, database DevOps is nowhere near ubiquitous. Compared to DevOps in application development, database DevOps has lower overall use. For example, only 36% are implementing automated builds. And, only 22% adopt continuous delivery (CD) for all databases. Nevertheless, this could quickly change, though, as 80% of respondents are working to implement CD for database changes or have already implemented it.

    Setting up a CD process for database changes could increase overall software delivery speed. The top two drivers for adopting database automation are increasing the speed of database changes and freeing up time for other work. The third top reason, minimizing application downtime, rose in rank this year — which makes sense, as the desire to create more reliable systems is an ever-present concern.

    However, to reap these rewards, organizations must overcome some significant challenges, like synchronizing application and database changes and maintaining high speeds for database automation, among other concerns.

    Organizations Adopt Hybridized Database Approaches

    Companies increasingly use a mix of different database technologies and styles. We also see an increase in cloud and hybrid database estates.

    In terms of database styles, relational databases still make up the majority of market share — 98% of respondents have at least one relational database. However, non-relational databases, like NoSQL, are gaining popularity. Forty-seven percent of database professionals have a NoSQL database in their enterprise. Interestingly, only 2% use non-relational databases exclusively, indicating it’s a niche use case.

    Enterprises are now using more databases than ever before. Seventy percent of database professionals reported having more than one database in their stack. This figure rose nearly 10% since last year. Database types are multiplying too — 45% have more than one type of database. In terms of database management systems, Microsoft SQL Server holds the most use, at an 82% usage rate. Others like MySQL, Oracle, PostgreSQL, and MongoDB trail behind.

    Enterprises are also increasing their use of cloud and hybrid database deployment models. Eighty percent of respondents host a cloud database, and 65% report a mix of cloud and on-premises estate.

    One possible explanation for the diversified database effect is an increase in public cloud provider usage, combined with the rise of multicloud strategies. Database options are increasing as well — many free, open-source databases can cater to unique project needs.

    This “polygot persistence” could also simply be a natural occurrence within large enterprises supporting many application nuances. As Martin Fowler describes, “… any decent sized enterprise will have a variety of different data storage technologies for different kinds of data.”

    Quality Database Ops = Quality Software Performance

    In summary, non-relational databases are gaining steam, cloud and hybrid database models are becoming more common, and large organizations are increasingly using multiple database types. The landscape is forecasted to diversify further, meaning database DevOps is stepping up to manage this complexity.

    The report indicates a correlation between quality database Ops and overall software quality, noting that organizations that release more frequently typically deploy database changes in much less time. To achieve these goals, “… the next area for database DevOps is in the data engineering and analytics space,” writes Pramod Sadalage, director, data & DevOps, ThoughtWorks.

    While it’s important to take a vendor-endorsed study with a grain of salt, it’s safe to say we will likely see more interest in database DevOps, especially as DevOps themes continue to permeate through the entire spectrum of software development and delivery.

    For more information, you can download The State of Database DevOps report behind an email gate here.

  • Ambassador Insights: Cloud-Native

    Ambassador Insights: Cloud-Native

    Cloud-native is a methodology and a mindset that’s been gaining traction in the DevOps and application development space as more organizations look to leverage the benefits of cloud infrastructure, including scalability. As with many other topics in the DevOps space, however, cloud-native isn’t easily definable; rather, it is loosely described by the technologies it utilizes, including containers and Kubernetes.

    In our second episode of Ambassador Insights, featuring DevOps Institute ambassadors Leonardo Murillo, CTO of Qwinix Technologies; Tracy Bannon, senior principal and DevOps strategic advisor and software architect at MITRE; and Pawel Piwosz, lead system engineer at EPAM Systems, we delve into what it means to be cloud-native, look at some of the cloud-native technologies helping shape the landscape and address the security aspects of cloud-native applications and infrastructures.

    The video is below, followed by a transcript of our conversation. Enjoy!

    Transcript

    Charlene O’Hanlon: Welcome back to TechStrong TV. I’m Charlene O’Hanlon, and I am here with another episode of the DevOps Institute Ambassador Insights Panel Discussion. I’m so excited to have these on a monthly basis with some very, very smart people who also happen to be ambassadors with the DevOps Institute. And each month, we have a different topic of discussion to align with our monthly spotlight topics on DevOps.com.

    This month, we are going to be talking about cloud-native and cloud-native technologies, and so, I have some experts in the field right now. First up, we have Leonardo Murillo, who is the CTO of Qwinix Technologies. Hey, Leonardo, thank you so much for joining me today.

    Leonardo Murillo: Thank you for having me, Charlene. I really appreciate it. This is great.

    O’Hanlon: Alright, alright. Next up, we have Tracy Bannon, who is the Senior Principal and DevOps Strategic Advisor and Software Architect at MITRE. Tracy, thanks so much for joining me, we really appreciate it.

    Tracy Bannon: Thanks for the invite.

    O’Hanlon: Great. And finally, last but not least, we have Pawel Piwosz, who is the Lead System Engineer at EPAM Systems. Pawel, thank you, also, for joining me today, we really appreciate it.

    Pawel Piwosz: It’s a pleasure to be here with you.

    O’Hanlon: Great, great, great. So, let’s dive right into the discussion. I know we’ve been talking on DevOps.com and Container Journal a lot about cloud-native, but I’m not sure, actually, that a lot of people understand exactly what we mean when we say cloud-native, so maybe we should set the stage, if you will.

    Leonardo, maybe you can start us out since you are really focused heavily on cloud-native. Can you kinda tell us what we mean when we say cloud-native? What are we talking about?

    Murillo: Sure. So, I think when we talk about cloud-native, we’re talking about a specific mindset and patterns to apply when we’re building both systems as well as organizations, which is kinda one of the things that I wanted to discuss today, right? Because cloud-native is not just how you build technology, and you don’t really need the cloud to build cloud-natively, right? Usually, when you think in terms of cloud-nativeness, you’re thinking about loosely coupled architecture, you’re thinking about containerization, immutability, statelessness, right? All of these are components that are incorporated in a cloud-native solution, and I think the organization has also to become cloud-native, and that’s where DevOps becomes really important, right? To be able to leverage and really take advantage of all the different qualities, right, that the cloud has basically surfaced and made available, right? What do you think, Tracy?

    Bannon: To extend on that and sort of foot stomp for what you’ve said already and love that you want to talk about the organization, we can talk about, I call it a reverse Conway maneuver.

    Murillo: Right. [Laughter]

    Bannon: [Laughter] So, there’s a lot to be said—I’m actually finding that there’s not agreement on what cloud-native is. There’s an argument—it means containers. Well, yes, and let’s talk about serverless and the impact of serverless. So, it’s not a specific architecture pattern, but it does mean that we are building to take the best advantage of the infinite scalability, right, and the self-healing nature and other aspects of cloud. Love your point as well, Leonardo—while we say it needs to be on cloud proper, building for cloud, right, doesn’t mean that I’m necessarily hosting in an AWS GCP, et cetera and so on. It means that I have applied those principles, and I can do that within my data center, my private cloud, or whether I’m paying somebody else to be the host for me.

    Murillo: Yeah, great point.

    Piwosz: That’s true, and it’s not only about the application, it’s about everything what is around. For example, CI/CD, how we store our code, how we approach to the code, how we approach the security networking. Because this is something that we very often forget when we are going to the cloud, right?

    O’Hanlon: Mm-hmm.

    Piwosz: So, platform as a service, we have everything, we don’t need experts.

    Bannon: [Laughter] Don’t get me started at all!

    O’Hanlon: [Laughter]

    Bannon: But that’s an interesting point is that there are so many fantastic capabilities that are being provided as a service that I don’t think the folks actually know where to begin. I’ve had some awesome infrastructure folks who go out and they do some Googling and they do some research and they come up with a reference architecture. And heaven forbid, but God love them, they go out and spin it up and push the button, and—wow, this is a good solution for my firm or for my client or for my needs—and it isn’t, necessarily.

    So, there’s a lot of trade space that we’re unintentionally losing with the rapidity that we’re moving, trying to move towards cloud. Architecture should be more important, not less important. It shouldn’t be a stalling factor up front, but I jokingly say that, in order to push some value, provide value out into industry or to my clients, I have to be doing that from vision forward, right? I can’t take a steel girder and put it through a wood chipper, right? It’s not going to work because it wasn’t constructed and thought of that way.

    But Leonardo, to your point earlier, as much as the technology to me is the fun and sexy part, the human aspect really needs to be dealt with as well. We talk about it a lot in the DevOps piece of it, the DevOps portion or support effort on it, but you really bring up that cloud-native requires us to think about the organizational structure and building a separate culture than what we’ve had before. I’d be interested in what you think about some of the emerging software factories, or should I say continued proliferation of software factories as the way to move forward on software?

    Murillo: I think that actually talks about kind of a different subject, and I’d like to kinda step back a little and think—because you mentioned something that is very much aligned to this, and it is the whole strategy as to how you approach the cloud, right? It’s not just about click a button and going in, right?

    Bannon: Mm-hmm.

    Murillo: And, to me, that has a lot of resonance to what DevOps is all about, right? If you think into kinda the cada mindset, right, define your North Star first, right, assess your current state, think about it consciously and mindfully, right?

    I think if organizations that are looking to go into the cloud or mature into the cloud do take that step, do take time, they will be able to maneuver this gigantic ecosystem of tools that are out there and technologies that are out there. Because I think there’s also an interesting component that we should discuss. You mentioned, Tracy, how it’s not just about the technology, it’s also about the humans, right, the people that are implementing.

    Bannon: Mm-hmm.

    Murillo: But I think that also resonates with the fact that technology is not there just for the sake of picking the latest and greatest tool, right? I read this great post by somebody that I can’t recall, that basically talked about how boring is good. You know, how boring technology is good because people are used to it and they’re kinda like aware of how it works.

    And I think the closer you are in your evolution path to what is comfortable, the better. And I think that’s one of the problems that I sometimes see in cloud adoption—people try to bite too big of a chunk of change at a given time, right?

    Bannon: Yep. Mm-hmm.

    Murillo: And there’s so much to choose from to make that huge bite. An actually targeted approach that is mindfully defined that is well strategized will solve a lot of these problems, right? Because it will give you a signal amongst all this ecosystem noise that teams are gonna be exposed to, right? So, Pawel, you are kinda like engineering these solutions, right? How do you work around this ultra-diversity of available technologies, right, when you’re building something?

    Piwosz: Mm-hmm. This is … a very big problem. Because right now, together with cloud, we gained much, much more speed with everything, really. So, imagine 20 years ago you had a server room with racks and servers there, so you’d change only the server, but the logical side was still the same.

    Today, we are jumping. Let’s stay with AWS. We are jumping from instituting analysis to microservices, then to serverless microservices, then to serverless itself. Who knows what we will find next year, for example, right? You need to switch your mindset here. This is something that especially all kinds of CisOps—well, I am all kinds of CisOps—people have in mind, right? The same for networking, for security. There is a huge difference in speed here.

    So, you need to incorporate into your mind things like do fast, fail fast, learn fast—especially learn fast, because we are forgetting about this very often; too often, I would say. And also, we are forgetting very often in the trenches about the security of the cloud.

    Bannon: Oh, gosh, yes.

    Piwosz: Because—yes, because we’re saying, okay, we have a shared responsibility model, so they are responsible for everything. We’re just running our application and not caring about anything else, what is really, really wrong, I believe.

    Murillo: And I think that points to a fundamental misunderstanding, right, of what security in the context of cloud native architecture is all about, right? And I also think about, Tracy mentioned this infinite capacity, right? And you mentioned, Pawel, going fast.

    I’ve been thinking a lot recently as to how those two components need also to be very effectively managed.

    Bannon: Yes.

    Murillo: By leadership, by those that are sponsoring these initiatives, right? Because after all—and this is something that I’ve been talking about lately, right? We have optimized for speed alone already without having, really, awareness of the impact that that would have on the environment and many things, right? And I think we really need to establish a mindset where engineering teams are aware that infinite capacity doesn’t mean just free for all, grab whatever amount of resources you have, that shared response security is not infinite, overwhelming security, right?

    And I think this is also relevant in the context of the tooling that we were talking about, right? Everything now is available kinda point and click. You download a package, you have an appointment. You download another package, you have authentication and connectivity, right? And we don’t go into details necessary to understand kinda the supply chain of all these solutions.

    So, I think that’s where—the mindset of DevOps, right, reduce waste also becomes very relevant, right? Just because you have infinite capacity doesn’t mean you can’t be wasteful or you don’t have to be constantly evaluating the outcome of your ongoing efforts, right? Yeah, so, I think that’s very important.

    Bannon: There’s a treasure trove of topics that you just landed on, so it sounds like it could be a longer collaborative.

    O’Hanlon: Yeah, right. [Laughter]

    Bannon: So, in terms of reducing waste, one of the things that I’ll put out there is that I believe, in what I’ve observed with teams that I run or teams that I’m reviewing the content is that some of the cloud capabilities have made us, I think, lesser programmers, lesser developers, because we’re not concerned about the same things that we were before. We’ve delegated authority or we’ve delegated that concern.

    I’ve seen some pretty hideous, performance-wise, if I were to run it anywhere other than being able to up my compute, it used to be that we had to be concerned because it cost a lot to add additional resources, right? If it wasn’t as performant as we needed it to be, you just threw more hardware at it. That went away for a long time because it was cost-prohibitive.

    We’ve almost gone back and revisited that in some ways. From a security perspective, it’s always been my perspective that it needs to be baked in. It has to be part of the ecosystem. So, when folks started talking about DevSecOps, I was actually against that, because DevOps means that there’s a security part of it, but I do understand that it was, at times, not thought about. Our developers need to be educated, but they need to be held accountable because it becomes—there is a group effort. Now, when I say developers, I mean the athletes who are hands-on, they’re engineering with us, they’re moving the software forward.

    But there are two pieces that come to mind with this. There’s a limit to how much they can consume. Mentally, there’s a limit to how much they consume. I’m looking at Pawel’s background and I’m thinking to myself, “I love all the stickers” and yet, those are all the technologies that he’s considering that he’s looking at. So, as leaders in technology, one of the things that we need to do is to provide guidance to the folks who are on our teams to help them reduce the noise. It doesn’t mean to ignore the new things, but it does mean go ahead and get to finish, get to done on one thing, get it working, learn from it, and then improve it. And if improving it means that there’s a certain amount of acceptable refactoring or pulling in another tool—absolutely, right? That’s technology insertion, that’s a good, smart thing.

    But it does also mean that we don’t instantly glom onto everything that’s coming along. I have one organization in particular where every team is allowed to have the autonomy and latitude and I’m just there as an observer, and it’s a little bit of melee. There are lots of good pockets of interesting things, but because there’s such technical diversity even in a small space, they’re having a hard time, because they’re not able to get crisp and good and deliberate with the first set of tools. To your point earlier, Pawel, they’re not getting good enough with what they’re doing before they’re switching on to something else.

    So, cloud native mindset is pretty important, but helping to folks understand cloud native from a, what is it from a patterns perspective, what are the architectural tradeoffs for it, and then helping them to make selections and stick with it long enough to get a success, I think, are really keys to helping organizations.

    O’Hanlon: So, do you guys think that cloud-native is kind of an all-or-nothing proposition? Are organizations—have you seen organizations kind of going all-in on cloud-native and then maybe pull back?

    Murillo: I’ve seen them going all in and I’ve seen them crash and burn. [Laughter]

    Bannon: Yes! [Laughter] Alright, then!

    Murillo: Yeah, I think—I was talking the other day as to, everybody knows juggling is really good for the brain, but if you try to learn to juggle with your most precious items, you’ll never learn because you’re gonna be very afraid.

    I think it’s the same about cloud and DevOps, right? Everybody knows it’s great, everybody knows there’s gonna be a lot of value out of it, but if you try to learn it with your most precious things—for instance, your entire organization—you’re gonna have a lot of resistance to getting it right.

    So, I think the same applies for DevOps and cloud-native. I think you need to iterate. You need to start small with projects that you’re capable of experimenting with, right? Kinda like the whole concept of a culture of experimentation and iteration is important, right? But there’s gotta be awareness to the fact that you cannot just experiment with everything, right, or with everything at the same time.

    So, what I mentioned, right, bite small pieces at a time, iterate, do concepts, and use those concepts to build kinda your operating model, right? What does a cloud mean to you for your organization, right? And then expand up until you have a very solid framework that is well establish, well understood, and then you can kinda start juggling with fire, but not until then.

    Bannon: That also helps us think through greenfield versus brownfield. I deal a lot with governments and a lot with federal governments and different agencies in defense. And there’s a tremendous amount of brownfield. It doesn’t mean that there’s old brownfield, but it means that there’s something pre-existing, so there have to be decisions made about where do I add on the cloud-native? Do I do it around the edges, is it incremental, am I doing strangler fig tree patterns, et cetera and so on? That’s one piece of it. Net new sometimes is a good place to try cloud-native, right, because you do have perhaps less confines around it, so take something smaller that’s greenfield and make your first foray that way.

    I think it’s an interesting conversation about the starting and stopping points for cloud-native? I noticed—and I’d like to hear, Pawel, if you’ve seen the same thing—I saw everybody lift and shift as quickly as they could. “I wanna get rid of my data center, so I’m just gonna move my workloads, right? IAS, I’m gonna move my workloads.”

    So, they moved their workloads, and I naturally thought the progression would be to pass or would be to cloud-native and to the refactoring. What I actually observed was a pendulum swing to the analytics side. And so, there was a tremendous, I have all of this compute available to me, I have less expensive storage, I’ll move over to the analytics side, and we’re just starting to see, a real increase in the cloud-native application space. Unless you’re truly talking about upstarts and greenfielding, there has been much less of it with the brownfield and the incremental improvements.

    Piwosz: Yeah, I agree with you. So, first of all, if you just do lift and shift to cloud, whatever we call the cloud, you will cry very soon. So, this is the first thing.

    The second—yes, we have a lot of possibilities regarding analytics, we have beautiful words right now, buzzwords like observability, telemetry, et cetera, et cetera. So, we’re just expanding our monitoring, let’s say old-fashioned monitoring to the new areas and collect more and more and more, and more structured things.

    So, this is something what is very, very easily achievable, but also—and this is in relation to the previous topic here, if you start with cloud, well, you are already in the cloud. There should be still a logic behind everything. Because, today is so tempting, because you do not have to do the initial investment, right? You just click a button and start using serverless or just create a big, big cluster of something, right?

    And then, in my work, I observe this multiple times, then you create a crazy, really crazy solution for a very simple thing. Well, what can go wrong in this, right? So you are using like 10 or more technologies which are completely different, you are trying to wire them together and then you are saying—okay, I know 20 technologies, it looks perfectly well in my CV. But when you talk with people, you just realize that it doesn’t work as it should work, really. That’s why, very often, organizations which are going to cloud and do not take logic in this, how it is organized, how it is architected, how this even developed, they are paying much, much more, not just because they did lift and shift, but they started to create very, very crazy solutions, right? And this is the kind of waste that you mentioned as well.

    Bannon: I’m gonna throw out just a couple quick words that’ll make people cringe, but when I think about—so, agility 20 years ago, right, the agile manifesto, there’s a woman named Linda Northrop from the Software Engineering Institute at Carnegie Mellon who said it was one of the worst things that ever happened to software architecture, because unintentionally, there was this emergent architecture, my architectures will just emerge, I don’t have to worry about them in advance. I want to push forward that enterprise architecture needs to still exist, but in a different form, in a different format. There still needs to be, it’s okay for there to be somebody more senior, somebody who is helping to drive the architecture and helping to pick which cloud technologies and where cloud native is the most appropriate.

    Because there’s different trade space, right? Even if I talk containers, there’s different trade spaces between how I’m using the containers and how I’m moving forward with that. Does that resonate with you, Pawel and Leonardo?

    Piwosz: Yes, yes. I would even add here that if you want to be cloud-native, your developers need to be cloud-native. So, there is no more, “It works on my machine”—this is obvious, right? But also, I will be bold here, so even development should go into cloud. And this is another layer here, which we didn’t touch, but it is very important, I believe.

    O’Hanlon: Well, I feel like we could have this conversation for at least another hour, but unfortunately, we gotta wrap things up, guys. But I do appreciate Tracy and Pawel and Leonardo for your insights. You guys are great. I’m gonna have all three of you back on and we’ll talk about other things in the future. We have lots of topics to get through this year.

    The level of intelligence and insight you guys bring to these conversations is just so, so value added, so I do appreciate your time in joining me today for another one of our DevOps Institute Ambassadors Panel Discussions. So, thank you, guys, again. We really do appreciate it, and please do stay in touch with me. I’d really absolutely love to get your expertise back on the show, so.

    Bannon: Alright, fantastic. Be well. Stay safe, everybody.

    Murillo: Thank you very much.

    Piwosz: Thanks, everybody. Thank you.

  • Citizen Development Program: Enabling Citizen Developers

    Citizen Development Program: Enabling Citizen Developers

    In part one of this series, we made the case for embracing citizen developers to close the developer demand-supply gap while delivering true business agility. We outlined the foundational elements that are consistent across successful citizen development programs: 1) adopting a low-code application platform, 2) embracing the citizen development journey and 3) marketing (internally) citizen development successes.

    citizen development 2

     

    We also discussed finding the right citizen developers – individuals with the right aptitude and attitude to be successful building applications using low-code tools. Now that we have identified the right use cases and the ideal citizen developer, we will focus on the key decisions for enabling (and empowering) citizen developers.

    Enabling (and Empowering) Citizen Development

    To enable citizen developers, you must focus on the individual and set them up for success through training, support, and recognition. Empowerment addresses the citizen development process, the life cycle of an application and, more importantly, reducing the organizational friction associated with both.

    citizen development 3

    As you look to build out a citizen development enablement program, you need to answer the following questions about training, support and recognition of your citizen developers:

    • Training
      • What is the training curriculum for citizen developers? Do learning paths differ based on developer category?
      • Is there organization-specific content that needs to be included in the training? If so, who owns the creation and maintenance of that content?
      • How will developer proficiency be assessed?
    • Support
      • How will citizen developers obtain ongoing support?
      • Will you schedule office hours hosted by subject matter experts?
      • Will there be an online community?
      • Will citizen developers be aligned with a specific SME / pro developer?
      • How quickly do you want to scale the program?
      • What are the appropriate checkpoints / milestones associated with scale?
    • Recognition
      • Will you formally recognize training accomplishments? Perhaps though gamification via badges?
      • How will you track, celebrate and reward successful applications?
      • Does demonstrated competency equate to increased developer access?

    It is important to remember that the role of “citizen developer” is frequently an additional responsibility beyond an individual’s day job. As such, it is critical to educate them, support them and celebrate their wins in order to ensure success.

    In order to empower your citizen developers, you need to consider both the application development process and the overall application life cycle. You need to answer the following questions about the process and the life cycle:

    • Application Development Process
      • What is the overall objective for citizen development? What metrics will you use to track progress?
      • Does each application require a separate approval or are developers, once approved, able to build multiple applications?
      • What are the technical standards and best practices specific to your organization?
      • What is your development process? Who has authority over development, testing and deployment?
      • Is your core development team / center of excellence structured, resourced and funded to support citizen development?
      • How will citizen developers and pro coders collaborate on applications?
    • Application Life Cycle
      • What is your application intake process? Who evaluates new app requests for platform fit, redundancy, cost, etc.?
      • Once an application is moved to production, who is responsible for the ongoing support and maintenance?
      • What is your process for rationalizing and deprecating applications?

    As low-code platforms continue to evolve, the capabilities that facilitate the collaboration between the citizen developer and the pro coders are critical to deliver a successful application. It is not uncommon for a pro coder to collaborate with a citizen developer to deliver the last 5% to 10% of an application’s necessary functionality.

    We have identified the right use cases and the right citizen developers in part one. We have enabled and empowered the citizen developers in part two. In part three of this series, we will explore establishing technical guardrails to protect the platform from the citizen developers, and the citizen developers from each other.

    This post is the second in a three-part series that provides real-world insights on delivering business value from citizen development initiatives.

  • Protecting Data from Insider Threats

    Protecting Data from Insider Threats

    “Insider threat” can be defined as the threat an employee or a contractor will use their authorized access to, wittingly or unwittingly, do harm to an organization’s security. Certainly, as organizations become data-driven, embrace data democratization and release new applications at breakneck speed, the probability of an insider threat is rising sharply.

    A common example of an insider threat is granting permissions to on-call SRE engineers who may need to access system tables across multiple databases, inspect contents of S3 buckets and make changes to the production environment to fix availability issues. Every two weeks, the composition of the team may change, and the composition of services and databases may vary dramatically.

    While it is impossible to completely safeguard against insider threats, organizations can better protect their data by investing in best practices that (a) reduce the likelihood of such a threat playing out, (b) limit the blast radius from an insider attack and (c) help detect the attack as quickly as possible. The third point is especially important – the Ponemon Institute’s recent Cost of Insider Threats 2020 Global Report claims that it takes, on average, 77 days to detect and contain an insider attack.

    A DevOps Framework for Protecting Data From Insider Threats

    For security measures to be effective, they must be non-invasive, especially in agile organizations where DevOps teams are expected to push releases several times a day.

    Implementation of Access Policies-as-Code

    Implementing access policies-as-code automates workflows for user and service access authorization. Using this approach, manual policy practices are replaced with “code” (policy files readable by your team and by the systems that enforce the policies) so that the right people on your team can request, approve and publish policy changes instantly.

    As an example, here’s how the above scenario may be implemented as code:

    Engineers can add themselves to on-call status with a code push in GitHub to a Terraform script, with only the team lead authorized to approve this action. (See example 1, below.)

    insider threats
    Example 1

    Using frameworks like Sentinel, changes to production environments can be limited to only on-call engineers. (See example 2, below.)

    insider threats

    Example 2

    Similar policies can limit only those engineers who are able to read unencrypted content of S3 buckets by fetching keys from Vault. (See example 3, below.)

    insider threats

    Example 3

    The above examples demonstrate guardrails that allow engineers to perform their duties, while drastically reducing the administrative burden on leads, resulting in fewer errors. An additional benefit of this approach is that it forces a public review of all changes to policies, which makes the security model more robust.

    Zero Standing Permissions

    Zero Standing Permissions (ZSP) is a DevOps-friendly security tenet that requires any administrative privilege to be available to users only when needed, and only for as long as needed. It enables teams to configure access, via administrative privileges, to highly critical components of their infrastructure for a limited duration, with restrictions on the scope of those privileges.

    Here are a few examples of how teams can implement ZSP for their databases:

    • Create an SRE role on the database that can update and delete database tables and a private Slack channel of db-admins that can allow on-call engineers to assume this role.
    • Implement a service that can be used to request and grant access via this SRE role for a default of 60 minutes. After that time, the access is automatically revoked and needs to be granted again.
    • Further implement policies in BrewOPA that restrict an SRE from dropping tables and databases, which avoids any disasters.

    Audit Trail for Privileged Activity

    SIEMs are increasingly the nerve center of every security organization. While effective threat-hunting and incident response requires several years of expertise, DevOps teams can significantly bolster the security of their cloud platforms by investing in log collection and basic analytics for all privileged activity in their environment.

    These tools include services such as the following:

    • Session recording for all Linux boxes using Cmd
    • Logging activity across databases with Data Cloud services
    • Centralizing and collecting all environment logs using services like CloudTrail.

    These logs can be visualized in tools like Kibana, where teams can look at activity pattern anomalies. These could include:

    • Someone opening up an FTP connection to outside the organization
    • Creating a manual copy of tables outside of the database
    • An increased number of authentication failures across resources

    While the concept of “least privilege” as a safeguard against insider threats to data has existed for some time, the advent of cloud-native and DevOps methodology has exacerbated the challenge of implementation. In recent years, security-as-code and infrastructure-as-code have emerged as good models for implementing security solutions, and are rooted in the above framework. The future encourages collaboration across various stakeholders, documents security policies for easy review and builds on existing tools and workflows. It will help limit insider threats, limit privilege sprawl and prevent “user fatigue.”

  • Gainful Employment

    Gainful Employment