devopsy.kinsta.cloud

Category: Features

  • Organizations Prioritizing Java Application Modernization

    Organizations Prioritizing Java Application Modernization

    A survey found that modernizing existing Java applications is a higher priority than other projects for 87% of respondents, with more than 80% of these applications expected to be re-engineered over the next five years. The survey polled 450 IT professionals working in organizations in the U.S. and United Kingdom that have more than 500 employees.

    Conducted by the market research firm Vanson Bourne on behalf of Diffblue, a provider of a generative artificial intelligence (AI) platform for refactoring applications and generating unit tests, the survey also found enterprises plan to invest nearly half (45%) of their software development resources on modernization of existing applications versus developing new ones. A full 90% of respondents expected to rely on automation to accomplish those tasks, the survey found.

    Specifically, survey respondents reported they planned to rely on automation to improve security (50%), increase development velocity (45%) and improve developer experience (42%). Well over half of respondents (58%) said they had already been working on these projects for more than 12 months.

    If organizations don’t modernize Java applications, more than half of respondents (51%) said too much time would be spent on unproductive coding, while 50% said development velocity would be adversely affected. The biggest obstacles cited are choosing the right technical approach (45%) and securing budget (42%).

    More than half of organizations (59%) have created a dedicated modernization budget to support their efforts. Nealy half (48%) said funds are being provided by business teams for projects, while 49% said general operating budgets have increased.

    Diffblue CEO Matthew Lodge said it’s clear there is a huge commitment to application modernization. The reality is the majority of work IT teams do involves applications that have already been deployed. The challenge they face is that the effort required to modernize these applications is still far too dependent on manual processes, he added.

    Overall, the survey found 96% of respondents considered Java applications extremely or very important to their organizations. On average, 65% reported additional Java applications are still being developed. Only 4% said they planned to migrate away from Java as part of a modernization effort.

    Over half of the respondents expected to use Java 11 (53%) or Java 17 (56%) in their applications, compared to 19% using Java 8. More than a quarter (27%) expected to use a forthcoming Java 21 release. A full 100% expected to use the Spring framework to build these applications, with more than half (54%) planning to upgrade to the latest version that supports Java 17. A full 97% said unit testing is an “extremely” or “very important” element of their application modernization effort.

    After experiencing something akin to a mid-life crisis, Java has itself been modernized with the release of Java 17, noted Lodge. The Java community is now adopting many concepts that may have been pioneered in other programming languages, he added.

    Regardless of whether organizations are modernizing existing Java applications or writing new ones, the one thing that appears certain is the venerable programming language isn’t about to disappear any time soon.

  • DevOps Done Right: How to Succeed in DevOps From Day One

    DevOps Done Right: How to Succeed in DevOps From Day One

    Whether you are diving into DevOps for the first time or trying to do it right this time, DevOps Onramp provides all the information you need for a successful DevOps journey. Join us on May 4, 2023, to learn how to get started with DevOps—and how to do it right.

    You’ll learn:

    • DevOps best practices, processes and the tools you’ll need
    • Tips and tricks from experienced practitioners sharing their real-world experiences
    • The basics of DevOps
    • How to choose the right technologies
    • Common challenges and how to overcome them
    • The benefits of DevOps as a methodology and a career
    • And more!

    As organizations face increasing pressure to adapt faster and become more agile, getting DevOps right and adopting a DevOps mindset is crucial to deliver high-quality software faster and increase business value. And that opens up great opportunities for anyone looking to start a new career or pivot from an existing role in technology.

    DevOps has become the standard of software development methodologies and it’s critical for successful digital transformation. Adopting DevOps—and doing it the right way—can benefit not only your organization but also your customers and end users by fostering innovation, reducing time to market, increasing development productivity, improving product quality and reliability and reducing costs.

    That’s why many big companies, such as Amazon, Netflix, Facebook and many others have adopted a DevOps mindset—and DevOps practices. And as more businesses are looking to move to the cloud and transition into DevOps, there are plenty of job opportunities available for DevOps engineers at various levels.

    DevOps is a growing field with a lot of opportunities for professional growth. According to a research study by Global Market Insights Inc., the DevOps market is expected to surpass $30 billion by 2028. Due to the high demand for skilled DevOps engineers and the shortage of qualified DevOps professionals in the industry, there is no better time to upskill than now.

    Whether you are diving into DevOps for the first time or trying to do it right this time, DevOps Onramp provides all the information you need for a successful DevOps journey.

    At DevOps Onramp Virtual Summit, taking place on May 4, 2023, you’ll get all the knowledge you need to get started with DevOps —and how to do it right. Join us to learn about DevOps best practices, processes and tools and get tips and tricks from experienced practitioners sharing their real-world experiences. We’ll go through the basics of DevOps, how to choose the right technologies, common challenges and the benefits of DevOps.

    One thing is for sure: The future of DevOps is very promising. The rush has started—don’t be left behind!

    DevOps Onramp Virtual Summit - Submit your talk

    If you’re interested in becoming a sponsor, please contact us. For more information, please visit the DevOps Onramp website.

  • Understanding the Infrastructure Automation Maturity Model

    Understanding the Infrastructure Automation Maturity Model

    Nearly every company wants to evolve its digital transformation and increase the pace of software delivery and operations. And infrastructure automation is a new means to achieve these ends. It supports the emerging discipline of platform engineering and can increase scalability and reactivity to unforeseen events, enabling software ecosystems to be more anti-fragile. Increased infrastructure automation also helps free up engineers from focusing too much on managing DevOps when they really should be building out new features.

    But introducing more infrastructure abstraction can be met with certain challenges. This is often because departments have a wide range of cultures, processes and tooling already in place. With varying maturity levels across teams, it can be challenging to gauge where a company is before attempting to introduce new automation across the board. And as further evolution may require significant changes, having a baseline is key to planning for the future.

    I recently chatted with David Williams, senior vice president of market strategy at Quali, about an internal technique they’ve been using at Quali to gauge the maturity of their clients’ infrastructure automation. Their infrastructure automation maturity model breaks down the journey into four unique stages, moving from the least-mature ad-hoc automation to the most-mature autonomous solutions. Below, we’ll review this model and consider what questions need to be asked to ascertain where your team sits on the spectrum. We’ll see how enterprises can leverage such a model to hone in on improving their software operations.

    Four Questions to Determine Infrastructure Maturity

    DevOps is still a wild west in terms of how people approach it, said Williams. So before attempting to mandate sweeping cultural changes, it helps to first determine the base level of DevOps maturity within an organization. Here are four questions that can quickly assess the state of infrastructure automation within an organization.

    1. What Culture Already Exists?

    First, it’s good to evaluate the culture that already exists. How do teams deliver value and how is this value measured? Perhaps throughput or code quality is measured with specific metrics or SLAs. Understanding the DevOps attitude (and aptitude) within the organization will highlight pre-existing capabilities and show how teams collaborate.

    2. How Are People Organized?

    The genetic makeup of teams can dictate much about development and operations. How are teams organized? Are they large, siloed teams? Or are they two-pizza-sized teams? Understanding team organization and communication patterns are necessary to identify bottlenecks.

    3. What Processes Are Already in Place?

    Next, consider the development timelines and procedures already established and in use. Are teams applying SAFe, Lean, Agile or Scrum methodologies? What are these exact processes and how mature are they? Answers to these questions will demonstrate general release cadences and how teams drive productization.

    4. What Infrastructure Automation is Already Being Used?

    Lastly, you’ll need a window into what level of infrastructure automation, if any, is already in use today. How is it delivered? How is it managed? How is the success of this automation measured, and what is the overall outcome? You will likely find that automation is typically quite siloed and teams have differing approaches. This auditing is vital to identify what works well and what doesn’t.

    The Four Levels of the Infrastructure Automation Maturity Model

    Asking the above questions will quickly determine an organization’s “readiness state,” said Williams. But how do these answers map to the overall maturity of the organization’s infrastructure automation? Well, he shared four basic levels of infrastructure automation maturity that are commonly found in practice throughout today’s software development environments, ranging from bespoke scripts to more robust self-defining automation.

    Level 1: Ad-hoc

    The most basic level of infrastructure automation is ad-hoc integrations involving a mix of old and new technology. This level is chaotic and fragmented, with varying processes used throughout the organization. These bespoke integrations and scripts also may not have excellent visibility, limiting the potential for reusability within an organization.

    Level 2: Automation

    Next is having automation that is specifically tied to a certain technology stack. Nowadays, organizations are commonly hybrid multi-cloud, having adopted automation piecemeal with each new stack. This often results in multiple silos of automation stacks that are blind to each other. At this maturity level, one automation might fire off another automated procedure and so on, but engineers aren’t 100% aware of how they influence each other.

    Level 3: Frictionless

    The next level of infrastructure maturity begins to take the reins with more intentional automation adoption. At this stage, organizations embrace an internal developer platform, similar to Spotify’s Backstage, that helps engineers deliver and manage infrastructure more seamlessly. This tooling is more advanced than other levels integrating key commands into the developer’s IDE. Doing so eliminates the need to switch between environments and reduces friction.

    Level 4: Self-Defining

    Finally, the most advanced form of automation involves deeper intelligence within application operations, including the ability to dynamically optimize infrastructure. At this stage, infrastructure is self-defining, meaning production applications can automatically adapt, be self-governed and enable bursting and non-bursting capabilities. Such intelligence is typically proprietary to cloud providers, said Williams, yet companies often desire this intelligence inherent at the application level. Williams describes this stage as the “intelligent allocation of resources in line with application life cycle requirements.”

    Benefits of Self-Defining Infrastructure Automation

    Self-defining infrastructure automation has many benefits for companies, including having the infrastructure in line with application needs, scalability and measuring usage to optimize cloud spending. Many points within the software development life cycle could warrant increased automation, such as infrastructure-as-code (IaC), deployment release engines, configuration, traffic scalability, cloud management, containerization and documentation. But it’s not until you open conversations around infrastructure automation maturity and understand who is responsible for managing it that you can hone in on what areas can be improved.

  • Akamai Makes Case For Next Era of Cloud Computing

    Akamai Makes Case For Next Era of Cloud Computing

    Akamai Technologies today unveiled a cloud computing service that combines its ability to deploy applications at the edge with the cloud platform it gained via its acquisition of Linode.

    Shawn Michels, vice president of product management for compute and apps at Akamai, said Akamai Connected Cloud will provide the foundation for running a new generation of modern applications that require access to both core infrastructure resources in the cloud alongside highly distributed edge computing services.

    As part of the effort to deliver that combination of services, in the second quarter Akamai is adding three sites in the U.S. to the 11 it already provides. In addition, Akamai revealed it had identified 10 additional cloud sites and 50 distributed edge computing sites that it will add throughout the rest of this year.

    As a long-time provider of a content delivery network, Akamai manages a massive distributed computing environment that spans 4,100 locations across 135 countries. The acquisition of Linode added a set of cloud computing services that enable Akamai to offer the same set of services, including CDN services, as cloud service providers.

    Akamai is now signaling it will compete more aggressively by discounting the egress fees charged whenever data is moved off a cloud platform. One of the most expensive and unpredictable costs is the egress fees cloud service providers charge whenever data is moved off their platforms, noted Michels.

    Finally, Akamai also revealed it has achieved ISO, SOC2 and HIPAA standards compliance for its services.

    Akamai is making a case for an alternative approach to cloud computing that it said will be optimized for both existing monolithic applications running on virtual machines and cloud-native applications based on containers and serverless computing frameworks. A recent survey of 458 development professionals, managers and senior leaders conducted by Techstrong Research, a sister entity of DevOps.com, found 43% of respondents are considering adding additional cloud service providers in the next 12 months. Nearly two-thirds said they are at least considering, evaluating or are ready to buy from a trusted alternative cloud vendor, with 20% reporting they have already contracted with one.

    It’s not clear whether IT organizations might actually migrate existing applications from one cloud service provider to another. At the very least, Akamai expects that as new applications are developed, the company will be able to gain a larger share of the overall market.

    There’s no doubt that a new era of cloud computing is dawning as organizations look to deploy distributed applications that process and analyze data closer to the point where it is created and consumed. These applications will then share the results of the data processed at the edge with, for example, centralized data lakes that make it possible to analyze data collected across a distributed computing environment.

    The one thing DevOps teams can count on is that as this next era of cloud computing evolves, the management of IT environments will become much more challenging for all concerned.

  • Five Great DevOps Job Opportunities

    Five Great DevOps Job Opportunities

    DevOps.com is now providing a weekly DevOps jobs report through which opportunities for DevOps professionals will be highlighted as part of an effort to better serve our audience.

    Our goal in these challenging economic times is to make it easier for DevOps professionals to advance their careers. Of course, the pool of available DevOps talent is still relatively constrained, so when one DevOps professional takes on a new role it tends to create an opportunity for others.

    The five job postings shared this week are selected based on the company looking to hire, the vertical industry segment and, naturally, the pay scale being offered.

    We’re also committed to providing additional insights into the state of the DevOps job market. In the meantime, for your consideration:

    Monster.com

    AppZen
    San Jose, California
    Software Engineer
    $165,000 to $190,000

    Indeed.com

    Safeway
    Pleasanton, California
    Lead DevOps Engineer
    $147,500 to $206,600

    Dice.com

    Amazee Global Ventures, Inc.
    Broomfield, Colorado
    DevOps Engineer
    $140,000 to $150,000

    SimplyHired

    WEX, Inc.
    Remote
    DevOps Engineer
    $127,000 to $169,000

    LinkedIn

    Apple
    Newport Beach, California
    Site Reliability Engineer/DevOps
    $115,000 to $177,000

  • Lineaje Unfurls Platform for Creating and Managing SBOMs

    Lineaje Unfurls Platform for Creating and Managing SBOMs

    Lineaje this week unfurled a platform for creating and managing the software bills of materials (SBOMs) that are increasingly mandated by enterprise IT organizations and government agencies.

    Fresh from raising $7 million in seed funding, Lineaje CEO Javed Hasan said the SBOM360 platform provides a simpler way to manage all the SBOMs that will soon inundate organizations.

    The SBOM360 platform makes it possible to use a search engine to discover all the components of an application and all the dependencies that exist within it, including vulnerabilities, and indicators of compromise (IOCs) in seconds, said Hasan. The company then adds fingerprinting technology that enables the platform to attest to the authenticity of the entire software supply chain, he added.

    While there is no shortage of tools for creating SBOMs, there are not as many platforms that enable DevOps teams to both create and manage them. In the wake of an executive order issued by the Biden administration requiring federal agencies to have an SBOM for all the software they use, interest in SBOMs to better secure software supply chains has significantly increased. However, very few organizations have a process in place that enables them to operationalize all the SBOMs that might be created.

    More challenging still, the pace at which software is being updated has accelerated to the point where many SBOMs are likely to be outdated. The only way to keep pace with that rate of change is to rely on a platform designed from the ground up to dynamically create SBOMs in seconds, noted Hasan.

    Finally, IT organizations are now being held more accountable for legacy software often polluted with vulnerabilities that need to be remediated, he added. As such, organizations need a tool that makes it simpler to identify vulnerabilities within the context of an SBOM.

    It’s not clear whether greater awareness of the need for SBOMs is translating into concrete action, but the expectation is that more organizations will soon be following the lead of the federal government by requiring them. That shift will naturally bring a lot of additional pressure to bear on DevOps teams. Historically, organizations tended to allow developers to aggregate software components without always checking to see if they are compromised. Cybercriminals are becoming increasingly more adept at injecting malware into software components in the hope that malware will find its way into any number of downstream applications.

    Regardless of the approach an organization takes to better secure software supply chains, more rigor is being applied to how software is built and deployed. The days when developers were free to aggregate software components as they saw fit by, for example, relying on open source software downloaded from a repository, are now at an end. The expectation now is the developer will be held accountable for the integrity of all components used within an application as organizations move to implement additional processes to more rigorously review code before it is deployed in a production environment.

  • flox Unveils More Accessible Instance of Nix Framework

    flox Unveils More Accessible Instance of Nix Framework

    This week, flox launched a more opinionated implementation of the open source Nix framework that programmatically automates package management and system configuration.

    Fresh from raising an additional $16.5 million in funding, flox CEO Ron Efroni said the company will also make an enterprise edition of its namesake flox framework available later this year.

    The Nix framework has been available since 2003 and provides DevOps teams with a portable, fully isolated development, test and production environment along with a catalog and tools for managing software packages. There are more than 5,000 contributors to the platform, but Nix is based on a unique programming language that many DevOps teams have found challenging to master.

    The flox framework provides a higher layer of abstraction for invoking Nix, and provides a set of guardrails to make the framework more accessible to a wider range of DevOps teams, said Efroni.

    That approach will make it easier to share development environments and packages across teams, machines, individual developers and entire organizations. The framework also provides visibility into the software bill of materials (SBOM) for applications used in production environments to enable real-time vulnerability management and detection without scanning, noted Efroni. That capability makes it easier to discover dependencies spanning multiple architectures; many organizations today still try to track dependencies using spreadsheets and tools that don’t serve to make DevSecOps processes simpler to manage, he added.

    It’s not clear how many organizations are using Nix today, but Efroni said that as software development management continues to become more complex across multiple platforms and architectures, there is a clear need for a different approach to enabling portability at scale. The biggest obstacle is overcoming the psychological biases many DevOps teams have developed toward Nix over the last two decades, he noted. A more opinionated framework should reduce the overall fear factor associated with Nix, noted Efroni.

    Regardless of the frameworks employed, it’s become apparent that DevOps teams are struggling under the weight of all the code they must manage, much of it written in multiple programming languages. Many organizations that embraced DevOps early are now finding the platforms they deployed have become challenging to manage and maintain. As application environments become more complex, there is a need to modernize DevOps workflows. Less clear is whether those efforts might be focused on, for example, containers and serverless computing frameworks versus a framework such as flox that is designed to span multiple architectures and platforms.

    It might be a while before IT organizations develop a unified approach to application development and deployment, given all the preferences of individual development teams. However, with the rise of platform engineering, it’s apparent more organizations are trying to strike a balance between developer freedom and the need to reduce the total cost of DevOps. That cost continues to rise as additional software architectures and platforms are employed.

    In the meantime, flox plans to contribute to both Nix and its own more opinionated version of the framework in the hopes of one day making it easier to achieve that goal.

  • Atlassian Extends Scope of Jira Project Management Portfolio

    Atlassian Extends Scope of Jira Project Management Portfolio

    At the Atlassian Presents: Unleash event today, Atlassian announced it is adding a Jira Product Discovery application to its portfolio. Jira Product Discovery makes it easier for organizations to keep track of the ideas that drive software development initiatives.

    At the same time, Atlassian is making available Jira workflow and toolchain templates to make it simpler for software development teams to extend the scope and reach of the project management software they use to track those projects. Rather than each organization developing these templates, Atlassian is now providing them in a way that allows organizations to customize and extend them as they see fit.

    Finally, Atlassian also announced that an existing Jira Work Management tool will be made available for free through March 2024.

    Megan Cook, head of product for software teams at Atlassian, said these additions will make it easier for organizations to collaborate around software development projects that businesses increasingly depend on to drive revenue. The overall goal is to make it easier for multiple stakeholders of the projects to more easily collaborate with software developers that rely on Jira to manage those projects, she added.

    These latest offerings are part of an ongoing Atlassian effort to enable organizations to simplify collaboration and enable organizations to embrace value stream management (VSM) without having to acquire a dedicated platform. In some cases, organizations may decide to adopt a dedicated VSM platform, but a project management application should make it simpler for everyone in an organization to keep track of how software development projects are impacting the business, noted Cook.

    It’s not clear just how many businesses are aligning their internal processes around DevOps workflows, but as more of them realize how dependent they are on software, there is a clear need to collaborate more efficiently with software development teams. In fact, many organizations are now trying to adjust to the rapid rate at which software is being delivered thanks to the adoption of DevOps best practices. In some instances, updates to software are now being delivered faster than many businesses can absorb given the impact those changes have on digital processes.

    The irony is many business executives used to routinely complain about how long it took IT organizations to adjust as business conditions changed. Now, many businesses are rolling out additional digital capabilities via software updates that can be made multiple times a month.

    The rate at which organizations will collaborate across departments will naturally vary, but the days when each department was a fiefdom unto itself are coming to an end. There may even come a day when organizations will need to restructure as the walls that once separated various fiefdoms become more porous.

    One way or another, the way organizations are managed is evolving in the digital age. Organizations are employing software to pivot more frequently as business conditions evolve. Each new idea can not only be tracked but also quickly evaluated for feasibility given the level of software development resources required, noted Cook. The challenge and the opportunity is as much about changing the culture of an organization as it is about modernizing the processes used to build and deploy software.

  • Report Affirms Continued AWS Cloud Dominance

    Report Affirms Continued AWS Cloud Dominance

    A report published this week by Wiz, a provider of a cloud security platform, found more than half of organizations (57%) are using multiple clouds, with 22% currently using three or more platforms.

    However, the report also noted that 72% of all workloads are running on the Amazon Web Services (AWS) cloud. Among organizations that have more than one cloud platform, Microsoft Azure (41%) is the most common secondary platform (41%), while Google Cloud Platform (GCP) is the most used tertiary platform among organizations employing two or more clouds (44%).

    The report also noted 9% of AWS customers use managed database servers, compared to 87% in GCP and 82% in Azure. However, over 91% of companies also have non-managed database servers running in a cloud. In total, only 6% of companies use managed database servers exclusively, compared to 90% using a mix of managed and non-managed database servers, the report finds.

    The most widely deployed databases are PostgreSQL, Redis and MySQL, with 90% of organizations running at least one instance of a PostgreSQL server.

    Scott Piper, principal cloud security researcher for Wiz, said the report makes it clear that despite gains by Microsoft and Google, AWS remains the most dominant cloud service provider. Even after a decade, rival cloud service providers have not been able to overcome the first-mover advantage that AWS continues to enjoy. In many cases, a second or third cloud is being employed only because a single development team preferred it or an IT team assumed responsibility for it when their company acquired another organization using it, noted Piper.

    However, while most organizations have multiple accounts per cloud service provider, the report also found that the bulk of the application workloads are managed via only a handful of accounts, he added. That suggests more organizations are subject to higher levels of disruption in the event of an outage than many of them may realize, said Piper.

    One of the reasons so many organizations have a narrow range of accounts, of course, is they simply don’t have enough personnel. In fact, a general skills shortage also tends to limit the number of cloud platforms organizations might otherwise employ.

    Multiple cloud platforms also tend to exacerbate cybersecurity challenges. With the introduction of each additional cloud service, the overall size of the attack surface that needs to be defended expands. The Wiz report found 47% of organizations have at least one database or storage bucket publicly exposed to the internet. It can take less than 13 hours for cybercriminals to discover and access an exposed bucket with a guessable name, noted Piper.

    More challenging still are the number of application programming interfaces (APIs) that need to be secured as cloud service providers continue to add new services, he added.

    Ideally, organizations should be adopting a framework to harden privileges, encryption, authentication and connectivity and improve hygiene, otherwise known as PEACH, said Piper.

    Regardless of the approach to cloud computing, it’s apparent there’s still a long way to go before organizations are ready to embrace hybrid cloud computing spanning multiple clouds.

  • Appdome Integrates Mobile Security Platform With CircleCI CI/CD

    Appdome Integrates Mobile Security Platform With CircleCI CI/CD

    Appdome this week made available an integration for the continuous integration/continuous delivery (CI/CD) platform from CircleCI that promises to make it simpler to secure mobile applications before they are deployed.

    As a provider of a platform for securing mobile applications running on iOS and Android platforms, Appdome provides a runtime application self-protection (RASP) platform that, among other capabilities, provides code obfuscation, mobile data encryption, jailbreak detection, root detection, man-in-the-middle attack prevention, on-device anti-malware, anti-fraud, anti-cheat and anti-bot capabilities.

    The platform is now integrated with the Circle CI/CD platform via the Orb framework created by CircleCI to simplify integrations with third-party tools.

    Karen Hsu, senior vice president of mobile DevOps and security solutions for Appdome, said the Appdome Build_2Secure Orb for CircleCI is an example of a series of integrations the company plans to make involving DevOps tools and platform that will make it easier to apply DevSecOps best practices to the deployment of mobile applications. That’s critical because it’s not uncommon for teams using different DevOps platforms and tools to be involved in the development of the same application, she noted.

    A recent Appdome survey suggested consumers are about to force the DevSecOps issue for providers of mobile applications regardless of how mature their processes are. A full 94% of respondents said they would promote a brand if the mobile apps protected them versus 68% that said they’d abandon brands that offered no protection.

    Securing mobile applications is especially challenging because once an application is compromised, it’s relatively trivial for cybercriminals to also inject malicious code into other applications running on a mobile device. There are no automated remediation capabilities, so the best defense is to isolate applications in a way that prevents malware from executing in the first place, noted Hsu. At a time when it’s already clear cybercriminals will be using artificial intelligence (AI) platforms to launch attacks, organizations will not have the time required to remediate vulnerabilities before malware is activated, she added.

    That Appdome approach provides the added benefit of reducing tensions between developers and cybersecurity teams that otherwise would be requesting immediate fixes to mobile applications that have been compromised, noted Hsu. As more mobile applications are built and deployed, the overall goal should be to enable both teams to work collaboratively together without unnecessarily disrupting each other’s workflow, added Hsu.

    It’s not clear what percentage of the applications being built and deployed today are destined to run on mobile devices, but securing those applications clearly presents some unique challenges. Many of those applications are deployed on consumer-grade devices attached to wireless networks that are not especially secure. Cybercriminals are increasingly targeting these devices not only to access sensitive data but also because they often provide a gateway through which the rest of an IT environment can be compromised.

    The simple truth of the matter is, sadly, DevOps teams need to assume that most mobile applications are going to be running in the cybersecurity equivalent of a hostile environment where the odds are considerably stacked against them.