Ensure robust security and secure access to sensitive data for Spring Boot applications using YugabyteDB’s advanced security features, including TLS encryption, and native cloud secret management services like AWS Secrets Manager, GCP Secret Manager, Azure Key Vault, or Hashicorp Vault.
Blogs by: Srinivasa Vasu
This blog provides a guide to building Spring Boot applications with YugabyteDB using GraalVM’s ahead-of-time (AOT) compilation to generate a native image. The guide covers the necessary prerequisites and steps to trigger the native build, including how to handle dependencies lacking reachability metadata with explicit runtime hints.
There is now support for YugabyteDB in Testcontainers. This blog explores how to use Testcontainers to write integration tests for a Spring Boot application with the Yugabyte database.
Learn how to best use Query Planner hints in the YugabyteDB database to optimize business queries based on how applications expose them. Walk through a use case that utilizes data sets from two popular TV shows to find total viewership per season, episode, etc.
Log aggregation is an integral part of a distributed system. As the name suggests, a distributed system will have multiple processes across multiple machines, and each process will generate a lot of data. Looking at the data in silos is time-consuming and wouldn’t yield important information as the data sets still need to be correlated. But aggregating the logs is a huge productivity booster that helps to transform the raw log data into insightful information.
Change Data Capture (CDC) is a technique to capture changes in a source database system in real-time. The goal is to stream those changes as events through a data processing pipeline for further processing.
CDC enables many use cases, especially in modern microservices-based architecture that involves a lot of bounded services. It is the de-facto choice for use cases such as search indexes, in-memory data cache, real-time notifications, data sync between sources,
GitOps is an operational framework for declarative-driven systems such as Kubernetes. More specifically, it provides a set of best practices that converge the runtime state of the services with the declarative state defined in Git. On the other hand, Argo CD is a declarative, continuous delivery tool for Kubernetes. Argo CD follows the GitOps pattern of using Git repositories as the source of truth for defining the desired application state. Both tools can be used for automation workflows.
Developer onboarding and experience gets simplified every day. But while developers use many modern software development techniques—including 12-factor, cloud native, and continuous integration—developer onboarding remains a challenge. Therefore, what developers need is an integrated, self-contained platform that helps them get started with ease.
Gitpod is one such way we can steer into that problem space to create a better developer experience. More specifically, Gitpod provides git-based, fully automated, integrated cloud-native development workflows with the prerequisites configured.
Java is the quintessential language runtime for enterprise applications built on monoliths, microservices, and modular architecture patterns. But when it comes to “Enterprise Java,” Spring is the de facto framework of choice.
The Spring ecosystem—with the simplicity of Spring Boot—has grown to provide integration touchpoints to a majority of the Java ecosystem. For starters, it offers a clean abstraction and “glue” code to build cohesive enterprise applications. However,
The evolution of “build once, run anywhere” containers and Kubernetes—a cloud-agnostic, declarative-driven orchestration API—have made a scalable, self-service platform layer a reality. Even though it is not a one size fits all solution, a majority of business and technical challenges are being addressed. Kubernetes as the common denominator gives scalability, resiliency, and agility to internet-scale applications on various clouds in a predictable, consistent manner. But what good is application layer scalability if the data is still confined to a single vertically scalable server that can’t exceed a predefined limit?