Month: September 2022

Article originally posted on InfoQ. Visit InfoQ

Akka, a toolkit for writing concurrent distributed applications based on the actor model, was created thirteen years ago by Jonas Bonér, founder and CEO at Lightbend. The company has recently announced a new Akka license model that has changed from the open-source Apache 2.0 to the source-available Business Source License (BSL) 1.1.

This means the Akka codebase is only free to use for development and on non-production systems. The BSL 1.1 license allows projects to choose another license after a specific period of time that will replace the BSL 1.1 license. Lightbend chose to revert the BSL 1.1 license back to an Apache 2.0 license after three years. Several other open source projects, such as Couchbase, Sentry and MariaBD, have moved to the BSL 1.1 license over the past several years.

The new license affects all companies with a revenue above 25 million dollars who wish to use the latest version of Akka. Current versions may still be used freely, but only critical security updates and patches are released for version 2.6.x under the current Apache 2.0 license until September 2023. Open source projects may contact Lightbend for an Additional Use Grant, which was already granted to the Play Framework.

Lightbend published the prices for production systems per core per year starting at 1,995 USD for the Standard package and 2,995 USD for the Enterprise package. These are standard prices and volume discounts might be applied.

Lightbend still encourages community members to contribute to Akka, which is permitted by the new license.

Bonér gave the following explanation for the new license:

We have decided to change Akka’s license to ensure a healthy balance between all parties, shared responsibility, and, by extension, contribute to Akka’s future development.

In the blog, Bonér details that open source software is created more-and-more by companies instead of individuals, and the companies using open source are more reluctant to pay for the software as they run it themselves. The new license model should spread the maintenance effort and cost as large companies will have to pay Lightbend to use Akka. Lightbend will then use that money to further maintain and evolve Akka.

The license change was heavily discussed by users of the Akka toolkit on social media platforms such as on Twitter, where the different options were discussed. Some of the comments included: companies might pay the license fee or remove Akka from their projects. It was even suggested that one company will buy Lightbend and revert the license back to an open source alternative. Some users debated whether or not an open source community fork will be created in the future.

More information about the licensing change can be found in the Akka License FAQ.

Article originally posted on InfoQ. Visit InfoQ

AWS recently launched support for histories of AWS Glue Crawlers, which allows the interrogation of Crawler executions and associated schema changes for the last 12 months.

AWS Glue is a serverless data-integration service. The service is a suite of AWS integrations built around two major components: its data-cataloging functionality, Glue Data Catalog (based on Apache Hive Metastore), and its extract-transform-load (ETL) pipeline capability, Glue ETL (based on Apache Spark). A Glue Data Catalog, for which the Crawler history feature displays changes, represents a metadata store in the Glue ecosystem. The catalog houses table definitions, which describe the schema of data that exists in a location outside of Glue, such as AWS Simple Storage Service (S3) or Relational Database Service (RDS). The catalog can then be used by Glue ETL as a reference to sources or targets of data for its pipelines, as well as by other AWS analytics services such as AWS Athena. Table definitions can be added manually or created using Crawlers.

Crawlers are jobs that create or update table definitions in a Glue Catalog on their completion. They can be run ad hoc or to a schedule and interrogate the target data source by classifying and grouping the scanned data. Crawlers use built-in classifiers for inferring the data’s schema and format but can be enhanced with user-defined custom classifiers for more complex use cases.

On execution of a Crawler, the history feature shows contextual information such as the duration of the run, the associated computing costs, and the changes effected in the metadata store.

Source: https://aws.amazon.com/es/blogs/big-data/set-up-and-monitor-aws-glue-crawlers-using-the-enhanced-aws-glue-ui-and-crawler-history/

Given that AWS Glue is an amalgamation of synergistic tools, its components are often compared to other solutions rather than the entire offering. The Glue Catalog is often compared to the Apache Hive Metastore, while Glue ETL offers functionality that can be found with AWS’s  Elastic MapReduce service. Yoni Augarten of lakeFS, in a comparison of Glue Catalog and Hive Metastore, recommended Hive for larger organizations heavily invested in the Hadoop ecosystem and Glue Catalog for smaller teams with more straightforward requirements.

The Crawler history feature can be used via the AWS console, programmatically via the ListCrawls Web API, or via any of the official AWS SDKs.

Article originally posted on InfoQ. Visit InfoQ

Amazon is introducing the Visual Conversation Builder for Amazon Lex, a drag and drop interface to visualize and build conversation flows in a no-code environment. The Visual Conversation Builder greatly simplifies bot design.

Amazon Lex is a fully managed artificial intelligence service with advanced natural language models to design, build, test, and deploy conversational interfaces in applications. Amazon Lex provides high-quality speech recognition and language understanding capabilities. The visual builder, allows to build and manage complex conversations with dynamic paths. By adding conditions directly to Lex bot, and managing the conversation path dynamically based on user input and business knowledge, all within a no-code environment.

According to Amazon, no machine learning expertise is necessary to use Amazon Lex. Developers can declaratively specify the conversation flow and Amazon Lex will take care of the speech recognition and natural language understanding functionality. Developers provide some sample utterances in plain English and the different parameters that they would like to collect from their user with the corresponding prompts. The language model gets built automatically.

To create a bot, you will first define the actions performed by the bot. These actions are the intents that need to be fulfilled by the bot. For each intent, you will add sample utterances and slots. Utterances are phrases that invoke the intent. Slots are input data required to fulfill the intent. Lastly, you will provide the business logic necessary to execute the action. An Amazon Lex bot can be created both via Console and REST APIs.

Chatbots are majorly incorporated into messaging applications, websites, mobile applications and other digital devices for interacting as digital assistants through text or text-to-speech functionalities. They offer various benefits, such as improved efficiency of business operations, customer engagement, branding and advertisement, data privacy and compliance, payment processing and automatic lead generation and qualification. Other visual chatbot builder alternatives are IBM Watson Chatbot Builder, Microsoft Bot Framework, Meta Bots for Workplace, among others.

As buying journeys grow more complex, removing friction from the digital experience is essential. Chatbots enhance the buyer and customer experience by providing a channel for site visitors to interact with brands 24/7 without the need for human intervention.

Article originally posted on InfoQ. Visit InfoQ

This week’s Java roundup for September 12th, 2022 features news from JDK 19, JDK 20, updates to Spring Framework, Spring Cloud and Spring Tools, introducing Helidon Níma, MicroProfile Reactive specifications, Quarkus 2.12.2, MicroStream 7.1.0, Project Reactor 2022.0.0-M6, Hibernate Search 6.1.7, JHipster Lite 0.15.1, Piranha Cloud 22.9.0, Kotlin 1.7.20-RC and Apache Tika 1.28.5.

JDK 19

JDK 19 remains in its release candidate phase with the anticipated GA release on September 20, 2022. The release notes include links to documents such as the complete API specification and an annotated API specification comparing the differences between JDK 18 (Build 36) and JDK 19 (Build 36). More details on JDK 19 and predictions on JDK 20 may be found in this InfoQ news story.

JDK 20

Build 15 of the JDK 20 early-access builds was also made available this past week, featuring updates from Build 14 that include fixes to various issues. Further details on this build may be found in the release notes.

For JDK 19 and JDK 20, developers are encouraged to report bugs via the Java Bug Database.

Spring Framework

Versions 6.0.0-M6 and 5.3.23 of Spring Framework have been made available to the Java community. Both releases offer new features, bug fixes and dependency upgrades. A new feature in version 5.3.23 introduces the isSynthesizedAnnotation() method defined in the AnnotationUtils class that will allow developers to migrate away from the deprecated SynthesizedAnnotation interface. Version 6.0.0-M6 defines seven new deprecations and will remove two previously-defined deprecations including the SynthesizedAnnotation interface. Further details on these releases may be found in the release notes for versions 5.3.23 and 6.0.0-M6.

Spring Cloud Dataflow 2.9.6 has been released featuring an updated PostgreSQL driver version 42.2.26 to address CVE-2022-31197, PostgreSQL JDBC Driver SQL Injection in ResultSet.refreshRow() with Malicious Column Names, a vulnerability in which the implementation of the refreshRow() method in the ResultSet class is not properly escaping column names such that a malicious column name that contains a statement terminator, such as a semi-colon, could lead to SQL injection. More details on this release may be found in the release notes.

Version 1.1.0 of Spring Cloud Sleuth OpenTelemetry, an experimental extension to Spring Cloud Sleuth, has been released featuring dependency upgrades to Spring Cloud 2021.0.4 and OpenTelemetry 1.18.0. More details on this release may be found in the release notes.

Spring Tools 4.16.0 has been released featuring: support for Eclipse 2022-09; a new experimental distribution build for Linux on ARM; and an updated M2Eclipse (m2e) 2.0.5. Further details on this release may be found in the change log.

Helidon

Oracle has introduced Helidon Níma, a microservices framework based on virtual threads, that offers a low-overhead, highly concurrent server while maintaining a blocking thread model. Under the auspices of Project Helidon, this new framework is available with the first alpha release of Helidon 4.0.0, but the Java community will have to wait until the end of 2023 for the formal GA release. More details on Helidon Níma may be found in this InfoQ news story.

MicroProfile

On the road to MicroProfile 6.0, scheduled to be released in October 2022, the Reactive Streams Operators 3.0 and Reactive Messaging 3.0 specifications have been made available to the Java community that feature alignment with Jakarta EE 9.1.

Quarkus

Red Hat has released Quarkus 2.12.2.Final featuring dependency upgrades to: SnakeYAML 1.3.2, Hibernate Validator 6.2.5.Final, and JBoss Threads 3.4.3.Final. Further details on this release may be found in the change log.

MicroStream

MicroStream has released version 7.1.0 of their Java object-graph persistence framework featuring: integration with Spring Boot; improvements to their CDI and MicroProfile Config runtime integrations; and improvements to their data channel garbage collection. There was also an open-sourcing all of their connectors to now include: Oracle and SAP HANA Database; Cloud storage (AWS S3, Azure Storage, Google Firestore, Oracle Object Storage); and others (Hazelcast, Kafka, Redis, DynamoDB, Oracle Coherence). More details on this release may be found in the release notes.

Project Reactor

On the road to Project Reactor 2022.0.0, the sixth milestone release, was made available featuring dependency upgrades to the reactor-core 3.5.0-M6 and reactor-netty 1.1.0-M6 artifacts. There was also a realignment to milestone 6 with the reactor-pool 1.0.0-M6, reactor-addons 3.5.0-M6, and reactor-kotlin-extensions 1.2.0-M6 artifacts that remain unchanged.

Hibernate

Hibernate Search 6.1.7.Final has been released that ships with a dependency upgrade to Hibernate ORM 5.6.11.Final; an alignment with Hibernate ORM dependencies in all artifacts that also include the -orm6 artifacts; and bug fixes related to Java modules.

JHipster Lite

Versions 0.15.0 and 0.15.1 of JHipster Lite, a starter project for JHipster, were released featuring numerous enhancements, bug fixes, dependency upgrades and refactoring. Further details on this release may be found in the release notes for versions 0.15.0 and 0.15.1.

Piranha

Piranha 22.9.0 has been released. Dubbed the “Core Profile just landed” edition for September 2022, this new release includes: support for the Jakarta EE Core Profile with a Piranha Core Profile landing zone; and initial support for the Jakarta Transactions and Jakarta Persistence specifications. More details on this release may be found in their documentation and issue tracker.

Kotlin

JetBrains has released Kotlin 1.7.20-RC featuring: support for several new plugins; a preview of the ..< operator for open-ended ranges; enabling the Kotlin/Native memory manager by default; and the addition of inline classes with a generic underlying type, an experimental feature.

Apache Software Foundation

Apache Tika 1.28.5 was released featuring: security fixes; a fix to avoid an infinite loop in bookmark extraction from PDFs; and dependency upgrades. Further details in this release may be found in the changelog. The 1.x release train will reach end-of-life on September 30, 2022.

Article originally posted on InfoQ. Visit InfoQ

Announced at WWDC 2022, Swift 5.7 is now officially available. It includes major improvements to the compiler internals, and many syntax and standard library additions, including String regex, concurrency updates, and more.

While not immediately visible to the programmer, the improvements to Swift’s generics implementation and to automatic reference counting aim to contribute to program performance and correctness. Speaking of generics, work has focused on reimplementing the type checker:

The new implementation fixes many long-standing bugs, mostly related to the handling of complex same-type requirements, such as same-type requirements on a collection’s SubSequence associated type, and code making use of the CaseIterable protocol which defines the requirement Self.Element == Self.

Generics also get a number of improvements at the syntax level. In particular, you can now specify an associated type in a protocol declaration, for example:

protocol Contestant {
    associatedtype Habitat: Territory

    var home: Habitat { get set }
}

struct SeaHabitat : Territory {
    ...
}

struct ConcreteContestant : Contestant {
    var home: SeaHabitat
    ...
}

The Habitat associated type is the primary type for the protocol, i.e., the one that is most commonly specified at the call site. This also opens the possibility of using opaque types with protocols and generics, for example in an object constructor that hides the concrete type of Contestant that is returned:

func currentContestant() -> some Contestant {
    ConcreteContestant(home: SeaHabitat(...))
}

This extension applies to existing protocols, too, allowing you to use Sequence to represent and kind of sequence of strings irrespective of their actual implementation, be it an Array, a Dictionary, and so on.

As mentioned, Swift 5.7 also improves automatic reference counting, making it more predictable and robust to compiler optimizations thanks to new rules to shorten variable lifetimes. In particular, programmers will not need to use withExtendedLifetime() anymore, when evaluating a closure whose correctness depends on a given variable, to prevent the compiler from optimizing it away before the closure returns.

Support for concurrency has matured in Swift 5.7 with better actor isolation, which aims to reduce the chance of data race and makes possible a new strict concurrency checker in Xcode. Additionally, Swift 5.7 also introduces the Async Algorithms package to provide ready-made solutions for a number of AsyncSequence use cases.

One improvement to the language syntax which will be greatly appreciated by all Swift developers, is the new shorthand for optional unwrapping in conditionals, which allows to more succinctly write:

var startDate: Date?
if let startDate {
    let newDate = startDate.addTime(...)
}

As a final mention, Swift 5.7 also bring a number of refinements to Windows support, including a more robust installer, improved support for static libraries, streamlined SDK layout, and the new Swift for Visual Studio Code extension.

Swift 5.7 includes many additional features and extensions than what can be covered here, so make sure you read the official announcement for the full detail.

Article originally posted on InfoQ. Visit InfoQ

Subscribe on:

Apple Podcasts
Google Podcasts
Soundcloud
Spotify
Overcast
Podcast Feed

.
From this page you also have access to our recorded show notes. They all have clickable links that will take you directly to that part of the audio.

Article originally posted on InfoQ. Visit InfoQ

AWS recently introduced IAM Identity Center APIs to create users and groups at scale. Administrators can use these new APIs to manage identities programmatically and gain visibility into users in the Identity Center directory.

Previously known as AWS SSO, IAM Identity Center supports the direct creation and management of users and groups and can be connected to existing sources and providers such as Microsoft Active Directory, Okta Universal Directory, or Azure AD. For audit and reconciliation purposes, the cloud provider introduced new Identity Center directory APIs to retrieve users and their group memberships. Sharanya Ramakrishnan, senior tech product manager at AWS, Bala KP, senior solutions architect at AWS, and Siva Rajamani, enterprise solutions architect at AWS, write:

As your enterprise grows, you may want to automate your administrative tasks to reduce manual effort, save time, and scale efficiently. If you’re a cloud administrator or IT administrator who manages which employees in your organization need access to AWS as part of their job role, or what AWS resources they need so they can develop applications, now you can set up automated workflows that manage this for you.

The ability to manage users and groups at scale has been a long term request from the community. Rowan Udell, principal solutions architect at Stax, tweets on the importance of a centralized service:

Always use AWS SSO/Identity Center. Always. If you have IAM users, get rid of them. If you’re following a guide that says “Create an Administration user”, don’t. Friends don’t let friends use IAM users. All roles. All the time.

Built on the per-account functionalities of AWS IAM and the multi-account features of AWS Organizations, the managed service removes the effort of federating and managing permissions separately for each AWS account. Ramakrishnan, KP, and Rajamani add:

If you use IAM Identity Center with a supported identity provider (IdP) or Microsoft Active Directory (AD), you may want to check if the right users and groups have synced into IAM Identity Center. You can do this manually, but now you can use the new APIs to make the process easier by setting up automated checks that query this information from IAM Identity Center and notify you only when you need to intervene.

IAM Identity Center can manage workforce sign-in and access to all accounts in an AWS Organization, with the possibility to delegate the administration to a member account. In a popular Reddit thread, user matheuscbjr highlights one of the use cases of the new APIs:

I had a demand to generate reports and automations based on users and groups in the old AWS SSO, at that time this was not possible and for that I had to get this information directly from AD via LDAP.

Other users argue instead that IAM Identity Center is not yet SCIM compliant and that it is easier to push users and groups from other identity and access management services.

IAM Identity Center is a free AWS service. The cloud provider updated the IAM Identity Center User Guide and the Identity Store API Reference Guide to provide more information about the new APIs.

Article originally posted on InfoQ. Visit InfoQ

Recently Google added a new integration in Cloud Code with its Compute Engine service (GCE) to make it easier for developers to manage their frequently used virtual machines in the IDE, view details about them, connect to them over SSH, upload application files, and view their logs.

Cloud Code is a set of IDE plugins for well-known Integrated Development Environment (IDE) like VS Code and JetBrains IntelliJ that make it easier to develop applications that use Google Cloud services. With the new integration to Compute Engine, developers have a way of exploring Virtual Machines (VM) in their GCP project and viewing details needed to effectively work with the VM from the IDE.

Developers can install Cloud Code for VS Code or Cloud Code for IntelliJ. Once installed, the developer can find Compute Engine in the activity bar in case of VSCode or a list of IDE tools in case of IntelliJ.

Source: https://cloud.google.com/blog/products/application-development/develop-applications-for-compute-engine-in-your-ide-with-cloud-code

Richard Seroter, a director of outbound marketing at Google, tweeted:

If you’re a developer who added the @googlecloud Code extension to your JetBrains IDE or VS Code, you can now manage your VMs without leaving your editor.

In the IDE, developers can navigate to Cloud Code’s new Compute Engine explorer, select a VM and view the details such as machine type, boot image, and IP address. In addition, they can right-click on a VM for a quick link to the Google Cloud Console, where they can take additional action.

Other actions developers can perform in the IDE are:

• Establish a Secure Shell (SSH) connection from the IDEs terminal into a selected VM and run a troubleshooting diagnostic in case of connectivity issues.
• Upload Code files into VM instance through “Upload File via Secure Copy (SCP).” Once uploaded, Cloud Code provides the option to open a new SSH connection to access the files and work with them on a remote VM instance. 
• Inspect the VM instance logs through the logs viewer in the IDE. The same accounts for when the VM logs are collected in Cloud Logging.

Source: https://cloud.google.com/blog/products/application-development/develop-applications-for-compute-engine-in-your-ide-with-cloud-code

Note that VS Code, for instance, also has a plugin in preview on GitHub for Azure Virtual machines. The plugin allows developers to view, create, delete, start, and stop Azure Virtual Machines. In addition, developers can add an SSH key to existing Azure Virtual Machines.

Lastly, more details are available on the Compute Engine documentation for Visual Studio Code and JetBrains IDEs.

Article originally posted on InfoQ. Visit InfoQ

Amazon is announcing a new built-in TensorFlow algorithm for image classification in Amazon Sagemaker. The supervised learning algorithm supports transfer learning for many pre-trained models available in TensorFlow Hub. It takes an image as input and outputs probability for each of the class labels. These pre-trained models can be fine-tuned using transfer learning even when a large number of training images are not available. It is available through the SageMaker Built-in algorithms as well as through SageMaker JumpStart UI inside SageMaker Studio.

Transfer learning is a term used in machine learning to describe the capacity to use the training data from one model to create another model. A classification layer is added to the TensorFlow hub model once it has been pre-trained, depending on the amount of class labels in your training data. The dense layer, fully linked, 2-norm regularizer, initialized with random weights, and dropout layer make up the classification layer. The dropout rate of the dropout layer and the L2 regularization factor for the dense layer are hyper-parameters used in the model training. The network can then either be fine-tuned using the fresh training data, with the pre-trained model included, or just the top classification layer.

The Amazon SageMaker TensorFlow image classification algorithm is a supervised learning algorithm that supports transfer learning with many pretrained models from the TensorFlow Hub. The image classification algorithm takes an image as input and outputs a probability for each provided class label. Training datasets must consist of images in .jpg, .jpeg, or .png format.

Image classification can be run in two modes: full training and transfer learning. In full training mode, the network is initialized with random weights and trained on user data from scratch. In transfer learning mode, the network is initialized with pre-trained weights and just the top fully connected layer is initialized with random weights. Then, the whole network is fine-tuned with new data. In this mode, training can be achieved even with a smaller dataset. This is because the network is already trained and therefore can be used in cases without sufficient training data.

Deep learning has revolutionized the image classification domain and has achieved great performance. Various deep learning networks such as ResNet, DenseNet, inception, and so on, have been developed to be highly accurate for image classification. At the same time, there have been efforts to collect labeled image data that are essential for training these networks. ImageNet is one such large dataset that has more than 11 million images with about 11,000 categories. Once a network is trained with ImageNet data, it can then be used to generalize with other datasets as well, by simple re-adjustment or fine-tuning. In this transfer learning approach, a network is initialized with weights, which can be later fine-tuned for an image classification task in a different dataset.

Article originally posted on InfoQ. Visit InfoQ

Transcript

Schuster: To continue the language discussion from before. We talked about ahead-of-time compilation and just-in-time compilation. Another dimension of this is what about garbage collection versus everything else, reference counting or manual memory management. Do you see that having an impact on cloud native languages?

Cormack: Yes, it’s an interesting one, because I think really, until Rust came along, everyone was in the basic view that garbage collection was the right thing to do. It was so much easier, solved all the problems, the performance issues were over. There’s a huge amount of engineering gone into garbage collection over the years, because it makes it so much easier for the user. It’s a research topic, and as an engineering topic. Java did a huge amount of work and a lot of other languages did a lot of work on making garbage collection fast. It’s quite a well understood problem in many ways. For most applications, it’s not really an issue. Then Rust came along, and just said, we’re not going to do it like that at all. We’re not going to do garbage collection, we’re going to be different, and came up with, there’s linear types piece, and some escapes from it, like going back to reference counting. I suppose, actually, the Apple ecosystem was the other big holdout, because Swift and Objective-C, we’ll just do reference counting, it’s good enough for everyone. It’s much simpler and more predictable performance than garbage collection, and it matters on the phone. We’re going to introduce that everywhere else as well. That was the other holdout.

Linear types originally came from work on trying to compile Haskell more efficiently and functional programming languages. It was always one of the things that was going to make functional programming much more efficient, because you could tell not about garbage collection, but about reusing the same memory location for a new thing. Because in principle, in functional programming, you declare a new variable for everything because you don’t mutate and splay. The naive implementation is to use a different memory location for each time you change something, which generally is not very efficient. The linearity thing then was all about, can I guarantee that if this thing is only used once, I can use the same memory location because you can’t have a reference to its previous state so I know I can update it. It was really about update in place linearity. It didn’t grow as a miracle in compiling functional languages that was kind of hoped, I think when they wrote the original papers. There’s some really fun papers on linearity. There’s one guy who wrote just totally bonkers papers on it, which are just incredibly funny. I’ll have to dig it out because it was just like, these papers are fun, in the early 2000s, late ’90s.

It didn’t create quite the revolution there, but Rust approached it, took the same thing and tried to solve that problem, like if we know that something is only used once, again, we don’t have to put it on the heap, we can just update in place, keep control. Then, if there’s only one thing that writes to it, then we can have read only copies temporarily, and so on. That was pretty radical as a break from the path that programming languages had been taking. I think it was very radical in terms of people thinking about how to write programs with it initially. It took time before it could even recognize all the cases where there was linearity, and so on. The later implementations were more forgiving, but it does make you think about allocation differently. It’s mental cognitive overhead having to think about allocation at all, in a sense, but also in a sense, if you care about performance, you’ve actually always thought about allocation. If you go to the high performance Java talks that we have at QCon, it’s like don’t allocate. The first rule is hot loop, never do any allocation at all. If there’s no allocation, there’s no garbage collection, so it’s not a problem. It’s always really been the case that people have thought about allocation for things where performance matters. For throw away code or things that are not performance critical, then it’s so convenient.

Zig

The other approach that Zig took more recently has been interesting too, because it came along after Rust, as a related niche. It’s obviously much less well known than Rust. It’s a niche that’s more as a replacement to C than for cases where you would definitely have to use C now. It’s very much designed around interoperability in C. They had a different model where rather than enforcing linearity, you have to specifically pass around an allocator to every type thing that could allocate, which makes it even more visible. You know of a function that allocates memory, because you have to pass it an allocator, but you can do things like do arena allocation where you pass an area of memory, this function allocates in that and afterwards, you clean it all out by releasing the whole arena. Which is actually similar to garbage collection type strategies that a lot of people use anyway. That’s where the arena term came from was garbage collect. That’s a different approach again.

Schuster: The Zig reference counter, do you have to manually free stuff?

Cormack: You have to manually free in Zig, but you can deallocate the whole allocator and create a whole arena. You can do a halfway stage where you can lose track of stuff, because you allocate a gig of memory, everything allocating to this. If it’s failed to free it, doesn’t matter because you’re going to free up the whole thing, for example. You don’t have to keep track of things as effectively, but you have to understand and create that strategy yourself. Normally, the default would be to have a C like thing where you have to free things and it’ll leak if you don’t, which is bad, but it lets you create these strategies yourself by making the allocator first class.

Zig also does other things with like have failing allocators, which most languages don’t work well in the presence of running out of memory, but in Zig, because you passed an allocator, everything you pass an allocator can fail. The allocator has a fail exit case, so everything has to catch failed allocation error. You can also do hard memory bound code effectively, which has actually been really difficult. Code that adapts to the amount of memory that’s available has been something that’s really hard to do. Linux does not encourage that either by just normally having lax allocation anyway and overcommit, as you turn it off. There’s a lot of cases where you’re in a runtime, you really want to know if anything’s failing, rather than just the standard crash, when I run out of memory, being able to catch that.

For the right kind of low level coding, it’s really important. Most code actually isn’t as resilient to running out of memory as it should be. That’s often something you can use to cause denial of service attacks by passing gigantic parameters to things and watching them crash because they run out of memory and things like that. Or if they don’t have backpressure, you can just accumulate memory and not fail correctly and feedback the backpressure and things like that. I think for resilience, explicitness in memory allocation is important as well. I think there’s been a new era since Rust of experimentations in different models, which is really valuable to find out what works, what doesn’t work. What kinds of cases does it matter? What kinds of things can we build if we do something different? How easy is it to learn how to do something like linear types, which was an academic construct for Haskell? Actually, it came from math before that.

Languages That Emulate the Rust Approach

Schuster: It’s definitely a big change from Rust, because I never thought we would have another manually memory managed language or a language that doesn’t use garbage collection, but here it is. Languages that also use the Rust approach, so you mentioned Zig.

Cormack: Zig doesn’t use the Rust approach.

Schuster: Not GC, yes.

Cormack: Yes, it doesn’t have GC. Other than Swift, those are the only three I can think of, that are doing that. I think it takes time to learn how these things work, and I think we might well see more.

C++ and Reference Counting

Schuster: I was wondering, every time I tried to poke fun at C++ developers for having a manually managed system, they always tell me, no, in modern C++, everything’s reference counted, smart pointers.

Cormack: Yes. It’s not enforced. It is used mainly as a reference counted language. C++ has been very adaptable from that point of view. If you see it as a way of adding new idioms and an evolving language without really removing everything, then, yes, you can definitely argue it’s in the reference counted piece. I don’t know if they’ll go as far as linearity and things as well. Some people will call reference counting garbage collection. It’s just a very simple form of garbage collection that doesn’t work well with cycles, but is incredibly efficient to implement. Reference counting is very old. I think the original garbage collection implementations in the ’60s were reference counting, because it’s so simple. You can argue that that’s more a continuation of GC. Even Rust has support for reference counting for all the use cases that linearity doesn’t work.

Schuster: It’s interesting with Rust, you get the type system to help you to make sure that you have the cheap reference counting operations if you don’t share it across thread boundaries, for instance, which is exciting. I find that you can use reference counting, but you don’t pay the atomic operation overhead.

Cormack: Yes.

Performance, Scalability, Cache Locality, and Dealing with Cycles

Schuster: We can talk more about languages, but we have here performance, scalability, cache locality, dealing with cycles. Yes.

Cormack: I do find it just interesting there are these tradeoffs that come back. It’s always been the case that the systems programmers, particularly the C programmers just said that garbage collection would never work for x use case. For many x use cases, that’s not been true. There are some use cases in kernel. Even then with unikernels, we have OCaml and things using garbage collection in the kernel. It’s more niche when you go down to that. As I said, for people who’re doing performance, they understand how the deallocations/allocations are taking place, regardless of what the runtime does, and they’re still doing the same things. Implicitly, you can do these things by hand, and not allocate and know that things are going to be allocated on the stack in your language and all the rest of it. Tracing and decompiling and seeing what’s going on in the runtime, and you can always build something equivalent by just not using these features.

Memory Overhead Cost of GC versus Reference Counting

Schuster: The one question I always have, and I haven’t found any good research on this, maybe that’s out there is, what is the memory overhead cost of GC versus reference counting? The answer isn’t that simple, because more than reference counting is becoming a bit lazy as well, so you don’t immediately deallocate stuff. There might still be some overhead.

Cormack: The worst case for garbage collection is, theoretically, twice as much on a really poor implementation of copying, but that’s not how it works. It’s invariably less than that, but it does depend a lot on your workload. Most GC has arenas for things that last for different amounts of time, most of the stuff is deallocated very quickly after it’s allocated. It doesn’t hang around for very long, it’s quite efficiently removed. It’s almost like stuck lifetime, and then you get a little bit longer, maybe it crosses a function boundary, and then gets deallocated. Then you’ve got stuff that lasts the lifetime of your program probably, and often stays, but maybe it changes slowly or something. It is very application dependent. There is a bunch of research on memory usage. I suspect, the memory usage has probably gone down since the research was done, the GCs have just continued to get more efficient in terms of things like that. It’s probably worth, and your application might be different. Few people rewrite things and after compare as well.

Schuster: That’s the problem. Yes.

The Cognitive Load of Memory Management

Cognitive load of memory management, doing it by hand, try to debug why it’s not working right or quickly, and frontload the cognitive load [inaudible 00:19:31].

Cormack: I think it’s like the real backlash we’ve seen against dynamic typing for the last few years. We are going to, ahead-of-time, let’s put things in the type system, let’s have more of those guarantees upfront period, again. From having a, let’s do things at runtime period, that was the dynamic language boom, the JIT compiler boom, and now we’ve gone back to the ahead-of-time old world in a sense, how things used to be because predictability is important. Predictability is a really interesting thing. If you want predictable latency rather than the lowest latency and so on, if you want to make sure that your largest latency is low, then doing things ahead of time and not doing GC just removes those tail latencies for when things can go wrong. For those types of applications, it makes a lot of sense. The developer cognitive load and debug load is interesting. I think, as you said, that one of the interesting things about linear types was it went into the type system, not somewhere else. You could use familiar tools, to some extent. It still behaved differently, and extending the type system does aid cognitive load. That’s what a lot of people say about things like Idris that tries to do a lot more in the type system. It does become very different. It’s definitely that ahead of time. Once you’ve got it right, you know it’s done, kind of thing, rather than having to then profile it and see if it worked.

Extended Berkeley Packet Filter (eBPF)

Schuster: Can we switch gears from languages a bit lower level? A few years ago at QCon London, you gave a talk called eBPF is the Amazon Lambda of the kernel. Did that work out?

Cormack: It’s interesting. I think there’s a lot going on. I think, actually, that community is still just growing and expanding. There’s actually been a lot of new things. There was an eBPF foundation set up in the Linux Foundation, Microsoft is implementing it for Windows. There’s big things. Linux stuff takes a long time, because a lot of people use quite old Linux kernels like Red Hat LTS and things. It’s only recently that the pieces of eBPF other than the profiling pieces have become really widely available. It’s still not the easiest ecosystem to program, because it’s low level and weird, and most people are programming in C still. It’s still on the growing stage. I’m seeing a lot more people interested in adopting it. A lot of companies doing things with it. It’s got really strong niches around things like networking. The first thing that happened with it was the performance stuff that was done mainly at Netflix, originally, then a lot of networking, because it turned out that manipulating packets was a really good use case. For now, things like security, it’s growing, making more complex security decisions about whether something should be allowed, which needs more context. Yes, it’s getting there. It’s still growing, taking time, expanding the tooling and so on, on that adoption curve.

eBPF in the Future

Schuster: What are the things that are being added in the future or that might expand it even more? What can we expect nowadays with eBPF, what things are stable?

Cormack: The handling of kernel interfaces is getting much easier. There was a whole revision of how the compiler works to make it easier to not have to compile a separate eBPF binary for every kernel version you wanted to run in, and to link it up at load time. That just made it annoying to just distribute code except in source code. I think that’ll make it remove a lot of barriers, because it was just annoying to just distribute binaries to people that would work. That’s probably the biggest piece is that ease of use piece on distribution.

eBPF vs. Sidecars

Schuster: I don’t know if you have an opinion on this. There was a discussion recently that was pitching eBPF versus sidecars, from an efficiency point of view, capability point of view. Is there anything to say there?

Cormack: I think that a lot of people are now using a combination, basically, eBPF if you can, because it’s much faster, and running stuff in the sidecar if you can, because it’s difficult. You haven’t written the code yet, or it’s a more complicated thing, or the kinds of manipulations that you want to do are more complicated. The other things with the networking side that hasn’t quite taken off yet is the use of in kernel, TLS, which was going to make it easier. Because if the kernel does the encryption, then it means that the eBPF code can access the data before it’s encrypted, so it can inspect more to make processing decisions before the encryption happens potentially. There’s a whole lot of optimizations you can do. If two connections are actually on the same host, you just loop them back through localhost, don’t bother to encrypt and decrypt, or don’t packetize them, and don’t run TCP over a local connection and things like that as well, which make for a lot of efficiency.

The sidecar model is simpler. The idea that you can take some bit of code and then control how it handles the outside world completely, in some code that you don’t have to deploy at the same time with that code is really powerful. I think there’s a lot more we could do there. With Docker Desktop, we manipulate a lot of the network traffic that’s coming out of containers before it reaches the host, because we’re doing it across a VM boundary, so we get that opportunity. If you could do it for a local process to effectively containerize it without it realizing, route its traffic differently, make security decisions locally, all those things as a control wrapper around some application you want to run, it’s an extension of the container model, in that sense.

Sidecars were always pitched originally as being a replacement for dynamically linked libraries. They’re dynamically linked bits of program that manipulate the outputs, which are generally like network streams and so on. If you can do this even more generally, like you can take all of the state that the application deals with, with Linux, and manipulate all of that and control all of that and monitor all of that, then that’s a really powerful way of thinking about containerization in that sense, and virtualizing, and just modifying how things work.

One of the things that Cilium does is it intercepts DNS requests using eBPF for access control. If you’re only supposed to access domains@google.com, it intercepts the DNS request, looks at the response, if you’re asking for a google.com address, and it comes back with an IP address that lets you call towards that IP address. If you ask for qconconferences.com DNS lookup, it’ll just come back, and it won’t return you the IP address, so your application can’t actually do anything. Then it configures the allowed and not allowed routes that it’s going to let you have based on those DNS requests. That model of getting more semantics around how the operating system can control you, and making it totally transparent without you having to have a DNS library or work out which DNS server that it’s even talking to, you know that an application you have control of can only resolve names through DNS. The hard coded IPs, you can just block them anyway, because it hasn’t done a DNS request. It’s a really interesting way of adding that semantic control around what things can do.

Things like access control and enforcing TLS are some of the things that sidecars were initially asked to do, because getting application developers to build in all their authorization access control framework that your organization wants is really hard, and linking to a shared library didn’t work once people started using multiple different languages. We don’t have that common linkage yet. Although, again, WebAssembly is looking at common library type things that could be multi-language, but we’re not really quite there yet.

The Security of eBPF Code

Schuster: I saw there was some concerns about the security of eBPF code or injecting its code that’s essentially running in the kernel. What’s the current thinking about that?

Cormack: I know we talked about sandboxing before. It needs to run in a sandbox. How good is the sandbox? The security issues in eBPF have been around changes that have been made to extend it when the model hasn’t been. The changes in the model generally have caused issues. Linux decided not to formally verify eBPF, but I think it’s an interesting research target. Most of the issues have been found so far, quite quickly. It wasn’t introduced as a best practice way that we have of designing sandboxes. It was a little bit more ad hoc and there’s been a number of issues. Particularly as the allowed constructor got more complicated, because initially it was really simple, and it was based on the original BPF for networking, but more features were added. Those features turned out to have security issues. It’s good to plan how you’re going to implement sandboxes because they will break and they do cause issues, and it’s just good to get those right.

Interesting Projects in the CNCF

Schuster: Justin you’re involved with the CNCF.

Cormack: Yes.

Schuster: Are there any projects that you find particularly interesting there that people should look into them?

Cormack: We have a lot of projects now. The thing we’ve done really over the last year or so is to really open up the sandbox to enormous number of experiments and projects that may or may not make it. I’ve lost track. I think there are 40 odd projects in the incubating and graduated kind of mature projects, and there are a lot of sandbox projects. There’s a core of projects connected directly to enhancing Kubernetes, and extending it in different ways. There’s a lot of interesting ones there. We’ve got things like Dapper that just came in recently, which is what Microsoft’s using for their new container runtime on Azure. It’s been open sourced, but it’s now a CNCF project. We’ve got things like Crossplane, which lets you run services as if they were native Kubernetes objects. I think it’s really interesting.

In the sandbox, we’ve got all sorts of things. We’ve got Wasm runtimes, confidential computing, key management encryption, lots of projects in Rust. We’ve got Wasm for Kubernetes from Microsoft. We’ve got all sorts of things. It’s a big experiment in things that may or may not work out, and we’re giving them the space to explore. We’ve given people visibility of these are things that people want to collaborate across companies, across their organizations, and they want to share them with other people. They don’t want to own the whole direction of the project, they want to make it open. We’re seeing projects go in quite early stages to there sometimes. We usually require that they’ve been around for a little bit, but if people are already starting to work together, and seeing multiple people coming in, then that’s a good point at which we allow projects in. It’s really a lot of fun things, a lot of experiments.

I think there’s a huge number of projects around different aspects of edge computing, and that’s where a lot of the Wasm things fall in, and that kind of thing. No one knows quite what the shape of that stuff is going to look like. There’s a lot of different approaches. We have several different projects extending Kubernetes to the edge in different architectures, in different ways. That’s great, because we don’t know what the shape of things is going to look like. We have people that are really excited about WebAssembly and the kinds of applications people might build with that. I think we’re still exploring the shape of what that will look like, and doing it in the open. We’re the big community of people who can really drive projects to success.

Was The Unikernel Killed by Docker and Containers?

Schuster: Did Docker and containers kill the unikernel, or is the unikernel still around?

Cormack: There’s a bunch of people still working on unikernels. They don’t go away because the ideas are really exciting and they’re much easier to implement than they used to be. I think the commercial models around unikernels have been really difficult, how to get mass adoption rather than niche adoption. It’s hard. What are you going to offer developers that’s radically different? I think that some of the things are related to pieces around WebAssembly and lightweight applications at the edge that people are starting to get interested in again. I think a lot of the ideas will come back again over the next few years as people explore those areas in more detail. Because smaller, lightweight and customized and specialized applications for single purposes for smaller, less resource hungry areas is an area that people are really interested in again now. We start building things that are big again, and we’ve got these reasons for thinking about small again. That’s where the interest still comes up a lot, still talk to people about things. People are still working on it, but it’s more hidden.

Schuster: It’s definitely exciting, maybe long-term.

See more presentations with transcripts