Or try one of the following: 詹姆斯.com, adult swim, Afterdawn, Ajaxian, Andy Budd, Ask a Ninja, AtomEnabled.org, BBC News, BBC Arabic, BBC China, BBC Russia, Brent Simmons, Channel Frederator, CNN, Digg, Diggnation, Flickr, Google News, Google Video, Harvard Law, Hebrew Language, InfoWorld, iTunes, Japanese Language, Korean Language, mir.aculo.us, Movie Trailers, Newspond, Nick Bradbury, OK/Cancel, OS News, Phil Ringnalda, Photoshop Videocast, reddit, Romanian Language, Russian Language, Ryan Parman, Traditional Chinese Language, Technorati, Tim Bray, TUAW, TVgasm, UNEASYsilence, Web 2.0 Show, Windows Vista Blog, XKCD, Yahoo! News, You Tube, Zeldman
Google’s generative AI Toolbox for Databases to help connect agents with databases | InfoWorld
Technology insight for the enterpriseGoogle’s generative AI Toolbox for Databases to help connect agents with databases 10 Feb 2025, 9:33 am
Google’s cloud computing division, Google Cloud, has added a new generative AI Toolbox for Databases to help enterprise developers connect agent-based generative AI applications to its databases.
The new Toolbox, which is currently in public beta, is an open-source server designed to streamline the creation, deployment, and management of AI agents capable of querying databases.
At launch, Toolbox will support connectivity to self-managed PostgreSQL, and MySQL, as well as managed databases including AlloyDB, Spanner, and Cloud SQL for Postgres, Cloud SQL for MySQL, and Cloud SQL for SQL Server.
Google Cloud said that it was open to contributions from databases other than its proprietary ones.
What is it and how does it work?
The new Gen AI Toolbox for Databases was developed to improve how generative AI tools interact with data and to address common challenges in generative AI tool management.
Some of the common challenges that developers face include scaling tool management, complex database connections, inflexible tool updates, limited workflow observability, and security vulnerabilities.
“Current approaches to tool integration often require extensive, repetitive code and modifications across multiple locations for each tool. This complexity hinders consistency, especially when tools are shared across multiple agents or services,” company executives wrote in a blog post.
In contrast, the new Toolbox can solve these common challenges by acting as an intermediary between the application’s orchestration layer and data sources or databases, the executives explained.
The Toolbox is made of two components — a server specifying the tools for application use, and a client interacting with this server to load these tools onto orchestration frameworks.
“These components centralize tool deployment and updates, incorporating built-in production best practices to enhance performance, security, and simplify deployments,” the executives wrote.
New Toolbox compatible with LangChain
The new Toolbox is also compatible with LangChain — a modular framework for Python and JavaScript that simplifies the development of generative AI-based applications and is also popular among developers.
“Together with Toolbox, LangGraph can leverage large language models (LLMs) like Gemini on Vertex AI to build powerful agentic workflows,” the executives wrote.
What that essentially means is that LangGraph extends LangChain’s capabilities by providing a framework for building multi-actor or agentic applications underpinned by LLMs.
Google Cloud also said that LangGraph’s support for cycles, state management, and coordination enables the development of complex and dynamic AI agents.
Additionally, LangGraph will provide a low-level agent framework for managing how agent calls tools and how their responses are integrated. However, Google Cloud has warned that the gen AI Toolbox for Databases is currently in beta, and may see breaking changes until the first stable release.
When LLMs become influencers 10 Feb 2025, 9:00 am
On Sunday people tuned in to watch the Super Bowl—and lots and lots of ads. Online, however, it’s increasingly the case that AI agents will see and interact with ads. Humans won’t. That’s the insight Grab’s regional marketing director Ken Mandel offers: “If an AI chooses your Coke order, not a human, then why bid for impressions on Instagram?” Summing up, he argues, “In a world where agents (not humans) interact with brands, the game shifts from advertising to AI influence and optimization.”
This promises to shake up the advertising industry, but something very similar is happening with developer tools. In developer relations, for example, it used to be critical for software companies to have developer advocates on Stack Overflow or Reddit, answering questions, writing tutorials, etc. But if developers increasingly turn to coding assistants like GitHub Copilot to get answers and guidance, then it becomes essential to influence how large language models (LLMs) “think” about one’s product. Yet how to do that isn’t clear at all.
In short, we know that we need to get smarter about how we influence the machines, but how?
Who trains the trainers?
Our ability to influence LLMs is seriously circumscribed. Perhaps if you’re the owner of the LLM and associated tool, you can exert outsized influence on its output. For example, AWS should be able to train Amazon Q to answer questions, etc., related to AWS services. There’s an open question as to whether Q would be “biased” toward AWS services, but that’s almost a secondary concern. Maybe it steers a developer toward Amazon ElastiCache and away from Redis, simply by virtue of having more and better documentation and information to offer a developer. The primary concern is ensuring these tools have enough good training data so they don’t lead developers astray.
For example, in my role running developer relations for MongoDB, we’ve worked with AWS and others to train their LLMs with code samples, documentation, etc. What we haven’t done (and can’t do) is ensure that the LLMs generate correct responses. If a Stack Overflow Q&A has 10 bad examples and three good examples of how to shard in MongoDB, how can we be certain a developer asking GitHub Copilot or another tool for guidance gets informed by the three positive examples? The LLMs have trained on all sorts of good and bad data from the public Internet, so it’s a bit of a crapshoot as to whether a developer will get good advice from a given tool.
Microsoft’s Victor Dibia delves into this, suggesting, “As developers rely more on codegen models, we need to also consider how well does a codegen model assist with a specific library/framework/tool.” At MongoDB, we regularly evaluate how well the different LLMs address a range of topics so that we can gauge their relative efficacy and work with the different LLM vendors to try to improve performance. But it’s still an opaque exercise without clarity on how to ensure the different LLMs give developers correct guidance. There’s no shortage of advice on how to train LLMs, but it’s all for LLMs that you own. If you’re the development team behind Apache Iceberg, for example, how do you ensure that OpenAI is trained on the best possible data so that developers using Iceberg have a great experience? As of today, you can’t, which is a problem. There’s no way to ensure developers asking questions (or expecting code completion) from third-party LLMs will get good answers.
Holding models accountable
Well, one option is simply to publish benchmarks. The LLM vendors will ultimately have to improve their output or developers will turn to other tools that consistently yield better results. If you’re an open source project, commercial vendor, or someone else that increasingly relies on LLMs as knowledge intermediaries, you should regularly publish results that showcase those LLMs that do well and those that don’t. Benchmarking can help move the industry forward. By extension, if you’re a developer who increasingly relies on coding assistants like GitHub Copilot or Amazon Q, be vocal about your experiences, both positive and negative. There’s a massive race among LLM providers to earn your trust. Name and shame the tools that hurt your ability to build great software.
Of course, it’s also possible that we’ll start to see projects and companies pay to influence code advice: SEO for coding assistants, as I’ve highlighted before. I’ve not seen that happening yet, but the trend Mandel sees in advertising could very easily find its way to software development. He says, “Imagine, Google Ads morphs into ‘Google AI Preference Bidding’—[and] brands bid to be the preferred suggestion when AI agents shop for users.” Could we see something similar happening with AI assistants? Sure. But I’m hopeful that benchmarking and vocal feedback will be a more effective way to ensure developers get the best possible guidance.
Are database administrators doomed? 10 Feb 2025, 9:00 am
Database administration has always been something of a well kept secret. Even within the wider domain of information technology, database administration is one of those areas of expertise that often goes overlooked by aspiring STEM students and tech-savvy job seekers.
Nevertheless, it’s an area for which expertise is in consistently high demand. And at a time when the futures of many professions have been darkened by the pall of AI-fueled uncertainty, database administration remains ripe with opportunity. For both those already in the field and those looking to enter it, I’m confident that there will be no shortage of demand for skilled professionals for the foreseeable future.
With that being said, it would be disingenuous of me to suggest it’s nothing but smooth sailing ahead for the field and its practitioners—especially for those already bearing the title of database administrator (DBA). As is the case for practically every profession today, the flurry of advancements happening in AI have serious implications for the DBAs of the world. In fact, I’d say there’s a very good chance that the title of DBA itself will soon become scarce among corporate org charts.
Still, the future is far from doom and gloom for DBAs. Provided they’re willing and able to adapt, the professionals currently in these roles needn’t fear obsolescence. On the contrary, I believe that today’s DBAs will likely see their professional prospects expand and their careers grow as a result of the changes to come over the next few years.
Seeking job security? Go where the data is
Before delving into the specifics of those changes, though, it would be negligent to not at least acknowledge the enormous changes that are taking place in and around data itself. In relatively little time, we’ve seen an explosion in the volume, variety, and value of data collected, stored, and analyzed by the average corporation. What was once the exclusive domain of developers and accountants is now essential to virtually every aspect of business decision-making. Whether you’re in marketing, PR, or human resources, making a decision of any material significance without the guidance of data has become something of a cardinal sin. Moving forward, the rate of growth will only accelerate as more organizations find more uses for more data across more parts of their operations.
If for no other reason than this, I think it’s safe to assume that database administrators will remain valuable assets to corporations for quite some time. Add to that the increasingly significant role of AI and the growing interest in proprietary solutions and I feel quite confident that the de facto guardians of enterprise data will have a place in the corporate world for some time to come.
Devops: A blueprint for the future of database administration
With that being said, the actual title of “database administrator” may soon become a thing of the past. If for no other reason then it will no longer adequately reflect the totality of these professionals’ roles and responsibilities. At the same time, the skills of today’s DBAs will continue to be in high demand. But, rather than being cast away, they will be recast as one facet of the role and one slice of the core responsibilities of this new brand of database professionals.
While it’s hard to know with absolute certainty exactly what shape such a role will take, I think we can look to other recent developments in the professional landscape—like that of devops—for clues as to what it might look like.
Just like devops blended developer and operations skills, database expertise will soon focus more on how infrastructural decisions will affect the way data operates further down the chain. The new duties and decision-making responsibilities will include things like determining how architecture will affect data interpretation and how to make data processes more efficient through changes at the infrastructural level.
Rather than looking at performance reports and seeking to fix the loudest, most glaring inefficiencies (like plucking the tallest, most unsightly weeds from a densely packed garden), tomorrow’s database professionals will approach optimization with the entire data pipeline in mind (considering the conditions of the soil, the relative positioning of each plant, and which crops are most essential to the community it feeds).
Big picture thinking will be key for tomorrow’s DBAs
As a result, it will be increasingly important for DBAs to incorporate new skills into their professional repertoires—especially those traditionally associated with data analytics and data science—which will allow them to more readily see data in context and recognize the bigger picture of database operations.
This “full-pipeline view”—from the generation of operational data as transactions take place, all the way to analysis and re-use—is something that many of the largest enterprises have already begun to take into consideration. Now, small and mid-sized businesses will need to do the same. And these organizations will undoubtedly need help making the right choices on what they use to support their applications and how they can make it easier to utilize and interpret their data over time. This will require a blend of knowledge and abilities, including how to use architecture more effectively and how to deliver the right outcomes using the right frameworks.
To help illustrate this paradigmatic shift, consider how today’s DBAs might look at query performance. Traditionally, DBAs would focus on the reports and queries that took the longest to execute and then work to optimize them. This could then lead to better performance for the slowest of queries.
However this does not take into account how often those queries get performed. That slow query might run just once a week, or even once a month—in which case, while improving it would certainly be a positive, the overall benefit to one’s operations would be small. On the other hand, optimizing queries that are used daily—even those that are generally considered to be “fine” or acceptable—can have far greater impact, despite the actual improvement being relatively marginal.
In order to reach these types of insights and recognize such opportunities, data professionals will have to collaborate much more closely with developers and business teams, as well as adopting a more comprehensive view and understanding of their organization’s data operations.
For those who are willing and able to make this mental shift, I believe their careers will not simply survive the coming changes, but thrive as a result. So, whether it be a DBA by another name, or someone new to the field moving directly into the role, I believe the future looks bright.
Bennie Grant is chief operating officer at Percona.
—
New Tech Forum provides a venue for technology leaders—including vendors and other outside contributors—to explore and discuss emerging enterprise technology in unprecedented depth and breadth. The selection is subjective, based on our pick of the technologies we believe to be important and of greatest interest to InfoWorld readers. InfoWorld does not accept marketing collateral for publication and reserves the right to edit all contributed content. Send all inquiries to doug_dineley@foundryco.com.
Will Kubernetes ever get easier? 10 Feb 2025, 9:00 am
Kubernetes hardly needs an introduction. After Linux, it’s the second-highest velocity open source project in the world. Over the years, thousands of companies have contributed to the platform. At the heart of the thriving cloud-native ecosystem, Kubernetes has become a platform of all things, the foundation for everything from CI/CD pipelines, to machine learning training clusters, to distributed databases with planetary scale.
Kubernetes, which recently celebrated its 10th birthday, is more flexible than ever. It now supports many workload types out-of-the-box—stateless, stateful, and data processing workloads, automated batch jobs, event-driven autoscaling workloads, and more. Custom resource definitions and operators now quickly grant additional features like observability, networking, backup and recovery, and policy management.
The community has devised tools to tackle many roadblocks, like multi-cluster management, porting legacy virtual machines, deploying to edge or bare-metal environments, and using Kubernetes for AI development—helping satisfy more and more use cases, all the while inventing cuddly mascots for new projects entering the ballooning cloud-native landscape.
All this cushy progress has put Kubernetes front and center in the future of enterprise cloud infrastructure. The Cloud Native Computing Foundation says 84% of organizations are either using Kubernetes in production or evaluating it, according to the CNCF’s 2023 annual survey. But, as Kubernetes adds more functionality and absorbs more workloads, is it getting any easier to use?
Remarkable progress
“Kubernetes has definitely gotten a lot easier and more stable to use,” says Murli Thirumale, general manager of Portworx, Pure Storage’s cloud native business unit. He credits this to Kubernetes having triumphed in the container scheduler wars of the 2010s, which pitted Kubernetes against Docker Swarm, Apache Mesos, HashiCorp Nomad, and others. After reaching a consensus, the industry aligned to improve the base deployment and build solutions on top, leading to a more stable distribution and consolidation of vendors for core functions.
Nowadays, hyperscalers offer managed Kubernetes distributions, like Amazon Elastic Kubernetes Service (Amazon EKS), Azure Kubernetes Service (AKS), and Google Kubernetes Engine (GKE). These, as well as plenty of alternatives, provide user-friendly, GUI-based options to manage clusters.
As a result, 84% of organizations are moving away from self-hosted Kubernetes and toward managed services, according to The State of Kubernetes 2023 survey. But this is not to say that innovation has halted by any means.
“There are many areas where ease of use is improving,” says Peter Szczepaniak, senior product manager of Percona. He specifically highlights how Kubernetes operators are making many areas more accessible, such as running complex workloads like databases with high levels of automation. Other advancements in Kubernetes itself are enhancing usability, he adds, such as expanding support of CSI drivers, affinity and anti-affinity configuration, and stateful sets that aim to directly address specific use cases.
Enterprise-centric tools also cover peripheral areas, easing usability for backup and disaster recovery. “The alternative is to script it yourself with various bits of open source code and stitch it together,” says Gaurav Rishi, vice president of product and cloud native partnerships at Kasten by Veeam. “Things have become a lot easier, including security. Even five years ago, enterprises weren’t productizing clusters because security was a concern,” he adds.
Kubernetes began with a robust REST API, allowing all resources to be acted upon with calls to API objects. Over the past decade, we’ve witnessed impressive alignment in the cloud-native industry, and the surrounding community has matured significantly. As an example, the CNCF offers certification for over 100 Kubernetes distributions and installers from vendors to ensure they actually conform to the expected APIs.
Rising complexity
That said, common snags remain. 75% of Kubernetes practitioners encounter issues affecting the running of their clusters, up from 66% in 2022, found Spectro Cloud’s 2023 State of Production Kubernetes report. It’s common to run 10 or more clusters, and a good chunk of developers (33%) find themselves begrudgingly doing platform work.
Many users say further abstraction is necessary, as there is still significant overhead to setting up Kubernetes, from provisioning to configuring security, hooking up monitoring, and so on. Although inroads have been made for small-to-medium businesses, Kubernetes is still often overkill for small projects and small companies that lack skill sets and resources. Interestingly, a 2022 survey from D2iQ found that only 42% of applications running on Kubernetes actually make it into production.
“It’s easier to get started with Kubernetes today,” says Itiel Shwartz, co-founder and CTO of Komodor. “Now it’s a sort of cloud itself, and it’s expected that services like your database, certificate provider, and load balancer will all run under Kubernetes as well. It’s gotten much more complicated to productionize.”
Significant gains have been made to lower the barrier to entry to Kubernetes and improve extensibility. But now the pressure is on to account for this diversity, leading to new problems on “day two.” “Kubernetes is mature, but most companies and developers don’t realize how complex of an environment it can be until they’re actually at scale,” says Ari Weil, cloud evangelist and VP of product marketing at Akamai.
Where users hit gotchas
Kubernetes users often encounter gotchas in a few areas. One barrier is simply contending with the sheer number of tools out there. The CNCF Cloud Native Landscape now hosts 209 projects with 889 total repositories, enough to cause analysis paralysis.
While tools like Helm and Argo CD streamline managing add-ons, each tool has unique configuration needs, which can introduce friction, explains Komodor’s Shwartz. “Add-ons in Kubernetes environments are notoriously difficult to manage because they introduce layers of complexity and require diverse expertise,” he says.
Not all cloud-native tools are created equal, adds Portworx’s Thirumale. He sees this influencing some organizations to make a safer bet on larger, established vendors instead of smaller innovators, especially for high-risk areas like AI or virtualization, where the cost of failure is high.
“Kubernetes is 10 years young,” jokes Rishi. There is plenty of innovation occurring, but he agrees the complex ecosystem can be confusing to grasp. On top of that are the cybersecurity risks that still plague containers, and many organizations must go through hoops to comply with stringent security requirements.
For instance, this could entail hardening data handling with the proper algorithms to meet NIST’s Federal Information Processing Standards (FIPS) or adopting continual container scanning practices to meet the FedRAMP Vulnerability Scanning Requirements for Containers. “On one hand, threat vectors are increasing, but on the other hand, the ecosystem has grown,” says Kasten’s Rishi.
Other common bottlenecks include setting up probes to check the health of applications, setting the proper requests and limits, and configuring network policies. “Improperly configured resource limits can lead to issues like pod evictions, unbalanced workloads, and unexpected application failures,” says Shwartz.
Another pitfall is simply a lack of widespread knowledge about how to use Kubernetes, says Percona’s Szczepaniak. Whereas virtual machines have been around for over twenty years, Kubernetes is still growing in mindshare within enterprises. “I’ve talked to many devops teams that get immediate pushback when introducing new technology if it requires any Kubernetes knowledge from the rest of the organization.”
Working with legacy workloads
At the same time, Kubernetes is becoming harder for devops teams to resist. Described as the cloud’s OS, Kubernetes now caters to far more than just container scheduling. Its scope now encompasses networking and storage through plugins using the Container Network Interface (CNI) and Container Storage Interface (CSI). “Through these extensions, Kubernetes became a multi-cloud control plane for infrastructure,” says Thirumale.
Kubernetes is being used to handle older workload types, too. The emerging KubeVirt tool, for instance, can schedule virtual machines (VMs) that often support legacy mission-critical applications. “This is a huge step forward for Kubernetes,” says Thirumale, who believes Kubernetes has become better positioned to enter the mainstream of existing applications in high-volume transaction areas like automotive, banks, old industrial companies, and beyond.
Others agree support for modern virtualization is a significant shift. “Before, you had two ships in the night: virtual machines on the legacy side versus cloud-native Kubernetes workloads,” adds Rishi. “Today, you can have all the best of what Kubernetes brings in terms of operations and development and faster velocity, even with virtual machines.”
Granting legacy workloads admission to cloud-native infrastructure is intriguing not only to modernize legacy enterprise stacks but also to avoid price hikes due to Broadcom’s consolidation of VMware offerings.
That said, legacy workloads carry different requirements around data migration, backup, disaster recovery, and securing access, says Thirumale. “We’re adding new functionality to Kubernetes data management that wasn’t needed for containers but is needed for virtual machines,” he says. Naturally, support for these additional use cases brings additional complexity for users.
Supporting AI workloads
Another area begging for Kubernetes — and for better usability — is AI development. AI lends itself to containerization, says Thirumale, making Kubernetes a natural fit for both model training and inferencing workloads. “AI and Kubernetes are almost 90% overlapped,” he says. “By its very nature, AI demands an elastic infrastructure.”
Yet, applying Kubernetes to new AI-native applications and managing the scalability of AI inference models on Kubernetes clusters are major challenges, says Vultr CMO Kevin Cochrane. “The operational discipline and playbooks for hosting containerized applications on Kubernetes need to be revisited,” he says. “There’s been little advancement in the tooling to support an integrated pipeline of AI models from training, to tuning, to inference, to global scalability within a Kubernetes cluster.”
“Machine learning workloads need to be deployed in many places, get resources, and be very elastic,” says Chase Christiansen, Staff Solutions Engineer at TileDB. While Kubernetes is a solid foundation for AI, using it alone for this purpose requires deploying ad-hoc services, making special operators for those services, building a pipeline, and handling unique scheduling requirements. For example, long-running jobs can fail overnight, complicating workflows without built-in mechanisms for retries or resilience, says Christiansen.
Kubeflow, an incubating CNCF project, addresses these challenges head-on by making it easier to deploy and manage machine learning models on Kubernetes. Organizations like CERN, Red Hat, and Apple use and contribute to Kubeflow, developing an ecosystem and toolkit for training AI models that seamlessly integrates with cloud-native architectures.
When paired with Kserve for framework-agnostic AI inferencing, Kubeflow can simplify workflows for data scientists. “These tools are making AI much easier to use because you’re abstracting infrastructure away,” says Christianson. “This helps the user experience of creating models, helping drive business outcomes.”
AI inferencing at the edge will likely become more commonplace for niche use cases. That said, cloud container deployments will persist, necessitating a common control layer. “You want a continuum of being able to manage multiple clusters, regardless of where they are deployed, to be able to mobilize them, and not be locked into a specific vendor,” says Kasten’s Rishi.
Moving Kubernetes to the edge
For AI inferencing and many other use cases where proximity to data and latency are top concerns, Kubernetes is finding a role in edge computing, and providing options for smaller container deployments.
“Kubernetes use cases on the edge are growing for sure,” says Rishi. This is alluring for government installations that require air-gapped secure environments or for retail and internet of things (IoT) devices with bandwidth or network limitations, he says. For instance, the US Department of Defense is actively deploying Kubernetes in areas with zero internet connectivity, from battleships to F-16 fighter jets.
Stripped-down Kubernetes flavors have emerged to enable lightweight edge container distributions. Rishi points to K3s, a light Kubernetes distribution for resource-constrained environments, and Bottlerocket, a portable Linux-based operating system for running containers. Major cloud providers also provide options for smaller container deployments, from Microshift, a slimmer alternative to OpenShift for edge devices, to Fargate, AWS’s serverless compute for containers. Alternatives like Amazon Elastic Container Service (Amazon ECS) or HashiCorp Nomad eschew Kubernetes entirely for simpler use cases.
“Kubernetes is definitely getting easier,” says Raghu Vatte, Field CTO and VP of Strategy at ZEDEDA. Yet, on the edge, you could be managing tens of thousands of tiny clusters, he explains, necessitating a centralized mechanism to orchestrate and deploy containers using a heterogeneous runtime. “You don’t want to rebuild an application just because you’re deploying it on the edge.”
The edge also appeals to areas like gaming or hyper-personalized workloads, which often require extremely low latencies. But how can organizations move compute closer to the user while keeping deployment standards consistent across environments? “Having openness and a lack of managed services gives you that portability,” says Akamai’s Weil.
To make Kubernetes workloads portable for various clouds and regions, Weil recommends avoiding proprietary wrappers. Instead, he highlights the value of ‘golden path templates’ that retain compatibility with Kubernetes in its open-source form and build upon stable CNCF projects like OpenTelemetry, Argo, Prometheus, or Flatcar. This can simplify back-end orchestration, reduce vendor lock-in, and bring flexibility for multi-cloud, he says.
Options for smaller container deployments can also support internal experimentation. For instance, Jemiah Sius, head of developer relations at New Relic, describes how his team essentially works as a small engineering division in New Relic, using tools like MiniKube or K3s to host technical documentation or spin up short-lived prototypes or proofs of concepts during workshops in resource-constrained local environments.
According to Sius, Kubernetes is becoming more usable for these scenarios. He also believes it is becoming easier to adopt in general, with increased community support, improved documentation, and a more streamlined installation process. However, he notes that there is still a steep learning curve, particularly in understanding performance and managing data silos.
Lowering the barrier to Kubernetes
A decade in, Kubernetes remains complex, even using managed services. However, efforts are underway to build abstractions that improve developer experience and accessibility. “Kubernetes tooling is helping bridge skill gaps by providing intuitive interfaces and out-of-the-box insights, which lowers the expertise barrier,” says Komodor’s Shwartz.
Tools are also evolving to make cluster visibility more accessible, with one-step installations for observability functions. “Before, you had to actually augment your application code and manually add configurations by changing the manifest,” explains New Relic’s Sius. User-friendly observability options now help operators better understand the health of their systems and identify performance or reliability problems with far less effort.
AI and machine learning also are playing a role in enhancing user experience with Kubernetes management. For instance, Andreas Grabner, devops activist at Dynatrace and a CNCF ambassador, shares how generative AI-driven tools have made it easier to observe and diagnose Kubernetes clusters, aiding root cause analysis with practical information to optimize systems.
Kubernetes is cemented into the future of cloud-native infrastructure. In this world, edge will become a more common deployment pattern, and containerization will power the future of AI-native applications. To address cloud-native complexity, many enterprises have placed their hopes in platform engineering to consolidate tools and create paved roads that improve the usability of cloud-native architecture.
By 2025, 95% of applications will be deployed on cloud-native platforms, estimates Gartner. But while the cloud-native ecosystem seems at its zenith, plenty of enterprises still haven’t made the shift to containers, signaling room for growth.
There’s still plenty of room for exciting growth for Kubernetes. Growth not only in terms of adoption, but also the underlying platform, the tools and add-ons, and the use cases. Designed to orchestrate containers at massive scale, the descendant of Google’s Borg seems destined to become a standard deployment pattern for all kinds of workloads. In any case, the race between usability and complexity seems bound to continue.
Will Kubernetes become mature and easy in the coming years, or a rebellious and unwieldy teen? Time will tell.
JDK 24: The new features in Java 24 8 Feb 2025, 12:04 am
Java Development Kit (JDK) 24 has entered the release candidate stage. The next version of standard Java will ship with 24 features, ranging from a class-file API to a fourth preview of structured concurrency.
The first JDK 24 release candidate arrived February 6, following two rampdown stages. JDK 24 is due as a production release on March 18, after a second release candidate due February 20. With its two dozen features, JDK 24 far outdoes predecessor JDK 23, which arrived September 17 with 12 features.
The five most recent additions to JDK 24 include warnings upon the use of memory access methods in sun.misc.unsafe
, a fourth preview of structured concurrency, deprecating the 32-bit x86 port for removal, and improving Java’s resistance to quantum computing attacks by providing Java implementations of a quantum-resistant module-latticed-based digital signature algorithm and a quantum-resistant module-latticed-based key encapsulation mechanism.
Previously proposed features include flexible constructor bodies; ahead-of-time class loading and linking; removing the Windows 32-bit x86 port; synchronizing virtual threads without pinning; simple source files and instance main methods; permanently disabling the security manager; module import declarations; an experimental version of compact object headers; primitive types in patterns, instanceof
, and switch
; linking runtime images without JMODs; the generational Shenandoah garbage collector; scoped values; a key derivation function API; removal of the non-generational mode in the Z Garbage Collector; stream gatherers; a vector API; a class-file API; warnings to prepare developers for future restrictions on the use of JNI (Java Native Interface); and a late barrier expansion for the G1 garbage collector.
JDK 24 has been designated a non-long-term support (LTS) release. (The current LTS release is JDK 21, which shipped in September 2023.) Like JDK 23, JDK 24 will receive only six months of premier-level support from Oracle. Early access builds of JDK 24 can be found at jdk.java.net. JDK 24 is slated to be followed next September by the next LTS release, JDK 25.
With a warning upon use of memory-access methods in sun.misc.Unsafe
, Java would issue a warning at runtime on the first occasion that any memory-access method in sun.misc.unsafe
is invoked. All of these unsupported methods were terminally deprecated in JDK 23 and have been superseded by standard APIs. The sun.misc.Unsafe
class was created to provide a mechanism for Java classes to perform low-level operations. Most of its methods are for accessing memory, either in the JVM’s garbage-collected heap or in off-heap memory, which is not controlled by the JVM. As the class name suggests, these memory-access methods are unsafe.
Structured concurrency, back for another preview, is intended to simplify concurrent programming by introducing an API for structured concurrency. With the structured concurrency concept, groups of related tasks running in different threads are treated as a single unit of work, thereby streamlining error handling and cancellation, improving reliability, and enhancing observability. The goal is to promote a style of concurrent programming that can eliminate common tasks arising from cancellation and shutdown, such as thread leaks and cancellation delays. Improving the observability of concurrent code also is a goal.
Deprecating the 32-bit x86 port for removal, which follows a proposal to deprecate the Windows 32-bit x86 port (see below), will deprecate the Linux 32-bit x86 port, which is the only 32-bit x86 port remaining in the JDK. It will also effectively deprecate any remaining downstream 32-bit x86 ports. After the 32-bit x86 port is removed, the architecture-agnostic Zero port will be the only way to run Java programs on 32-bit x86 processors. Deprecating the 32-bit x86 port in JDK 24 will allow for its removal in JDK 25.
The two features proposed for improving Java security through quantum-resistance include a quantum-resistant module-lattice-based key encapsulation mechanism (ML-KEM) and a quantum-resistant module-lattice-based digital signature algorithm (ML-DSA). ML-DSA would secure against future quantum computing attacks by using digital signatures to detect unauthorized modifications to data and to authenticate the identity of signatories. Key encapsulation mechanisms (KEMs) are used to secure symmetric keys over insecure communication channels using public key cryptography. Both features are designed to secure against future quantum computing attacks.
Flexible constructor bodies are in a third preview after being featured in JDK 22 and JDK 23, albeit with a different name in JDK 22, when the feature was called statements before super(...)
. The feature is intended to reimagine the role of constructors in the process of object initialization, letting developers more naturally place logic that they currently must factor into auxiliary static methods, auxiliary intermediate constructors, or constructor arguments. The proposal introduces two distinct phases in a constructor body: The prologue contains code that executes before the superclass constructor is invoked, and the epilogue executes after the superclass constructor has been invoked. The feature also would preserve the existing guarantee that code in a subclass constructor cannot interfere with superclass instantiation.
Ahead-of-time class loading and linking aims at improving startup times by making classes of an application instantly available in a loaded and linked state, when the HotSpot Java virtual machine starts. This would be achieved by monitoring the application during one run and storing the loaded and linked forms of all classes in a cache for use in subsequent runs.
The Windows 32-bit x86 port was deprecated for removal in JDK 21 with the intent to remove it in a future release. Plans call for removing the source code and build support for the Windows 32-bit x86 port. Goals include removing all code paths that apply only to Windows 32-bit x86, ceasing all testing and development efforts targeting the Windows 32-bit x86 platform, and simplifying the JDK’s build and test infrastructure. The proposal states that Windows 10, the last Windows operating system to support 32-bit operation, will reach its end of life in October 2025.
Synchronizing virtual threads without pinning involves improving the scalability of Java code that uses synchronized methods and statements by arranging for virtual threads that block in such constructs to release their underlying platform for use by other threads. This would eliminate almost all cases of virtual threads being pinned to platform threads, which severely restricts the number of virtual threads available to handle an application workload.
A fourth preview of simple source files and instance main methods would evolve the Java language so beginners can write their first programs without needing to understand language features designed for large programs. The feature was previously previewed in JDK 21, JDK 22, and JDK 23. The goal is to allow beginning Java programmers to write streamlined declarations for single-class programs and then seamlessly expand their programs to use more advanced features as their skills grow.
Permanently disabling the security manager involves revising the Java platform specification so developers cannot enable the security manager, while other platform classes do not refer to it. The security manager has not been the primary means of securing client-side Java code for many years, has rarely been used to secure server-side code, and has been costly to maintain, the proposal states. The security manager was deprecated for removal in Java 17.
Module import declarations, previously previewed in JDK 23, enhance the Java programming language with the ability to succinctly import all of the packages exported by a module. This simplifies the reuse of modular libraries but does not require the importing of code to be a module itself. The second preview adds capabilities pertaining to lifting the restriction that no module can declare a transitive dependence on the java.base
module, revising the declaration of the java.se
module and allowing type-import-on-demand declarations to shadow module import declarations.
Compact object headers would reduce the size of object headers in the HotSpot VM from between 96 and 128 bits down to 64 bits on 64-bit architectures. The goal of the proposed feature is to reduce heap size, improve deployment density, and increase data locality.
A second preview of primitive types in patterns, instanceof, and switch in JDK 24 would enhance pattern matching by allowing primitive types in all patterns and contexts. The feature also would extend instanceof
and switch
to work with all primitive types. The goals of the feature include enabling uniform data exploration by allowing type patterns for all types, whether primitive or reference; aligning types with instanceof
and aligning instanceof
with safe casting; and allowing pattern matching to use primitive types in both nested and top-level pattern contexts. Other goals include providing easy-to-use constructs that eliminate the risk of losing information due to unsafe casts, following the enhancements to switch
in Java 5 and Java 7, and allowing switch
to process values of any primitive type. This feature was previously previewed in JDK 23.
With linking runtime images without JMODs, the plan is to reduce the size of the JDK by roughly 25% by enabling the jlink
tool to create custom runtime images without JDK JMOD (modular JAR) files. This feature must be enabled when the JDK is built (it will not be enabled by default) and some JDK vendors may choose not to enable it. Goals include allowing users to link a runtime image from modules regardless of whether those modules are standalone JMOD files, modular JAR files, or part of a runtime image linked previously. Motivating this proposal is the notion that the installed size of the JDK on the file system is important in cloud environments, where container images that include an installed JDK are automatically and frequently copied over the network from container registries. Reducing the size of the JDK would improve the efficiency of these operations.
Generational Shenandoah would enhance the garbage collector with experimental generational collection capabilities to improve sustainable throughput, load-spike resistance, and memory utilization. The main goal is to provide an experimental generational mode, without breaking non-generational Shenandoah. The generational mode is intended to become the default mode in a future release.
Scoped values enable a method to share immutable data both with its callees within a thread and with child threads. Scoped values are easier to reason about than local-thread variables. They also have lower space and time costs, particularly when used together with virtual threads and structured concurrency. The scoped values API was proposed for incubation in JDK 20, proposed for preview in JDK 21, and improved and refined for JDK 22 and JDK 23. Scoped values will be previewed in JDK 24.
With the key derivation function (KDF) API, an API would be introduced for key derivation functions, which are cryptographic algorithms for deriving additional keys from a secret key and other data. A goal of this proposal is allowing security providers to implement KDF algorithms in either Java code or native code. Another goal is enabling applications to use KDF algorithms such as the HMAC (hash message authentication code)-based extract-and-expand key derivation function (RFC 5869) and Argon2 (RFC 9106).
Removing the non-generational mode of the Z Garbage Collector (ZGC) is a proposal aimed at reducing the maintenance cost of supporting two different modes. Maintaining non-generational ZGC slows the development of new features, and generational ZGC should be a better solution for most use cases than non-generational ZGC, the proposal states. The latter eventually should be replaced with the former to reduce long-term maintenance costs. The plan calls for removing the non-generational mode by obsoleting the ZGenerational option and removing the non-generational ZGC code and its tests. The non-generational mode will expire in a future release, at which point it will not be recognized by the HotSpot JVM, which will refuse to start.
Stream gatherers would enhance the stream API to support custom intermediate operations. Stream gatherers allow stream pipelines to transform data in ways that are not easily achievable with the existing built-in intermediate operations. This feature was proposed as a preview in JDK 22 and JDK 23. The API would be finalized in JDK 24. Goals include making stream pipelines more flexible and expressive and allowing custom intermediate operations to manipulate streams of infinite size.
The vector API is designed to express vector communications that reliably compile at runtime to optimal vector instructions on supported CPU architectures, thus achieving performance superior to equivalent scalar computations. The vector API previously was incubated in JDK 16 through JDK 23. Goals of the proposal include clearly and concisely expressing a wide range of vector computations in an API that is platform-agnostic, that offers reliable runtime compilation and performance on x64 and AArch54 architectures, that degrades gracefully and still functions when a vector computation cannot be expressed at runtime, and that aligns with Project Valhalla, leveraging enhancements to the Java object model.
The class-file API, previously previewed in JDK 22 and JDK 23, would be finalized in JDK 24, with minor changes. This API provides a standard API for parsing, generating, and transforming Java class files. It aims to provide an API for processing class files that tracks the class file format defined by the Java Virtual Machine specification. A second goal is to enable JDK components to migrate to the standard API, and eventually remove the JDK’s internal copy of the third-party ASM library. Changes since the second preview include a renaming of enum values, removal of some fields, the addition of methods and method overloads, methods renamed, and removal of interfaces and methods deemed unnecessary.
Late barrier expansion for the G1 garbage collector is intended to simplify the implementation of G1’s barriers by shifting their expansion from early in the C2 compilation pipeline to later. The barriers record information about application memory accesses. Goals include reducing the execution time of C2 compilation when using the G1 collector, making G1 barriers comprehensible to HotSpot developers who lack a deep understanding of C2, and guaranteeing that C2 preserves invariants about the relative ordering of memory accesses, safepoints, and barriers. A fourth feature is preserving the quality of C2-generated JIT (just-in-time)-compiled code, in terms of speed and size.
The first JDK 24-targeted feature, officially called “Prepare to Restrict the Use of JNI,” calls for issuing warnings about uses of JNI and adjusting the foreign function and memory (FFM) API, featured in JDK 22, to issue warnings in a consistent manner. These warnings are intended to prepare for a future release that ensures integrity by default by uniformly restricting JNI and the FFM API. Goals of the plan include preserving JNI as a standard way to interoperate with native code, preparing the Java ecosystem for a future release that disallows interoperation with native code by default, and aligning the use of JNI and the FFM API so library maintainers can migrate from one to the other without requiring developers to change command-line options.
The most recent LTS release, JDK 21, arrived in September 2023 and is due to get at least five years of Premier support from Oracle. The next LTS version, JDK 25, is due in September 2025. LTS releases have dominated Java adoption, which means adoption of JDK 23 and JDK 24 could be on the low end as users await JDK 25.
Visual Studio Code unveils Copilot code editing suggestions 7 Feb 2025, 11:47 pm
A just-released update of Visual Studio Code, version 1.97, introduces a preview of Copilot Next Edit Suggestions, an AI-powered feature that predicts the next edit the user wants to make. The new VS Code release also includes a movable Command Palette and the ability to quickly debug Python scripts without setup.
Visual Studio Code 1.97, also known as the January 2025 release, was introduced February 6. It can be downloaded for Windows, Mac, or Linux.
With Copilot Next Edit Suggestions (Copilot NES), VS Code 1.97 adds a feature for predicting the location of the next edit to make and what the edit should be. Copilot NES suggests future changes based on previous edits. Developers simply press tab to navigate and accept suggestions. Copilot NES can be enabled via the VS Code setting github.copilot.nextEditSuggestions.enabled
.
Visual Studio Code 1.97 also makes the Copilot Edits feature generally available. Copilot Edits, which allows users to make code changes across multiple files in their workspace directly from chat, was previewed in VS Code 1.95. Also with VS Code 1.97, the model picker now includes OpenAI o3-mini and Gemini 2.0 Flash.
For Python, VS Code users now can debug a Python script or module directly from the terminal, without setup, thanks to a new no-config debug feature.
Other new features in VS Code 1.97:
- Developers now can move the Command Palette and other Quick Inputs to a new position, rather than having it fixed at the top of the window.
- When installing an extension from a publisher for the first time, developers will now see a dialog to help assess the trustworthiness of the extension publisher. When a user updates to VS Code 1.97, the publishers of currently installed extensions are automatically trusted.
- Contents of the Output panel now can be filtered, which can improve management and analysis of logs, particularly when dealing with large volumes of log data.
- The notebook editor now supports showing inline values after cell execution, via the setting
notebook.inlineValues
. - In the JavaScript debugger, scripts now can be “pretty printed” by using the “Debug: Pretty print for debugging” command from the command palette or editor actions, even if they are not the source the debugger is currently paused in.
- The TypeScript 5.7.3 recovery release, a minor update that fixes a few import bugs and regressions, is included.
Visual Studio Code 1.97 arrives after the December release of VS Code 1.96 featuring an overtype mode and followed by four point release updates for fixes.
The hidden threat of neglected cloud infrastructure 7 Feb 2025, 9:00 am
In 2012, the Cybersecurity and Infrastructure Security Agency (CISA) issued a public advisory regarding software to monitor and control building systems. Fast-forward to 2023, and cybersecurity researchers at watchTowr discovered that an abandoned Amazon S3 bucket referenced in that advisory was still active and vulnerable.
Left unattended for over a decade, malicious actors could have reregistered this bucket to deliver malware or launch devastating supply chain attacks. Fortunately, researchers notified CISA, which promptly secured the vulnerable resource. The incident illustrates how even organizations dedicated to cybersecurity can fall prey to the dangers of neglected digital infrastructure.
This story is not an anomaly. It indicates a systemic issue that spans industries, governments, and corporations. A recent investigation by watchTowr underscores the pressing risks posed by abandoned or poorly configured cloud infrastructure, revealing a widespread blind spot that urgently needs the industry’s attention.
An unguarded access point
During the four-month investigation by watchTowr researchers managed to assume control of roughly 150 neglected AWS S3 buckets belonging to a range of users, including Fortune 500 corporations, government agencies, academic institutions, and cybersecurity firms. These abandoned cloud assets were still being queried via millions of HTTP requests. Legitimate organizations and systems sought critical resources such as software updates, unsigned virtual machines, JavaScript files, and server configurations. During two months, more than 8 million such calls were recorded.
The implications are staggering: These requests could have easily been manipulated by bad actors to deliver malware, collect sensitive information, or even orchestrate large-scale supply chain attacks. WatchTowr warned that breaches of this magnitude could surpass the infamous 2020 SolarWinds attack in scale and impact. Among the incidents uncovered by watchTowr are several alarming examples:
- Abandoned S3 buckets tied to SSL VPN appliance vendors were discovered to be still serving deployment templates and configurations.
- An older GitHub commit from 2015 exposed an S3 bucket linked to a popular open source WebAssembly compiler.
- Researchers uncovered systems pulling virtual machine images from abandoned resources.
A minor oversight with major consequences
Entities attempting to communicate with these abandoned assets include government organizations (such as NASA and state agencies in the United States), military networks, Fortune 100 companies, major banks, and universities. The fact that these large organizations were still relying on mismanaged or forgotten resources is a testament to the pervasive nature of this oversight.
The researchers emphasized that this issue isn’t specific to AWS, the organizations responsible for these resources, or even a single industry. It reflects a broader systemic failure to manage digital assets effectively in the cloud computing age. The researchers noted the ease of acquiring internet infrastructure—an S3 bucket, a domain name, or an IP address—and a corresponding failure to institute strong governance and life-cycle management for these resources.
Neglected digital infrastructure is a massive, often ignored security vulnerability. Enterprises need to adopt a stronger and more proactive approach to cloud governance and infrastructure management to avoid falling victim. Below are actionable recommendations for enterprises to address the challenges uncovered by watchTowr:
- Establish a clear and comprehensive inventory of all digital assets, whether on premises or in the cloud.
- Perform frequent security reviews of your cloud environment and address misconfigurations or outdated resources.
- Ensure that every cloud resource is assigned to a specific owner within the organization who is held accountable for its maintenance or decommissioning.
- Employ automated scripts to identify and remove unused resources, including S3 buckets, old DNS entries, and unneeded IPs.
- Embed security best practices into your development life cycle. Require all configurations for cloud resources to meet specific security benchmarks before deployment and ensure proper oversight for infrastructure as code.
- If your organization relies on third-party cloud resources or open source tools, establish monitoring to detect when those resources are abandoned or compromised.
I agree with all of these.
An opportunity for change
The discovery of vulnerable cloud infrastructure is both a warning and an opportunity. Enterprises can substantially reduce risk exposure by adopting a culture of accountability, investing in robust asset management, and integrating automated security practices.
Organizations must move beyond the “fire-and-forget” mindset. It requires vigilance, a long-term strategy, and consistent investments in security to truly support an enterprise’s goals. By addressing these vulnerabilities now, enterprises can ensure that cloud computing promises don’t come with unintended—and potentially catastrophic—costs. You’ve been warned.
Full-stack JavaScript leads the way 7 Feb 2025, 9:00 am
Building web apps begins with a simple premise, but the real-world experience is a juggling act of optimizations, best practices, toolchains, and so on. Developers tend to respond by doing what we do best: creating new tools and techniques to manage ever-changing demands.
The paradox is, if we don’t strike the right balance, our efforts compound the problem with more technology choices and the effort of integrating them. To quote Tom Petty, “There ain’t no easy way out.” It’s an enduring part of building the Internet that we are continually walking the tightrope, refining our balance as we go.
Top picks for JavaScript readers on InfoWorld
State of JavaScript: Highlights of the JavaScript developer survey
Every year, the State of JavaScript survey gives a wide view of both specific JavaScript technologies and the pace and dynamics of change in the software industry at large. The rise and fall of JavaScript frameworks is especially instructive in this latest report.
Get started with HTMX: Dynamic HTML without JavaScript
HTMX, now in version 2.0, is an HTML extension syntax that replaces JavaScript with simple markup while leaving the choice of server-side APIs entirely up to the developer. I’ve written a few tutorials demonstrating how to seamlessly combine HTMX with popular tools and frameworks, including BunJS.
Angular team unveils strategy for 2025
Angular is shaping up to be one of JavaScript’s great stories of rebirth. The framework stumbled early on, earning a reputation among developers for being heavy-handed. It has since taken on new life, with plans this year to enhance developer experience and more.
Bun 1.2 squashes Node compatibility bugs
BunJS continues its drive forward as a fully compatible, drop-in Node replacement. With a growing reputation for impressive performance, Bun has the feeling of a passion project with a fanatical devotion to optimization.
More good reads and JavaScript updates
Vitest 3.0 is out!
Vitest testing framework can be used as part of the Vite build tool or as a standalone tester. Check it out for yourself to see why its popularity is surging.
JavaScript frameworks in 2025
Ryan Carniato, creator of SolidJS, has posted an in-depth look at the framework landscape going into 2025. The move to server-side figures large, but he also sees the pendulum swinging back toward the client. Bottom line? Full-stack thinking is here to stay.
Introducing AX: Why agent experience matters
Netlify cofounder Matt Biilmann, has interesting thoughts on the rise of agenic AI. Namely, he proposes that next-gen software companies must take “AX”—the overall experience of AI agents using their products and platforms—as seriously as they do UX and DX. But does the word experience really apply to AI agents? Not to go all Blade Runner on you, but Do androids dream of electric sheep?
GitHub Copilot previews agent mode 7 Feb 2025, 12:50 am
GitHub has added new capabilities to its GitHub Copilot AI-powered coding assistant, including a preview of a new agent mode capable of iterating on its own code. The company also announced the general availability of Copilot Edits in Visual Studio Code.
The updates, announced February 6, serve as an evolution of GitHub Copilot from an AI pair programmer to an agentic peer programmer, as agents become increasingly integral to software development, according to GitHub.
Copilot Edits allows developers to specify a set of files to be edited and prompt Copilot in natural language to immediately make inline changes across multiple files. Agent mode enables Copilot to iterate on its own output as well as the results of that output to complete a user request. Agent mode can recognize and fix its own errors, suggest terminal commands, and analyze runtime errors with self-healing capabilities, GitHub said.
To access agent mode, developers need to download VS Code Insiders and then enable the agent mode setting for GitHub Copilot Chat.
Other features in preview include:
- New models from industry leaders including Google Gemini 2.0 Flash and OpenAI o3-mini available in Copilot Chat. Administrators have organization-wide access control.
- Next edit suggestions to accelerate code changes by identifying and proposing the next edit based on the context of previous changes. By pressing tab, users can implement suggestions throughout an open file with insertions, deletions, and replacements.
- Prompt files that allow users to store and share reusable prompt instructions in their VS Code workspace. These “blueprints” include self-contained markdown files that blend natural language guidance, file references, and linked snippets to “supercharge” coding tasks.
- Vision for Copilot, a feature that allows users to generate a UI, alt text, and code by feeding Copilot a screen, image, or snip.
The company also unveiled “Project Padawan,” which involves plans for autonomous SWE agents on GitHub that will independently handle entire tasks at the developer’s direction. This effort represents a future where developers can assign GitHub issues to GitHub Copilot, let AI complete the task autonomously, and then review the work.
GitHub also announced provisioning and authentication support for GitHub Copilot Workspace for Enterprise Managed Users. This allows organizations to configure and control Workspace access securely, GitHub said.
Oracle maintains hold on JavaScript trademark 6 Feb 2025, 6:09 pm
Oracle, under external pressure to yield control over the JavaScript trademark, has instead filed a motion for dismissal of part of a petition to cancel the trademark.
Filed February 3, Oracle claims the petition fails to state a claim upon which relief can be granted alleging that Oracle committed fraud relating to the trademark. The petition to the United States Patent and Trademark Office (USPTO) to cancel the trademark was filed November 22, 2024 by JavaScript runtime builder Deno Land.
Deno Land has argued that Oracle committed fraud by submitting screen captures of the Node.js website to defend its ownership of the JavaScript trademark despite Oracle having no affiliation with Node.js. Oracle denies making a fraudulent submission, saying it also submitted a specimen pertaining to the JavaScript Extension Toolkit page from Oracle’s own website. Oracle seeks to have the USPTO trial and appeal board extend the deadline to answer the petition to at least 30 days beyond the board’s decision on the motion.
Efforts to void Oracle’s ownership of the JavaScript trademark have been led by Deno and Node.js creator Ryan Dahl. In a February 4 blog post, Dahl criticized Oracle’s latest move. “Yesterday, Oracle filed a motion to dismiss in response to Deno’s petition to cancel its ‘JavaScript’ trademark,” Deno Land CEO Dahl said. “But instead of addressing the real issue—that JavaScript is an open standard with multiple independent implementations—Oracle is trying to stall the process and sidestep accountability.”
In addition to the fraud claim, Deno Land has argued that Oracle should not hold the trademark, which it received when acquiring Sun Microsystems in 2009, because JavaScript was not an Oracle product and Oracle has abandoned the trademark anyway. But Oracle has refused to give up the trademark. “The situation is self-evident to anyone working in tech,” Dahl said this week. “Oracle did not create JavaScript. Oracle does not control JavaScript. Oracle should not own the trademark for JavaScript.”
Oracle could not be reached for comment about the issue on February 5.
Google rolls out cheaper AI model as industry scrutinizes costs 6 Feb 2025, 11:37 am
Google has announced several updates to its Gemini portfolio, including a budget-friendly product, amid growing demand for low-cost AI models driven by the rise of Chinese competitor DeepSeek.
“We’re releasing a new model, Gemini 2.0 Flash-Lite, our most cost-efficient model yet, in public preview in Google AI Studio and Vertex AI,” the company said in a blog post.
The updated lineup now includes several Gemini variants tailored to different price points and performance levels.
In addition to Flash-Lite, Google has made Gemini 2.0 Flash generally available after a developer preview in December and has begun testing an updated version of its flagship “Pro” model.
The updated Gemini 2.0 Flash would be available via the Gemini API in Google AI Studio and Vertex AI, allowing developers to build production applications with 2.0 Flash.
“The Flash series of models is popular with developers as a powerful workhorse model, optimal for high-volume, high-frequency tasks at scale and highly capable of multimodal reasoning across vast amounts of information with a context window of 1 million tokens,” Google said. “2.0 Flash is now generally available to more people across our AI products, alongside improved performance in key benchmarks, with image generation and text-to-speech coming soon.”
Flash-Lite 2 features a 1-million token context window and supports multimodal input, similar to Flash 2, Google added. It can generate captions for around 40,000 unique images at a cost of less than a dollar on Google AI Studio’s paid tier.
DeepSeek’s disruption in AI
The rising costs of AI development have drawn heightened investor scrutiny after Chinese AI firm DeepSeek revealed it spent less than $6 million on the final training run of one of its models – far below what developers at leading US AI firms estimate for similar systems.
DeepSeek’s disclosure has fueled investor concerns, surfacing in earnings calls at Alphabet, Microsoft, and Meta, as stakeholders question the long-term sustainability of soaring AI investments.
“The introduction of DeepSeek models has disrupted the generative AI landscape through several key developments, including cost-effective model development, the democratization of AI access, and geopolitical and security considerations,” said Kartikey Kaushal, senior analyst at Everest Group. “The impact of these developments was felt globally, as major firms like Nvidia, Microsoft, and Alphabet saw declines in their stock prices.”
Competition in the AI sector intensified further over the Lunar New Year holidays last month as Alibaba Group unveiled an upgraded AI model, claiming it outperforms DeepSeek. The move raises the stakes in the battle for low-cost, high-performance AI solutions.
“From a vendor standpoint, there will be increased pressure to deliver a broader range of affordable AI solutions,” Kaushal said. “Vendors like OpenAI and Microsoft will need to reassess their pricing models to stay competitive and attract investments. Additionally, they must balance R&D spending with revenue generation.”
Despite the cost concerns, Google, Microsoft, and Meta have signaled plans to maintain substantial capital spending in the field.
Implications for enterprises
Google’s launch of the Flash-Lite model marks a direct response to its Chinese rival but also signals a broader shift in the enterprise AI landscape, where cost efficiency is becoming a key battleground.
For businesses integrating AI, this shift could lead to a reallocation of budgets, moving spending away from costly model training and development toward AI integration, automation, and workflow optimization. However, analysts caution that it may come with trade-offs.
“Enterprises opting for low-cost AI models must weigh trade-offs in performance, security, and data privacy,” Kaushal said. “With fewer parameters, these models may have weaker contextual understanding and reasoning, making them less effective for complex tasks.”
Beyond performance considerations, security risks include weaker defenses against adversarial attacks and data poisoning. Shared infrastructure also raises concerns over data privacy, potential leaks, and regulatory compliance challenges.
Hidden costs – such as additional validation layers, security measures, and reputational risks from performance issues – may further complicate decision-making, underscoring the need for a balanced approach.
Using NATS with .NET Aspire 6 Feb 2025, 9:00 am
If you’re building a cloud-native application using a scalable cluster of microservices, you’re going to need a way for those services to communicate. Traditional API calls work well for tightly coupled code, but what if you’re building an application that scales its edge separately from its core, or that brings in information from across the internet?
This is where message-oriented architectures become necessary. Services source events, which are then distributed to functions that can respond to those events. Those events are encapsulated in messages, along with relevant data, to deliver everything needed for a service to process that event. We often think of this as a common Internet of Things design pattern, but it’s applicable across many different types of enterprise applications.
Messaging in cloud-native code
Basic publish-and-subscribe messaging architectures are relatively simple to build and use, with basic functionality built into most development frameworks. Things are quite different at scale, with message brokers and other middleware necessary to manage, queue, and deliver messages to service endpoints.
Things get more complex when you’re working with technologies like Kubernetes. The number of available endpoint services can vary as the orchestrator adds and removes pods and nodes to manage resources. The unpredictable number of moving parts makes traditional ways of managing messages difficult.
As more at-scale, cloud-native applications have to work with the edge, we need to think about messages differently. At the very least we need new ways of defining the link between messages and endpoints, as there’s no way to be sure that an endpoint address will be the same between calls. Traditional addressing techniques that take advantage of network addresses start to break down.
We need to be able to send those messages in a way that can respond to changes in application topology in real time, and where endpoints are discovered by an alternative to IP addresses.
Introducing NATS
That tool is here now, part of the Cloud Native Computing Foundation’s incubation program. NATS, the Neural Autonomic Transport System, builds on lessons from biology to build a new form of messaging middleware designed to work in modern environments. Written in Go, like Kubernetes, it offers a common messaging server that can be run anywhere, and a set of clients for most common development platforms. Even though NATS’ focus is on linking mobile clients to central servers, its architecture is suitable for any edge-to-core messaging application.
Most current messaging architectures require a 1:1 connection pattern. NATS aims to improve operations by using a M:N connectivity model, a superset of 1:1. This approach allows you to work without the complexities of a modern networking architecture and reduces the need for load balancers and proxies. It offers its own security tools to avoid the overhead of added services.
Key to the operation of NATS is what it calls “subject-based messaging.” This is a variant of the familiar publish-and-subscribe model, with subjects grouped into a hierarchy. The server tracks which clients are subscribed to which subjects, and if there are no subscriptions to a message’s subject, it’s dropped, which saves on resources.
There are memory requirements that come with managing subscriptions, so while they’re technically unlimited, it’s a good idea to scope them in advance (using a . to separate each level in a hierarchy). Each level in a hierarchy is a separate token and can be used with wildcards to fine-tune subscriptions, behaving like a namespace.
Deploying NATS servers
A NATS server can be deployed in many ways, with support for most common OSes. If you’re planning to use it as part of an Azure application, you can choose between Linux and Windows, with x86 and Arm64 builds. You can start small, with the cheapest possible host VM, and scale up as necessary. By taking advantage of NATS’ minimal hardware requirements, starting with one core and 32MB RAM, it’s an economical choice that balances between server and networking performance.
Although NATS is often used to route messages without storing them, it includes a message queue service called JetStream. This provides a shared history across all the NATS servers in a cluster, allowing clients to retrieve messages at any time. This is useful, say, if you’re building a mobile app that needs to be able to synchronize events with a server if it goes offline for any time.
Installation options include a binary or a Docker container. If you prefer, it’s available via the third-party Scoop package manager. Alternatively, you can clone the GitHub repository and build your own install using Go. This approach can be used to embed a NATS server in your own code. The easiest option by far is to use a Docker container to host your server. This allows you to run it isolated from other applications and ensures that you have all the required components in one place.
Once installed you can use NATS’ CLI to manage your server. The latest versions of the NATS CLI replace several different tools, giving you one place to manage your messaging server. Like the server, it’s written in Go, so it can be installed via existing Go tools or using Scoop. This gives you the possibility of quickly hosting a test server on development PCs.
Using NATS in .NET clients
Servers need clients, and NATS has an official .NET client, available from NuGet. It supports both the older .NET Framework via .NET Standard as well as the modern .NET 6.0 and later. It’s important to use the right client version, NATS.Net, as an older, deprecated version is also available.
Once you have a server running, you’re ready to build your first .NET NATS client. Download the NATS.Net package and add references to it in your project. This lets you create a NATS client object, which lets you subscribe to the NATS message stream and then use an asynchronous function to capture data as it’s sent out. The client can be used to publish as well as read, so you only need to install the client once.
The .NET client supports JetStream too, using similar techniques to connect to a subscription. Messages stored on a server are processed in order, ensuring that chronology is preserved, with a network of NATS clients offering eventual consistency. Here the server cluster becomes the source of truth for your application.
.NET NATS at scale with Aspire
.NET support for NATS goes beyond building your own infrastructure, as it’s now part of the Aspire distributed application framework. NATS is managed as a server resource, using a builder statement to create an instance in your application, ready for use. You can use the same tool to work with existing NATS servers by defining a connection string in Aspire.
This adds a simple server without JetStream support. Simply add a WithJetStream
statement to your builder to enable it. At the same time, you can define a storage directory outside the NATS container where it will store JetStream data. If you define this as a data volume, it will be available if the NATS container crashes and restarts, enabling basic message resilience. One of Aspire’s more useful features is its built-in health checks, which will test your NATS server regularly to ensure it is running and that clients can connect.
Aspire provides its own packaging for the NATS.Net client, using its own dependency injections to add configurations where necessary. Again, you use its builder feature to add clients and configure message namespaces.
Working with NATS in an Aspire application is much like working with it in any other environment. What’s important is that Aspire offers a way to deploy and configure both servers and clients. This should allow you to focus on the essential logic of your application. Configuration is managed in one place, with the option of using JSON to store connection strings so you can use source control to manage it.
Open source tools such as NATS are key to delivering at-scale, cloud-native applications, so it’s important for .NET Aspire to support them—even when they’re still in incubation.
Malicious package found in the Go ecosystem – update 5 Feb 2025, 10:51 pm
Update February 6: Google has removed the package and provided the following statement:
The module has been removed from both the Go module proxy and GitHub, and we’ve added it to the Go vulnerability database for anyone who thinks they may have been impacted. We are addressing this through fixes like capability analysis via Capslock and running comparisons with deps.dev. We want to thank Socket and the Go team contributors that detected the module and are addressing fixes. We’ll continue to work with the wider industry to raise awareness around common open source security issues like these and work being done through initiatives like SLSA and OpenSSF.
A malicious typosquat package has been found in the Go language ecosystem. The package, which contains a backdoor to enable remote code execution, was discovered by researchers at the application security company Socket.
A February 3 Socket blog post states that the package impersonates the widely used Bolt database module. The BoltDB package is widely adopted in the Go ecosystem, with 8,367 packages dependent on it, according to the blog. After the malware was cached by the Go Module Mirror, the git
tag was strategically altered on GitHub to remove traces of malware and hide it from manual review. Developers who manually audited github.com/boltdb-go/bolt
on GitHub did not find traces of malicious code. But downloading the package via the Go Module Proxy retrieved an original backdoored version. This deception went undetected for more than three years, allowing the malicious package to persist in the public repository.
Socket has petitioned to have the package removed from the module mirror and reported the threat actor’s GitHub repository and account, which were used to distribute the malicious boltdb-go
package. This attack is among the first documented instances of a bad actor exploiting the Go Module Mirror’s indefinite caching of modules, according to Socket. To mitigate software supply-chain threats, Socket advised that developers should verify package integrity before installation. They also should analyze dependencies for anomalies, and use security tools that inspect installed code at a deeper level. Google, where Go was designed, could not be immediately reached for comment about the issue on February 5.
Digma Preemptive Observability Analysis engine tackles AI code bugs 5 Feb 2025, 8:06 pm
Digma has unveiled Preemptive Observability Analysis, an observability engine designed to reduce bugs introduced by AI code generation and other coding issues.
The commercial version, introduced February 5, follows a limited-capability free version. Digma said its engine provides engineering teams with code-level insight into the root cause of software development problems while adding AI-driven suggestions to resolve performance issues, architectural flaws, and problematic runtime behaviors. Preemptive Observability Analysis (POA) engine is active during the pre-production testing stage of the software development lifecycle.
In addition to tackling AI-generated bugs, Preemptive Observability Analysis engine also addresses bugs in human-generated code that cause performance issues and SLA (service level agreement) degradations, Digma said. The tool will be particularly transformative for organizations in highly transactional environments such as fintech, e-commerce, and retail, said the company.
Many companies have relied on application performance monitoring tools to highlight service problems, SLA failures, and monitor production status, Digma said. These tools can send alerts when services slow down or fail in production, or when thresholds are breached, but they do not offer insight into the root cause of problems and are limited when used in non-production environments, according to Digma. By shifting the focus to finding issues earlier in the software development lifecycle with preemptive observability, teams can prevent problems rather than deal with their impact later, the company said. Preemptive observability also is intended to help enterprises reduce cloud costs through early identification of performance and scaling issues.
The commercial release of Digma’s Preemptive Observability Analysis engine includes the following capabilities:
- Pattern-based issue identification before code reaches production.
- AI-driven fix suggestions based on runtime behavior analysis.
- Team collaboration insights to prevent code conflicts between teams.
- Cloud cost optimization through early detection of scaling issues.
- Management dashboards for non-coding engineering leaders.
- Sandbox environment for evaluation without deployment.
Is 2025 the year of quantum computing? 5 Feb 2025, 3:35 pm
The year was 1900 and Max Planck was a young physicist working on the problem of blackbody radiation. This was an intense area of research because the experimental data—the radiation emitted by different types of matter as they were heated—disagreed with what had been predicted by classical physics.
Physics at that time was riding a wave of enormous success, and its future in explaining much of the natural world seemed certain. There were just a few loose ends to tie up.
One such loose end was the research showing that, when heated, solid bodies did not emit gradually increasing amounts of radiation in all frequency bands. Worse, if they did, it would create even greater problems in the form of infinite energy, the ultraviolet catastrophe. Desperate for a solution, Planck used experimental data to construct a mathematical model that worked, even though it violated centuries of scientific thinking.
The result was the idea that energy comes in discrete levels or packets, what Planck called quanta. This produced his famous constant and gave birth to an entirely new kind of physics: quantum mechanics.
It would be several decades yet before computing began to take shape, so there was no way for Planck to foresee its strange and almost mystical intersection with quantum science. Nonetheless, quantum computing, as we know it today, is indebted to his work.
The limits of traditional computing
Classical computing really took off with the Von Neumann architecture in the 1940s. Since then, it has pressed onward with ever smaller transistors and ever more clever designs for wringing performance and efficiency out of matter. Although this has produced astonishing advances and hitherto unimaginable capabilities, certain classes of problems remain resistant, even in theory.
For example, take the ancient and easily understood problem of prime factorization for large numbers. This problem on sufficiently large integers—say, with 2,048 bits—would take even a top-of-the-line supercomputer several billion years to crack.
Prime factorization isn’t just a mathematical puzzle of interest to theorists. Much of the security of the Internet rests on problems of this kind.
Modeling uncertainty
Traditional computers are Boolean constructs at heart. Fundamentally, they acknowledge yes/no states. Much of the power of modern AI systems is in layering stochastic, random, or probabilistic engines on top of this base. The reasoning is that much of the world is fuzzy, and therefore only amenable to statistical approximations.
But for hard mathematical problems, only overcoming the basic hardware model will suffice. What’s needed is a computer that does not just say yes or no, but gives a likelihood. Such a computer would be able to model otherwise unknowable areas of the universe. Quantum computing does this by replacing transistor bits with subatomic particles called qubits.
To understand how this works, we need to follow Planck’s idea of quanta through its evolutionary trajectory in Einstein’s ideas about light quanta and onto the realm of Heisenberg’s uncertainty principle, where we begin to wrangle with interpreting the experimental data of subatomic physics.
When faced with the uncertainty principle, even hard-nosed scientists are forced to confront a philosophical question: Does the uncertainty found in experiments stem from the physical world, from our relationship to it, or from our senses and minds? In other words, is such uncertainty ontological or epistemological? (Heisenberg himself preferred the term indeterminate.)
The Copenhagen interpretation of quantum mechanics essentially says: let’s not try to decide, let’s just continue to do good science.
The promise of quantum computing
One of the best ways to appreciate the scientific predicament of quantum mechanics is in the split-beam or double-slit experiment. Remaining in the realm of thought experiments, but trusting that experimental physicists are expressing valid truths, the basic idea is that a photon (a subatomic particle) will exhibit different characteristics, depending on how you look at it. If you look at a photon before it hits the detectors, it’ll act like a particle; otherwise, it’ll act like a wave.
What is good for photons goes for all subatomic particles and all their properties. The uncertainty principle is a framework, a circumscribed line around our understanding that tells us what it’s possible to know. One cannot know both the location and speed of a subatomic particle. Finding one value makes the other undiscoverable with accuracy. Push and pull as we might—and scientists have pushed and pulled mightily—the world of the subatomic remains obscure. Wherever it enters the realm of sensible phenomenon, a subatomic particle’s behavior becomes probabilistic.
But perhaps these strange properties could be useful. What if we could use the nature of such particles to make vast statistical calculations, relying on the physical properties of matter itself?
That is the promise of quantum computing. The difficulty is in nailing down these particles in a way that makes sense. Holding them in a usable state is alone a huge engineering challenge. Some particles, like neutrinos, are very stable but hard to get into an interactively useful state. Others, like protons and neutrons, are interactive but highly volatile, and susceptible to decoherence.
Decoherence is the transition of phenomenon from the subatomic to the macro world. Some quantum mechanics interpretations draw a firm line along this boundary, essentially dividing the universe into two realms. What quantum computing must do is somehow put the question to the particles while they remain coherent in the quantum world, and then guide them to decoher into our macro world in a way that we can output sensibly.
This is the challenge of creating interfaces between macro detectors and traditional computing resources, and the developing quantum computing infrastructure.
Quantum computing in the real world
As quantum computing research gradually inches toward real-world usability, you might wonder where we’ll see the impacts of this technology, both short- and long-term.
One of the most immediately important areas is cryptography. Since a quantum computer can take on many states simultaneously, something like factoring large numbers can proceed in parallel, relying on the superposition of particle states to explore many possible outcomes at once.
There is also a tantalizing potential for cross-over between machine learning and quantum computing. Here, the probabilistic nature of neural networks and AI in general seems to lend itself to being modeled at a more fundamental level, and with far greater efficiency, using the hardware capabilities of quantum computers. How powerful would an AI system be if it rested on quantum hardware?
Another area is the development of alternative energy sources, including fusion. Using matter itself to model reality opens up possibilities we can’t yet fully predict. Drug discovery and material design are also areas of interest for quantum calculations. At the hardware level, quantum systems allow us to use matter itself to model the complexity of designing useful matter.
These and other exciting developments, especially in error correction, seem to indicate quantum computing’s time is finally coming. But there’s a huge amount of work still to be done to move towards usable systems—and then there will be even more work to make it all practical for everyday users. What we will likely see is the emergence of hybrid computing models, where cloud systems rent quantum computing resources that contribute their unique powers to the overall system.
The quantum disruption is coming
To understand where we are in this tale, consider Google’s recently announced breakthrough with the Willow chip. The critical takeaway here is that engineers have successfully built a quantum system that reduces errors as the number of qubits are scaled up. Error checking is essential in all computer systems but it’s especially so in quantum systems, where decoherence is always nipping at particles, threatening to cause them to lose their entanglement by interaction with the macro environment.
It’s also important to note that Willow scaled up to an array of 7×7 physical qubits. That’s still a pretty modest size, even though it does open up impressive capabilities. There will come a moment when quantum computing makes the leap from experimental projects to being a useful computing resource. It probably won’t be 2025, but the quantum disruption is coming. It is such an exploratory area of research that it’s hard to predict its impact.
On the philosophical side, you might wonder what quantum says about the nature of reality. Not only do quantum experiments point to something entirely different from causation as we know it, but it’s possible to build machines that utilize this characteristic. A quantum computer essentially takes an object while it’s in an unknown condition (framed by probabilities) and proposes a question to it. We then decipher the question back to its known state, where it’s possible to derive useful data from that “trip into the unknown.”
Quantum hasn’t fully arrived, but there’s every reason to believe it’s coming. Technologists should keep an eye on the quantum space. Watch for where and when the quantum industry makes itself felt in the areas you are engaged with. Be ready to leap when the time comes.
Databricks acquires BladeBridge to aid data warehouse migrations 5 Feb 2025, 10:40 am
Data lakehouse provider Databricks has acquired data platform modernization software provider BladeBridge for an undisclosed sum to help its new customers move from rival data warehouses, such as Teradata, Snowflake, Amazon Redshift, and Microsoft SQL Server, to its lakehouse built atop Databricks SQL.
The New York-headquartered firm will provide enterprise customers with insights into the scope of conversion, configurable code transpiling, LLM-powered conversion, and easy validation of migrated systems, Databricks top executives wrote in a blog post.
How does it work?
BladeBridge, which has four major products in the form of an Analyzer, a Converter, the Data Recon module, and a Studio, said it expected enterprises will save “months of work by automatically building a summary of all extract, transform, load (ETL) and database assets in just a few hours.”
The Analyzer provides a full report of the migration’s scope and complexity, while also automatically conducting query testing between the rival database and Databricks SQL to identify discrepancies for early remediation, Databricks and BladeBridge explained in a joint statement.
After conducting an analysis, the Converter starts converting the rival data warehouse into Databricks SQL by using a configuration-driven approach that is expected to account for differences between the legacy architecture and Databricks SQL.
“The approach ensures that customers retain full ownership of the conversion patterns, so configurations can always be updated if new requirements emerge at later stages of the migration,” the companies said, adding that BladeBridge’s AI-driven conversions account for all legacy ETL, SQL, and other code.
In order to accelerate the conversion process with configuration instructions, BladeBridge uses an iterative process, the companies said.
“When unit tests fail for any component, the configuration files are simply adapted to resolve the errors,” they explained.
Why did Databricks acquire BladeBridge?
Databricks wants to increase its revenue by offering its customers lower costs and lower risks in the process of migrating their legacy data warehouses to its own proprietary platform.
BladeBridge claims that it provides an AI-based approach to help migrate to at least 20 different data warehouses and ETL tools 50% faster than traditional approaches.
BladeBridge has strong ties with system integrators, such as Accenture, Capgemini, Celebal Technologies, and Tredence, with proven deployments across “hundreds of customers.”
Databricks’ future roadmap and plans
Without specifying a particular date, the company said that it plans to make BladeBridge and its related products freely available to enterprises and partners.
Databricks also has plans to scale BladeBridge expertise to other system integrators, it said, adding that it sees the acquisition contributing to its goal of reaching a $3 billion revenue run rate and being free cash flow positive in the fourth quarter ending January 31, 2025.
The acquisition of BladeBridge comes just after Databricks closed its $15 billion Series J financing round that saw new and existing investors, such as Temasek and QIA invest $10 billion. As part of that round, the company closed a $5.25 billion credit facility led by JPMorgan Chase alongside Barclays, Citi, Goldman Sachs, and Morgan Stanley.
The company, after the close of the funding round, had said that it would use the new capital towards building new AI products, acquisitions, and expansion of its international go-to-market operations, while also providing liquidity.
The lakehouse provider, which is currently valued at $62 billion, has been acquiring companies to expand its offerings.
Last year in March, the company acquired Boston-based Lilac AI to help enterprises explore and use their unstructured data to build generative AI-based applications. In June 2023, Databricks acquired LLM and model-training software provider MosaicML for $1.3 billion to boost its generative AI offerings.
Cloud development environments for the win 5 Feb 2025, 9:00 am
About 30 years ago this week, Delphi 1.0 was released. Many of you probably have no idea what Delphi is, but it was a revolutionary rapid application development environment tool. Delphi made developing Windows applications orders of magnitude faster than it had been before.
Delphi wasn’t a trivial application itself, and it was decided to deliver it on a CD-ROM (remember those?). As far as I know, Delphi was the first major software application to be shipped on a CD-ROM instead of on floppy disks, though floppies were available for purchase — all 32 of them. There were, of course, protests about it, because at the time, CD-ROM drives were fairly new and not ubiquitous.
Delphi continued to grow in complexity and capability. Eventually, the installation filled a DVD, but Delphi outgrew that and required a long download process to install.
That complexity was made even greater because the IDE could be configured with components, code libraries, and IDE plugins. Eventually, it wasn’t uncommon for things to become so complex that it could take a week to install and set up a new developer. There were packages to install, directory paths to set, code to be properly located, relative paths to be configured, and many, many other small details to consider and set.
Other development environments like Eclipse or Visual Studio were no different. There were enough variations to all of it that no two development environments were precisely identical. The saying has been around for a long time, but this complexity is the root of the infamous saying “But it works on my machine.” (To which the response is, “Well, let’s ship your machine, then!”)
A significant advancement
But that was the bad old days. Today, things are very, very different. That is not to say that “package hell” isn’t a thing. Package managers like npm
and brew
have made things much better, but even they can lead to problems with versioning and other challenging complexities.
One of the differences today is that the notion of developing in a browser is a real thing. Because the most popular coding tool — Visual Studio Code — is written in TypeScript, it can rather easily be modified to run in a browser. And because it can be configured with code, and because modern development languages are configured in code as well, it becomes relatively easy to deliver a specific configuration with a specific version of an application to you in a browser. This is a significant advancement in how software development is done.
The first thing this enables is for a software developer to work anywhere on almost any computer that has a browser. You can, if need be, go to any public library and fix a production bug in your application. You can log in, bring up a cloud development environment of your project, and work on it, all in a browser. No more spending a week to get set up. And instead of lugging around a heavy laptop, developers can work on something light like a Chromebook.
Beyond that, the ability to take a snapshot of “my machine” so that it can be shared and leveraged in different scenarios is incredibly powerful. Consider this scenario… You are assigned a bug, and in the bug report is a link to the exact, precise environment in which the bug was reproduced. You click on that link and the development environment is immediately configured, enabling you to reproduce the bug in minutes instead of hours or days.
Or maybe you want to pair program with a junior developer to help her fix an issue, but you live six states apart. With a cloud development environment, you can both look at — even share — the same development environment. And because the bug is easy to reproduce, you can find a fix much faster. That same feature can get a brand new employee up and running in minutes, not days.
Upsides and a few downsides
And if you are concerned about the security of your code base, imagine a scenario where that code base never resides on a laptop that leaves your building. Leaving a laptop in an Uber no longer becomes a worry.
Software supply chain security becomes much easier to manage as each development environment is approved and provided to each team member. You don’t have to worry any longer about a team member installing a malicious package via typosquatting.
While all this is great, there are a few things to be concerned about. First, cloud development environments can make it hard to set up customizations and special, one-off solutions that some developers may require. If you depend entirely on browser-based development environments, you may find yourself at the whim of a sketchy airline internet service and other internet access struggles. If network latency is a problem, it can make working online sluggish and frustrating.
There have been a few changes in how software development systems function since the days of buying development tools off the shelf and installing them from floppy disks. Cloud development environments have made things vastly easier to set up while increasing productivity and flexibility. Developing in the browser is only going to get better as innovations continue to bring new features and ideas to the table.
How to make lightweight Docker images (and keep them slim) 5 Feb 2025, 9:00 am
It’s a challenge keeping Docker images from bulking up unnecessarily. A single base image, a couple of RUN
commands, and before you know it, you’re looking at an image weighing 200 MB or more. Is all that tonnage really necessary?
Odds are you can make the images you build a good deal more svelte with only a little work, and without losing any real functionality. This guide walks through six ways to create slender Docker images and keep them that way.
Start from scratch
The most basic Docker image you can create, scratch
, isn’t actually an image but an empty container that you can fill with whatever your application needs. Starting from scratch (or scratch
) may seem like the way to create a minimal image, and in many cases, it can be. But this approach comes with a few pitfalls.
First, scratch
makes no assumptions at all about what your application needs. If your app consists of a single binary with no dependencies—for instance, a Go application—then the scratch
image will work. But the vast majority of applications have some kind of runtime dependency: a linked library, maybe, or perhaps even a certificate.
Don’t assume that just because the application launches and runs, it’s fully functional. Omissions like a missing linked library can ambush you if you’re not testing for their presence. This is a particularly big issue in dynamic languages like Python, where without tests you get no warning something is missing until you need it.
If you’re avoiding starting from scratch
because you tried it and ended up with something that didn’t work, don’t assume you need to throw in everything plus the kitchen sink (and countertops) to get it working. You may be able to begin with a runtime designed to start with the minimal requirements for the language or runtime you’re employing.
Use a ‘slim’ runtime image
For many applications written in languages that require a runtime, you can use a “slim” runtime image for the language. These are prebuilt images that contain the bare minimum of what’s needed to launch and run an application written in the given language.
It’s worth saying again that slim images only give you what’s needed to support the runtime itself, not your particular application. For instance, if you have a Python application that needs third-party packages from PyPI, you must add those as part of the image build process (RUN pip install
, etc.).
Another good source for slender base images, built for specific use cases, is the Google Distroless Image collection. They’re built on top of stripped-down instances of Debian Linux, run on multiple architectures, and offer included runtimes for Python 3, C-compiled programs, Java (including versions 17 and 21), and Node.js (versions 18, 20, and 22). They don’t contain shells or package managers, so you must configure your Dockerfile’s ENTRYPOINT
so it won’t attempt to use a shell (e.g., ENTRYPOINT ["start"]
instead of ENTRYPOINT "start"
) or supply arguments to the language runtime configured as the default.
Use multi-stage builds
A convenient way to automatically minimize the amount of space used when building is the multi-stage build process. Multi-stage builds use multiple FROM
statements in the Dockerfile. Each successive FROM
lets you begin with a completely new container image, which you can then populate selectively with artifacts created from the previous FROM
build process.
This trick works best when you have, for instance, some kind of software build process as part of the procedure. Much of what’s left over after the build process isn’t needed, so you can discard it and just copy out the needed bits into a new, empty image.
Another very nice feature of multi-stage builds: stages can be named and re-used across the build process. And the resulting images can be saved and re-used, or harvested from selectively, for future projects.
Minimize layers
Each distinct RUN
command in your Dockerfile creates a new layer in your image. You’ll want to consolidate as many of those commands as possible when layering in your application’s requirements. You don’t have to try to do this at first; it’s something you can discover incrementally, as you experiment with the best set of RUN
instructions to get your container together.
You can also use the third-party docker-squash tool to “squash” together two or more layers in an image. Or, again, you can use the multi-stage process to “scrape” a given build stage to only what’s needed, then populate a new, empty stage with that.
Use .dockerignore
A .dockerignore file, like its cousin in Git (.gitignore
), lets you screen out files and directories from the build process. In some ways this is the opposite approach from a multi-stage build: instead of cherry-picking what to include from an existing image, you’re describing what to leave out of an image that is yet to be built.
Anything ephemeral or irrelevant to the runtime is a good candidate for being filtered out: Git repositories, temporary directories, build artifacts, downloaded archives (from which other things are unpacked), and so on. This way, you don’t have to clean the build directory ahead of time, which risks losing the advantage you get from caches or local copies. You can just omit them from the build.
You can get pretty granular with .dockerignore
, in the same way you can with .gitignore
, so you can use it to do things like ignore all files in a directory except a particular one. You may also find it useful to programmatically generate .dockerignore
as part of the build process if you’re dealing with a complex and changing set of possible filters.
Use tooling to inspect and alter existing images
Various tools exist for inspecting existing Docker images and seeing what’s there, or taking an image and minifying it by runtime analysis.
The dive tool lets you take a Docker image and break down its contents layer by layer. For each layer you can see the changes made from the previous layer, and get an estimate of how efficient (or inefficient) each layer’s space usage is. If an image has a lot of wasted space or redundancies, dive
can reveal that quickly.
A more powerful tool, Slim, now a CNCF Sandbox project, performs runtime analysis on a container to determine what’s being used and what’s not. Its creators boast that Slim can reduce images by orders of magnitude in size, although your mileage will vary. But it’s worth experimenting with for the xray
function alone, which can generate a reverse-engineered Dockerfile from a container. That’s a handy way to rethink how a container is assembled without needing to see its sources.
Smart Traffic Enforcement: Kazakhstan’s Qorgau System in Action 5 Feb 2025, 8:57 am
Traffic management is a growing challenge for cities worldwide, requiring a balance between enforcement, efficiency, and public trust. In Kazakhstan, the Qorgau system is redefining road safety through an innovative fusion of artificial intelligence (AI), computer vision, and mobile technology. Designed to assist traffic police in real-time violation detection and enforcement, Qorgau represents a leap forward in smart policing.
A digital approach to safer roads
Since its implementation, the impact has been substantial. Road accidents in Kazakhstan have decreased by 30%, and the number of injured individuals has dropped from over 500 in 2019 to 338 in 2023. At the same time, the system has streamlined the collection of traffic fines, raising compliance rates from 50.5% in 2017 to 88.1% in 2023. These improvements demonstrate the power of digital transformation in public safety.
Qorgau’s mobile-first approach equips traffic police with a digital tool that integrates seamlessly with the country’s broader law enforcement infrastructure. The system uses AI-driven cameras to scan traffic in real time, detect violations such as speeding, running red lights, and improper lane usage, and immediately flag offenders. The results are sent to police officers’ tablets, allowing for quick decision-making without unnecessary vehicle stops. This minimizes congestion and eliminates subjective enforcement, ensuring fairer and more efficient policing.
Beyond enforcement, Qorgau contributes to preventive policing. The system logs vehicle movement data, helping officers identify patterns in high-risk areas and anticipate violations before they occur. This approach aligns with global smart city initiatives, where data-driven decision-making enhances public safety while reducing administrative burdens on law enforcement.
Laying down the digital foundation is key
However, deploying such an advanced system comes with challenges. The need for 24/7 monitoring, secure data transmission, and AI-driven analytics required significant investment in digital infrastructure. Additionally, ensuring officers were properly trained to use the system was critical for its effectiveness. These challenges were addressed through close collaboration between Kazakhstan’s Ministry of Internal Affairs and technology partners, resulting in a fully integrated and highly efficient solution.
The success of Qorgau highlights a broader global trend in intelligent transportation management. Many cities worldwide are turning to AI-powered systems to optimize traffic flow, improve air quality, and reduce road fatalities. Countries like Singapore and the UAE have pioneered similar initiatives, leveraging smart sensors and data analytics to create safer and more efficient urban environments.
Looking ahead, Qorgau is poised for further expansion. Enhancements in facial recognition, automated ticketing, and AI-driven pattern analysis will further streamline operations, while the possibility of integrating the system with autonomous vehicle networks could redefine the future of road safety. As Kazakhstan continues to embrace digital transformation, Qorgau stands as a leading example of how technology can bridge the gap between enforcement and public service.
Curious to learn more about Qorgau and its impact on Kazakhstan’s road safety?
Kazakhstan’s Qorgau system is setting a new standard for smart traffic management and public safety. For an in-depth look at its technological framework, key successes, and what lies ahead, download the full report: Global Trends in Smart Traffic and Transportation
AWS tightens default security on Redshift 5 Feb 2025, 3:14 am
Amazon’s security improvements for its AWS Redshift managed data warehouse service are welcome additions, says an expert.
Loris Degioanni, chief technology officer at Sysdig, told InfoWorld that AWS’s enhanced security defaults for Amazon Redshift are a “necessary evolution for the accelerated cloud adoption we’ve seen across organizations with varying security expertise. Secure configurations are the first line of defense, and by enforcing best practices from day one, these changes reinforce the shift-left mindset Sysdig has long championed. However, security doesn’t stop at strong defaults — continuous monitoring, risk prioritization, and real-time threat detection are critical.”
Redshift allows organizations to store and analyze their data using their choice of business intelligence tools. According to HGInsights, just over 27,700 organizations use Redshift.
The changes
The three changes are in Redshift’s default settings for newly created clusters, Redshift Serverless workgroups, and clusters restored from snapshots:
- Public accessibility to data has been disabled. Newly-created clusters will be accessible only within a customer’s virtual private cloud [VPC]. If an administrator needs public access, they must explicitly override the default and set the “PubliclyAccessible” parameter to “true” when running the “CreateCluster” or “RestoreFromClusterSnapshot” API operations. Note that if Redshift applications are in a VPC other than Amazon’s, customers can configure cross-VPC access.
With a publicly accessible cluster, AWS recommends admins always use security groups or network access control lists (network ACLs) to restrict access; - Database encryption is enabled by default. In other words, the ability to create unencrypted clusters in the Redshift console is gone. When an admin uses the console, CLI, API, or CloudFormation to create a provisioned cluster without specifying an AWS Key Management Service (AWS KMS) key, the cluster will automatically be encrypted with an AWS-owned key. The AWS-owned key is managed by AWS.
- Secure connections are enforced by default. This enforces encryption of communication between a customer’s applications and the Amazon Redshift data warehouse to help protect the confidentiality and integrity of the data being transmitted between the customer’s applications and Amazon Redshift.
A new default parameter group named “default.redshift-2.0” is created for newly created or restored clusters, with the “require_ssl” parameter set to “true” by default. New clusters created without a specified parameter group will automatically use the “default.redshift-2.0” parameter group, which will be automatically selected in the Redshift console. This change will also be reflected in the “CreateCluster” and “RestoreFromClusterSnapshot” API operations, as well as in the corresponding console, AWS CLI, and AWS CloudFormation operations.
For customers using existing or custom parameter groups, Redshift will continue to honor the “require ssl” value specified in the customer’s parameter group. However, AWS recommends that admins update this parameter to “true” to enhance the security of connections. Admins still have the option to change this value in their custom parameter groups as needed. The procedure is outlined in the Amazon Redshift Management Guide for configuring security options for connections.
Amazon also noted that those creating unencrypted clusters by using automated scripts or using data sharing with unencrypted clusters could be impacted by the changes. “If you regularly create new unencrypted consumer clusters and use them for data sharing, review your configurations to verify that the producer and consumer clusters are both encrypted to reduce the chance that you will experience disruptions in your data-sharing workloads,” it advised.
Asked why these changes are being made, Sirish Chandrasekaran, Redshift’s vice-president, said the additional security defaults will help customers adhere to best practices in data security from day one without requiring additional setup, reducing the risk of potential misconfigurations.
Out of the box, Redshift comes with a number of security capabilities, including support for multi-factor authentication, encryption for data at rest, access control and identity management and federation for single sign-on. But these and other tools are useless unless they are used and properly configured.
Recommendations
In a series of blogs, Palo Alto Networks made a number of recommendations to Redshift admins:
- make sure they know exactly which users and roles have the ability to use the command “redshift:GetClusterCredentials” and “redshift-data.” An attacker can use this command to generate temporary credentials to access a Redshift cluster;
- Redshift admins can create users and groups and assign them only the privileges they need. Admins should create a user per identity, so in the event of a security incident, it’ll be possible to track and monitor what data was accessed, or even prevent unauthorized access before it happens;
- because Redshift can authorize identity and access roles that allow a data cluster to access external data sources, make sure these roles are limited to only those who need this access.
Palo Alto Networks also provided more detail on access control in a blog post, and Sysdig offered this advice on Redshift security best practices.
Finally, Sysdig’s Degioanni provided this additional caution: “While cloud providers provide a level of security for their underlying infrastructure and services, organizations remain responsible for protecting their own applications and data under a shared responsibility model. Because attacks can happen quickly — sometimes within minutes — having real-time visibility into production workloads is crucial for detecting active risk and responding to threats as they occur.”
Page processed in 1.258 seconds.
Powered by SimplePie 1.4-dev, Build 20170403172323. Run the SimplePie Compatibility Test. SimplePie is © 2004–2025, Ryan Parman and Geoffrey Sneddon, and licensed under the BSD License.