devopsy.kinsta.cloud

Tag: application development

  • OutSystems Employs More AI to Accelerate Low-Code Development

    OutSystems Employs More AI to Accelerate Low-Code Development

    OutSystems today at its online NextStep 2020 conference announced it is making more extensive use of artificial intelligence (AI) to accelerate the building and deployment of low-code applications.

    The company unveiled AI Assist to automate, guide and validate processes throughout the application life cycle and Architecture Dashboard, which employs machine-learning algorithms to enable IT teams to visualize complex application architectures.

    OutSystems is also adding Workflow Builder to visually map complex business processes and automatically generate workflow-based applications, and Experience Builder, which enables developers to rapidly prototype mobile applications based on common patterns and flows.

    Finally, OutSystems has added Integration Builder to simplify integration with packaged applications such as those from SAP and Salesforce.

    Mike Hughes, senior director of product marketing for OutSystems, said the AI capabilities being added extend an existing TrueChange capability based on machine learning algorithms that checks for bugs and architecture errors, analyzes the impact of changes to components and application dependencies, provides team and architectural governance and monitors performance in real-time. The goal is to automate as much of the DevOps process as possible on behalf of developers of low-code applications, he said.

    In general, he noted, low-code tools are being embraced by professional developers to accelerate the development of even the most complex applications. In fact, while low-code tools may make it possible for end users to participate in the development process, there are not many so-called citizen developers building low-code applications on their own.

    Adoption of low-code platforms is accelerating at a time when many organizations have increased their reliance of software-as-a-service (SaaS) applications. While each SaaS platform makes available either a low-code or no-code tool for customizing the application environment, Hughes says enterprise IT organizations require tools that enable them to build and deploy custom applications and workflows than span multiple SaaS platforms and on-premises applications. That issue becomes especially apparent to any organization looking to accelerate digital business transformation initiatives in the wake of the COVID-19 pandemic, added Hughes.

    In fact, he noted, the one thing the pandemic has reminded everyone is that change is the only constant. IT organizations need flexible application development and deployment tools more than ever.

    Of course, there’s no shortage of options when it comes to low-code and no-code tools. In fact, Hughes said the distinction between these tools is starting to blur as platforms such as OutSystems make different capabilities available to different classes of developers depending on the use case.

    In the meantime, as the number of low-code applications that are being developed continues to increase, organizations should make sure they have the DevOps processes in place needed to deploy and update these applications more frequently. After all, it doesn’t take long for a backlog of low-code applications waiting to be deployed by an IT team to build.

  • TechStrong TV: The Low-Code Movement, With ServiceNow

    TechStrong TV: The Low-Code Movement, With ServiceNow

    ServiceNow is well-known for its IT transformation products and customer/employee workflows. But the company has another technology, App Engine, a low-code application platform that lets people build applications faster than they can on any other platform.

    In this TechStrong TV interview, I speak with Josh Kahn, general manager of the platform business unit at ServiceNow, about App Engine and the evolving low-code landscape, which is a very hot topic in today’s business environment. The video is below followed by a transcript of our conversation. Enjoy!

    Transcript

    Alan Shimel: Hey, everyone. Thanks for joining us on another episode of TechStrong TV here on Digital Anarchist. Really happy to be joined for this episode by Josh Kahn. Josh is the general manager of the platform business unit over at ServiceNow. Hey, Josh, welcome.

    John Kahn: Alan, thank you for having me. Really excited to be here today.

    Shimel: We’re excited to have you here, man. Let me just make sure I didn’t mess up anything with the title or the unit and everything, right?

    Kahn: Got it exactly right. That’s right.

    Shimel: Cool, man. Appreciate it. So Josh, look, our audience doesn’t really need an introduction to ServiceNow the company. You know, it’s probably one of the most successful companies over the last two/three years in the tech universe, if you will, right? Phenomenal growth, phenomenal story. But you’re the GM for the platform business unit, and I don’t know if our audience is as familiar with that. I think a lot of people think of ServiceNow with ITSM and those kinds of things. What exactly is the platform unit there?

    Kahn: Yeah, so the platform business unit actually has two parts to it. One is taking requirements from all of our different lines of business and defining shared capabilities in the platform itself that they use to build their products. The other part is defining the things that our customers and partners need to build their own applications on our platform just like we do. And the platform at ServiceNow really is a single platform. It’s one platform, one architecture, one data model. So we make sure that the same capabilities our own businesses have to build on are available to our customers and partners. It’s the job me and my team have to make sure that that’s world class for all of the developers out there in our customers and our partners and in the ecosystem

    Shimel: Sure. Excellent, man. Josh, if you can, share with our audience a little bit, what’s your background

    Kahn: Yeah, so I’ve been in platforms for a long time. I actually graduated college and my first job was at Accenture where they said, “Hey, you’ve got to do some development work before you can get on to being a business analyst.” And I thought, oh man, I can’t wait to be a business analyst. I’ll power through this development stuff, and I just loved it, and I spent the first years of my career programming and programming in C on Windows 3.1 and doing three-tier client server systems. That was a lot of fun. At some point, the internet came along and I realized, wow, that was a much better architecture so found my way to Netscape.

    Shimel: A little bit

    Kahn: Say again.

    Shimel: I said a little bit better.

    Kahn: Yeah. So I found my way to Netscape which was the only internet company at the time and ended up there working on the Netscape 1 platform in a product management role and just http: my career continued to focus on development environments, platforms, and helping people bring solutions to market. Fortunately, I’ve been at ServiceNow for about four years and am continuing to really focus on how do we build a platform that lets our customers unleash the innovation in their organizations and create the kinds of applications that we create ourselves today? We want to bring that to our customers. That’s a really fun job to have.

    Shimel: Excellent. You know, it’s funny. About two weeks ago I interviewed Tom Jermoluk. He was at Netscape obviously with Jim Clark, and he went off with Jim on a bunch of other adventures. They’re still adventuring, right? Tom is now at Beyond Identity or something like that. But yeah, we were talking about – I mean those Netscape days, you’re of an age, I was an OS/2 guy rather than Windows 3.1, truth be told. But you know, you’re at an age where Netscape, people forget I mean that was the opening of the internet commercially, right, without Netscape and what went on there. It was crazy times. Unbelievable times.

    Kahn: I mean the thing that I was building an application where we designed a billing system for an airline to bill back and forth and exchange services and fees and they just sort of wash out dollars at the end of the month and somebody wrote somebody else a check. You know, one airline painted the other airlines planes and then the other airline de-iced. It was a really complicated data model to build, and we had to roll it out to all these different hubs but we tackled the data model problem. We tackled the logic problem. The thing that we couldn’t get around was the messaging infrastructure. That’s the thing that the internet made so easy. I mean among many things, I think it’s one of the reasons that it’s unlocked so much potential is it’s so easy to get a message from point to point for an application.

    Shimel: Absolutely.

    Kahn: It’s really, really changed the –

    Shimel: Yeah, no, it was revolutionary. But you know, you bring up a good example and that is kind of what development was like back then versus what development can be like today. That kind of brings me up to App Engine and what I wanted to speak to you a little bit today, right, where, look, man, it’s – thank God you don’t have to do what you were doing in 1996/97/98 to develop an application today, right? We do have the internet. It does make a lot of things easier.

    But we also live in a time of low-code no-code revolution where you don’t have to be a C-plus developer anymore to put together an application rather quickly. Rapid application development, right? And so I think a lot of people who are familiar with ServiceNow, Josh, they may not be familiar with App Engine and what it brings. So talk to us a little bit about – if you don’t mind, talk to us a little bit about App Engine.

    Kahn: I’d love to, and I think you’re absolutely right. We’re well-known for our IT transformation products, customer workflows, employee workflows, less known for App Engine. So we focused App Engine on providing an application platform that lets people build applications faster than they can on any other platform. A lot of the first questions I get from customers is, “Hey, I have a number of application platforms and I can build – yeah, I want to go faster but what kinds of applications is your platform really best for?”

    And one of the things that we’ve really done, in addition to making it possible to build low-code and build fast, is focus on digital workflows. So digital workflows are ways to drive business process across the organization. A lot of organizations were building those pre-COVID because they had digital transformation initiatives, but the COVID pandemic put the speed and the need of digitizing business process to the forefront of every organization, every government. It’s really just been a catalyst for building applications that drive business process, run across a lot of different systems, and create those sort of digital outcomes.

    Shimel: Great. You’re preaching to the choir here, and we see it every day. Six years’ worth of digital transformation in about four months. That being said, digital transformation is way big, right? I probably went out of the screen on that. I apologize. It’s very big. But low-code no-code allows us to almost take it in bite-sized chunks. It allows us to get our hands around it without the huge development teams and all the languages and all that and really – especially like now in COVID, right, I need an application that does this now, right? We just sent everyone home remote. I need to be able to do this now. And so things like App Engine enable that sort of thing. Do you have any maybe examples you could share with us?

    Kahn: Absolutely. Yeah. I think you’re absolutely right. And we see a world where, look, people who write software and people who code are still going to be incredibly important, right?

    Shimel: No doubt.

    Kahn: The issue is demand. There’s just too many applications to build so we’ve got to help people who don’t know how to code but do know business process to create those applications. That’s what we really tried to do with our low-code platform. And I’ll give you some examples, and a lot of the kinds of applications that people build in a no-code way tend to be the simpler variety of applications. So a few that we’ve worked with customers on. One they call Opendoor. So this allows all of their employees to submit ideas or concerns to the executive team. It was an idea at this organization that started when it was a very small company.

    As the company has grown and grown, it’s no longer feasible for people to walk into the CEO’s office and he was getting 60,000 e-mails a year with ideas for how to do things better or how to mitigate risk. And so they had someone build an application using low-code technology called Opendoor, and any employee can go on a mobile device, submit an idea or a concern and it gets routed to the right executive team in the corporation at the executive level to address so it doesn’t all go to the CEO. If it’s obviously an issue that should be thought of in the finance department, it goes straight to the CFO. If it’s something that should be thought of in the human resources department, it goes straight to the talent officer. But it’s a way that employees are able to get those requests, visibility to the executive team. It was built without developers writing code. It was simply a no-code application process.

    Shimel: Excellent.

    Kahn: You know, I think there’s also an interesting dynamic, too, where we see an opportunity for people who write code to support those – we call those citizen developers. A lot of people use that term citizen developer. So what we think of as a citizen developer is someone who is technical but doesn’t typically write code. So I’ll give you an example. One individual was the person in her department that they would always go to and say, “Hey, we’re going to evaluate a SAS application for project management. Can you go look at these three apps and tell us which one you think is best?” So she really knew technology. She could log in, find her way around, configure things but wasn’t going to go write code to build an application herself.

    What we’ve seen with the citizen developers is they can get pretty far into building an application, but oftentimes they hit a cliff where they need help from somebody who can really write code, whether it’s an integration with a system of record or some kind of complex business logic that’s just a little bit beyond the capabilities of the no-code tooling that they’re using. That’s where we think it’s really important to bring these citizen developers and the developers who write code together on a single platform so that they can support each other and we can get scale from the citizen developers but also have the pro code developers do the tough stuff that really empowers and enables the citizen developers.

    Shimel: You know, Josh, that is so dead on to part of what DevOps is about, right, which is all of us working together in that thing. I wanted to let you finish your thought, but a couple of comments on it is number one, when we look at the full spectrum of the kind of applications modern enterprises, modern organizations need to function, yeah, there are some things that are really hard. They need applications that are really hard to build, have very, very complex workflows and very complex needs or requirements. You really do need to be a high-level developer, let’s call it, a really high level experienced developer to pull that off.

    But I would venture to say that that’s probably 20 percent or less of the kind of apps – when you look at the full spectrum of apps that people use, it’s probably 20 percent or less. I think the majority of the apps are rather mundane, right? They don’t need the rocket scientist to develop. If you just give someone some good building block tools, they could put together 90 percent of the functionality they need, 95 percent of the functionality that app needs to be functional and effective.

    And I think, you know, we said it before, there’s something like 40 million, 42 million developers in the world was the last number I saw, growing 20 percent a year. Would be the fastest growing country on Earth. It’s still not enough. As you said, there’s still not enough developers. So part of what we have to do in DevOps, part of what we do in digital transformation is say, “Hey, if we don’t need one of those 42 million on this but we have someone here doing it, let someone here do it.” We don’t need that pro developer, if we can call it that, to do everything every time. And so the citizen developer as the term is coined, right, becomes more and more important to do more and more of these 80 percent or so apps that don’t require it, right, that don’t require that pro guy or pro gal.

    And so the real question for organizations, and I’m sure this is something you deal with, is how do you empower those people? With an App Engine maybe. But sometimes – Josh, again I’d like to hear your voice – it’s not just the tool. It’s making the CIO, the IT department aware that, hey, let’s not just dump everything on that developer’s desk because he is dealing with security and DevOps and testing and deployment. He’s got enough on his plate. Are there things we can take off the plate for the citizen developer and get it done quicker, cheaper, and just as functional?

    Kahn: Yep, absolutely. So it’s really interesting you say that because we see a pretty common journey with a lot of our customers that have great success with App Engine and it tends to start with the team building a business-critical application of some sort. So I’ll give you an example. Academy Mortgages is one of our customers, and I talked for a bit with the CIO about their journey, and I’ll describe it in terms of what Academy Mortgage did, but this is a very common journey that plays out in lots of our customers.

    So Felix was describing first they had a couple of business-critical applications they built out on the platform. So Academy Mortgage does loan origination. Then a lot of times they will package them up and sell them to investors. So there’s a process when you sell them where there’s a set of stipulations that have to be attested to as a part of that process. So they had a hundred people that manage that stipulation process.

    So they built a digital workflow on our platform with App Engine, and they were able to do that process with half the number of people. So they reduced from 100 people to 50 people to process even more loans than they had in the past. You say, well, hey, where did those 50 people go? And I asked Felix that question. He’s like, “Hey, these are people that know the mortgage industry. They’re incredibly knowledgeable. They’re great employees. We redirected them to other work.”

    So this is a case where they took a business-critical application, had a huge cost savings and increase in revenue generation for the organization through the combination of saving those people and redirecting. But that was only step one. You know, the next thing is they built a small center of excellence. So they put, not huge, three people in a team that were like the experts on building App Engine applications. That team was able to build over 50 applications for 27 different departments at their organization. So now they’ve gone from a couple of big wins – I mentioned one of them, but they had a couple of big wins – to a small center of excellence team and then they move on to phase three.

    Once they’ve had that broad sort of impact with the 50 applications, they start empowering the rest of the organization to build the simple ones, right? So Felix calls it power to the people. He wants to let the citizen developers do the really simple stuff and his CEO team is gonna continue to do the high impact, high complexity, real business value-driving applications. So the vision that you laid out, Alan, is exactly what I’m seeing our customers doing is combining both professional developers for the really complex stuff and citizen developers for the simpler applications

    Shimel: I mean it’s the right person for the right job using the right tool, quite frankly. So you know, Josh, I, like the rest of the world, hope and pray that this COVID thing doesn’t stick with us forever and we come out the other side somehow into what the new normal is. In this new normal, what role – I mean do we go back – we can’t go back to the way it was before, but what role does low-code no-code play in this whole thing going in this new normal that emerges

    Kahn: Yeah, I mean it’s incredible the amount of processes that are being re-engineered across every industry. Anything that depended on contact, human contact, paper changing hands, two people being in the same place is now being re-engineered to become contactless processes. And so for any organization will have hundreds or thousands of those processes, and to think that you’re going to need a skilled developer to write code to reengineer each one of those processes is – you know, you’re going to put the timeline out too far for your organization to be successful. You’ll put people’s lives at risk. You’ll put your organization at risk.

    And so the pace of digitization is just going through the roof. The only way to really keep pace with that digitalization is to empower citizen developers. So what we’ve seen in our customers is a real demand to empower their citizen developers, their business analysts to reengineer business process. They know that process well. If they can be armed with tools that allow them to model it, define it, and deploy it, then the organization can create transformation at scale. That is what everyone is looking for in this post-COVID era.

    Shimel: Absolutely.

    Kahn: We’re dealing with it today, but even as we move out those processes will continue to be reengineered and change.

    Shimel: Agreed. I think, look, the whole thing around business process automation, robotic process automation, RPA, another popular topic and I think the other thing is we’re interviewing a analyst a couple weeks ago and they said something like we’ve done six months or six years of digital transformation in a couple of months.

    The interesting thing about that is it’s almost like putting money in the bank. So that money’s there now. So when and if this COVID enters, you don’t start with zero in the bank. You start with what you’ve already deposited, right, and then we build on that. I think that’s an important thing for people to remember in that all of these investments we’re making now and empowering our citizen developers with tools like App Engine. They’re now short term or diminishing assets. These are long-term investments we’re making that will serve us well going out beyond the immediate crises or whatever you want to call it.

    And it’ll be interesting because I feel like, you know, so like you, we both came of an age, right, when the internet came onboard and we had this concept of internet time, right, this kind of crunch time. In internet time, it goes three times faster than the real world. I think we have now introduced like COVID time, and I don’t mean to be – look, a lot of people are suffering. A lot of people are dying. But we have compressed timeframes in terms of how fast we’re developing apps, in terms of how fast we are bringing onboard these things. I don’t think that goes away. You can’t put that genie back in the bottle.

    Kahn: You can’t. You know, I think there’s a perfect example of that that we saw with the City of Los Angeles. So the mayor’s office wanted – this is early on in the pandemic. They wanted to roll out COVID testing for all of the citizens of Los Angeles, and they called ServiceNow, and we brought in one of our partners on a Saturday morning. The mayor was saying I have a press release on Sunday night. I need to roll out the testing application so that when we tell people there’s testing, we can tell them where to go to sign up. And so this partner, Cask was our partner that did this, they assigned six developers who worked through the night, did a demo for the mayor’s office on Sunday morning, and by Sunday evening they had this application up and running for 4 million citizens of Los Angeles, eventually expanded to the county so you get to 16 million people.

    But it’s interesting because it wasn’t a registration form. It was a really powerful logistics app. Behind the scenes, they had to have agents who could route the request to the right site to get tested. They had different sites and each site had two-hour windows where they didn’t want to put too many people in a window because then you have –

    Shimel: Unbelievable.

    Kahn: – too close together. So you want to talk COVID time, I mean within 48 hours they were able to build an application that handled a complex logistical challenge and make it available for 4 million people. You know what I mean? Even on the internet.

    Shimel: Fantastic.

    Kahn: – that would be inconceivable.

    Shimel: Crazy. I don’t want to get into politics, but why couldn’t we do that nationally, man? You know, if it worked for L.A. for a couple of million? But let’s not go there. Josh, we’re about out of time. I want to thank you for coming on and sharing a little bit with us, talking, learning. You know what we didn’t mention? For people who want to find out more about App Engine, where can they go.

    Kahn: Yeah, look, best place to go is ServiceNow.com. You’ll drill into the platform area, learn about App Engine. If you’re interested, you get your own developer instance and you can be up and running building applications in no time.

    Shimel: Fantastic, man. Hey, thanks for joining us. Josh Kahn, VP of the Platform Business Unit at ServiceNow, talking to us about App Engine, empowering citizen developers around the world. This is Alan Shimel for TechStrong TV. We’ll be right back with our next guest.

  • How ‘Some-Code’ Platforms Perform a Balancing Act

    How ‘Some-Code’ Platforms Perform a Balancing Act

    Recently, there’s been a surge of interest in visual programming models, all with varying degrees of user-friendliness. These low-code platforms utilize drag-and-drop elements to help citizen developers stitch together applications, avoiding the complexities of hard-coding connections. Such platforms are crucial amid a developer drought and shine in their usability. But, how usable is too usable?

    “A low-code platform should abstract complexity, yet always offer a way under the hood,” said Jesse Orshan of WayScript. In other words, the platform should never get in the way of advanced mechanics. To do so, “some-code” platforms balance usability and customizability.

    I recently spoke with WayScript co-founders Jesse Orshan and Lane Eden to see how some-code combines traditional coding and low-code. As opposed to a 100% visual no-code experience, some-code focuses on operational automation while granting a peek under the hood. Read on to see how the notion of “some-code” may set itself apart from the larger visual programming movement.

    Why Just ‘Some-Code’?

    To understand some-code, consider the greater industry. As I recently covered, many factors are spurring a low-code revitalization. One is the need for rapid development for internal tools. Orshan acknowledged how “cumbersome, costly, and time-consuming it is to build and maintain internal tools.”

    Many developers are fully capable of, for example, programming a native iOS app. Yet, turning that into a business application with a back-end running in the cloud with the proper databases, server arrangement, access management, and continuous deployment strategy is a whole different story.

    “The idea is to blend coding and low-code,” Orshan said. “Scaffolding is the most difficult part of development.” Therefore, a some-code platform provides an operational toolset—a framework that enables developers to focus on their application logic.

    Some-Code Leverages Event-Driven Architecture

    Event-triggering has become common within modern programming. Triggering is necessary for automating tasks and workflows involving interconnected tools.

    For example, say an internal tool for a sales department must automatically update a lead spreadsheet and send a Slack notice once an email is received from a prospective client. This process requires scripting a series of API queries involving Gmail, Salesforce and Slack APIs.

    Though the logic seems simple from the outset, hooking together applications is not a trivial task. “Building a robust triggering system that can scale with your load is a very complicated thing to do,” said Eden. HTTP API integration is a unique skill that not all possess. “Thereʼs an understated art to building good APIs,” according to an Increment blog post.

    The hurdles of API integration have already given rise to drag-and-drop workflow services such as IFTTT and Zapier. Some-code applications, too, could quickly enable developers to mix-and-match APIs in the programming language of their choice.

    Other Some-Code Benefits

    Internal tooling can be a big pain point. It’s “bespoke and custom to every business,” said Orshan. Utilizing drag-and-drop components alongside an IDE, some-code could lower the DevOps barrier for constructing enterprise-grade interconnected applications that require testing, auto-build and deployment automation. Here are some other some-code benefits:

    • Abstracted type system: APIs are at the heart of many low code initiatives, enabling integrations with third-party tooling to enable event-based modeling. Some-code could enable developers to program logic without hardcoding integrations, offering a “unifying system abstracted type system,” noted Orshan.
    • Flexibility: A unique prospect of some-code is that it could retain the programming language developers are accustomed to.
    • Aids rapid development: Some code seeks to abstract things away, making it easier for developers to quickly solve core problems.
    • Fill integration talent gap: A lack of specialized talent encompasses integration engineers and IT security disciplines. According to OutSystems, 45% of businesses adopt low-code to reduce dependency on hard-to-hire technical skills.

    The Reality of ‘Citizen Development’

    Problem-solvers come in all skill sets. Some are programming novices with little know-how, and UIs cater well to this group. However, only 8% of companies say they have business users utilizing a no-code platform without IT intervention, according to OutSystems’ 2019 State of Application Development report. Instead, the majority of low-code users are professional IT developers, at 69%.

    “There is a place for visual elements, and there is a place for coding,” said Eden. “Sometimes, writing a function in Python is just way more efficient.”

    Though low-code providers may trumpet the citizen development ideal, in reality, in 2019, only 20% cited enabling citizen developers as a key reason for adopting low-code. Perhaps this need will increase subsequent a fully remote economy and a developer talent shortage. Yet, as of now, experienced software developers are the ones using and benefiting from low-code tools.

    Final Thoughts

    The usability of no-code empowers business technologists to build basic workflows, yet lacks deep customization abilities. Yet, pure manual programming slows when you consider the many web APIs, differing standards and DevOps tooling integrations necessary to deploy modern enterprise-grade cloud applications.

    The premise behind some-code is to help skilled developers stitch the operational scaffolding around their source code, helping integrate, validate, test and deploy software in a more streamlined approach. This style could be a better balance for advanced developer teams requiring an extra push.

    “Our guiding philosophy is there should always be a way to get under the hood,” said Orshan. “The platform should never get in the way.”

  • OverOps Taps Into Git Repos to Accelerate Code Reviews

    OverOps Taps Into Git Repos to Accelerate Code Reviews

    OverOps this week announced it has added support for a git blame and automated source attach capability to its namesake platform for analyzing code that surfaces both root cause data for every error as well as the identity of the developer who owns that code.

    Eric Mizell, vice president of solution engineering at OverOps, said once those developers are identified, the OverOps platform will automatically alert them about the errors in the code.

    Every Git repository provides access to a git blame tracking command that identifies the authors of source code and the last time files were modified source file. The git blame and automated source attach capability extends that tracking command to accelerate the process of fixing errors that are discovered by the OverOps platform, which leverages machine learning algorithms and other forms of advanced analytics to perform static and dynamic analysis of code to detect errors in code before a DevOps team promotes code into a production environment.

    Mizell said this latest capability accelerates the remediation process by automatically routing critical alerts to the developers responsible for the last commit.

    Ultimately, DevOps teams should be able to spend less time in “war rooms” trying to resolve issues in a production environment because errors in code will have been addressed much earlier in the application development life cycle, he said.

    Naturally, there’s a lot of sensitivity when it comes to analyzing code. It will be up to each IT organization to determine the level of visibility into the quality of the code being created by each developer. Most organizations will simply route alerts to individual developers to address without making each issue the topic of a team review. However, organizations may want to track what types of errors are being made consistently to better inform training requirements.

    Regardless of approach, most experienced developers don’t want to spend a lot of time discovering the same issues multiple times when reviewing code someone else wrote. Tools that automate the discovery of those issues should enable development teams to focus their efforts on the more complex issues that inevitably arise when building modern applications.

    In the wake of economic downturn brought on by the COVID-19 pandemic, there’s a lot more pressure on DevOps teams to become more efficient. In many cases, the velocity at which applications need to be built, tested and deployed in the wake of the economic downturn has increased as organizations invest more in digital business transformation.

    Not every developer will enjoy have the code they wrote analyzed by a machine. However, most coders take pride in their work and would prefer to address in their own way any issue that may arise. The challenge is putting in place a code review process that results in better code being deployed faster without unnecessarily antagonizing the most valuable contributors to the digital success of any organization.

  • Survey: Organizations Knowingly Deploy Vulnerabilities

    Survey: Organizations Knowingly Deploy Vulnerabilities

    A survey published today by Synopsys, a provider of electronic design automation (EDA) and application security tools, finds nearly half (48%) of respondents admit they consciously push code with known vulnerabilities into production because of time constraints.

    Based on a survey of 378 cybersecurity professionals conducted by Enterprise Strategy Group (ESG) on behalf of Synopsys, the survey also finds 65% of respondents said developers in their organization are participating in a formal security training program.

    However, only a third (34%) are employing application security tools across more than three-quarters of their codebase. And, as the rate at which code is created increases, only 30% expect they will be able to protect more than three-quarters of their codebase 12 months from now despite the fact that more than half (56%) said they apply highly integrated sets of security controls throughout their DevOps process.

    Nearly three-quarters (72%) also said their organization makes use of 10 or more application security tools.

    Patrick Carey, director of product marketing for the Software Integrity Group at Synopsys, said the survey shows many organizations are making trade-offs between potential risks to the business and the desire to deliver software faster. As the rate at which updates to applications are being delivered increases, thanks largely to the adoption of best DevOps processes, Carey noted it becomes easier to justify knowingly allowing vulnerable code to be deployed in a production environment. The assumption is that most severe vulnerabilities will be prioritized while less critical vulnerabilities are addressed over the course of the application lifecycle management process.

    In most organizations, the survey finds either a development manager or the application security analyst is responsible for making these decisions. Just under a third of organizations make both jointly responsible. More than three-quarters (78%) also report their security analysts are directly engaged with their developers. Just under a third (31%) work directly with developers to review individual features and code, compared to 28% who work with developers on threat modeling and 19% that participate in daily scrums.

    The survey finds that integrations that complement high-velocity application development process are critical for 43% of respondents. As a result, more organizations are looking for application security tools that can be directly embedded within an integrated development environment (IDE), noted Carey.

    However, the fact that application security tools are shifting further left does not mean organization won’t also have to invest in other tools that are embedded within DevOps platforms that manage runtime deployments, added Carey.

    As is always the case when it comes to best DevSecOps practices, the two biggest challenges are getting the right tools in the hands of developers and then aligning workflows between development and cybersecurity teams. The survey suggests substantial progress has been made on the latter, while tools for developers are increasingly becoming available. After all, most developers want to do the right thing when it comes to application security. The issue is determining what precisely that means.

  • Automation: The Human-Free Zone Approach to Software

    Automation: The Human-Free Zone Approach to Software

    Humans hate repetitive manual tasks. We suck at them—we make mistakes, lose concentration, get bored. Throughout history, humans have instinctually developed automation to keep us away from the hazard-prone, tedious work of these tasks.

    In software, we use configuration management, deployment tools and lean/agile processes born out of factories and the automation principles established there to automate the software factory. Utilizing automation reduces software errors and increases reliability and productivity by allowing the work performed to scale to hundreds and even thousands of systems.

    As we’ve written scripts and functions to help ourselves, we’ve had to implement access control, least privilege, two-person rule and other security principles to secure against the human threat and to prevent catastrophic loss through either a malicious actor, leaked credentials or other type of compromise. And this problem gets more complex and difficult the more automation is involved. However, what if we harness the power of automation to solve our security risks—to remove the human threat mostly or entirely from production by enforcing a single path to production via CI/CD pipelines, building and deploying signed artifacts and system hardening including explicit removal of human/remote access?

    With this, we can validate the chain of custody on all changes to the system while also proving that outside actors cannot make unauthorized changes. This is what we’re looking for when we talk about DevSecOps.

    Automation to the Rescue

    Here are the processes humans should be fully or at least partially removed from to optimize software effectiveness, security and efficiency:

    • Code and pipeline.
    • Artifact deployment.
    • Automated access.

    Code and Pipeline (partial human interaction)

    Let’s start on the left, with our code and pipeline. The rules here are simple and familiar. We start with source code management and the two-person rule. No one individual can write and commit code without approval from someone else. Implementing the two-person rule as well as securing production access ensures that access control happens solely within the pipeline and we have full enforcement of the two-person rule. We can have a full team review along with static code analysis, but the core rule is that no one person has the power to write and commit code, ensuring that a single human cannot be responsible for making a change.

    The code repository is watched by our pipeline with the task of testing, building and verifying a versioned artifact. This artifact is everything in our code at a moment in time. When we think about rollback scenarios, we’re thinking about deploying the previous artifact. This artifact is checksummed so we can attest to its integrity at any point, and we can validate the checksum by pulling the code and building it ourselves.

    Artifact Deployment

    And we need an artifact for not just our application code from development, but also based on what the infrastructure looks like from Operations. This is part of the promise of DevSecOps: Ops writes code that gets checked into repositories just like Development. This allows us to pair our application artifact with our operations artifact. These artifacts together are what we deploy—the system at a moment in time and the application at a moment in time. So, at this point, we’ve established that two humans (at least) have looked at the source code and, once committed, that our pipeline has picked up those changes, performed static code analysis on it and created signed artifacts, ready to be deployed to a test environment. Now that we have our artifacts, we need to deploy them.

    Again, the goal is to not use humans, so after our artifacts are built we must test deployment. The way we ensure security is having the pipeline push the artifacts to a secured artifact store and our systems pull from there as we approve environments to receive the update. This accomplishes two important things: First, by having a push from our pipeline, we again maintain that chain of custody tracing back to source control. Second, we limit which environments are updated by having those systems subscribe to the appropriate artifact stores. The only work humans do here is performing testing and deciding when to promote. The automation actually takes care of the actual promotion work. Now finally, we have the ability to run our artifacts in production.

    Automated Access

    The idea of a continuous delivery pipeline isn’t new and is practiced by many teams today. What we’re going to add to this is a production system that does not have inbound access.

    Because in this design systems pull from the artifact store, the only rule needed is outbound from production to the artifact store. This means you can disable remote management entirely, trusting fully in the chain of custody established in the pipeline. This trust, along with ensuring remote management is disabled, establishes the human-free pipeline. We have shifted user access focus into source code repositories and into the management of the CI/CD pipeline. We have visibility into every stage of the process and eliminated the need for users to have login credentials to production systems. The credential management is also a function of pipeline management, drastically reducing its complexity.

    This is what it means to practice DevSecOps—understanding how automation actually enables the security team to reduce the complexity of our security model and gets security out of the role of blocker and into enabling the business.

  • Vercel Makes Front End Applications Faster

    Vercel Makes Front End Applications Faster

    Vercel this week extended its effort to redefine how front-end applications are developed to reduce dependencies on backend systems.

    The company has created Next.js, which makes it possible to build web applications using a framework based on the React library for creating user interfaces that enable both static generation (SSG) and server-side rendering (SSR). The latest version a Vercel Edge platform based on Next.js has been re-architected to provide faster routing and better caching.

    Vercel CEO Guillermo Rauch said that capability results in a 10x performance improvement that, among other things, enables applications that employ the React framework for user interfaces to automatically pre-render, code-split and hot-reload, with no configuration required.

    Fresh off raising $21 million in funding, Vercel is committed to making it easier to build highly interactive applications that run in real-time by leveraging Next.js, Rauch said. Vercel claims there are more than 30,000 sites running Next.js in production at organizations such as Airbnb, Hulu, Nike, Ticketmaster and Uber.

    Rauch said most developers are looking to take advantage of frameworks that enable them to treat the underlying IT infrastructure as if it were serverless whenever possible using a familiar JavaScript-type tool.

    At the same time, Vercel is making it possible to run Next.js on a local host, which enables integration with React Refresh from Facebook to enable real-time page change visualization on local hosts. New pages can also be pushed automatically whenever data changes. In addition, developers can replicate all the customized functions from a cloud on a local host.

    Finally, the distributed caching provided via Vercel’s content delivery network (CDN) eliminates the need to rely on legacy CDNs that often require repetitive round trips, he said.

    As frameworks such as Next.js are embraced, DevOps teams will need to adjust to applications capable of providing richer application experiences without relying as much on backend infrastructure. That shift has implications for everything from the amount of network bandwidth consumed to the performance of web applications. Rather than continually focusing on backend infrastructure to optimize application performance, Rauch said the Vercel platform employs caching, routing and a React framework to optimize application performance.

    It’s not clear whether or how much DevOps teams will nudge developers toward frameworks such as Next.js to develop web applications. In theory, the more efficient web applications are the less time and effort that will be needed to monitor applications. In addition, the overall size of the backend IT environment might not need to be as large.

    One way or another, however, the way web applications are developed is evolving. That doesn’t mean JavaScript-based frameworks will eliminate the need for programming languages such as Java. However, the preponderance of applications relying on Java to invoke backend services soon might be reduced substantially.

  • How to Source Vulnerability Data for True DevSecOps

    How to Source Vulnerability Data for True DevSecOps

    Open source comes with code vulnerabilities that must be considered in the DevOps process

    The war between open source and “only proprietary code” is long over. Open source won the day by convincing the opposition of the benefits of joining the open source community. “Vulnerabilities in the Core,” a report published by the Linux Foundation and the Laboratory for Innovation Science at Harvard in early 2020, explained: “Open source has now become an integral component of the modern economy and is a fundamental building block of everyday technologies like smart phones, cars, the Internet of Things, and numerous pieces of critical infrastructure.”

    Development teams have embraced open source for its inherent strengths: efficiency, speed, quality and innovation. As one Gartner report puts it, “In most modern DevOps development projects, the majority of code used in an application is made up of open source.”

    But open source comes with code management responsibilities that DevOps teams need to consider. Open source has the same security risks that plague all software—bugs or other defects that could be exploited by hackers. While larger open source projects have communities that generally issue patches for vulnerabilities much more quickly than commercial vendors, thanks to thousands of “eyes” on the code, keeping open source software secure is not as simple as enabling auto-updates, as is done for much commercial software.

    Unlike commercial vendors that automatically “push” patches out to users, open source operates on a “pull” model. As patches are made available, consumers of the open source component first need to be aware that the patch is out there and then “pull” it from a repository to accomplish the needed update.

    The NVD and Its Timeliness Problem

    Public sources such as the National Vulnerability Database (NVD) are a good first step for information on publicly disclosed vulnerabilities in open source software. However, you need to keep in mind that there can be significant lags in data reporting, scoring and actionability of the data in an NVD common vulnerabilities and exposures (CVE) entry, with some research reporting an average 27 days between the initial announcement and NVD publication. The format of NVD records also makes it difficult to determine which versions of any given open source component are affected by a vulnerability.

    For example, the Linux vulnerability CVE-2016-5195, popularly known as Dirty Cow, was announced Oct. 19, 2016. Proof-of-concept code exploiting the vulnerability was available a full two weeks before the Nov. 10 listing for the CVE in the National Vulnerability Database. That’s two weeks in which anyone relying on the NVD would have been left in the cold.

    The problem is more recently reflected in the findings of the 2020 Open Source Security and Risk Analysis (OSSRA) report, produced by the Synopsys Cybersecurity Research Center (CyRC). Four of the top 10 vulnerabilities found in the audited codebases did not have CVEs associated with them at the time of the report’s publication. The vulnerabilities without CVEs included high-severity flaws in jQuery and FileAPI. Those security issues can be fixed with updates of the respective open source components, as can the majority of vulnerabilities listed in the CyRC OSSRA report. But, to patch any of those CVE-less vulnerabilities, you first need to be aware of them.

    The issues impacting the NVD’s ability to publicize security vulnerabilities make it unwise to rely solely on that organization for vulnerability information. While I’m not recommending abandoning the NVD, DevOps teams should look to a secondary source of information that will provide better notification of vulnerabilities affecting your codebase and, ideally, supplement notifications with technical details and upgrade and patch guidance.

    Augmenting NVD Vulnerability Information

    Many commercial software composition analysis (SCA) solutions can provide you with more timely, richer vulnerability data than the NVD alone, proactively finding issues and helping you fix them quickly when warranted. If you’re considering an SCA solution, you should ask your vendor what they offer in the form of security advisories and alerts.

    For example, consider the Common Vulnerability Scoring System (CVSS), an industry standard for assessing the severity of a vulnerability. The CVSS score (v2 and v3) provides an overall base score that takes both exploitability and impact into account.

    A robust SCA solution will provide a temporal score in addition to the CVSS base, exploitability and impact scores. Temporal scores take into account metrics that change over time owing to events that are external to the vulnerability. Remediation levels (“Is there an official fix available?”) and report confidence (“Is the report confirmed?”) can help temper the overall CVSS score to an appropriate level of risk.

    Similarly, an SCA solution should offer key Common Weakness Enumeration (CWE) classifications—a list of software or hardware weaknesses that have security ramifications—for all vulnerabilities, providing insight into the type of weakness being exposed. A CWE classification tells developers which type of weakness leads to the vulnerability in question.

    Information such as this can help you understand what you’re dealing with and aids in assessing the severity of the vulnerability for mitigation purposes. For example, a development team may prioritize a SQL injection differently than a buffer overflow or denial of service.

  • Features or Quality? App Survey Shows Surprising Results

    Features or Quality? App Survey Shows Surprising Results

    Software is an essential part of our everyday lives, but that doesn’t mean that people are always happy with the app experiences that they’re having.

    We at DeepCode conducted a survey to learn more about what people really think about software quality today. Is it getting better or worse? How important are bugs and security vulnerabilities to the average user? The results are interesting, whether you’re building or managing software.

    I’m going to highlight the data from the eight questions contained in the survey, provide some analysis on each question, and then summarize the key points that we can learn from the overall results.

    People’s habits are baked in for a core group of apps: 78% use 10 or fewer apps each day, and 41% use five or fewer apps on a daily basis. When you consider the apps that we all use for activities such as email, web browsing, messaging, social media, entertainment and work, you can see that there’s only so much room for people to bring extra software into their daily routines.

    Bugs and security vulnerabilities clearly have consequences: 92% of users lose confidence when they encounter them. People have high standards and they’re not willing to ignore issues.

    Not only are software issues taken seriously, but they cause 93% of users to consider switching to a different app. With so many options available today that share a lot of similarities, software companies have to be careful not to push people in a different direction.

    Considering making a change to different software is one thing, but 72% have actually done it because of bugs and security issues. User loyalty doesn’t always last forever.

    A nice majority believe that software companies take quality issues as seriously as they should. Users know developers have a lot to deal with and are doing their best, but as we’ve seen so far, that doesn’t change the fact that they’ll have a negative reaction when your software lets them down.

    There’s still a perception out there that all users care about are big, new features. Because of that, many times you’ll see software companies downplay bug fix releases as if they’re not worth mentioning. With 85% preferring bug/security fixes over new features, your best feature in any release is improved quality.

    The earlier statistic about software companies taking quality seriously carries over to this question because 83% think it’s improving. It’s encouraging to see that extra attention on bugs and security issues is directly resulting in better software.

    This one is rather evenly split, but if software quality is indeed getting better, then hopefully the percentage of those impacted will trend downward over time. It’s important to be cautiously optimistic here, however, because as software gets more ingrained in our lives through the internet of things and beyond, we’re opening ourselves to data and privacy threats that none of us are properly prepared for.

    Quality Is Key

    The results of this survey prove that quality software matters. Our brains may be telling us that, but if we’re honest, sometimes our hearts convince us that new features are the most important thing—no matter the cost. Users prefer bug/security fixes, and if they encounter software problems, they’ll consider switching. It’s really that simple.

    Smaller software companies may not have the resources to innovate on the same level as some of the bigger players, but they can focus on improving the quality of what they offer. When a user has a bad experience with a competitor, your company can be known for quality and provide a safe haven for anyone comparing different options.

    The users have spoken: You’ll be rewarded for building quality into the software development process.

  • Product vs. Project: Balancing Management Roles for Success

    Product vs. Project: Balancing Management Roles for Success

    Many businesses today rely on project management to ensure that all the activities that are required to help the business function are able to do so efficiently. The importance of project management is ingrained into many businesses, and doesn’t need to be justified—or does it? For software development companies, product management also needs to be considered just as much, if not more. To determine whether both or one is needed, and to what extent, business leaders need to first recognize the similarities and differences between the roles of the project manager versus the product manager, and what each can bring to the business.

    The key to understanding the differences starts with the descriptive writing mantra that everyone learned back in school: the 5 Ws (and 1 H), otherwise known as who, what, when, where, why and how. Though the who and where are generally self-explanatory, you can easily understand the difference between product management and project management by understanding which of the other four questions each job answers. Both positions fulfill critical roles in effective product delivery.

    Product Management: Getting Concrete Answers

    Product management answers the questions of “what” and “why.” These are important because, for every product you build, you need concrete answers to these questions.

    What

    The fundamental question that we’re asking here is, “What are we building?” Many enterprises have a product range that spans across dozens of different markets. Though this is great for the business and investors, it’s not an effective way for a team to work. When you ask a team to build or support a product, they need a clear vision of what that product will actually do. This is especially true for software products because it’s easy for them to lose their identity if they attempt to do too much.

    In a big enterprise, a “do everything” mentality can cost more over time. It’s likely that you have many software teams, and each one is building software that’s designed to suit a specific part of the market. When those teams implement software that duplicates some functionality already provided by your business, you’re wasting time and effort.

    This is where a good product manager is valuable. They help keep software teams focused on what they’re building and rein in the desire (by developers and executives alike) to grow the software outside the job it needs to do.

    Why

    The other major question that product managers answer is, “Why are we building this?” For developers, why is often more important than what. Work is almost always interconnected with the work of other teammates. When teams understand why they’re building something, it’s much easier to understand how those connections should work. It also gives developers information about which trade-offs they should make when implementing a feature, such as simplicity and usability versus speed.

    It’s the job of the product manager to understand and convey the why of the product. They do that by conversing with executives and project stakeholders to understand how this product fits into the overall business need.

    Project Management: The Thoughtful Side

    Project management, on the other hand, answers a different set of questions. A project manager’s job is focused on the how and when.

    How

    Large software projects are complex, with many interdependent and interlocking pieces. Efficient software project managers understand those interdependent requirements and plan for them. They organize the project’s tasks so that by the time someone is ready to work on one piece, its dependencies have already finished. Developer downtime is minimized and it enables those developers to focus only on the problems they need to solve for each task.

    Managing these kinds of interdependent requirements is the most valuable thing that project managers do for their software developers, though it can often be missed by executives, who are much more focused on the second project management question: when?

    When

    This is the visible project management question, “When is that project going to be done?” External stakeholders don’t care about how or why. They usually only care about what when the final product isn’t what they expected. But when is a question that’s top of mind for every single team leader who waits for a software project to be finished.

    This is also the most difficult question to answer. It’s almost impossible to reliably predict how long it will take to deliver a feature—not even a whole project, just one part of it. Something that seems simple at the outset turns out to be much more complicated. Alternatively, sometimes something you think might take two weeks instead takes only a day or two.

    The Balancing Act

    In most traditional cases, both product and project management are crucial for software delivery pipelines to run smoothly. However, many enterprises are now moving their deployment infrastructure toward a continuous delivery model, which adopts DevOps principles. For teams that practice continuous delivery, the question of when something is coming out can sometimes feel less important. Additionally, many software teams transition toward agile software principles, which makes the collective software team responsible for the question of how. Third-party planning tools can also make it easier for software teams to answer the how and when questions for themselves.

    For this reason, many teams are transitioning away from using dedicated project managers. Instead, they move much of that responsibility to the teams and focus their planning efforts on the product itself. However, the most successful projects answer all four questions effectively. When you don’t have a good answer to one or more of these questions, the project can end up stressful and frustrating.

    The people answering these questions might change over time, as it has changed already. The crucial point is to just ensure that you do have people who are dedicated to solving these questions and relaying this information to their teams. This is the smartest way to ensure projects stay on track and deliver the product that is expected and needed.