Tag: DevOps platform

  • Dagger: Standardizing CI/CD is the Holy Grail of DevOps

    Dagger: Standardizing CI/CD is the Holy Grail of DevOps

    Continuous integration and continuous delivery (CI/CD) has become a hallmark of quick software release life cycles. Nowadays, many teams support CI/CD pipelines for their software, offering a repeatable pathway to build, test and deploy code. A CI/CD pipeline is necessary to support an iterative, rapid deployment approach—yet, maintaining one is not an easy task.

    Enter Dagger. Dagger is a utility that aims to streamline how developers create and manage their CI/CD pipelines. Dagger, led by founders of Docker, recently unveiled their public beta launch along with a Series A $20 million funding raise led by Redpoint Ventures. While many open source CI/CD projects already exist on the market, Dagger is unique in offering easier configurations, pre-built components and more reusable actions.

    Akin to traditional supply chain management, software supply chain management is an increasingly complex endeavor involving many third-party dependencies. Development teams truly require a set of standard building blocks to piece it all together. For this reason, Solomon Hykes, co-founder and chief executive of Dagger, told SiliconANGLE that “solving this problem is the holy grail of DevOps.”

    Below, we’ll look at the common stressors inherent in creating and managing modern software delivery chains. We’ll also take a peek into the Dagger beta to see what it’s attempting to accomplish.

    Issues Facing CI/CD

    Software development supply chains are growing larger and larger to support a complex network of software architectures. But DevOps engineers, who must automate this chain, are drowning in tool sprawl—and stitching these components together to make custom pipelines can become a big bottleneck.

    Especially as an organization expands its distributed microservices architecture into the cloud, it can be tricky to scale a repeatable CI/CD pipeline across various department and disparate tech stacks. This often results in many bespoke CI/CD pipelines. Even within the same team, nuances between codebases can complicate each CI/CD process and require engineers to rewrite scripts.

    Simultaneously, organizations are under intense pressure to deliver to meet new digital innovation demands. But, until DevOps can make the release process more efficient, software development automation risks introducing more toil than it takes away.

    Diving Into Dagger

    So, how is Dagger alleviating these concerns? Well, Dagger creators described it as a “portable devkit for CI/CD pipelines.” Using Dagger, DevOps engineers can use a standard set of building blocks to assemble their CI/CD pipelines and then run them on their chosen cloud. It’s like a better developer experience for CI/CD pipeline creation.

    So, how does Dagger work under the hood? Dagger is powered by Buildkit, the Dockerfile-agnostic builder toolkit. Developers then use Cue to specify how their code is run in a container and to link up actions. Cue is an open source configuration language developed at Google.

    According to the docs, it takes about five minutes to install Dagger and the necessary dependencies. Dagger also provides boilerplate code to integrate with pre-existing CI environments. In essence, Dagger doesn’t need to replace your CI tool—it adds “a portable development layer on top of it.”

    Then, there are the actions themselves. Dagger supports a growing library of actions that it calls Universe. At the time of writing, the Universe of actions is limited and is being staged in the main Dagger repository. These actions are reusable Cue packages. For example, this package details how to run and deploy the Nginx web server in Cue:

    package nginx
    
    import (
        "universe.dagger.io/docker"
    )
    

    And then,

    #Build: {
        output: docker.#Image & _pull.image
    
        _pull: docker.#Pull
        *{
            flavor: "alpine"
            _pull: source: "index.docker.io/nginx:stable-alpine"
        } | {
            flavor: "debian"
            _pull: source: "index.docker.io/nginx:stable"
        }
    }
    

    Benefits

    CI/CD can certainly benefit from standard building blocks and more fluid wiring between tools. There are several potential benefits from Dagger’s proposition:

    • Unification: Unifying developer and CI environments could avoid headaches.
    • Localization: Dagger enables testing a closed-loop pipeline locally. This helps for debugging.
    • Reusability: Building blocks help avoid rewriting automation scripts repeatedly.
    • Multi-cloud: Easier ability to migrate a pipeline from one cloud to the other, thus avoiding vendor lock-in.
    • Compatability: Dagger can run in any environment compatible with Docker, meaning it’s probably workable with your current toolset.

    Final Thoughts: Lego Blocks For CI/CD

    Docker revolutionized the software industry by easing the process of managing containerized applications. And now, Docker founders Solomon Hykes, Sam Alba, Andrea Luzzardi and others at Dagger are tackling another meaningful problem within today’s complex software ecosystem. Given the success of their previous endeavors, it’s not too difficult to imagine a network of reusable CI configurations emerging with an excitement similar to Docker Hub.

    Of course, Dagger is still in its early stages and there’s much development ahead. It will undoubtedly be an interesting project to follow in the years to come. Dagger is being built as an open source project on GitHub. The company has also opened a Discord channel to engage with the community.

  • Unified Enterprise DevOps Platforms Eliminate Bottlenecks

    Unified Enterprise DevOps Platforms Eliminate Bottlenecks

    Nearly all enterprise digital transformation projects include moving software to DevOps processes and platforms. The effort, cost and time it takes to be successful with these transformations depend on a lot of factors, but one thing stands out: as indicated in my white paper Unified Enterprise DevOps Platform Why? How? And What?, “An enterprise with many variations of DevOps platforms and tools is at best chaotic, and at worst, is a gross impediment to overall organization agility – undermining the very purpose that DevOps is meant to serve.”

    In my recent blog Why a Unified Enterprise DevOps Platform is Necessary, I indicated that “The aggregate set of platforms and tools is like a Frankenstein’s monster, with many incompatible parts resulting in an awkward looking product that is hard to control, replicate and evolve.”

    Success with DevOps requires frictionless interplay between the people, processes and technologies that need to cooperate for continuous deliveries to happen effectively. The existence of different DevOps solutions creates organizational barriers to unification, because different groups become dependent on their local variations.

    A Unified Enterprise DevOps Platform Accelerates Time-to-Value

    Culture barriers, process problems and DevOps platform “wars” all are factors impacting the progress of digital transformations. A unified enterprise DevOps platform would accelerate time-to-value, and realize efficient, safe operation for digitally transforming enterprises and organizations.

    The following are general requirements for a unified enterprise DevOps platform.

    ● A new, unified approach that supports end-to-end capabilities for continuous delivery of software, as a managed service, for multiple streams of pipelines.
    ● Unified metrics that show business value, costs of the value stream and timing for end-to-end continuous delivery flow across multiple pipelines.
    ● Unified capabilities including visibility, orchestration, integration, security, governance, traceability and management of flow for application value streams across multiple pipelines.
    ● Capabilities to unify continuous testing/QA, troubleshooting and debugging.
    ● A new, unified approach to simplify and accelerate toolchains that support new cloud-native and cloud-adapted applications, infrastructures, machine learning, commercial off-the-shelf and open source software.

    A DevOps Platform Blueprint

    In my SlideShare DevOps-as-a-Service Values, I described a four-layer blueprint for a unified enterprise DevOps platform that satisfies these general requirements. The main elements in the blueprint are:

    ● Stakeholders – There are three types of stakeholders: business, appdev users and DevOps admin teams.
    ● Service access layer – Consists of portals and APIs for business, appdev and DevOps administration users and access security.
    ● Service layer – consists of user services and DevOps admin services.

      • User Services include things that appdev users need to perform their application development and testing work. This includes capabilities for no-code automation and orchestration, repos for code, artifacts and data, multi-CI/CD pipelines and sandboxes, test data, configuration, continuous testing/QA, service level objectives (SLOs) for business and appdev users and troubleshooting and debugging.
      • DevOps admin services include things that a DevOps team needs to administer and manage the platform. This includes capabilities for platform administration, the ability to import pipelines into the unified platform, integration with enterprise service catalogs, integration with enterprise issues and change request systems, SLOs for DevOps administrators and capabilities to implement governance policies-as-code.

    ● Resources layer – includes resources that the services need to run including application stacks, infrastructure resources, tools, infrastructure code and topology data.

    One of the most important benefits of a unified platform is the ability to unify SLOs for each class of stakeholders. The SLOs need to be chosen to best fit the requirements of each application.

    Business value can be demonstrated by the following SLOs:

    ● Productivity metrics.
    ● ROI data tracking.
    ● Agility of services – Lead time for changes and frequency of releases.
    ● Reliability of services – Change failure rate; time to restore services.
    ● Governance compliance and security.

    Appdev user value can be demonstrated by the following SLOs:

    ● Platform availability.
    ● Service response time.
    ● User experience scores.
    ● Change request response time.

    DaaS team value can be demonstrated by the following SLOs:

    ● Scope of applications – number of apps supported, number of users per month.
    ● Number of requests served per month.

    Without a unified enterprise DevOps platform, all these SLOs would have to be implemented multiple times, once for each type of DevOps platform.

    To realize DevOps-as-a-Service for enterprises with multiple related pipelines, each pipeline needs to be configured to work within a unified model where common tools process each application and microservice continuous delivery task in parallel. Unified control and monitor points are needed – and should be exposed by the unified platform – to realize SLOs in a unified way. Without a unified platform, all of these SLOs will need to be implemented separately, for each platform, and then another system will be needed to aggregate them into a common view.

    The SLOs will indicate where the biggest bottlenecks are for a particular pipeline. In many enterprise pipelines, the biggest bottleneck is testing, troubleshooting test failures and debugging to resolve the failures. It is a myth that continuous testing is just the execution of automated tests. The whole range of “testing things” includes test planning, test resource scheduling, test design, test implementation, test environment management, test execution, test results reporting, test result analysis, troubleshooting, debugging, fix retest and test management, and all can be sources of bottlenecks. These “testing things” are all sources of bottlenecks for every stage of a DevOps pipeline, for all Three Ways of DevOps. Without a Unified enterprise DevOps platform, all these testing things must be addressed separately, in accordance with the different pipeline platforms.

    Testing, troubleshooting and debugging tasks are a major source of bottlenecks for most DevOps value streams. A unified platform improves continuous testing/QA, troubleshooting and debugging as follows:

    ● Continuous testing/QA – Orchestration of test environments, execution of tests and reporting test verdicts is unified.
    ● Troubleshooting – Failures are displayed in a consistent format, including trends correlated to pipeline and application log data, to simplify analysis of test failures.
    ● Debugging – Causes of failure can be isolated with intelligent analysis of troubleshooting results, and the platform can quickly install the fixes and orchestrate the test environment to verify the fix is working.

    These testing, troubleshooting and debugging advantages have a major impact on the ability to accelerate digital transformations.

    What This Means

    Digital transformation of many enterprises and organizations are being seriously impeded by having too many DevOps platforms and tools. A unified enterprise DevOps platform resolves the technical problems of broken, leaky, “Frankenstein” toolchains and processes. Enlightened leaders that understand the importance and the broad impacts of unified enterprise DevOps platform are wise to recognize the sense of urgency surrounding a migration to a unified platform, and take action to stop the proliferation of too many platforms.

    To realize a unified enterprise DevOps platform in an enterprise takes more than simply buying and installing a new platform and telling everyone to start using it in place of what they are used to. With multiple entrenched DevOps platforms in place, there are practical and political considerations that must be overcome. Introducing any changes across a large group of applications in an enterprise can be chaotic, and will often be more costly and take too much time if the changes are not well-coordinated in accordance with a carefully crafted strategy and implementation roadmap that leaders and team members are aligned with.

  • Armory Offers Framework to Extend Spinnaker

    Armory Offers Framework to Extend Spinnaker

    Armory, provider of a curated instance of open source Spinnaker continuous delivery (CD) software, is making generally available an open source plugin framework for any instance of Spinnaker.

    Announced this week at its online OPEN CORE SUMMIT, the framework has already been employed to create 15 plugins for Spinnaker, including an observability tool from Armory and a provisioning tool from Pulumi. The plugin framework creates extension points that provide standardized interfaces for creating plugins that invoke various microservice within the Spinnaker CD platform.

    Armory CTO Isaac Mosquera said the goal is to make a Spinnaker platform now being developed under the auspices of the Continuous Delivery (CD) Foundation more easily extensible. The relationship between the frameworks and Spinnaker is naturally symbiotic; more extensions are needed to increase the appeal of the platform. Organizations are unlikely to build those extensions unless Spinnaker achieves a critical mass of adoption.

    Originally developed by Netflix, Spinnaker is being advanced by CD Foundation, along with the Jenkins and Jenkins X continuous integration/continuous delivery (CI/CD) platforms. Organizations will employ different platforms under different circumstances, but the Spinnaker platform does enjoy the capability of being integrated with multiple CI platforms that DevOps teams already have in place, noted Mosquera.

    That ability to mix and match DevOps platforms is becoming more critical as IT environments become more hybrid, he said. The expectation is support for Tekton pipelines, which were originally developed by Google and now are part of the CD Foundation portfolio, will be added to various CI/CD platforms to make it easier to integrate DevOps pipelines.

    In the meantime, a debate surrounding how to implement best GitOps practices is starting to swirl. Thanks to the rise of Kubernetes, it is becoming easier to employ GitOps processes to automate the pulling of code from a Git repository onto any platform. In some cases, that approach might reduce or eliminate the need to rely on a dedicated CI/CD platform to manage that process. Conversely, Mosquera noted CD platforms such as Spinnaker also provide a range of capabilities that span everything from automating audit process to rolling back application code in event of a major deployment issue.

    In the meantime, the amount of code moving through DevOps pipelines continues to increase. Simultaneously, the code is arriving in form of microservices that, although are comparatively easier to build, are often more challenging to deploy, update and manage.

    It’s not clear how many organizations might be looking to replace existing DevOps platforms to manage those processes more effectively. However, more organizations are embracing DevOps processes more widely to deal with an ever-increasing volume of code. As such, the number of organizations adopting open source DevOps platforms in one form or another will continue to rise. Most of those organizations, however, are unlikely to want to download on their own the raw bits that make up those projects.

  • Copado Adds Value Stream Management to Salesforce DevOps Platform

    Copado Adds Value Stream Management to Salesforce DevOps Platform

    Copado, a provider of a DevOps platform for building applications that extend software-as-a-service (SaaS) applications from Salesforce, this week announced it has added value stream management capabilities.

    Andrew Leigh, chief marketing officer for Copado, said providing a platform that accelerates the development and deployment of application code is no longer sufficient. The winter 2021 release of the Copado DevOps 360 platform now includes value stream management capabilities that enable organizations to better prioritize DevOps projects, he said.

    In response to the COVID-19 pandemic more organizations than ever are now relying more on SaaS applications that can be accessed easily by employees working from home. IT organizations are also now using platforms such as Salesforce to jumpstart digital business transformation initiatives. Rather than write develop entire applications from the ground up, many organizations are employing low-code tools from Salesforce and others to extend, for example, customer relationship management (CRM) platforms.

    Leigh said most of the activity revolves around professional developers who are increasingly applying best DevOps practices to build those applications. Copado has certified more than 25,000 developers on its platform, he said.

    Given the current state of the economy, Leigh said interest in DevOps platforms is rising among organizations building Salesforce applications because they want to ensure a return on investment (ROI). Organizations that are investing six figures to build these applications are especially interested in value stream management tools that help make sure these projects are delivered on time.

    The value stream management capabilities added by Copado include support for the Scaled Agile Framework (SAFe) for building complex applications more efficiently. It also provides the ability to synchronize stories from Jira and Agile Planning boards.

    The latest version of the Copado DevOps 360 platform also adds a suite of declarative pipeline builders that allow non-technical teams to define and manage value pipelines without a single line of code. That capability is intended to simplify version control and automation flows to enable developers and administrators who manage Salesforce instances to better align their efforts.

    Copado added deeper integrations to third-party testing tools that incorporate artificial intelligence (AI) and updated its static code analysis and compliance tools.

    Salesforce is clearly not the only SaaS application platform that organizations are looking to extend, but it is among the fastest-growing. For its most recent third quarter, the company posted revenues of $5.42 billion, an increase of 20% year over year. The company is now lifting its future guidance to slightly exceed pre-pandemic levels. Salesforce is projecting fiscal 2021 revenue at the end of its fourth quarter will total $21.11 billion. Revenue guidance for fiscal 2022 has been raised to $25.5 billion. Salesforce earlier this week also announced its intention to acquire Slack, a provider of a messaging platform that is used widely by DevOps teams.

    Leigh said a dedicated DevOps platform for Salesforce applications is necessary because Salesforce applications are constructed using a set of objects and tables unique to the platform versus traditional application code. Regardless of the reason for requiring a dedicated DevOps platform, interest in building and deploying custom applications on top of the Salesforce platform has increased sharply since the start of the pandemic.

  • JFrog Sets Future Course Post-IPO

    JFrog Sets Future Course Post-IPO

    Another milestone in the march toward mainstream adoption of best DevOps practices was reached this week, with JFrog becoming a public company.

    JFrog CTO Yoav Landman said the funding that the provider of a continuous integration/continuous development (CI/CD) platform is receiving from investors is a clear vote of confidence in DevOps. The next major DevOps challenge will be finding ways to further automate the distribution of software across what is rapidly becoming a much more extended enterprise now that IT organizations are embracing various types of edge computing platforms, he said.

    JFrog CTO Yoav Landman

    The injection of funding will be used in part to enable JFrog to address that challenge through a combination of internal product development and inorganic acquisitions, said Landman. The last few years have witnessed a wave of consolidation as providers of DevOps platforms expand their reach into adjacent categories.

    At the same time, Landman said IT teams should expect to see JFrog investing more in various forms of artificial intelligence (AI) to further accelerate software development and deployment.

    JFrog, as a leading proponent of DevOps, has been making a case for focusing specifically on application binaries rather than just source code. The building and deployment of application binaries is at the root of any digital business transformation initiative, noted Landman. As such, any organization that now views itself as some type of software company needs to master DevOps processes to succeed.

    That requirement is also accelerating the rate at which CI and CD processes need to converge, he added. Most organizations that have embraced DevOps tend to master CI. CD has proven more challenging because each platform on which software is deployed is unique. JFrog addressed the challenges associated with CD first via its JFrog Artifactory platform before adding on the CI tools required to automate DevOps processes on an end-to-end basis.

    In general, Landman noted there is now more focus on software supply chains as more organizations come to appreciate how dependent they are on applications to differentiate themselves from competitors. That issue is one of the main reasons the senior leadership of more companies are becoming more aware of the processes required to build and deploy quality applications consistently across an expanding number of platforms. In fact, it’s conceivable there might one day be more software running on edge computing platforms than in either local data centers or public clouds.

    JFrog reportedly has more than 5,800 customers currently. It’s not clear to what degree organizations that have already embraced DevOps might be willing to replace their CI/CD platform or, in some cases, consolidate the multiple CI/CD platforms they already employ. However, as the number of organizations that are embracing best DevOps practices continues to grow there appears to be plenty of opportunity for providers of CI/CD platforms to grow as well.

  • Solving the DevOps Dilemma in the COVID Era 

    Solving the DevOps Dilemma in the COVID Era 

    The coronavirus pandemic is forcing businesses to double down on DevOps transformation initiatives across the enterprise, pushing companies to be more agile and implement software changes throughout their organization at a much faster rate. However, too many IT departments rely on older, complex processes to approve software changes coming from DevOps teams and simply cannot keep pace with this accelerated rate. This is because many parts of the delivery process remain heavily manual, time-consuming and siloed. In other words, rather than realizing enterprise-wide transformations, the value from DevOps initiatives is remaining localized and doesn’t come close to delivering on the promise DevOps held in the first place.

    But because of the profound and sudden changes to the way we work, the industry is reaching an inflection point. Increased demand and competitiveness for modern digital experiences and ways of working are forcing businesses (even those within highly regulated industries) to rethink how they build software and get it approved faster. The need is clear among developers to reduce time-to-approval for new features, yet organizations must remain steadfast in protecting the business against rushed features that may not contain the proper safeguards and could negatively impact business operations.

    To help strike a balance during this critical time, a new trend to expedite software development and deployment is emerging: a platform-based approach to DevOps.

    Driving Visibility With Platforms

    The potential for platforms to streamline aspects of DevOps is profound. Platforms are able to model data and workflows to connect developers and IT continuously all along the development and delivery process. For example, the platform can leverage information from the flow to automate the manual and time-consuming change approval process, enabling them to release features rapidly and safely.

    But the benefits of platforms transcend beyond workflows. The vast number of tools used by developers and IT makes it difficult for leaders to get a holistic view of how each team is performing. This lack of visibility slows the behavioral and cultural change needed to succeed with DevOps. However, with the system of record and engagement that the right platforms provide, stakeholders on both sides of a project can easily view and audit the release process, which means shorter development cycles, increased deployment frequency and more dependable, high-quality releases.

    Companies, and even teams within the same company, are at many different stages of DevOps maturity. Some are fully adopting distributed teams based around products and simple development pipelines that make rapid, incremental changes, potentially multiple times per day. However, most organizations still have more complex releases that are still on a longer cadence such as weekly or monthly. Those releases may involve multiple teams and a wide range of development tools so again, the platform approach provides visibility and the ability to automate across the entire release.

     DevOps at Scale

    While many businesses are leveraging DevOps in various capacities, they have yet to be able to scale adoption across their entire organizations. This is the Achilles Heel for DevOps as a whole—after all, the goal with any transformative initiative is to scale, and traditionally DevOps has been difficult to scale past initial early successes.

    The challenge in scaling DevOps is that while there are many tools at developers’ fingertips, the actual processes around audit, compliance, security and change management are still often performed manually, and many of the tools are disconnected, meaning fragmented data and, yet again, limited visibility across numerous teams within an organization. At a time when controls should be becoming more decentralized, with more operational parameters ‘moving left’ to the control of development teams, we are instead seeing delays during deployment, difficulty driving best practices and DevOps adoption across the enterprise, and a lack of trust across teams.

    However, with a platform approach, the ability to scale is built into the technology since software approvals can be automated, enabling IT teams to allow more decision-making in development with appropriate guardrails. The IT teams can ensure the release of features rapidly and safely—and more importantly—focus on strategic, business-critical work.

    Resolving Data Configuration Challenges With Platforms

    In addition to unlocking visibility and scale with DevOps platforms, there’s a growing practice of leveraging platforms to improve configuration data. As companies shift to working in the COVID-19 era, they’re using more applications that require frequent updates. To ensure the applications don’t break in production, developers are automating application testing and deployment with platforms, allowing this process to occur earlier in the software delivery life cycle.

    However, ensuring configuration data accuracy during this process can be challenging. By using a platform for developers to add and consolidate configuration data, users can better control the application environment, prevent issues in production and quickly correct post-deployment problems. All this is possible by integrating machine learning into the platforms to prevent incorrect configuration data settings from reaching production environments. The machine learning identifies potential misconfigurations earlier, before apps are moved into production, ultimately helping users avoid app and infrastructure deployment inconsistencies.

    With platforms, developers can both improve the quality of configuration data and identify incorrect configurations using machine learning ultimately to prevent software changes from causing outages and incidents during a highly critical time.

    The Bottom Line

    The coronavirus pandemic has magnified the importance of agility and quickly adapting technology to meet changing customer and employee needs. As a result, enterprises are trying to figure out how to navigate and embrace new technologies that help ensure business resiliency. When done right, DevOps should help accelerate and scale this innovation, while still maintaining compliance and security. Adopting a platform-based approach to DevOps helps organizations reduce time-to-approval of new features so they can effectively drive digital transformation across the business—the North Star of all IT initiatives in this new work environment.

  • Five Attributes of a Great DevOps Platform

    Five Attributes of a Great DevOps Platform

    As we move toward 2020, the expectations are high, the software industry is moving faster and the demand for rapid and continually improving digital experiences have raised the standard. To match the needs and demands of the market, firms around the world are embracing the DevOps culture to ensure and streamline the development, packaging, testing, deployment and maintenance of software at scale. 

    Every DevOps organization is defined by its own leadership, culture, practices, policies, leadership style, structure, talents, skills, technical capabilities, processes and tools. However, there are certain common characteristics that are important to consider before deciding a better DevOps platform to use in your organization. Today, we will discuss such important features that can help you while selecting your DevOps platform. 

    What is DevOps?

    DevOps is a mindset in an organization that enforces a set of collective practices to ensure easy collaboration between dev and ops so the business can run smoothly without any hassle. DevOps aims to fasten the time to market through frequent and incremental improvements to deliver quality software updates to customers. 

    The meaning and definitions of DevOps can vary from company to company. Automation being the focal point, firms want to focus on achieving zero-touch automation, with utmost security and governance as a priority in the delivery pipeline.

    Even though the meaning of DevOps varies, several inherent DevOps principles cannot be replaced, and they repeatedly insist on collaborative relationships, developing early, failing early, shared learning and continuous feedback. These DevOps principles enhance quality with improved deployment rates while simultaneously improving predictability, scalability and security of the production environment. Tech leaders in the company need to view DevOps as a holistic approach rather than a small set of guidelines for the teams, and DevOps guidelines should be aligned with the company’s long term technology vision and objectives. 

    Here are some facts to consider while deciding a better DevOps platform for your organization.

    A Mindset of a Unified Culture

    Culture plays a significant role in establishing the guidelines while embracing DevOps in any organization. Through DevOps culture, companies seek to bring dev and ops teams into harmony to promote collaboration, automation, process improvements, continuous iterative development and deployment methodologies. But above everything else, a sound DevOps culture fundamentally solves one of IT’s biggest people problems: bridging the gap between dev and ops teams to get them to stop working in silos and have common goals. 

    According to Gartner estimation, DevOps efforts fail 90% of the time when infrastructure and operations teams try to drive a DevOps initiative without nurturing a cultural shift in the first place. It is not just about the efficient tools or experts working; it is about the behavioral modifications and mentality necessary to effect cultural change.

    Hence, it is important for the firms to consider the culture of the company before selecting its tool as a potential DevOps tool for their development. 

    Automation Inside and Outside

    Automation is one of the key principles of a strong DevOps team because it has such a high return on investment. 

    Automation makes up as a large part of DevOps culture to standardize production platforms, and even firms believe it as true because standardization and automation help make deployments more predictable, easy and less prone to human errors. 

    Automate everything as part of the workflow process, including infrastructures, compliance and continuous delivery pipeline. For example, tools such as Artifactory can manage and control all your binary repositories to help your developers and ops collaborate and automate build and deploy tasks easily. Similarly, Docker allows development teams to containerize applications and automate application deployments with speed.

    By reducing manual, non-important and repetitive tasks, you will increase your development and testing speed while cutting down on human and unnecessary errors. Additionally, by automating tedious and repetitive tasks, firms free up team members to work on higher-level and more important tasks.

    Important to note here, JFrog Pipelines is an innovative DevOps automation solution that well integrates and connects all critical processes in the software delivery lifecycle in the company, from development to testing to production. Using minimum code, it allows you to create smart and event-driven workflows across tools and teams easily, to speed up the release of software applications. This helps you achieve continuous integration, continuous delivery, continuous deployment and continuous monitoring in DevOps.

    Support Both Hybrid and Multi-Cloud

    What is Multi-cloud?

    Multi-cloud is the use of cloud computing from two or more public cloud providers in single network architecture to meet their business objectives. A multi-cloud strategy has many advantages. It avoids vendor lock-in, decreases latency, enhances business continuity, overhead cost reduction and maximizes flexibility for development teams. However, multi-cloud management comes with some challenges that require careful orchestration, and needs to pay close attention to security and governance issues.

    What is Hybrid-cloud?

    A hybrid cloud is a mixture of on-premises and off-premises IT resources. Based on business and compliance requirements, the hybrid cloud allows firms to move data and applications between private and public environments. 

    Hybrid cloud computing allows instant transfer of information between public and private environments, allowing enterprises to experience the benefits of both environments efficiently. 

    Flexibility, scalability and cost savings are some of the top benefits of hybrid-cloud. 

    Considering a platform that supports both multi-cloud and hybrid-cloud is the best solution for the enterprises moving toward the digital transformation ladder.

    Continuous Updates 

    Frequently rolling out updates, in a continuous sequence, to bring service improvements to consumer devices more rapidly and efficiently is what every firm is trying to do these days. The customer wants new features as early as possible and continuously. That is one reason why companies embrace automation and follow practices like continuous integration, continuous deployment and continuous delivery through tools such as GitHub, Artifactory, Circle CI, Docker, Kubernetes, etc. 

    The DevOps platform should be able to manage your DevOps pipeline from a single pane of glass. A platform that can provide a universal end-to-end solution that integrates with your ecosystem to orchestrate and optimize all critical processes in your CI/CD pipeline. Boosting fearless updates continuously from code to the edge in self-managed, on-prem, hybrid and multi-cloud environments.

    A Robust Community 

    All successful companies have built their own communities through their products and services. DevOps is all about the culture shift. Changing existing culture and moving forward is one of the hardest things to do—despite the benefits that DevOps offers, such as speed and agility. No matter what changes a team implements, embracing DevOps often comes to a halt once the companies realize it requires a change in culture and mentality of all the teams involved. This is where the value of community comes in, by fostering the development of a more open communication, easy and supportive feedback, and collaborative culture within teams, companies can be able to drive this DevOps culture. This mindset should come from within and outside of the organization by tapping into this sense of community-based collaboration. Communities are required because they ensure the well being of many of the technologies we use daily.

    Your favorite DevOps platforms—Jenkins, Docker, Kubernetes, Artifactory—and their popularity is because of the communities they have created around the tools. 

    A well-focused DevOps platform gives power to people who listen carefully to what the market is saying, gets the feedback and utilizes it effectively. Hence, community is a very important feature of a DevOps organization. 

    Conclusion

    Companies around the world are embracing DevOps, and the demand for DevOps skills soars as organizations spend their time and money on digital transformation. DevOps has become a modern approach to IT that helps companies to think and execute broader business strategies. DevOps can drive significant brand value by accelerating speed to market, better collaboration, ensuring better testing and automation. A DevOps platform should have all the qualities mentioned above to succeed in this highly competitive market.

  • JFrog Delivers on Hybrid Cloud Promise for DevOps

    JFrog Delivers on Hybrid Cloud Promise for DevOps

    JFrog announced the availability of what it claims to be the first available hybrid DevOps platform capable of spanning multiple clouds.

    Dror Bereznitsky, chief product officer for JFrog, said the JFrog Platform integrates a range of DevOps tools within the context of the continuous integration/continuous deployment (CI/CD) platform that the company previously developed, with the goal of making it possible to continuously release software originating from any source on to any platform.

    Announced late last year, the JFrog Platform also provides DevOps teams with the first universal package manager with JFrog Artifactory along with support for both REST application programming interfaces (APIs) and a command line interface (CLI), he said.

    In addition, the JFrog Platform provides a common integrated user interface to access all capabilities and has been integrated with JFrog Pipelines for CI/CD, which is based on code JFrog gained via its acquisition of Shippable last year. The JFrog platform also enables DevOps teams to now also deploy applications on Kubernetes clusters.

    Finally, because the platform is managed by JFrog, DevOps teams can count on high availability and cybersecurity updates that are automatically delivered, said Bereznitsky.

    Bereznitsky said thanks to the rise of microservices based on containers and other cloud-native technologies, organizations are reaching a tipping point in terms of the amount of complexity their existing DevOps platforms can absorb. As such, many organizations that have already adopted a DevOps platform will be re-evaluating them. JFrog is betting that rather than spending more time on managing their underlying DevOps platform, more organizations will prefer to divert more resources to application development.

    It’s too early to say precisely how application development will evolve going forward. There is certainly an opportunity to centralize DevOps processes in a way that will make organizations more efficient. Most organizations today employ multiple platforms for building and deploying applications that often conspire to increase total costs unnecessarily. The challenge those organizations will face is overcoming the cultural issues it is likely to create within their organization.

    In the meantime, JFrog rivals clearly see the same opportunity. The race to become a de facto standard for building and deploying a new generation of highly portable applications is now on, at a time when many of the providers of DevOps tools are starting to consolidate. At the same time, the number of applications that will be deployed across an extended enterprise that now spans everything from public clouds to edge computing platforms soon will dramatically increase. As the volume of applications increases, the level of friction associated with building and deploying applications will ultimately determine the DevOps platform any organization is going to be inclined to standardize on.

    — Mike Vizard

  • Cybersecurity Fears May Drive Shift to Managed DevOps

    Cybersecurity Fears May Drive Shift to Managed DevOps

    Should organizations consider using a managed service for DevOps to keep their platforms up to date and secure?

    The recent disclosure of a vulnerability that would allow open source Jenkins continuous integration/continuous delivery (CI/CD) platforms to be employed to launch a distributed denial of service (DDoS) attack highlights how challenging it is to secure the platforms on which many organizations now depend to build their most critical applications.

    The CVE-2020-2100 bug theoretically would have allowed cybercriminals to employ the Jenkins UDP discovery protocol to bounce traffic between servers until they could no longer respond. That same flaw also could be employed to launch DDoS amplification attacks against platforms connected to the internet. Those attacks can’t be stopped unless one of the servers is rebooted or its Jenkins service is restarted. The specific vulnerability discovered was fixed last month in Jenkins v2.219. IT organizations can either upgrade their Jenkins servers, disable the UDP discovery protocol or block the UDP port 33848.

    Tracy Miranda, director of open source community for CloudBees and member of the governing board for the Continuous Delivery Foundation (CDF), which oversees the development of Jenkins, said the bug itself is at best of medium severity. However, now that it’s been disclosed, the race is on to patch Jenkins servers or block UDP port 33848 before cybercriminals exploit the vulnerability on any public-facing instance of a Jenkins server.

    Given the fact that most IT organizations may not have resources at hand to patch their Jenkins servers quickly, Miranda said these and other potential future cybersecurity issues are a testament to why more organizations should rely on instances of Jenkins that are managed by third-party providers on their behalf. Organizations are spinning up more Jenkins servers than ever as they move to accelerate application development, and by relying on a managed service provider (MSP) to manage Jenkins, IT teams can focus more of their efforts on building and deploying applications rather than on managing CI/CD platforms.

    These days, more organizations are looking at DevSecOps as a best practice. Much of that focus, however, is on securing the applications that DevOps teams create; not nearly as much attention is being paid to securing the underlying platforms on which those applications are being built and deployed.

    It’s too early to say to what degree cybersecurity concerns might push IT organizations toward managed DevOps platforms. However, the more that cybersecurity teams participate in the DevOps process, the more they will ask questions about the fundamental security of the underlying platform.

    Of course, many IT teams often view managed services provided by third-party vendors as a threat to their existence. Nevertheless, DevOps platforms are among the most complex and expensive platforms to manage. In fact, that complexity is one of the main reasons so many organizations have hired site reliability engineers rather than relied on traditional IT administrators to manage DevOps platforms such as Jenkins. The issue that often comes up is just how many SREs an organization needs to hire before the cost of a managed DevOps platform becomes economically more appealing.

    — Mike Vizard

  • CircleCI Achieves SOC 2 Compliance for DevOps Platform

    CircleCI Achieves SOC 2 Compliance for DevOps Platform

    CircleCI has achieved a SOC 2 compliance rating for the DevOps platform it makes available via a software-as-a-service (SaaS) model.

    Tad Whitaker, security manager at CircleCI, said CircleCI is the first provider of a SaaS platform for DevOps that has invested the hundreds of thousands of dollars required to achieve SOC 2 compliance.

    SOC 2 compliance requires organizations to pass an annual audit based on the Trust Services principles and criteria defined by the American Institute of Certified Public Accountants (AICPA). That criteria evaluate IT environments on everything from the cybersecurity controls they have in place to the integrity of the data management processes employed. A SOC 2-level certification means DevOps teams can have confidence in the fact that their data is being kept completely confidential, said Whitaker.

    With interest in best DevSecOps processes on the rise, Whitaker noted more organizations are starting to ask questions about how data is managed and secured on the cloud services they rely on to build and deploy applications. Cybersecurity professionals who are now participating in those processes are starting to ask challenging questions. To address those concerns, Whitaker said CircleCI created a team within the company to first attain SOC 2 compliance and, now, maintain it.

    That may lead to additional processes and controls being put in place, but DevOps teams can be confident that everything possible is being done to secure their data from prying eyes, including employees of CircleCI.

    A lot of the data being employed to build new applications is among the most sensitive an organization is likely to possess. As organizations embrace DevOps practices to drive digital business transformation initiatives, there’s a much greater need to ensure the DevOps environment is secure end to end. However, most of the DevOps platforms delivered as a service today are not able to validate the level of security they claim to have put in place, said Whitaker.

    It’s unclear how many organizations are going to insist of SOC 2-level certifications before agreeing to develop applications on a specific DevOps platform. However, SOC 2-level certifications are routinely required for cloud service providers so it’s only a matter of time before the same audit requirements are applied to other cloud services. The challenge will come when DevOps teams have to adjust their existing DevOps processes to accommodate the security processes that SOC 2-compliant cloud service providers are required to make.

    In the meantime, the days when DevOps teams could employ cloud services to bypass cybersecurity policies are coming to an end. Cybersecurity teams are finally catching up in terms of figuring out how to enforce cybersecurity policies beyond an on-premises IT environment. Not every DevOps team may appreciate the impact those policies may have on productivity. However, if the alternative is to have sensitive data that DevOps teams are now being held accountable for exposed on the web because of careless processes than the time to come to terms with cybersecurity has finally come.

    — Mike Vizard