Category: Uncategorized

Posted on mongodb google news. Visit mongodb google news

Analysts estimate that the big data sector will expand at a CAGR of 13.5% between 2022 and 2030. By the latter year, the sector’s sales will come in at a huge $745 billion. Moreover, forms of AI such as machine learning can spot patterns across large volumes of data. And these patterns, in turn, can produce insights which enable firms to more effectively recruit customers, develop better products and increase their productivity. Given these points, big data and the companies that can extract it will become increasingly valuable over the longer term. Here are three strong buy big data stocks.

MongoDB (MDB)

Source: Michael Vi / Shutterstock.com

MongoDB (NASDAQ:MDB) has created a popular document-oriented database. The firm charges for its cloud-based database, called Atlas, based on the amount of data which its customers utilize. Moreover, Atlas has become very popular among users of the public cloud, Atlas’ revenue is already growing at an annual clip of nearly 33%. And it already generates 68% of the company’s overall sales.

Given these points, I believe that Atlas’ growth will greatly accelerate in the medium and long-term as the amount of data consumed by cloud users increases exponentially in order to support their use of AI. And the acceleration of Atlas’ gains, in turn, should enable the growth of MongoDB’s top and bottom lines to accelerate a great deal as well, enabling MDB stock to outperform.

MongoDB’s PEG ratio was a reasonably attractive 1.46 times as of January 2024. Given MDB’s rapid growth and attractive valuation, I view the shares as one of the best strong buy big data stocks.

Datadog (DDOG)

Source: Karol Ciesluk / Shutterstock.com

Datadog’s (NASDAQ:DDOG) monitoring and analytics platform for cloud applications enables its customers to analyze large volumes of data from various sources.

On March 14, Bank of America identified DDOG as one of its “bull stocks,” saying that the shares were undergoing a “‘head and shoulders’ bottom breakout” that could take the shares to $172.

Last quarter, the company’s EPS soared 79% year-over-year to 44 cents. Also noteworthy is that its EBITDA came in at $31.7 million, versus an EBITDA loss of $31.6 million in Q4 of 2022. The huge jump indicates that DDOG, like MDB, is beginning to benefit meaningfully from the proliferation of AI.

I expect the latter trend to intensify in the longer term. Supporting that conclusion, DDOG CEO Olivier Pomel recently stated that the utilization of DDOG’s offerings by AI-focused companies is growing quickly.

Oracle (ORCL)

Source: Jonathan Weiss / Shutterstock.com

Database software giant Oracle (NYSE:ORCL) is starting to market AI applications. Specifically, on March 14, the firm unveiled AI tools that will enable its customers to generate data-driven insights. The company correctly noted that with these insights, its customers will be able to improve their businesses. As a result, I believe that the demand for these offerings will be strong.

Also noteworthy is that on March 18 ORCL announced a partnership with Nvidia (NASDAQ:NVDA). Under the deal, the two firms will jointly market Oracle’s AI and cloud offerings, along with Nvidia’s chips and software. Given the huge enthusiasm for Nvidia’s products, the deal should meaningfully increase Oracle’s orders and revenue going forward, as governments and companies will be much more likely to buy Oracle’s systems if they are paired with Nvidia’s products.

Meanwhile, the Street appears to be becoming more upbeat on ORCL stock, as two investment banks recently upgraded the shares in the wake of the company’s Q4 results.

Argus raised its rating on the name to “buy,” citing the firm’s rapidly growing cloud revenue. The company’s cloud infrastructure revenue jumped 49% last quarter versus the same period a year earlier, excluding currency fluctuations. Argus placed a $145 price target on ORCL stock.

Another investment bank, William Blair, raised its rating on the shares to “outperform,” The bank was impressed by the 41% year-over-year increase in the company’s remaining performance obligations, and it expects Oracle’s revenue from AI users to increase meaningfully going forward.

On the date of publication, Larry Ramer did not have (either directly or indirectly) any positions in the securities mentioned in this article. The opinions expressed in this article are those of the writer, subject to the InvestorPlace.com Publishing Guidelines.

Article originally posted on mongodb google news. Visit mongodb google news

Article originally posted on InfoQ. Visit InfoQ

This week’s Java roundup for March 25th, 2024 features news highlighting: JEP 466, Class-File API (Second Preview), targeted for JDK 23; milestone releases of Jakarta Data and Jakarta NoSQL specifications; the second release candidate for JobRunr 7.0.0; and point releases for Spring projects, Quarkus, Helidon and LangChain4j.

OpenJDK

After its review has concluded, JEP 466, Class-File API (Second Preview), has been promoted from Proposed to Target to Targeted for JDK 23. This JEP proposes a second round of preview to obtain feedback from the previous round of preview: JEP 457, Class-File API (Preview), delivered in JDK 22. This feature provides an API for parsing, generating, and transforming Java class files. This will initially serve as an internal replacement for ASM, the Java bytecode manipulation and analysis framework, in the JDK with plans to have it opened as a public API. Goetz has characterized ASM as “an old codebase with plenty of legacy baggage” and provided background information on how this draft will evolve and ultimately replace ASM.

JDK 23

Build 16 of the JDK 23 early-access builds was made available this past week featuring updates from Build 15 that include fixes for various issues. Further details on this release may be found in the release notes.

Jakarta EE

The fourth milestone release of the Jakarta Data 1.0.0 specification features notable changes such as: removal of the countBy() method from the BasicRepository interface as it was a magical method name query and considered awkward; replace Sort by Sort where appropriate to allow sorting by a member of a super entity; and a new method, elements(), added to the inner Cursor interface, defined in the PageRequest interface, that automatically packages elements as an unmodifiable list. More details on this release may be found in the changelog.

Similarly, the first milestone release of Jakarta NoSQL 1.0.0 specification features notable changes such as: removal of the Document, Key-Value and Column Family APIs as they are now maintained in Jakarta Data; and the addition of new annotations, @MappedSuperclass, @Embeddable, @Inheritance, @DiscriminatorColumn and @DiscriminatorValue for improved support of NoSQL databases. More details on this release may be found in the changelog.

Spring Framework

Spring Cloud 2023.0.1, codenamed Leyton, has been released featuring bug fixes and notable updates to sub-projects: Spring Cloud Kubernetes 3.1.1; Spring Cloud Function 4.1.1; Spring Cloud OpenFeign 4.1.1; Spring Cloud Stream 4.1.1; and Spring Cloud Gateway 4.1.2. This release is based on Spring Boot 3.2.4. More details on this release may be found in the release notes.

The release of Spring for GraphQL 1.2.6 delivers bug fixes, improvements in documentation, dependency upgrades and new features: recommended use of the PERSISTED_QUERY_MARKER field defined in the GraphQL PersistedQuerySupport class to avoid a GraphQL AssertException due to persisted queries that don’t contain standard queries; use either first or after arguments to determine forward pagination in conjunction with the last and before arguments to determine backward pagination. This version will be shipped with the upcoming releases of Spring Boot 3.1.11 and 3.2.5. More details on this release may be found in the release notes.

Quarkus

The release of Quarkus 3.9.1 provides notable changes such as: the new naming strategy for Quarkus reactive extensions; support for OIDC Client JWT Bearer authentication; and an initial release of the new declarative Quarkus WebSockets extension. More details on this release may be found in the changelog.

Helidon

The release of Helidon 3.2.7 features notable changes such as: a replacement of the deprecated the overloaded from() methods, defined in the Multi interface, with corresponding create() methods; and a replacement of the deprecated readTransaction() and writeTransaction() methods, defined in the Neo4j Session interface, with the executeRead() and executeWrite() methods, respectively, in the Neo4jHealthCheck class. More details on this release may be found in the changelog.

Similarly, the of release of Helidon 2.6.7 ships with notable changes such as: a refresh of the MicroProfile Fault Tolerance static method cache upon CDI shutdown; support for disabling security providers through configuration; and a resolution to a NullPointerException from a disable feature in the OidcSupport class. More details on this release may be found in the changelog.

Open Liberty

IBM has released version 24.0.0.3 of Open Liberty featuring: enabling of default verbose garbage collection on IBM Java and IBM Semeru Runtimes; support for back-channel logout on OpenID Connect clients and servers; and a resolution to CVE-2023-50312, a vulnerability in IBM WebSphere Application Server Liberty versions 17.0.0.3 through 24.0.0.2 that could provide weaker-than-expected security for outbound TLS connections caused by a failure to honor user configuration.

Apache Software Foundation

Versions 10.1.20 and 8.5.100 of Apache Tomcat ship with notable changes such as: ensure that the URI, query string and protocol are not corrupted when restoring a saved POST request body after a successful FORM authentication; and align error handling for the Writer and OutputStream classes to ensure the use of either class once the response has been recycled triggers a NullPointerException provided that discardFacades is configured with the default value of true. For the milestone release, the team decided to reduce the minimal Java version to JDK 17. More details on these releases may be found in the release notes for version 10.1.20 and version 8.5.100.

The release of Apache Camel 4.5.0 provides bug fixes, dependency upgrades and new features such as: the creation of new Camel Milvus, Camel Qdrant and Camel AWS Bedrock components to support the Milvus and Qdrant vector databases and AWS Bedrock, respectively; and improved support for the bind command in Camel JBang with the ability to set properties and enhanced error handling. More details on this release may be found in the release notes.

Eclipse Foundation

Versions 4.5.7 and 4.4.9 of Eclipse Vert.x 4.5.7 both deliver notable changes such as: a resolution to CVE-2024-29025, a vulnerability in Netty versions before 4.1.108.Final by which an attacker can send a chunked post consisting of many small fields that will be accumulated, with no limits, in the bodyListHttpData list; and a resolution to Vert.x building its virtual thread factory at runtime with the correct reflection calls. More details on these releases may be found in the release notes for version 4.5.7 and version 4.4.9.

The release of Eclipse JKube 1.16.2 provides notable fixes such as: the addition of a JKubeBuildStrategy field in the WatcherContext class to throw an exception if using a Kubernetes Watch (k8s:watch/k8sWatch) in a buildpacks build strategy; the OpenShift Maven plugin generates a YAML file with a route target port that doesn’t correctly map to the target port causing a Kubernetes pod that is not accessible through the route if the service port is different than the target port. More details on this release may be found in the release notes.

TornadoVM

TornadoVM 1.0.3, the third maintenance release, delivers bug fixes and improvements such as: support for multiple Java threads running different instances of the TornadoVM execution plans; new API extensions to query and apply filters to backends and devices from the TornadoExecutionPlan class; and support for the TornadoNativeArray class data types to obtain memory segments without the header offset. More details on this release may be found in the release notes.

JobRunr

The second release candidate of JobRunr 7.0.0, a library for background processing in Java that is distributed and backed by persistent storage, features bug fixes, enhancements and new features: the ability to configure a shutdown period of BackgroundJobServer class; access to labels via JobContext class; and use of the Spring Data Redis LettuceConnectionFactory class to obtain an instance of the Lettuce RedisClient class. More details on this release, including information about the version 7.0.0 GA release on April 9, 2024, may be found in the release notes.

LangChain4j

Versions 0.29.1 and 0.29.0 of LangChain4j have been released providing notable features such as: advanced retrieval augmented generation (RAG) with Azure AI Search; support for function calling Mistral AI; and a new module to support AWS Anthropic Claude on Bedrock. More details on these releases may be found in the release notes for version 0.29.1 and version 0.29.0.

Java Operator SDK

The release of Java Operator SDK 4.8.2 features: a resolution to pruning issues of fields being delivered from the server by ignoring server-managed fields for server-side apply (SSA) matching; and improved integration tests by increasing the timeout from 20 to 40 minutes. More details on this release may be found in the release notes.

MicroStream

The release of MicroStream 8.1.2 provides code cleaning and adjustment for direct byte buffers in order to avoid possible VM crashes due to a removed check in G1GC in JDK 21.0.2. More details on this release may be found in the release notes.

Posted on mongodb google news. Visit mongodb google news

Pacer Advisors Inc. raised its holdings in shares of MongoDB, Inc. (NASDAQ:MDB – Free Report) by 1,400.8% in the 4th quarter, according to its most recent 13F filing with the SEC. The fund owned 3,632 shares of the company’s stock after acquiring an additional 3,390 shares during the period. Pacer Advisors Inc.’s holdings in MongoDB were worth $1,485,000 at the end of the most recent reporting period.

A number of other large investors have also made changes to their positions in MDB. Raymond James & Associates increased its position in shares of MongoDB by 32.0% in the 1st quarter. Raymond James & Associates now owns 4,922 shares of the company’s stock valued at $2,183,000 after buying an additional 1,192 shares in the last quarter. PNC Financial Services Group Inc. boosted its stake in MongoDB by 19.1% in the 1st quarter. PNC Financial Services Group Inc. now owns 1,282 shares of the company’s stock worth $569,000 after purchasing an additional 206 shares during the period. MetLife Investment Management LLC acquired a new position in MongoDB in the 1st quarter worth $1,823,000. Panagora Asset Management Inc. boosted its stake in MongoDB by 9.8% in the 1st quarter. Panagora Asset Management Inc. now owns 1,977 shares of the company’s stock worth $877,000 after purchasing an additional 176 shares during the period. Finally, Vontobel Holding Ltd. boosted its stake in MongoDB by 100.3% in the 1st quarter. Vontobel Holding Ltd. now owns 2,873 shares of the company’s stock worth $1,236,000 after purchasing an additional 1,439 shares during the period. Institutional investors own 89.29% of the company’s stock.

MongoDB Stock Down 0.0 %

MongoDB stock opened at $358.64 on Monday. The stock has a market cap of $25.89 billion, a P/E ratio of -144.61 and a beta of 1.24. The company’s 50-day moving average price is $414.58 and its two-hundred day moving average price is $390.12. The company has a quick ratio of 4.40, a current ratio of 4.40 and a debt-to-equity ratio of 1.07. MongoDB, Inc. has a twelve month low of $198.72 and a twelve month high of $509.62.

MongoDB (NASDAQ:MDB – Get Free Report) last issued its quarterly earnings results on Thursday, March 7th. The company reported ($1.03) EPS for the quarter, missing analysts’ consensus estimates of ($0.71) by ($0.32). The business had revenue of $458.00 million for the quarter, compared to analyst estimates of $431.99 million. MongoDB had a negative return on equity of 16.22% and a negative net margin of 10.49%. As a group, analysts expect that MongoDB, Inc. will post -2.53 EPS for the current year.

Analyst Ratings Changes

A number of equities analysts recently weighed in on the stock. KeyCorp upped their target price on shares of MongoDB from $500.00 to $543.00 and gave the stock an “overweight” rating in a research note on Wednesday, February 14th. JMP Securities restated a “market outperform” rating and set a $440.00 price objective on shares of MongoDB in a research note on Monday, January 22nd. Citigroup increased their price objective on shares of MongoDB from $515.00 to $550.00 and gave the stock a “buy” rating in a research note on Wednesday, March 6th. UBS Group restated a “neutral” rating and set a $410.00 price objective (down from $475.00) on shares of MongoDB in a research note on Thursday, January 4th. Finally, Guggenheim increased their price objective on shares of MongoDB from $250.00 to $272.00 and gave the stock a “sell” rating in a research note on Monday, March 4th. Two equities research analysts have rated the stock with a sell rating, three have assigned a hold rating and nineteen have issued a buy rating to the company. According to data from MarketBeat, MongoDB currently has a consensus rating of “Moderate Buy” and a consensus target price of $449.85.

Get Our Latest Analysis on MongoDB

Insider Buying and Selling

In related news, CRO Cedric Pech sold 1,248 shares of MongoDB stock in a transaction on Tuesday, January 16th. The shares were sold at an average price of $400.00, for a total transaction of $499,200.00. Following the completion of the transaction, the executive now owns 25,425 shares of the company’s stock, valued at $10,170,000. The sale was disclosed in a legal filing with the Securities & Exchange Commission, which is available through this link. In other MongoDB news, Director Dwight A. Merriman sold 1,000 shares of MongoDB stock in a transaction on Monday, January 22nd. The shares were sold at an average price of $420.00, for a total value of $420,000.00. Following the completion of the sale, the director now directly owns 528,896 shares of the company’s stock, valued at $222,136,320. The transaction was disclosed in a legal filing with the SEC, which is available at the SEC website. Also, CRO Cedric Pech sold 1,248 shares of the business’s stock in a transaction dated Tuesday, January 16th. The stock was sold at an average price of $400.00, for a total transaction of $499,200.00. Following the sale, the executive now directly owns 25,425 shares of the company’s stock, valued at $10,170,000. The disclosure for this sale can be found here. Insiders sold 54,607 shares of company stock valued at $23,116,062 over the last quarter. Insiders own 4.80% of the company’s stock.

MongoDB Profile

(Free Report)

MongoDB, Inc provides general purpose database platform worldwide. The company offers MongoDB Atlas, a hosted multi-cloud database-as-a-service solution; MongoDB Enterprise Advanced, a commercial database server for enterprise customers to run in the cloud, on-premise, or in a hybrid environment; and Community Server, a free-to-download version of its database, which includes the functionality that developers need to get started with MongoDB.

Featured Stories

Want to see what other hedge funds are holding MDB? Visit HoldingsChannel.com to get the latest 13F filings and insider trades for MongoDB, Inc. (NASDAQ:MDB – Free Report).

Receive News & Ratings for MongoDB Daily – Enter your email address below to receive a concise daily summary of the latest news and analysts’ ratings for MongoDB and related companies with MarketBeat.com’s FREE daily email newsletter.

Article originally posted on mongodb google news. Visit mongodb google news

Article originally posted on InfoQ. Visit InfoQ

Recently, GitHub talked about using merge queues to implement code updates. Merge queues have been developed and scaled to manage over 30,000 pull requests, alongside the corresponding 4.5 million CI executions, for GitHub.com.

The merge queue system organizes pull requests into deployable batches, initiates builds and tests through GitHub Actions, and maintains the integrity of the main branch by preventing updates with failing commits, by following branch protection regulations. Conflicting pull requests within the queue are automatically identified and excluded, with the system regrouping as necessary.

Will Smythe, staff product manager, and Lawrence Gripper, staff engineer at GitHub, elaborated on GitHub’s journey with merge queues in a blog post. Aside from increasing developer velocity, the move to merge queues was aimed at enhancing the overall experience for developers in shipping their work, preventing problematic pull requests from affecting the broader team, and ensuring a consistent and highly automated process across all services and repositories.

By mid-2021, GitHub began piloting the merge queue feature with several smaller, internal repositories. They implemented changes to the process in stages, which involved testing and reverting modifications early in the morning before the majority of developers started their workday. Over time, GitHub systematically migrated its large monorepo and all repositories linked to production services to the merge queue system by 2023.

The merge queue blends into GitHub’s existing pull request workflow, eliminating the need for developers to learn specific ChatOps commands, or to utilize labels or particular comment syntax for state management, enhancing GitHub’s developer experience. Developers can easily queue their pull requests and, if they identify any issues with their changes, exit the queue with one click.

Following the general release of the merge queue by GitHub in around Q3 2023, we stumbled upon a relevant discussion on Hacker News. The tech community participated actively in the discussion, with a user highlighting their few months-long uses of the system for monorepo pull request merges, acknowledging its substantial improvements to the process. They also praised the system’s faster ability and reliable trunk-based releases, expressing appreciation towards the team behind the feature.

Another user inquired whether merge queues would be arriving in Azure DevOps anytime soon, indicating interest in its availability. One participant responded in the thread perceiving the lack of updates in Azure Repos and pointing out its continued reliance on ssh-rsa host keys for SSH Git—a protocol deprecated by OpenSSH for several years.

Monthly, more than 500 engineers utilize merge queue to integrate 2,500 pull requests into GitHub’s large monorepo, resulting in a 33% reduction in the average time to deploy a change. In a periodic developer satisfaction survey conducted by GitHub, an engineer applauded the merge queue as “one of the most significant quality-of-life enhancements for deploying changes that I’ve witnessed at GitHub!”

Article originally posted on InfoQ. Visit InfoQ

Databricks launched DBRX, a new open-source large language model (LLM) that aims to redefine the standards of open models and outperform well-known competitors on industry benchmarks.

With 132 billion parameters, DBRX has demonstrated in its own run of industry benchmarks that this model outperforms popular open-source LLMs such as LLaMA 2 70B, Mixtral, and Grok-1 across various language understanding, programming, and math tasks. The new model even competes favorably against Anthropic’s closed-source model Claude on specific benchmarks.

The AI Community expressed excitement about the release of DBRX, with Clem Delangue, CEO at Hugging Face posting on X:

Not a surprise but DBRX is already #1 trending on HF!

DBRX’s performance is attributed to its more efficient mixture-of-experts architecture, making it up to 2x faster at inference than LLaMA 2 70B despite having fewer active parameters. Databricks claims that training the model was also approximately 2x more compute-efficient than dense alternatives.

The model was pretrained on 12 trillion tokens of curated text and code data, leveraging advanced technologies like rotary position encodings and curriculum learning during pretraining. Developers can interact with DBRX via APIs or utilize Databricks’ tools to fine-tune the model on their proprietary data. Integration into Databricks’ AI products is already underway. DBRX is available on GitHub and Hugging Face.

Databricks anticipates that developers will adopt the model as a foundation for their own LLMs, potentially enhancing customer chatbots or internal question-answering systems. This approach also provides insight into how DBRX was constructed using Databricks’ proprietary tools.

To create the dataset utilized in developing DBRX, Databricks utilized Apache Spark and Databricks Notebooks for data processing, Unity Catalog for data management and governance, and MLflow for experiment tracking.

DBRX sets a new standard for open-source AI models, offering customizable and transparent generative AI solutions for enterprises. A recent survey from Andreessen Horowitz, indicates a growing interest among AI leaders to increase open-source adoption as fine-tuned models approach closed-source performance levels. Databricks expects DBRX to accelerate the shift from closed to open-source solutions.

Article originally posted on InfoQ. Visit InfoQ

The creators of DBOS have recently introduced DBOS Cloud, a transactional serverless application platform tailored for TypeScript developers. With all state information stored in a highly available DBMS, this new platform assures transactional serverless computing, offering reliable execution alongside so-called “time travel” capabilities.

Dubbed as “the world’s first cloud-native operating system” and a “database alternative to Kubernetes”, DBOS (DataBase oriented Operating System) implements operating system services in SQL, operating atop a high-performance distributed, transactional, partitioned fault-tolerant database. Michael Stonebraker, computer scientist and a Turing Award laureate, writes:

The idea for DBOS (DataBase oriented Operating System) originated 3 years ago with my realization that the state an operating system must maintain (files, processes, threads, messages, etc.) has increased in size by about 6 orders of magnitude since I began using Unix on a PDP-11/40 in 1973. As such, storing the OS state is a database problem. Also, Linux is legacy code at the present time and is having difficulty making forward progress. For example, there is no multi-node version of Linux, requiring people to run an orchestrator such as Kubernetes.

According to the authors, DBOS Cloud automatically logs every step an application takes and each change it makes in the database. Two distinct features of DBOS Cloud are reliable execution and time travel: in the event of an interruption to the code running on a DBOS program, it automatically resumes from the point of interruption without re-executing any previously completed work. Stonebraker adds:

Providing such guarantees yourself is months of work, but in DBOS, they’re built into every program (…) You can step through past executions to reproduce rare bugs and even run new code against historical state.

Furthermore, a “time travel debugger” enables developers to replay any DBOS Cloud trace locally on a laptop, observe past application states, and test code changes. In the future, the team plans to release a time travel functionality for disaster recovery, enabling developers to roll back an application and its data to any previous state. Jeremy Daly, CEO and founder of Ampt, comments:

What makes this super interesting is that the project was founded by Dr. Mike Stonebraker (he created Ingress, PostgreSQL, and VoltDB) and Matei Zaharia, the creator of Apache Spark.

Peter Zaitsev, founder at Percona and open source advocate, agrees but adds:

Mike Stonebraker does not seem to be a big fan of Open Source for his companies in recent years.

While the team has released an open-source DBOS TypeScript SDK, unlike Ingress, PostgreSQL, VoltDB, or Apache Spark, DBOS itself is not open-source. In a thread on Hacker News, Peter Kraft, co-founder at DBOS, explains:

Under the hood of our cloud platform (mostly Go + SQL), we’re building on ideas from the academic project to provide new features like reliable execution/time travel, but like a good OS, we want to hide that complexity from users.

A free tier and a programming guide covering idempotency and workflow execution on the serverless computing platform are now available. The free tier offers fixed resources per application (a Firecracker microVM with 512 MB of RAM and 1 vCPU) that scale to zero when not in use.

Article originally posted on InfoQ. Visit InfoQ

Many large language models (LLMs) have become available recently, both closed and open source, further leading to the creation of combined models known as Multimodal LLMs (MLLMs). Yet, few or none of them unveil what design choices were made to create them, say Apple researchers who distilled principles and lessons to design state-of-the-art (SOTA) Multimodal LLMs.

Multimodal large language models are built by combining a large language model and a vision foundation model into a single model. MMLMs, which according to Apple researchers “are emerging as the next frontier in foundation models”, aim at consuming image and text inputs to generate text data in a way that outperforms the foundation models they build upon.

Apple researchers focused on two aspects of the process that lead to the creation of MLLMs: decisions about the model architecture and choices for pre-training data.

On the first front, they found that image resolution, visual encoder loss and capacity, and visual encoder pre-training data are the three most important design aspects. On the contrary, architectural decisions regarding how visual data is fed into the LLM do not seem to affect the resulting model performance.

Regarding pre-training, the researchers analyzed three different approaches —image-caption, interleaved image-text, and text-only data— in few-shot, zero-shot, and text-only contexts. Zero-shot models are trained to recognize and classify objects or concepts without necessarily having previously seen any examples of them. In few-shot training, the focus is instead on models that can make accurate predictions based on training that includes only a very small number of labeled examples.

The outcome was that interleaved and text-only training data is key for few-shot and text-only model performance, while caption data is key for zero-shot models.

To prove their results, the researchers built a family of models, dubbed MM1, outperforming current state-of-the-art models, including Emu2, Flamingo, and IDEFICS. Benchmarking was done on captioning, where the model provides a descriptive caption of an image, and visual question answering, where the model answers questions about an image and helps understand its content.

Thanks to large-scale multimodal pre-training […] MM1 enjoys appealing properties such as in-context predictions, multi-image and chain-of-thought reasoning. MM1 also enables strong few-shot learning capability after instruction tuning. These strong results demonstrate that the presented recipe for building MLLMs translates the design principles to a competitive model at scale.

As the researchers explain in their paper, to get these levels of performance with MM1, they investigated different image encoders as well as ways of connecting them to LLMs; different types of data and how to set weights; and how to train the MLLM, including its hyperparameters. Their results include insights such as the importance of image resolution, model size, training data composition, and so on, which they hope can provide a solid foundation for the community to build stronger models across multiple architectures and data strategies.

Article originally posted on InfoQ. Visit InfoQ

Transcript

Hartshorne: I’m here to talk about a time in Honeycomb’s life. As a company, we had been around for several years and the business was slowly growing. We were getting more customers. As the traffic grew, some scaling issues come up, and they are managed. This is great. We could keep growing and a different thing comes up, and it’s managed. As the pace of growth goes along, these things happen. Each time, there are side effects that push out a little bit further. What you wind up with is a system that is still there and working well, and just creaking. It starts to push its boundaries more frequently in different ways. It’s not patterns, it’s rough. We saw as a business, we wanted to grow. We’re realizing that what got us to that part in our company’s life would not get us to the next one. I would like to talk a little bit about how we managed that.

Background

My name is Ben Hartshorne. I’m a Principal Engineer at Honeycomb. I worked on this talk with Jess Mink. They joined Honeycomb as a senior director of platform engineering when we were facing this. They started, and we said, “We would like to double the size of our business, please help.” We needed to get a lot of work that was on the periphery here, somehow scheduled in the face of growing the business and increasing the product, and everything else. The thesis is relatively straightforward. A compelling business case is what will get your work scheduled. We need to understand, what does a compelling business case look like? How do we get there? How do we ensure that we can do this for technical work? Because the company has been growing and the product organization has been growing, and there’s more sophistication around deciding what we should build. We need to match that.

Understanding Priorities

I want to start by thinking about what does it mean to understand priorities, just a little bit. It’s a truism in the startup world and probably in all of the business world, that there’s always more work than you can possibly do. There’s this herd of features out there, they are beautiful. They are product ideas. They’re things you can do, new things you can build, ways you can improve. They all must go through this gate of your engineering capacity. You can only do so much work. We’re starting from this perspective of there’s no way we can do everything. The engineer’s view on this herd is on the inside of this fence. There’s this line of beautiful work coming in at you, it is full. You have your roadmap. You have all of your work queued up. You have the new products to build, the existing ones to improve. You look at this and you think, how can I possibly do the work that I see that we need to do in order to maintain this business? When do I schedule this? Can we close the gate for a little bit so we can sweep the entrance? That’s hard. Take for a moment the other perspective, the product managers, the ones who are creating this curated list of things for you to do. This is their view. They see this enormous pile of things they would like to build, ways the business can improve, and they’re not going anywhere. Why isn’t engineering doing our work? They ask. They see this as an enormous opportunity, and need to figure out, engineering has the capacity that they do. We need to understand which sheep to offer them, which are going to make it through the gate first. This is a little bit about what they do.

Let’s imagine this sheep in the front here. This sheep in the front will reduce your hosting costs by 20%. Very good sheep. We should do this. Any project that might show up has to be considered in the context of what the business is doing, what’s currently going on everywhere. Imagine we are a primary color company who does some web search, and we have the opportunity to reduce our hosting costs by 20%. This is a career making move. This is going to happen. It doesn’t matter really. It matters a little bit how much it costs. This is a project that is absolutely going to happen. Picture this middle group here, classic startup scene, early in their business, they have the same opportunity to reduce their hosting costs by 20%. Their hosting cost is what, like $300 a month? No, you’re not going to do that. Then there’s all of the states in between where your business might be in a merger, or it might be in a reorg, or there might be something going on. You have this obvious benefit, reduce hosting costs, but it’s really not clear whether you should do it. If the reorg isn’t a complete, and the entire product that’s being hosted there is going to be disbanded, no, don’t go spend time reducing the costs to host it. The same project, the same decision, the same idea may get a very different result depending upon what’s going on in the rest of the business.

What’s the Prioritization Process?

Let’s look a little bit more at how to choose which of these things to do. It’s not always quite so simple as an enormous cost reduction. Product management has come up in this track before. There are sophisticated tools to help product managers take this enormous mountain of ideas and input and form it into the things that they’re going to present for engineering, to understand whether or not one of these things should be done. This input comes in many forms. There’s feedback from customers. There’s ideas sprouted from anywhere, really. There’s appreciation for a specific aspect of your business. All of these come together. They come in separately, but they need to be understood to be representations of a thing that the business does, a service that it provides, a problem that it’s solving. You can look at each of these different bits, whether it’s a piece of customer feedback that comes in, and try and reframe it so that it is shaped like a problem that the business is fulfilling. This process is managed for every one of those sheep we saw. What we wind up with is this enormous corpus of data about all of the different problems that we are confronting as a business, which ones affect our customers in one way or the other. Some of them are blocking new customers. Some of them are allowing the expansion of existing customers. Each one has this depth to it that has been accumulated by the product organization.

Once you get an understanding of these ideas, you can try and tease them apart into a couple of categories. There’s the obvious good, the obvious bad, the big, squishy middle. I particularly love this graph. I first came across it in a workshop by a guy named Jeff Patton. When I went to look for the image that he used, found he credited it to a graph called Constable’s truth curve, which was in fact presented here at QCon in 2013. On the left there you have the size of a bet you’re willing to make for this particular piece of work. On the top, going across is how much you expect to get from that. Let me give you an example. I have a new feature that is going to make you several millions of dollars as a business. It’s going to take quite a lot of time. It’s up there with the green dollar sign. You ask me, “So you’re proposing this thing. We recognize all development is a bet. How confident are you? You say it’s going to bring in this much money? What’s the likelihood you’re wrong?” I say, “I think it is, and if I wrong, I’ll buy you a cup of coffee.” Maybe don’t take that bet. The green is equally clear. You have some relatively easy task that has a very clear return. You’re very confident, there’s no question about whether this would benefit the business. I’m willing to give you my car if I’m wrong. Yes, we should do that. That’s in the nice green section up there. The squishy middle is like most of everything else. We need tools to help us explore these ideas and better understand where they fit. In hopes of pushing them out of that squishy green middle, into one of the other edges. There are a couple of good thought organizing frameworks out there. These is just two samples, an opportunity canvas, a learning canvas. They’re both ways of taking your understanding of the problem, of the people it will help, of the people it might not help, of the cost, structuring it in a way that facilitates some of this conversation.

Ultimately, the goal of this process is to clarify the ROI, the return on investment of any given piece of work. We need to find out who this work will influence, who it will impact, how much, and how much those users care about this particular thing. If it makes a big difference to some aspect that they never use, maybe not so important. A big part of the process of product management is understanding all of these questions. I’ve spent a while talking about this, it seems like a lot of work. We’re here to talk about tech debt. The thing is, yes, it is expensive, and software is more expensive. This has come up a couple of times in this track too. Engineers are expensive. Engineering efforts are expensive. I don’t want to just focus on us as individuals doing this work. You’ll hear somebody say, this is about one engineers’ worth of salary for a year or two for this project. If it’ll take us three months, we should do it, that sort of thing. That’s not enough. There’s a metric out there published by a number of public companies, it represents revenue per employee. We’re beyond engineering here, it’s not revenue per engineer, revenue per employee. This is what each employee of the company represents in terms of value that they’re building in order to bring the company to a good place. If we do a little quick math, engineering is usually maybe 30%, 35% of the company. Look at those numbers a little bit. We’re talking about a million dollars per engineer, in terms of the revenue they’re expected to generate through their work. For high performing companies, this is even higher, $2 million to $5 million.

Our time is expensive, it is worth a lot. We need to recognize that in order to value the work that the product organization has been putting into how they’re curating all of those sheep and to choose which ones they’re going to let through this gate. They are putting an enormous amount of respect on our teams, in order to choose the most impactful projects for us to build. When we think about tech debt, we think about a thing that we need to do that’s outside of this regular stream of work. We think that our piece of work should jump the queue. “This database upgrade is important. We have to do it.” Do we? Maybe not. What’s the business value? What’s the return? How can we measure this piece of work and this feature in the same language, the same framework as all of this effort that’s been put towards the rest of the work that is coming to us from the rest of the organization? Hang on to that question for a moment.

Recap (Understanding the Priorities)

We talked about, obviously, we can’t do all the work and the prioritization, we’re going to base strongly in a business case. Both the return we get for doing the work, also the cost of the investment we put into doing the work, and then that balance. The balance between those must exist in the context of the business and what’s important for the business at that time. The cost of the work, very good.

Selling the Impact or Your Project

Let’s talk about what we get back. What are we going to get for this project that we need to do? We’ve seen our work queues look like this. We need to upgrade the thing. We need to move the other bit. We need to refactor this. You all know what this is. This is tech debt. We can tell. We look at it, we see, yes. In order to focus it back on the business, so I want to think a little bit more about what tech debt is. It’s hard to say what tech debt is, so let’s answer the easier question instead. What do we do here? This is a wonderful graph, the VP of Engineering at Honeycomb put up in a blog post, understanding what goes into engineering work. On the left side, we have all the things that are customer facing, the features we actually build. Also, customer escalations and incident response, bug fixes. On the right side is all of the stuff that’s behind the scenes. Customers only see that part when something goes wrong: toolchains, refactors, training, testing, compliance, upgrades. Let’s split it the other way, up top. We think engineers are responsible for writing code, that’s true. The stuff up top, this is in code. This is adding new features, removing features. It’s also the upgrades. On the bottom, we have all of the attributes of running a system that are in production that are not in code. This is going to be part of your CI/CD system and your deploys, your training, your QA. Also, your incident response, the things you need to do that are part of owning your work in a modern software SaaS system. All of this is part of an engineer’s regular job.

Which one is tech debt? I think of tech debt normally in terms of refactoring of dependency upgrades, of work that you have to do in order to reform the product to fit some new business shape. Really, every category outlined in red here can be described as technical debt. I loved one of the examples from yesterday about doing a feature flag triage and leaving your feature in there just long enough so that you can reuse your feature flag when you’re putting in the next one. You delay the removing some code. It’s not just the stuff in the back. It’s not just the stuff that you think of in terms of refactoring. There’s a problem here, when we’re using a term so consistently, and we all have different definitions, it really muddies the conversation. When I’m talking to somebody, and I say, here’s this piece of tech debt, we need to spend some time on it, and they hear something that’s in a completely different portion of the circle. It does not aid the communication. Perhaps we can just stop using the term. We’re going to need to talk about work in a business context anyways. The goal of this workflow is the same as getting it on the roadmap.

Language is Important

As engineers, one of the things that we do is translate language that we see into understanding how that will affect us and our systems. There’s an observability company out there whose website has a big banner on the front, “Find your most perplexing application issues.” When I look at that, when we as engineers look at that, we’re like, how? I want to fit that into my product. I want to understand how I can rely on it, where I can rely on it. Where it will help me, where it won’t. How do you do this? What is it? We’ll make a translation in our head. Honeycomb is a tracing product. I believe it is a good example of what goes on in our heads. This translation is very useful when we’re building systems. When we’re trying to explain business value, it leads us to talk about, we need to upgrade the database. Not so helpful. We’re here to flip that around a little bit. As we are trying to understand how to prioritize and schedule the work that we see within engineering, we need to understand how to switch from talking about what it is that we need to do, upgrade the database, and start talking about why we need to do it so that we can connect it back to this business case. Sometimes that takes a couple of tries. We talked about needing to upgrade this database. Or maybe not. Do we, really? Let’s ask the team, why do we need to upgrade this database? They tell us, actually, it’s hitting its end of life. It’s an EoL database, we need to get off of it. Do we, really? It’s still serving our queries. In this mythical world, even that isn’t good enough. Let’s say that our hosting provider says, we will not run EoL software, so you have four months, and then we are shutting it off. Now we see, ok, what happens when they shut off our database? The entire product stops working. We need to upgrade that database, because we want the product to continue. If you go to your sales reps and say, would you like our product to stop working next September? They will say, no, please schedule the work you need to do. I would like you to fix that, how can I help? Who should I talk to? I will help you get this work scheduled, because it is clearly connected to ensuring that the business can continue. Hosting providers usually don’t go in there and flip off your database just because you’re running an EoL version of MySQL.

I want to tell another story. This one’s a little different, because I didn’t actually get the business case until after it had happened. We were running an old version of a LaunchDarkly library. LaunchDarkly does feature flagging. It was fine. It worked. There was one team that they had some extra time, they upgraded it, they had a thing they wanted to try. There was a shift in the model of this library from thinking about a user as the thing that manages a flag, to thinking about a context. Intentionally more broad. The context pulls in all sorts of other attributes of where this flag is being executed. This team used that to flag on their feature for a single node and get a very nice comparison graph. This was awesome. Within just a short period, many other teams were doing the same thing and getting to see, ok, I can do a percentage rollout, rollback. I can flip it on to these. We were used to only flipping it on and some of the data that is more relevant to our application, it opened up a whole new window. We saw, we can safely canary changes in a way that we couldn’t. We can do A/B testing in a way that we couldn’t. This is amazing. If we had been able to see that business case that we can make our engineering teams able to deploy their software more safely, more quickly, with more confidence around the change, yet better understanding of the impact of the change, we would have been able to prioritize that work. It was lucky that it was not so much effort and that one team had the space to make it happen. This idea of finding the business case in order to do the work, sometimes it takes some effort to understand what is going to happen with this. That can feel a little squishy.

Back It with Data

We are engineering teams here. We have a magical power. We can create data. We can find data. Our systems give us data. If they don’t have the data we need, we can make changes to those systems. We can commit code to get more data. We can use this to back up all of our arguments. When we get one of these conversations like, I think it’s going to do this, and someone else says I think it’s going to do that. We can find out. SLOs, top of the list there. They’re my favorite tool for mapping business value back to a technical metric, because in their formation, they are representing the experience of the user. They’re encoding, what does it mean for a given experience to be successful or not? How many of those experiences are we allowed to have fail? Over what period of time before we hit a threshold where our users and our customers get angry and leave?

I would love to spend the rest of the time talking about SLOs. Liz Fong-Jones did a talk, it’s published on InfoQ, on production excellence with a fantastic segment on SLOs. They’re not alone in our sources of data, we have all of our metrics showing various limits of our services. We get to do chaos experiments. When we have a service, and we’re not quite sure what that limit is, and we need to know more, we can artificially constrain that service in order to push its boundaries and find out what we would otherwise find out in an incident, six months down the road. Of course, there are those incidents. They really are two sides of the same coin. I don’t want to leave out qualitative surveys. Often a piece of technical engineering work that fits into this category of tech debt may feel like its target is not a specific amount of money for the business, but facilitating one’s experience in a certain part of the code base. There’s this idea of haunted graveyards, the section of the code where people fear to tread, because it’s dangerous, it’s complicated. Cleaning those up is valuable, to allow the business to move forward. Some qualitative surveys can really lend credence to this as you ask your engineers, how was it to build this new feature? How was your feature flag experience? With all of this data, it’s easy to fall back into those old habits. We need to upgrade the database because the CPU is too high. Who cares? You got to bring it back in business context, take that language about the CPU is too high and translate it to, what effect will that have on our ability to run our business? We’re back to our list here. We want to get this work prioritized. To do so, we understand what is important to the business here, now. We take the projects we need to do that we see are obvious and understand how to translate that into something that’s based on impact, rather than the technical change that we wish to make. We find the data we need to back it up.

I want to take you back to the Honeycomb experience of a year and a half ago, with this system that has been growing, and it’s starting to creak and fail in other interesting ways. Let’s run this playbook. Let’s see what happens. Start with understand the priorities. Honeycomb is a SaaS business. We are software as a service. ARR rules everything, this is annual recurring revenue. This is how much people are paying us, whether it’s monthly, or yearly. It includes people that decide to leave, and end their contract with Honeycomb. It is a big deal. ARR is this number that we have on our fundraising decks that we talk to the board about, that we make projections for. This is what we are organizing our business around, saying we’re going to get to this amount of revenue and we’re going to do it in this amount of time. I know there are many talks here about reducing costs and expanding revenue. For many SaaS companies earlier in their life, the balance is heavily skewed towards revenue. ARR is the thing, so let’s use it.

We get a dollar number of our ARR target, but that doesn’t translate to upgrading a database. By talking to the sales and product team, we get more detail, because this number is such a big deal, there’s a lot of research and work that goes into building it. It’s not just a number. It’s not just throwing a dart or watching a curve and saying, we’re going to make it there. No, they know we’re going to get this many customers of this type and we’re going to see these many upgrades and we’re going to see this many folks leave. All of this comes together to form that top line number. It’s wonderful that we have descriptions of who we’re going to get, still doesn’t help because I don’t know how to work with dollars but they have more answers. When I ask, ok, you’re getting 10 more enterprise customers, what does that mean? Which of our current customers can I model this after? How are they going to use our product? They came back with answers. They’re like, ok, this group of customers, they’re going to be focused more on ingestion and they’re going to use fewer of these resources. These other ones over here, they’re going to be more of a balance. Those ones there are going to be very heavy on the API. Now we’re getting onto my turf. We’re getting to numbers that I can see, the numbers that I have grasp about. I can now use this information to connect it back to the business value that’s going to come from each of those things. We need to take this data and map it to our infrastructure. Honeycomb is a macroservice architecture. We have a smallish number of relatively large services, they’re all named after dogs. We’re applying these to our infrastructure here.

How Does This Service Scale?

For each of these teams that have a dog under their care, we ask these teams, please spend some time understanding your service, writing about your service, and reflecting upon how it fits in here. Start with just an overview of the service. Then think about where the bottlenecks are, how the service scales. Then look at the sales targets that we covered that we have these numbers for, and write down which ones of those are applicable to your service. Maybe ingestion matters, maybe it doesn’t, depending on what the service consumes, who it talks to. Some are important, some aren’t. This is where we involved all of engineering. Every team did this. It didn’t take all that long. Our SRE team is already embedded in each of them, and they helped by guiding them through some of these processes to write down and give a unified format to these reports. As an example, our primary API service, this is the front door of Honeycomb’s ingestion. It accepts all of the telemetry from our customers. It does some stuff to it, authentication, authorization, validation, transformation. It sends it along to the downstream service, which is a Kafka cluster, for transmission to our storage engine. It has some dependencies. It depends upon a database for authentication tokens. It depends upon a Redis cluster for some rate limiting and things. The upstream services are our customers. The downstream services, it’s Kafka. The sales target affecting the service is clear. It’s the telemetry that our customers are sending us. When thinking about how it scales, it is a standard horizontally scaling service, stateless. These are the canonical scaling things. It can grow as wide as it wants, almost. Through some past experience, both planned and unplanned, we’ve discovered that as the number of nodes grows, the load on the database grows. When we get to about 100, the database starts to slow down, which means you need more nodes, which makes the database slow down, and it goes boom. That is clearly a scaling limit. We have it written down.

Now comes the fun question. We found the scaling limit. That’s great. We have to fix it, obviously. Maybe? Let’s take these sales targets and say, where are we going to be on this curve of our sales target? When are we going to hit this scaling limit? Is it within the next year? Do we need to fix it now? Is it a problem for future us? Let’s decide. For this one, as it turns out, we expect it to hit that volume by mid-year. The database thing was one that we had to focus on. We got this whole report, it did highlight the database load that we will hit before reaching our sales targets, also called out a couple other ones, and some that we don’t really know about. Those are a cue for running some chaos experiments, or other ways of testing our limits.

The Business Case

The business case came down to this one. It was very clear. We could go back to our sales team and say, we need to schedule some work to mitigate the load on this database as the service scales out. If we don’t, we will not hit the sales targets that you gave us. The answer is very easy. Yes, please schedule that work. How do we need to do it? We did this for all of our services and came up with a lovely Asana board showing some things to fix, some things to care about now. Some things that are probably relevant in the year. Some that aren’t clearly like yes or no, but might extend the runway, so we can keep them in our back pocket and understand that if we see something creeping up, that’s a thing we can do to make it work. There’s one tag, it’s called explody. You’ll see the label explody on some of these.

As an organization, there’s this fun side effect to this exercise that we got to talk about a couple of things that we don’t always cover in the regular day-to-day engineering. Explody is one of them. That’s a description of this API service horizontal scaling thing that I was talking about. It grows and you don’t really see much until you get to that threshold and then boom, everything comes crashing down. Those problems are scary and huge. Also, you don’t usually have a lot of time to react between once that cascade starts and when you hit the boom. It helps you understand a little bit about how to schedule that kind of work, the non-explody ones. As an example, if you have a service that runs regularly scheduled jobs, once per minute you run a job. Over time, that job takes longer, until it takes like 65 seconds. When it’s overlapping, the next one doesn’t start. That’s not explody. Some jobs won’t run, most will. It will degrade, but it will degrade slowly and it will degrade in a way that you can go back to those SLOs, and use that to help you figure out when to schedule it. Equally important problem, slightly different method of scheduling.

The last bit here, I don’t know how many of you have had a conversation with somebody when designing a system. We look at this diagram and this architecture and say, “No, that can’t scale. No, we can’t do it this way, that won’t scale.” It’s a struggle, because, yes, maybe it won’t, but do we care? Will the system work for us for now? There’s the classic adage of don’t design things the way Google does, because Google has 100 million times your traffic, and then you will never encounter those problems. If you follow that design, you’re doing yourself a disservice. These scaling problems, which ones to ignore, this mapping of sales targets to scaling limits is a very strong way to have that conversation and make it very clear that from the business perspective, we can wait for that one.

Close the Loop

We caught ourselves a strong business case, using the priorities of the business, time to fix some of these problems, and the choice to put some of the other ones off. We are now done. We have gotten this work scheduled, almost. There’s one more step here, which isn’t so much about getting the work scheduled in the first place but is about making our jobs as an engineering team, especially in a platform, a little bit easier the next time around. We need to celebrate. We need to show the success of this work that we’re doing. When we find one of these projects, and we finish it, we need to make it very clear that we put engineering effort towards a business problem in a way that has given us the capacity to grow the business in the way that we need to. Then, when we have finished it and it’s gone on, and we pass that threshold that was previously impossible, we can call it out again and say, remember this? Yes, we couldn’t have gotten here without it. This stuff is really important. It lends credence to our discussions in the future about what’s going to be happening when we have more technical work to schedule.

The last one, this was a fun experience from a near miss incident. There were some capacity issues, and we were struggling to grow the capacity of the service quickly enough. During the course of this near miss, one engineer bemoaned, it takes 3 whole minutes to spin up new capacity for this service. This engineer had been at Honeycomb for a couple of years, but that was still recent enough that they didn’t remember the time before we were in a Kubernetes cluster, when new capacity took 15 minutes to spin up. We put up a big project here. We’re going to change the way we’re doing our capacity and the way we run our services. We’re going to set a target of 10 minutes for new capacity, and new services to come up. No, let’s be aggressive, let’s set it to 5. Here we were recognizing it takes 3 whole minutes? This is great. This is amazing material because it gives us an opportunity to reflect on where we’ve come. For a lot of the platform work, for a lot of the tech debt work, that work is almost invisible. We need to find ways to bring it to light so that we can see as an organization the effect that this work is having on our longevity, on our speed, on our ability to deliver high quality software.

Summary

This is the recipe for getting technical debt work onto the roadmap. Understand what your business needs. Understand the impact of the projects you need to do to reduce that technical debt. Own the success of that business. Frame it in a way that is communicating that priority, not just the technical work. Use our power of data to back it up. Remember to ensure that you talk about the effect it had once you’re done, and that effect has been realized the business is exceeding those limits that it previously saw.

Questions and Answers

Participant 1: You didn’t bring one thing that was establishing a shared language or a shared vocabulary or framework for presenting the business benefits and things. What about scenarios where you have potential security issues? A scenario where I need to upgrade the library, because there is the potential for every bonus point on x. At which point now you’re just projecting what the potential damage should be. How do you solve that?

Hartshorne: How do we express security concerns in the language of business impact? I will admit, our security team is very good at that. I am not so good at it. There are a couple of ways. For larger businesses, there are frameworks that they’re required to operate under for security. There are agreements that one makes with both sub-processors and with customers around the response time to certain types of issues. You can use that to build an argument. If we are contracted to respond to a security incident within 30 days of being notified, we have to. You were asking about upgrading libraries because of potential flaws. That is definitely fuzzier. I was talking about how projecting projects that you’re going to make are bets. How much are you willing to bet that this is going to have that impact. Is it a cup of coffee? Is it a house? Framing security in terms of bets, it carries a little bit of a different feel to it. Yet, that is what’s going on. None of our services are 100% secure. We are doing risk analysis to understand which risks we are willing as a business to undertake and which we’re not. Do we have the recourse of the legal system if this particular risk manifests? Our business, and I think most businesses do have large documents describing their risk analysis for the current state of the world. The risks from inside, the risks from outside, the risks from third-party actors and so on. I think all of those are tools one can use to better assess the risk of a particular change. Those all come straight back again to business value.

Participant 2: I’ve often found that one of the hardest types of tech debt problems is to get to move on, to get buy-in. It’s the kind of problem where the benefit you’re going to get from solving it is freeing up your engineers to improve the velocity. You’re not solving tasks that really should be automated, but the amount of work to do and to automate it is going to take a couple weeks. We don’t do it, and in exchange for that sometimes we do it manually once every couple weeks, and it takes us few days to do it. It’s like an inducible cost from outside of the engineering organization, because you know that it’d free up a whole lot more engineering bandwidth to work on features and other things as a part of [inaudible 00:45:51]. I’m wondering if you have any thoughts on how to frame that as a business objective that would actually [inaudible 00:46:00].

Hartshorne: How do we schedule work that is toil that our engineers are doing successfully, because the job is getting done? There are a couple of ways. The first I want to highlight is the product philosophy of incremental improvements, shipping the smallest thing. There’s a wonderful diagram of how to build a car. One path starts with a set of wheels, and then a frame, and then some shell, and then the engine. At the end of it, you have a car, which, great, you can’t do anything until you get all the way to the end. The other says, maybe start with a skateboard, graduate to a bicycle, maybe a motorcycle, and finally, you’ll make your way to the car. I reference this, because a lot of those types of toil tasks can have small improvements that incrementally transform the task. As an example, you might start with a person that needs to roll the cluster by hand, and they go through and they kick each server in turn, and on they go. Simply writing that down in clear language, forming a checklist for it makes the next version faster. You can take two of those checkboxes and transform them into a script and it makes it faster. Each one of those is significantly easier to find the time to do than the entirety of the toil. That’s the first one.

The second is to bring up again, the idea of qualitative surveys. We ask our on-calls, every time they start a shift, and every time they finish a shift, a number of questions. It’s a light survey. Did you feel prepared for your shift? Do you think the level of alerting we have is too little too much, just about right? What came up during this shift? Did you feel stressed about any particular bit? What was the hardest part of this shift? Collecting those on a quarterly basis gives us some really good and unexpected insight into some of the types of toil that are coming up. Maybe it’s a flappy alert. Maybe it’s some service that needs to get kicked and need some improvements in its operational controls. Those are data. We can use those to say, our on-calls are spending 40% of their time chasing down false positives. This is wasted effort. That brings it back to expensive engineering time, and is, I think, a pretty good road into a compelling argument to spend some time improving the situation.

See more presentations with transcripts

Article originally posted on InfoQ. Visit InfoQ

Subscribe on:

Apple Podcasts
Google Podcasts
Soundcloud
Spotify
Overcast
Podcast Feed

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

Article originally posted on InfoQ. Visit InfoQ

HashiCorp recently released version 2.3 of Terraform Cloud Operator for Kubernetes with a new feature: the ability to initiate workspace runs declaratively. The Terraform Cloud Operator for Kubernetes was introduced in November 2023 to provide a Kubernetes-native experience while leveraging Terraform workflows.

The Terraform Cloud Operator allows users to manage Terraform Cloud resources with Kubernetes Custom Resource Definitions (CRD). This operator allows the users to provision infrastructure internal or external to the Kubernetes cluster directly from the Kubernetes control plane.

The Key Benefits of Terraform Cloud Operator are:

• Flexible resource management: Version 2 introduces multiple custom resources with dedicated controllers for various Terraform Cloud resources, enhancing flexibility and performance for managing custom resources concurrently in large-scale deployments.
• Namespace management: Tailor the operator’s watch scope to specific namespaces using the --namespace option, enabling fine-grained resource management tailored to your organizational needs.
• Configurable synchronization: Adjust the synchronization frequency between custom resources and Terraform Cloud with the --sync-period option, ensuring timely updates and operational smoothness.

In previous iterations of the Terraform Cloud Operator v2, initiating a run was limited to patching the restartedAt timestamp within the Module resource. This method proved non-intuitive, lacked universality across workspace types, and offered no control over run types, hampering migration efforts. However, version 2.3 addresses these challenges by enabling users to declaratively commence plan, apply, and refresh runs on workspaces, thereby empowering developers with enhanced self-service capabilities across all Operator-managed workspaces, including VCS-driven ones.

Version 2.3 introduces three new annotations within the Workspace custom resource to facilitate workspace run initiation:

• workspace.app.terraform.io/run-new: Set to true to trigger a new run.
• workspace.app.terraform.io/run-type: Control the run type (plan, apply, or refresh).
• workspace.app.terraform.io/run-terraform-version: Specify the Terraform version for speculative plan runs.

This is an example of Workspace Resource and Annotation:

apiVersion: app.terraform.io/v1alpha2
kind: Workspace
metadata:
  name: this
spec:
  organization: kubernetes-operator
  token:
    secretKeyRef:
      name: tfc-operator
      key: token
  name: kubernetes-operator

To immediately initiate a new apply run for the above workspace resource using kubectl:

kubectl annotate workspace this 
    workspace.app.terraform.io/run-new="true" 
    workspace.app.terraform.io/run-type=apply --overwrite

After successful execution, the annotation is reflected in the Workspace resource for observability:

apiVersion: app.terraform.io/v1alpha2
kind: Workspace
metadata:
  annotations:
    workspace.app.terraform.io/run-new: "true"
    workspace.app.terraform.io/run-type: apply
  name: this
spec:
  organization: kubernetes-operator
  token:
    secretKeyRef:
      name: tfc-operator
      key: token
  name: kubernetes-operator

Post-run completion, the operator automatically resets the run-new value to false.

With Terraform Cloud Operator v2.3, initiating and managing workspace runs becomes more intuitive, empowering teams to efficiently manage infrastructure while embracing Kubernetes-native experiences.