devopsy.kinsta.cloud

Tag: google

  • WTH? We Wanna WFH | DoD Dual-Sources JWCC | More Nvidia ARM Woes

    WTH? We Wanna WFH | DoD Dual-Sources JWCC | More Nvidia ARM Woes

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

    This week: Working from home is de rigueur, JEDI redux, and more about Nvidia/Arm.

    Survey Says: Devs Stay Out of Office

    First up this week: GitHub’s annual survey of developers has some fascinating data on the workplace (ahem) “new normal.” The pandemic has radically changed devs’ expectations of where they can do their jobs.

    Analysis: WFH is SOP

    As with other roles, Dev people want to continue to work from home. But does this pose a threat to your DevOps culture? Make sure you can do Ops with equal flexibility.

    Paul Krill: Dev productivity is back to pre-pandemic levels

    GitHub’s “2021 State of the Octoverse” research … sees signs that work rhythm is returning to pre-pandemic levels. GitHub also found that 46 percent of developers who worked co-located with teammates now expect to work fully remotely or in a hybrid environment.
    …
    Based on data culled from more than four million repositories and surveys of more than 12,000 developers … JavaScript and Python remain the top languages, followed by Java and TypeScript. [And] GitHub found that development team performance can increase as much as 87 percent when reusing code and as much as 43 percent when using … CI/CD.


    Zeroing in on the WFH angle, it’s Richard Speed:

    Respondents who were in the office either full or part-time dropped from 42 percent before the pandemic to a mere 10.7 percent now. … That’s a lot of empty desks.
    …
    Fans of the ctrl-c, ctrl-v combo will be delighted to note that GitHub found that when code reuse was made “frictionless” at work, developer’s performance increased by up to 87 percent. … It’s all splendid stuff.


    But beware of statistical fallacies, thinks Henrik Ingo—@h_ingo:

    #WorkFromHome may have been more common than anyone realized. [But] is the population of GitHub users/respondents somehow skewed toward pioneers/early adopters? … This might be a case of correlation is not causation.

    Defense Dept. Orders New Clouds

    The DoD issued its latest cloud contract opportunity notice, with the snappy title of “Joint Warfighting Cloud Capability” (JWCC). Reading between the lines of the notice, it all sounds very DevOps-cum-Agile.

    The Pentagon has backed away from its previous insistence on a single supplier, and now wants at least two cloud providers.

    Analysis: JEDI redux, because AWS wants a do-over

    JWCC is the follow-on from the aborted JEDI procurement. Amazon Web Services was “disappointed” to have been passed over in favor of Microsoft. Now it appears the DoD wants them to share.

    What can you learn from such a multi-vendor DevOps strategy?

    Jordan Novet: Pentagon asks Amazon, Google, Microsoft and Oracle for bids

    Amazon and Microsoft were the finalists for a single Joint Enterprise Defense Infrastructure. … Microsoft won it in 2019, Amazon filed a protest and the Pentagon canceled the contract in July.
    …
    The new effort [is] known as Joint Warfighting Cloud Capability. … JWCC differs from JEDI because it allows the Pentagon to rely on multiple cloud providers.
    …
    The U.S. General Services Administration … said only two U.S. cloud infrastructure providers, Amazon and Microsoft, appear able to comply with all of the Pentagon’s requirements. … The value of the new contracts is not known, but the Defense Department estimates it could run into the multiple billions of dollars.


    In summary, heed this Anonymous Coward:

    Competing suppliers will try harder than one non-competing supplier. The DoD has had a lot of problems with One-Ring-to-rule-them-all systems like the F-35. … JEDI would have been the same.
    …
    Smaller steps with upgrades while testing/using offers better returns. Done right they can get a better deal by making the companies compete against each other in making sure the products are actually useful.


    But look carefully at the DoD contract opportunity, says bustinbrains:

    They’ll all get contracts. Then DoD will simply use the one that they actually like the best. No one can complain because it’s open-ended with no guarantees.

    Arm/Nvidia Deal on FTC’s Radar

    Last week, we talked about Nvidia’s goal to acquire Arm Ltd from SoftBank, and the regulatory challenges it poses—notably in the UK, home of the chip architect. After we went to press, the other shoe dropped.

    Analysis: Just Give Up Already

    As we said last week, Nvidia can’t be allowed to do this. Not only are ARM chips found in 99% of smartphones, but they’re an increasing fixture in the datacenter—especially places that value “performance per Watt.”

    Richard Waters: What’s next for the tumultuous takeover of Arm?

    Nvidia’s acquisition of UK chip design company Arm from SoftBank has provoked serious opposition on both sides of the Atlantic. … The US Federal Trade Commission had its own worries. China, meanwhile, is waiting in the wings.
    …
    The deal has shone a spotlight on the unique position Arm plays in the chip industry. [Nvidia] offered a guarantee that it won’t block any other companies from licensing Arm’s designs. The offer has fallen on deaf ears, with both the EU and UK ruling it inadequate. … Post-Brexit politics have also come into play.
    …
    At what point might Nvidia and SoftBank call it a day? … A stock market listing [is] the most likely alternative, with the UK a favoured venue.


    How’s it viewed from the inside? Here’s a hint from fivemack:

    I was at ARM when Softbank bought them; it came as a surprise to everybody, because we were absolutely confident that we were unbuyable because anyone interested in us would want to use differential licensing as a weapon against their competitors, and we … were confident that regulators wouldn’t accept that.
    …
    Lots of people went home with a year’s pay check in free money. And not a few people … went home with a decade’s pay check in free money.


    More and more DevOps workloads are running on ARM silicon. Here’s Biophoton:

    The low power expertise of ARM has to be an advantage in the data centre (DC) market. … Plus Linux is available on ARM so architectural lock-in of Intel could be eroded in the DC market.

    The Moral of the Story: You are known by the company you keep


    You have been reading The Long View by Richi Jennings. You can contact him at @RiCHi or tlv@richi.uk.

    Image: Lukas Mann (via Unsplash)

  • Google Makes Fuzz Testing Integration Tool Available

    Google Makes Fuzz Testing Integration Tool Available

    Google today made available a ClusterFuzzLite tool that makes it simpler to incorporate fuzz testing into a DevOps workflow.

    Fuzz testing refers to an automated software testing technique that involves providing invalid, unexpected or random data as inputs to an application to discover issues such as potential memory leaks.

    Jonathan Metzman, a senior software engineer for Google, said ClusterFuzzLite is a lighter-weight version of a tool that Google makes available to its internal development teams. It is not a fuzz testing tool itself, but rather a tool that makes it easier to surface the results of a fuzz test within a DevOps workflow. Once those results are surfaced, it then becomes easier for developers to address issues before an application is deployed in a production environment.

    Core capabilities enabled by ClusterFuzzLite include continuous fuzzing, sanitizer support, corpus management and report generation tools. The goal is to make fuzz testing more accessible to a broader range of developers as part of an overall effort to embrace DevSecOps best practices, noted Metzman.

    ClusterFuzzLite currently supports GitHub Actions and Google Cloud Build, but Metzman said it is easily extensible to other DevOps platforms. It is designed to run as part of a DevOps workflow by adding a few lines of code to a continuous integration/continuous delivery (CI/CD) workflow.

    Google has already made ClusterFuzzLite available to open source projects, but is now providing additional access for commercial developers. Since its release in 2016, over 500 critical open source projects have integrated into the Google fuzz testing program for open source software, resulting in over 6,500 vulnerabilities and 21,000 functional bugs being fixed.

    In the wake of recent guidelines issued by the U.S. National Institute of Standards and Technology (NIST) that were themselves in response to an executive order issued by president Biden, the number of organizations using fuzz testing is expected to increase now that NIST has determined that fuzz testing is a minimum standard requirement for code verification.

    For several years, Google has been making a concerted effort to improve the security of open source software. The challenge for all developers is finding a way to build more secure applications without slowing down the rate at which they are deployed. Fuzz testing makes it possible to identify issues much earlier in the application development life cycle versus just before an application is deployed.

    Less clear, of course, is whether developers are starting to use these tools on their own or if the increased adoption is because of a concerted effort by their organization to embrace DevSecOps best practices. Regardless of the motivation, however, the overall state of application security should continue to improve as it becomes simpler for developers to invoke more advanced testing tools.

    In the meantime, organizations of all sizes are reviewing how they construct software in the wake of a series of high-profile security breaches. In theory, at least, increased focus on software supply chains should prevent issues from arising after deployment when they become much more costly to remediate.

  • Accelerate State of DevOps Report: The Move to Multi-Cloud

    Accelerate State of DevOps Report: The Move to Multi-Cloud

    Analysis of the 2021 Accelerate State of DevOps Report (SODR) data shows an increasing number of organizations are choosing multi-cloud and hybrid cloud solutions. In our survey, respondents were asked where their primary service or application was hosted, and the results showed that public cloud use is on the rise.

    Of the 1,200 survey respondents this year, 55% indicated they’re using a public cloud, a 5% increase from 2019. Of those approximately 660 people, 21% indicate they use multiple cloud providers and 34% indicate using a hybrid cloud strategy. For clarification, multi-cloud refers to the use of two or more public cloud providers and hybrid cloud refers to the use of an on-premises data center and/or private cloud in combination with one or more public clouds.

    multi-cloud adoption

    Our data indicated that the No. 1 reason for using multiple providers is to leverage the unique benefits that each provider brings to the market. Every cloud provider provides basic compute and storage services, but building a best-in-class business can be best achieved by taking advantage of best-in-class cloud computing features and not being locked into a specific vendor. In fact, 26% of our respondents indicated this was their primary reason for their multi-cloud or hybrid cloud approach.multi-cloud reasons

    The second most-reported reason, at 22%, was availability. Companies around the world are increasingly identifying as software companies and relying on software to be their primary business driver. Software allows companies to deliver value to their customers, outperform their competition, respond to market events and bring innovation to the market. Availability of this core product is not a “nice to have”, it is essential. The truth is, however, that computers and networks are fragile—they fail. If we accept this fact, we can design and build systems that are prepared for this eventuality. Companies are addressing these risks with strategies that decrease the blast radius of changes and allow systems to continue operating even in the face of failure.

    Speaking of worst-case scenarios, disaster recovery (DR) is the third most-reported reason for adopting multiple cloud providers. In fact, the cloud and the global proliferation of data centers has allowed companies to rethink what disaster recovery actually means. Gone are the days of systems going down and operators scrambling to rebuild systems and restore from tape backups—the cloud is the backup. The adoption of cloud plus fully automated pipelines creates a paradigm shift around DR that allows companies to design their disaster recovery strategy around zero downtime.

    In addition to hybrid and multi-cloud strategies increasing, we also saw a rise in the use of the five essential characteristics of cloud computing. The National Institute of Standards and Technology (NIST) defines the five essential characteristics as:

    These five characteristics must be embraced and used to realize the value of the cloud. A company that adopts cloud but does not employ these characteristics simply shifts their operating environment from one place to another but doesn’t gain anything. In fact, the unfamiliarity of a new environment, new pricing models and lack of optimization from years of running on-premises often leads to disappointment. Successful companies embrace these five characteristics.

    We know from previous reports that these characteristics are essential for delivering software at a high or elite performance level. We see adoption rates between 73% and 78% across the five characteristics with the lowest being on-demand self-service (73%) and the highest being measured service (78%). There is no doubt that this increased adoption is a key driver for the jaw-dropping performance we saw this year from our elite performers.

    Elite performers can now deploy 973x times more frequently, have a 6,570x faster lead time to deploy, have a 3x lower change failure rate and a whopping 6,570x faster time to recover from incidents when failure does happen. Go back and read that again—no, those are not typos nor an error in the data! An elite-performing company can bring a new feature to market 6,570x faster than a low-performing company. This is one of the reasons we see a direct link between software delivery performance and overall business performance.

    We encourage you to read the entire 2021 Accelerate State of DevOps report. There’s lots of great information in the report including the addition of a fifth key metric—that’s right; the ‘Four Keys’ are now the ‘Five Keys.’ “What is the new metric?” you ask? Well, I guess you will have to read the report and find out. 🙂

  • Google Donates Sqlcommenter to OpenTelemetry Project

    Google Donates Sqlcommenter to OpenTelemetry Project

    Google announced today that Sqlcommenter, an open source project that provides access to an object-relational mapping (ORM) auto-instrumentation library, is being merged with OpenTelemetry, an open source project for building agent software to instrument applications.

    Nimesh Bhagat, a product manager for Google, said Sqlcommenter is designed to make it simpler to correlate application and database telemetry. OpenTelemetry provides a mechanism for collecting logs, metrics and traces that is being advanced under the auspices of the Cloud Native Computing Foundation (CNCF).

    The challenge organizations using OpenTelemetry to collect that data will face is the need for tools to query that data in whatever platform it ultimately resides, noted Bhagat. OpenTelemetry previously lacked a common standard by which application tags and traces can be sent to databases and correlated with an application stack. Google envisions that IT teams will either employ Sqlcommenter to explore data or access via platforms such as Cloud SQL Insights or a third-party application performance management (APM) platform.

    Google made Sqlcommenter available as open source software earlier this year. It is designed to enable object–relational mappings (ORMs) to augment SQL statements before execution by, among other things, providing access to comments containing information about the application code that caused its execution.

    Sqlcommenter also allows OpenTelemetry trace context information to be propagated to the database, enabling correlation between application traces and database query plans that ultimately should make it easier to, for example, determine the root cause of a performance issue involving a microservices-based application making calls to a database. Sqlcommenter is primarily designed to be employed by full-stack developers that have some familiarity with how to use SQL to query data residing in an observability platform, noted Bhagat.

    Specifically, Sqlcommenter is designed to provide deeper insights into the performance of backend databases by simplifying the process of correlating slow queries with source code. It currently supports Python, Java, Node.js and Ruby languages along with ORMs such as Django, Sqlalchemy, Hibernate, Knex, Sequelize and Rails.

    As the number of applications that are instrumented using open source software continues to steadily increase, the amount of data that a DevOps team could potentially query also will steadily increase. Cloud storage platforms have made it easier to store that data at an affordable cost but the next challenge is clearly going to be finding a way to surface meaningful insights from all that data. Undoubtedly, achieving that goal will require everything from query tools to machine learning algorithms capable of identifying patterns at a level of scale that would not otherwise be possible.

    In the meantime, DevOps teams can look forward to being able to attain a level of observability that previously could only be achieved at a cost that tended to limit the number of applications organizations would instrument. At a time when the dependencies between applications increases with each passing day, that level of observability will soon prove indispensable.

  • Google Unveils Tool to Better Secure GitHub Repos

    Google Unveils Tool to Better Secure GitHub Repos

    Google today launched a GitHub app that provides automated continuous enforcement of security best practices for GitHub projects.

    Kim Lewandowski, a product manager for open source software security at Google, said the Allstar application enables IT teams to assess any project on GitHub to check for security policy adherence. In addition, Allstar sets desired enforcement actions and automatically applies those rules when triggered by a setting or file change in a repository.

    The goal is to provide the open source community with a tool that makes it possible for organizations to have more confidence in the open source software that is being employed within a software supply chain, said Lewandowski.

    Allstar is intended as a companion application for Security Scorecards, a tool that Google made available last year to assess whether, for example, an open source project employs branch protection to ensure that malware isn’t inadvertently committed to a project. Allstar continuously checks expected GitHub API states and repository file contents against security policies and the enforcement actions defined by an IT organization. After it detects a policy violation, the tool can be configured to simply send an alert or to automatically enforce a specific policy to remediate the issue, said Lewandoski. Specifically, she said the options available are to log the security policy violation without taking any additional action, open a GitHub issue or modify the GitHub setting to match the original Allstar configuration.

    At present, Allstar provides a limited number of security policy checks, but more will be made available over the coming months, said Lewandowski. Current security policy checks include branch protection, vulnerability disclosures, access controls and detection of binary artifacts that can’t be scanned. Additional checks that will be added include automatic dependency updates and frozen dependencies.

    Lewandowksi said Allstar and Security Scorecards are part of an ongoing Google effort to give back to the open source community that is being targeted by cybercriminals attempting to compromise software supply chains. Just about every application is now dependent on open source components, to some degree. The maintainers of those projects, however, don’t always have the tools or expertise required to check for malware that has been injected into a codebase, she noted.

    In general, Lewandoski noted that achieving DevSecOps best practices will require a lot more automation of application security. It’s not possible for each developer to become a world-class cybersecurity expert. The challenge is finding a way to introduce that automation into the application development process as early as possible, which, she noted, in many cases starts with open source components that are incorporated in applications.

    It may take a while for every maintainer of an open source project to revamp the processes through which code is added to their project. However, the easier it becomes to continuously review that software, the more confidence organizations that use it will have in its security. In fact, the maintainers of those projects should expect the downstream users of that software to be asking some pointed questions about how security is being managed in the wake of a series of recent high-profile breaches of software supply chains.

  • Google Proposes SLSA Framework to Secure Software Supply Chains

    Google Proposes SLSA Framework to Secure Software Supply Chains

    Google is proposing organizations adopt a framework for securing the integrity of software artifacts across a software supply chain.

    Kim Lewandowski, a product manager for open source software security at Google, said the Supply Chain Levels for Software Artifacts (SLSA) is based on an internal framework, known as binary authorization for Borg, that the company has been employing now for more than eight years to secure its software. Borg is the name Google attached to the platform for building and deploying applications upon which Kubernetes is based.

    In its current form, SLSA is a set of guidelines that identifies how to attain four different levels of application security. The goal, however, is to create a framework that will automatically generate auditable metadata that can be fed into policy engines to create a SLSA certification.

    The lowest level of SLSA requires that the build process be fully scripted or automated and generates metadata that enables provenance to be created. At the highest level, SLSA requires a two-person review of all changes made during a hermetic, reproducible build process. At the highest SLSA security level, organizations should be able to assure others that their software supply chain has not been compromised, said Lewandowski.

    Google

    In the wake of a recent series of high-profile breaches of software supply chains, the level of scrutiny being applied to how software is constructed has increased significantly. In theory, at least, developers have assumed more responsibility for application security as part of an overall shift left that provided them with more programmatic control over IT environments. As a result, cybercriminals are now focused on compromising either the credentials of developers as part of an effort to insert malware into application as it is developed, or they are trying to exploit vulnerabilities that developers have inadvertently created by programmatically misconfiguring infrastructure.

    DevSecOps best practices are, of course, being adopted to teach developers how to better secure their application environments. The issue is that not enough developers are learning how to secure applications fast enough. The volume of attacks against the software supply chain continues to grow at a rate that is now much faster than organizations can thwart simply by educating developers. In some cases, organizations are once again empowering cybersecurity teams to make sure software supply chains are secure regardless of the potential impact on the rate at which applications are being developed.

    Google is trying to promote adoption of SLSA as a framework for securing both open source and proprietary application code, said Lewandowski. There’s no silver bullet for securing software, but a framework that ultimately automates as many of the security processes as possible within the context of a DevOps workflow would go a long way toward hardening the software supply chain, noted Lewandowski.

    SLSA is being put forward as a response to a cybersecurity executive order issued by President Biden that, among other things, tasks the National Institute for Standards and Technology (NIST), an arm of the U.S. Department of Commerce, to consult with federal agencies, the private sector, academia and other stakeholders in identifying standards, tools, best practices and other guidelines to enhance software supply chain security. Given the level of dependencies that exist across those software supply chains, that executive order, to varying degrees, now applies to almost any entity that builds software for an organization that, on some level, interacts with the Federal government.

  • Earth Day: The Green Side of Computing

    Earth Day: The Green Side of Computing

    When we think of climate change and the existential threat of global warming, our minds often conjure images of dirty factories pumping out carbon dioxide or fuel-guzzling cars sitting idle with their engines rumbling. We think of ice sheets tumbling into the ocean and sea levels rising, and we know that grand, sweeping changes are needed. However, while it’s always good to have one eye on the elephant in the room, it’s equally important to step back and look at the picture as a whole.

    Changing Climate Perceptions

    Have you ever thought about your own impact on the environment when settling down to stream something on Netflix? Or how your Zoom meeting tomorrow might contribute to the climate emergency? A recent study found that, despite a record drop in global emissions in 2020 due to the pandemic, the switch to remote working and at-home entertainment still presented a significant environmental risk. One hour of streaming or video conferencing, for instance, can emit 150 – 1,000 grams of carbon dioxide, so perhaps you should think twice about switching on your camera during your next virtual meeting. That’s because everything you do online is facilitated by a data center somewhere in the world. That data center will need to be powered, cooled and maintained in order to operate effectively. The majority of countries reported around a 20% rise in internet traffic from the beginning of the pandemic, meaning those data centers have to work even harder.

    Now, let’s apply this to the world of business. Do organizations consider their cloud activity or data center usage when assessing their environmental footprint? If the latest figures are anything to go by, simply turning down the thermostat by a few degrees may not be enough. Today, the technology business sector consumes roughly 7% of the world’s energy. By 2025, Greenpeace estimates that figure could skyrocket to more than 20%, mainly due to innovations in cloud computing designed to drive efficiency, automation and, of course, facilitate remote working.

    Data center workloads increased by 500% between 2010 and 2020 as more of the working world moved online. In the U.S. alone, data centers use roughly 660 billion liters of water per year to generate electricity and cool their facilities. In recent years, greenhouse gas emissions from data centers have eclipsed that of the entire global airline industry. That means your company’s use of technology could contribute more to global warming than a transatlantic flight. It’s clear that our perceptions around climate change and our relationship to the environment need to broaden considerably.

    Turning the Tide

    Fortunately, it seems the tide is turning. There are initiatives popping up all around the world to try and counter the impact our data centers are having on the environment. The European Union, for instance, has launched the 2030 Climate and Energy Framework – which aims to reduce greenhouse gas emissions by 40% by 2030, with all sectors doing their part. While governments have traditionally focussed on the more obvious issues, such as the burning of fossil fuels by cars, it seems their scope is now broadening in the knowledge that every action – large or small – helps. If we can solve the problem of polluting data centers now, before our dependence on them grows exponentially, we can prevent the next big ‘elephant in the room’ from emerging. Google knows this, and vowed to power all of its data centers using carbon-free energy by 2030. Other companies, like Equinix, are even further along with their green initiatives to protect and power a more sustainable digital world. In 2019, over 90% of Equinix’s global data center energy consumption was covered by renewable energy sources, pushing it one step closer to its long-term goal of using 100% clean and renewable energy.

    Computing has always had an impact on the environment, but it was so negligible that it barely registered. Those impacts are still negligible when looked at in isolation, but when multiplied by billions, they quickly add up. By changing the way we think about cloud computing and accepting it as a net contributor to the climate crisis, we can start to steer our future to safer shores. Making sure you work with data centers who share your passion for a green future is a great first step.

  • Sentry Extends Application Performance Monitoring Tool

    Sentry Extends Application Performance Monitoring Tool

    Sentry this week announced it has added support for applications that employ serverless computing frameworks as well as the Google Web Vitals service to its application monitoring tool.

    Company CEO Milin Desai said incorporating Google Web Vitals metrics into Sentry Performance Monitoring will become crucial as Google makes good on a pledge to rank websites and applications on its search engine based on the metrics it collects via this service.

    Google Web Vitals determines how fast an application is by monitoring how fast a site presents user interface objects. By coupling Web Vitals with transaction data gathered by Sentry, it becomes possible for developers to correlate how a transaction may be adversely impacting the user experience. That data then can be employed to adjust what application programming interfaces (APIs) should be called within an application, Desai said.

    At the same time, he noted a larger percentage of developers are starting to employ serverless computing frameworks within the front end of their applications. The Sentry platform now monitors serverless computing frameworks that are employed within a PHP, Node and Ruby-based application. Most of those frameworks are being used to trigger a specific action when some type of event occurs within an application, said Desai.

    Finally, Sentry has also added a Trends view that enables developers to see the most improved and most regressed transactions that have occurred over time. That capability enables developers to more easily determine when changes to the overall IT environment are adversely impacting their applications. Armed with that data, it then becomes easier to identify what changes were made at that time.

    In general, Desai said there is not enough focus on enabling observability for application developers versus IT operations teams. Sentry Performance Monitoring is designed to enable developers to correlate specific events occurring within their code to actual end user experiences by adding five lines of code to their applications.

    Observability tools for developers will not obviate the need for observability tools for IT operations teams, but Desai noted as far as visibility into applications is concerned, most developers today are flying blind. Observability is supposed to be a core tenet of any DevOps practice. However, the level of observability actually being achieved tends to vary widely among IT organizations.

    Of course, the best place to solve any issue is going to be within the application code, whenever possible. Many developers could eliminate performance issues long before many IT operations teams realize they exist if they had more visibility into how code was executing. That issue will become all the more pressing as IT organizations deploy applications based on microservices that have many dependencies.

    The challenge IT organizations face now is determining not only which observability platforms to employ, but also what level of visibility is required for all the different roles and personas that make up that team.

  • DevOps Deeper Dive: Google Roils Open Source Community

    DevOps Deeper Dive: Google Roils Open Source Community

    Google this week agitated the bulk of the open source community by launching the Open Usage Commons consortium to protect the trademarks of open source projects, starting with the Istio, Angular and Gerrit projects it launched.

    Launched in collaboration with SADA Systems and some independent contributors, the stated goal of the Open Usage Commons is to help open source projects assert and manage their project identity through programs specific to trademark management and conformance testing.

    Istio is a service mesh that runs on top of Kubernetes, while Angular is a web application framework. Gerrit is a code collaboration tool.

    Unlike previous open source projects that Google played a major role in developing such as Kubernetes, Google has yet to contribute these three projects to an open source consortium. That decision has members of the open source community now questioning Google’s commitment to open source software.

    In fact, IBM, which launched the Istio project in collaboration with Google, this week said the Open Usage Commons does not meet the level of open source governance IBM expects. Originally, IBM said the expectation was that Istio would be contributed to the CNCF once it achieved a level of maturity. That contribution would include Istio intellectual property and the trademark. Now IBM is encouraging Google to reconsider its Open Usage Commons approach.

    If Google continues to hold on to the intellectual property rights for open source projects such as Istio, those projects will become little more than a community project that Google exercises control over, said Priyanka Sharma, general manager of the Cloud Native Computing Foundation (CNCF), which oversees the ongoing development of Kubernetes, among other open source projects.

    “It’s not in the spirit of open source,” said Sharma. “I don’t think you can even call it open source.”

    Other open source initiatives will be hesitant to build on top of projects such as Istio if the intellectual property belongs to a single vendor, added Chip Childers, executive director of the Cloud Foundry Foundation (CFF). The trademark is never the main issue, he said.

    “The trademark is only part of the consideration,” said Childers.

    In the case of Istio, the decision to launch Open Usage Commons might also draw more attention to a Service Mesh Interface (SMI) project being advanced under the auspices of the CNCF. That interface promises to make it easier to rip and replace one service mesh for another.

    In the meantime, Google may be trying to maximize its investments in open source projects that until now have tended to benefit rivals more. In terms of consumption of cloud services based on Kubernetes, Google is a distant third at best to Amazon Web Services and Microsoft.

    In general, there are more open source projects than ever. However, some of the entities that launch those projects have complained that cloud service providers simply turn those projects into cloud services in a way that consumes most of the revenue opportunities any open source project might generate.

    Google now appears to be exacerbating those tensions further by trying to retain control over the open source project it leads, while selling services based on other open source software projects. It’s not clear to what degree this rift might drive a wedge between multiple open source factions. Google with this move may just drive more members of the open source community into the arms of AWS and Microsoft. However, for the moment at least, none of the projects covered by the Open Usage Commons trademarks are so critical that they could not be replaced by any one of several alternative projects that are truly open source.

  • Cisco Aligns With Google to Meld DevOps and NetOps

    Cisco Aligns With Google to Meld DevOps and NetOps

    The extension of a partnership between Cisco Systems and Google to drive tighter integration between their respective software-defined wide area network (SD-WANs) offerings and cloud platforms promises to accelerate the convergence of NetOps and DevOps.

    John Apostolopoulos, vice president and CTO for Intent-Based Networking Group at Cisco, said in the wake of the COVID-19 pandemic it’s clear more organizations will be employing SD-WANs as an alternative to virtual private networks. Many of those SD-WAN deployments, however, will be on public clouds rather than in a traditional on-premises data center, he added.

    As that transition occurs, DevOps teams will increasingly invoke SD-WAN services via application programming interfaces (APIs) residing in the cloud to provide users with access to cloud applications, noted Apostolopoulos.

    Cisco and Google have a technology alliance in place that spans everything from Kubernetes to cloud management software. That partnership is now being extended to include forthcoming deployments of Cisco SD-WAN software on Google Anthos, a cloud platform based on Kubernetes that can be deployed on any cloud or on-premises IT environment, sometime in the first half of 2021.

    The availability of SD-WAN services from Cisco on multiple cloud platforms will naturally have significant implications for NetOps teams. Rather than having to manage individual routers and switches, the future of SD-WANs is moving more toward being a set of software services that are programmatically invoked. It’s not clear to what degree NetOps teams might be folded into DevOps teams as that transition occurs. IT teams will always require networking experts to optimize networking services to one degree or another, said Apostolopoulos. However, the days when DevOps teams had to wait days or weeks for a NetOps team to manually provision network services on their behalf are coming to an end.

    Apostolopoulos said in the wake of the COVID-19 pandemic, flexibility has become a highly prized IT asset. As such, more applications will soon be deployed in the cloud than ever. Cisco is betting that rather than having to manage multiple cloud network services, more organizations will prefer to extend enterprise networking services from Cisco across multiple clouds. That approach will enable IT organizations to more easily centralize the management of network services via a management console built on top of a consistent set of APIs, he noted.

    Just as importantly, Cisco will provide the integrated tools needed to secure those network services, added Apostolopoulos.

    In effect, Cisco is betting that enterprise IT organizations are going to consolidate networking and security services as part of an effort to reduce the total cost of IT. Cisco may not always be the least expensive provider of an individual router or switch. However, the total cost of integrating networking and security offerings from multiple vendors can add up quickly. The degree to which organizations have the political will and economic capital required to achieve that goal, of course, remains to be seen. Nevertheless, it’s also clear that maintaining the current networking and security status quo is not going to be able to hold for very much longer.