Category: Features

  • Solvo Automatically Crafts Cloud Security Policies

    Solvo Automatically Crafts Cloud Security Policies

    Solvo today announced general availability of a namesake tool that automatically creates a least-privilege policy and applies it to application workloads deployed in the cloud.

    Previously available only as a private beta, Solvo will also continually analyze a workload after it’s been deployed to enable IT teams to adjust security policies as additional updates to an application are made.

    In addition, Solvo is making available for free the Solvo Security Genie, which IT teams can use to identify misconfigurations, excessive permissions, privilege levels and third parties that may have access to accounts on the Amazon Web Services (AWS) public cloud.

    Shira Shamban, Solvo CEO, said the primary reason there are so many cloud security issues today is because developers – that lack cybersecurity expertise – are being asked to define policies. Solvo removes that burden by analyzing a workload and creating a cybersecurity policy before applications are deployed in the cloud. That cybersecurity policy can then be automatically applied by the developer.

    Shamban said that approach will reduce a lot of the DevSecOps tension that organizations are currently experiencing as they try to shift responsibility for cybersecurity further left toward developers. While no developer deliberately sets out to deploy an insecure application, shifting responsibility for cybersecurity to a developer who doesn’t really understand what’s required creates a lot of additional stress.

    The Solvo platform, available as a paid subscription or under a freemium model for individual developers and teams, addresses a lot of the cloud security issues that inevitably arise when infrastructure is provisioned as code by developers. It eliminates that stress by automating the creation and application of cybersecurity policies within the context of a DevOps workflows, said Shamban.

    However, a cybersecurity team can also manually edit those cybersecurity policies after an application is deployed, Shamban added.

    As DevSecOps best practices continues to evolve, it is clear the relationship between developers and cybersecurity teams needs to evolve, as well. For a long time, many cybersecurity teams viewed developers as the primary source of the problems they encountered. Getting used to the idea that those same developers are now going to solve those issues on their own requires a level of trust that will take time to build.

    Developers, for their part, are generally accepting of the idea that they should take more responsibility for security, so long as the tools provided to them are not selected by cybersecurity professionals that don’t appreciate application development workflows.

    In time, there is no doubt the cultural divide that exists between developers and cybersecurity teams will narrow. However, it’s arguable that more progress will be made, more quickly, if developers are allowed to choose their own security tools rather than accept an edict from on high mandating a specific approach. In fact, the best course of action for many IT teams is simply to offer words of encouragement to developers that elect to set an example for the rest of their colleagues.

  • Python Remains Popular in Programming Language Study 

    Python Remains Popular in Programming Language Study 

    A ranking by analyst firm RedMonk reflects on Python’s continued popularity as a leading enterprise programming language for a number of reasons. According to a recent study by RedMonk, JavaScript also remains widely popular as the web development programming language of choice for a significant number organizations. 

    In many ways, Python’s strong showing in the ranking — drawn from GitHub pull requests and Stack Overflow data — indicates its long-term viability among DevOps developers. 

    “One lack of change that is worth surfacing is Python’s number-two spot,” Stephen O’Grady, a RedMonk co-founder and analyst writes in The RedMonk Programming Language Rankings: January 2021. “Java was extremely hot on Python’s heels – and was, in fact, closer to the number-one ranking than to PHP behind it – but Python’s ability to defend its new high ranking is notable.” 

    RedMonk

    Python’s prolonged high ranking is notable because of its versatility, Rachel Stephens, a RedMonk analyst who is responsible for the RedMonk Language Rankings’ design, told DevOps.com. “The breadth of use cases — and associated libraries that support those use cases — means there are a number of possible entry points for developers. The number of toeholds for the language within the enterprise helps its ubiquity,” said Stephens.

    There also remains much discussion about what accounts for Python’s continued popularity beyond the scope of the study. A popular subject in forums, including Reddit, Python is typically described as highly versatile, relatively easy-to-learn and a simple, yet elegant language. While not cited in the RedMonk study, some software engineers and coders — such as this writer — appreciate how Python can make more intuitive sense, and is also less rigid compared to, say, a classic language such as C++. While JavaScript is largely used for web apps and scripts, of course, Python could arguably be the most popular language outside of the sphere of web development, thus accounting for its second-highest ranking in the study.

    As such, “due to the accretive nature of our methodology, movement within the top-ranked languages is an infrequent occurrence,” Stephens said.  

    “[However], Python overtaking and sustaining its ranking over Java was a big deal. That said, we remain strong believers in the future of Java and the Java ecosystem, and we know there is a vast amount of enterprise Java that isn’t captured in the metrics we use,” Stephens said. “We don’t view Python’s ascendence as a zero-sum gain over the use of Java.”

    For JavaScript, “in spite of all of the competition from up-and-coming languages, all the discussion of fragmentation – and even criticisms of JavaScript the language itself – it remains remarkably popular,” O’Grady said.  

    “Simply put, JavaScript remains – its detractors notwithstanding – a force of nature like no other within the industry, and there are no indications in the data that this is likely to change any time soon,” O’Grady added.

    Meanwhile, in the book Hardcore Programming for Mechanical Engineers, published by No Starch Press, JavaScript trails Python in other rankings, while Python is also more popular than JavaScript for other reasons than those described in the RedMonk study. Python, for example, is cited as the ‘The Most Wanted Language,’ based on a Stack Overflow survey. 

    While Python is not the fastest language, as measured  in benchmarks listed in Hardcore Programming for Mechanical Engineers  — Go consistently outperforms it, for example, in execution times — Python’s popularity remains very high overall, according to the book’s author.

    “These results are not surprising; Python is an extremely versatile and productive language,” author Ángel Sola Orbaiceta wrote. “Writing code in Python is a delight, and its standard library is well-equipped: for just about anything you want to do, Python has something ready to help.” 

     

  • Why a Unified Enterprise DevOps Platform is Necessary

    Why a Unified Enterprise DevOps Platform is Necessary

    As a senior DevOps consultant working with large organizations over many years, I have been involved in more than 70 digital transformation projects, with hundreds of applications. While many things have changed over time, one thing has been a consistent source of problems that presents a formidable impedance to these transformations. The diverse number of DevOps platforms and tool variants used in those platforms results in a chaotic software delivery environment. From the point of view of any one application, almost any choice of DevOps platform and toolchain is fine, to an extent. But when you stand back and look at the larger picture, an enterprise with many variations of DevOps platforms and tools is at best chaotic; at worst, it is a gross impediment to overall organizational agility – which undermines the very purpose that DevOps is meant to serve.

    I relate to the quote “You don’t need another CI/CD automation tool. You have too many already.” The aggregate set of platforms and tools is like a Frankenstein’s monster with many incompatible parts resulting in an awkward looking product that is hard to control, replicate and evolve.

    DevOps Platform Blockages

    Success with DevOps requires frictionless interplay between the people, processes and technologies that need to cooperate for continuous deliveries to happen effectively. All three of these factors are impacted when an organization has too many variants of DevOps platforms.

    People factors – It starts with leadership. Business leaders want to leverage the values of continuous flow of software improvement made possible by DevOps. However, the flow is bottlenecked when the services of the organization must be delivered through a disparate combination of unconnected pipelines, each with separate processes to monitor, manage, troubleshoot and maintain.

    Process factors – Continuous delivery works because the DevOps platforms enable automation of processes to remove bottlenecks in flow. Process management and improvements are seriously slowed down when the details of automating the orchestration, execution and monitoring for software version management, integration, testing, security assurance and deployment processes are not standard between different DevOps platform variants.

    Technology factors – Often application development teams have their own favorite DevOps platform and a chosen set of tools. However, when application development teams in the same organization choose different DevOps platforms and tools, sharing knowledge, process data and practices becomes difficult. These incompatibilities slow down the overall evolution of continuous delivery for the organization.

    Requirements for a Unified DevOps Enterprise Platform

    Culture barriers, process problems, and DevOps platform “wars” are factors impacting the progress of digital transformations. A new unified enterprise DevOps platform would accelerate time-to-value and realize efficient, safe operation for digitally transforming enterprises and organizations. The following are general requirements for a unified enterprise DevOps platform.

    ● A new unified approach that supports end-to-end capabilities for continuous delivery of software, as a managed service, for multiple streams of pipelines is needed.
    ● Unified capabilities should include visibility, orchestration, integration, security, compliance, governance, traceability and management of flow for application value streams across multiple pipelines.
    ● Businesses need unified metrics that show business value, costs of the value stream and timing for end-to-end continuous delivery flow across multiple pipelines.
    ● A new unified approach is necessary to simplify and accelerate toolchains that support new cloud-native and cloud-adapted applications, infrastructures, machine learning, commercial off-the-shelf and open-source software.

    What This Means

    Digital transformations are an imperative for modern enterprises and organizations to remain competitive. However, the transformations of many enterprises and organizations are being seriously impeded by having too many DevOps platforms and tools. A new unified enterprise DevOps platform is needed to resolve the technical problems of broken, leaky, “Frankenstein” toolchains and processes.

  • Ambassador Insights: Value Stream Management

    Ambassador Insights: Value Stream Management

    Value stream management is the next critical evolution for enterprises and organizations that want to further mature their efforts toward smart, efficient and effective software development and delivery. The need for ongoing software innovation and delivery is becoming a top priority for all businesses today, thanks to the new digital demands organizations are facing from their employees and customers.

    Value streams help ensure that software and services under development deliver on the promise of value for employees or customers. But it’s not as easy as it seems; plenty of enterprises still struggle to know exactly what value is being derived from their software development efforts.

    In our third episode of Ambassador Insights we talk with DevOps Institute ambassadors Siddharth Pareek, the Global DevOps Center of Excellence Leader at NatWest Group; Garima Bajpai, the founder of Canada DevOps Community of Practice; and Steve Pereira, founder of Visible, about how value stream management can help enterprises on the next step of their software development journey.

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

    Transcript

    Charlene O’Hanlon: Hey, everybody, welcome back to TechStrong TV. I’m Charlene O’Hanlon, and I am here now with a group of very, very smart people in the value stream management space. They are part of the DevOps Institute Ambassadors, and they are here for our monthly installment of the DevOps Institute Ambassadors Insights Panel Discussion.

    This month, the topic is on value stream management, so like I said before, these guys are experts in the field, and I’m sure we’re gonna get some really insightful information from them. Thank you, all three of you, for joining me today.

    We have Siddharth Pareek, who is the Global DevOps Center of Excellence Leader at NatWest Group. Siddhartha, thank you so much for joining me today.

    Siddharth Pareek: The pleasure’s all mine.

    O’Hanlon: We also have Garima Bajpai, who is the Canada DevOps Community of Practice—is that correct, is that your correct title, Garima?

    Garima Bajpai: Yes, I’m the Founder for the Canada DevOps Community of Practice, and thank you for the introduction.

    O’Hanlon: Alright. Well, thank you for joining me today. And last but certainly not least, we have Steve Pereira, who’s the Founder of Visible. Steve, thank you so much, it’s great to see you again.

    Steve Pereira: Thanks. Great to see you, it’s great to be here.

    O’Hanlon: Alright, great. So, let’s talk value stream management. You know, it’s something that we’ve been talking a little bit about here and there on DevOps.com over the last couple years, but it seems like in the last year or so, especially, it has taken on more steam, if you will. It’s definitely more significance, a lot more people having the conversation about value stream management and its role in organizations, but I think it’s probably important that we at least start at the beginning, level set a little bit, and maybe, Steve, we can start out with you. Can you just kinda maybe loosely define what value stream management is and what it means to organizations?

    Pereira: Yeah, absolutely. That’s a great starting point. I think folks in the DevOps space are familiar with the origins to a degree where we had agile kind of be wildly successful in boosting development performance, right, and then all of a sudden, we hit this block where it’s like, okay, well, we can’t really go any faster unless we look at the bigger picture, right, and we start to involve Operations.

    Well, that’s where I see value stream management now is that DevOps has reached this point where we’re seeing massive performance improvements, we’re seeing a lot of positive outcomes, and we’re hitting the boundaries of that where all of a sudden, the bottlenecks and the opportunities are elsewhere at a further zoom point. So, if we now zoom out again and look at a larger sphere of influence, there’s a ton of opportunity outside of DevOps where value stream management is really the recipe for success. It’s a holistic operational capability that allows you to tie together this big picture view of your organization—and not just software development, but value streams are everything in your business, right? Your entire organization is just a collection of value streams delivering value to customers.

    So, the ability to organize, visualize, measure, and manage all of that in a very, let’s say, low touch, high automation way is going to be a game changer for organizations of all kinds, whether they are primarily software driven or building and delivering software, or if they are supply chain health care logistics, it really doesn’t matter. It’s gonna touch everything, because it has to, to drive the level of performance that we want and that end to end level of productivity.

    O’Hanlon: Okay, alright. Garima, have you, in your position, you’re obviously very deeply embedded in the DevOps space, have you seen kind of an increased interest in value stream management over the last year, especially in the DevOps space?

    Bajpai: Yes, I have, and I actually come from a large enterprise background and I work with complex systems, largely monolithic environments, which are transitioning into cloud native applications.

    Now, when we talk about these large enterprises, value stream mapping, to me, has been a tool in the toolbox of value measurement. So, I would actually reflect from the standpoint where Steve had left. So, value stream mapping, to me, is as much an art as it is science. So, what Steve was mentioning, the scientific aspect of value stream management, which is basically leading to more productive, cost-efficient organizations where we can bring speed and scale.

    But it has also an element of creativity where we bring the discovery part of the value, right? So, how do we ensure your value stream management is able to discover new value for the organization? That’s the first point. The second point is, visualization of that value is also important. So, how your value stream management is able to map all the complex value streams which you have in an enterprise and bring it together to visualize that value in one way. So, that’s the second thing.

    I also wanted to bring another point, which I have experienced when working with large organizations. When you think about a data-driven approach towards value, there is no unified process to combine the value in one way, to build consensus in the organization. There are various functional silos and complex structures, and there is a maze of organizations which we have to bring together for consensus building. And that is where value stream management is pretty useful.

    And the fourth aspect I would like to bring from a creative aspect is, we also combine value stream management with applied data science to produce the future of the organization, the future state, defining the future state.

    So, these are the four elements I would like to bring into the conversation, probably changing the conversation a bit as well, so, let’s see how it goes. [Laughter] 

    O’Hanlon: [Laughter] Alright, great. So, Siddharth, kind of expanding on that, is your organization currently using value stream mapping or value stream management, and if so, have you guys noticed any changes in when you’re using it versus before you started using it?

    Pareek: I’ll put it this way. We’re at the starting phase of the journey of adoption of these value stream mapping concepts. And I could easily answer and say that what Steve and Garima said, I’m done with it. But I’ll add something to the flavor so that the audience understands value stream mapping more.

    What you are doing when you’re talking about DevOps is, you’re talking about reducing failures. We are talking about releasing early, we’re talking about less failures, less bugs, all those things. What is really the customer’s, the end user who is really worried about it, really concerned about it, maybe not. They are probably concerned about the customer satisfaction. They’re talking about how much reviews they’re getting on their product on different platforms, or maybe more.

    And what is happening is, there is a gap between these two things—what developers are delivering and what the customer is expecting. And that is where the role of value stream mapping comes from, where it bridges the gap between the IT side and the business side, which is clearly visible to everyone across the stream. And what it does is, it tells you a similar story for everyone. When you ask a Dev guy what are the values you’re delivering, he will not talk about incident reductions or chain failure occurrence or DORA metrics, all those things. They will talk about, we are delivering what businesses expect of us.

    Coming back to the story of why, how much it is done within the organizations of ours, I think this needs to be picked up and probably come up in the later conversations. Why it has not been done so much, because of the problems that exist within the organizations.

    So, in short, we are starting the journey, but miles to go.

    O’Hanlon: Okay, alright. So, it sounds like value stream management is a great idea and organizations really should be considering it, but it might not be as simple as just flipping a switch or saying, “Hey, let’s do value stream management.”

    So, what are some of the things, then, that may be tripping up organizations as they start on their value stream management journey? And Siddharth, since your organization is kind of in that place right now, what are you seeing as kind of the roadblocks, if you will, to value stream management in your organization?

    Pareek: I mean, we talk about value stream mapping, we talk about a holistic view of the place on the left-hand side where the idea generates to the place on the right-hand side somewhere, where the value is delivered to the customer. And over there, software development teams or a testing team has a small role to play. 

    The bigger roles are your governance, your security, your compliance. How can you visualize them? How can you make, you know, process re-engineer them? For example, the NatWest Group which I worked for, they have huge compliance laws that need to be followed. Can just a simple value stream exercise streamline them? Maybe yes, maybe no. And why I say either of them is, because it depends upon the deep-rooted problems that could be solved or could not be solved going forward.

    O’Hanlon: Alright, great. Steve, I know your organization deals a lot with companies that are going through the value stream management kind of adoption journey. So, what are you seeing as some of the things that organizations are having trouble with as they start out using value stream management or as, even in their consideration phase?

    Pereira: Yeah, there’s a lot going on. There’s tons of complexity. There’s a huge spectrum of circumstances. Certainly, Siddharth really touched on a major one, which is the existing requirements in an organization that enforce the status quo, right? The things that keep us where we are, are these powerful forces of, like, things need to be done a certain way and we expect them to follow process. So, thinking of how to improve process or things that will affect the flow of value through the organization always get pushed to the wayside, right? Because it would be nice to have that, but we gotta keep everything rowing as is, right? We can’t risk that and we can’t ever forget about the fact that nothing can fall through the cracks in the status quo.

    But that’s where we see that drift, you know, the slow drift into legacy and calcification and friction is that. That doesn’t mean that you’re moving forward, right? It doesn’t mean that you’re going to make progress. And the promise, here, of value streams is really in re-orienting the entire organization to be driving vastly improved value flow, but also, as Garima mentioned, innovation, right? It’s not only just making things better, it’s making better things and it’s making different things, right? It’s this idea of thinking in terms of value and orienting towards value allows you to re-imagine your entire organization, and that is kind of the promised land. 

    But to get there, you have to get over the realities of the org chart, right? The realities that we structure our organizations based on legacy hierarchies where everyone has to fit in and report to somebody and then they have reports and you have to go up and over through the org chart. If you look at an org chart and you map the flow of value to the org chart, it’s just this wandering path that goes all over the organization and no wonder it’s inefficient, no wonder we struggle to deliver value and really make meaningful improvements.

    So, I think I would say demoting the org chart in terms of importance and focusing more on the streams and the interactions between the streams, starting to see those streams, and then aligning our teams and aligning our activities and our operations to those streams is no easy feat, but we can start really easily by just seeing it, right? Just seeing what’s going on, just observing the current state, that lays the groundwork.

    So, I would say that there can be a lot of defensive reactions to the idea that the org chart is not that important to customers, to value delivery. That could threaten people who are really invested in that hierarchy and their position in it. But ultimately, it does bring everybody together in a much more meaningful way to think in terms of streams.

    The other challenge, I think, is that, when we think about surfacing gaps and surfacing issues, a lot of cultures means that people get pointed at, right, and it’s, they’re scapegoating and there’s people, individuals who are responsible or those challenges, and we know that that’s not true. But the cultures that are in legacy trouble, are in these calcified states and not succeeding with transformation efforts, it’s often because that’s the mindset. The mindset is, we need to find the person accountable and force them to tackle the problem. It’s not our problem, it’s their problem, because I have my problems and someone’s trying to scapegoat me for something, so it’s only fair it’s going around, right? 

    And the level of visibility and the metrics and the measurements that you can get from value stream management can be used or abused, right? You can use those measurements to draw all kinds of conclusions, and in the wrong culture, it can be weaponized. That’s not to say that there’s not a ton of value and a ton of promise there, it’s just, if it’s misapplied or it’s done in a way that’s more kind of tailoristic or legacy founded, you’re potentially doing harm by surfacing all of this reality that people tend to ignore and just go about their business.

    O’Hanlon: You bring up some good points, and obviously, it doesn’t sound like value stream management, adopting it, is a walk in the park, but obviously, there are clear benefits, otherwise organizations really wouldn’t be considering it.

    I’m wondering if you could maybe kinda choose one or two things that maybe organizations need to do to derive the value from value stream management. Garima, I’d like to start with you. What are some of the things that, as I said, organizations really need to do to kinda derive that value from value stream management? Considering all the things that Steve just said, it sounds like there’s really an uphill battle for a lot of organizations.

    Bajpai: Right, and I think we will start from what Siddharth as well as Steve has mentioned that, coming from a large enterprise background, I see that there’s a lot of valueless complexity in large organizations, which quickly leads us to job security. So, there is a lot of organizations which are struggling with this problem.

    Now, to disable this problem, I think what we will necessarily have to do is, first of all, nobody wants to do a useless job. We need to be sure that we have inculcated behavioral aspects into value stream mapping. And, you know, looking from a bird’s eye view perspective, there are three things which we need to necessarily do.

    The first and foremost thing is empowering people and building accountability where you can actually visualize that in your value stream map, everybody is accountable for a value, you know? Nobody wants to do a useless job, right?

    The second part of this whole problem is making the value stream mapping as efficient as there is a loop that is basically, you’re incrementally building the value, you’re not trying to kind of big bang this approach of doing your value stream mapping and engaging everybody to kind of ensure that we decompose this complexity in the organization.

    And the third aspect, which is really very important, is that, first set the strategy. Whenever you are trying to do a value stream management, what is the objective? There can be four objectives—cost, you might need to ensure speed, you might need scalability in the organization, or you want to introduce new value into the value stream. So, there are four possibilities. So, what are your key objectives? Just define that strategy before you prioritize or you do any kind of decomposition of the value stream, from a value stream management perspective.

    O’Hanlon: Alright. Siddharth or Steve, do you have anything that you’d like to add onto that?

    Pareek: Yep. One thing is, and the organizations started very wrongly is, to confuse value stream mapping with the process mapping, to think both are somehow a similar exercise. However, people need to understand, process mapping talks about a very micro view of what things are happening, whereas value stream mapping talks about the macro view.

    And why that is important to know is, if you go into the process mapping stage, you may optimize one component of your whole floor, which is good for that component, but if you look holistically, it may create chaos for other components as well. 

    So, let’s suppose, you know, you will have streamlined a manual process of delivering certain products at a faster rate. You’ve improved that process, but what you’ve done is, maybe for other components, you have created a long stack of inventory to clear it out. And that is where this value stream mapping would come across. Because you’re going one level above the thought process, or from micro to macro. So, that is one proof that people make it happen.

    The second thing that makes it happen is, people go with jumping on the value stream mapping exercise or sessions they need to have. The first and primary thing is, they need to get the buy-ins of those stakeholders, because after the exercise, this scenario, the output would be very scary for people, accept and to action upon. So, they should have a good acceptance that yes, we agree to what happens after these sessions. Two things. I think that’s it from my side.

    O’Hanlon: Okay. Steve, any thoughts?

    Pereira: Yeah, I think that one thing that I want to clarify for the audience is that we’re talking a lot, I mean, this session is about value stream management and we keep talking about value stream mapping. And it speaks to the starting point, you know? It speaks to how you actually start to make traction with this and get going is understanding the big picture and it starts with mapping. And for me, it starts with mapping outcomes to obstacles and key objectives in the organization.

    So, starting with clarity, and we’re talking about the difficulty involved here and how complex this is. Really, we’re getting so much better at adopting these techniques, because we’re starting to realize that you can’t get there with agile, you can’t even get there with DevOps, and we struggled for decades trying to make this work. The value stream thinking approach, the holistic approach, the fact that this is the entire organization and it’s entire ecosystems that are involved in this. The flow of value is larger than we imagined initially, right? It’s not software development, it’s not even Development and Operations, right? It affects everything in the organization, but that perspective puts you decades ahead of where we were stuck in the mud.

    And so, just adopting that way of thinking and stepping back and saying, “Okay, well, what’s really going on here? What are we dealing with in the current state?” That’s gonna put you in this really strong position to adopt things like value stream management. But value stream management to me is the act of managing the value stream. It’s not software. There are tools that are available to do that job and we’re in early days of that, but management is the act of managing value, right? It’s visualizing, it’s tracking the flow, it’s understanding the flow of value through the organization.

    So, that really, to me, starts with mapping and this baseline view. And I’ll echo everything that the other folks said—bringing in the right perspectives from the top to the bottom is really gonna make that happen. And it’s really, you know, the first opportunity where we’ve had that invitation in a very accommodating way, right? This is truly inclusive. There’s something in this for the business. There’s something in this for customers there’s something in this for technical folks, and everybody gets some value out of it. Everybody gets tons of value out of it, but it’s not just, “Yeah, you need to look at DevOps, because otherwise, this tech thing is gonna get out of control.”

    O’Hanlon: Mm-hmm.

    Pereira: There’s messaging and there’s value in it for the business, and there’s something in it for the customers, and that’s unique and that is a perspective that we’ve never had before, but is starting to come to reality.

    O’Hanlon: Alright. Well, definitely, as I said before, we’ve been having the conversations on DevOps.com about value stream management and value stream mapping, and I firmly believe that, at the very least over the next year, we’re going to be hearing a lot more about value stream management. 

    So, Steve, Garima, Siddharth—thank you, all three of you, for bringing your expertise to today’s DevOps Ambassadors Insights Panel on value stream management. I appreciate it very, very much, and I do value your expertise, so thank you, all, for joining me today. I really do appreciate it.

    Pereira: Thanks for having us. Great to see you all.

    O’Hanlon: Alright.

    Bajpai: Thank you. Bye bye.

    Pareek: Thanks, Charlene. Goodbye, everyone.

  • Data Theorem Extends Scope of App Analyzer Portfolio

    Data Theorem Extends Scope of App Analyzer Portfolio

    Data Theorem, Inc. today added to its portfolio a Cloud Secure analyzer that promises to provide full stack visibility into applications through the client, network and cloud layers of a distributed computing environment.

    Doug Dooley, Data Theorem COO, said Cloud Secure extends an existing Analyzer Engine offering that is currently widely employed to identify vulnerabilities found in applications running on public cloud services. That enables DevOps teams to analyze application runtimes using a tool that can be integrated within a continuous integration/continuous delivery (CI/CD) platform as part of a DevSecOps workflow, Dooley noted.

    Cloud Secure now extends that capability to include the client layer for both mobile and web applications, as well as REST and GraphQL application programming interfaces (APIs) at the network layer, to provide a more comprehensive approach to attack surface management, Dooley said. That’s a crucial capability, because in modern IT environments, the single biggest attack surface is now all the APIs that need to be secured, Dooley added.

    DevOps teams can also employ multiple Cloud Hacker Toolkits, created by Data Theorem, to simulate hacks against various types of applications, including those now running on serverless computing platforms. That approach eliminates the need to rely on manual penetration tests that can’t keep up with the rate at which DevOps teams are now building and deploying applications, Dooley noted. For organizations to achieve DevSecOps, the whole security process needs to be just as automated as the rest of the DevOps workflow, he added.

    In general, Dooley said most of the results of penetration testing shared with DevOps and cybersecurity teams lack much-needed context. They may inform members of an IT team that there is a leak, for example, in an S3 bucket hosted on a cloud storage service from Amazon Web Services (AWS). However, they don’t identify what type of data is at risk. That’s critical information at a time when IT organizations need to make high-stakes decisions about where to prioritize their DevSecOps efforts.

    As developers assume more responsibility for application security, the biggest challenge organizations will face is finding security tools that can be easily integrated into application development processes that have become more extended as applications, made up of microservices, are deployed across highly distributed computing environments.

    It’s still early days as far as adoption of DevSecOps best practices are concerned, but as more tools become available, it’s becoming more feasible for organizations to make that transition from the bottom up. No developer sets out to deliberately write and deploy an insecure application. However, DevSecOps edicts issued from on high will fall on deaf ears if the developer lacks the tools required to achieve the goal. Tools that a developer embraces are going to be more widely employed than any tool that is specifically mandated by IT leaders that don’t really understand how applications inside their organization are constructed.

    Regardless of how DevSecOps is achieved, the one thing that is certain is as more applications get deployed, the probability there will be a major security incident becomes all but certain.

  • Cisco Leans on HashiCorp to Manage Infrastructure as Code

    Cisco Leans on HashiCorp to Manage Infrastructure as Code

    HashiCorp and Cisco today announced a Cisco Intersight Service for Terraform offering based on HashiCorp Terraform Cloud Business software.

    Cisco Intersight is an IT operations management platform that enables IT teams to manage IT infrastructure across a hybrid cloud computing environment. Open source Terraform tools have emerged as the dominant tool for provisioning infrastructure as code in the cloud and, increasingly, in on-premises IT environments.

    HashiCorp Terraform Cloud Business is an instance of Terraform that has been extended to include some additional security and governance capabilities enterprise IT organizations typically require.

    In recent years, Cisco has significantly expanded its presence in on-premises IT environments as many IT teams opted to deploy its servers alongside its networking equipment. Like every other provider of on-premises IT environment, Cisco has been moving to extend the reach of its management frameworks to public clouds to help foster the rise of hybrid cloud computing.

    Prior to the pandemic, most public clouds and on-premises IT environments were managed in isolation from one another. However, in the wake of the economic downturn brought on by the pandemic, more IT teams are trying to centralize the management of IT platforms as part of an ongoing effort to reduce the total cost of IT. The multiyear alliance with HashiCorp fills a major hole in the Cisco management portfolio, as Terraform increasingly becomes a de facto standard for provisioning IT infrastructure-as-code.

    Vijay Venugopal, head of product management for Cisco Cloud and Compute Software, said the alliance with HashiCorp will make it possible to provide Terraform support across a management portfolio that, over time, continues to be enhanced with machine learning algorithms that add artificial intelligence (AI) capabilities, also known as AIOps. That platform is already being employed by 6,000 customers to manage more than 600,000 servers, running primarily in on-premises IT environments, added Venugopal.

    HashiCorp Terraform Cisco

    It’s unclear how the battle for control over hybrid cloud computing will ultimately play out. While providers of on-premises platforms such as Cisco are making a case for using existing management frameworks to also manage workloads deployed on public clouds, the providers of those platforms are now extending their reach into on-premises IT environments. Cisco is, of course, betting that most organizations would prefer to extend an existing framework to achieve that goal, versus having to rip and replace existing IT infrastructure to employ an alternative framework from a cloud service provider.

    Regardless of how organizations ultimately decide to manage IT in the age of the hybrid cloud, it’s clear developers, thanks to tools such as Terraform, are exercising more direct control over IT infrastructure. Incorporating Terraform within a larger IT management framework presents an opportunity to bridge the divide between developers and IT operations teams that have historically relied on visual tools to provision infrastructure. The challenge now is finding a way for developers and IT administrators – with varying levels of programming expertise – to work more closely as management of IT environments become increasingly more complex.

  • How to Mitigate Low-Code Security Risks

    How to Mitigate Low-Code Security Risks

    Gartner predicts that by the end of 2025, over 65% of development projects will use low-code builders. The field of low-code continues to expand. But what security implications does low-code introduce?

    Low-code refers to tools that enable application construction using visual programming models. Adopting drag-and-drop components instead of traditional code, no-code and low-code platforms enables non-technical folks to construct their own workflows without as much help from IT. Yet, handing power to citizen developers with less security training can be risky. Plus, low-code platforms may hold compromised propriety libraries or leverage APIs that may unknowingly expose sensitive data to the outside world. There’s also the possibility that low-code could increase shadow IT if not governed well.

    Low-code opens the door to more producers. But, does it open the backdoor, too? I recently met with Chris Wysopal, CTO and cofounder of Veracode, to discuss the growing security risk posed by low-code applications. According to Chris, hardening low-code environments involves a combination of compartmentalization, dynamic and runtime techniques, and adopting the “least privilege as possible” rule across the board. Below, we’ll expand on potential low-code risks and see what other methods Wysopal recommends organizations employ to secure the emerging low-code paradigm.

    Low-Code Security Concerns

    Verizon’s 2020 Data Breach Investigations Report (DBIR) found 43% of all breaches are connected to a vulnerability at the application layer. Thus, securing these applications, or in the case of low-code, the layer that generates them, is essential for business to function smoothly.

    When it comes to low-code, Wysopal notices a few key risk areas:

    Proprietary libraries with hidden vulnerabilities. By their nature, low-code platforms typically use a good deal of proprietary software, making securing them a bit opaque. These systems could involve a proprietary language, proprietary libraries and proprietary frameworks. If you trust a low-code platform, you place a lot of faith in the low-code vendor to have a strong security process in place.

    Some platforms do generate traditional code, which organizations can export to run on a Node.JS or Java server. Yet, this often involves a mix of code and proprietary libraries, says Wysopal. While you could run traditional static analysis on the generated code, you may miss some context.

    Lack of citizen developer security training. Citizen developers have little technical knowledge, let alone DevSecOps training. If runtime applications present vulnerabilities, expecting no-code users to mitigate them is unrealistic.

    API integrations. If low-code platforms expose an API or generate a web application via an API, the platform could be exposing sensitive data.

    Ways to Harden Low-Code Environments

    To respond to these areas, Wysopal offers some advice for securing low-code environments:

    • Perform static code analysis: Perform your own static analysis on any generated code and test for common errors. “Look at the code, and understand where it interacts with the outside,” Wysopal recommended.
    • Audit proprietary libraries: Whenever possible, Wysopal said he recommends pushing back on the vendor to question them on their application security standards and examine proprietary libraries for potential risks.
    • Verify partners: Similarly, take precautions when working with third-party partners around low-code tools. Partner tools should be carefully vetted and hold some sort of application security certification from the low-code platform.
    • Secure the API layer: Understand what APIs the application interacts with. These connections should be tested dynamically and automatically with an API scanner. Along your journey, consider these API security testing best practices.
    • Compartmentalize: Wysopal also recommends traditional isolation techniques. Consider more than just the application layer; Wysopal recommended isolating the app and running it in a virtual machine or a container.
    • Security training for citizen developers: Since citizen developers are typically not trained on appsec practices, hold security exercises to train them on fundamentals. A helpful demonstration could involve directly attacking an app to find flaws.
    • Apply the least-privilege-as-possible rule: When assigning user capabilities, whenever possible, use secure-by-default settings and allow access only to those that need it.

    By applying dynamic and runtime techniques, you may catch vulnerabilities, such as a cross-site scripting error. However, if you’re working with proprietary low-code systems, you may not be able to fix it immediately! You may have to send a request to the vendor and wait for the bug to be patched. Thankfully, most technology providers take more immediate action in response to bugs than to feature requests, Wysopal noted.

    Change the Attitude Toward Security

    On the low-code spectrum, there is the attitude that “people aren’t really doing mission-critical applications — they’re mainly doing prototyping, or back office automations,” Wysopal said. Or, since low-code applications often do not publicly expose an application, they are deemed low-risk and fall to the bottom of the security team’s inbox and list of to-dos. “We’re still in a world where people don’t secure all applications,” he said.

    However, these attitudes are a bit short-sighted, since “applications aren’t islands,” Wysopal said. Even if applications are intended for internal use only, phishing attempts could expose credentials and gain access to the network. Here, attackers could leverage sensitive resources or steal infrastructure for compute power.

    Thus, all low-code users should be aware of potential threats and change habits to address these risks accordingly. However, the onus is also on low-code vendors to sufficiently arm their systems. Having a vulnerability disclosure, bounty program and an easy means to accept bug reports from white hat security researchers will be necessary to continually patch issues.

    No-Code ≠ No-Bug

    Low-code continues to permeate more and more digital operations, opening up novel potential for citizen developers. While the low-code movement promises impressive returns, it also brings potential risk.

    To mitigate these concerns, we must level up our security understanding and evolve our approaches, Wysopal said. “Any application can have flaws and security bugs in them.” Just because you’re not writing a function in C and are relying on a visual programming model doesn’t mean you’re not introducing flaws.

    Disseminating the real risk of resources and dependencies, along with helpful consumer-facing documentation, will set the superior low-code platforms apart from the rest. Otherwise, putting faith in proprietary libraries will be a tough pill to swallow.

  • ServiceNow Acquires Intellibot to Gain RPA Capabilities

    ServiceNow Acquires Intellibot to Gain RPA Capabilities

    ServiceNow’s acquisition of Intellibot, a provider of a robotic process automation (RPA) platform, this week is part of a larger effort to automate the development of applications that are driving digital business transformation within enterprise IT environments.

    Earlier this month, ServiceNow unfurled a set of revamped low-code tools that both professional and so-called citizen developers could employ to build applications to modernize various business processes. However, many existing business processes are either manual or paper-based. An RPA platform enables organizations to create bots that mimic, within an application environment, the way those processes are currently managed.

    Josh Kahn, senior vice president for Creator Workflow Products at ServiceNow, said ServiceNow envisions the Intelligent RPA platform as a mechanism to automate rote processes that, for one reason or another, don’t manifest themselves via a set of application programming interfaces (APIs) that application developers can easily invoke.

    Each IT team, of course, will need to decide when it makes more sense to employ bots to digitize an existing workflow versus reengineering it using a set of custom applications infused with machine learning algorithms and natural language processing (NLP) capabilities. As digital business transformation initiatives become more urgent, the application development backlog within many enterprise IT organizations that require those capabilities is steadily increasing.

    However, in some cases, an RPA platform can reduce that backlog by surfacing a set of visual tools to automate a process that doesn’t require a lot of developer expertise to effectively digitize.

    In general, Kahn said ServiceNow is making a case for building a wide range of applications on top of the same software-as-a-service (SaaS) platform many internal IT teams already employ for IT service management (ITSM). That approach enables IT teams to streamline processes as the number of custom applications that need to be both developed and, ultimately, managed, steadily increases over time, Kahn said.

    The developers of those applications might be professionals using a low-code tool instead of writing additional code to quickly build an application, or it might be a “power user” that has enough understanding of software development best practices to build an application. Regardless of who builds the application, the rate at which applications are built using low-code tools is clearly about to accelerate.

    Kahn said the next step for ServiceNow will be to embed the Intellibot RPA capabilities in the ServiceNow platform sometime after the deal closes in the second quarter. In fact, one of the reasons ServiceNow opted to acquire Intellibot is because, as a smaller startup vendor, it is easier to incorporate their RPA platform than it would be to reengineer a much larger RPA platform. However, ServiceNow remains committed to integrating with other third-party RPA platforms that are already being employed by its customers, Kahn noted.

    Regardless of how or at what rate applications are developed, the number of core technologies required to build them continues to expand. The issue IT organizations will need to come to terms with is the degree to which they want to stitch all those tools together themselves, or rely on a platform to do it for them.

  • Why a Low-Code Platform Should Have Pro-Code Capabilities

    Why a Low-Code Platform Should Have Pro-Code Capabilities

    If you want to build a house, you could get a lot done yourself. You could sketch out a simple design, start assembling materials, maybe even nail down some floorboards and install drywall. But to make it truly functional, and to respond to all the unknown fixes — big and small — that would surely arise, you want professional support to enhance and reinforce the job you’re doing. Plus, not everyone is an expert in plumbing and electric.

    The same is true of app development.

    Low-code platforms are available for both professional and less-experienced developers to build apps more quickly than ever. The speed and practicality of low-code has injected a newfound approachability to the coding process, yet can’t account for the full range of user experiences at work within the modern enterprise company of today.

    If this sounds like a takedown of low-code, it’s far from it. As an approach, low-code is transformative. And here to stay. By empowering non-coders (citizen developers), you enable development of responsive web apps using visual tools and pre-built components and save precious development and IT resources.

    Low-code can free IT departments from a constant onslaught of demands and requests for support and create new ways to digitally advance products and services. Plus, IT leadership can be freed up to focus on the strategic needs of the business and maintaining momentum within major digital transformation initiatives. Therefore, it’s worth understanding why not all low-code platforms are the same, and how they’re viewed through the lens of the professional developer and enterprise architect.

    Using Only Low-Code Means You Can Fall Short

    The simple, unvarnished truth is that, when it comes to coding, there is no one-size-fits-all solution. Things are never that simple, or easy.

    There are many crucial components to the app development process that require time, attention and expertise to succeed. The best low-code platforms support the specification of automated workflows and — this is very important — can integrate with various enterprise systems, applications and sources of data. Enterprise systems can be incredibly complex and manage multiple data sets and processes, and some can be outdated. To build enterprise apps with a low-code platform, you need to be able to connect to these systems and customize with the same nuance and security that a pro-code platform provides.

    Take, for example, the Facebook app. While it’s simple and easy to use even on a mobile phone, just imagine all the complexity that makes up the backend: data, algorithms, ad networks, moderation, reporting, etc. — all updating in real-time for billions of users. The same goes for other apps with complex backends but simple front ends, such as those used to manage health insurance companies, retailers, government agency portals, wayfinding apps for big box stores … These are just a few examples that customers of ours offer solutions for built using HCL Volt MX. HCL Volt MX allows organizations to build applications for any audience — consumers, partners and employees, across any device — native mobile, web and wearables. It also provides improved efficiency and higher developer productivity. The platform has robust services for identity, integration, orchestration, business-process automation and rules management. Paired with its low-code design environment, you can create consumer-grade apps across multiple touchpoints — fast.

    Learn more about HCL Volt MX

    Giving developers — and thus, the full enterprise app dev operation — a connected arsenal of front- and back-end tools to design and maintain a dynamic framework includes combining low-code accessibility with power tools that pro-coders expect. Hence, companies can ensure they’re not sacrificing customization, scalability and sustainability, even with the need for design velocity and speed-to-market.

    Bridge Front-End and Back-End Capabilities

    When you are deciding on your approach for delivering your next digital experience, you should have the best of low-code with a pro-code foundation that manages the complete software development life cycle on the terms that a full-stack developer expects. Meaning, you expect the platform to increase your velocity, offer rock-solid security and give you integrated DevOps and automated testing, simplified backend integration and the ability to use advanced technologies such as blockchain, augmented reality (AR) and conversational apps and more, with ease.

    Also, what happens when the application needs features or functionality not included in the pre-built building blocks? How do teams fill in the gaps that inevitably occur when connecting to existing enterprise systems? How will low-code provide the highest level of security over a full range of unique workflows and handle enterprise systems of dizzying complexity?

    In our experience, there is always a time when a full-stack developer experience can get the very most out of the low-code platform, especially when the app demands complexity in the integration and orchestration, needs to scale to millions of users and have a sticky, “pixel perfect” user experience.

    As Simple As You Want, As Expert As You Need

    Professional developers are looking for software that can boost productivity without sacrificing features that allow them to poke around and see what adjustments a given app needs to deliver a full-native mobile, web or wearable app experience. A low-code platform with pro-code support, such as HCL Volt MX, bridges gaps in the entire software development life cycle and brings the business stakeholders, digital innovators, designers and professional developers together to achieve their digital vision.

    You Get the Best of Both Development Options

    • Lightning-fast capabilities for implementing front-end experience, workflows and functions that enable the business to see how their vision comes alive.
    • A professional-grade infrastructure that can respond to the needs of the front-end features and handle the more complex integration and coding demanded by any enterprise business requirements.

    If you’re solely investing in a low-code platform to build web apps, your operation can quickly run out of steam. Being pro-developer grade means you can respond immediately to the intention of the app’s development concept, no matter the complexity and scale required — native mobile, web and wearables. After all, creating apps is never a “one-and-done” pastime; we all know it’s an iterative approach that wins the day. Make sure your low-code platform choice is pro-developer grade.

    Learn how HCL’s Volt MX provides a low-code approach that includes back-end support.

  • LeanIX Extends Application Management Reach

    LeanIX Extends Application Management Reach

    LeanIX today unveiled a catalog that enables DevOps teams to more easily track the relationships between microservices as they are built and deployed.

    At the same time, the company also revealed it has acquired Cleanshelf, a provider of a platform for managing software-as-a-service (SaaS) applications.

    LeanIX CEO André Christ said the Microservice Intelligence catalog will make it simpler for IT organizations to keep track of their ongoing software development efforts, while Cleanshelf provides the mechanism for centralizing management of SaaS applications that are now widely employed across the enterprise.

    The Microservice Intelligence catalog is the latest addition to the LeanIX Continuous Transformation Platform used to manage enterprise applications. It automatically captures and correlates metadata being generated across disconnected toolchains, pipelines and Kubernetes clusters to create a 360-degree view of microservices and their dependencies, said Christ.

    In addition to being integrated with the LeanIX Enterprise Application Suite, Microservice Intelligence comes with out-of-the-box connectors for Kubernetes, Jenkins, GitHub Actions and Red Hat OpenShift platforms.

    By monitoring deployment frequencies, mean-time-to-recovery (MTTR) and failure rates, Christ noted it will become easier to make software engineering decisions based on data and insights surfaced via the Microservice Intelligence catalog. DevOps teams can also annotate the microservices recorded by the catalog to provide additional information, Christ added.

    The Microservice Intelligence catalog provides the added benefit of making it easier to onboard new developers, said Christ. Each new member of a development team can, on their own, explore the overall application environment without requiring an IT team to dedicate someone to describe it each time a new member of a DevOps team is hired, Christ noted.

    At the same time, other stakeholders, such as cybersecurity teams, can explore the application environment to better understand dependencies as well as the potential impact of a newly discovered vulnerability, Christ added.

    In general, Christ said, as application life cycle management across the extended enterprise becomes more complex it’s clear new platforms will be required to manage legacy monolithic applications, emerging microservices-based applications and SaaS applications that, in the wake of the COVID-19 pandemic, are being used to enable employees to work from home. The Cleanshelf platform, in particular, will be rebranded as LeanIX SaaS Intelligence to address that latter issue. A SaaS discovery and cataloging capability will also be made available as a free component of the LeanIX Application Portfolio Management module in the second quarter.

    IT environments have never been more distributed, and it’s clear most organizations are under pressure to reduce the total cost of IT by centralizing management functions. It’s too costly to dedicate a management platform for each type of application deployed across an extended enterprise. LeanIX is making a case for a platform that enables IT organizations to finally centralize the management of application environments.

    It’s unclear at what rate that centralization may occur, given the level of inertia that exists within most IT organizations today. However, as application lifecycle management continues to evolve, the centralization of the management of application portfolios that continue to grow is all but inevitable.