JetBrains' New Kotlin Release Cadence: Date-based, Not Feature-based

There's a lot going on this week in the Kotlin community. JetBrains, the Prague-based maker of the venerable code-centric Java IDE, IntelliJ IDEA, and creator of Kotlin, is hosting an online event focused on the programming language.

Kotlin 1.4 (named, obviously, for the latest release) is a three-day event, underway now (Oct 12-14) that's bringing together Kotlin experts to share insider insights with the global developer community.

Most of the speakers are JetBrains people, but fans of the company's must-read blogs will recognize many of names on the speaker roster, including: Kotlin lead Andrey Breslav; Stanislav Erokhin, Kotlin's head of development; Egor Tolstoy, Kotlin product manager; Roman Elizarov, team Lead in Kotlin language research; and Hadi Hariri, the company's developer advocate. Also speaking: Florina Muntenescu, Android developer advocate at Google and Sébastien Deleuze,  Spring Framework committer at Pivotal.

Still time to log on.

Meanwhile, JetBrains officially announced a new release cadence for Kotlin and the IntelliJ Kotlin plugin. According to JetBrains' Kotlin community manager Alina Dolgikh, users can expect new releases of Kotlin 1.x every six months. These releases will be date-driven, not feature-driven, Dolgikh said in a blog post, which brings the language into what has emerged as something of a standard release cycle for software development tools over the past few years.

"Since Kotlin 1.0 came out in 2016, we've built our release schedule around new key features in the language," Dolgikh said. "This meant that, until big language features were ready, we would not release anything at all. As a consequence, we delivered changes and improvements once a year or sometimes even less frequently. The language has evolved more slowly than we would like, and release dates have been somewhat unpredictable for the users. The main goal of the new date-driven release cadence is to accelerate the delivery of important language updates."

There are three types of Kotlin releases: feature, incremental, and bug-fix. The new cadence will mostly impact the feature releases. Major IDE features will arrive in releases synchronized with IntelliJ IDEA, she said. Dolgikh provides a useful  diagram of the new Kotlin release cadence in her post.

The Kotlin IDE plugin will be released simultaneously with the Kotlin language release, she said, and every time IntelliJ IDEA is released. Why?

"Nowadays, major changes in the Kotlin IDE plugin depend on the IntelliJ Platform more than on the Kotlin compiler," she explained. "So, from now on, new versions of the Kotlin plugin will ship with every release of the IntelliJ Platform, as well as with new versions of Kotlin."

"Kotlin is evolving quickly and we're keen to remove any obstacles preventing the team and the community from achieving their goals," Dolgikh added. "Today we've introduced two major process improvements, and we believe they will speed up the language progress even more."

Kotlin ranked 13th among the most popular languages for professional developers in the StackOverflow Developer Survey 2020, and it cracked the Top 20 in the most recent RedMonk Programming Language Rankings. The Kotlin developer community claims that more than 30,000 members are exchanging "knowledge and support" on Slack and Reddit, and the official Twitter account has more than 90,000 followers.

Created by Prague-based JetBrains, Kotlin is a statically typed language that compiles to both JVM byte code and JavaScript. JetBrains has claimed that Kotlin is more stable at runtime than Java, because it can statically check weak points and supports things like variable type interface, closures, extension functions, and mix-ins. It's also less verbose than Java, which means devs can write less code with a more readable syntax.

JetBrains unveiled Kotlin at the 2011 JVM Language Summit in Santa Clara, CA, and later released it for distribution under the Apache 2 Open Source License.

Posted by John K. Waters on 10/14/2020 at 8:08 AM0 comments


Google v. Oracle Finally in SCOTUS's Hands

The decade-long court battle between Google and Oracle over 37 Java APIs Google used without Oracle's permission in its Android mobile operating system is finally coming to an end. (Really this time…. probably.) Oral arguments before the Supreme Court of the United States (SCOTUS) ended on Friday.

The case has been pending at the High Court for almost two years. It was set originally for oral argument in March, but was rescheduled to this fall when the coronavirus pandemic scrambled the spring argument sessions. (My earlier report includes a summary of the long history of this case, which started when Oracle sued Google in 2010.)

Google is asking the court to reverse a federal circuit court's finding that the structure, sequence, and organization (SSO) of Oracle's Java API package was copyrightable, and also that Google's use of that SSO was not a "fair use" under copyright law.

There's a lot at stake in this case--and not just the $8.8 million in damages Oracle is seeking from Google, which is an Alphabet subsidiary. It has the potential to be one of the most important copyright cases of the decade.

In January, several small companies and tech organizations joined the Mozilla software community in a friend of the court brief, urging the High Court to reverse the federal circuit court's decision.

The brief makes its argument from the perspective of small, medium, and open-source tech organizations, said Abigail Phillips, head of the Mozilla Foundation's legal department, in a blog post. "Mozilla believes that software reimplementation [the process of writing new software to perform certain functions of a legacy product] and the interoperability it facilitates are fundamental to the competition and innovation at the core of a flourishing software development ecosystem."

The list of organizations on the Mozilla amici curiae includes Medium, Cloudera, Creative Commons, Shopify, Etsy, Reddit, the Open Source Initiative, Mapbox, Patreon, the Wikimedia Foundation, and the Software Freedom Conservancy.

"The case has potentially huge implications on copyright protection for software, fair use, and the sanctity of jury verdicts," attorney J. Michael Keyes told ADTmag in an email. "Both parties' counsel were peppered with questions that focused primarily on copyright protection for software, the idea/expression merger, and whether Google's use was 'fair.'"

Keyes is an intellectual property attorney and a partner at the international law firm Dorsey & Whitney. He listened to the argument last week, and offered a rundown:

"Several of the justices' questions seemed skeptical of Google's position and troubled by Google's use of Oracle's software code," Keys said. "Justice Roberts said [that] just because you 'crack the safe' doesn't give you the right to take the money. Justice Alito was worried that if the Court adopted Google's position, it would effectively end copyright protection for software. Justice Sotomayor appeared to express her skepticism of Google's position in pretty blunt terms:  'What gives you the right to use their original work?' Justices Gorsuch and Kagan seemed troubled that other tech giants like Apple and Microsoft have created successful mobile platforms without copying Java—why should the Court give Google a pass?

Oracle's counsel was also met with questions about whether its "declaring code" was copyrightable, Keyes said.

"Surprisingly, there wasn't a big emphasis or focus on the federal circuit's disruption of the jury verdict on fair use," Keyes added. "Justice Alito did seem to question whether the lower court applied the wrong standard, s did Justice Gorsuch. Given that there isn't a single instance of a federal appeals court overturning a jury verdict on fair use, it seemed like this issue would have received more 'air time.'

Bill Frankel, shareholder at Brinks, Gilson & Lione, and chair of the firm's copyright group, also reached out with an email.

"The Justice's grappled with Google's argument that software interfaces are purely functional lines of code and not the kind of creative expression that copyright exists to protect," Frankel said. "Where do you draw the line between copyrightable code and uncopyrightable code? But they deeply probed into the issue of the merger doctrine and whether there has been a merger of the expression in Oracle's declaring code and the functional purposes of that code. Were the Court to adopt Google's argument of merger, the holding presumably would be limited to the Java declaring code at issue, and would leave open, if not uncertain, the scope of copyright protection for APIs in future disputes."

Frankel noted (as did many delighted reporters) the number analogies the Justices came up with during arguments to get their arms around some technical concepts.

"The Justices came up with a number of analogies to suggest the possible functionality of Oracle's APIs," he said, "including mechanical devices like QWERTY keyboards and telephone switchboards and the like. But these analogies seemed inapposite. Chief Justice Roberts' analogy to a menu was closer to the mark. But even a menu divided into appetizers, entrees, and desserts can be written a myriad of ways. At the end of the day, Oracle's code was original, creative, and properly the subject of copyright. The questions to be resolved are what the scope of that copyright should be and how the fair use factors should properly be weighed in the context of software copyrights."

Posted by John K. Waters on 10/14/2020 at 10:12 AM0 comments


Kubernetes Security Provider is AWS Outposts Ready

Kubernetes security solutions provider Alcide achieved a milestone this week. The Israel-based company has earned the AWS Outposts Ready designation, which is part of the Amazon Web Services (AWS) Service Ready Program.

This designation is a big deal for the young company. It recognizes that Alcide's platform has demonstrated successful integration with AWS Outposts deployments. AWS Outposts is a fully managed service that extends AWS infrastructure, AWS services, APIs, and tools to virtually any datacenter, co-location space, or on-premises facility for a consistent hybrid experience.

The Alcide platform has three main modules: Advisor, kAudit, and Runtime. Advisor is a Kubernetes multi-cluster vulnerability scanner that covers rich Kubernetes and Istio security best practices and compliance checks. kAudit automatically identifies anomalous behavior and suspicious activity based on the Kubernetes audit log. It also allows defining custom rules and alerts when certain Kubernetes actions occur. RunTime (ART) protects the container network with a microservices firewall and a threat detection engine. It also tracks processes running in containers themselves.

"We know the importance of helping customers and organizations more easily identify potential security risks in order to take action," said Joshua Burgin, General Manager for the AWS Outposts group, in a statement. "With Alcide Advisor and Alcide ART available to customers on AWS Outposts, we are able to provide a comprehensive view of (a customer's) security posture on their infrastructure, on AWS Outposts, and in AWS Regions, both on premises and in the cloud, for a truly consistent hybrid experience."

I had an opportunity to talk with Gadi Naor, Alcide's CTO and co-founder earlier this year at the beta launch of the company's sKan, a solution designed to provide "end-to-end continuous security guardrails" for Kubernetes deployments.

"We keep hearing from our customers that they want to bring Kubernetes security insights to developers early on," Naor told me at the time. "sKan stretches our main security platform into the comfort zone of the developers who are building applications running on Kubernetes in the most automated and seamless manner, without interrupting their development workflow."

Posted by John K. Waters on 09/17/2020 at 8:35 AM0 comments


Latest BSIMM Report: Security for DevOps and CI/CD Becomes a Priority

Enterprises are adapting their software security efforts to support DevOps as CI/CD instrumentation and operations orchestration have become standard components of organizations' software security initiatives. That's one of the insights from the latest Building Security In Maturity Model (BSIMM ) report from Synopsis.

First published in 2009, the BSIMM is the result of a multiyear study of real-world software security initiatives (SSIs). It was developed to provide a "fact-based" set of best practices for developing and growing an enterprise-wide software security program. That set of practices was the first maturity model for security initiatives created entirely from real-world data. The latest BSIMM is available for download now.

This edition of the BSIMM report was authored by Sammy Migues, principal scientist at Synopsys, and one of the original developers of the BSIMM, John Steven, founding principal of Aedify Security, and Mike Ware
Sr. director of technology at Synopsys.

"The purpose of the BSIMM is to quantify the activities carried out by various kinds of [software security initiatives] across many organizations," the report's authors explain. "Because these initiatives use different methodologies and different terminology, the BSIMM requires a framework that allows us to describe any initiative in a uniform way. Our software security framework (SSF) and activity descriptions provide a common vocabulary for explaining the salient elements of an SSI, thereby allowing us to compare initiatives that use different terms, operate at different scales, exist in different parts of the organizational chart, operate in different vertical markets, or create different work products."

The 11th BSIMM report was the result of the efforts of more than 8.4k security software security professionals, who guide the efforts of almost 500k developers. This edition examines practices across 130 companies in a range of industries, from financial to health care, to identify and help solve their software security challenges. 

The list of emerging trends in this report for DevOps teams includes:

  • Software security efforts are matching pace with software delivery: New activities show a shift toward DevSecOps, including: SM3.4 Integrate software-defined lifecycle governance, AM3.3 Monitor automated asset creation, CMVM3.5 Automate verification of operational infrastructure security 
  • Organizations are "shifting everywhere:" The "shift left" concept has evolved from performing security testing earlier in the development cycle to performing as soon as artifacts are available.
  • Security champions are evolving in firms embracing DevOps and DevSecOps: This is to recruit members from cloud and related roles to apply their expertise as code for organizational benefit.

The BSIMM has proved to be a useful reflection of the current state of software security initiatives in the enterprise, and given how hard it can be to get any organization to communicate honestly about its security practices, something of a miracle. As Gary McGraw, co-author of the original BSIMM, likes to say, it was a science that escaped the test tube to become a de facto standard.

"That's very gratifying, personally," McGraw told me in a 2015 interview, "but the important thing is the emphasis here on real data, and the use of facts in computer security. I think we've finally moved past the witchdoctor days in software security."

Posted by John K. Waters on 09/15/2020 at 8:53 AM0 comments


Our First Podcast Features "Hope Speech" Researcher Ashique KhudaBukhsh

We finally dipped our quarantined toes into the ever-widening podcast ocean last week, because we just didn't have enough to do around here. But seriously, after more than two decades on this beat, it really seemed like the right time to start sharing some of the amazing conversations I get to have on a daily basis with the brilliant and inventive people driving high tech.

We were lucky to have as our first guest Ashique KhudaBukhsh, a project scientist in the School of Computer Science at Carnegie Mellon University's Language Technologies Institute (LTI). I met Ashique in January, when he was still a post-doctoral researcher. I stumbled upon one of his team's published papers, and I called him to talk about what they were up to. That conversation led to two stories in ADTmag's sister publication, Pure AI.

Ashique and his team are engaged in a unique and compelling line of research. He and his colleagues are using artificial intelligence (AI) to analyze online comments in social media and pick out those that defend or are sympathetic to disenfranchised groups. That research led to the development of machine learning classifiers that effectively sort the "hopeful" and "helpful" from the hateful on social media.

The LTI researchers focused initially on finding supporting content about the Rohingya people, who began fleeing Myanmar in 2017 to avoid ethnic cleansing. Ashique explains why that group was chosen, and how his team used the fastText text representation and classification library with polyglot embedding. He also explains how they developed an original strategy they call "active sampling," which used the nearest neighbors in the comment-embedding space to construct a classifier able to detect comments defending the Rohingyas among larger numbers of disparaging and neutral comments.

He also talks about how Facebook, Twitter, YouTube, and other social media platforms, which are employing strategies to identify hate speech and misinformation on their platforms, could use his team's machine learning classifiers to complement that effort.

Ashique is teaching now, but his research continues, and he came to the podcast ready to share his story. It's a great story. You should check it out.

The WatersWorks Podcast will be available soon on iTunes and other podcast apps. But you can listen to it now on the Pure AI website. While you're there, feel free to read the two stories about Ashique's team's work ("Carnegie Mellon Uses AI To Counter Hate Speech with 'Hope Speech'" and "Carnegie Mellon Continues its Research on "Hostility-Diffusing, Peace-Seeking Hope Speech"). They include links to his group's research papers, which you also might want to read.

We'll be podcasting twice a month. I'll let you know when we finish the next one.

Posted by John K. Waters on 09/03/2020 at 7:46 AM0 comments


GitHub's Ruby 2.7 Upgrade Journey

GitHub's upgrade this year to Ruby 2.7 was a massive, months-long undertaking that required a serious investment in engineering resources and time. The team maintaining the popular Microsoft-owned code-hosting-and-collaboration platform recently shared some of the details of that transition, which, among other things, required that they fix more than 11,000 warnings.

"Fixing that many warnings, some of which were coming from external libraries, takes a lot of coordination and teamwork," observed Eileen M. Uchitelle, a staff software engineer at GitHub and core Rails team member, in a blog post. "In order to be successful we needed a solid strategy for sharing the work."

Ruby 2.7 was released last December; the GitHub team completed the upgrade this summer and deployed to production in July. The team completed a major Rails upgrade almost exactly two years ago.

"Upgrading Rails on an application as large and as trafficked as GitHub is no small task," Uchitelle wrote in an earlier post. "It takes careful planning, good organization, and patience. The upgrade started out as kind of a hobby; engineers would work on it when they had free time. There was no dedicated team. As we made progress and gained traction it became not only something we hoped we could do, but a priority."

The team learned a lot from that Rails upgrade, Uchitelle said, and they used that knowledge on the Ruby upgrade, which was a bit more focused undertaking. They set up the application to be dual-bootable in both Ruby 2.6 and Ruby 2.7 by using an environment variable, she said. "This made it easy for us to make backwards compatible changes, merge those to the main branch, and avoid maintaining a long running branch for our upgrade," she said. "It also made it easier for other engineering teams who needed to make changes to get their system running with the new Ruby version."

GitHub was built with Ruby on Rails and launched in February 2008, and it's now one of the largest source code hosting service in the world, with an estimated 40 million users and more than 100 million repositories. The app itself is huge: more than 400,000 lines of code. And it gets 100s of pull requests daily.

One of the key goals of the upgrade was to make it possible to run both Ruby and Rails in deprecation-free mode and not be left behind in the future by a modern upgrade cadence, the code hoster has said. With this release, future versions of Ruby will no longer accept passing an options hash when a method expects keyword arguments. "At GitHub, we're committed to running deprecation-free on both Ruby and Rails to prevent falling behind on future upgrades," Uchitelle said.

Uchitelle left no doubt that the team feels the latest upgrade was worth all this effort, if for the performance improvements alone. " The Ruby Core team is well on their way to fulfilling the promise of Ruby 3.0 being 3x faster, she said. She also pointed to improvements in application boot times in production mode (down from about 90 seconds to about 70 seconds). She also cited a decrease in object allocations, which went from about 780k allocations to about 668k allocations. Object allocations affect available memory, she noted, so it's important to lower these numbers whenever possible.

"For any companies that are wondering if this upgrade is worth it, the answer is: 100%," she said. "Even without the performance improvements, falling behind on Ruby upgrades has drastic negative effects on the stability of your codebase. Upgrading Ruby supports your application health, improves performance, fixes language and framework bugs, and guides the future of the language!"

Both of Uchitelle's blog posts are well worth reading: "Upgrading GitHub to Ruby 2.7," and "Upgrading GitHub from Rails 3.2 to 5.2."

Posted by John K. Waters on 09/01/2020 at 1:42 AM0 comments


Preview of Java Message Service 2.0 over AMQP on Azure Service Bus

Microsoft wants to empower its customers to lift and shift their Java and Spring workloads to Azure, while also helping them to modernize their application stack with best-in-class enterprise messaging in the cloud. Toward that end, Redmond recently announced preview support for Java Message Service (JMS) 2.0 over AMQP in Azure Service Bus premium tier.

The Advanced Message Queuing Protocol (AMQP) is an open standard application layer protocol for passing business messages among apps or organizations. It comprises an efficient wire protocol that separates the network transport from broker architectures and management. AMQP version 1.0 supports a range of broker architectures that may be used to receive, queue, route, and deliver messages, or used peer-to-peer.

Microsoft's Azure Service Bus is a fully managed enterprise integration message broker that can decouple applications and services. It's used to connect applications, devices, and services running in the cloud, and often acts as a messaging backbone for cloud-based apps.

Microsoft program manager Ashish Chhabria announced the support in a blog post.

"The enterprise messaging ecosystem has been largely fragmented compared to the data ecosystem until the recent AMQP 1.0 protocol standardization in 2011 that drove consistent behavior across all enterprise message brokers guaranteed by the protocol implementation," Chhabria wrote. "However, this still did not lead to a standardized API contract, perpetuating the fragmentation in the enterprise messaging space.

"The Java Enterprise community (and by extension, Spring) has made some forward strides with the Java Message Service (JMS 1.1 and 2.0) specification to standardize the API utilized by producer and consumer applications when interacting with an enterprise messaging broker. The Apache QPID community furthered this by its implementation of the JMS API specification over AMQP. QPID-JMS, whether standalone or as part of the Spring JMS package, is the de-facto JMS implementation for most enterprise customers working with a variety of message brokers."

In this preview, Azure Service Bus supports all JMS API contracts, Chhabria said, enabling customers to bring their existing apps to Azure without rewriting them. The list of JMS feature supported today includes:

  • Queues.
  • Topics.
  • Temporary queues.
  • Temporary topics.
  • Subscriptions.
    • Shared durable subscriptions.
    • Shared non-durable subscriptions.
    • Unshared durable subscriptions.
    • Unshared non-durable subscriptions.
  • QueueBrowser.
  • TopicBrowser.
  • Auto-creation of all the above entities (if they don't already exist).
  • Message selectors.
  • Sending messages with delivery delay (scheduled messages).

To connect an existing JMS based application with Azure Service Bus, Chhabria explained, simply add the Azure Service Bus JMS Maven package or the Azure Service Bus starter for Spring boot to the application's pom.xml and add the Azure Service Bus connection string to the configuration parameters.

Posted by John K. Waters on 08/26/2020 at 12:12 PM0 comments


Google's Jib Gaining Traction in the Broader Java Dev Ecosystem

Google introduced the beta version of its open-source Jib tool for containerizing Java applications in July 2018 with relatively little fanfare. Two years later, the tool has put on some serious muscle in the form of new features and plug-ins, and quietly become a developer favorite.

Jib is an open-source Java tool maintained by Google for building Docker images of Java applications. Jib 1.0.0, released to general availability last year, was designed to eliminate the need for deep Docker mastery. It effectively circumvented the need to install Docker, run a Docker daemon, and/or write a Dockerfile.

Jib accomplishes this by separating the Java application into multiple layers for more granular incremental builds. (Traditionally, a Java app is built as a single image layer with the application JAR.) "When you change your code, only your changes are rebuilt, not your entire application," the GitHub page explains. "These layers, by default, are layered on top of a distro-less base image."

"Jib has come a long way since it went GA," wrote Google software engineers Chanseok Oh and Appu Goundan in a blog post, "and now has a sizable community around it. The core Jib team has been working hard to expand the ecosystem, and we're confident that the community will only grow larger."

For example, Google publishes Jib as both a Maven and a Gradle plugin. The GitHub repository of Jib extensions to those plugins--the Jib Extension Framework, published in June-- enables users to easily extend and tailor the Jib plugins behavior. Jib extensions are supported from Jib Maven 2.3.0 and Jib Gradle 2.4.0.

"We think that the extension framework opens up a lot of possibilities, from fine-tuning image layers to containerizing GraalVM native images for fast startup or jlink images for small footprint," Oh and Goundan, said. 

Google published first-party Jib Maven and Gradle extensions to cover the Quarkus framework's "special containerization needs." (It was already possible to direct Quarkus to create an optimized image with the core Jib engine without applying the Jib build plugin.) Using the Jib build plugins enables finer-grained control over how to build and configure an image compared with Quarkus' built-in Jib engine-powered containerization.

Google has also put some effort into supporting the implementation of first-party integration for Spring Boot in Jib. For example, Jib's packaged containerizing-mode now works out of the box for Spring Boot, containerizing the original thin JAR rather than the fat Spring Boot JAR that's unsuitable for containerization.

Finally, Google has made sure that Jib works out of the box with Skaffold File Sync. Skaffold is a command line tool that facilitates continuous development for Kubernetes-native applications. Using the keyword auto, developers can take advantage of remote file synchronization to a running container with zero sync configuration.

Posted by John K. Waters on 08/25/2020 at 10:41 AM0 comments


A Roundup of Red Hat Revelations from KubeCon+CloudNativeCon

So much Red Hat news has been coming out of the KubeCon + CloudNativeCon EU 2020 Virtual event this week that it has been hard to keep up. We reported earlier on the spotlight announcements around its dev tools for Kubernetes. But that was just the tip of the iceberg. The IBM subsidiary has had a busy week!

Here's a roundup of Red Hat's other big revelations from the show:

OpenShift 4.5 Gets Virtualization Platform
Red Hat's enormously popular packaged distribution of the open-source Kubernetes container management and orchestration system gets an upgrade that includes a new virtualization platform.

OpenShift 4.5, announced this week, includes OpenShift Virtualization, a new platform feature that enables IT organizations to bring standard VM-based workloads to Kubernetes, helping eliminate the workflow and development silos that typically exist between traditional and cloud-native application stacks. Virtual machines can now coexist side-by-side with cloud-native services and containers on Kubernetes simultaneously, either for to be rebuilt as a container image or to simply make workflows more efficient, Red Hat said in a statement. OpenShift 4.5 also introduces full-stack automation for VMware vSphere deployments, making it "push-button" easy to deploy OpenShift on top of all currently supported vSphere environments.

Advanced Cluster Management for Kubernetes Goes GA
The advanced cluster management capability, now generally available, was designed to help organizations more effectively scale OpenShift deployments via unified Kubernetes management.

Built specifically for a cloud-native world, the cluster management toolset supports containerized application deployments across multiple clusters, whether an organization is just beginning to explore cloud-native computing or they are running next-generation workloads in production, Red Hat says. Advanced Cluster Management for Kubernetes "meets organizations where they are on their containerization journey," from container proofs-of-concepts to containerized production deployments, with tools to more effectively manage multiple Kubernetes clusters and enforce security policies and governance controls. The toolset also provides a single control plane, which aims to eliminate the fragmented tools that can be required to manage Kubernetes across the hybrid cloud.

New Edge-Computing Support
Red Hat also announced the addition of new capabilities and technologies to its hybrid cloud portfolio designed to support enterprise-grade edge computing, starting with OpenShift.

Red Hat OpenShift now supports three-node clusters, scaling down the size of Kubernetes deployments without compromising on capabilities, and making it better suited for space-constrained edge sites. The Advanced Cluster Management for Kubernetes tools provides management for thousands of edge sites along with core locations via a single, consistent view across the hybrid cloud, which managing scaled out-edge architectures as straightforward as traditional datacenters, Red Hat says.

Red Hat Joins Intuit on Argo Project
The two company's announced that they will be collaborating on Argo CD, a declarative continuous delivery tool for Kubernetes deployments. If it works as planned, the tool will make it easier to manage configurations, definitions, and environments for both Kubernetes itself and the applications it hosts using Git as the source of truth.

Argo CD, which was open sourced by Intuit in January 2018, is also an incubation-level project within the Cloud Native Computing Foundation (CNCF) and is currently deployed in production by many companies, including Electronic Arts, Major League Baseball, Tesla, and Ticketmaster.

Red Hat, a long-time leader in the open-source community, will help to drive the contributor base and engage with a broader open source ecosystem, the company's said. Red Hat also intends to work to integrate Argo's GitOps capabilities into future versions of OpenShift, which would provide a more developer-centric way of controlling Kubernetes infrastructure and applications.

Posted by John K. Waters on 08/20/2020 at 12:37 AM0 comments