devopsy.kinsta.cloud

Tag: CD

  • The Differences Between DevOps and GitOps

    The Differences Between DevOps and GitOps

    The transition to a DevOps model has been welcomed by many organizations that are looking to implement more efficient development processes. However, there are multiple models to choose from, with GitOps a popular choice for many. So what is the difference, and which one is better?

    In this article, we will discuss what each model entails and their key differences and establish if one is better than the other for your business.

    What is DevOps? – An Overview

    The DevOps model involves several tools and practices designed to make software development much more efficient. This increase in efficiency is achieved by implementing more automation, adopting continuous delivery practices and improving the communication channels between the developers and operations. 

    Ultimately, DevOps is designed to assist organizations in deploying new products and systems faster. By establishing more collaboration between development and operational teams, changes can be made quickly to best suit the business’s overall goals. 

    There is no single tool that is required for DevOps. In fact, your team can use any tool that effectively improves communication and automates key tasks. 

    How to Integrate a DevOps Strategy

    Adopting and integrating a DevOps strategy into your organization’s overall workflow is not a difficult process, and it can be achieved by following these steps: 

    1. Create a continuous integration/continuous delivery (CI/CD) pipeline.
    2. Configure this new pipeline to enable the automated deployment of changes to your development/production environment.
    3. Set up an alert and monitoring system for your development environment. 
    4. Create collaboration channels so operational teams can inform the developers of new opportunities to improve the business’s workflow. 

    An Overview of GitOps

    GitOps is a modern concept that was initially introduced by the Kubernetes management system Weaveworks. This model uses Git, an open source, distributed version control system, to track any changes to a system and who has made them. 

    The GitOps model uses a Git repository as the single source of truth (SSoT), improving collaboration between developers and operational team members. This, in turn, allows organizations to automate the deployment process. 

    By leveraging CI/CD pipelines like DevOps, changes are automatically applied to the codebase without any need for manual input. Thanks to Git, these changes can also be easily reversed if needed, reverting to a previous working version. 

    How to Integrate a GitOps Strategy

    GitOps can be integrated into a business’s workflow quite simply by following four key steps: 

    1. Set up a Git repository for your organization’s codebase. When integrating a GitOps strategy, an organization does not need to use GitHub exclusively, as any code repository that uses Git commands can do the job. 
    2. Connect this repository to a CI/CD tool.
    3. Configure your chosen tool to deploy automatic changes to your development environment. Popular tools include Jenkins and Circle CI. 
    4. Set up monitoring and alerts for your development environment. 

    It should be noted that the CI part of GitOps still needs to go through your DevOps tool, whether it’s GitHub Actions or AWS CodeBuild. 

    The Differences Between DevOps and GitOps

    The core difference between the two is that GitOps allows teams within an organization to manage and deploy changes to infrastructure using Git as the single source of truth. DevOps, on the other hand, focuses on effectively connecting development and operational teams using a tool of the organization’s choosing. 

    Either model can offer a number of benefits in terms of development and deployment, but there are notable differences between the two that should be considered. It should also be noted that DevOps and GitOps can work in unison as long as continuous integration (CI) is delivered using your chosen DevOps tool.

    DevOps – Key Elements

    • The DevOps model is considered a working culture.
    • DevOps can use a variety of CI/CD pipelines and is not restricted to any one tool.
    • This model increases automation and the regularity of deployment, reducing any human input. 
    • Cloud configuration can be used for coding, supply chain management and other key requirements.
    • The pipeline separates development and operations processes while improving collaboration between the two.

    GitOps – Key Elements

    • GitOps is a development and deployment technique that relies on the Git version control system.
    • Git is used as the single source of truth for all changes to the codebase.
    • GitOps can use Kubernetes and infrastructure-as-code (IaC) practices and various other CI/CD pipelines. 
    • The GitOps model is designed to increase development times and reduce reliance on lengthy scripts.
    • It also enables a smoother transition between a project’s development and operation stages.

    DevOps Vs. GitOps – Which Model Is Better?

    Both GitOps and DevOps are becoming increasingly popular when it comes to adopting new approaches to improve software development processes and making deployment quicker and more efficient. As outlined above, the difference between the two models largely comes down to the tools that are used, but the result is roughly the same in terms of the overall benefits. 

    Deciding which approach is the right one for your organization or determining which one is “better” will always come down to the needs and requirements of your organization. In fact, the ideal scenario would be to integrate GitOps so it works alongside your DevOps approach. 

    GitOps is not a replacement for DevOps, as the CI process still relies on DevOps tools. However, GitOps can improve the effectiveness of the DevOps team thanks to continuous delivery processes. Using Kubernetes-native mechanisms and commands and sticking to standard source code principles, GitOps does not require developers to change how they work, guaranteeing a seamless implementation process.

    Wrapping Up

    DevOps is a working culture that improves collaboration between development and operations teams and utilizes automation tools, resulting in rapid and more efficient software development. GitOps, on the other hand, uses Git as the single source of truth, making it easy to track changes and further increase development times thanks to continuous delivery processes. 

    Although each model can be used exclusively, they can also work alongside each other to deliver rapid software development and high levels of collaboration. Therefore, it is unfair to claim that one model is better than the other, as they can both play their part in an overall DevOps strategy. 

  • Are We Delivering?

    Are We Delivering?

    I had an interesting conversation today where I was told, “We do great with CI but terrible at the CD part.” My immediate reaction was to point at all the great CD activity going on in vendor space right now. But as I stopped to ponder, I realized that we’re doing all of that great CD activity to play catch-up.

    DevSecOps has us covered in spades—the toolsets allow for scanning and protection all through the process, from the first line of code to application retirement. I would argue that after being left out in the cold, DevSecOps has done a better job than DevOps at the right side of the equation.

    In DevOps, the various “cloud-native” deployment models (I use scare quotes because they’re not really cloud-native. If you dig into them, nearly every one of them includes Kubernetes in their definition of cloud) are starting to do the job admirably, but in shops starting to automate the entirety of the process, the CI part has been automated and code delivery accelerated for a good long while.

    In short, adoption seems to prove, once again, that the benefits of rapid development are more important than the benefits of offering a stable, repeatable deployment environment. This makes one wonder what, exactly, we should be doing to convince IT and business leaders in orgs smaller than web monsters that security and repeatability both demand the implementation of capable continuous delivery.

    I think we failed the audience when we allowed pundits to blather on and on about deploying thousands of times a second when most applications in most orgs need to deliver at a significantly slower pace. And not only that, but want to deliver at that slower pace, given the “Don’t fix what isn’t broken” rule. Even if the environment is stable, rolling out for a single minor bug fix is possible but it’s not the best use of time—both computer and human.

    But we are catching up. We have things like GitOps and Kubernetes automation catching up with the rate of development; security is already there and test automation is ready to find issues before deployment. It is simply implementation that is behind and, as time goes on, more orgs will get the implementation part nailed.

    And through that process, you’ll be there, rocking it. Step up and make sure it is done right. The entire process is there; you could sleep better at night knowing that it is all in place and you are not likely to get a midnight call. Your org loves stability, you love good nights of sleep … Go out and get it.

  • It’s a Toolchain!

    It’s a Toolchain!

    I was talking with some friends the other day, and we got to discussing how inaccurate the word “toolchain” is. We pundits–and even a lot of marketers–use the word toolchain regularly and, while it’s not a terrible encapsulation of what we’re doing, it is, at best, a hasty generalization. There are a lot of reasons for this.

    The biggest reason is that “your toolchain” can have meaning when talking to a single DevOps team, but an organization rarely has just one. And increasingly, even single teams will use different tools depending upon the project they’re currently focused on. There are a lot of languages, targets, environments, specialized tools, frameworks, etc. that are unique and interdependent. Any organization that actually ends up reaching “one toolchain” will keep that honor only until the next merger. Or until the next project starts up. Because in the end, IT is about solving problems and while some things like OSes get standardized, others do not, as they are focused on solving those problems.

    Then we have the variations. Even ‘one’ toolchain is really not the same chain of tools; it is the same CI/CD tool managing a pool of others. This has really interesting connotations for the idea of the “weakest link in the chain,” whether we’re talking security, compliance or testing, because the weakest link might depend on which tools are spawned this run. To take an easy example that doesn’t overlap with the biggest reason above—targeting containers for test and virtual machines (VMs) for deployment. Some organizations do this type of thing regularly due to licensing or space issues. Two different deployment steps in ‘one’ toolchain. There are more instances like this than you would think. “This project uses make, that one uses cmake” is an example of the type of scenarios we’re talking about. These minor variations are handled by what gets called from CI.

    Finally, most of the real-life organizations I stay in touch with are both project-based and are constantly evolving. That makes both of the above scenarios the norms, not the exceptions. While they would love to have one stack and one toolchain for all projects, no one realistically sees that happening anytime soon. Some organizations that crank out precisely one type of application for one type of audience (dynamic web apps for a particular market, for example) can get to a single DevOps toolchain, but most do not.

    A windbag like myself claiming that we’re using the wrong term—and that toolchains should always be plural when having these discussions—does not make it important. I do think it matters though because what is useful for one toolchain is not for the next. The oldest, most established and, arguably, most thorough code analysis tools are for C/C++. Talking about how we have a solution to help add testing to your toolchain is not terribly useful if the point is to extoll the virtues of those code analysis tools and the audience is full of people from primarily Python or Go shops.

    Right now, important tools for you to consider are those that make your work easier. Consolidation should be high on your list of priorities; we have far too many DevOps tools. Merging should be a consideration. Yes, Python and Ruby have different needs, but if there is a single tool that can offer build or test for either based on information contained in the pipeline, grab it so two toolsets don’t bifurcate your build process.

    And keep kicking it. Seriously. In the grand scheme of things, we’re entering a bit of a rough patch in IT, but you all have been managing to keep the org online and functioning for plenty of rough years. Don’t stop now. Your users would thank you if they weren’t annoyed by that spelling error on the button of the “About” page. So I’ll do it for them. Thank you.

  • Cloud: Why Must We Be Confusing?

    Cloud: Why Must We Be Confusing?

    When I was a kid learning to play Dungeons & Dragons (D&D), the concept of level was never confusing—though the authors should have seen that it very well could be. For those unfamiliar, D&D has many uses of the word level—character level, caster level, spell level, dungeon level and, increasingly, as time went on, monster level. I can almost guarantee that I missed some uses of the word level in the game, but you get the idea.  In fact, if I missed your favorite, feel free to add a comment.

    We used context to determine what was meant, and we clipped along without any (game) world-shattering consequences. Though some people were horribly confused.

    (Side note: I worked with D&D co-creator Gary Gygax for a while and he knew about the over-use but didn’t feel that after D&D’s surge in popularity it could be fixed. His later RPG creations did seek more clarity and less word reuse, but most RPG systems available today still have many uses of the word level.)

    I am comfortable declaring that those of us who grew up on RPGs are now running vendor companies and doing analysis. Otherwise, why would we have so many uses for unique words? I mean, we no sooner got DevOps than we made a total mess about what, exactly, you meant when you said “CD”. Was it continuous deployment? Continuous delivery? Both? Similarly, we malformed continuous integration. Let’s call it CI—and then make an entire market around it really being continuous test while it is still used to refer to continuous integration, because that is not at all confusing.

    But then we jumped to cloud, and spent some time being really busy trying to confuse everyone about what “cloud” actually means. Is it only public cloud, or does it include private cloud? If private cloud, does that include virtual private cloud only, or does it include cloud in a co-host or data center? Is SaaS actually cloud, or is that a completely different beast?

    And that brings us to the reason I came here to write this particular blog post. We are now being barraged with “cloud” that includes Docker hosted on Kubernetes. I think of this as akin to one too many uses of the word “level”.

    Kubernetes is not cloud. It offers similar infrastructure in a smaller format, but the key to Kubernetes is that it supersedes cloud. Kubernetes doesn’t care about your cloud (or lack thereof) once it has been implemented. Cloud simply becomes infrastructure-as-a-service (IaaS) when Kubernetes is deployed. This is terribly important for a variety of reasons, not the least of which is that if you drop Kubernetes onto a cloud provider, you have two sets of infrastructure to lock down. Two sets that have a lot of internet exposure—because it’s not called “public cloud” for nothing.

    I do understand where referring to Docker hosted on Kubernetes as ‘cloud’ comes from; there are a ton of similarities. But Kubernetes needs a platform—hardware or virtual—to run on. And hand-waving the implications of that nested relationship is asking for trouble. And when cloud is either a thing of the past or so totally commoditized that people don’t think about it, Kubernetes or its successors will likely be the reason. So let’s take it easy re-using cloud too much.

    In the short term, though, my advice is that if someone in the industry mentions cloud in their product offering or analysis, ask which use of ‘level’ they mean. Because honestly, Kubernetes, if implemented on hardware or IaaS, can be picked up and moved to whereever it is needed. And that’s not “cloud”.

    Keep kicking rear. Doesn’t matter where your apps are running, it matters that you’re keeping them running and locked down. Keep it up, and call things what they are—container orchestrators are not cloud platforms, no matter which functionality they share. And to all my RPG peeps, keep having fun. There are always new adventures to be had… No matter the level.

    Image: Photo by S L on Unsplash.

  • 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.

  • NS1 Touts a Common Delivery Platform for Devs and Ops

    NS1 Touts a Common Delivery Platform for Devs and Ops

    NS1 has extended the capabilities of its DNS and network management platform with the release of NS1 Connect. The platform is designed to serve as a delivery platform that integrates developer and network operations teams’ tasks for the creation and management of applications across highly distributed cloud-native and on-premises environments.

    While DevOps teams typically rely on dozens of tools for the deployment of software and the management of the network connections on which the software runs, NS1 was created to—among other things—reduce the number of different tools DevOps teams require by improving visibility, automation and management for these processes.

    In this way, NS1 Connect provides a unified API framework to automate DNS, traffic optimization and network services management across heterogeneous networks, Sanjay Ramnath, vice president of products at NS1, told devopsy.kinsta.cloud. NS1 Connect’s reach covers internal and external applications deployed via on-premises, cloud or hybrid infrastructure. This enables NetOps and DevOps teams to integrate NS1 solutions into their infrastructure and CI/CD pipelines with lower complexity and enables NetOps teams to accelerate management and minimize the risk of misconfiguration, Ramnath said. “Prior to this, teams had to deal with complex manual processes or disparate API frameworks that slowed down their ability to develop, deploy and deliver applications.”

    In his talk, Your Business Depends on Eliminating Boundaries Between Applications, Users, Infrastructure, and Data during INS1GHTS 2021, NS1’s annual user conference, Ramnath described how a number of NS1 products and services are integrated into a single platform under the NS1 Connect umbrella. They include cloud-native network services for DNS, DHCP and IPAM (DDI), edge-to-cloud networking for NS1’s managed DNS, dedicated DNS, private DNS and DNS for China and application traffic automation for VPN traffic steering, pulsar active traffic steering and general traffic management. Other commonly used network services are provided as well, including IP address management that can be centralized across the network, said Ramnath.

    The idea was to remove many of the roadblocks DevOps teams face when seeking to deploy on highly distributed infrastructures. “The goal here is to remove some of those boundaries and barriers that are talked about on the infrastructure side,” says Ramnath. “[This helps to make sure] that our control plane is centrally provided and centrally consumable as a cloud solution and that our products can be deployed wherever they are needed in a zero-touch way, in a lightweight fashion, making sure that we are aligned with cloud-native operations.”

    The need to maintain low latency across distributed infrastructures is also key. As David Coffey explained during the conference in The Future of Application Traffic Intelligence and Automation session, low latency is essential for creating “that great experience for users.”

    “Low latency is not an attribute of this feature, it is a top, tier-one priority for people to accomplish, but it’s an incredibly complicated aspect, given all of the frameworks that are out there—the tools, the DevOps capabilities and the components required to support and deploy these modern-day applications,” said Coffey. “That’s what enables application companies to deliver that low latency and treat it as an attribute in the system; not having to go out of their way to create this. We want to enable all developers to embed this into their system—and we can provide them with a degree of success for delivering that great experience to their customers and to their networks.”

  • Harness Acquires Drone CI Project

    Harness Acquires Drone CI Project

    Harness announced it has acquired Drone.io, creator of the open source Drone continuous integration (CI) project.

    Company CEO Jyoti Bansal said Harness, which provides a continuous delivery (CD) platform delivered as a service, will offer Drone to organizations that want a CI platform alongside a CD service from a single vendor. However, Harness will also continue to facilitate the integration of its namesake CD platform with other CI platforms.

    Drone will continue to be freely available as open source software and will be re-christened Harness CI Community Edition. Drone Enterprise will be sold as Harness CI Essentials Edition. Later this year, Harness plans to introduce Harness CI Enterprise Edition, which will extend the core platform.

    The two companies claim there are currently more than 50,000 active Drone community users for a project that is supported by 250 contributors. Organizations that have adopted Drone include eBay, CapitalOne, Cisco Systems and VMware. Instead of requiring scripts, continuous integration pipelines created in Drone can be declared and managed as code in Git. That approach creates a standard syntax for pipelines that are easier to create, use, maintain and troubleshoot. The two companies claim that reduces the time and cost of continuous integration by a factor of five to 10 over rival platforms.

    Analyst firms are projecting the DevOps software market will generate $15 billion in revenue by 2023, signaling an opportunity to provide a more modern CI platform that is easier for organizations to employ, Bansal said. Jenkins, the most widely used CI/CD platform today, traces its lineage back to 2004.

    While the overall market continues to grow, however, there’s been a wave of consolidation among vendors attempting to construct end-to-end DevOps platforms. Many enterprise IT organizations tend to prefer to rely on as few vendors as possible to reduce integration costs, which is an issue Harness in part is trying to address by acquiring Drone.io.

    Harness is a member of both the Continuous Delivery Foundation (CDF) and the Cloud Native Computing Foundation (CNCF). Drone is already available on a wide variety of platforms, including Kubernetes, and it’s not clear if either arm of the Linux Foundation will play a major role in advancing the development of Drone. The CNCF has thus far accepted Argo, an open source CD platform for Kubernetes, as an incubation-level project.

    In the meantime, competition among providers of CI/CD platforms is intensifying. Jenkins, originally developed by CloudBees, is now being advanced under the auspices of the CDF along with Jenkins X, a CI/CD for Kubernetes environments, and Spinnaker, a CD platform originally developed by Netflix. GitLab, Microsoft and its GitHub subsidiary, JFrog and CircleCI all have established major rival CI/CD ecosystems of their own.

    Ultimately, it will be up to each IT organization to decide which CI/CD platform makes the most sense for them. It’s even possible many departments within the same organization will make use of multiple CI/CD platforms. Over time, however, most enterprise IT organizations are expected to adopt a CI/CD standard to better facilitate collaboration across multiple DevOps teams.

  • CD Foundation Touts Spinnaker CD Progress

    CD Foundation Touts Spinnaker CD Progress

    At an online Spinnaker Live event today, the Continuous Delivery (CD) Foundation revealed the open source CD platform is gaining significant momentum since being contributed by Netflix late last year.

    There were on average 842 merged pull Spinnaker requests a month in the first quarter of 2020. A total of 1,183 contributors participated in the project in the last year, with 40% of those contributors participating in the first quarter. Since the first quarter, the project has added at least two new contributors a week.

    Rosalind Benoit, chair of the CD Foundation Outreach Committee and director of community at Armory, a provider of an enterprise edition of Spinnaker, said the bulk of the increased contributions to Spinnaker are coming from Amazon Web Services (AWS), which the cloud service provider is already employing to orchestrate software delivery across multiple platforms.

    Benoit said Spinnaker represents an effort to finally address CD issues that have been difficult for most organizations to solve. While continuous integration (CI) is a solved problem, Benoit says CD remains problematic. Each platform code is deployed on within enterprise IT environments is a snowflake; as such, not much progress has been made toward automating the delivery of code across different platforms, said Benoit.

    The goal for Spinnaker is to create a foundation for CD that will achieve groundswell support that was achieved for Kubernetes by the Cloud Native Computing Foundation (CNCF), she noted. Both the CD Foundation and CNCF are arms of the Linux Foundation.

    Last year, the CD Foundation was launched to advance development and adoption of Spinnaker alongside Jenkins, an open source CI/CD platform; Jenkins X, an opinionated open source CI/CD platform for Kubernetes; and Tekton, an open source project and specification for creating CI/CD components.

    While many DevOps teams have attempted to address CD challenges using Jenkins, progress has been uneven at best. Spinnaker was built by Netflix specifically to automate software delivery across multiple clouds using a framework that can be integrated with any CI tool. As such, it serves to provide a clearer line between where CI ends and CD begins.

    Historically, most application code is pushed from a CI tool out to a deployment platform. As Spinnaker and other cloud-native platforms such as Kubernetes continue to evolve, the process of pulling images from CI tools to achieve CD goals will become much more automated.

    It’s not clear just how much depth of support for Spinnaker there is among providers of DevOps platforms. Members of the CD Foundation in addition to Armory include CloudBees, CircleCI, Google, Huawei, IBM, JFrog, Netflix, GitLab, Harness, Puppet, Rancher Labs, Red Hat, SAP and Sysdig. AWS has yet to formally join the CD Foundation. However, few of these vendors have detailed how they intend to incorporate Spinnaker in their respective platforms.

    In the meantime, DevOps teams should be paying close attention to how best CD practices will evolve alongside existing CI processes because it’s clear the next major phase of their continuing DevOps adventure is only now just beginning.

  • Report Finds Much Room for CD Improvement

    Report Finds Much Room for CD Improvement

    A report published by Harness, a provider of continuous delivery (CD) platform accessed via the cloud, finds organizations are spending on average $109,0000 per year just to deploy per application.

    Based on a survey of more than 100 organizations, the report finds organizations are struggling with deployment frequency, lead time and meantime to recover after a failed release.

    On average, organizations are deploying code to production every four days, which takes about eight hours to complete, according to the report. An average of 11% of those deployments fail and those failures take an average of 60 minutes to manually roll back.

    Steve Burton, CMO at Harness, said that while a lot of progress has been made in recent years in terms of implementing continuous integration (CI), the continuous delivery (CD) side of the DevOps equation remains challenging. Each platform an application gets deployed on is a unique “snowflake” that requires organizations to rely on custom scripts to deploy an application. The report finds deployment pipelines are expensive to create and maintain, requiring two to three dedicated full-time employees and up to 66 hours to onboard a new application. New artifacts on average took 5.5 hours to reach production and then 10 hours per deployment.

    Harness has been making a case for a dedicated CD platform that is accessed as a software-as-a-service (SaaS) platform. That approach provides a way to automate application delivery in a way that more easily complements the variety of tools and platforms organizations rely on to build applications, he said.

    The Harness report finds 71% of respondents employ the Jenkins CI/CD platform. Other popular tools and platforms include Jira project management software (76%), Selenium for testing (63%) and Amazon Web Services (AWS) for cloud deployment (65%). While Jenkins can be employed to deliver applications, Burton said the survey results make it clear there’s not been a lot of progress when it comes to CD.

    It’s too early to say to what degree changing economic conditions brought on by the COVID-19 pandemic might encourage IT organizations to rethink their approach to DevOps. Organizations are undoubtedly going to be more sensitive to cost. Much of the cost involved in DevOps comes from first standing up and maintaining the DevOps environment and then hiring IT professionals with DevOps skills to manage it. A SaaS platform, in contrast, is maintained by the provider, comes with built-in analytics tools, enables automatic rollbacks and is paid for on a consumption basis, notes Burton.

    No one knows for sure at what rate organizations might be rolling out new applications in the months ahead. While some may choose to pull back, others are advancing various digital business initiatives as part of an effort to become more resilient. In many cases, that means replacing many legacy applications with fewer modern applications that run natively in the cloud.
    Regardless of the path forward, the one thing that is certain is the level of scrutiny being applied to DevOps efficiency is about to substantially increase.

  • Wind River Launches CD Platform for Embedded Systems

    Wind River Launches CD Platform for Embedded Systems

    Wind River is fostering the adoption of DevOps processes for embedded systems by making available a continuous delivery (CD) platform that its customers can download.

    Glenn Seiler, vice president for open source strategy for Wind River, said the CD platform is based on an open source instance of the Jenkins continuous integration/continuous delivery (CI/CD) platform. The company envisions organizations downloading the platform as source code that Wind River will update regularly for use on top of the Wind River Linux platform, he said.

    Wind River is taking advantage of containers, Kubernetes, the Puppet IT automation framework and a repository to ease deployment of its CD platform, added Seiler. The company is committed to providing updates to that platform, which Wind River uses internally, at least every three weeks, said Seiler.

    Wind River expects most organizations will already have some form of a CI process in place. The CD platform provided by Wind River will focus on accelerating the delivery of applications built using whatever CI process organizations have in place today, said Seiler.

    In the embedded systems space, Seiler said the adoption of best DevOps practices is still in its very early days. However, with the rise of edge computing and the internet of things (IoT), organizations will need to find a way to securely deploy and update highly distributed application environments. To achieve that goal, many organizations will apply the same DevOps principles enterprise companies have been applying to their embedded systems, he said.

    To ensure the integrity of the software supply chain on which the Wind River CD platform is delivered, Wind River has also been certified under the ISO 9001:2015 specification for management processes, as well as the OpenChain specification for open source compliance.

    Wind River also has the Wind River Workbench for Linux LTS, based on the Eclipse integrated development environment (IDE), along with various system analysis tools including a trace visualization tool from Percepio AB to identify the root cause of anomalies.

    While it’s taken more than 10 years to drive the adoption of best DevOps practices in the enterprise, adoption in embedded systems environments should be faster now that the journey has begun. Organizations of all sizes are pushing more application workloads to the edge at faster rates. Traditional approaches to building and deploying applications on standalone embedded systems will not be able to keep pace. Organizations that build applications for embedded systems will be challenged by first acquiring the right tools and then adapting their internal culture to the complexities that arise when they need to build and deploy applications faster.

    Wind River is making the case for a curated open source CD platform that should enable organizations to spend less time on managing the underlying DevOps platform in favor of focusing more time and energy on changing their internal culture.

    — Mike Vizard