Tag: development platform

  • Rethinking Your Approach to Ops Governance

    Rethinking Your Approach to Ops Governance

    The “You build it, you run it” approach has changed the mindset of modern organizations that are increasingly adopting DevOps practices. No longer completely beholden to the requirements of operations, engineering teams are continually acquiring more autonomy to deliver rapid innovation. At the same time, more organizations are adopting platform teams to accelerate development, empowering teams with easier access to services without requiring them to understand the underlying complexity. While this approach is helping teams build, scale and ship software faster, it’s also resurfacing previous areas of tension around operational governance. 

    Organizations are generally choosing between two governance approaches: Mandated or paved path. Each has a different perspective on the appropriate level of autonomy to grant development teams and where governance should sit within the development life cycle. But there’s a third approach—the “trust and verify” approach—that can provide both high levels of autonomy for development teams and the sophisticated governance that operations teams need to ensure compliance and security.

    What is a Platform Team and Why are Organizations Adopting the Model?

    A platform team provides a foundation of self-service APIs, tools, services, workflows and support that accelerates the delivery of digital services and products. Platform teams operate similarly to any R&D team; employing customer support, operations, development, SRE, product managers and other personnel. They use research, customer feedback and usage data to iteratively improve their services.

    Rather than each development team reinventing the wheel, the platform team builds shared services that shield developers from the underlying complexity of infrastructure and enable self-serve access to services. As engineering resources become even more in-demand and scarce, organizations are using platform teams to optimize resources and share outputs.

    Two Platform Governance Approaches: Mandated Vs. Paved Path

    Organizations today typically are using one of two approaches to platform governance: Mandated or paved path.

    A mandated approach solves the governance problem by mandating that all engineering teams use the platform. However, this approach puts the onus on the platform team to keep up with the changing demands of engineering. Organizations must invest in a platform team that can keep up with engineering requirements so they still feel like they can innovate and use the best tools.

    The second approach is a paved path, popularized by Jeff Lawson of Twilio. This allows for engineers to go outside the platform if they are willing to take on the SLAs the platform provides and are responsible for all the costs of maintaining their own alternatives. Lawson said in this McKinsey interview, “What you do is you create the incentive structure for teams to take the paved path. But if they really have to go a different route, you make it possible for them to do that.”  

    While the paved path approach offers more autonomy for engineering teams, it requires teams that veer off the path to maintain the integrity of their software. Without guardrails, operations must put full trust in teams to keep their services secure and compliant. It can often be difficult for operations teams to maintain visibility into the services and infrastructure that fall outside the core platform.

    So, given that a mandated approach restricts autonomy and a paved path can make compliance more difficult, what is the middle ground?

    Bridging the Gap Between Mandated and Paved Path

    First, it’s important to understand that governance is not synonymous with command and control. Instead, operations teams should think of governance as the practice of maintaining visibility and providing best practices. Rather than a mandated platform approach, organizations can choose an approach that offers more autonomy to engineering teams (similar to paved path) while also maintaining operational governance. This is a trust and verify approach. 

    Using the trust and verify approach, organizations should focus their efforts on technology, not people, to maintain compliance. The goal would be to have a platform that could easily connect to the entire toolchain any product team uses for complete visibility and context. In this way, operations can gain governance without adding friction for product teams. This requires a top-down approach within organizations: I&O leaders investing in engineering resources or an off-the-shelf platform that can enable this technology. Both engineering and operations can flourish in this modern environment. Approaching governance from a trust and verify perspective will expand access to innovation while ensuring compliance and security standards. 

    Governance Should be Over Technology, not People

    Creating a bridge to a trust and verify approach means placing the responsibility for governance on technology rather than people to maintain detailed audit trails of human and machine actions tied to identity and reduce the potential for human error through automation. This approach provides autonomy for engineering teams while also ensuring governance through visibility and process controls embedded into workflows and tooling. 

    Shellie Miller, senior manager, technology governance and compliance at Hulu, believes technology can support DevOps practices. “To have a successful DevOps organization, we don’t need to have command and control or have this clear line of separation between dev and operations. It’s putting the responsibility on the infrastructure, the platform and the tooling and the policies and the processes that you have to enable those self-serve capabilities,” Miller said. 

    Mitigating Human Error Through Automation

    This investment in technology should focus on automation and process controls that fit within teams’ current processes. “What auditors are really trying to do is mitigate human error,” said Miller. “Teams should really focus on automating controls, building those security practices and those best practices into the platform. That way, dev teams are just subscribing to that offering.” 

    Changes to applications, systems, data and code—one of the biggest culprits with regard to risk—is where automation and process controls embedded into platform offerings can make a huge impact. “From an engineering perspective, constant change is needed to support rapidly changing consumer demands,” Miller added. “However, from an audit perspective, these activities increase risk of material impact to viewer experience, revenue and/or financial reporting.”

    Investment in Governance Comes From the Top

    While technology holds the key to better governance and compliance standards, there’s an investment that must be made, whether that’s investing engineering resources in building automation or investing in an off-the-shelf platform that can enable automation.

    “Leadership and organizational backing is absolutely key,” said Miller. “You can’t get to compliance or governance or any kind of operational maturity, for that matter, when you’re doing a bottom-up approach.”

    Building a compliance and security program around technology and not people means having the proper skills and mindsets. A bottom-up approach could create friction, especially due to a lack of education and understanding of the why and how. A top-down approach ensures there are resources to both implement the technology and to foster a culture of understanding and education. 

    The most common question I get asked is, ‘Why can’t we trust our people?’” Miller said. “Compliance requirements don’t generally start with the thought that our people are being malicious. We should run an organization of trust, and through automated monitoring and governance, we can verify and govern without being intrusive and disruptive. Lack of training and the demand on teams is what drives the perception that there’s no trust. Security and compliance is intended to mitigate risk and prevent threats to the systems that enable the business.”

    Building on a “Trust and Verify” Platform Approach

    When it comes to governance, technology is our greatest asset. Of course, this investment can be substantial for many organizations that don’t have the engineering resources to build in-house. Today, new open source or off-the-shelf platforms enable operations teams to build self-service capabilities that provide guardrails against human error, an audit trail of human and machine actions and visibility across disparate tools and services. 

    No-code solutions that also provide a developer platform for deeper customization enable teams to build out these core requirements of governance without consuming considerable engineering resources. The door to a future where operations teams can provide more autonomy to development teams while maintaining governance is now open. Every organization has the ability to attain a “trust and verify” approach and meet the needs of both dev and ops.


    To hear more about cloud-native topics, join the Cloud Native Computing Foundation and the cloud-native community at KubeCon+CloudNativeCon North America 2021 – October 11-15, 2021

  • GitLab Shifts 18 Features Into Core Open Source Platform

    GitLab Shifts 18 Features Into Core Open Source Platform

    GitLab this week announced it has moved 18 features that previously organizations had to pay for into the core open source version of its namesake continuous integration/continuous delivery (CI/CD) platform.

    Scott Williamson, executive vice president of product management for GitLab, said as a general rule the company makes available DevOps tools for teams across the four tiers of services that organizations can employ. Features now being migrated to the Core offering include:

    Plan: Synchronize collaboration with “related issues,” “export issues,” “issues board focus mode” and “Service Desk”

    Create: Build better code and branch with the “web terminal for WebIDE,” “file syncing to web terminal” and “design management”

    Verify: Improve code quality with reports on merge requests

    Package: Build and share more efficiently with a set of package managers in one place

    Release: Continuous delivery simplified with “canary deployments,” “incremental rollout,” “feature flags” and “deploy boards”

    Configure: Support for multiple Kubernetes clusters to ease deployment of different environments

    Defend: Bolster application security with network policies for container network security

    As the global economy falters in the wake of the COVID-19 pandemic, it’s likely reliance on open source software will increase. Most organizations would rather throw IT labor at the ongoing management of an IT environment to manage open source software versus having to lay off IT employees that would be extremely difficult to find once the economy recovers. It remains to be seen to what degree that strategy will play out in DevOps environments, but Williamson said historically most of GitLab’s customers are organizations that first adopt the open source version of its platform.

    Less clear is the degree to which the downturn might also induce many of the organizations to employ a DevOps platform delivered as a set of software-as-a-service (SaaS) applications. GitLab has been for the past several years for an integrated approach to DevOps based on a single code base that is ultimately easier to deploy and manage. Many IT organizations may decide that rather than manage DevOps infrastructure, they now prefer to allocate what limited resources they have on hand to writing code.

    The number of application development projects being launched could also decline while others are suspended. At the same time, however, there are some vertical industry segments, such as digital entertainment and education services, that might see a spike in demand for additional services now that many people are staying home to help limit the scope of the COVID-19 pandemic.

    Of course, many DevOps teams are among the legions of workers that now need to remotely access platforms. Williamson said supporting remote DevOps teams has long been a strength of the GitLab platform. GitLab also makes available a playbook that provides DevOps teams with guidance on how best to work remotely.

    Clearly, it will be a few months before the full impact of the COVID-19 pandemic is fully appreciated. Regardless, many IT organizations are clearly preparing for the worst of times while continuing to hope for the best outcome possible.

    — Mike Vizard

  • Quick Base Makes Free Low-Code Platform Available for First Responders

    Quick Base Makes Free Low-Code Platform Available for First Responders

    Quick Base, a provider of a platform for building low-code applications, announced this week that it is making its platform available for free through Sept. 30 to first responder organizations that need to build applications quickly to address the COVID-19 pandemic.

    Jay Jamison, chief product and technology officer for Quick Base, said it’s apparent first responders soon will need applications to track things ranging from assets such as ventilators to heat maps that show the number of patients in a geographic area relative to the number of intensive care units (ICUs) available.

    Quick Base is also making available templates that can be employed to build the most common types of emergency response applications, such as ones already being employed by the City of New Orleans.

    Examples of other applications that will be needed include the ability to track businesses in real-time that may be flouting COVID-19 restrictions or landlords that are evicting tenants despite emergency decrees, noted Jamison.

    Most of these applications will need to be developed in days versus weeks or months. To that end, Quick Base is also making available to first responder organizations the expertise of its internal customer success staff as well as third-party consultants, he said.

    In addition, Quick Base plans to certify many of these applications for distribution via its online store, which will make it easier for a first responder organization in one locality to leverage an application that has already been developed by another first responder organization.

    In general, Jamison said first responder organizations will need to apply DevOps principles across their entire organization to adjust to highly fluid situations. Applications undoubtedly will need to be modified as processes evolve and new emergency decrees are declared, he noted.

    The biggest challenge from an IT perspective is many first responder organizations lack the process expertise needed to build an application on the fly. Volunteers with IT expertise will be needed to work alongside medical experts, who will need applications that most likely will be deployed in the cloud but made accessible via a range of mobile computing devices. The chances all those applications will work perfectly when first deployed is almost nil, so timely updates to applications will be critical.

    Of course, applications and IT processes are not always the first things that come to mind to combat a pandemic. However, the faster first responders can respond to changing conditions on the ground, the more lives that might potentially be saved. In some large cities, it’s probable first responders already have access to a range of applications that to vary degrees might scale to meet the current challenge. However, in smaller localities, the availability of such applications is nominal at best.

    Quick Base is not the only provider of low-code and no-code tools for building applications, so there are plenty of options for building applications quickly. Whichever the platform employed, time is going to be of the essence. Outbreaks in Italy, Spain and China have already shown how quickly events can spiral out of control. If any new application is going to be relevant in any other emerging CIVID-19 hot zone, the work to build that application needs to start immediately.

    — Mike Vizard

  • DevSecOps: Fortanix Adds Open Source Rust SDK to Build Encrypted Apps

    DevSecOps: Fortanix Adds Open Source Rust SDK to Build Encrypted Apps

    There’s a lot of focus these days on DevSecOps as part of an effort to fix what’s generally acknowledged as a broken cybersecurity paradigm. But instead of trying to ensure every potential vulnerability is addressed before an application is deployed, another idea is gaining momentum among the DevOps community: Build applications that are secure in the first place, using modern programming languages.

    Fortanix, at RSA Conference 2019, launched an Enclave Development Platform (EDP) based on an open source software development kit (SDK) written in Rust. The SDK is optimized for Intel Software Guard Extensions (SGX), which are extensions to Intel instruction sets that define private regions of memory, dubbed enclaves, that prevent data to either be read or saved by any process outside the enclave. Intel SGX is required to be on by default in the latest generations of Intel processors.

    Company CEO Ambuj Kumar said Fortanix has been advocating the adoption of a runtime platform that makes it possible to process encrypted data in memory without ever having to expose it as plain text. By partnering with Intel to create a Rust-based SDK, the company wants to make it easier for developers to take advantage of an inherently secure programming language to invoke the Fortanix runtime.

    Fortanix, which also provides access to a self-service key management service for managing encryption, recently received an additional $23 million in funding led by Intel Capital.

    Kumar said Rust is gaining in popularity as a programming language because it is designed to include guardrails that prevent cybercriminals from injection attacks by corrupting code running in memory. In fact, Kumar noted that one of the reasons why cybersecurity professionals are now against deploying applications written in C or C# is because there are no such guardrails available.

    The combination of Rust and Intel SGX doesn’t eliminate the need for organizations to define a set of best DevSecOps processes. But it does take a significant amount of pressure off developers who choose to build applications using a modern programming language to create applications that are not as easily hacked.

    Naturally, it will take some time for developers to give up tools based on legacy programming languages that many of them have been using for years. But Kumar said Rust adoption is already spreading like wildfire because developers are looking for a way to eliminate cybersecurity issues that many are now being held accountable to resolve once they are discovered in a production environment.

    Of course, billions of lines of legacy application code are not going to disappear overnight simply because a new programming language has come into vogue. But enhancing cybersecurity may very well become a compelling reason to rewrite some of those most mission-critical legacy applications, especially if they wind up improving the performance. After all, those legacy applications are targeted because that’s where the organization’s most valuable data resides. Of course, Intel is betting it won’t make sense to deploy those rewritten applications on processors that don’t support SGX. But whatever the rationale, the amount of time developers have to devote to ongoing cybersecurity issues is clearly limited.

    — Mike Vizard