devopsy.kinsta.cloud

Author: Frank Ohlhorst

Best of 2021 – Transform Legacy Java Apps to Microservices

As we close out 2021, we at devopsy.kinsta.cloud wanted to highlight the most popular articles of the year. Following is the sixteenth in our series of the Best of 2021.

Velocity is one of the major tenets of DevOps, and anything that maintains or improves velocity benefits the overall process. Yet, there are still many speed bumps in the DevOps process that threaten to derail progress and slow DevOps processes to a crawl. One of the biggest speed bumps arises when transforming legacy monolithic applications into something more cloud-friendly—namely, microservices.

Microservices are clearly the future of applications developed for the cloud; research giant IDC predicts that 90% of all new apps deployed by 2022 will feature microservices architectures. IDC also notes the primary benefits of microservices are the improvements to developers’ ability to design, debug, update and leverage third-party code. Although DevOps tends to be about developing internal code, the benefits offered by a microservices architecture remain much the same.

Microservices: Getting There

Moving toward a microservices architecture can be straightforward or complex, depending on the path an organization is taking and where they begin. For example, if the goal is to transform legacy applications into microservices, the process can be complex and tedious. Transformation of legacy applications often means manually disassembling legacy code and breaking it up into standalone code elements that will run as microservices. That greatly complicates things for the DevOps pipeline, where fast iteration of existing code is the norm, not the exception.

However, there are tools coming to market that can ease the process. One such tool is vFunction, which recently came out of stealth with the mission to transform monolithic Java apps into microservices.

vFunction has an interesting approach to that process. The vFunction platform is deployed locally, where the vFunction Java virtual machine (JVM) agent examines legacy applications and gathers data which is then collected on the vFunction server. From there, software architects can further investigate the collected information about the legacy applications, and start designing a microservices architecture to modernize the codebase. “Once developers are satisfied with the design, vFunction generates a service specification file, which contains all the information required to create the microservice,” said vFunction CEO and co-founder Moti Rafalin. “That file is used by our automation engine, which scans the original code and copies the relevant artifacts to create the new service.”

Rafalin said that vFunction leverages supervised learning techniques, graph theory and clustering algorithms to identify dead code and code anomalies that could prevent a clean breakdown, or “decomposition,” of the legacy application. Ultimately, vFunction has the potential to automate many of the manual steps that DevOps engineers used to perform to break monolithic applications into microservices. According to Rafalin, vFunction makes the process as much as 15 times faster and can achieve somewhere between 80% to 95% automation. Currently, vFunction is focused solely on Java, which it deems the biggest opportunity today. However, the company has plans to support applications written in other languages in the future.

Beyond newcomer vFunction, there are other ways to deal with moving legacy Java applications into the cloud. One example is Anthos, which is a managed application platform that extends Google Cloud services into DevOps environments. Another is IBM’s Mono2Micro, which is an AI-based, semi-automated toolset to assist with refactoring monolithic Java applications.

For those looking to build microservices-based applications from scratch, numerous tools exist. Most interesting are the development environments that use rapid application development (RAD) techniques and leverage low-code models. There are dozens of RAD platforms available; prime examples being WaveMaker , OutSystems and AgilePoint.

In most cases, those moving legacy applications to a microservices model will usually select numerous tools, based on the particular use case. For some, it may be easier to rewrite smaller legacy applications; for others, refactoring may be the only way to capture the intellectual property in legacy applications. Either way, carefully selecting the appropriate tools goes a long way towards maintaining velocity in the DevOps realm. Maintaining that velocity proves critical for building cloud-friendly applications on budget and on time.

“Unless one modernizes those monolithic applications to be cloud-native, they end up requiring very large machines and often end up paying more to the cloud providers,” Rafalin said. “Organizations now understand that, if they want the true benefits of the cloud, they need to modernize these apps. And this starts with adopting an architecture that includes microservices, APIs, and modern design principles.”

The lesson is to choose wisely, and select toolsets that support scale as well as growth, and that can support the requirements of microservices.

December 27, 2021
How Log4j Becomes a Serious DevOps Problem
The recent discovery of the Apache Log4j vulnerability has wide-ranging implications for anyone who develops software, especially for those in the DevOps realm. What’s most troubling about the vulnerability (CVE-2021-44228) is how prevalent the use of Log4j is. The vulnerability is reported in a vast array of applications and directly impacts numerous Apache projects, including Druid, Dubbo, Flink, Flume, Hadoop, Kafka, Solr, Spark and Struts. There are also numerous Cisco programs impacted by the vulnerability. The list of impacted applications and libraries seems to be almost infinite, extending to Elastic LogStash, GrayLog2, Neo4J, Steam, Twitter and even the VMware Tanzu family of programs.

Simply put, any application that uses Log4J for logging and tracing is subject to the identified family of attacks known as Log4Shell. Those attacks prove easy to exploit and can be used to take control of vulnerable servers.

Why DevOps Practitioners Should be Concerned

The world of DevOps is all about reiteration, where features and improvements to applications are slipstreamed into production environments. To accelerate development, the QA process is usually limited to the most recent changes.

In other words, developers, via their pipelines, can often establish a baseline of quality and then speed up their CI/CD pipelines by testing only what has changed since the last iteration of the application. This process ensures an acceptable level of quality without introducing what are perceived to be unnecessary steps.

However, those processes do not take into account newly discovered flaws in older APIs and libraries, meaning that those flaws could telegraph into deployed applications and leave DevOps teams completely unaware of the impact and possible disruption. Detecting flaws after an application is deployed is like putting the cart in front of the horse.

Further complicating the situation is that many developers lack a well-defined and well-maintained software bill of materials (SBOM), which means developers may be unaware of the components and/or libraries being used in a deployed application.

Without an SBOM, it becomes increasingly difficult to remediate an issue with an application—especially if developers are unaware of the issue to begin with.

Where Should Responsibility Lie?

More often than not, vulnerabilities introduced into applications become a game of finger-pointing, where developers blame library suppliers or infosec staffers, and infosec blames developers for not performing due diligence on the components they are selecting to incorporate into their applications.

Of course, finger-pointing only adds to the angst and delays the process of remediation and does nothing to determine where the responsibility for detecting and remediating vulnerabilities lies. DevOps teams need to put these squabbles aside and establish a process that deals with unintentionally introduced vulnerabilities. What’s more, DevOps teams need to invest in DevSecOps to make sure that vulnerabilities are detected and remediated as quickly as possible.

To avoid the potentially massive disruption that a vulnerability like Log4Shell can cause, those running DevOps should consider:
- Creating and maintaining an SBOM
- Deploying automated tools that scan for discovered vulnerabilities
- Automatically comparing the SBOM against vulnerabilities
- Including DevSecOps processes within their CI/CD pipelines
- Frequently testing applications for flaws
- Coordinating with cybersecurity personnel when a flaw is discovered
- Patching frequently
With more and more vulnerabilities discovered on an almost daily basis, DevOps teams must be ever vigilant about what components are incorporated into their applications. What’s more, with the increased use of low-code/no-code tools and integrated development environments (IDEs), DevOps will also need to consider if those tools use other libraries that can become compromised.
December 20, 2021
AWS Outage Exposes Weaknesses of DevOps Resilience

The December 7, 2021 Amazon Web Services (AWS) outage severely disrupted services from a wide range of businesses for more than five hours and highlighted just how reliant businesses have become on internet-delivered services. The outage mostly impacted web services in the eastern U.S., yet the implications are universal: It’s a reminder that many businesses blindly ignored the old axiom about putting all your eggs in one basket and instead are relying on a provider with a single point of failure.

Services ranging from airline booking systems to streaming video to e-commerce were disrupted during the outage, causing millions of dollars in lost revenue and countless hours in productivity. One of the more interesting aspects of the outage is the impact it had on services from collaboration vendors such as Slack, Trello, Asana and Smartsheet—tools that many development and DevOps teams have come to rely on.

Furthermore, core AWS services, such as the company’s Elastic Compute and DynamoDB cloud tools were also impacted, disrupting many third-party services and severely hampering business processes that use those services. While the obvious victims of the outage are well known, like Amazon’s own e-commerce operation, there is a troubling undercurrent: The disruption to DevOps frameworks and those using them.

AWS has been rather tight-lipped about the root cause of the outage thus far; however, there are still many lessons to be learned for the DevOps community and questions that must be asked such as “Can the DevOps process survive during IaaS/SaaS disruptions?” and “Can multi-cloud failover solutions be baked into the applications DevOps builds?”

There are no simple answers to those questions, but the outage highlights the need to understand the underlying architecture and framework of a deployed DevOps system. Take, for example, how many developers in the DevOps community have embraced SaaS tools to accelerate the development process and to feed CI/CD pipelines. SaaS applications such as code scanners, pipeline orchestration and even IDEs have become common in the world of DevOps. But has anyone bothered to ask what happens if a single one of those tools fails?

What’s more, the reliance on SaaS tools in the development process has led to the creation of potential liabilities in the applications created by DevOps developers. DevOps applications have come to rely on APIs, are often driven by microservices and are frequently deployed into containers that run on SaaS. If any of those elements become non-functional, numerous applications could fail, ultimately putting the onus on developers to explain why they are creating applications with a single point of failure.

Moving forward, the DevOps community needs to take a serious look at the components of their frameworks and determine if there are any single points of failure—including their IaaS/SaaS providers. While it may be impossible to remediate every single one, there is a lesson to be learned about how fragile the development process can become if no one bothers to build an inventory of the tools used and take into account how a failure of any one of those tools could impact workflow. There are numerous examples of how an external failure of a single component impacted the functionality of an application, while the discovery process of the root cause has taken days or even weeks. This can be mostly attributed to not only a lack of knowledge, but a lack of visibility into the components used.

Those lessons can be extended to the development process itself, where the best practice of rooting out single points of failure can be extended to the applications themselves. Leveraging that intelligence starts with understanding the concept of a software bill of materials (SBoM), a piece of supporting documentation that is becoming increasingly important to the purveyors of applications. A properly-defined SBoM reveals all of the components (libraries, APIs, etc.) that are baked into an application and can be used as a map to define where weaknesses may lie.

For the DevOps community, the recent AWS outage has become a clarion call to look inward and discover how the applications they are building may be part of the problem. With continuity and resiliency becoming major topics in the IT and business realm, it’s about time that DevOps practitioners start to look at how they can support both of those business-critical needs. The days of finger-pointing to shift blame must come to an end, and if businesses that rely on software want to grow, someone needs to take responsibility for providing answers when outages occur and learn from those outages to create applications that are more resilient.

December 9, 2021
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.

May 18, 2021
4 Ways SASE Fuels DevOps Productivity

Many enterprises are adopting secure access service edge (SASE) solutions as part of their digital transformation efforts. SASE, in a nutshell, merges together SD-WAN and security stacks to deliver secure networking and improved WAN performance, making it a logical choice for cloud-enabled businesses going through the throes of digital transformation. However, SASE offers other benefits, which may be of particular interest to DevOps teams.

Let’s take a look at four ways SASE can enhance the productivity of DevOps teams.

Reducing Collaboration Challenges

SASE reduces the challenges associated with team collaboration. SASE, by design, integrates WAN optimization with cybersecurity. Today’s DevOps teams need to work together, despite being physically separated, and must have reliable, secure connectivity amongst the team. “DevOps are all about time-to-market, and DevOps teams are looking for ways to shorten their CI/CD cycles. A critical part of that process is reducing their dependency on the networking and the security teams,” said Boaz Avigad, director of product marketing, CATO Networks. “Since SASE solutions already provide optimized performance and robust security, DevOps [teams] are free from waiting for infrastructure teams to provision the necessary resources. SASE provides DevOps the control and operational cadence they need without compromising performance or security.”

SASE Improves Networking

SASE improves overall network performance with integrated load balancing and failover capabilities. DevOps teams cannot afford to lose connectivity, especially when rolling out new iterations of software or resolving bugs. “For DevOps teams, fast and reliable application performance is critical,” said Avigad. “SASE architectures free DevOps [teams] from worrying about the infrastructure by connecting all the company’s edges, data centers, mobile users and cloud resources, with the same self-healing, secure and fully optimized global network. Should a line fail or a route become congested, SASE automatically switches to an alternate path.”

Better Security Built In

SASE helps to secure DevOps projects with native cybersecurity capabilities. When properly implemented, SASE integrates numerous security technologies directly into the network stack. “DevOps teams worry about information interception and protecting their applications from threats. All security services share a single, unified context, improving insight and closing the gaps in legacy security architectures; gaps attackers often exploit,” said Avigad. “SASE not only includes NGFW, IPS, SWG, AV and MDR services, it also converges them together into a single-pass architecture.”

SASE Removes DevSecOps Burdens

SASE secures internal applications, along with the interactions with those applications, which in turn helps to reduce the burdens on DevSecOps team members. Applications that run over SASE/SD-WANs are further secured by zero-trust network access (ZTNA) and software-defined perimeter (SDP), technologies that help to keep all interactions between an endpoint and an application secure. “Many proprietary applications are too sensitive to run over the public internet. SASE protects those applications by obfuscating traffic, protecting all entry points with a NGFW and restricting access with its zero-trust architecture,” said Avigad. “All internal application traffic is also continuously inspected for threats.”

Adopting SASE for DevOps teams is beginning to make a lot of sense. The technology addresses many of the pain points that DevOps teams experience as businesses drive toward digital transformation. What’s more, the security benefits offered bring forth additional productivity, while also unifying the security stack.

April 14, 2021
App Testing Must Evolve Within the DevOps Pipeline

As the practice of DevOps evolves, so do the supporting tasks; hopefully in such a way that they introduce increased efficiency and automation to accelerate development and deployment pipelines. However, one specific process still remains a speed bump on the road to DevOps acceleration: the process—or, more specifically, the chore—of testing.

Naturally, testing is an undeniably important component of quality assurance. However, introducing efficiency into a process that dictates quality assurance can accelerate development and improve outcomes, especially when it comes to application testing.

“Application testing should never be done in a vacuum, or, worse, a silo,” said Sara Faatz director, developer relations at Progress Software. “The DevOps process can benefit from accelerating the testing process, introducing automation and embracing teamwork.”

Faatz makes some valid points; historically, application testing was treated as either a standalone or separate process, and often was performed by non-programmers following some type of script. “We discovered early on that creating synergy between testers and developers was an important concept for accelerating development, while fostering teamwork,” said Ramiro Millan, director, product development, Test Studio. “Addressing the trifecta of acceleration, automation and teamwork challenges actually requires adopting a different mindset when it comes to testing, especially when it comes to automation and communication.”

However, solving those problems requires adopting different procedures, as well as deploying tools to streamline processes and introduce automation. That said, there are ancillary challenges that also have to be addressed. For example, there is often a disconnect between the cultures of QA teams and development teams. Here, QA teams need to overhaul their processes and introduce more agile practices. In other words, the time is now to identify new practices and methods that allow QA teams to be creative and innovative while helping to test the software created by DevOps.

“Automation is becoming hyper-critical for testing. However, it is not just automation alone, but also the ability to run tests in the background and not hijack control of the console or the machine,” Millan said. “Automation should also bring with it the ability to concurrently run multiple tests in the background, which, in turn, accelerates the testing processes.”

That makes a great deal of sense. In many DevOps shops, QA has become a speed bump in the CI/CD pipeline, meaning that developers often have to wait for testing processes to complete before they can deploy anything. What’s more, developers are often disconnected from the status of testing.

“Communication between developers and testers is taking on renewed importance. Using tools that can hand off statuses between teams, while also enabling different members to participate in the processes, proves to accelerate execution times,” Faatz said. “The ultimate goal here is to bring forth faster delivery, less maintenance and more stability. I think stability is a big part of the equation. If we can automate those day-to-day, repetitive tasks, we garner that additional stability.”

Although testing is a broad subject, many of the lessons offered can have a beneficial impact on the overall process. Currently, many vendors are focused on subsets of the testing process, such as headless browser testing, PDF validation, UI/UX testing, backend integration and so on. This can be an indicator of just how complex the QA process can become if unified tools and automation are not introduced into the process.

“The trick, here, is to pick a tool that does not replace peoples’ processes, but transforms manual QA processes into something that can leverage automation,” Millan said. “Automation brings about consistency, and consistency brings forth improved results.”

The lessons learned indicate that testing must evolve to keep up with the DevOps model, and also suggest that DevOps is pushing QA teams to adopt new methods of testing and interaction. The only remaining question is how quickly QA can better integrate into DevOps, and eliminate the deployment speed bumps.

March 19, 2021
The Importance of Incorporating DesignOps Into DevOps

Design is a critical software project element that often goes unnoticed by those writing code. After all, coders and implementers tend to take the design process for granted and leave the look and feel of applications to the designers. In the days of waterfall based development, design was one of the first steps in the development sequence of creating a new application. However, with Agile and DevOps development practices, design became disconnected from the overall process.

“If you look at the full spectrum of AppDev, it becomes obvious that there are many elements that should be part of DevOps. Take, for example, cyber – today, there is a movement to integrate cyber into the DevOps pipeline, which the industry has started to call DevSecOps,” said Mark Troester, VP of strategy at Progress, a software company offering tools for developers and IT. “To make design a part of the iterative process of DevOps, teams need to think about including designers during the complete development process, something along the lines of how cyber has become part of the iterative process. In other words, teams should be embracing the concept of DesignOps,” Troester said.

To understand the challenges this creates for those looking to include design as part of the DevOps process, one only needs to look at how design, specifically user experience/customer experience (UX/CX) design, was done in the past. Designers would use tools such as InVision Studio, Axure, Proto.IO, Adobe XD, or one of the many other tools available, to prototype the look and feel of an application, or, more specifically, the end-user experience. The term DesignOps was coined to encapsulate the processes around design. However, DesignOps solely focused on the process of design, such as design workflows, design tools, design governance, team management, budgets and so on.

The ultimate goal of DesignOps was design creation; that design was then passed on to those who would write the code and develop the logic to bring that design to fruition in the form of an application. DesignOps worked rather well when an organization was adhering to waterfall development methodologies, where each step was clearly defined and the goal was to deliver a complete, finalized application to those requesting it.

“Larger organizations were able to field large design teams and could afford to implement a complete design system. When you have 50 or more designers, a complete design system becomes critical to manage design,” said Troester. “However, as AppDev has evolved into a more agile process, especially under DevOps, the disconnect between design and development became a significant problem.”

What Troester is alluding to is the reiterative development cycle used by DevOps teams, where applications are delivered in pieces and then further modified based on user feedback or business operational changes. Businesses today are embracing agile concepts, so they can react much faster to changing market conditions. This, in turn, means modifying applications as quickly as possible to maintain a competitive advantage. Currently, design remains somewhat siloed, and can become a bottleneck for implementing changes if the UX/CX must be modified to address those needed changes.

“With the rise of DevOps, teams need to start thinking of reiterative processes, where DesignOps integrates with the DevOps team, so there is collaboration between the designers and the developers, allowing design changes to happen quickly,” Troester said. “Yet, there are still remaining challenges – some created by the COVID-19 crisis – where designers and developers may not even be in the same building, much less the same time zone,” he said.

To Troester’s point, the COVID-19 crisis has forced businesses to evolve in ways that were once thought impossible. Developers, designers and even operations teams and individuals may no longer be sharing office space, and might be distributed across multiple locations. That complication will drive the need for better collaboration tools that bring design into the DevOps cycle.

“DevOps teams, as well as DesignOps teams, should be looking into technologies that can bridge the designer/developer divide. It will be critical in the near future to facilitate collaboration between design and development,” Troester said. “Perhaps, the answer lies with building some type of bi-directional API into design systems, which can play a key role in the implementation and support of design-first experiences,” he added.

Existing solutions to the current divide seem to be few and far between. But, that does not mean DesignOps and DevOps teams should not be currently looking for a solution to what will become a major problem as DevOps accelerates in the enterprise.

March 11, 2021
Top Misconceptions About Low-Code Development

Accelerating the pace of development has become one of the biggest goals in DevOps. After all, having teams speed the creation and modification of applications is supposed to be one of the primary advantages of DevOps pipelines. Yet, far too many DevOps teams run into speed bumps that can derail the process. For some, turning to alternative methods to generate and modify code can slay the beast of project deceleration, and that is where low-code platforms come into play.

However, the waters are muddied by misconceptions about what low-code is and what it isn’t. Here, three industry experts share their own observations about these common misconceptions.

Low-Code is Only for Citizen Developers

“People often confuse low-code with no-code platforms,” said Richard Rabins, CEO, Alpha Software Corporation. “No-code platforms, which are driven by visual modeling and user interface builders, are aimed at citizen developers with little or no coding experience to quickly build applications.” Rabins makes some good points; no-code environments are designed to put the power of application development into the hands of a citizen developer, meaning those no-code platforms are optimized for simple workflows and not for teams. On the other hand, low-code platforms can integrate with deployment platforms, which helps expedite delivery while also enforcing consistency.

Low-Code Makes Collaboration and Reusability Difficult

“Over time, many developers have come to believe that low-code platforms were built for a single programmer working on a waterfall project,” said Deepak Anupalli, co-founder and VP of Engineering at WaveMaker, Inc. “Today, low-code platforms, like WaveMaker, offer development environments that integrate with code management tools, as well as APIs, to support the sharing of code and fostering team collaboration.” Anupalli’s point is that the majority of low-code platforms incorporate workflows that support team activities. What’s more, those platforms support scale-up, reuse of code and the ability to work within pipelines.

Low-Code Prevents Custom Development

“From the beginning, low-code was all about building applications with little or no code needed, creating the perception that low-code platforms did not lend themselves well to customization,” said Rabins. “However, nothing could be further from the truth. Developers are able to expand the functionality of low-code projects as the need arises. They can insert custom code, call APIs, integrate with other platforms, and so on.” Rabins points out that low-code doesn’t mean no-code, simply that low-code can generate code that can be modified and adapted as needed, supporting pipelines that deliver fully customizable applications.

Low-Code Platforms are Only a Trend

Many seem to think that low-code platforms are just a trend that will ultimately fade away as other technologies come to light. However, according to Business Wire, the low-code market will grow 44.4% by 2022 to reach $27.23 billion. Anupalli added that WaveMaker has experienced year-over-year growth since the company was founded.

Leaders in the market today include Visual LANSA, GeneXus, Appian, Mendix, OutSystems, WaveMaker and Alpha Software.

Low-Code Solutions are Proprietary

One of the leading assumptions about low code platforms is that they all use some type of proprietary programming language. That may be true for a few platforms, but many embrace open source ideologies and use common languages, such as Java, PHP, and C#. Take, for example, the RISE Editor, which enables users to output code based on models in a number of different languages. RISE is not alone in the industry; several other platforms embrace either open source or can create easily accessible code. VisionX and WaveMaker create in Java, allowing generated code to be edited with other Java IDEs.

Low-code development platforms (LCDPs) have come a long way since the term was first coined by Forrester Research back in 2014. And yet, these numerous misconceptions remain, which may have slowed the adoption of LCDP in enterprises using DevOps pipelines. Dispelling these assumptions goes a long way towards helping application developers realize the benefits that LCDP can offer.

February 26, 2021
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.
February 18, 2021
How Managed Detection and Response (MDR) Solutions Benefit DevOps

Managed Detection and Response (MDR), a relative newcomer in the cybersecurity realm, is starting to have a noticeable impact on enterprises seeking to better secure their operations. Research giant Gartner notes that, “By 2025, 50% of organizations will be using MDR services for threat monitoring, detection and response functions that offer threat containment capabilities.” Despite rising adoption rates, though, much confusion remains about MDR and how it should fit into enterprise IT.

MDR is typically defined as an outsourced security service that enables organizations to better detect malicious activity over the network. MDR is usually sold as a service, and vendors offer tools and technologies that integrate into a business’s IT to detect and mitigate network intrusions, malware attacks, attempted data theft and other malicious threats. MDR can be a powerful ally in the quest to contain cyberattacks, but only if deployed correctly and leveraged properly.

Enterprise Benefits

MDR offers obvious benefits for enterprises, but there’s enormous potential when MDR is integrated with DevOps. Many organizations are turning to DevSecOps methodologies to build cybersecurity into their development and deployment pipelines, and MDR can help.

“One challenge is that DevSecOps is a term that is poorly defined in most cases, and misunderstood in many others,” said Dave Martin, senior director, product management – threat response at Open Systems. “Some people think of DevSecOps as an extension of a quality assurance department, which means that cybersecurity is mostly an afterthought, and not part of the development cycle. MDR, at least how we do it at Open Systems, brings forth a full-time security operations layer, which includes a security analyst, that can become part of the DevOps team,” Martin said.

Martin makes an interesting point. As more organizations attempt to implement DevSecOps, knowledge, along with action, are lacking. MDR has the potential to supplement knowledge and insight into the security posture of the code being generated. Many organizations leave cybersecurity to the network or operations teams, expecting endpoint or network security tools alone to contain threats. However, many threats in the wild may leverage older code, or target unpatched applications. MDR can enable DevOps teams to get ahead of the latest threats by keeping developers informed about evolving threats and vulnerabilities, as well as incorporating tools for continuous cybersecurity into the development and deployment pipelines. One of the core concepts of MDR is providing access to experts that can take action to mitigate an attack. This is an important consideration, according to the Enterprise Strategy Group, which reports that 51% of survey respondents face a problematic shortage of skills in the area of cybersecurity.

What’s more, MDR becomes a tool to secure the DevOps environment, as well as a tool for developers to make code more secure. “It is critical to find advanced threats, ones that may have bypassed existing security controls, before those threats impact DevOps, yet people need to be made aware of those threats so they are not mistakenly included in the development pipeline,” said Martin.

Choosing an MDR Provider

With so many players in the MDR space, choosing a provider that fits into a DevOps and enterprise strategy can be daunting. According to Reports and Data, the global MDR market is expected to grow at a CAGR of 30.4% until it reaches $4.6 billion by 2026. Today, providers number in the dozens, and while many claim they have “complete” offerings, they may not consider the needs of DevSecOps along with traditional network operations concerns.

There are some important considerations when choosing an MDR platform. For example, visibility of the attack surface is a critical concern. If an MDR provider does not have visibility into all potential attack surfaces, breaches and compromises may still occur. Also, adopters should be keenly aware of how false positives are contained, as well as the level of alert activity. Many cybersecurity solutions can introduce alert fatigue and obscure effectiveness. Automation should be a key part of any MDR solution, as it can help to categorize threats, initiate responses and identify the latest threat trends without human interaction.

“MDR should tear down many of the cybersecurity silos that businesses have today, and bring the various pieces of IT together into a unified cybersecurity sensitive culture,” said Martin.

Ultimately, MDR is about people, processes and technology, and should bring these elements together to ensure success in the ongoing battle against cybercriminals.

January 12, 2021