devopsy.kinsta.cloud

Tag: application development

  • Digital.ai Deepens Value Stream Management Integration

    Digital.ai Deepens Value Stream Management Integration

    Digital.ai announced today it has expanded usage of machine learning algorithms within its namesake value stream management (VSM) platform to include modules to optimize flow and improve application quality in addition to enhancing its risk prediction and process optimization modules.

    In addition, Digital.ai has expanded the number of pre-built integrations it now provides for hundreds of DevOps tools and platforms.

    Derek Holt, general manager of agile and DevOps for Digital.ai, said the goal is to expand the bi-directional flow of data between the core Digital.ai platform and modules and tools provided by the company and its third-party DevOps partners.

    Digital.ai was formed from the merger of XebiaLabs and CollabNet VersionOne. The combined company has rolled up Numerify, a provider of analytics tools infused with artificial intelligence (AI), Experitest, a set of testing tools and Arxan, a provider of an application security platform. With the latest release, these capabilities have been integrated into the core Digital.ai platform in a way that goes well beyond merely providing access via a common user interface, said Holt.

    The goal is to provide organizations with a VSM platform through which better decisions can be made to optimize software development and delivery by first collecting data from all the DevOps tools employed and then using machine learning algorithms to surface optimization recommendations, noted Holt. As application development environments become more complex to manage, it’s already apparent that most IT teams will require AI capabilities embedded in a VSM platform to manage interdependent projects, noted Holt.

    Armed with those recommendations, it becomes simpler to reallocate resources in the event a critical project is going to be completed later than planned or shift resources to make sure that project is completed on time. A VSM platform also enables IT organizations to assess the impact those decisions will have on the rest of the business at a time when organizations have never been more financially dependent on the timely delivery of software. The late delivery of a single application module can wind up having a profound impact on revenue projections for organizations that increasingly rely on digital processes to engage customers.

    A recent survey conducted by Digital.ai found that many digital transformation initiatives are struggling, to some degree. Nearly half of respondents (49%) said they are not seeing the results they expected from their digital transformation efforts, and 54% admitted they were worried about their ability to compete. Over 90% need to see a better return on their digital transformation investments.

    Digital.ai claims it currently has more than 1,200 customers, including Allianz, Commerzbank, eBay, Janus Henderson and Levi’s that are using elements of the Digital.ai platform to better manage software development projects. Many of the users of those tools now include business executives and other application stakeholders that are employing a VSM platform to track the progress of application development projects. Digital.ai Analytics Lenses that are domain-specific make it simpler for different classes of end users to access pre-built dashboards and metrics, noted Holt.

    The market research firm Gartner has predicted that 70% of organizations will employ a value stream management platform by 2023 to improve flows across their DevOps pipelines. However, as DevOps platforms and project management applications continue to evolve, many are also adding many of the analytics capabilities found in a VSM platform. Each IT organization will need to decide which approach makes the most sense for them, but Digital.ai is clearly betting that as application development becomes more challenging, the need for an integrated VSM platform will become much more apparent.

  • Despite Cloud Adoption, Enterprises Demand On-Premises Software

    Despite Cloud Adoption, Enterprises Demand On-Premises Software

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

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

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

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

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

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

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

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

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

    on-premises

  • Will App Dev Become a Normal Competency?

    Will App Dev Become a Normal Competency?

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

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

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

    The Undigital Condition

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

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

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

    A New Generation of Citizen Developers

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

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

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

    Leveling Up From Productivity Tools

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

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

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

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

    Goals for Citizen Developer Programs

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

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

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

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

    The Era of Low-Code

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

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

  • Citizen Development Program: Establishing Guardrails

    Citizen Development Program: Establishing Guardrails

    Citizen development is as easy as one, two, three.

    1. Select the right use cases
    2. Enable the citizen developer(s)
    3. And establish the guardrails, which I will cover here.

    Of course, there is a little more to it than this. Success requires focus, planning and patience. We previously discussed, in parts one and two of the series, the discipline required around use cases and citizen developers (CDs). This third and final post covers how to establish the appropriate technical and process guardrails to ensure the wider enterprise, platform and developers are protected.

    Establishing the Guardrails

    Guardrails exist for two primary purposes: alignment and independence. Clear and concise guardrails ensure alignment across organizational objectives, company policies and disparate teams. Those same guardrails provide CDs with a degree of independence – a safe operating space where they will not be micromanaged or unnecessarily burdened by processes.
    Effective guardrails define and enforce a range of acceptable behaviors, as well as reduce risk and speed application delivery.

    While low-code application platforms (LCAPs) each have their unique capabilities and technical implementations, relevant features can be viewed in three broad categories: platform foundation security, app dev access control and development tools & processes.

    Within the context of your specific LCAP and development methodology, you need to consider and answer the following questions:

    Platform Foundation Security

    • How will you provide your CDs a “safe” environment to build and test their applications? Does your platform support separate and secure development, test and production environments? Will you put your citizen developers in their own discrete development environment?
    • Will your developers be working with data that requires encryption and/or localization? If so, does your platform support data encryption and compliance with relevant data residency laws?
    • Does your LCAP support anti-virus scanning and/or HTML sanitization, and if not, how will you prevent a CD from inadvertently putting your organization at risk?
    • What logging and auditing is required for your CD activities? Who reviews logs? How long is the information kept?
    • Does your platform support enhanced security mechanisms like two-factor authentication (2FA) or virtual private networks (VPNs)? Will citizen developers be working in areas or with applications that require enhanced security?
    • Are there other risk, compliance and security standards that your organization mandates? If so, how will you incorporate them?

    App Dev Access Control

    • How will you provision or deprovision developer and tester accounts? How will you handle developer login and authentication into the development environment?
    • Will CDs have development access to downstream environments across testing, staging and production?
    • Will you use groups to control access to applications in development, and if so, who will manage these groups?
    • Will you use roles to grant access to distinct development capabilities like tables, workflows, UIs, mobile, reporting, analytics, etc.? What determines which role(s) a citizen developer is granted?
    • Will you provide a library of pre-built application components (e.g., workflows, dashboards, virtual agents, etc.)? How will you control access to and usage of the pre-built components?
    • Will you allow citizen developers to access pre-built integrations? How will you control access to and monitor usage of those pre-built integrations?
    • Does the developer identity and access management process need to be driven by an enterprise identity provider, such as Azure Active Directory?
    • Will citizen developed applications be able to access other citizen developed applications? How will app-to-app access be controlled?

    Development Tools and Processes

    • How will you manage your demand intake process? How will you ensure that new applications do not duplicate existing application functionality? What criteria will you use to determine if an application is a good fit for a citizen developer?
    • Will you require your CDs to adhere to all, some or none of your existing development methodology? Can you explain the methodology in terms the citizen developer will understand and accept?
    • Will you require CDs to create requirements or agile stories before building an application?
    • Will you require tests be developed for CDs’ applications, and if so, can these be automated? Who will develop those tests?
    • Will you require code or application reviews of citizen developed applications? What best practices and standards will be used during those reviews? Can those reviews be automated?
    • What level of documentation, if any, will you require developers to produce?
    • How will you promote applications through the development pipeline (i.e., dev to test to prod)? Can the app promotion process be automated?
    • How will you track and manage CDs’ applications through the development pipeline and their life cycle?

    Reflections on Citizen Development Programs

    The exercise of writing this series and your feedback has encouraged me to reflect on parts one (selecting the right use cases) and two (enabling citizen developers). Here are a few final thoughts to consider:

    • Do you care that a CD builds just one app or do you want them to build more?
      Ideally, a CD continues to deliver app after app. But attrition can be high in a CD program. Therefore, if your CD built a single application that delivers business value and then returned to their “day job,” you should still celebrate that success.
    • Is citizen development better suited for creating new apps or maintaining existing apps?
      In my view, the answer is both. LCAPs provide great opportunity for CDs to prototype or even produce an MVP of an application. At the same time, LCAPs allow professional developers to build more complex applications and turn the maintenance of those applications over to CDs.
    • How many LCAPs can you reasonably expect a citizen developer to understand?
      Realistically, perhaps one, or maybe two. Keep in mind that app development is important, but having CDs focus their technology choices on a single LCAP vastly improves their chances of success.
    • Do citizen developers make good professional developers?
      Consider this – some of the best developers I have worked with do not have computer science or software engineering degrees. It’s more important that a developer has a passion for technology and, more importantly, for understanding how technology solves business problems.
    • Finally, explore and embrace citizen development before your competitors do, as the value proposition is real in this new world of work we have found ourselves in. After 30 years in enterprise IT, I can confidently say we’ve reached an inflection point in technology and business, truly democratizing application development.

    This post is the third of a three-part series from Mark Tognetti that provides real-world insights on delivering business value from citizen development initiatives.

  • Languages and DevOps: Can’t be Contained

    Languages and DevOps: Can’t be Contained

    The evolution of platform is an interesting study. From physical to virtual to cloud to containers, the progression has been steady, and each successive platform has benefits for both Dev and Ops that make them appealing. In the case of containers, portability is the word.

    As easy to fold into your DevOps toolchain as cloud, yet able to be deployed wherever you need, containers have absolutely taken the industry by storm. While all cloud vendors offer container options these days, their “value add” capabilities are thinly veiled attempts at vendor lock-in, so most organizations have avoided them.

    Development languages are as diverse as they are for physical or cloud; you can pretty much find containers hosting every language imaginable. That makes perfect sense, since one use of containers is to keep an otherwise-obsolete environment alive. That’s certainly not the primary use of containers, but it is an important one. The catch with containers is that the primary languages depend greatly on usage. A container that is persistent and intended to last months or even years will tend toward a different set of languages than one that is ephemeral and intended to last only minutes.

    The big weaknesses of containers – security, persistent storage, and management – have been addressed more and more as container usage has grown. Complexity of environments is now the big issue, but that is not inherent to containers; merely enabled by the ease with which new machines can be spun up.

    For longer-term containers, Java and C# are still the languages of choice, though others are certainly making headway. A combination of how new container technology is, and the extra layer between applications and hardware in the current popular container solutions make C/C++ less popular than on physical machines. They are still used because like other targets, containers still have operating systems that are linked to more easily in these languages.

    Shorter-lived containers tend to use languages that grew up in the Agile environment – from Python to JavaScript to Go. The ability to quickly crank out the code and get to test is useful for Agile and DevOps environments.

    Hooking into DevOps toolchains is at least as easy as it is in a cloud environment. There are even a fairly large number of companies that have moved to spinning up a container to build, then destroying it, only to do it all again on the next build. This is not mainstream yet, but the ability to completely configure the container and its loaded toolset makes it an appealing option.

    The kicker – one that cannot be overstated – is that it is simple and easy to get developers running with a copy of a complex system that once would have required several physical boxes. I, personally, have worked on a seven-plus server client system that I had a complete copy of on my (admittedly beefy) development laptop. It wasn’t the most performant, but it was enough to do unit testing.

    The security weaknesses of cloud come along with containers too – there is a lot more than just configuring an IP to directing traffic, for example – but mitigating tools and processes are available.

    This pundit truly believes that containers are the future of DevOps. They have the best of previous iterations, while offering mobility that just didn’t exist in other solutions. The ability to move an entire infrastructure from one deployment target to another (data center to cloud, for example), or from one cloud vendor to another makes this option the king for organizations that require (for business objectives, compliance or finance reasons) the ability to move their applications quickly.

    Meanwhile, rock on.

    Containers are the cutting edge of wherever it is we are headed. They are more agile than any other solution, they do not limit programming or networking options, can be run wherever the organization needs them and can be modified or redeployed easily. There is more complexity, but most of it has been obfuscated; only when things go terribly wrong is the complexity really an issue. Development for containers, with a few exceptions, is development for the target OS. That makes it easy to keep the organization’s systems preferences while enabling developers. All good. And many (I daresay most) of you are already taking advantage of them. Keep rocking it. Use what the org needs, and don’t forget to check every once in a while to make certain what is in use is what needs to be in use.

  • Copado Acquires New Context to Drive DevSecOps Adoption

    Copado Acquires New Context to Drive DevSecOps Adoption

    Copado, a provider of a DevOps platform for building applications deployed on the Salesforce cloud platform, announced today it has acquired New Context as part of an effort to expand the scope of its portfolio into the realm of DevSecOps best practices.

    Andrew Leigh, chief marketing officer for Copado, said the acquisition brings Copado tools and professional services expertise that will be applied to help organizations build and deploy secure, custom applications on top of the same cloud platform they already use to access a range of software-as-a-service (SaaS) applications.

    The New Context Lean Security Intelligence Platform enables developers to achieve that goal by analyzing code and then surfacing recommendations for when developers should apply specific security controls, Leigh explained. Existing New Context customers include Blue Shield of California, GE, Kaiser Permanente and Royal Dutch Shell.

    Like most organizations that have embraced DevOps best practices, it’s still early days as far as adoption of DevSecOps are concerned. However, it’s already apparent that Copado is well-positioned to advance adoption of a complementary Lean Security Intelligence Platform, said Leigh. Copado, which claims to have more than 1,000 customers, recently raised an additional $96 million in funding to help fuel those efforts. The company also claims it recorded 120% growth in annual recurring revenue (ARR).

    In the wake of the COVID-19 pandemic, more organizations are employing SaaS applications to drive digital business transformation initiatives. Rather than building every application from the ground up, it is often simpler to extend, for example, a Salesforce customer relationship management (CRM) application.

    Once organizations reach a certain level of scale, they then start to apply DevOps best practices to those builds. These efforts, however, are often uneven. A recent survey, conducted on behalf of Copado, found that while 82% have increased or maintained the size of their Salesforce development teams, the change fail rate jumped from 23% last year to 33% in 2020 when compared to a similar survey conducted a year ago. The survey also notes time to recover increased from 110 hours in 2019 to nearly 196 hours in 2020.

    The next major challenge facing organizations that have embraced DevOps is, of course, DevSecOps. The challenge is that, since Salesforce environments are unique, applications are constructed using a set of objects and tables that are specific to that platform. As such, Salesforce environments generally require a DevOps platform designed from the ground up to work with objects and tables.

    Salesforce, in its most recent fourth quarter, reported revenue of $5.82 billion, up 20% year-over-year despite the lingering economic impact of the COVID-19 pandemic. As such, the number of custom applications being developed on top of Salesforce should steadily increase, especially as low-code tools become more widely adopted. It’s now only a matter of time before more organizations reach application development initiative critical mass that warrants investing in a DevOps platform to manage them.

  • Ambassador Insights: Cloud-Native

    Ambassador Insights: Cloud-Native

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

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

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

    Transcript

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

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

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

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

    Tracy Bannon: Thanks for the invite.

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

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

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

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

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

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

    Murillo: Right. [Laughter]

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

    Murillo: Yeah, great point.

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

    O’Hanlon: Mm-hmm.

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

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

    O’Hanlon: [Laughter]

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

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

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

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

    Bannon: Mm-hmm.

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

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

    Bannon: Mm-hmm.

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

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

    Bannon: Yep. Mm-hmm.

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

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

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

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

    Bannon: Oh, gosh, yes.

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

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

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

    Bannon: Yes.

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

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

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

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

    O’Hanlon: Yeah, right. [Laughter]

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

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

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

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

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

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

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

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

    Bannon: Yes! [Laughter] Alright, then!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    Murillo: Thank you very much.

    Piwosz: Thanks, everybody. Thank you.

  • DevSecOps May Be Key to Prevent Data Leaks

    DevSecOps May Be Key to Prevent Data Leaks

    Data leakage has become something of a norm in the digital realm, despite the fact that cybersecurity budgets are growing and more engineers are assigned to these very issues. Nowhere does this seem more true than in the realm of health care, where breaches that expose sensitive patient data are, sadly, a fairly common occurrence. 

    A recent report by Approov illustrates how severe the problem has become. According to Approov’s  All That We Let In research report, many of the mobile healthcare applications in use today are leaking sensitive patient data through APIs, potentially compromising millions of patients. 

    The study tested 30 popular mobile health (mHealth) apps, and the research estimates that some 23 million mHealth users are exposed, at a minimum. The average number of downloads for each app tested was 772,619. Analysts expect that the total number of users exposed by the 318,000 mHealth apps now available on major app stores is likely far greater. Among vulnerabilities detailed in the report:

    • 50% of the records accessed contained names, Social Security numbers, addresses, birthdates, allergies, medications and other sensitive data for patients.
    • 50% of the APIs tested allowed users (medical professionals) to access the pathology, x-rays and clinical results of other patients.
    • 50% of the APIs tested did not authenticate requests with tokens.
    • Of the 30 popular apps tested, 77% contained hardcoded API keys, some of which don’t expire, and 7% contained hardcoded usernames and passwords. Seven percent of the API keys belonged to third-party payment processors that warn against hard-coding their secret keys in plain text.

    “Look, let’s point out the pink elephant out in the room,” said Alissa Knight, researcher and author of the report. “There will always be vulnerabilities in code, so long as humans are writing it. Humans are fallible. But, I didn’t expect to find every app I tested would have hard-coded keys and tokens, and all of the APIs to be vulnerable to broken object-level authorization (BOLA) vulnerabilities allowing me to access patient reports, X-rays, pathology reports and full PHI records in their database. The problem is clearly systemic.”

    The report helps to illustrate a critical point: Sloppy code can lead to data leakage. “These findings are disappointing, but not at all surprising. The fact is, leading developers and their corporate and organizational customers consistently fail to recognize that APIs servicing remote clients, such as mobile apps, need a new and dedicated security paradigm,” said Approov founder and CEO David Stewart. “Because so few organizations deploy protections for APIs – that ensure only genuine mobile app instances can connect to backend servers – these APIs are an open door for threat actors, and present a real nightmare for vulnerable organizations and their patients.” 

    For organizations deploying apps using a DevOps methodology, it becomes very clear that much more must be done on the cybersecurity side to prevent data leakage. However, the general consensus is that data protection falls under the purview of CISOs and cybersecurity teams in the enterprise. Perhaps there is no better argument for adopting DevSecOps than the data leakage problems caused by insecure code and sloppy APIs. The report echoes that sentiment and offers several recommendations for developers creating and organizations using mobile applications. In other words, organizations should take several key steps to protect their customer data and sensitive resources, including:

    •  Address both app security and API security: Recognize that synthetic traffic to the API is an issue, and arises from bots and automated tools, not from genuine apps and legitimate data requests.
    • Shift left and shield right: Secure the development process and harden apps, but ensure that runtime protection is also in place.
    • Protect against X-in the middle attacks: Certificate pinning is critical, but often left undone because expired certificates can block apps and impact customer experience. However, when done correctly, certificate pinning does not impact either performance or availability.
    • Improve visibility into controls: Organizations and developers need to monitor the effectiveness of the controls they implement and adjust them easily – both for compliance with legislative mandates and to sustain data security and privacy.
    • Continuous testing: Penetration testing and static and dynamic code analysis should be performed regularly.

    Interestingly, those recommendations fit squarely into the role that DevSecOps should take in the DevOps process. 

  • Hybrid Low-Code: The Next Step in App Development

    Hybrid Low-Code: The Next Step in App Development

    The promise of low-code development has long been the ability to develop business-critical applications by humans with little programming experience. In fact, over the past year or two, the lines between low-code and no-code have become increasingly blurred. Low-code platforms have incorporated more and more functional no-code features to increase the efficiency of the developer even further. Some of these platforms have become so intuitive to use, the idea that anyone can create an app has evolved into the idea of citizen developers. But is low-code really the be-all and end-all when it comes to app development? Seems the answer to that is, “It depends.”

    It has become glaringly obvious that exclusively no-code platforms can’t create complex applications. But then again, these platforms were never really designed with that kind of functionality in mind. No-code can be a highly valuable, rapid prototyping tool as well as a decent tool for very small, very specific apps. These apps would be best suited for intradepartmental use or to extend the functionality of very specific SaaS tools. No-code is not going to power your business-critical applications, and a not-quite-a-developer is not going to lighten your IT load.

    But what about low-code? Can low-code be the bridge between citizen developers and the ever-growing list of backlogged apps? Maybe. Using citizen developers comes with a whole heap of issues that need to be addressed. While this topic can be the subject of an entire blog in its own right, I can quickly highlight the major issues to consider. How much of a citizen developer’s time should be dedicated to app development? Is using citizen developers going to create backlog issues in their primary departments? Who is going to train and support citizen developers? How is IT ensuring that citizen developer-created apps are secure, scalable and extendable? As great as citizen developers sound, they still are not a definitive solution.

    A realization has dawned in the low-code industry. Low-code can’t be and do everything, but it can be a useful development tool to speed up application development. However, most low-code platforms are in their own development silos, separated from other development tools with their own IDEs. Instead, one idea is to create a quick and easy-to-use user interface, drag and drop some app functionality, and then finish complex apps in a language the low-code platform can integrate with, such as Java, or via a Visual Studio plug-in. Even the biggest and best low-code vendors admit that just using low-code isn’t going to power your business.

    Low-code can’t be everything, but it can be a major part of everything. It just needs to look different from how most low-code platforms are designed. Using a hybrid low-code approach will allow organizations to truly use low-code from start to finish in the app development process. Rather than looking at low-code as a separate tool in the development process, a hybrid low-code approach brings low-code inside an IDE where traditional coding methods are still used.

    Is hybrid low-code the future of app development? I would say hybrid low-code is a next step in the evolution of app development. Low-code development tools shouldn’t be isolated in their own IDEs. It can be frustrating to leave a low-code IDE to finish the app in another IDE, and then have to connect the different elements into one cohesive app. As you can see, efficiency is reduced every time a developer leaves one IDE for another. Hybrid low-code views low-code as a tool inside a bigger development toolbox. It is there when convenient, but a developer isn’t forced to use just low-code. They can import already created assets from other languages, hand-code complex solutions, drag-and-drop when it makes sense, and create all the necessary components of a progressive web app with a click of a button.

    While there might be a profound realization that “traditional” low-code can’t do everything it originally promised, hybrid low-code could, instead, fulfill that promise.

  • Rookout Tool now Debugs Third-Party Code

    Rookout Tool now Debugs Third-Party Code

    Rookout revealed today it has extended its eponymous debugging tools to include third-party applications.

    Shahar Fogel, Rookout’s CEO, says most organizations today are building applications that rely heavily on code or modules developed by a third party. Rookout now makes it possible to analyze and debug that code before it is incorporated within a larger application environment, Fogel said.

    That’s crucial, because many of the operational issues a DevOps team is likely to encounter can be traced to flawed code written by someone outside of the IT organization, Fogel said. This new capability will reduce the amount of time DevOps teams spend trying to deduce the root cause of an issue, he said.

    Many IT organizations erroneously assume that all the code running in their environments has passed through a continuous integration/continuous deployment (CI/CD) environment, Fogel said. In reality, it’s not uncommon for developers to deploy code directly into a production environment in the name of expediency. Not all of that code, however, may have been written by the developer. Many developers wrongly assume the code they download from a repository was properly vetted and debugged.

    Rookout now makes it possible to debug both open source code and proprietary code written by a third party or present on an application deployment platform, said Fogel. Rookout collects the local variables, function arguments, tracing data, call stack and other relevant data, and can identify issues down to specific lines of code. Support for third-party code has been extended to the call stack level to enable developers to see how code execution flows across their own and third-party code.

    As more responsibility for applications shifts left toward developers, organizations need to provide them with tools to analyze applications and the platforms they run on. Beside building applications faster, one of the primary theoretical benefits of DevOps is the notion that developers can build more resilient applications, because it’s ultimately their responsibility to remediate any issues that arise after an application is deployed in production. In practice, that’s difficult to achieve when developers have no visibility into code that they didn’t write themselves.

    Going forward, there’s going to be a lot more third-party code running in production, as developers reuse application code encapsulated in containers downloaded directly from registries, Fogel said.

    The degree of accountability developers have for their appliations’ code currently varies widely by organization. However, given the right tools, and enough time, most developers would prefer to debug both the code they write and any they have incorporated, even if it were written by someone else. That desire, however, requires more time to build and test applications. Of course, it’s worth the tradeoff if developers encounter fewer incidents that require developers to debug applications after they are deployed in a production environment.