Tech News - Cloud & Networking

On 9th December, Microsoft announced that the go-live release of the Azure Functions 3.0 is now available. Among many new capabilities and functionality added to this release, one amazing addition is the support for the newly released .NET Core 3.1 -- an LTS (long-term support) release -- and Node 12. With users having the advantage to build and deploy 3.0 functions in production, the Azure Functions 3.0 bring newer capabilities including the ability to target .NET Core 3.1 and Node 12, higher backward compatibility for existing apps running on older language versions, without any code changes. “While the runtime is now ready for production, and most of the tooling and performance optimizations are rolling out soon, there are still some tooling improvements to come before we announce Functions 3.0 as the default for new apps. We plan to announce Functions 3.0 as the default version for new apps in January 2020,” the official announcement mentions. While users running on earlier versions of Azure Functions will continue to be supported, the company does not plan to deprecate 1.0 or 2.0 at present. “Customers running Azure Functions targeting 1.0 or 2.0 will also continue to receive security updates and patches moving forward—to both the Azure Functions runtime and the underlying .NET runtime—for apps running in Azure. Whenever there’s a major version deprecation, we plan to provide notice at least a year in advance for users to migrate their apps to a newer version,” Microsoft mentions. https://twitter.com/rickvdbosch/status/1204115191367114752 https://twitter.com/AzureTrenches/status/1204298388403044353 To know more about this in detail, read Azure Functions’ official documentation. Creating triggers in Azure Functions [Tutorial] Azure Functions 2.0 launches with better workload support for serverless Serverless computing wars: AWS Lambdas vs Azure Functions

Today, at the ongoing KubeCon 2019, Grafana Labs, an open source analytics and monitoring solution provider, announced that Loki version 1.0 is generally available for production use. Loki is an open source logging platform that provides developers with an easy-to-use, highly efficient and cost-effective approach to log aggregation. The Loki project was first introduced at KubeCon Seattle in 2018. Before the official launch, this project was started inside of Grafana Labs and was internally used to monitor all of Grafana Labs’ infrastructure. It helped ingest around 1.5TB/10 billion log lines a day. Released under the Apache 2.0 license, the Loki tool is optimized for Grafana, Kubernetes, and Prometheus. Just within a year, the project has more than 1,000 contributions from 137 contributors and also has nearly 8,000 stars on GitHub. With Loki 1.0, users can instantaneously switch between metrics and logs, preserving context and reducing MTTR. By storing compressed, unstructured logs and only indexing metadata, Loki is cost-effective and simple to operate by design. It includes a set of components that can be composed into a fully-featured logging stack. Grafana Cloud offers a high-performance, hosted Loki service that allows users to store all logs together in a single place with usage-based pricing. Loki’s design is inspired by Prometheus, the open source monitoring solution for the cloud-native ecosystem, as it offers a Prometheus-like query language called LogQL to further integrate with the cloud-native ecosystem. Tom Wilkie, VP of Product at Grafana Labs, said, “Grafana Labs is proud to have created Loki and fostered the development of the project, building first-class support for Loki into Grafana and ensuring customers receive the support and features they need.” He further added, “We are committed to delivering an open and composable observability platform, of which Loki is a key component, and continue to rely on the power of open source and our community to enhance observability into application and infrastructure.” Grafana Labs also offers enterprise services and support for Loki, which includes: Support and training from Loki maintainers and experts 24 x 7 x 365 coverage from the geographically distributed Grafana team Per-node pricing that scales with deployment Read more about Grafana Loki in detail on GitHub. “Don’t break your users and create a community culture”, says Linus Torvalds, Creator of Linux, at KubeCon + CloudNativeCon + Open Source Summit China 2019 KubeCon + CloudNativeCon EU 2019 highlights: Microsoft’s Service Mesh Interface, Enhancements to GKE, Virtual Kubelet 1.0, and much more! Grafana 6.2 released with improved security, enhanced provisioning, Bar Gauge panel, lazy loading and more

NeuVector has released a new Security Policy as code capability for Kubernetes workloads. This release will automate container security for DevOps teams by using Kubernetes Custom Resource Definitions (CRDs). As security policies can be defined, managed, and automated during the DevOps process, teams will be able to quickly deliver secure cloud-native apps. These security policies can be implemented using CRDs to deploy customized resource configurations via YAML files. As these security policies are defined as code, they are version-tracked and built for easy automation. Teams can easily migrate security policies across Kubernetes clusters (or from staging to production environments) and manage versions of security policies tied to specific application versions. “By introducing our industry-first Security Policy as Code for Kubernetes workloads, we’re excited to provide DevOps and DevSecOps teams with even more control to automate safe behaviors and ensure their applications remain secure from ever-increasing threat vectors,” explains Gary Duan, CTO, NeuVector. “We continue to build out new capabilities sought by customers – such as DLP, multi-cluster management, and, with today’s release, CRD support. Our mission is acutely focused on raising the bar for container security by offering a complete cloud-native solution for the entire application lifecycle.” Features of NeuVector’s Security Policy as code Captures network rules, protocols, processes, and file activities that are allowed for the application. Permits allowed network connections between services enforced by application protocol (layer 7) inspection. Allows or prevents external or ingress connections as warranted. Sets the “protection mode” of the application to either Monitor mode (alerting only) or Protect mode (blocking all suspicious activity). Supports integration with Open Policy Agent (OPA) and other security policy management tools. Allows DevOps and security teams to define application policies at different hierarchies such as per-service rules defined by DevOps and global rules defined by centralized security teams. It is extensible so as to support future expansion of security policy as code to admission control rules, DLP rules, response rules, and other NeuVector enforcement policies. Head on to Neuvector’s blog for more details on Security Policy as Code feature. Further details about this release will be shared at KubeCon + CloudNativeCon North America 2019. Chaos engineering comes to Kubernetes thanks to Gremlin CNCF announces Helm 3, a Kubernetes package manager and tool to manage charts and libraries. StackRox Kubernetes Security Platform 3.0 releases with advanced configuration and vulnerability management capabilities.

The Cloud Native Computing Foundation (CNCF), which builds sustainable ecosystems for cloud native software, yesterday announced the stable release of Helm 3. Helm is a package manager for Kubernetes and a tool for managing charts of pre-configured Kubernetes resources. “Helm is one of our fastest-growing projects in contributors and users contributing back to the project,” said Chris Aniszczyk, CTO, CNCF. “Helm is a powerful tool for all Kubernetes users to streamline deployments, and we’re impressed by the progress the community has made with this release in growing their community.” As per the team the internal implementation of Helm 3 has changed considerably from Helm 2. The most important change is the removal of Tiller, a service that communicates with the Kubernetes API to manage Helm packages. Then there are improvements to chart repositories, release management, security, and library charts. Helm uses a packaging format called charts, which are collections of files describing a related set of Kubernetes resources. These charts can then be packaged into versioned archives to be deployed. Helm 2 defined a workflow for creating, installing, and managing these charts. Helm 3 builds upon that workflow, changing the underlying infrastructure to reflect the needs of the community as they change and evolve. In this release, the Helm maintainers incorporated feedback and requests from the community to better address the needs of Kubernetes users and the broad cloud native ecosystem. Helm 3 is ready for public deployment Last week, third party security firm Cure53 completed their open source security audit of Helm 3, mentioning Helm’s mature focus on security, and concluded that Helm 3 is “recommended for public deployment.” According to the report, “in light of the findings stemming from this CNCF-funded project, Cure53 can only state that the Helm projects the impression of being highly mature. This verdict is driven by a number of different factors… and essentially means that Helm can be recommended for public deployment, particularly when properly configured and secured in accordance to recommendations specified by the development team.” “When we built Helm, we set out to create a tool to serve as an ‘on-ramp’ to Kubernetes. With Helm 3, we have really accomplished that,” said Matt Fisher, the Helm 3 release manager. “Our goal has always been to make it easier for the Kubernetes user to create, share, and run production-grade workloads. The core maintainers are really excited to hit this major milestone, and we look forward to hearing how the community is using Helm 3.” Helm 3 is a joint community effort, with core maintainers from organizations including Microsoft, Samsung SDS, IBM, and Blood Orange. As per the team the next phase of Helm’s development will see new features targeted toward stability and enhancements to existing features. Features on the roadmap include enhanced functionality for helm test, improvements to Helm’s OCI integration, and enhanced functionality for the Go client libraries. To know more about this news, read the official announcement from the Cloud Native Computing Foundation. StackRox Kubernetes Security Platform 3.0 releases with advanced configuration and vulnerability management capabilities Microsoft launches Open Application Model (OAM) and Dapr to ease developments in Kubernetes and microservices An unpatched security issue in the Kubernetes API is vulnerable to a “billion laughs” attack Kubernetes 1.16 releases with Endpoint Slices, general availability of Custom Resources, and other enhancements StackRox App integrates into the Sumo Logic Dashboard for improved Kubernetes security  

Yesterday, Red Hat introduced the open source Project Quay container registry, which is the upstream project representing the code that powers Red Hat Quay and Quay.io. Open-sourced as a Red Hat commitment, Project Quay “represents the culmination of years of work around the Quay container registry since 2013 by CoreOS, and now Red Hat,” the official post reads. Red Hat Quay container image registry provides storage and enables users to build, distribute, and deploy containers. It will also help users to gain more security over their image repositories with automation, authentication, and authorization systems. It is compatible with most container environments and orchestration platforms and is also available as a hosted service or on-premises. Launched in 2013, Quay grew in popularity due to its focus on developer experience and highly responsive support and added capabilities such as image rollback and zero-downtime garbage collection. Quay was acquired by CoreOS in 2014 with a mission to secure the internet through automated operations. Shortly after the acquisition, the company released the on-premise offering of Quay, which is presently known as Red Hat Quay. The Quay team also created and integrated the Clair open source container security scanning project since 2015. It is directly built into Project Quay. Clair enables the container security scanning feature in Red Hat Quay, which helps users identify known vulnerabilities in their container registries. Open-sourced as part of Project Quay, both Quay, and Clair code bases will help cloud-native communities to lower the barrier to innovation around containers, helping them to make containers more secure and accessible. Project Quay contains a collection of open-source software licensed under Apache 2.0 and other open-source licenses. It follows an open-source governance model, with a maintainer committee. With an open community, Red Hat Quay and Quay.io users can benefit from being able to work together on the upstream code. Project Quay will be officially launched at the OpenShift Commons Gathering on November 18 in San Diego at KubeCon 2019. To know more about this announcement, you can read Red Hat’s official blog post. Red Hat announces CentOS Stream, a “developer-forward distribution” jointly with the CentOS Project Expanding Web Assembly beyond the browser with Bytecode Alliance, a Mozilla, Fastly, Intel and Red Hat partnership After Red Hat, Homebrew removes MongoDB from core formulas due to its Server Side Public License adoption

Today, StackRox, a Kubernetes-native container security platform provider announced StackRox Kubernetes Security Platform 3.0. This release includes industry-first features for configuration and vulnerability management that enable businesses to achieve stronger protection of cloud-native, containerized applications. In a press release, Wei Lien Dang, StackRox’s vice president of product, and co-founder said, “When it comes to Kubernetes security, new challenges related to vulnerabilities and misconfigurations continue to emerge.” “DevOps and Security teams need solutions that quickly and easily solve these issues. StackRox 3.0 is the first container security platform with the capabilities orgs need to effectively deal with Kubernetes configurations and vulnerabilities, so they can reduce risk to what matters most – their applications and their customer’s data,” he added. What’s new in StackRox Kubernetes Security Platform 3.0 Features for configuration management Interactive dashboards: This will enable users to view risk-prioritized misconfigurations, easily drill-down to critical information about the misconfiguration, and determine relevant context required for effective remediation. Kubernetes role-based access control (RBAC) assessment: StackRox will continuously monitor permission for users and service accounts to help mitigate against excessive privileges being granted. Kubernetes secrets access monitoring: The platform will discover secrets in Kubernetes and monitor which deployments can use them to limit unnecessary access. Kubernetes-specific policy enforcement: StackRox will identify configurations in Kubernetes related to network exposures, privileged containers, root processes, and other factors to determine policy violations. Advanced vulnerability management capabilities Interactive dashboards: StackRox Kubernetes Security Platform 3.0 has interactive views that provide risk prioritized snapshots across your environment, highlighting vulnerabilities in both, images and Kubernetes. Discovery of Kubernetes vulnerabilities: The platform gives you visibility into critical vulnerabilities that exist in the Kubernetes platform including the ones related to the Kubernetes API server disclosed by the Kubernetes product security team. Language-specific vulnerabilities: StackRox scans container images for additional vulnerabilities that are language-dependent, providing greater coverage across containerized applications.  Along with the aforementioned features, StackRox Kubernetes Security Platform 3.0 adds support for various ecosystem platforms. These include CRI-O, the Open Container Initiative (OCI)-compliant implementation of the Kubernetes Container Runtime Interface (CRI), Google Anthos, Microsoft Teams integration, and more. These were a few latest capabilities shipped in StackRox Kubernetes Security Platform 3.0. To know more, you can check out live demos and Q&A by the StackRox team at KubeCon 2019, which will be happening from November 18-21 in San Diego, California. It brings together adopters and technologists from leading open source and cloud-native communities. Kubernetes 1.16 releases with Endpoint Slices, general availability of Custom Resources, and other enhancements StackRox App integrates into the Sumo Logic Dashboard  for improved Kubernetes security Microsoft launches Open Application Model (OAM) and Dapr to ease developments in Kubernetes and microservices  

Update: On 25th November, the Quarkus team announced the release of Quarkus 1.0.0.Final bits. Head over to the Quarkus blog for more details on the official announcement. Last week, RedHat’s Quarkus, the Kubernetes native Java framework for GraalVM & OpenJDK HotSpot announced the availability of its first release candidate. It also notified users that its first stable version will be released by the end of this month. Launched in March this year, Quarkus framework uses Java libraries and standards to provide an effective solution for running Java on new deployment environments like serverless, microservices, containers, Kubernetes, and more. Java developers can employ this framework to build apps with faster startup time and less memory than traditional Java-based microservices frameworks. It also provides flexible and easy to use APIs that can help developers to build cloud-native apps, and best-of-breed frameworks. “The community has worked really hard to up the quality of Quarkus in the last few weeks: bug fixes, documentation improvements, new extensions and above all upping the standards for developer experience,” states the Quarkus team. Latest updates added in Quarkus 1.0 A new reactive core based on Vert.x with support for reactive and imperative programming models. This feature aims to make reactive programming a first-class feature of Quarkus. A new non-blocking security layer that allows reactive authentications and authorization. It also enables reactive security operations to integrate with Vert.x. Improved Spring API compatibility, including Spring Web and Spring Data JPA, as well as Spring DI. A Quarkus ecosystem also called as “universe”, is a set of extensions that fully supports native compilation via GraalVM native image. It supports Java 8, 11 and 13 when using Quarkus on the JVM. It will also support Java 11 native compilation in the near future. RedHat says, “Looking ahead, the community is focused on adding additional extensions like enhanced Spring API compatibility, improved observability, and support for long-running transactions.” Many users are excited about Quarkus and are looking forward to trying the stable version. https://twitter.com/zemiak/status/1192125163472637952 https://twitter.com/loicrouchon/status/1192206531045085186 https://twitter.com/lasombra_br/status/1192114234349563905 How Quarkus brings Java into the modern world of enterprise tech Apple shares tentative goals for WebKit 2020 Apple introduces Swift Numerics to support numerical computing in Swift Rust 1.39 releases with stable version of async-await syntax, better ergonomics for match guards, attributes on function parameters, and more Fastly announces the next-gen edge computing services available in private beta

Fastly, a San Francisco based startup, providing edge cloud platform, yesterday announced the private beta launch of Compute@Edge, its new edge computing services. Compute@Edge is a powerful language-agnostic compute environment. This major milestone marks as an evolution of Fastly’s edge computing capabilities and the company’s innovation in the serverless space.  https://twitter.com/fastly/status/1192080450069643264 Fastly’s Compute@Edge is designed to empower developers to build far more advanced edge applications with greater security, more robust logic, and new levels of performance. They can also create a new and improved digital experience with their own technology choices around the cloud platforms, services, and programming languages needed.  Rather than spend time on operational overhead, the company’s goal is to continue reinventing the way end users live, work, and play on the web. Fastly's Compute@Edge gives developers the freedom to push complex logic closer to end users. “When we started Fastly, we sought to build a platform with the power to realize the future of edge computing — from our software-defined modern network to our point of presence design, everything has led us to this point,” explained Tyler McMullen, CTO of Fastly. “With this launch, we’re excited to double down on that vision and work with enterprises to help them build truly complete applications in an environment that offers new levels of stability, security, and global scale.” We had the opportunity to interview Fastly’s CTO Tyler McMullen a few months back. We discussed Fastly’s Lucet and the future of WebAssembly and Rust among other things. You can read the full interview here.  Fastly Compute@Edge leverages speed for global scale and security Fastly’s Compute@Edge environment promises to offer 100x faster startup time at 35.4 microseconds, than any other solution in the market. Additionally Compute@Edge is powered by its open-source WebAssembly compiler and runtime, Lucet and supports Rust as a second language in addition to Varnish Configuration Language (VCL).  Other benefits of Compute@Edge include: Code can be computed around the world instead of a single region. This will allow developers to reduce code execution latency and further optimize the performance of their code, without worrying about managing the underlying infrastructure The unmatched speed at which the environment operates, combined with Fastly’s isolated sandboxing technology, reduces the risk of accidental data leakage. With a “burn-after-reading” approach to request memory, entire classes of vulnerabilities are eliminated With Compute@Edge, developers can serve GraphQL from its network edge and deliver more personalized experiences Developers can develop their own customized API protection logic With manifest manipulation, developers can deliver content with a “best-performance-wins” approach— like multi-CDN live streams that run smoothly for users around the world Fastly has operated in the serverless market since its founding in 2011 through its Edge Cloud Platform, including products like Full Site Delivery, Load Balancer, DDoS, and Web Application Firewall (WAF). Till date, Fastly’s serverless computing offering has focused on delivery-centric use cases via its VCL-powered programmable edge. With the introduction of Compute@Edge, Fastly unlocks even more powerful and widely-applicable computing capabilities. To learn more about Fastly’s edge computing and cloud services, you can visit its official blog. Developers who are interested to be a part of the private beta can sign up on this page. Fastly SVP, Adam Denenberg on Fastly’s new edge resources, edge computing, fog computing, and more Fastly, edge cloud platform, files for IPO Fastly open sources Lucet, a native WebAssembly compiler and runtime “Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett Wasmer introduces WebAssembly Interfaces for validating the imports and exports of a Wasm module

Yesterday, at the Microsoft Ignite 2019 in Orlando, the company released the preview of its first full-stack, scalable, general open cloud ecosystem, ‘Azure Quantum’. For developers, Microsoft has specifically created the open-source Quantum Development Kit, which includes all of the tools and resources you need to start learning and building quantum solutions. Azure Quantum is a set of quantum services including pre-built solutions to software and quantum hardware, providing developers and customers access to some of the most competitive quantum offerings in the market. For this offering, Microsoft has partnered with 1QBit, Honeywell, IonQ, and QCI. With Azure Quantum service, anyone gains deeper insights about quantum computing through a series of tools and learning tutorials such as the quantum katas. It also allows developers to write programs with Q# and QDK and experiment running the code against simulators and a variety of quantum hardware. Customers can also solve complex business challenges with pre-built solutions and algorithms running in Azure. According to Wired, “Azure Quantum has similarities to a service from IBM, which has offered free and paid access to prototype quantum computers since 2016. Google, which said last week that one of its quantum processors had achieved a milestone known as “quantum supremacy” by outperforming a top supercomputer, has said it will soon offer remote access to quantum hardware to select companies.” Microsoft’s Azure Quantum model is more like the existing computing industry, where cloud providers allow customers to choose processors from companies such as Intel and AMD, says William Hurley, CEO of startup Strangeworks. This startup offers services for programmers to build and collaborate with quantum computing tools from IBM, Google, and others. With just a single program, users will be able to target a variety of hardware through Azure Quantum – Azure classical computing, quantum simulators, and resource estimators, and quantum hardware from our partners, as well as our future quantum system being built on revolutionary topological qubit. Microsoft, on its official website, announced that the Azure Quantum will be launched in private preview in the coming months. Many users are excited to try the Quantum service by Azure. https://twitter.com/Daniel_Rubino/status/1191364279339036673 To know more about Azure Quantum in detail, visit Microsoft’s official page. Are we entering the quantum computing era? Google’s Sycamore achieves ‘quantum supremacy’ while IBM refutes the claim Using Qiskit with IBM QX to generate quantum circuits [Tutorial] How to translate OpenQASM programs in IBX QX into quantum scores [Tutorial]

A few days ago, the Google AI team introduced Snap, a microkernel-inspired approach to host networking at the 27th ACM Symposium on Operating Systems Principles. Snap is a userspace networking system with flexible modules that implement a range of network functions, including edge packet switching, virtualization for our cloud platform, traffic shaping policy enforcement, and a high-performance reliable messaging and RDMA-like service. The Google AI team says, “Snap has been running in production for over three years, supporting the extensible communication needs of several large and critical systems.” Why Snap? Prior to Snap, Google AI team says they were limited in their ability to develop and deploy new network functionality and performance optimizations in several ways. This is because developing kernel code was slow and drew on a smaller pool of software engineers. Second, feature release through the kernel module reloads covered only a subset of functionality and often required disconnecting applications, while the more common case of requiring a machine reboot necessitated draining the machine of running applications. Unlike prior microkernel systems, Snap benefits from multi-core hardware for fast IPC and does not require the entire system to adopt the approach wholesale, as it runs as a userspace process alongside our standard Linux distribution and kernel. Source: Snap Research paper Using Snap, the Google researchers also created a new communication stack called Pony Express that implements a custom reliable transport and communications API. Pony Express provides significant communication efficiency and latency advantages to Google applications, supporting use cases ranging from web search to storage. Features of the Snap userspace networking system Snap’s architecture comprises of recent ideas in userspace networking, in-service upgrades, centralized resource accounting, programmable packet processing, kernel-bypass RDMA functionality, and optimized co-design of transport, congestion control, and routing. With these, Snap: Enables a high rate of feature development with a microkernel-inspired approach of developing in userspace with transparent software upgrades. It also retains the benefits of centralized resource allocation and management capabilities of monolithic kernels and also improves upon accounting gaps with existing Linux-based systems. Implements a custom kernel packet injection driver and a custom CPU scheduler that enables interoperability without requiring the adoption of new application runtimes and while maintaining high performance across use cases that simultaneously require packet processing through both Snap and the Linux kernel networking stack. Encapsulates packet processing functions into composable units called “engines”, which enables both modular CPU scheduling as well as incremental and minimally disruptive state transfer during upgrades. Through Pony Express, it provides support for OSI layer 4 and 5 functionality through an interface similar to an RDMA-capable “smart” NIC. This enables transparently leveraging offload capabilities in emerging hardware NICs as a means to further improve server efficiency and throughput. Supports 3x better transport processing efficiency than the baseline Linux kernel and supporting RDMA-like functionality at speeds of 5M ops/sec/core. MicroQuanta: Snap’s new lightweight kernel scheduling class To dynamically scale CPU resources, Snap works in conjunction with a new lightweight kernel scheduling class called MicroQuanta. It provides a flexible way to share cores between latency-sensitive Snap engine tasks and other tasks, limiting the CPU share of latency-sensitive tasks and maintaining low scheduling latency at the same time. A MicroQuanta thread runs for a configurable runtime out of every period time units, with the remaining CPU time available to other CFS-scheduled tasks using a variation of a fair queuing algorithm for high and low priority tasks (rather than more traditional fixed time slots). MicroQuanta is a robust way for Snap to get priority on cores runnable by CFS tasks that avoid starvation of critical per-core kernel threads. While other Linux real-time scheduling classes use both per-CPU tick-based and global high-resolution timers for bandwidth control, MicroQuanta uses only per-CPU highresolution timers. This allows scalable time-slicing at microsecond granularity. Snap is being received positively by many in the community. https://twitter.com/copyconstruct/status/1188514635940421632 To know more about Snap in detail, you can read it’s complete research paper. Amazon announces improved VPC networking for AWS Lambda functions Netflix security engineers report several TCP networking vulnerabilities in FreeBSD and Linux kernels ReactOS 0.4.12 releases with kernel improvements, Intel e1000 NIC driver support, and more

Yesterday, GitLab retracted its earlier decision to implement user level product usage tracking on their websites after receiving negative feedback from its users. https://twitter.com/gitlab/status/1187408628531322886 Two days ago, GitLab informed its users that starting from its next yet to be released version (version 12.4), there would be an addition of Javascript snippets in GitLab.com (GitLab’s SaaS offering) and GitLab's proprietary Self-Managed packages (Starter, Premium, and Ultimate) websites. These Java snippets will be used to interact with GitLab and other third-party SaaS telemetry services. Read More: GitLab 12.3 releases with web application firewall, keyboard shortcuts, productivity analytics, system hooks and more GitLab.com users were specifically notified that until they accept the new service terms condition, their access to the web interface and API will be blocked. This meant that users with integration to the API will experience a brief pause of service, until the new terms are accepted by signing in to the web interface. The self-managed users, on the other hand, were apprised that they can continue to use the free software GitLab Core without any changes. The DevOps coding platform says that SaaS telemetry products are important tools to understand the analytics on user behaviour inside web-based applications. According to the company, these additional user information will help in increasing their website speed and also enrich user experience. “GitLab has a lot of features, and a lot of users, and it is time that we use telemetry to get the data we need for our product managers to improve the experience,” stated the official blog. The telemetry tools will use JavaScript snippets that will be executed in the user’s browser and will send the user information back to the telemetry service. Read More: GitLab faces backlash from users over performance degradation issues tied to redis latency The company had also assured users that they will disclose all the whereabouts of the user information in the privacy policy. They also ensured that the third-party telemetry service will have data protection standards equivalent to their own standard and will also aim for their SOC2 compliance. If any user does not wish to be tracked, they can turn on the Do Not Track (DNT) mechanism in their GitLab.com or GitLab Self-Managed web browser. The DNT mechanism will not load the  the JavaScript snippet. “The only downside to this is that users may also not get the benefit of in-app messaging or guides that some third-party telemetry tools have that would require the JavaScript snippet,” added the official blog. Following this announcement, GitLab received loads of negative feedback from users. https://twitter.com/PragmaticAndy/status/1187420028653723649 https://twitter.com/Cr0ydon/status/1187380142995320834 https://twitter.com/BlindMyStare/status/1187400169303789568 https://twitter.com/TheChanceSays/status/1187095735558238208 Although, GitLab has rolled backed the Telemetry service changes for now, and are re-considering their decision, many users are warning them to drop the idea completely. https://twitter.com/atom0s/status/1187438090991751168 https://twitter.com/ry60003333/status/1187601207046524928 https://twitter.com/tresronours/status/1187543188703186949 DevOps platform for coding, GitLab reached more than double valuation of $2.75 billion than its last funding and way ahead of its IPO in 2020 GitLab goes multicloud using Crossplane with kubectl Are we entering the quantum computing era? Google’s Sycamore achieves ‘quantum supremacy’ while IBM refutes the claim PostGIS 3.0.0 releases with raster support as a separate extension Electron 7.0 releases in beta with Windows on Arm 64 bit, faster IPC methods, nativetheme API and more

In June this year, Jonathan Chan, a software developer reported that Docker Compose automatically reads from .env. Since other systems also access the same file for parsing and processing variables, this was creating some confusion resulting in breaking compatibility with other .env utilities. Docker Compose has a "docker-compose.yml" config file used for deploying, combining, and configuring multiple multi-container Docker applications. The .env file is used for putting values in the "docker-compose.yml" file. In the .env file, the default environment variables are specified in the form of key-value pairs. “With the release of 1.24.0, the feature where Compose will no longer accept whitespace in variable names sourced from environment files. This matches the Docker CLI behavior. breaks compatibility with other .env utilities. Although my setup does not use the variables in .env for docker-compose, docker-compose now fails because the .env file does not meet docker-compose's format,” Chan explains. This is not the first time that this issue has been reported. Earlier this year, a user opened an issue on the GitHub repo. He described that after upgrading Compose to 1.24.0-rc1, its automatic parsing of .env file was failing. “I keep export statements in my .env file so I can easily source it in addition to using it as a standard .env. In previous versions of Compose, this worked fine and didn't give me any issues, however with this new update I instead get an error about spaces inside a value,” he explained in his report. As a solution, Chan has proposed, “I propose that you can specify an option to ignore the .env file or specify a different.env file (such as .docker.env) in the docker-compose.yml file so that we can work around projects that are already using the .env file for something else.” This sparked a discussion on Hacker News where users also suggested a few solutions. “This is the exact class of problem that docker itself attempts to avoid. This is why I run docker-compose inside a docker container, so I can control exactly what it has access to and isolate it. There's a guide to do so here. It has the added benefit of not making users install docker-compose itself - the only project requirement remains docker,” A user commented. Another user recommended, “You can run docker-compose.yml in any folder in the tree but it only reads the .env from cwd. Just CD into someplace and run docker-compose.” Some users also pointed out the lack of authentication mechanism in Docker Hub. “Docker Hub still does not have any form of 2FA. Even SMS 2FA would be something / great at this point. As an attacker, I would put a great deal of focus on attacking a company’s registries on Docker Hub. They can’t have 2FA, so the work/reward ratio is quite high,” a user commented. Others recommended to set up a time-based one-time password (TOTP) instead. Check out the reported issue on the GitHub repository. Amazon EKS Windows Container Support is now generally available GKE Sandbox : A gVisor based feature to increase security and isolation in containers 6 signs you need containers  

Yesterday, AWS announced that it is sponsoring the popular Rust programming language. Rust has seen a lot of developments in AWS as it is used for various performance-sensitive components in its popular services such as Lambda, EC2, and S3. Tech giants such as Google, Microsoft, and Mozilla also use Rust for writing and maintaining fast, reliable, and efficient code. Alex Crichton, Rust Core Team Member says, “We’re thrilled that AWS, which the Rust project has used for years, is helping to sponsor Rust’s infrastructure. This sponsorship enables Rust to sustainably host infrastructure on AWS to ship compiler artifacts, provide crates.io crate downloads, and house automation required to glue all our processes together. These services span a myriad of AWS offerings from CloudFront to EC2 to S3. Diversifying the sponsorship of the Rust project is also critical to its long-term success, and we’re excited that AWS is directly aiding this goal.” Why AWS chose Rust Rust project maintainers say the reason AWS chose Rust is due to its blazingly fast and memory-efficient performance; its rich type system and ownership model guarantee memory-safety and thread-safety; its great documentation, its friendly compiler with useful error messages, and top-notch tooling; and many other amazing features. Rust has also been voted as the “Most Loved Language” in Stack Overflow’s survey for the past four years. Rust also has an inclusive community along with top-notch libraries such as: Serde, for serializing and deserializing data. Rayon, for writing parallel & data race-free code. Tokio/async-std, for writing non-blocking, low-latency network services. tracing, for instrumenting Rust programs to collect structured, event-based diagnostic information. Rust too uses AWS services Rust project uses AWS services to: Store release artifacts such as compilers, libraries, tools, and source code on S3. Run ecosystem-wide regression tests with Crater on EC2. Operate docs.rs, a website that hosts documentation for all packages published to the central crates.io package registry. The AWS community is excited to include Rust in their community. It would be interesting to see the combination of Rust and AWS in their future implementations. Few users are confused about the nature of this sponsorship. A Redditor commented, “It's not clear exactly what this means - is it about how AWS provides S3/EC2 services for free to the Rust project already (which IIRC has been ongoing for some time), or is it an announcement of something new ($$$ or developer time being contributed?)?” To know about this announcement in detail, read AWS’ official blog post. Amazon announces improved VPC networking for AWS Lambda functions Reddit experienced an outage due to an issue in its hosting provider, AWS Rust 1.38 releases with pipelined compilation for better parallelism while building a multi-crate project Mozilla introduces Neqo, Rust implementation for QUIC, new http protocol

A few days ago, Amazon announced the general availability of the Windows Container support on  Amazon Elastic Kubernetes Service (EKS). The company announced a preview of the Windows Container support in March this year and also invited customers to try it out and provide their feedback. With the Windows Container Support, development teams can now deploy applications designed to run on Windows Servers, on Kubernetes alongside Linux applications. It will also bring in more consistency in system logging, performance monitoring, and code deployment pipelines. “We are proud to be the first Cloud provider to have General Availability of Windows Containers on Kubernetes and look forward to customers unlocking the business benefits of Kubernetes for both their Windows and Linux workloads,” the official post mentions. A few considerations before deploying the Worker nodes include: Windows workloads are supported with Amazon EKS clusters running Kubernetes version 1.14 or later. Amazon EC2 instance types C3, C4, D2, I2, M4 (excluding m4.16xlarge), and R3 instances are not supported for Windows workloads. Host networking mode is not supported for Windows workloads. Amazon EKS clusters must contain 1 or more Linux worker nodes to run core system pods that only run on Linux, such as coredns and the VPC resource controller. The kubelet and kube-proxy event logs are redirected to the Amazon EKS Windows Event Log and are set to a 200 MB limit. In a demonstration, Martin Beeby, a principal evangelist for Amazon Web Services has created a new Amazon Elastic Kubernetes Service cluster, which works with any cluster that is using Kubernetes version 1.14 and above. He has also added some new Windows nodes and deploys a Windows application. For a complete demonstration and to know more about the Amazon EKS Windows Container Support, read AWS’ official blog post. Amazon EBS snapshots exposed publicly leaking sensitive data in hundreds of thousands, security analyst reveals at DefCon 27 Amazon is being sued for recording children’s voices through Alexa without consent Amazon Managed Streaming for Apache Kafka (Amazon MSK) is now generally available

More than five months after announcing Warp, Cloudflare has finally made it available to the general public, yesterday. With two million people on the waitlist to try Warp, the Cloudflare team says that it took them harder than they thought to build a next-generation service to secure consumer mobile connections, without compromising on speed and power usage. Along with Warp, Cloudflare is also launching Warp Plus. Warp is a free VPN to the 1.1.1.1 DNS resolver app which will speed up mobile data using the Cloudflare network to resolve DNS queries at a faster pace. It also comes with end-to-end encryption and does not require users to install a root certificate to observe encrypted internet traffic. It is built around a UDP-based protocol that is optimized for the mobile internet and offers excellent performance and reliability. Why Cloudflare delayed the Warp release? A few days before Cloudflare announced Warp on April 1st, Apple released its new version iOS 12.2 with significant changes in its underlying network stack implementation. This made the Warp network unstable thus making the Cloudflare team arrange for workarounds in their networking code, which took more time. Cloudflare adds, “We had a version of the WARP app that (kind of) worked on April 1. But, when we started to invite people from outside of Cloudflare to use it, we quickly realized that the mobile Internet around the world was far more wild and varied than we'd anticipated.” As the internet is made up of diverse network components, the Cloudflare team found it difficult to include all the diversity of mobile carriers, mobile operating systems, and mobile device models in their network. The Cloudflare team also found it testing to include users’ diverse network settings in their network. Warp uses a technology called Anycast to route user traffic to the Cloudflare network, however, it moves the users’ data between entire data centers, which made the Warp functioning complex.  To overcome all these barriers, the Cloudflare team has now changed its approach by focussing more on iOS. The team has also solidified the shared underpinnings of the app to ensure that it would even work with future network stack upgrades. The team has also tested Warp with network-based users to discover as many corner cases as possible. Thus, the Cloudflare team has successfully invented new technologies to keep the session state stable even with multiple mobile networks. Cloudflare introduces Warp Plus - an unlimited version of Warp Along with Warp, the Cloudflare team has also launched Warp Plus, an unlimited version of WARP for a monthly subscription fee. Warp Plus is faster than Warp and uses Cloudflare’s Argo Smart Routing to achieve a higher speed than Warp. The official blog post states, “Routing your traffic over our network often costs us more than if we release it directly to the internet.” To cover these costs, Warp Plus will charge a monthly fee of $4.99/month or less, depending on the user location. The Cloudflare team also added that they will be launching a test tool within the 1.1.1.1 app in a few weeks to make users “see how your device loads a set of popular sites without WARP, with WARP, and with WARP Plus.” Read Also: Cloudflare plans to go public; files S-1 with the SEC  To know more details about Warp Plus, read the technical post by Cloudflare team. Privacy features offered by Warp and Warp Plus The 1.1.1.1 DNS resolver app provides strong privacy protections such as all the debug logs will be kept only long enough to ensure the security of the service. Also, Cloudflare will only retain the limited transaction data for legitimate operational and research purposes.  Warp will not only maintain the 1.1.1.1 DNS protection layers but will also ensure: User’s-identifiable log data will be written to disk The user’s browsing data will not be sold for advertising purposes Warp will not demand any personal information (name, phone number, or email address) to use Warp or Warp Plus Outside editors will regularly regulate Warp’s functioning The Cloudflare team has also notified users that the newly available Warp will have bugs present in them. The blog post also specifies that the most popular bug currently in Warp is due to traffic misroute, which is making the Warp function slower than the speed of non-Warp mobile internet.  Image Source: Cloudflare blog The team has made it easier for users to report bugs as they have to just click on the little bug icon near the top of the screen on the 1.1.1.1 app or shake their phone with the app open and send a bug report to Cloudflare. Visit the Cloudflare blog for more information on Warp and Warp Plus. Facebook will no longer involve third-party fact-checkers to review the political content on their platform GNOME Foundation’s Shotwell photo manager faces a patent infringement lawsuit from Rothschild Patent Imaging A zero-day pre-auth vulnerability is currently being exploited in vBulletin, reports an anonymous researcher