Category: Blogs

  • Digital Transformation – Escaping the Event Horizon

    Digital Transformation – Escaping the Event Horizon

    Roundtable 9: Those who survive, and even thrive, during disruption successfully escape the event horizon, creating innovative new business, product and operational models. They also leverage and harness technology in new and innovative ways through digital transformation. Not escaping the event horizon leaves companies who languish in survival mode, or worse.

  • Nobl9 Makes SLO Specification Open Source

    Nobl9 Makes SLO Specification Open Source

    During an online SLOconf event today, Nobl9 revealed that the platform it created to enable IT teams to achieve service level objectives (SLOs) is now available under an open source Apache license.

    Brian Singer, chief product officer for Nobl9, said the goal is to make a YAML specification format for defining SLOs that includes a parser and basic validation and testing capabilities more accessible via an OpenSLO project. Achieving that goal is critical at a time when organizations are deploying microservices-based applications that have dependencies that often adversely impact performance and availability.

    While the concept of an SLO and/or a service level agreement (SLA) has been around for a long time, IT teams that have embraced DevOps best practices by hiring site reliability engineers (SREs) are programmatically attempting to assure that SLOs are attained and, just as importantly, maintained, said Singer. Most SLAs have, historically, not been well-enforced. OpenSLO makes it possible to achieve that goal by embedding SLO objectives within a YAML file that become part of a Git-based workflow, he noted.

    SLOs

    Niall Richard Murphy, author of the book, Site Reliability Engineering, has signed on to be a core OpenSLO contributor working alongside committers from GitLab, Dynatrace and Nobl9. The ultimate goal is to make it simpler to share and migrate portable SLO specifications across multiple application development projects by constructing them using an object model, said Singer.

    Nobl9, meanwhile, will continue to operate a software-as-a-service (SaaS) platform for managing SLOs based on OpenSLO. Singer noted there will be an increased need for OpenSLO as it becomes more widely employed. The Nobl9 SLO platform is compatible with monitoring platforms such as Datadog, New Relic and Prometheus, and uses data collected from monitoring and observability platforms to calculate acceptable rates of error per service. It can be configured to trigger alerts and even workflows in anticipation of outages.

    Accessible via a CLI/GUI/API, the platform also enables DevOps teams to create business rules and define “facets” of users based on the application experiences required. DevOps teams can identify users who are being serviced poorly in addition to tracking groups of users. They also can associate contractual obligations to an SLO for a critical business period.

    The platform also makes it easier to determine how to make systems more reliable or lower reliability goals to reduce costs when possible. IT organizations will also spend much less time determining the root cause of any issue using a combination of real-time and historical data that is more accessible. Today, it’s not uncommon for IT teams to spend weeks looking for the source of an application degradation issue, only to discover the problem can be fixed in a matter of minutes.

    It’s still early days as far as adoption of SLO-as-code is concerned, but the days when SLAs or SLOs were, at best, aspirational statements of intent are coming to an end. The expectation is SLOs will soon be maintained via YAML files embedded within application code and distributed across a rapidly expanding enterprise with more interdependencies than any IT team can manually track.

  • Managing Cloud Security with Check Point Software

    Managing Cloud Security with Check Point Software

    Managing cloud security across multiple cloud providers, private cloud, AppSec and software as infrastructure, is highly complex.

    In this TechStrong TV episode, TJ Gonen, head of cloud security product line at Check Point Software, advises a security strategy that meets the challenges of cloud environments and cloud-native software architectures, and DevOps toolchains.

    Information about Check Point’s cloud offerings is available here.

    The video is immediately below, followed by the transcript of the conversation. Enjoy!

    Transcript

    Mitch Ashley: I have the pleasure of being joined by TJ Gonen, who is head of cloud security product line at Check Point Software. Welcome, T.J.

    TJ Gonen: Hey, thanks for having me, Mitch.

    Ashley: I love your name. A guitar player in a band in college was named TJ, a good friend of mine.

    Gonen: Oh, really? [Laughter]

    Ashley: So, it’s always nice when I come across another TJ. Well, hey, would you introduce yourself and, as we were joking before, for the two people who might not know, in the world, Check Point Software, tell us a little bit about Check Point.

    Gonen: Right, yeah, so TJ Gonen, and I joined Check Point actually about a year and a half ago from an acquisition of the company. I was one of the founders in the serverless security space, in the cloud security space, so I’ve been around Check Point for 18 months, about 18 months.

    Check Point has been around for a bit more than that, 27 years, one of the OGs of cyber security—literally invented the firewall. [Laughter] So, it sounds crazy, but that’s literally what happened and over the last 27 years or a bit more now, one of the largest individual or independent cyber security companies in the world, billions of dollars, traded on NASDAQ, 100,000 customers over the years, 60,000 active customers, enterprises, I think we secure literally everyone and provide solutions across the full gamut of cyber security with a lot of focus on cloud security over the last two, three years, just because that’s a topic. And that’s what I do for Check Point, I round the cloud security product line.

    Ashley: Excellent. Yeah, I was sharing with you the second firewall I implemented was a Check Point firewall back in the ‘90s, so it goes back a ways. You’ve been around—

    Gonen: It does, it does.

    Ashley: – tried and true solution, for sure. Well, we wanna talk about not just the old days of when maybe you or I started in security. You know, obviously, the environments of what we manage and have to deal with the threat, the attack surface, all of those things has become infinitely more complex, and it’s continuing to go that way, if that’s an accurate phrase.

    I’m sure one of the issues that you deal with is helping customers with how do they manage all of their security across, you know, multiple clouds, cloud providers, their applications, their on prem, stuff that they’re running, SaaS services—whatever it might be that anybody in the organization is touching, whether they’re inside a firewall or outside, right, especially with remote work. Tell us a little bit about that.

    Gonen: Right. Yeah, I think—I mean, because both you and I go a long way back, then we have the privilege, if it’s a privilege, to look at the generations. So, it’s interesting. I think, you know, we talked about Check Point inventing the firewall in ’93, ’94 when the Internet revolution started, and I think that differently, when you look at security before the Internet and you look at security since then, obviously, that changed dramatically. And I think that what we’re experiencing now with cloud is sort of that thing happening again. It’s another inflection point.

    Ashley: Mm-hmm.

    Gonen: And if you—and realistically, from the invention of the Internet and the ultra-connected world, most of what we had to deal with was, generally speaking, in the same domain. Yeah, more complex, more bandwidth, more stuff, more operating systems, but the blueprint—I think people figured out sort of the blueprint over the last 20-something years of what you are supposed to do after the Internet came across, right? Cloud, I think, restarts a lot of this discussion, and it’s not just the sheer notion of, yeah, your data center is somewhere else and your stuff is somewhere else—I think it’s just velocity and scale.

    I think the biggest struggle we hear from customers and prospects, and honestly, even if you own your own environment, is just, you think you figured it out and then a day after, it’s 10 times bigger, 50 times more people have access to it, and you lost control. It’s so easy to lose control. So, I think where we were, where we had, “Hey, you know what? Oh, you have a data center? Okay, let’s put the firewall, let’s put some segmentation, let’s put AV or whatever—okay, here’s the blueprint.” Now, we are in this place where, how many data centers do we have? One, day after it’s 50, and now, how do you know, even, what’s going on there?

    So, I think scale and speed has been the biggest problem, and I think cloud is a real revolution. It’s not incremental, it’s not another thing you need to deal with.

    Ashley: Mm-hmm.

    Gonen: It’s a thing you need to deal with, and it’s a big issue.

    Ashley: The evolution of, we move things to the cloud, but we do things the same way we did on prem.

    Gonen: Right, right—it’s not that.

    Ashley: Then there’s the next evolution of how do you do it within, truly within a cloud environment that matches that. I mean, I remember the days of just managing the rules and what were they all in there for and who put what in, and just—that was complex, you know, when you’re an enterprise, multi-location.

    Gonen: Yeah.

    Ashley: Talk about the management capabilities that you have to have in a cloud environment, multi-cloud environment.

    Gonen: Actually, you sort of touched on something that is a no-no in the cloud environment. You literally mentioned something that, like—hey, someone was sitting down and writing firewall rules and configuring who has access.

    Ashley: Mm-hmm.

    Gonen: Manual, right? There is just no way you can do anything manually in the cloud. I mean, think about this, Mitch. Everything that happened over the last 10 years in Dev and infrastructure has been focused on automating everything.

    Ashley: Mm-hmm.

    Gonen: Literally. We talk about CI/CD, and obviously, DevOps and now cloud, if you look at cloud—cloud totally automated infrastructure and then it totally automated application infrastructure and now it’s automating everything, no code and stuff like that.

    Ashley: Including infrastructure as software, right?

    Gonen: Yes, exactly.

    Ashley: Not all of them are in a stack.

    Gonen: Everything. So, everything has moved towards automation. So, if we are going to, let’s say, you can imagine saying someone is gonna configure something manually on security, by definition, we’ve failed. So, the biggest challenge that’s facing security is how do I automate security? Because it has to secure stuff that’s fully automated.

    So, I would say, you asked about management—the first thing I would say about management for cloud, it can’t be manual. If there is, we have a saying inside Check Point that we say in the CloudGuard team, it ain’t done ‘til it’s automated. Whatever you were working on, whatever capability feature security for, if it’s not automated, if you can’t automate it, you are not done, because by definition, you are gonna be left behind and something is gonna be open, because the rest of the stuff is automated.

    So, I think the biggest—and when we talk with a prospect and when I talk on the stage, even, I always say, “Listen, when you talk about your security blueprint for the future for the cloud, number one is automation. It’s not how secure it is, it’s how automated it is.” Because it doesn’t matter, you can have rocket science technology for security—if it’s not automated, you’re gonna miss half of your footprint, anyway. So, automation has—

    Ashley: Mm-hmm. [Cross talk] the same way twice, right?

    Gonen: Right, exactly. [Laughter]

    Ashley: Without the audit trail. Well, talk a little bit about, you know, there was sort of the orchestration phase, right?

    Gonen: Right, right.

    Ashley: What we thought of as automation now, you’re talking about the entire Dev and Ops process.

    Gonen: Yeah, right.

    Ashley: The infrastructure as code, applications, dynamic environments—you know, things are changing very quickly.

    Gonen: Right, right.

    Ashley: How does it differ today from maybe folks that remember orchestration as [Cross talk]?

    Gonen: Right, yeah. So, it is different, and I think in security—let’s talk from a security perspective, because I think that’s the angle that, definitely, we deal with today. We feel like there’s two pieces to automation that are critical in this world. I call it, I split it into the first one being the presence of security needs to be automated. We lost the luxury of someone telling us that it’s doing something so we can put security in place.

    Ashley: Mm-hmm.

    Gonen: That luxury is gone, so the presence of a security control or mechanism has to be there automatically. So, if someone—just to keep it really simple, if someone is deploying new container to the cloud, which happens a billion times a day, and I decided that that container needs to be secured, then whatever the security mechanism I chose for that container needs to be there automatically. The container is deployed, security is there. How? Magic. I don’t know, but the presence of security has to be automated.

    The second thing that has to be automated is the security configuration itself. Because, again, we lost the luxury of someone saying, “Hey, I deployed an application, how about you call someone to configure the web application firewall and fine tune it to the application?” or, “I changed the application, now someone needs to fine tune the rules.” What? Find new what? It’s gonna change in five seconds, again.

    So, two things have to be automated—the presence of security, and that really talks to DevOps and integrating into the infrastructure as code pieces, just like code is automated or the deployment process is automated, the presence of security and deploying serverless functions, security has to be there. I’m deploying a new VPC and I decided that I need a firewall at the entrance, it has to be there automatically. No manual, no human intervention. And the second piece is the actual configuration. So, if I decided—let’s follow that thought process—if I decided that I’m deploying a serverless function, a Lambda function with AWS, security needs to be there. The security needs to be there automatically, but also the profile of that security, the allow and block rules has to be there automatically and they need to auto adapt to changes.

    And I think that’s such a—this is such a different breed of security automation. This is not just orchestrating security into where it needs to be, and it needs to be in a billion places, it’s also the sheer notion of how do I keep things maintained and configured correctly. And that’s why I think a big change is the definition of who does security engineering.

    Ashley: Mm-hmm.

    Gonen: Like, you and I started a billion years ago—me a billion, maybe you half a billion.

    Ashley: I’m two billion, so.

    Gonen: Two billion? You’re two billion, okay, there you go. [Laughter] So, between us an average of one and a half billion years ago. A security engineer is the one that configured the Check Point firewall, right?

    Ashley: Mm-hmm.

    Gonen: And part of the process was, “Hey, open this port for me, close this port for me, what’s the”—that’s gone. The new engineering is, the new engineer is not only the DevOps guy and the DevSecOps guy, because everything is as code and security has to be as code. I would argue that the new security engineer is the machine itself. Because you have to eliminate, as much as possible, even the process of an intervention, even by a DevOps person.

    There is, the security just needs to find itself there and auto-configure itself. That’s where it needs to go, and that’s where we put in a lot of effort. That’s why I said it ain’t done ‘til it’s automated, because I can give you the best solution ever, but if I actually require you to know what’s going on, there is just no way. You can’t keep up. There’s not enough humans in the world to keep up with the change of what’s happening now in the cloud.

    Ashley: Let me ask you this, because something that I’ve believed for quite a while now is that we are always talking about educating developers about security and helping to write a more secure code.

    Gonen: Right, right.

    Ashley: But the opposite is true, too. Not that security engineers need to be software developers, but security engineers need to understand software architecture as more than a temporary cloud. You obviously know it, you’ve been using the language of containers and Kubernetes and software as code. It’s not that you need to—it isn’t the old way of let’s go to the security team and have them set this all up for us, which is the whole premise of what you’re talking about. That happens, that has to be built into the process, it has to be built into the environment.

    So, what is the role of the security engineer in that kind of a shift left, DevSecOps, that kind of an automated environment—what skills do they need to have today that they maybe didn’t need 5 or 10 years ago?

    Gonen: It’s so fascinating. I mean, this topic, I think that there’s—we’re in this real point in time where there is a new role, architecture, or let’s say hierarchy defined. Because I think you’re gonna find security people, just to your point, when you come to a CISO and you say, “Hey, can you tell me what’s happening in my Kubernetes environment inside Azure?” And the average CISO is gonna say, “I have no clue.” The Dev guys, they do whatever they want with this environment. My security guys know how to read dashboards. They don’t know how to read code.

    Ashley: More of a SecOps kind of—

    Gonen: More of a SecOps, yeah. And I think, then—and to your point, though, when you go to the develop and you say, “Hey, developer, what’s your security strategy?” and he says, “Dude, I’m a developer—what security strategy?” So, I think you’re right that there’s new roles being defined, and I think where the world is coming to is one that you’re gonna find more, like I mentioned a bit earlier, the SecOps and Sec engineering roles are gonna be more and more definitely, in the world of the cloud, people who can write scripts.

    Ashley: Mm-hmm.

    Gonen: I think that you come back in five years from now, you talk with a SecOps guy, and you say, “Hey, can you write item scripts, can you write bash process, do you understand how to connect to the AWS API?” and he says no, he’s gonna have a real problem managing engineering, security engineering in the new world.

    Now, so, I think where the world is gonna go is that you’re gonna have what today is traditional, security do policy, defining what needs to happen, and governance. So, these are the two ends of the spectrum. I’m gonna define what I expect to happen, which measures what do I test for, what do I scan for and so forth, and I’m gonna make sure that it’s being done. And then, inside that sandwich, inside that Oreo cookie, the piece in the middle is gonna be more of the developer people—DevOps, DevSecOps. Because they’re gonna be in charge of actually doing a lot of the security work, so if the policy says applications have to be segmented in the cloud, so the payment application has to be segmented, you know, separated from the CRM application. The security people are gonna say that. That’s the policy, because it’s PCI data or whatever.

    The people that are actually gonna implement segmentation are gonna be DevSecOps people or DevOps people, because the segmentation is done in Kubernetes, and the security guy doesn’t know how to write Kubernetes microsegmentation over Calico and CNI, and these are all buzzwords, he doesn’t even know what they mean. And there’s gonna be governance at the other end to say, “Okay, that was being done. That might be a dashboard or something like that.”

    Ashley: You know, there may be—we could spend a whole other conversation on this.

    Gonen: Oh, yeah, I’m sure. [Laughter]

    Ashley: There might be a nice parallel, the analogue to this was what’s happened on the Ops side, because SRE is big, right?

    Gonen: Right, yeah.

    Ashley: And those are people that know how to code and know how to write scripts, and maybe something like that is the emergence of the security engineer role is going to be as, “My job is to automate the security.”

    Gonen: Exactly.

    Ashley: “Work with the teams, whether it’s the tool pipeline or it’s the software Dev team, the infrastructure teams.”

    Gonen: Right, right.

    Ashley: And almost that kind of a role, I wonder if that might be where we’re headed.

    Gonen: It’s actually very much true, I think that you are heading in the right direction. The SRE was born exactly from that necessity—hey, I need an Operations guy, but I need him to be able to actually orchestrate stuff using code. And I think it’s exactly what’s gonna happen or is already happening to some extent, but it just doesn’t have a name yet, except DevSecOps, right? Like, maybe DevSecOps is the closest thing, which just doesn’t come down to an acronym—DSO, maybe, I don’t know. [Laughter]

    Ashley: Yeah, we need a new job title, I’m sure.

    Gonen: We need a new job title. [Laughter] But other than that, that’s exactly it. And really, I mean, in the cloud world—listen, if you’re a cloud native company and your data center and applications are cloud native, if you hire a security guy from 10 years ago, he’s gonna be lost.

    Ashley: Mm-hmm.

    Gonen: I mean, everything is code. He needs to be able to—

    Ashley: Plus, a lot of developers are moving into security that have an interest, right?

    Gonen: Yeah, right, yeah.

    Ashley: So, that may be the best way to acquire. Well, hey, we’re running out of time, T.J., and I look forward to having you back.

    Gonen: Yeah, sure.

    Ashley: I’d love to chat with you more, especially as we get into sort of the DevOps and the CI/CD pipeline and integrating security into that.

    Gonen: Yeah, I’d love to.

    Ashley: Who knew 27 years ago we’d be having this conversation—

    Gonen: [Laughter] There you go.

    Ashley: – with Check Point? So, things have certainly advanced. Where can folks find out more and check out your cloud offerings?

    Gonen: Yeah, so, CheckPoint.com, and it says in very large letters cloud. That’s where you can go and you can start a demo, you can read a lot of the white papers around these things. And actually, I think more than anything else, we were just talking about developers—experiment with it yourself. Developers, that’s what they like to do.

    Ashley: Mm-hmm, absolutely—write a little bit of code, see what it does.

    Gonen: [Laughter] Right.

    Ashley: TJ Gonen, great talking with you, Check Point Software. I look forward to chatting again. Take care.

    Gonen: Sounds good. Take care.

  • Despite Cloud Adoption, Enterprises Demand On-Premises Software

    Despite Cloud Adoption, Enterprises Demand On-Premises Software

    A recent report from Dimensional Research reveals that the demand for on-premises software is equal to that of public cloud. The report, which was commissioned by Replicated, a company specializing in on-premises software modernization, queried 405 participants in software development, executive, product management, sales and services roles to determine the needs, usage and challenges of on-premises software.

    The report revealed that some 90% of companies surveyed said their on-premises sales of software solutions continue to rise, while 70% that do not currently offer on-premises solutions intend to in the near future. 

    “In the past few years we’ve experienced a steady increase in interest from leading global companies who see that modern on-prem software delivery through containers and Kubernetes can make data protection and security much easier,” said Grant Miller, co-founder and CEO of Replicated. “Coupled with growing customer demand, it’s a win-win scenario for any industry.”

    While Miller’s view may be optimistic, the survey also revealed that the majority (65%) of companies cited privacy compliance as the top reason for using on-premises software delivery; an indication that the market is being influenced by cybersecurity issues more than any other factor. However, 54% also stated uptime and reliability were a primary driver for on-premises solutions, while 45% noted the importance of integration.

    The report indicates that enterprises, which have cited digital transformation and a movement towards the cloud as critical factors over the last two years, may also be thinking more about on-premises solutions in light of cybersecurity and compliance concerns. This, in turn, means that DevOps has the potential to gain even more traction in the enterprise. 

    While the report mentions the merits of an on-premises software strategy, it does raise the question of why more enterprises have not moved in that direction already. That hesitation to re-embrace on-premises software can mostly be attributed to perceived complexity, time commitments and the cost of engineering resources to make it happen. 

    Complexity is further highlighted by 74% of survey respondents reporting that it would take more than a week to install and configure on-premises software, and 29% stated an install could take over two months. For the 16% that claim they can rapidly install and configure on-premises software in less than a week, the potential for growth in the market is notable. 

    While the future remains somewhat uncertain, the report from Dimensional Research runs counter to other reports, such as a Synergy Research Group report that revealed in 2019, spending on cloud platforms edged past the resources spent on acquiring servers and software for on-premises data centers. “60% of the servers now being sold are going into cloud providers’ data centers and not those of enterprises,” said John Dinsdale, a chief analyst at Synergy Research Group, confirming the trend. “Clearly, companies have been voting with their wallets on what makes the most sense for them.”  Dinsdale said the growth of cloud infrastructure will continue to accelerate aggressively over the next five years. 

    Although conflicting observations tend to add to the market confusion, one thing is certain – DevOps shops have market opportunities to service customers deploying both to the cloud and on-premises software.

    on-premises

  • Will App Dev Become a Normal Competency?

    Will App Dev Become a Normal Competency?

    With a shortage of available developers, companies are considering low-code methods to meet massive application development needs. As a result, by 2024, citizen developers will be responsible for 65% of applications, Gartner predicted. So, if technical ability rises across the board, will application development become an expected skill set for tomorrow’s digital workers? And if so, when?

    “Application development will become a normal competency,” said John Bratincevic, senior analyst, Forrester. Bratincevic recently gave a talk at the Rethinking “How” into “Who” with Low-Code event, presented by TrackVia.

    I asked Bratincevic to dive deeper into how application development is becoming democratized. In short, the low-code movement has permanently altered expectations around who can be involved in application development. To him and others within the industry, leveling up with citizen development knowledge could be vital to retaining a competitive advantage in the future digital-native workplace.

    The Undigital Condition

    As more and more companies digitally transform, they are evolving into software companies. In this new paradigm, “software is an expression of the business,” says Bratincevic. Yet, most organizations have not entirely digitally transformed. According to Forrester’s Q1 2020 Global Digital Process Automation Survey, 76% of companies still rely on paper-based processes, and 94% use Excel or email-based processes.

    Unfortunately, developer talent is too few and far between to rectify this “undigital condition,” and existing IT teams are struggling to keep pace with demands for more software-based processes. Too often, teams are told to get in line and wait for experts to develop software when they can, said Bratincevic. This gap results in a less adaptive structure that limits new ideas.

    “All organizations are probably, to some degree, adaptive, but their improvement and adaptation are typically only periodic and conducted by specialists,” wrote Mike Rother, Toyota Kata. “In other words, such organizations are not, by their nature, adaptive.”

    A New Generation of Citizen Developers

    The old model is not realistic anymore, said Bratincevic. Instead, a new generation of citizen developers could use no-code and low-code platforms to program operational tasks themselves. These tools use visual, declarative techniques instead of programming and are “empowering employees outside of IT to deliver apps,” Bratincevic said.

    So what is the demographic behind citizen development? Reports show that younger, digital-native employees are more likely to use low-code platforms. According to the TrackVia report The Next Generation Worker: The Citizen Developer, 50% of citizen developers are 18 to 29 years old. The study also found that citizen developers are 13% more likely to expect promotions, correlating citizen development experience to career advancement.

    In this projected economy, “digital elites” seem well-positioned to progress, whereas others are in dire straits. “Knowledge workers with simpler, more focused roles (e.g., a “coordinator”) and without digital skills are at risk,” said Bratincevic. Thankfully, low-code could offer a practical way to enter the tech field and increase job security.

    Leveling Up From Productivity Tools

    Today’s average worker is quite familiar with personal productivity apps such as email, social communications, calculations and other consumer technologies. Just as productivity tools have become commonplace, Bratincevic predicts that application development will become a standard skill set in the future.

    Other IT leaders agree that coding literacy will soon become ubiquitous. Apple CEO Tim Cook, for example, recently emphasized to the U.S. president that “we believe strongly that it should be a requirement in the United States for every kid to have coding [education] before they graduate from K–12 and become somewhat proficient at it.”

    Application development may become a typical proficiency; however, the exact nature of software development is up for debate — especially as development environments add more abstraction layers to the lower stack that only involve programming languages indirectly. For example, Bratincevic describes how those learning to code often use a service like code.org, which involves low-code tooling and games to help educate students. “I see the same pattern for the adult professionals in the workforce,” he said.

    Future application development may not even resemble programming in the traditional sense. “Once ‘development’ on these kinds of tools becomes ubiquitous, we may not even call it application development anymore,” Bratincevic said. “It will just be — work.”

    Goals for Citizen Developer Programs

    According to an Outsystems report, 20% of companies adopted low-code to enable citizen developers to construct applications. “One of the main reasons firms are buying low-code is to enable non-IT folks to develop,” noted Bratincevic. “I routinely get inquiries from enterprises who are looking to accomplish this very thing, at scale in their organizations.” In particular, he notes apps of substance being created within health care, vehicle manufacturing, oil and gas and insurance industries.

    It appears more and more organizations are sanctioning a new wave of citizen developers. So what goals should these new citizen development programs aim to achieve? Bratincevic shared the following benchmarks:

    • Digitize. Everything. Always: Foster a digital problem-solving culture and develop a digital workforce.
    • Balance autonomy and control: Citizen developers shouldn’t have to ask permission to make a spreadsheet. Yet, guardrails are necessary for more far-reaching programs.
    • Take charge as privateers: He recommends organizations start by adopting an autonomous, business-led team, which he calls a Privateer model.

    Low-code could also help bring shadowy, rogue IT to light and rehabilitate it in a sanctioned way.

    The Era of Low-Code

    In 2021, the low-code market is estimated at $13.8 billion, said Gartner. SD Times even coined 2021 the “year of low-code.” But, since the citizen developer movement has permanently raised the bar, I would edit this statement to say we have entered the era of low-code.

    For more information and case studies on citizen development, I recommend watching the panel webinar Citizen Developer Movement with Forrester: Rethinking “How” into “Who” with Low-Code. In addition to John Bratincevic, it features Dave Garret, chief strategy and growth officer, PMI, (who I’ve spoken with in the past on How To Foster a Culture of Citizen Developers) and Joshua Yaklin, SVP of operational risk, Stearns Lending.

  • DAOPS Meetup 2021: Software Engineering, DevOps and DevSecOps

    DAOPS Meetup 2021: Software Engineering, DevOps and DevSecOps

    DAOPS Foundation—a non-profit organization committed to accelerating global digital transformation through technical standardization—is hosting the first ever DAOPS Meetup on May 18. The virtual meetup will bring together DevOps leaders from Sonatype, DevOps Institute, TARS Foundation and DAOPS Foundation to discuss the latest in software engineering and the latest DAOPS developments.

    Here are the four sessions scheduled for the DAOPS Meetup.

    ASEM, Next Generation Software Engineering Infrastructure

    Software is the core of digital transformation. In the digital era, the way we produce software also needs to be digitized. Forest Jing, chief evangelist at DAOPS Foundation, explains how they plan to help global enterprises build a high-performance, technical organization based on Lean, Agile, CI/CD, SRE, DevSecOps, Cloud Native, etc., by developing the next generation software engineering infrastructure named ASEM.

    Best DevOps Practice with TARS

    TARS is a high-performance RPC framework based on name service and Tars protocol, also integrated administration platform, and implemented hosting-service via flexible schedule. During this session, Mark Shan, chair at Tencent Open Source and TARS Foundation, will share the best DevOps practice using TARS.

    DevOps Hybrid Skills — Upskilling towards EverythingOps

    Upskilling is a human endeavor and a key contributor to personal and career growth. This past year was like no other. As we progress through the “next normal” of this decade, one thing is certain—digital transformation relies on human skills transformation. DevOps has continued to shift left in recent years, becoming more integral to operational processes as manifests in domains such as secure-development-focused DevSecOps, secure-operations-focused SecOPs, artificial intelligence-based AIOps, machine learning-focused ModelOps, and data management-related DataOps. As each of these evolves, its specific required skill set is being fleshed out and internal IT staff have the opportunity to upskill to meet requirements. Join Dheeraj Nayal, global community ambassador at DevOps Institute, to learn all about DevOps upskilling.

    The Rise of Next Generation Software Supply Chain Attacks

    Cameron Townshend, Solution Architect from Sonatype

    The adoption of open source in software development has grown exponentially over the past decade. Yet, the time required for hackers to exploit a newly disclosed open source vulnerability has shrunk by 93.5%. As development teams deliver new innovations, adversaries are also upping their game; something we’ve seen in recent high profile and devastating cyberattacks, such as Dependency Confusion.

    Adversaries have the intent and ability to exploit security vulnerabilities in the software supply chain—and in some cases plant vulnerabilities themselves. They have increased scale through automation and improved breach success through precision targeting. Cameron Townshend, solution architect at Sonatype, urges developers to fight back by doing the same: automating security directly in the DevOps pipeline.

    For more information and to register visit the DAOPS Meetup website.

  • Perforce Acquires 21 Labs to Advance Mobile App Testing

    Perforce Acquires 21 Labs to Advance Mobile App Testing

    Perforce Software announced today is has acquired 21 Labs, a provider of a suite of tools that leverages artificial intelligence (AI) to provide a no-code approach to testing mobile applications. Terms of the deal were not disclosed.

    Tim Russell, chief product officer for Perforce Software, said the 21 Labs tools complement a set of similar AI-based tools for testing web applications that the company makes available via its Perfecto portfolio. The company also makes available Virtual Devices, a service that makes it feasible to test mobile computing devices at scale using Apple iOS and Google Android emulation software. Perforce acquired Perfecto in 2018.

    21 Labs developed a test automation platform that uses algorithms to observe interactions within a mobile application that are then used to generate tests. That approach sharply reduces the need for a developer or professional application developer to employ scripts to generate those tests, said Russell.

    The next step will be to integrate 21 Labs with the test recommendation engine that Perforce already makes available via its Perfecto testing platform, added Russell.

    Perforce

    As the rate at which applications are developed accelerates, Russell noted, application testing has become a major bottleneck. The shift toward scriptless approaches to application testing will make it possible for organizations to quickly vet applications to ensure quality without having to slow down the rate at which they are being deployed. That’s especially critical at a time when mobile applications are often at the core of any digital business transformation initiative.

    It’s not clear to what degree application testing will be automated, but it’s apparent that as AI becomes more advanced, the need for many of the routine tests conducted by professional developers today will be eliminated. In theory, that should afford professional developers more time to conduct complex tests, while more routine tests are automatically run as an extension of a DevOps workflow.

    Application testing, of course, has always been the first thing to suffer whenever developers are pressed for time to make a delivery deadline. However, the sooner any issue is discovered, the less expensive it generally is to fix. At the same time, end users are not generally patient when it comes to mobile applications that don’t work as advertised. External-facing mobile applications, especially, need to provide a compelling experience the first time they are fired up. At the same time, internal digital business processes that are accessed by end users and business partners now need to be accessible from anywhere.

    Arguably, it’s harder to provide a great application experience on mobile computing devices than it is on a desktop platform, which means there should be even more testing of mobile applications before they are deployed in a production environment. The days when developers experimented on end users by rolling out minimally viable applications are coming to an end, as end user expectations continue to rise. DevOps teams that don’t adjust to that new reality may soon discover just how critical testing has become to their own job security.

  • WhiteHat Security Allies With Bit Discovery on Vulnerability Intelligence

    WhiteHat Security Allies With Bit Discovery on Vulnerability Intelligence

    WhiteHat Security, a subsidiary of NTT, has announced an integration with Bit Discovery to make it easier for developers and cybersecurity teams to discover the extent to which the attack surface they need to defend might be impacted by a vulnerability.

    Bit Discovery maintains a database made up of more than 5 billion internet-connected assets and hundreds of third-party resources to automatically generate an inventory of the assets that make up an organization’s attack surface. Bit Discovery continuously scans internet-connected assets to monitor new domains, phishing sites and connected devices to provide cybersecurity teams with a deeper understanding of the threats their organization faces.

    WhiteHat Security integrated its application security platform for scanning for application vulnerabilities with the Bit Discovery database via application programming interfaces (APIs) to make it possible to search that database via a dashboard. All vulnerabilities surfaced via that dashboard are verified by WhiteHat’s Threat Research Center, a team of application security experts, to reduce any potential alerts that might actually be false positives.

    Craig Hinkley, WhiteHat Security CEO, said the goal is to make it simpler for organizations to shift more responsibility for applications security left toward developers in a way that doesn’t result in them chasing their tail every time a new vulnerability is discovered. Instead, a virtuous cycle of workflows can be created that enables developers and cybersecurity teams to collaborate more effectively, Hinkley added.

    Ultimately, the goal is to make scanning for application vulnerabilities a more natural extension of any quality assurance process. The simple fact that there is so much focus today on DevSecOps best practices only highlights how much work there is to be done before security becomes just another routine gate within an automated DevOps workflow, noted Hinkley.

    In the meantime, unfortunately, cybersecurity teams are finding it increasingly difficult to keep pace with the rate at which applications are being developed and updated. The Bit Discovery database integration provides a way for cybersecurity teams to have more relevant conversations with developers about which vulnerabilities need to be prioritized based on the actual threat they represent to the organization. In the absence of that integration, security becomes a losing battle, simply because developers and cybersecurity teams both are overwhelmed by the volume of vulnerabilities that would otherwise need to be investigated on their own without any assistance.

    The integration between WhiteHat Security and Bit Discovery comes at a time when the focus on software supply chains has increased significantly in the wake of a series of recent high-profile breaches. More attention is now being paid to preventing malware from finding its way into the application development process. The challenge is finding a way to provide developers with actionable insights into risks that need to be mitigated before and after an application is deployed in a production environment. After all, vulnerabilities are just as often discovered after an application is deployed as they are before.

    It may be a while before most organizations are able to implement a robust set of DevSecOps best practices, but the more reliable the vulnerability intelligence being provided to developers, the more likely it becomes they will act on it before a cybercriminal exploits it.

  • Cloud Governance Can Trim Cloud Costs

    Cloud Governance Can Trim Cloud Costs

    The abrupt need to transition to remote work last year caused many companies to migrate to the cloud or accelerate an in-process migration. Cloud has become an essential part of company operations and budgets. Last year, worldwide end user spending on public cloud services was $257.5 billion, making up 9.1% of total global enterprise IT spending, and it’s forecasted to increase to 14.2% by 2024, according to Gartner.

    Upfront Cloud Costs

    The allure of cloud for organizations is its potential to save money, increase agility and offer easier scalability. However, these promises don’t materialize without proper management. Organizations will likely see an initial rise in costs with cloud adoption. Organizations spend, on average, 12% more running a workload in IaaS (infrastructure-as-a-service) compared to when it happens in their own data center. These cost increases occur when work is lifted and shifted without modification.

    Like any change, there will be upfront costs involved with the process of migrating to the cloud that need to be considered. With careful planning, organizations can avoid surprises. Items that need to be factored in when budgeting include the cost of cloud infrastructure, labor costs associated with migrating applications to the cloud, and the monthly bill from cloud providers. Many cloud providers provide cost calculators to help organizations determine what to expect when migrating to the cloud.

    Managing Cost

    A factor that is key to managing cloud costs is planning for the monthly cloud bill. Without proper monitoring, this is where overspend can occur—57% of IT leaders have exceeded their cloud budgets at some point, according to a 2018 Softchoice survey. One of the issues is the lack of visibility that leaders have into their cloud costs. A lag in your cloud billing data makes it difficult to make accurate decisions, which can be the case with spend reports from cloud providers that are 12 to 24 hours old.

    A lack of timely visibility into current costs and the inability to forecast future costs leads to cost overruns and blown budgets, which is why having a product that provides the most up-to-date information and monitors your budget is important. There is no use in budgeting if it’s not being monitored. Let me repeat: an unmonitored budget is useless.

    Timely visibility and monitoring your budget fall under financial control of your cloud—one of the three pillars of cloud governance. Cloud governance includes the development and implementation of budget controls, as well as controls to manage access and ensure ongoing compliance.. A cloud management product can help with this by not only keeping your budget under control and alerting you before you go over that budget, but also by finding saving opportunities through ongoing optimization.

    Using these tools means you can automatically find out about ways to save your organization money.

    The other two pillars of cloud governance, managing access and ensuring compliance, also impact your overall cost in the cloud. A robust governance and management solution establishes proactive protocols that can automate tasks such as account setup and ensuring compliance with your security standards. Automating controls will save your organization time and money. Monitoring and ensuring that your cloud is secure will help you avoid costly security breaches. When adopting the cloud, a plan for implementing cloud governance should be at the forefront to help you realize the cost savings of cloud.

    Despite the initial costs of scaling to the cloud, in the long term, cloud adoption does result in cost savings. Once organizations move away from managing on-premises data centers and implement cloud governance in their cloud environment, that’s when opportunities for innovation can happen due to time and money being saved. For example, when Riso, a printer and digital copier manufacturer, migrated to AWS, the company cut its total IT operational costs by 55%. Avery Dennison, a manufacturing company that specializes in labeling, saw an annual run rate savings of $5 million due to investing in cloud-first initiatives. These are just some examples of how the cloud has helped companies optimize their costs. It can be possible for your organization to reap similar benefits with proper planning and the implementation of cloud governance.