devopsy.kinsta.cloud

Category: Continuous Delivery

Continuous delivery is a software engineering discipline that allows organizations to consistently develop and release quality software at a rapid pace. It is achieved by automating the software development lifecycle, enabling tasks such as development, testing and release to occur concurrently and continuously.

  • Why App Dependency Mapping Is Critical for Cloud Migration

    Why App Dependency Mapping Is Critical for Cloud Migration

    Software dependencies are a crucial part of efficient, component-based programming. At the same time, they can be a hurdle for fast-paced agile development teams, because they can make it more difficult to deploy, update and migrate software applications. Many applications have dozens or hundreds of dependencies, each with its own transitive dependencies, making the problem worse.

    Dependencies are components that provide required functionality that a main component depends on. They can be incorporated into code using package managers like npm or Maven, Git-based code repositories like GitHub and container image registries like Docker Hub. 

    Application dependency mapping involves discovering and identifying dependencies and interactions between application components, their dependencies and underlying infrastructure. Creating a map of application dependencies is an essential part of gaining visibility over complex application structures and understanding the impact of deploying them in different environments.

    Why Application Dependencies Are Critical for Cloud Migration

    Application dependency mapping ensures you have identified all the components you must migrate to the cloud. You may not need to migrate all components to the cloud, but you do need to ensure all dependencies are identified and migrated together. Otherwise, your application may suffer performance issues because important dependencies remain on-premises.

    For example, if you move an application server to the cloud but keep the application’s database on-premises, your application will experience severe performance degradation and may also cause related applications to fail. Once a dependency is disrupted, all related applications suffer. Therefore, when migrating applications to the cloud, you must include all associated dependencies. 

    How Application Dependency Mapping Tools Can Help

    Application dependency mapping can help you avoid poor application performance and service outages. It is a critical component of the migration process, but is also difficult without automated tools. Application dependency mapping tools check an application and help with the following:

    • Modeling all inter-server relationships 
    • Identifying inbound and outbound connection latency
    • Determining the necessary TCP ports
    • Detecting running processes 
    • Application performance monitoring over time

    Cloud vendors offer specific application dependency mapping tools developed for their environments. For example, Amazon Web Services (AWS), Google Cloud and Microsoft Azure offer proprietary tools to help manage this process. However, these tools are tied to each provider, which means you should use the vendor tool that matches your chosen target cloud environment.

    Alternatively, you can use open source tools that provide similar services but are vendor agnostic. Use these tools if you want an assessment that is not specific to a single cloud vendor environment.

    Mapping Application Dependencies to Prepare for Cloud Migration

    An application consists of a hierarchy of dependent APIs and tools. The hierarchy starts with the application’s interfaces and then goes down through platform tools. Dependency management helps identify combinations of related versions and ensures that the development team recognizes new application dependencies when changes occur.

    Versioning application components

    The first step in this process involves versioning application components. If you intend to deploy a specific software component independently, you need to assign a version number for every revision and then track the dependency chain for this version. 

    This technique ensures you know the specific platform tool versions associated with each application version. If you need to roll back, you know what additional components you need to roll back to ensure version compatibility.

    Changing platform components

    This technique requires changing some platform components, such as middleware, which also requires synchronizing each application’s platform version. You should start from the top of the application dependency chain.

    Each application is designed to use specific operating system and middleware features, expecting “version Y or later” of the tools. As a result, you must validate each tool with a specified version against the tool’s dependencies and continue validating each of these dependencies until you reach the bottom of the dependency chain.

    However, some application dependencies are not as obvious and explicit as others. You may encounter problems if you expect to run a guest operating system in a virtual machine (VM) on a hypervisor platform in a different source. 

    You may also encounter issues if a cloud stack release, like OpenStack, requires a certain scripting language version. You can mitigate this issue by testing every dependency chain against the standard middleware and operating system combination, ensuring that all dependencies are recognized.

    Rebuild the dependency tree

    Once you are ready to move to the cloud, you need to supplement the dependency tree for applications and include all the references to the cloud provider’s APIs and features. Make sure to determine how the provider notifies of changes to tools and APIs and prepare to validate new dependencies these changes can create.

    For a multi-cloud or hybrid deployment, you must compare cloud dependency trees across all the components and applications planned to migrate beyond a cloud platform boundary. Note that having a different dependency tree for each provider can result in problems when scaling or failing over between providers’ platforms. You can avoid this by synchronizing components in advance.

    You should also rebuild your dependency trees whenever you change software platform components. A basic update could undo all the mapping and work you have done, and you can easily overlook a change to a small middleware component. You can mitigate this by setting up a life cycle management process to ensure dependency problems do not arise when incompatible elements are introduced. 

    Conclusion

    In this article, I explained the basics of application dependency mapping, and showed how application dependency tools can make cloud migrations safer and easier:

    • Versioning application components—Understanding what version your application expects for all dependent components.
    • Changing platform components—Determining the impact of switching out certain platform components. 
    • Rebuild the dependency tree—Use the map of your existing dependency tree to rebuild a matching dependency tree in the cloud environment.

    I hope this will help you evaluate the use of dependency mapping and make your next migration a success.

  • Who Controls Your Build Process?

    Who Controls Your Build Process?

    We have come a long way in a short time in IT, and are currently in a ‘digestive’ state, where we take a bit of a break and prepare for the next wave of changes. Okay, not really a break, just a change in what we’re looking at.

    In the old days, CPU, memory speed, network throughput and disk access times would be in constant flux; one would be the server performance bottleneck and, when that was resolved, another would be the bottleneck. We’re in that kind of relationship right now. The majority of organizations are now using DevOps and our focus is currently on DevSecOps along with multi-cloud. Along the way, by unwritten consent, vendors have started calling Kubernetes “cloud.” This is totally amusing to me as a pundit, because Kubernetes is really a “cloud killer.”

    All public clouds are based upon the premise that they will have massive lock-in. And Kubernetes breaks that premise—unless an organization uses a cloud vendor’s customized version of Kubernetes; then they have other issues. No, I’m not blind, I am well aware that there are other reasons that cloud lock-in occurs, but there is a difference between “We chose this bit of custom functionality, well aware it locked us into our chosen vendor,” and “The act of using this vendor locks us in.” Multi-cloud and repatriation are things that would not be popular enough to talk about if not for tools like Kubernetes.

    So the next bit, IMO, is that once cloud portability is an established fact at most organizations, we’ll circle back to another iteration of build management. Many organizations are still on CI/CD iteration 1.0 and using Jenkins to manage their build process. While companies like GitLab and Atlassian have taken a bite out of the Jenkins-as-build-management phenomenon, they are also solid lock-ins through value add, and both of these vendors (plus most others in wave 2.0 of DevOps-centric build management) are heavily invested in the cloud. While the ability to build in the cloud is a very good thing, the requirement that a tool which is central to your toolchain be run from the cloud is not.

    That means we’ll be circling back to visit this issue again. And probably sooner rather than later. There is no denying that budgets are going to decrease for the bulk of us in the coming months, and I have no idea when they’ll rebound. That means that recurring expenses—like mandatory monthly subscription fees—will take a hit in B2B the same as they are in B2C. Don’t shy away from those assessments. Actually look objectively at your monthly payment plans and determine the ROI of each subscription your organization uses. Years ago, organizations centralized and reduced the number of development tool subscriptions they managed; this is just a continuation of that process in modern times. Spend your organization’s money where it will reap the most rewards instead of “where we always have.”

    You also want to make sure that you trust the company in charge of your builds, and that you believe they are stable. Over the years, we’ve seen several examples of companies that appeared stable when they were not; actually making the assessment is important.

    You’re building and maintaining the systems that keep the organization online and productive. Don’t hesitate to cut the fat. And don’t hesitate to maintain control. If the tool and its lock-in are forcing the org to work in ways that don’t fit the culture, look at alternatives.

    In short: Keep your options open. We know that money will be tighter in the near future, so let’s be sure we’re set up for that and retaining control of our build process. And keep rocking it.

  • Continuous Delivery Advances Come at Cost of Testing

    Continuous Delivery Advances Come at Cost of Testing

    A survey of 820 application development professionals conducted by Applitools, a provider of an application testing platform, found well over a third of respondents (38%) working for organizations that now deploy daily changes to production environments.

    The challenge is that application testing is not able to keep pace with that rate of continuous deployment (CD). The survey found organizations are seeing test suites covering less than 50% of applications.

    Applitools COO Moshe Milman said a major reason test coverage is so low is that more than 40% of respondents said their continuous integration (CI) test suites can take more than an hour to run, which often resulted in tests either being postponed or possibly not run at all, he noted.

    Most organizations are also still relying on manual testing processes that can’t keep pace with the accelerated rate of application deployment and subsequent updates, added Milman. More than half of organizations (55%) automated less than half of their testing, according to the survey. More than two-thirds of respondents (67%) are embracing test automation to improve their test coverage, the survey found.

    In general, the percentage of organizations that are now employing CD processes to accelerate the pace at which applications are deployed is steadily increasing, said Milman. Manual testing processes, however, slow down the rate at which organizations deploy code. Many organizations routinely make trade-offs between application quality and a need to deploy code faster. Inevitably, there will be issues that can be traced back to decisions to not adequately test code prior to deployment, noted Milman.

    Overall, the survey found 90% of respondents building and deploying web applications, followed by 52% that were building and deploying mobile applications. Only 30% are building desktop applications. Testing of the applications, however, tends to vary widely. Nearly two-thirds of respondents (65%) said they tested applications on an end-to-end basis, with 55% testing integration followed by unit testing (53%) and application programming interface (API) testing (51%).

    However, only 26% tested application performance, followed by 13% that tested security and 12% that tested load, the survey found.

    Part of the issue, of course, is that it’s not always clear who is responsible for application testing. In theory, developers are accepting more responsibility for application testing as they take more responsibility for managing applications on an end-to-end basis. In practice, developers are often rushing to make application development deadlines. It’s not uncommon for developers to skip or limit testing in the name of productivity. Many of them have also embraced agile development methodologies that, at least theoretically, allow them to address any issues that might arise via the next application update.

    The issue that arises is that end users have become less tolerant of experimentation. If an application doesn’t initially work as expected, it’s exceedingly difficult to regain user confidence. Many will simply evaluate another similar application. The irony, of course, is that in the race to deliver code faster, application experience winds up being sacrificed because of the lack of time to properly test an application before deploying it.

  • JFrog Aligns With AWS to Improve Cloud Application Security

    JFrog Aligns With AWS to Improve Cloud Application Security

    At the AWS re:Inforce event this week, JFrog announced it integrated its JFrog Xray software composition analysis tool with AWS Security Hub, a cloud security posture management (CSPM) service that alerts IT teams whenever a security issue is detected.

    In addition, JFrog also announced it is participating in a preview of an AWS Marketplace Vendor Insights tool. AWS created Marketplace Vendor Insights to provide cybersecurity and compliance risk assessments of the third-party software made available on the AWS marketplace.

    Steve Bohac, partner marketing manager for JFrog, said the integration of JFrog Xray with AWS Security Hub will streamline the flow of cybersecurity alerts an IT team receives by centralizing the delivery via AWS Security Hub. AWS this week similarly moved to integrate the Amazon GuardDuty Malware Protection service with AWS Security Hub.

    Collectively, security services accessed via AWS Security Hub are intended to make it simpler for IT teams that have deployed application workloads on the AWS cloud to embrace DevSecOps best practices. JFrog Xray, for example, is designed to be deployed using the AWS Lambda serverless computing framework, noted Bohac.

    The arrival of these services comes at a time when the focus on cloud security, as part of a larger effort to better secure software supply chains, is rising in the wake of a series of high-profile application breaches. In general, cloud platforms are more secure than on-premises IT environments; however, the processes used to build and deploy cloud applications are often problematic in that mistakes are frequently made. Developers routinely use open source tools like Terraform to provision cloud infrastructure and accelerate application development. Most of those developers have limited cybersecurity expertise so, inevitably, there are misconfigurations that cybercriminals have become more adept at finding and exploiting.

    The ongoing chronic shortage of cybersecurity professionals means most organizations are not able to keep pace with the rate at which workloads are being deployed in the cloud.

    Fortunately, more organizations are also starting to embrace DevSecOps best practices to make software supply chains more secure. The challenge is that no matter how much time and effort is made to educate developers, there will always be a development team that makes a mistake. Tools such as JFrog Xray make it feasible to discover those issues before an application is deployed.

    It’s not clear how long it might be before DevSecOps has a meaningful impact on cloud application security. The number of applications already deployed on cloud platforms is already innumerable. In theory, at least, as each of those applications is reviewed and updated, they should become more secure as DevSecOps best practices are more widely employed. However, it may be years before the overall security of cloud applications materially improves.

    Eventually, the next generation of cloud applications should be substantially more secure than their predecessors. The hope is, in the meantime, any vulnerable cloud applications that have security flaws won’t be exploited before IT teams can bring to bear the resources required to fix them. In effect, it is a race against time.

  • RapidAPI Adds Tool to Make Building APIs Simpler

    RapidAPI Adds Tool to Make Building APIs Simpler

    RapidAPI today added a free RapidAPI Studio offering to its portfolio that makes it easier for developers to build, consume, manage and monetize application programming interfaces (APIs).

    Wade Wegner, senior vice president and head of product at RapidAPI, said RapidAPI Studio, available in beta, makes it simpler for developers to move between design and development, testing and management without losing context.

    It is also designed to be slipstreamed into developer workflows by either being accessed via a browser, as a desktop application, a macOS-native application or as an extension to the VS Code tools provided by Microsoft, added Wegner.

    That approach also makes it easier for teams of developers to collaboratively work on API projects, he noted.

    APIs are foundational to every modern application development initiative. Each microservice included in a modern application has its own API. As a result, the number of APIs—internal and external—that organizations are building and exposing has increased exponentially, especially as the number of digital business transformation initiatives continues to expand. While the bulk of APIs employed today are internally facing, the number of external-facing APIs being employed tends to rise sharply as more business processes become digitized.

    Less clear is who within the organization is responsible for managing those APIs after they have been deployed. In some cases, developers assume responsibility for them along with every other component of an application. Developers, however, tend to move on to other projects; DevOps and cybersecurity teams are being tasked with managing, securing and updating APIs. This is part of a larger effort to better secure software supply chains in the wake of a series of high-profile breaches.

    Unfortunately, documentation of those APIs has been somewhat lax within many organizations. In many cases, organizations are not even sure how many APIs have been deployed. Many organizations also discover, to their chagrin, that so-called zombie APIs previously abandoned by developers can still be exploited by cybercriminals to exfiltrate data.

    At the same time, the management of APIs is becoming more complex. Along with existing REST APIs and legacy web services based on XML, organizations are now deploying GraphQL APIs. The result is a mix of API schemas that require different levels of expertise to manage and secure.

    It’s not clear how the increased focus on securing software supply chains might impact API management. However, it’s apparent that cybercriminals are becoming more adept at discovering insecure APIs through which they can exfiltrate data. The challenge organizations face is that it’s not feasible to secure those APIs without first having a framework in place for managing them.
    One way or another, an API management crisis will soon come to a head as it becomes even simpler to build and deploy APIs. The only thing that remains to be seen is to what degree organizations will get ahead of that issue before it spins out of control altogether.

  • CircleCI Integrates CI/CD Platform With GitLab

    CircleCI Integrates CI/CD Platform With GitLab

    CircleCI today announced it has integrated its continuous integration/continuous delivery (CI/CD) platform with a rival software-as-a-service (SaaS) offering from GitLab.

    DevOps teams can now, for example, trigger pipelines in CircleCI from GitLab forked merge requests in addition to merging requests and making commits for specific branches. Other capabilities include the ability to access testing capabilities on the CircleCI platform and integrate permissions to ensure security.

    CircleCI CEO Jim Rose said the company routinely integrates its CI/CD platform with other offerings because organizations typically have multiple teams using different version control platforms at different times. The goal is to give those teams access to capabilities and best practices regardless of which specific platform they are using.

    In general, Rose said organizations are trying to strike a balance between the standardization of DevOps platforms and the need to enable development teams to innovate by adding new tools. Standardization tends to create more opportunities to automate more tasks in ways that reduce costs. However, developers will eventually rebel against any effort to limit the choice of tools they use to improve productivity, noted Rose. Too many senior IT leaders are quick to assume that a plethora of tools is an indication of a problem rather than the result of ongoing experimentation, he added.

    In the wake of the global economic downturn, many organizations are also revisiting their existing DevOps workflows to try to increase overall efficiency by automating more tasks. Those organizations realize they can’t afford to continue throwing labor at manual DevOps tasks, Rose added.

    The challenge, of course, is that building and deploying modern software is becoming more complex. Organizations are embracing microservices to make applications more resilient as they realize how dependent they are on software. The issue is that as the number of microservices continues to expand, it becomes apparent that legacy manual processes will not scale, said Rose. As a result, the impetus to automate DevOps processes becomes that much greater, he added. Less clear is to what degree organizations that have already embraced DevOps platforms might be willing to swap out their current CI/CD platform to achieve that goal.

    In the meantime, more organizations are embracing DevOps to manage software development projects that drive a wide range of digital business transformation initiatives. The applications driving those processes typically need to be continuously updated as business requirements change. That becomes much easier to achieve when using processes optimized around continuous development and deployment.

    Regardless of which underlying CI/CD platform organizations choose, they should assume that, eventually, some level of integration between those platforms will be necessary. After all, in the event of an acquisition, for example, it’s not likely both companies will have standardized on the same DevOps platform. Given the amount of time required to migrate from one DevOps platform to another the amount of time required for interoperability is inevitably going to be measured in months if not years.

  • VW CEO Fired for Dev Fails | Fiber Shortage Hits | Google Fires Blake Lemoine

    VW CEO Fired for Dev Fails | Fiber Shortage Hits | Google Fires Blake Lemoine

    Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.

    This week: Herbert Diess is out at VW because software is hard (yo), fiber optic cable is hard to find, and the guy who said LaMDA was sentient is dumped by Google. (more…)

  • Empathy for the API Developer

    Empathy for the API Developer

    Security teams have always been perceived as an impediment to delivery by software teams who feel that security imposes arbitrary and unreasonable policies and use poorly-integrated tools that are beset with high false-positive rates. With the advent of DevOps, security has been seen as an increasing obstacle to rapid deployment cycles. 

    Security teams believe developers do not care about security and will try their best to avoid security controls or policies. Security teams are often frustrated by developer pushback when remediating vulnerabilities, particularly when they fail to appreciate the cascading effects of making code and dependency changes late in the life cycle.

    From my perspective, with a foot in both camps and a decade of experience helping developers produce more secure code, I believe the key to addressing the disconnect between teams is to develop greater empathy for the developer.

    Why Insecure Software Exists

    Software development is a complex endeavor with many (often conflicting) requirements. Blaming software developers for insecure software is an overly simplistic and counterproductive approach, best summarized by a former colleague:

    “I can tell you that virtually all developers I talk to care about application security. They care about the quality of the products they create, the integrity of the data their software handles, and the reputation of the organizations they work for.” —  Jim Jastrzebski, Veracode

    From my experience, developers don’t deliberately set out to create insecure software; instead, there are a number of reasons it happens.

    Devs are overly optimistic: Developers are creative folks and natural problem-solvers. They can often visualize the perfect end result of their labor without necessarily considering the technical and security debt they may encounter along the way. Remember—things do go wrong.

    Overconfidence: I often refer to this as the Dunning-Kruger effect for developers. Faced with complex platforms, languages and frameworks, developers tend to overestimate their ability to comprehend and master them. Complex systems take time to fully understand and being overly confident can lead to unintended consequences and compromise security. Beware of insecure defaults and configurations.

    Bad things only happen to other developers: Think of this as a kind of schadenfreude for developers. During code reviews with developers, I have been surprised to hear comments like, “ … But that won’t happen to my code!” Despite vast evidence to the contrary, some developers think that bad things only happen to others and to others’ code. Assume a defensive mindset; expect the worst and hope for the best.

    Taking shortcuts: Developers are goal-oriented and want to produce working code on schedule. And schedules are tight. The inevitable consequence is that sometimes shortcuts are taken (missing error handler or input validation, for instance) leading to security vulnerabilities. Track and tackle your technical debt.

    Technical debt or legacy code: Speaking of technical debt, it’s probably one of the biggest issues facing developers: The burndown of technical debt and maintenance of legacy code. Software systems are complex and minor changes may wreak havoc, especially in microservices-based applications and architectures. Remember that developers may have legitimate concerns about making changes that are not absolutely necessary.

    This stuff is difficult: The biggest thing to remember to develop the empathy muscle is to appreciate the difficulty of the software development process. Developers are facing multiple conflicting requirements against tight deadlines and are required to master a variety of technologies. Mistakes will happen; the important thing is to learn lessons and improve the process.

    The last point is perfectly captured by this quote:

    “90% of security problems are just complexity problems. It’s technical complexity, it’s network complexity, it’s organizational complexity.” — Adrian Ludwig, Atlassian

    Care and Feeding of Developers

    Once security engineers have a better understanding of the challenges facing developers, they can focus on their messaging when communicating about security issues. Remember that the developer is unlikely to be personally responsible for every issue and should not be blamed or scolded. This will produce defensive behavior and is unlikely to achieve a positive outcome. Focus on the shared security challenge at hand and how a joint approach can solve the problem.

    A frequently-cited problem for developers is the relatively high false-positive rates security tools produce, particularly with code scanning tools. Security engineers should make sure that the tools are suited to your technical stacks and fine-tune the tool as much as possible. Ideally, the security team should triage the initial report and remove obvious false positives. 

    Additionally, certain legacy security tools do not integrate well into CI/CD pipelines and cannot be easily automated within the build process. If a developer has to use a manual or asynchronous process to perform a security scan, they will become frustrated and possibly ignore this requirement. Make sure security tools work well with the developer’s environments and workflows.

    Do not assume every developer has a deep understanding of the security issues identified—take the time to explain them thoroughly and/or document them internally. A great approach is to conduct shared learning sessions where developers and security teams work through a vulnerable application together to learn the concepts.

    Another frustration developers cite is a lack of clear understanding of the security requirements or requirements that are constantly changing. Ensure security policies are clearly stated and available to developers, and explain the reasons why the policies exist in the first place—for example, to meet PCI DSS accreditation. 

    Finally, make sure the combined teams are given time not just to learn but to absorb lessons and that success is recognized and rewarded. 

    “The sky is always falling—we never celebrate success.” – Chris Romeo, Security Journey

    Empowering Developers

    So, what does developer empathy look like for API developers?

    First, API developers and security engineers can both benefit from the positive security model that uses the OpenAPI definition as the contract for API behavior. Anything not specified by that contract is considered invalid—in other words, the contract specifies the allow list. This is in stark contrast to the traditional approach for web security which is reliant on blocking according to a block list—obviously, not all bad input can be known leading to false negatives with this approach. Overly aggressive blocking may block valid input and typically result in false positives; familiar to users operating web application firewalls (WAFs).

    The OpenAPI definition offers another advantage: The applicable policies can be expressed as code in the definition as opposed to via some verbose, abstract policy documentation. The benefit of policy-as-code is to uniformly enforce policy across the life cycle starting when the developer first starts coding the API. 

    Finally, developers need security tools that work in their preferred environments (for example, first-class IDE and CI/CD plugins) and provide value in the form of remediation guidance or actionable findings that help developers reduce technical debt. 

    Security and development don’t have to be at odds; help developers to help themselves by building empathy and working with them rather than against them.

  • Future of DevOps: Trends to Watch

    Future of DevOps: Trends to Watch

    Technology is transforming every aspect of industry, and digitalization and automation have flourished in the past few years. DevOps has established itself as an indispensable software development methodology for successful digital transformation.

    According to a recent market survey, the DevOps market will exceed $20 billion by 2026, growing at a CAGR of 24.7% from 2019 to 2026. DevOps has facilitated rapid and dependable software development, delivery, improved quality and higher customer satisfaction.

    DevOps, too, is continuously evolving to meet the changing demands of the corporate environment. Let’s look at the future of DevOps and the trends you should expect to see.

    Serverless Computing

    DevOps teams will see a rise in the adoption of serverless architecture, mainly because of the massive capital and operational costs of server infrastructure. Numerous DevOps groups are working with modular components offering an overview of the pipeline. Moving these modular components to serverless architecture will empower groups to mitigate a few pieces of errands identified with pipeline architecture and focus on deployment and development of the product.

    Serverless computing streamlines overall DevOps operations, including the complete software life cycle, from development to deployment, testing and maintenance in one place. Also, serverless computing reduces the developer’s workload by taking care of server maintenance, such as cloud monitoring and system updates. Other prime USPs include flexibility, reliability, speed and cost-efficiency.

    Microservices Architecture

    Microservices architecture has been gaining popularity as an alternative to traditional monolithic architecture in the IT industry, and this trend is expected to continue. Microservices architecture is a pattern of organizing computer systems into segments that can scale on demand. A microservices architecture pattern is the next evolution of service-oriented architecture (SOA) that structures an application as a collection of coupled services. If one piece of the application fails, microservices make it easy to identify and contain the issue without disrupting the whole application.

    DevOps and microservices architecture enable decentralized teams to innovate rapidly, maintain control over their tech stack and standards, track performance metrics, supervise the development and release cycles and reduce overall consumption time by achieving shorter software release intervals.

    Low-Code/No-Code Applications and Platforms

    To keep up with the demand for new applications and features, many organizations have turned to low-code/no-code development to deploy applications swiftly. Adopting a low-code approach with DevOps is a game-changer. It enables developers to experience higher agility and gives the organization a competitive advantage in the fast-paced, demanding software market.

    Low-code applications allow non-technical ‘citizen developers’ to contribute to software development with the help of visual interface integration. In addition to end users, developers and DevOps engineers are set to play a crucial role in this trend, using low-code platforms and tools that offer drag-and-drop elements and other extensions. These low-code application development tools support every aspect of software development, including app ideation, analysis, software design, code development, quality assurance, deployment and documentation.

    DevSecOps

    Many large enterprises are integrating and automating security into DevOps processes. The transformation from DevOps to DevSecOps is expected to gain even more momentum in the future. According to a forecast, the DevOps market size is expected to reach $5.9 billion by 2023 at a CAGR of 31.2% during the forecast period.

    More companies will embed security controls earlier in the software development cycle to ensure application security. Tools and frameworks will simply integrate with CI/CD pipelines and testing tools will see a rise in 2022. DevSecOps empowers developers to consistently track, monitor and remediate security defects during the various stages of development while improving the speed of delivery and quality.

    Kubernetes and GitOps

    Kubernetes is an open source container orchestration platform emerging as an infrastructure trend on the operations side. Kubernetes will expand further into the software development space in 2022 and beyond. It will ease the task of starting a local Kubernetes cluster on a developer’s machine. Kubernetes security is expected to take center stage as well, through infrastructure-as-code (IaC) scanning.

    GitOps is a Kubernetes-related infrastructure trend that allows developers and IT operators to use Git to manage clusters and deliver efficient, secure applications without misconfigurations. It automates releasing incremental updates, and consistent delivery will enable developers to build, test and deploy software rapidly.

    AI and ML

    Artificial intelligence and machine learning have already transformed the way businesses operate nowadays. In 2022, it is anticipated that AI/ML will further streamline and accelerate every phase of the SDLC. It enables DevOps teams to enhance their performance through intelligent automation, improving feedback and managing alerts.

    Advanced analytical methods like predictive analytics are becoming increasingly important as the market evolves. AI can enable proactive investigation of the DevOps pipeline to identify problems and offer possible solutions. AI and ML integration also enable deep learning, data mining, statistics and modeling, becoming an integral part of your business’ workflow.

    Conclusion

    DevOps continues to evolve and pivot to drive significant IT transformations that directly bolster business goals and objectives. It will assist in enhancing the company’s ability to design, produce, launch and maintain high-quality software solutions. The above trends will help organizations move rapidly beyond automation, focusing on continuously improving outcomes. These trends are catalysts for creating a regular and dependable release pipeline and building better communication between development, IT and business teams.

  • Poor App Remediation Creates a Vicious Vulnerability Cycle

    Poor App Remediation Creates a Vicious Vulnerability Cycle

    A survey of 200 security professionals found nearly 83% of respondents reported that an increase in the rate at which applications are being deployed has led to an increase in the reintroduction of previously remediated vulnerabilities.

    The survey, conducted by Waratek, a provider of tools for managing security-as-code, found 93% of the security professionals polled currently work for organizations that have embraced DevOps or Agile development methodologies. Half of the respondents (50%) described maintaining security in those environments as challenging, with a slightly higher percentage (58%) noting that implementing security within DevOps process does slow down the rate at which applications are deployed. A full 85% also noted that manual security work slows the rate at which applications can be deployed as well.

    Surprisingly, more than two-thirds (67%) of security professionals also said they would be willing to sacrifice security to allow applications to be delivered on time.

    Nearly three-quarters (71%) also said they expected that keeping pace with DevOps teams would only become more difficult, with 61% also noting that keeping pace with DevOps teams resulted in delays to other critical security projects.

    Waratek CEO Doug Ennis said the root cause of the application security challenge can be traced back to continued reliance on manual processes. It’s too easy for developers, for example, to reuse code that contains vulnerabilities that were fixed in one version of an artifact but not another, he noted.

    That lack of automation also conspires to increase overall cybersecurity fatigue, added Ennis. More than 50% of survey respondents reported they spend days or weeks each year investigating false positives. There simply are not enough cybersecurity professionals available to make sure applications are secure without relying more on automation, said Ennis.

    In the wake of a series of high-profile security breaches, there is more focus on software supply chain security than ever. However, it’s not clear to what degree organizations are embracing automation and DevSecOps best practices to secure those software supply chains. The challenge is finding a way to build more secure applications without slowing down the rate at which those applications are built and deployed.

    Many organizations are clearly already shifting more responsibility for application security left toward developers and DevOps teams with hopes of achieving that goal. However, it’s still the cybersecurity team that get the call whenever there is a breach, noted Ennis. There must be workflows in place that enable automatic remediation in ways that don’t always require organizations to wait on a developer to build and deploy a manually-applied patch that is usually inconsistent, he added.

    The Log4Shell vulnerability is a perfect example of how flawed the current process for building and deploying patches is, Ennis explained.

    In fact, as more applications are deployed, developers often find themselves spending more of their time fixing vulnerabilities than they do writing new code. A new approach to building and deploying secure applications that leverages automation is clearly required. The challenge is creating automation that consistently achieves that goal each and every time required in a way that doesn’t break any of the applications that need to be fixed.