Month: October 2022

Article originally posted on InfoQ. Visit InfoQ

Google Cloud recently announced the private preview of Blockchain Node Engine, a managed node-hosting option for Web3 development. Ethereum will be the first blockchain supported.

Designed to help Web3 developers build and deploy on blockchain-based platforms, the new managed service monitors the nodes and restarts them during outages. Amit Zavery, GM/VP engineering at Google, and James Tromans, director of Cloud Web3 at Google, explain:

While self-managed nodes are often difficult to deploy and require constant management, Blockchain Node Engine is a fully managed node-hosting service that can minimize the need for node operations. Web3 companies who require dedicated nodes can relay transactions, deploy smart contracts, and read or write blockchain data with the reliability, performance, and security they expect from Google Cloud compute and network infrastructure.

According to the cloud provider, the main benefits for Web3 organizations will be streamlined provisioning, managed operations, and secure development, including placing nodes behind a Virtual Private Cloud firewall and integrating with Cloud Armor as a protection against DDoS attacks. Zavery and Tromans add:

Today, manually deploying a node is a time-intensive process that involves provisioning a compute instance, installing an Ethereum client (e.g. geth), and waiting for the node to sync with the network. Syncing a full node from the first block (i.e., genesis) can take several days. Google Cloud’s Blockchain Node Engine can make this process faster and easier by allowing developers to deploy a new node with a single operation.

The preview of the node-hosting service on Google Cloud triggered popular debates on Twitter and Reddit, with some users excited about the new option and others questioning if cloud providers will keep the promise of decentralization. User Lazy_Physicist highlights how the announcement can help spreading nodes among different providers:

You know how people say a concerning quantity of Ethereum nodes are run in AWS? Now you can do the same in Google Cloud. Basically Google just streamlined the provisioning of a node that you can run a validator on. Definitely a centralizing force but usually more options are better.

Earlier this year Google announced the Digital Assets Team to support customers building, transacting and deploying on blockchain-based platforms. Solana and Dapper Labs are among the Web3 companies already running on Google Cloud.

Google Cloud is not the only provider working on managed blockchain options: AWS offers Amazon Managed Blockchain, a service to join public networks or manage private networks using Hyperledger Fabric or Ethereum. Microsoft recently retired Azure Blockchain Service and Azure Blockchain Workbench. User AusIV comments:

If you’re running an application that needs scale and reliability you’re way better off with an RPC gateway than a managed node. If you’re trying to support the network by running a node, managed services are definitely not the way to do it. The network has a problem with the percentage of nodes run in a small handful of service providers.

A form is available to join the private preview of Blockchain Node Engine.

Article originally posted on InfoQ. Visit InfoQ

The latest release of Falco adds the ability to handle multiple simultaneous event sources within the same instance, support for selecting which syscalls to capture, a new Kernel Crawler to collect the most recent supported kernel versions, and more.

Up until version 0.33.0, the only way for Falco to consume events from multiple event sources was to deploy multiple instances of Falco, one for each event source. This was especially limiting in the face of Falco’s plugin system, which allowed to go beyond syscall tracing by adding new kind of event sources starting with Falco 0.32.

This is a huge improvement and also brings back support for running syscall and k8s audit logs in the same Falco instance, for all the folks who were interested in doing so.

This new feature introduces a user-facing change in that each Falco instance enables syscall event sources by default, which means you will need to explicitly disable syscalls if you want a plugin-only deployment.

Falco 0.33 also introduces new libsinsp APIs that make it possible to individually select which kernel syscalls and tracepoint events should be collected. This is a step forward in comparison to the previous “simple consumer mode”, which was able to discard events not useful for runtime security purposes. Selecting individual syscalls and events should improve Falco performance and reduces the amount of dropped events.

Related to this, the new release of Falco further attempts to mitigate the issue of dropped events by giving control over the size of the syscall kernel ring-buffer, which is shared memory where drivers buffer events for Falco to consume them at a later point. By tuning the ring-buffer size, you can control how frequently Falco will drop events.

As mentioned, the Kernel Crawler is a new tool that automatically searches for new kernel versions supported for a number of Linux distros. It should make it easier to adopt Falco by simplifying the task of installing kernel modules and eBPF probes for a given kernel version. The Kernel Crawler is used to populate and maintain a database with the build matrix which lists all kernel versions and distros supported by Falco.

The latest Falco release brings many additional new features and improvements, including new drivers for minikube, improved rate limiting for alerts, and new supported syscalls and security rules. Do not miss the official announcement or the changelog 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

GitOps is a new software development paradigm that promises to streamline and fully automate the software deployment process. Instead of relying on IT staff or unwieldy scripts to provision environments, GitOps defines all environments as code, and deploys the environment together with all applications in a consistent and predictable manner. Everything is managed in source control, using tools that are familiar to most developers.

GitOps promises, and delivers, massive productivity benefits for developers. But just like any new technical approach, the challenge is in the details. One of the complex aspects of GitOps is ensuring sufficient visibility of live environments, to ensure that it can be synchronized with a desired configuration. In this article, I’ll explain why observability is so critical to GitOps, and how ArgoCD, a popular GitOps platform, addresses the observability challenge.

What Are Continuous Delivery and Continuous Deployment?

Continuous delivery prepares a software product for production deployment, making it possible to deploy changes at the push of a button. In traditional setups, this was typically done by merging a change to the master branch (this is known as push deployment).

In newer GitOps environments, it is done by committing a change to a central environment repository, triggering a deployment (this is known as pull deployment).

Continuous delivery creates artifacts that can be deployed to production. This is the next step after continuous integration (CI). It prepares a software release that is ready for deployment, and is only waiting for teams to evaluate the change and decide whether to release it.

Continuous deployment takes this one step further, removing the need for a human to evaluate the new version and push the button to release the software. In continuous deployment, every change is automatically tested and if it meets certain predetermined quality criteria, it is automatically deployed to production.

What Is GitOps?

The GitOps model prescribes the use of source control systems, typically based on Git, for application and infrastructure configuration management. Git version control systems act as the single source of truth for GitOps. Based on this single source of truth, GitOps uses declarative configuration to adjust a production environment to match a desired state.

GitOps automatically manages the provisioning of infrastructure and deployment via Git pull requests. It relies on a Git repository containing the system’s complete state to ensure a full audit trail of system state changes.

The GitOps approach emphasizes developer experience, allowing Dev teams to manage infrastructure with familiar processes and tools used for other software development tasks. GitOps offers almost complete flexibility in the choice of tooling.

What Are the Benefits of GitOps?

There are many reasons to start using GitOps. Most of them are related to the ability to deliver software faster, more reliably, and with higher quality. Here are commonly cited GitOps benefits:

• Increased productivity – GitOps enables fully automated continuous deployment with an integrated feedback loop, which reduces deployment time compared to traditional CI/CD pipelines. According to the State of DevOps report by the DORA research group, acquired by Google, the four characteristics of the highest performing DevOps teams are high Deployment Frequency (DF), low Lead Time for Changes (MLT), low Time to Restore Service(s) (MTTR), and low Change Failure Rate (CR). GitOps can directly improve all four of these metrics.
• Improved developer experience – when operating in a Kubernetes cluster, GitOps removes the need to execute kubectl commands. Instead of having to learn and maintain Kubernetes internals, developers can use familiar tools like Git to manage Kubernetes updates and features declaratively, and any operations on the Kubernetes cluster are carried out automatically by the GitOps controller. New developers can ramp up more quickly and become productive in days instead of months, and experienced developers can rely on their knowledge of existing tools.
• Improved stability – in a GitOps workflow, audit logs are automatically created for all changes. This auditability promotes stability, because it is easy to see what changes resulted in production issues. It can also be used for compliance with any necessary  standards such as SOC 2.
• Improved reliability and rollback – Git provides rollback and fork features that allow teams to achieve reliable and repeatable rollbacks. Because Git is the source of truth of the cluster’s configuration, the team has a single source to recover from any production issue. This reduces recovery time from hours to minutes.
• Consistency and standardization – GitOps provides a model for changing infrastructure, applications, and Kubernetes add-ons in a consistent way, providing visibility across the enterprise and ensuring all teams have a consistent end-to-end workflow.
• Security guarantees – Git can sign changes and prove author and origin, and provides strong encryption for tracking and managing changes. This provides a high level of trust over the integrity and security of a Kubernetes cluster.

What Is Observability and How Does it Support GitOps?

Traditional monitoring methods have reached their limits in the context of cloud native application architectures. The focus is shifting from monitoring to observability:

• System monitoring involves detecting a set of known problems by determining the health of the system against predefined metrics. For example, container monitoring aims to answer two questions: what went wrong, and why. Over time, this enables profiling a container to anticipate, predict, and prevent problems before they happen.
• Observability aims to provide an understanding of the state of a system based on three key elements – logs, metrics, and traces. Observability is a characteristic of a system – just like a system can be scalable, reliable, or secure, it can also be observable. In a cloud native environment, observability should be built into applications from day one.

Monitoring and observability are strongly connected. An observable system can be more easily monitored. Monitoring is part of observability, and effective monitoring is a result of an effectively observable system.

Observability provides insights using three main concepts:

1. Logs – provide a record of discrete system events.
2. Metrics – measure and process numerical and statistical data at set time intervals.
3. Traces – provide an event sequence to map the logic path taken.

These three types of insights provide answers to most critical questions, including the current state of the deployment compared to the intended state. They are important for all aspects of the system ranging from intended architecture and configurations to the UI, resources, and behavior.

The Need for Observability in a GitOps Process

The GitOps model emphasizes the ability to simplify complex Kubernetes management tasks. The core concept is the deployment to production via changes to a central Git repository, with changes made to a Kubernetes cluster fully automatically.

To enable a true GitOps process, there is a need for two types of observability:

• Internal observability – the GitOps controller needs to know what is happening in the Kubernetes cluster, for example, in order to compare it with a desired configuration and make adjustments.
• External observability – other systems operating within and outside the cluster need to be aware of workflows automated by the GitOps system. To this end, the GitOps system should publish metrics that cloud native monitoring systems can consume.

How Does Internal Observability Work?

In a GitOps work process, Git is the single source of truth for the system’s intended state, while observability provides a single source of truth for the system’s actual state. Thus, it allows GitOps developers to understand the system’s state in the real world.

If, for example, you intend to have three NGINX pods running in the cluster based on a deployment manifest in your Git repository. The GitOps system will use Kubernetes controllers to determine how many pods are actually running and their current configuration. If it detects the wrong number of instances or any change to pod configuration (this is known as configuration drift), it creates a “diff alert”.

Once the system is aware of a divergence (i.e., a mismatch between the desired and actual number of instances), the diff alerts can trigger the relevant Kubernetes controller. The controller will attempt to synchronize the actual and desired states. Once there are no diff alerts, the system concludes that the actual state matches the desired state, meaning the application is “synchronized”.

The key concept throughout this process is awareness of divergence. You cannot sync or fix the state if you don’t know it is out of sync. Thus, internal observability is critical for enabling GitOps and ensuring the actual state remains up to date.

How Does External Observability Work?

External observability has three elements:

• A monitoring system must be running in the Kubernetes cluster. There are several mature tools that support cloud native environments – a common choice is Prometheus for Kubernetes.
• A GitOps controller making changes to the cluster in accordance with a Git configuration.
• Published metrics generated by the GitOps controller or related systems.

Once these three elements are in place, the monitoring system scrapes metrics from GitOps automation systems in the cluster. This can proactively inform the rest of your ecosystem what changes are taking place. In other words, other systems get a “heads up” that an application is being synchronized, instead of discovering it in retrospect and generating unnecessary alerts.

Let’s see how this works with a popular GitOps project: Argo.

What Is Argo?

Argo is a collection of open source projects that help developers deliver software faster and more securely. Argo is Kubernetes native, making it easy for developers to deploy and publish their own applications.

Argo tools enable continuous deployment with advanced, progressive deployment strategies, allowing developers to define the set of actions required to release a service:

• Argo CD is a GitOps-based continuous deployment tool for Kubernetes. The configuration logic is in Git, and developers can work on their code using the same development, review, and approval workflows they already use in Git-based repositories. Argo CD does not have continuous integration, but integrates with CI systems.
• Argo Rollouts is an incremental delivery controller built for Kubernetes. It enables progressive deployment strategies out of the box, including canary deployments, blue/green deployments, and A/B testing.
• Argo Workflows is a container-native workflow engine for orchestrating parallel tasks on Kubernetes.
• Argo Events is an event-driven workflow automation framework and dependency manager that can manage events from a variety of sources, including Kubernetes resources, Argo workflows, and serverless workloads.

In the context of GitOps, Argo facilitates application deployment and lifecycle management. It makes it possible for developers to operate environments and infrastructure seamlessly, automating deployments, facilitating rollbacks, and enabling easy troubleshooting.

Argo as an Enabling Technology for GitOps

Argo uses Kubernetes manifests to continuously monitor Git repositories, verify commits, proactively fetch changes from repositories, and synchronize them with cluster resources. This synchronous reconciliation process ensures the state of the cluster configuration always matches the state described in Git.

This is the exact definition of GitOps – meaning that Argo allows teams to implement a full GitOps process easily, in their existing Kubernetes clusters, and without changing their existing work processes.

In addition, Argo eliminates the common problem of configuration drift, which occurs when elements in a cluster diverge over time from a desired configuration. These unexpected configuration differences are one of the most common reasons for deployment failures. Argo can automatically revert any configuration drift, or at least show the deployment history of the cluster to identify drift and identify the change that led to it.

Lastly, the Argo project aims to provide a better experience for Kubernetes developers, maintaining a familiar user experience while easily applying advanced deployment strategies. It is implemented as Kubernetes Custom Resource Definitions (CRDs), meaning that it works just like existing Kubernetes objects with extensions that developers can easily learn and use.

To summarize, Argo makes it easier to implement GitOps for the following reasons:

• A more efficient workflow – developers can deploy code using familiar processes and tools.
• Improved reliability and consistency – using an automated agent to ensure that the desired state defined in Git is the same as the state of the cluster.
• Improved productivity – with fully automated CD and no complex setup.
• Reduced deployment complexity – deployment becomes a transparent process that occurs behind the scenes.
• Progressive delivery – in a traditional setup it was very difficult to set up strategies like blue/green or canary deployment, and these are available out of the box in Argo.

Argo CD: GitOps with Observability Built In

Internal Observability in Argo CD

Argo CD receives information about resource status and health via the Kubernetes API Server. When it detects a change between current cluster state and the configuration in Git, it goes through three phases:

• Pre-sync – checking if the change is valid and requires a change to the cluster
• Sync – making a change to the custer
• Post-sync – verifying that the change was made correctly

This process occurs in one or more waves that sweep the entire cluster, looking for changes, and reacting to diffs. The order of resources within a wave is determined by type (namespaces, then Kubernetes resources, then custom resources) and by name.

Within each wave, if any resource is out-of-sync, Argo CD adjusts it and then continues sweeping the cluster. Note that if resources are unhealthy in the first wave, the application may not be able to synchronize successfully.

Argo CD has a delay between each sync wave in order to give other controllers a chance to react to the change. This also prevents Argo CD from assessing resource health too quickly, before it updates to reflect the current object state.

External Observability in Argo CD and Argo Workflows

Argo CD provides a notifications feature, which lets you continuously monitor Argo CD apps and receive alerts about significant changes in the state of an application. It offers a flexible way to set up notifications with templates and triggers – you can define the content of notifications and when Argo CD should send them.

Another part of the Argo project is Argo Workflows, which lets you automate tasks related to CI/CD pipelines in a Kubernetes cluster. Argo Workflows generates several default controller metrics, and lets you define custom metrics to provide information about the state of Workflows.

Argo Workflows generates two types of metrics:

• Controller metrics – provide information about the state of the controller.
• Custom metrics – provide information about the state of your Workflow. You define the custom metrics using the Workflow specifications. The owner of the metric generator is responsible for generating custom metrics.

For example, you can define custom Prometheus metrics and apply them at the Workflow or Template level. These metrics are useful for various cases, including:

• Enforcing thresholds – keep track of your Template or Worklfow’s duration and receive alerts when they exceed your threshold.
• Tracking failures – see how often your Template or Workflow fails across a certain timeframe.
• Metric reporting – set up reports for internal metrics like the model training score and error rate.

Conclusion

GitOps is gaining traction as a mainstream development practice. I showed why observability is an inseparable part of GitOps systems, and described two types of observability:

• Internal observability – required for the GitOps controller to identify configuration drift in the cluster and correct it.
• External observability – required to notify operations staff and other systems of changes made by the GitOps controller.

I briefly showed how both of these are implemented in a popular open source GitOps platform – the Argo project.

GitOps is based on several complex mechanisms, and the best way to wrap your mind around them is to take ArgoCD for a test drive. Check out the official getting started tutorial which shows how to install ArgoCD and deploy a minimal application to a Kubernetes cluster. Try to “mess up” your test cluster and see how Argo picks up the changes and reverts the cluster to your desired configuration.

To go more in depth and understand the ArgoCD sync processes, see the discussion on Sync Phases and Sync Waves in the official documentation.

Article originally posted on InfoQ. Visit InfoQ

Recently Microsoft announced the public preview of a new version of the Computer Vision Image Analysis API, making all visual image features ranging from Optical Character Recognition (OCR) to object detection available through a single endpoint. 

Computer Vision Image Analysis API is part of Microsoft Azure Cognitive Service offering. With the API, customers can extract various visual features from their images. The latest version, 4.0, offers a new feature with OCR, optimized for image scenarios that make OCR easy to use for user interfaces and near real-time experiences. In addition, it now supports 164 languages, including Cyrillic, Arabic, and Hindi languages. The feature recognizes printed and handwritten text in image files (supported formats are .JPEG, .JPG, .PNG, .BMP, and .TIFF).

 
Source: https://azure.microsoft.com/en-us/blog/image-analysis-40-with-new-api-endpoint-and-ocr-model-in-preview/

Next to the OCR feature, also in preview is the “detect people in image” feature. Finally, all the features are available in one API.

Note that Microsoft tests its products with the API. PowerPoint, Designer, Word, Outlook, Edge, and LinkedIn are using Vision APIs to power design suggestions, alt text for accessibility, SEO, document processing, and content moderation.

Besides the OCR and detecting people in image features of Image Analysis, the company also previews another feature: Spatial Analysis. With this feature, developers can create applications that count people in a room, understand dwell times in front of a retail display, and determine wait times in lines.

The upgrade of Computer Vision API is also part of Microsoft’s Responsible AI process and its principles of fairness, inclusiveness, reliability, safety, transparency, privacy and security, and accountability. Other public cloud companies like Google follow the same principle with their responsible AI guidelines.

The company recommends using the new version of the API in the future. Developers can use Image Analysis through a client library SDK by calling the REST API or try out the feature with Vision Studio. 

More details on the Computer Vision API are available on the documentation landing page and FAQs. Price details and availability can be found on the pricing page.

Lastly, Andy Beatman, a senior product marketing manager at Azure AI, revealed what will come next in an Azure blog post:

We will continue to release breakthrough vision AI through this new API over the coming months, including capabilities powered by the Florence foundation model featured in this year’s premiere computer vision conference keynote at CVPR.

Article originally posted on InfoQ. Visit InfoQ

This week’s Java roundup for October 24th, 2022 features news from OpenJDK, JDK 20 release schedule, Build 20-loom+20-34, Spring Integration 6.0-RC1, Spring Tools 4.16.1, GraalVM 22.3, Open Liberty 22.0.0.11 and 22.0.0.12-beta, Eclipse Vert.x 3.9.14, Apache TomEE 8.0.13, JReleaser 1.3.0, Hibernate Search 5.11.11 and 5.10.13, PrimeFaces point releases, JDKMon 17.0.37 and EclipseCon 2022.

OpenJDK

JEP 434, Foreign Function & Memory API (Second Preview), was promoted from its Draft 8293649 to Candidate status this past week. This JEP, under the auspices of Project Panama, evolves: JEP 424, Foreign Function & Memory API (Preview), delivered in JDK 19; JEP 419, Foreign Function & Memory API (Second Incubator), delivered in JDK 18; and JEP 412, Foreign Function & Memory API (Incubator), delivered in JDK 17. It proposes to incorporate refinements based on feedback and to provide a second preview in JDK 20. Updates include: the MemorySegment and MemoryAddress interfaces are now unified, i.e., memory addresses are modeled by zero-length memory segments; and the sealed MemoryLayout interface has been enhanced to facilitate usage with JEP 427, Pattern Matching for switch (Third Preview).

JEP Draft 8295817, Virtual Threads (Second Preview), has been promoted to Submitted status this past week. This JEP, also under the auspices of Project Loom, proposes a second preview from JEP 425, Virtual Threads (Preview), delivered in JDK 19, to allow time for additional feedback and experience for this feature to progress. It is important to note that no changes are within this preview except for a small number of APIs from JEP 425 that were made permanent in JDK 19 and, therefore, not proposed in this second preview.

Similarly, JEP Draft 8296037, Structured Concurrency (Second Incubator), has been promoted to Submitted status. This JEP, also under the auspices of Project Loom, proposes to reincubate this feature from JEP 428, Structured Concurrency (Incubator), delivered in JDK 19, in JDK 20 to allow time for additional feedback and experience. The only change is an updated StructuredTaskScope class to support the inheritance of scoped values by threads created in a task scope. This streamlines the sharing of immutable data across threads.

JDK 20

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

Mark Reinhold, chief architect, Java Platform Group at Oracle, formally announced the release schedule for JDK 20 as follows:

• Rampdown Phase One (fork from main line): December 8, 2022
• Rampdown Phase Two: January 19, 2023
• Initial Release Candidate: February 9, 2023
• Final Release Candidate: February 23, 2023
• General Availability: March 21, 2023

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

Project Loom

Build 20-loom+20-34 of the Project Loom early-access builds was made available to the Java community and is based on Build 20 of JDK 20 early-access builds.

Spring Framework

On the road to Spring Integration 6.0.0, the first release candidate was made available featuring support for: RabbitMQ Streams, Kotlin Coroutines and GraalVM polyglot JavaScript invocations. This version also includes the removal of Spring Data for Apache Geode. More details on this release may be found in the release notes.

Spring Tools 4.16.1 for Eclipse, Visual Studio Code, and Theia has been released featuring early access builds available for Spring Tools 4 on Eclipse 2022-12 milestones. Developers who plan to upgrade from Spring Tools 4.15.3 should follow this migration guide due to a major update in m2e 2.0 that ships with Eclipse 2022-09. Further details on this release may be found in the release notes.

GraalVM

Oracle Labs has released GraalVM 22.3 featuring: support for JDK 19 and jlink; and Native Image monitoring and developer experience updates. As announced at JavaOne, the GraalVM CE Java code will become part of OpenJDK. This is the last feature release of 2022. More details on this release may be found in the release notes and this YouTube video. InfoQ will follow up with a more detailed news story.

Open Liberty

IBM has promoted Open Liberty 22.0.0.11 from its beta release to deliver: support for JDK 19 and distributed security caching so that multiple Liberty servers can share caches by using a JCache provider. This version also addresses CVE-2022-24839, a vulnerability out of Nokogiri (Rubygem), a fork of the now-defunct org.cyberneko.html, that raises a OutOfMemoryError exception when parsing ill-formed HTML markup.

Open Liberty 22.0.0.12-beta has also been released that offers support for six new Jakarta EE 10 specifications: Jakarta Batch 2.1, Jakarta XML Web Services 4.0, Jakarta Server Pages 3.1, Jakarta Standard Tag Library 3.0, Jakarta Messaging 3.1 and Jakarta WebSocket 2.1. There is also support for two updated specifications in the upcoming release of MicroProfile 6.0: JWT Propagation 2.1 and MicroProfile Metrics 5.0.

Eclipse Vert.x

Eclipse Vert.x 3.9.14 has been released that ships with dependency upgrades to GraphQL Java 19.2, Netty 4.1.84.Final, Protocol Buffers Java 3.21.7 and Jackson Databind that addresses CVE-2022-42003, a denial of service vulnerability in Jackson Databind. The 3.9 release train is scheduled to reach end of life by the end of 2022, so developers are encouraged to upgrade to Vert.x 4.x. Further details on this release may be found in the release notes.

Apache Software Foundation

Apache TomEE 8.0.13 has been released featuring: an example on how to work with properties providers; and dependency upgrades that include Jakarta Faces 2.3.18, MyFaces 2.3.10, Hibernate Integration 5.6.9.Final, BatchEE 1.0.2, Tomcat 9.0.68 and SnakeYAML 1.33. More details on this release may be found in the release notes.

JReleaser

Version 1.3.0 of JReleaser, a Java utility that streamlines creating project releases, has been made available featuring: a new WorkflowListener extension that reacts to workflow events; an option to install additional native-image components; and support for deploying JARs and POMs to Maven compatible repositories. Further details on this release may be found in the changelog.

Hibernate

Versions 5.11.11.Final and 5.10.13.Final of Hibernate Search have been released that feature dependency upgrades to Hibernate ORM versions 5.4.33.Final and 5.3.28.Final, respectively. Version 5.10.13 also provides a fix for a ClassCastException being thrown when creating a FullTextSession interface from an EntityManager interface created by Spring Boot 2.4.0+ and Spring Framework 5.3+.

PrimeFaces

PrimeFaces, a provider of open-source UI component libraries, has provided point releases of PrimeFaces 7.0.30, 8.0.22, 10.0.17, 11.0.9 and 12.0.1. New features and enhancements include: implement an IN match mode, i.e., filterMatchMode="in", for the JpaLazyDataModel class; and ensure that the emptyLabel attribute when using the SelectCheckboxMenu class doesn’t display text.

PrimeVue 3.18.0 has also been released that delivers: accessibility enhancements to all menu components; templating support for FileUpload; and a responsive Paginator. More details on this release may be found in the changelog.

JDKMon

Version 17.0.37 of JDKMon, a tool that monitors and updates installed JDKs, has been made available to the Java community this past week. Created by Gerrit Grunwald, principal engineer at Azul, this new version ships with a fix for the detection of GraalVM builds.

EclipseCon

EclipseCon 2022 was held at the Forum am Schlosspark in Ludwigsburg, Germany this past week featuring speakers from the Java community that presented on topics such as Java, The Open Source Way, Cloud Native Technologies and All Things Quality & Security. The conference included the annual Community Day that precedes the conference.

Article originally posted on InfoQ. Visit InfoQ

A new open-source library called Alpa aims to automate distributed training and serving of large deep networks. It proposes a compiler where existing model-parallel strategies are combined and the usage of computing resources is optimized according to the deep network architecture.

The network inference loss scales logarithmically with the number of weight parameters and utilized data during training. This led to an increased effort within the deep learning community to develop larger models. To keep up with the growing network size, the scaling of training compute has also accelerated, doubling approximately every 6 months. As accelerator memory capabilities are limited, the main engineering obstacle is the mapping of network parameters to the existing accelerator devices depending on both cluster properties and communication primitives. In particular, this problem surfaces during training as corresponding gradient tensors are also stored and exchanged via the accelerator memory.

There are two main methods to carry out model-parallel distributed training. In the first strategy, functions (e.g. convolutional layers) constituting the computational graph are divided between the devices (aka inter-operator parallelism), and input mini-batches are split into micro-batches where each micro-batch is executed over the same set of functions (aka pipeline) that are placed on multiple devices (e.g. Device Placement Optimization, GPipe). In the second case, the function parameters are divided (aka intra-operator parallelism) and batch inputs are run over different parts of function parameters that are placed on different devices (e.g. GShard, DeepSpeed-ZeRO).

Both strategies have related trade-offs. For example, inter-operator parallelism offers lower network bandwidth usage which can be a favorable scenario for multi-node training. Intra-operator parallelism, on the other hand, minimizes GPU idle time but suffers from higher data exchange requirements. Therefore, it may be more suitable when GPUs are connected with high-bandwidth connection primitives such as NVIDIA NVLink or AMD xGMI. Current training stations are generally made of multiple GPU units with custom inter-GPU connection modules. However, this is not the case on public cloud, hence a hybrid strategy utilizing both inter- and intra-operator parallelism may significantly improve resource usage.

Deep learning libraries continue to release new APIs assisting placement planning for model parameters and input data such as DTensor for Tensorflow and FSDP for PyTorch. The distribution plans can be manually created (e.g. Megatron-LM), but it is beneficial to have auto-generated plans and training schedules especially for very large networks and for AutoML-designed architectures. Alpha can be considered as an attempt to automate such placement procedures. Its compiler leverages both intra- and inter-function parallelism to output runtime-optimized distributed training strategies depending on the cluster and the deep network structure.

Currently, Alpa is built upon Jax that offers automatic composable transformations (i.e. automatic vectorization, gradient computation, SPMD parallelization, and JIT compilation) for side-effect-free function chains applied to the data.

The results presented in the OSDI 22 paper indicate that Alpa provides competitive training strategies when compared to the manual placement and the previous state-of-the-art methods. Additional info can be obtained from the official Google blog and details related to the design decisions are explained on the official documentation. The project also showcases a proof-of-concept OPT-175B model server.

Article originally posted on InfoQ. Visit InfoQ

Microsoft announced on September 26th that Azure Functions runtime v4 will support running .NET Framework 4.8 functions in an isolated process, allowing the developers to move their legacy .NET functions to the latest runtime. The isolated process execution decouples the function code from the Azure Functions’ host runtime, which in turn allows running different .NET frameworks within a single environment.

Azure Functions now offer four runtime versions for functions written in .NET:

• v1: Runs on .NET Framework 4.8 only. Supported without end-of-life announcement yet. No security updates.
• v2: Runs on .NET Core 2.1. currently not supported for new functions. No security updates.
• v3: Runs on .NET Core 3.1. Supported until December 2022 (linked to .NET 3.1 end-of-life).
• v4: Runs on .NET 6 but supports all versions of .NET (including .NET Framwork 4.8) when running in isolated mode.

Azure Functions runtime v4 introduces isolated process execution. Until v4, function code runs in the same context of the underlying function host process that’s running on the server. It allows for fast performance and startup time, but it ties the developer to the .NET version that the runtime is using.

Isolated process execution launches the function code in a separate console application on the function host server. The function host then invokes the function code using inter-process communication. According to Microsoft’s announced Azure Functions roadmap update, the in-process and isolated process execution models will coexist in v4 runtime until feature and performance parity is achieved. Once a sufficient parity is achieved, the runtime will only allow isolated process execution.

From the technical perspective there are some adjustments that developers have to do to change their existing functions to run in an isolated process, outlined by Microsoft in a quick guide in the documentation. Functions running inside an isolated process can’t use direct trigger and binding references (such as accessing the BrokeredMessage when binding to a Service Bus queue). They can only use simple data types and arrays. The original HTTP context is available as an instance of HttpRequestData class. In the same fashion, writing to a HTTP output is achieved using HttpResponseData class. The Azure Function runtime manages the mapping of those classes to the real HttpContext instance. Developers will also have to update unit tests that cover existing in-process function classes, using fake data for incoming HTTP data. One such approach has been explained by Carlton Upperdine on his blog.

The bindings for functions running in an isolated process are different from the bindings of in-process functions. While the in-process ones leverage the underlying Azure WebJob definitions and bindings, isolated process functions must add the Microsoft.Azure.Functions.Worker.Extensions NuGet packages.

On the other hand, using the isolated process execution will allow developers to build the underlying host pipeline in the Program.cs file, like the way ASP.NET Core applications build their own execution host. It supports building custom middlewares and injecting dependencies in a straightforward fashion. For convenience, there is a ConfigureFunctionsWorkerDefaults method that sets up the host execution pipeline with integrated logging, a default set of binders, adds gRPC support and correctly sets up the JSON serializer for property casing.

Article originally posted on InfoQ. Visit InfoQ

Previously known as AWS Amplify iOS, AWS Amplify for Swift now offers a rewritten API to support Swift async/await and make concurrency code more idiomatic. Additionally, the new release introduces beta support on macOS for a number of AWS features, including Auth, Storage, Geo, and others.

AWS Amplify for Swift is built on top of the AWS SDK for Swift, which is still only a developer preview. While insulating the developer from any changes in the underlying layer, AWS Amplify for Swift aims to provide a higher-level, declarative, and use-case centric API to access a number of AWS services, including Analytics, Authentication, DataStore, Geo, and Storage. Both REST and GraphQL are supported to access remote API data.

As mentioned, the most significant improvement in AWS Amplify for Swift is support for the new concurrency features introduced in Swift 5.5. Previous to version 2.0, AWS Amplify relied on a callback-based model for network and asynchronous operations. The adoption of async/await will make it easier for developers to write concurrent operations. For example, in the case of authentication:

    do {
        let signInResult = try await Amplify.Auth.signIn(username: username,
                                                         password: password)
        if signInResult.isSignedIn {
            print("Sign in succeeded")
        }
    } catch {
        print("Sign in failed (error)")
    }

AWS Amplify 2.0 also provides better support for debugging authentication and upload/download workflows thanks to a number of architectural improvements. Furthermore, AWS engineers took the chance to remove all calls to obsolete APIs, which makes AWS Amplify a warning-free dependency.

AWS Amplify has a modular architecture, where each supported service is implemented through a plugin. This makes the library theoretically able to support alternative services using the same high-level API, although no additional plugins other than those required for AWS are available.

AWS Amplify for Swift is part of a larger collection of tools AWS offers for mobile iOS and Android app development, including a CLI tool used to configure all AWS services used by the app and a number of UI components for React, React Native, Angular, Vue, and Flutter.

Article originally posted on InfoQ. Visit InfoQ

Kubernetes platform offers a variety of storage systems and which option you choose depends on storage characteristics like scalability, performance, and cost. Seán McCord from Sidero Labs spoke on Wednesday at KubeCon CloudNativeCon North America 2022 Conference about the tools the teams can use to evaluate when to use which storage solution.

He said storage is very unlike hosting apps on the cloud. It’s very stateful and not easily or quickly replicated. It also takes big chunks of network and CPU usage to move data to various places. In general, storage eats up a lot of infrastructure resources. The storage options on Kubernetes typically fall into three categories: 

1. Object Stores
2. Block Stores (good for persistent volume (PV) storage; supports standards like iSCSI and NVMEoF), and 
3. Shared File Systems (like NFS which has been used for decades, it’s the least common denominator, easy to setup but locking problem is a challenge)

Other factors like location also matter in deciding the cloud storage solution. If you are using a single cloud vendor in your organization, it’s better to use their system. Another important consideration is whether the storage is managed in-cluster or out-of-cluster.

McCord discussed three characteristics of storage: scalability, performance, and cost.

Scalability: This includes traditional RAID technology with a single controller, highly centralized with limited replication factors. There are also standard SaaS expanders with redundant controllers, still highly centralized using a single SaaS channel, offering limited tiering. Storage clusters: more interesting stuff happening in storage cluster space. These eliminate single point of failure (SPoF), are horizontally scalable, and can be faster as they grow. They also offer dynamic, fine-grained replication and topology awareness.

Performance: In terms of performance, benchmarks are misleading especially in storage. It depends on factors like drives themselves, controllers and interfaces, workload needs, and unexpected scaling effects. He advised the app teams to test as precisely as possible before using any performance metrics for decision-making.

Cost: With hardware components like disks and controllers, the storage infrastructure can get complex very quickly. Maintenance is also an important part because drives will fail often. Growth and scalability can affect the overall cost. The more centralized the infrastructure, the more likely you will reach a limit where you can’t grow anymore. The benefits of horizontal scaling is huge in terms of cost.

McCord also talked about the storage interfaces like iSCSI, NVMEoF, Ceph and NFS. iSCSI is an old standard; it’s slow but used by many vendors. The Linux implementation called OpeniSCSI requires local sockets and local config file to set it up. NVMEoF is a new standard; it’s cleaner, simpler, and faster. Ceph is another storage interface that supports RBD and CephFS file system solutions. NFS is also an option. Shared file system contenders include NFS, Gluster via kadalu, CephFS, MinIo, Linstor which is a popular one and highly pluggable.

He then discussed storage cluster options like OpenEBS family which is based on Amazon’s Elastic Block Store or EBS solution. It’s just a block storage with a limited replication and topology control. He also talked about other solutions like cStor, Jiva, Rancher’s Longhorn, Mayastor, Seaweed FS and Rook/ceph.

McCord summarized his presentation with following K8s storage recommendations:

• If you can delegate someone else to handle the storage, then pay that vendor for it (e.g. PortWorx).
• If you don’t have any special storage requirements, just store it using a solution like Linstor.
• If you need control of scaling, but Ceph is too complicated, use OpenEBS/Mayastor if you need performance over ruggedness and use OpenEBS/cStor if you need ruggedness over performance.
• For best storage features, scaling, and fault tolerance, use Ceph for overall stability. Otherwise use Rook/Ceph.

For more information on this and other sessions, check out the conference’s main website.