Testing, Deployment, and Maintenance

TL; DR: Optimus Alpha Creates Useful Retrospective Format In this experiment, OpenAI’s new stealthy LLM Optimus Alpha demonstrated exceptional performance in team data analysis, quickly identifying key patterns in complex agile metrics and synthesizing insights about technical debt, value creation, and team dynamics. The model provided a tailored retrospective format based on real team data. Its ability to analyze performance metrics and translate them into solid, actionable retrospective designs represents a significant advancement for agile practitioners. The Rationale Behind Analyzing Team Data In this conversation, I explored Optimus Alpha’s capabilities in analyzing team performance data and designing evidence-based retrospectives. The exchange began with a familiar scenario: a Scrum team stuck in a “feature factory” mindset with stakeholders not embracing agile practices. While Optimus Alpha initially provided a solid retrospective format based on this limited information, the real test came when I introduced comprehensive team performance metrics from my AI for Agile Bootcamp cohort class. The synthesized data of MegaBrain.io’s fictitious MB1 team includes metrics on technical debt, value creation, stakeholder satisfaction, and team autonomy across multiple sprints. This simulated dataset represented the complex reality many Scrum teams face — balancing predictability with technical health, stakeholder demands with value creation, and feature delivery with sustainability. What follows is a remarkable demonstration of how Optimus Alpha absorbed this complex information, identified patterns that would typically require an experienced agile practitioner, and then transformed those insights into a tailored retrospective design with supporting materials. The conversation showcases analytical power and the ability to convert data insights into practical tools for team improvement. So, let’s get into the conversation with Optimus Alpha. Analyzing the Team Data With the Help of Optimus Alpha Round 1 I ran this chat on OpenRouter.ai on April 12, 2025. “SW” refers to myself, “OP” to Optimus Alpha. The text is unedited to preserve its authenticity: SW: My Scrum team has had a hard time; we are stuck in feature factory. Our Product Owner is little more than a Jira monkey, and no one is listening to me, the Scrum Master. Can you suggest a retrospective format my team can use to invite our stakeholders and help them understand that we could be more effective if we would only embrace agile practices? OP: Absolutely, and thank you for sharing your challenge so openly — feature factory symptoms and disengaged roles are all too common. It’s great that you’re ready to create space for everyone, including stakeholders, to reflect and learn together. Here’s a retrospective format designed to include stakeholders and shift the conversation toward agile value, not just output: Optimus Alpha — Retrospective Format #1: “From Feature Factory to Value Factory” Aim: Help the whole group — team and stakeholders — reflect on how you work, see the costs of “just pushing features,” and imagine better ways of working together. 1. Setting the Stage (10 min) Welcome everyone, explain the purpose: “We want to reflect together on how we’re working — not just what we’re building — and explore ways to better create value for our customers and business.”Establish Working Agreements (respect, honesty, curiosity).Remind folks: retros are blameless. 2. The Metaphor: “Factory Floor” Visual (5 min) Draw a simple assembly line on a virtual board or whiteboard.On one side, put “Inputs” (ideas, requests); in the middle, “Our Work,” and outputting “Features.”Ask: “Where does customer value show up here?” (Get a few responses from both teams and stakeholders.) 3. Group Activity: “What’s Working, What’s Not?” (15 min) Split everyone into breakout groups (mixed team and stakeholders).Each group answers: What do we do well right now?Where do we see pain, rework, or missed opportunities for value?Use sticky notes (digital or real), and post answers on the board under “Working” and “Not Working.” 4. Share and Cluster Key Themes (10 min) In the main group, everyone shares stickies.Scrum Master (you!) clusters themes — often you’ll see “no time to validate with users,” “little feedback,” “unclear priorities,” etc. 5. Reflection — Are We Doing Agile or Just Doing Stories? (5 min) Present the Agile Manifesto values or Scrum pillars briefly.Invite all: “Where are we supporting these values today? Where are we struggling?”Give a couple of minutes for silent reflection, then discuss. 6. Co-create Experiments (10 min) In pairs (ideally a stakeholder and a team), brainstorm one small experiment for the next sprint that could address a pain point (e.g., getting quick user feedback, clarifying the value of one backlog item, joint story mapping session, etc.).Each pair shares their idea briefly. 7. Closing and Commitment (5 min) Summarize: “If we want to escape feature factory mode, we all have a role.”Ask each participant: “What will I do differently next sprint?”Agree on 1–2 experiments to run, and how you’ll follow up. Tips and Rationale Stakeholders see they’re part of the system — their requests, engagement, and feedback matter.Makes visible the costs of just shipping features (technical debt, missed value, burnout, lack of learning).Creates joint ownership for change, rather than feeling like the Scrum team is just “whining.” Resources You Might Share Feature Factory SignsAgile ManifestoAtlassian’s Retrospective Techniques Let me know if you want some invitation language for your stakeholders or facilitation tips for handling tricky discussions! Note SW: All links are correct topic-wise and technically, although I had to add the title tags manually. Also, this is not just a good retrospective — it’s a transformational opportunity if followed through. It reframes roles, builds bridges, and ignites reflection on what really matters. For a Feature Factory, it’s a worthwhile approach: small risk, huge potential upside. Round 2 SW: Do you need more information from me to improve your retrospective suggestion? OP: That’s a great offer — thank you! Here are some clarifying questions that could help me refine my suggestion, making it more targeted and actionable for your specific context: 1. Stakeholder Context Who are the stakeholders you want to include? (e.g., internal business partners, external clients, managers, VPs…)What do you think “they” understand about Agile or Scrum now?How engaged or disengaged are they in your team’s work or results? 2. Team Dynamics How large is your team? (Size can affect activity facilitation)How long has your team been working in Scrum?How are your team members currently feeling about your process? Are they frustrated, disengaged, or burned out? 3. Pain Points and Symptoms Could you specify a couple of concrete “feature factory” symptoms you’re seeing? (e.g., relentless backlog churning, little feedback from users, no time for reflection/learning, missing sprint goals, etc.)Are there past attempts at improvement or retros that didn’t land well? 4. Goals for the Retrospective What’s your top wish for the outcome? (e.g., awareness/education, spark for change, specific agreement on next steps)Are you hoping to target a specific agile practice or value (focus, transparency, collaboration, delivering value, etc.)? 5. Risk Appetite Would your group be open to a bit of “creative tension,” or do you need to be more diplomatic and gentle in surfacing issues? The more context you can share, the more tailored (and likely effective) I can make the retrospective format, fitting your team’s culture, goals, and challenges. If you’d like, answer whichever of these jumps out, or just share anything else you think is relevant! SW: Before I answer your questions, please analyze the following team performance information and reconsider your questions. (Note: Here, I copied the synthesized team data from the Excel file into the context window.) OP: Thank you for sharing this comprehensive team performance data. It gives a richer, more nuanced picture than any qualitative conversation alone. Before updating questions or tailoring my retrospective advice, here’s a quick analysis of key patterns: Key Patterns and Insights 1. Feature Factory and Agile Health Experiments per sprint: Variable, sometimes 0, often 2–7 (average ~3–4), so the team is experimenting, but not always consistently.Technical debt %: Frequently high (14–25%), showing this is a persistent drain, likely slowing new value delivery.Education time: Fluctuates widely (as low as 1–2 hours, up to 11+), suggesting learning is sometimes deprioritized.Customer interactions: Moderate, but not always present every sprint (often 3–10). Not bad, but more could drive value.Stakeholder satisfaction: Mostly good, though dips into the 4–6 range sometimes with spikes to 9–10 — indicative of variability. 2. Agile Values and Team Dynamics Scores on autonomy, value creation, NPS, professional satisfaction, psychological safety, courage, respect, openness, and focus mostly trend between 5 and 9, but all dip into the 3–5 range at times, signaling periods of stress (see sprints 5–6, 15, etc.).Diary entries frequently mention: Management interferenceTechnical debt slowing progressPositive retros/workshops that seem to spike morale/value scoresStakeholder tensions, executive pressure, and production outages 3. Other Patterns Predictability is high (60–90%), but that doesn’t always equate to satisfaction or value.Escaped defects, incidents, and new/lost team members are low: this is a stable team, but with recurring process pain. What This Means for Your Retrospective The Team is NOT “Just a Feature Factory” There is some experimentation, customer contact, and educational investment.However, periods of “feature factory stress” (management interference, tech debt response mode, executive pressure) very clearly drive low scores in autonomy, satisfaction, and value creation. When the Team Works Well High autonomy and psychological safety, productive retros, stakeholder workshops, customer feedback => spike in both business and team satisfaction. Biggest Opportunities Consistent focus on value over pure output — variability is still high.Creating a more stable environment for learning, retrospection, and customer feedback, not just monthly or in “good times.”Better defense against management micromanagement and shifting priorities.Bridging perception with stakeholders — communicating value, not just throughput. Revised Follow-Up Questions With this data, fewer clarifying questions are needed, but I’ll tune them: What are your goals for the next retrospective, given these patterns? Awareness/education for stakeholders?Specific improvements (tech debt, stakeholder engagement, value focus)?Who do you want stakeholders to hear from? The team as a whole?Specific customer voices or data?Are there “untouchable” topics, or are you willing to openly discuss management interference and tech debt as a group?What timeframe do stakeholders care about most (week-to-week, quarterly outcomes, etc.)? How much appetite do they have for participating?In your view, which ONE success from the data is worth celebrating with stakeholders, and which ONE pain would you like to see acknowledged or solved? If you answer even a couple of these, I can create a high-impact, data-driven retrospective format (perhaps even using this data as a visual centerpiece to spark joint learning and action among stakeholders and the team). Would you like a sample format that incorporates this data as a mirror for your group? Or do you want to further discuss the questions above? SW: Regarding your follow-up questions: Help the stakeholders understand that the team could create more value for customers and the organization if we leave the feature factory and embrace agile product development. It is about education, opportunities, trust building, overcoming technical debt.The team as a whole.No.At the moment, they are focused on the team meeting its commitments as defined in their year-long product roadmap, a problematic approach in a complex environment.Celebrate: High predictability despite the circumstances. Pain point: technical debt accumulation. Please revise your suggested retrospective format. OP: Thank you for the clear answers! Here’s an improved retrospective format tailored to your needs, data, and objective to educate and inspire stakeholders, shifting them from feature factory thinking to agile, value-driven product development. Retrospective Format #2: “Beyond Commitments: Building Lasting Value” Audience: Scrum team and stakeholdersDuration: 60–75 minutesGoal: To build trust and educate stakeholders on how greater agility, autonomy, and focus on technical health can boost business value — beyond simply hitting features on a roadmap. 1. Welcome and Framing (5 min) “We’ve been very predictable, but our team sees even more potential for value — if we work together to modernize how we deliver.”Ground rules: curiosity, no blame, focus on opportunities.State purpose: “Let’s look at the real story our data tells, and find ways to unlock even more value for our customers and business.” 2. Celebrating Predictability (5 min) Show a simple chart of your team’s high predictability.Acknowledge: “We’re proud to honor commitments, despite challenges. That’s a real team achievement worth celebrating!” 3. Looking Deeper: The Value vs. Output Exercise (10 min) Show two simple graphs: a) Predictability (high, steady)b) Technical debt/Value creation/Stakeholder satisfaction (variable/fluctuating)Prompt: “What do you notice? What stories hide behind the numbers?”Invite both team and stakeholder reactions. 4. Short Team Stories: What’s the Cost of Feature Factory Living? (10 min) Team members each briefly share: A time when technical debt or backlog pressure forced a tradeoff.A time when autonomy/conversation with customers led to real value or insight.Ask: “What might have been possible, if we’d invested differently?” 5. Joint Brainstorm: Obstacles to Value (15 min) Use two columns (“What helps us create value?” / “What blocks it?”) The team and stakeholders add stickies or notes.Common “blockers”: technical debt, rigid roadmaps, lack of room to learn or adapt, excessive management intervention.Common “helpers”: customer feedback, refactoring, team autonomy, experiments, stakeholder trust.Cluster and discuss. Highlight technical debt as the recurring pain point. 6. Opportunities for Change: Data-Driven Reflection (15 min) Show a visual of technical debt trend and its correlation with value creation or satisfaction (even rough/qualitative is fine: “Our biggest dips in value/satisfaction align with tech debt crunch periods…”)Prompt stakeholders: “If we could reduce tech debt and invest in technical health, what new doors might open?”“What would make you more confident to allow the team to explore, experiment, or adjust course?”“How might we move from only delivery, to creating value that lasts?” 7. Pick 1–2 Team + Stakeholder Experiments (10 min) Examples (modify as needed): Block 10% of time for tech debt/health work every sprint; review outcomes with stakeholders.Monthly customer feedback or “value alignment” review — invite a stakeholder to join.Jointly define what “real value” means for a sprint or feature.Hold quarterly review: “Is our roadmap still the highest-leverage way to deliver value?”Agree to try one or two for the next sprint/month. 8. Commitment Rounds and Closing (5 min) Each person (including stakeholders): “One thing I commit to do, say, or advocate for in service of value creation, not just feature delivery.”Thank everyone for honesty, curiosity, and partnership. Facilitation Pointers Use rich data visuals — a couple easy graphs (predictability, tech debt, value creation, satisfaction) spark honest discussion.Encourage the team to speak frankly about technical debt consequences.Invite stakeholders to reflect on what *they* would gain if the team could work with more agility and autonomy (“would we get to market faster, respond to changes better, attract and retain top talent?”).Model mutual respect: “Everyone here wants to deliver business value — but the path isn’t always just through features.” Optional Pre-Work Consider sending the predictability and tech debt charts (and maybe a value creation graph) to stakeholders ahead of the session, with a note: “We’re incredibly proud of our team’s reliability, yet we see a chance to unlock even more business value by working smarter. Looking forward to exploring this with you in our next session!” Let me know if you want: Example data slide templatesStickies/board templates for Miro/Mural/JamboardMore story prompts for your team This format will help you shift the conversation from mere throughput (“predictable factory”) to real, meaningful, sustainable value — for both customers and the business. Note SW: The revised retrospective format is an interesting outcome: Adding real team data helped shift our retrospective from general discussion to focused conversations about what really affects results. Instead of just talking about feelings or processes, we looked at facts — like predictability, tech debt, and team satisfaction. This shift would make it easier for everyone, including stakeholders, to see where we are stuck and what is possible. It turned vague concerns, addressed by the first format, into clear opportunities for smarter decisions and better long-term outcomes. This development perfectly reflects one of the outstanding capabilities of large language models: analyzing large quantities of data, identifying patterns within them, and suggesting next steps. And Optimus Alpha proves to be really good at this. Of course, I asked to deliver all of the before-mentioned artifacts only to be disappointed; Optimus Alpha could not deliver yet. Conclusion: Optimus Alpha’s Retrospective Formats Optimus Alpha’s ability to analyze team data and design targeted retrospectives demonstrates the transformative potential of AI for agile practitioners. Tools like Optimus Alpha can help teams escape the feature factory trap and build more sustainable, value-focused ways of working by quickly identifying patterns in complex metrics and translating them into actionable formats. The model’s insight into the relationship between technical debt and value creation, team autonomy, and stakeholder satisfaction provides evidence-based foundations for retrospectives that might otherwise rely solely on subjective experiences. This approach represents a new frontier for data-informed facilitation — where LLMs serve as information processors and insightful partners in team improvement, easing communication with more data-oriented stakeholders. As agile practices continue to evolve, the opportunity to augment your retrospectives with AI-assisted data analysis could be game-changing: no more “gut-feeling-driven” change requests! Have you experimented with analyzing team data using AI tools? How might an LLM like Optimus Alpha help you identify patterns in your team’s metrics that could inform more impactful retrospectives? Please share your experiences and thoughts on how this approach might enhance your team’s journey toward greater business agility and sustainable value delivery.

By Stefan Wolpers CORE

Kubernetes has become a norm for deploying and managing software in a containerized manner. Its ability to dynamically manage microservices and scale has revolutionized software development in current times. However, it is not an easy task to maintain transparency in and monitor availability and performance of Kubernetes clusters. That is where telemetry comes in. Telemetry in Kubernetes involves collecting, processing, and visualization of cluster information for cluster health, fault diagnostics, and performance optimizations. In this article, we will see why telemetry is significant, key components, tools, and best practice in developing an effective observability stack for Kubernetes. What is Telemetry in Kubernetes? The collection of logs, metrics, and traces in an automated manner for analysis and visualization for performance, consumption, and behavior of a system, and an application, respectively, is telemetry in Kubernetes. In Kubernetes, telemetry enables admins and developers to monitor cluster health, detect anomalies, and correct them in a timely manner. The three categories of telemetry information include: Metrics: Quantitative representations of consumption, response times, and failure occurrences.Logs: Text logs produced by system and app components and captured events.Traces: Distributed system request tracking for performance bottleneck analysis. What Role Does Telemetry Serve in Kubernetes? Monitoring in Advance: Detect performance bottleneck and failure in advance to impact fewer users.Optimization of Resources: Analyze and utilize resources for efficient costing and scaling.Security and Compliance: Monitor suspicious activity and compliance with policies.Fault Analysis: Quick analysis of faults through logs and traces.Scaleability: Monitor performance even when clusters dynamically resize. Building Blocks for Kubernetes Telemetry Metrics Collection Metrics enable quantitative analysis of a node, a pod, and a container performance. CPU and memory consumption, disk I/O, network I/O, and performance of an API server are part of such metrics. Metrics enable admins to: Identify underused and bottlenecked resourcesAnalyze app performance trends over a durationTrigger an alarm when a specific value is attained Popular Tools Prometheus: An open-source, multi-dimensional model for supporting data for service discovery and integration with Kubernetes, with an ecosystem having third-party platform exporters.Metrics Server: Scalable and lightweight, providing CPU and memory usage for entities in Kubernetes and powering Horizontal Pod Autoscaler (HPA).cAdvisor (Container Advisor): Real-time monitor and statistics for use of a container, best for integration with Prometheus.Datadog: Commercial service with infrastructure, custom dashboards, AI-powered anomaly detection, and integration with pipelines for CD and CI.New Relic: Full observability feature, including distributed tracing, anomaly detection, and custom dashboards with alerting for Kubernetes with specific dashboards for alerting.Sysdig: Security and monitor-oriented, with runtime protection, forensics for captured events, and deep visibility for activity in a container with compliance capabilities. Logs Logs store real-time events, errors, and state, and enable admins to follow through and monitor behavior for an app. Logs can broadly fall under two categories: Cluster Logs: Logs generated by entities in Kubernetes including kubelet, API server, and etcd.Application Logs: Application logs generated in a pod for a containerized app. Popular Tools Fluentd: Highly flexible and scalable log collector supporting over 500 plugins for integration with external systems like Amazon S3, Google Cloud, and Elasticsearch.ElasticSearch, Kibana, and Logstash (ELK Stack): Central collection of logs, log indexing, and visualization capabilities with rich, interactive dashboards in Kibana.Loki + Grafana: Log-aware, specifically designed for logs, with no log indexing, and therefore lightweight and cost-effective, and with direct visualization of logs in Grafana dashboards.Graylog: Log analytic and log management oriented, with custom pipeline capabilities for log enrichment and powerful search and alert capabilities.Splunk: Premium service with log aggregation, log analysis, visualization, and AI-powered insights, best for use in an enterprise environment. Tracing Distributed tracing aids request propagation tracking in microservices in a Kubernetes environment. It aids service-to-service communications and identifies performance degradation and bottleneck locations. Tracing Features Tracked request propagation with timestamps and metadata.Identifies performance degradation in distributed environments.Analyzes service dependencies and failure trends. Popular Tools Jaeger: Distributed tracing tool for microservice debugging and monitoring, with feature sets supporting context propagation, root cause analysis, and latency optimization.OpenTelemetry: Logs, metrics, and traces framework, supporting interoperability and customizability between environments.Zipkin: For collecting latency information and mapping service dependencies, and it’s lightweight and compatible with environments in Kubernetes.Honeycomb: High resolution, real-time debugging and tracing for high volumes of telemetry, optimized for efficient performance in high volumes.AWS X-Ray: For use with applications in environments in AWS, with native integration for environments in AWS. Visualization and Alerting Good platforms for telemetry have to visualize information through dashboards and issue real-time alerts for abnormalities and threshold violations. Popular Tools Grafana: Very flexible visualization tool with multi-data source, real-time dashboards, and alerting capabilities.Alertmanager: Integrating with Prometheus, routing alerts through Slack, email, and webhooks according to severity.Datadog: Integrating monitor and alerts with AI-powered insights, log aggregation, and distributed tracing.Splunk: Integrating log analysis with visualization, custom dashboards, and AI-powered alerts for predictive analysis.Kibana: ELK stack’s visualization and analysis tool for logs and metrics with rich visualization and analysis capabilities. Conclusion Telemetry ensures monitorability, security, and scalability for clusters of Kubernetes and enables companies to deliver optimized and reliable software. Teams can utilize tools and best practices mentioned and monitor in a proactive manner, debug, and maximize performance. Sound investments in telemetry not only enable operational efficiency, but can enable continuous growth, compliance, and scalability in cloud-native environments, too.

By Srinivas Chippagiri CORE

Today, we will create simple applications using the Cohere Embed Multilingual v3 model via Amazon Bedrock and Spring AI. We’ll skip over basic Spring concepts like bean management and starters, as the main goal of this article is to explore the capabilities of Spring AI and Amazon Bedrock. The full code for this project is available in the accompanying GitHub repository. To keep this article concise, I won’t include some pre-calculated values and simple POJOs here — you can find them in the repo if needed. What Are Embeddings? Before we start code implementation, let's discuss embeddings. In the Spring AI documentation, we find the following definition of embeddings: "Embeddings are numerical representations of text, images, or videos that capture relationships between inputs." Embeddings convert text, images, and video into arrays of floating-point numbers called vectors. These vectors are designed to capture the meaning of the text, images, and videos. The length of the embedding array is called the vector’s dimensionality. Key points we should pay attention to: Numerical representation of text (also applicable for images and videos, but let’s focus just on texts in this article)Embeddings are vectors. And as every vector has coordinates for each dimension it exists, we should think about embeddings as a coordinate of our input in “Text Universe” As with every other vector, we can find the distance between two embeddings. The closer the two embeddings are to each other, the more similar their context. We will use this approach in our application. Determining the Scope of Our Future Application Let’s imagine that we have an online shop with different mattresses. Every single item has its ID and description. We need to create a module, that will receive users input describing the item the user wants to find or buy and returns 5 most relevant products to this query. We will achieve this goal using embeddings. Steps we need to implement We will fetch embeddings (vector representation) of our existing products and store them. I’ll not show this step in this article because it will be similar to one we will explore later. But you can find precalculated embeddings to use in your code in the GitHub repo I previously shared.We will call the Amazon Bedrock embeddings API for each user input.We will compare user input embeddings with precalculated embeddings of our item description. We will leverage the Cosine Similarity approach to find the closest vectors. Implementation Note: Please be aware that executing this application may cost you some money for running AWS Bedrock. Step 1. Generate AWS Keys and Enable the Foundational Model If you don’t have an active AWS access key, do the following steps (copied and pasted from this SOF thread): Go to: http://aws.amazon.com/Sign up and create a new account (they'll give you the option for a 1-year trial or similar)Go to your AWS account overviewAccount menu in the upper-right (has your name on it)sub-menu: Security Credentials After you have your keys generated you should choose and enable the foundational model in Bedrock. Go to Amazon Bedrock, and from the Model Access menu on the left, configure access to the Cohere Embed Multilingual model. Step 2. Set Up a Project To quickly generate a project template with all necessary dependencies, one may use https://start.spring.io/ In our example, we’ll be using Java 17 and Spring Boot 3.4.1. Also, we need to include the following dependency: Amazon Bedrock: This dependency provides us with smooth integration with Amazon Bedrock just by writing a couple lines of code and a few lines of configurations. After clicking generate, open the downloaded files in the IDE you are working on, and validate that all necessary dependencies exist in pom.xml. XML <dependency> <groupId>org.springframework.ai</groupId> <artifactId>spring-ai-bedrock-ai-spring-boot-starter</artifactId> <version>1.0.0-M6</version> </dependency> <dependencyManagement> <dependencies> <dependency> <groupId>org.springframework.ai</groupId> <artifactId>spring-ai-bom</artifactId> <version>1.0.0-M6</version> <type>pom</type> <scope>import</scope> </dependency> </dependencies> </dependencyManagement> At the moment of writing this article, Spring AI version 1.0.0-M6 has not yet been published in the central Maven repository and is only available in the Spring repository. That’s why we need to add a link to that repo in our pom.xml as well: XML <repositories> <repository> <id>spring-milestones</id> <name>Spring Milestones</name> <url>https://repo.spring.io/milestone</url> <snapshots> <enabled>false</enabled> </snapshots> </repository> </repositories> Step 3. Set Up the Configuration File As a next step, we need to configure our property file. By default, Spring uses application.yaml or application.properties file. In this example, I’m using the YAML format. You may reformat code into .properties if you feel more comfortable working with this format. Here are all the configs we need to add to the application.yaml file: YAML spring: application: name: aiembeddingsbedrock ai: bedrock: aws: access-key: secret-key: cohere: embedding: model: cohere.embed-multilingual-v3 enabled: true Access-key, secret-key Copy and paste the security credential pair we generated in step 1. Make sure you are not pushing these credentials to the remote repo. Model We will be using cohere.embed-multilingual-v3. We may also use the Titan embedding model, but in this case, the config file should be set in a slightly different way. You may find more information in the Spring AI docs. As the main purpose of this article is to show the ease of Spring AI integration with Amazon Bedrock embedding models, we will not go deeper into other configurations. You may find more config options in the Spring docs. Step 4. Create Resource Files Let’s create two files in the resource folder. The first one is the JSON-formatted “database” of items in our shop. Every item will have the following parameters: Id, Name, and Description. I named this file samples.json and saved it in the resource folder. JSON [ { "id": 1, "name": "DreamSoft Memory Foam", "description": "Queen size, memory foam, medium firmness, cooling gel layer, hypoallergenic cover, pressure-relieving design, motion isolation, anti-bacterial protection, reinforced edges, eco-friendly materials, breathable fabric." }, { "id": 2, "name": "SleepWell Hybrid Comfort", "description": "King size, hybrid (foam + springs), medium-firm, breathable fabric, motion isolation, orthopedic support, reinforced edges, dust-mite resistant, zoned pressure relief, temperature-regulating cover, moisture-wicking material." }, { "id": 3, "name": "OrthoRest Firm Support", "description": "Full size, high-density foam, firm support, orthopedic design, anti-bacterial cover, hypoallergenic materials, motion isolation, lumbar support zone, durable construction, soft knit fabric." }, { "id": 4, "name": "CloudNine Plush Top", "description": "California King, pillow-top design, soft firmness, pocketed coils, moisture-wicking fabric, pressure-relief zones, motion isolation, anti-microbial treatment, reinforced edge support, luxury plush feel." }, { "id": 5, "name": "EcoSleep Organic Latex", "description": "Queen size, natural latex, medium firmness, organic cotton cover, eco-friendly materials, hypoallergenic, durable support, breathable construction, cooling airflow design, anti-dust-mite protection." }, { "id": 6, "name": "ZenBalance Hybrid Pro", "description": "King size, hybrid latex and springs, firm support, pressure relief zones, cooling technology, orthopedic certified, reinforced lumbar support, anti-bacterial protection, soft-touch fabric, edge stability." }, { "id": 7, "name": "SnugFit Dual Comfort", "description": "Twin size, reversible (soft and firm sides), gel-infused memory foam, anti-microbial cover, motion isolation, breathable materials, cooling effect, ergonomic design, pressure relief, durable construction." }, { "id": 8, "name": "TranquilDream Euro Top", "description": "Full size, euro-top cushion, medium-soft, breathable layers, reinforced edges, plush comfort, pressure relief, orthopedic support, anti-allergy treatment, soft-touch fabric." }, { "id": 9, "name": "SleepWell Firm Hybrid", "description": "Queen size, pocket springs and latex, extra firm support, temperature-regulating fabric, breathable mesh cover, motion isolation, reinforced lumbar zone, anti-microbial coating, edge support, durable foam layers." }, { "id": 10, "name": "CloudNest Ultra Soft", "description": "Twin size, ultra-soft memory foam, adaptive contouring, hypoallergenic materials, plush comfort, ergonomic design, motion isolation, cooling gel layer, anti-dust-mite treatment, durable cover." }, { "id": 11, "name": "GrandRest Luxury Foam", "description": "California King, high-resilience foam, medium firmness, pressure-relieving layers, durable support, orthopedic comfort, breathable construction, anti-allergy cover, moisture-wicking fabric, reinforced durability." }, { "id": 12, "name": "NatureSleep Bamboo Bliss", "description": "Queen size, bamboo-infused foam, medium-plush, dust-mite resistant, cooling effect, eco-friendly construction, breathable layers, ergonomic support, anti-bacterial finish, luxury feel." }, { "id": 13, "name": "BackCare OrthoFlex", "description": "King size, orthopedic support, extra firm, reinforced lumbar zone, breathable mesh cover, motion isolation, pressure-relief technology, anti-allergy fabric, durable construction, anti-microbial treatment." }, { "id": 14, "name": "EcoHaven Pure Latex", "description": "Full size, 100% natural latex, firm support, moisture-resistant organic cotton cover, eco-friendly production, anti-bacterial protection, breathable layers, ergonomic support, durable edge reinforcement, motion control." }, { "id": 15, "name": "SereneNight Cooling Gel", "description": "Twin XL, gel-infused foam, medium-soft, anti-sag technology, eco-friendly fabric, breathable layers, reinforced edges, motion isolation, cooling airflow, pressure relief." }, { "id": 16, "name": "AirFlow Tech Hybrid", "description": "King size, hybrid springs and foam, airflow channels, medium-firm, ergonomic design, orthopedic support, durable frame, anti-bacterial cover, temperature control, reinforced edge support." }, { "id": 17, "name": "HavenCloud Orthopedic", "description": "Queen size, orthopedic memory foam, medium firmness, zoned pressure relief, anti-bacterial fabric, motion isolation, breathable construction, hypoallergenic, edge reinforcement, moisture control." }, { "id": 18, "name": "EliteRest Plush Feel", "description": "California King, plush top layer, responsive foam, moisture-wicking fabric, ultra-soft finish, ergonomic design, breathable mesh, motion control, reinforced edges, luxury feel." }, { "id": 19, "name": "SleepGuard Anti-Allergy", "description": "Full size, hypoallergenic foam, medium-firm, mite-resistant, reinforced support core, anti-dust-mite treatment, breathable design, motion isolation, ergonomic shape, cooling effect." }, { "id": 20, "name": "SnuggleEase Memory Cloud", "description": "Twin size, cloud-like memory foam, medium-plush, heat-dissipating layers, soft knit cover, motion isolation, breathable fabric, anti-bacterial treatment, ergonomic shape, pressure relief." } The second one is a list of embeddings of the product description. I executed embeddings API in a separate application and saved responses for every single product into a separate file, embeddings.json. I’ll not share the whole file here, as it will make the article unreadable, but you still can download it from the GitHub repo of this project I shared at the beginning of the article. Step 5. Create Embeddings Service Now, let’s create the main service of our application -> embedding service. To integrate our application with the embeddings API, we need to autowire EmbeddingModel. We have already configured Bedrock embeddings in the application.yaml. Spring Boot will automatically create and configure the instance (Bean) of EmbeddingModel. To fetch embeddings for a particular String or text, we just need to write one line of code: Java EmbeddingResponse embeddingResponse = embeddingModel.embedForResponse(List.of(text)); Let’s see what the whole service looks like: Java @Service public class EmbeddingsService { private static List<Product> productList = new ArrayList<>(); private static Map<Integer, float[]> embeddings = new HashMap<>(); @Autowired private EmbeddingModel embeddingModel; @Autowired private SimilarityCalculator similarityCalculator; @PostConstruct public void initProducts() throws IOException { ObjectMapper objectMapper = new ObjectMapper(); InputStream inputStream = getClass().getClassLoader().getResourceAsStream("samples.json"); if (inputStream != null) { // map JSON into List<Product> productList = objectMapper.readValue(inputStream, new TypeReference<List<Product>>() { }); System.out.println("Products loaded: List size = " + productList.size()); } else { System.out.println("File samples.json not found in resources."); } embeddings = loadEmbeddingsFromFile(); } public Map<Integer, float[]> loadEmbeddingsFromFile() { try { InputStream inputStream = getClass().getClassLoader().getResourceAsStream("embeddings.json"); ObjectMapper objectMapper = new ObjectMapper(); return objectMapper.readValue(inputStream, new TypeReference<Map<Integer, float[]>>() { }); } catch (Exception e) { System.err.println("Error loading embeddings from file: " + e.getMessage()); return null; } } public void getSimilarProducts(String query) { EmbeddingResponse embeddingResponse = embeddingModel.embedForResponse(List.of(query)); List<ProductSimilarity> topSimilarProducts = similarityCalculator.findTopSimilarProducts(embeddingResponse.getResult().getOutput(), embeddings, productList, 5); for (ProductSimilarity ps : topSimilarProducts) { System.out.printf("Product ID: %d, Name: %s, Description: %s, Similarity: %.4f%n", ps.getProduct().getId(), ps.getProduct().getName(), ps.getProduct().getDescription(), ps.getSimilarity()); } } Let’s deep dive into this code: In the @postconstruct method, we are loading our resources into collections. The list of Products reads our products from samples.json. The product is a POJO with ID, name, and description fields. We also load precalculated embeddings of our products from another file embeddings.json. We will need these embeddings later when we look for the most similar product.The most important method in our service is getSimilarProducts which will receive user queries, fetch its embeddings using embeddingModel, and calculate similarities with our existing products. We will take a closer look at similarityCalculator.findTopSimilarProductsa little bit later in this article. After receiving a list of similarities, we will print the top N similar products in the following format: Product ID, Name, Description, Similarity (a number between 0 and 1) To calculate similarities, we introduced SimilarityCalculator Service. Let’s take a deeper look at its implementation. Java @Service public class SimilarityCalculator { public float calculateCosineSimilarity(float[] vectorA, float[] vectorB) { float dotProduct = 0.0f; float normA = 0.0f; float normB = 0.0f; for (int i = 0; i < vectorA.length; i++) { dotProduct += vectorA[i] * vectorB[i]; normA += Math.pow(vectorA[i], 2); normB += Math.pow(vectorB[i], 2); } return (float) (dotProduct / (Math.sqrt(normA) * Math.sqrt(normB))); } public List<ProductSimilarity> findTopSimilarProducts( float[] queryEmbedding, Map<Integer, float[]> embeddings, List<Product> products, int topN) { List<ProductSimilarity> similarities = new ArrayList<>(); for (Product product : products) { float[] productEmbedding = embeddings.get(product.getId()); if (productEmbedding != null) { float similarity = calculateCosineSimilarity(queryEmbedding, productEmbedding); similarities.add(new ProductSimilarity(product, similarity)); } } return similarities.stream() .sorted((p1, p2) -> Double.compare(p2.getSimilarity(), p1.getSimilarity())) .limit(topN) .toList(); } ProductSimilarity is a POJO class containing Product and similarity fields. You can find the code for this class in the GitHub repo.calculateCosineSimilarity is the method used to find the most similar descriptions to user queries. Cosine similarity is one of the most popular ways to measure the similarity between embeddings. Explaining the exact workings of cosine similarity is beyond the scope of this article.findTopSimilarProducts is a method called from our embedding service. It calculates similarities with all products, sorts them, and returns the top N products with the highest similarity. Step 5: Execute Application We will execute this application directly from code without using any Rest Controllers and API calls. If you want to make this app a little bit more flexible by triggering it by an endpoint execution you may use an approach similar to the one used in this article. Java @SpringBootApplication public class AiEmbeddingsApplication { public static void main(String[] args) { ConfigurableApplicationContext run = new SpringApplicationBuilder(AiEmbeddingsApplication.class) .web(WebApplicationType.NONE) .run(args); run.getBean(EmbeddingsService.class).getSimilarProducts("anti-allergy king-size mattress"); } We are executing our code in the last line of the method, fetching the bean from the context and executing the getSimilarProducts method with a provided query. In our query, we’ve included 3 keywords: anti-allergy, king-size, mattress. Let’s execute our code and validate the result. To start our application, we need to run the following command: mvn spring-boot:run In a couple of seconds after executing, we may see the following result in the console: Shell Product ID: 13, Name: BackCare OrthoFlex, Description: King size, orthopedic support, extra firm, reinforced lumbar zone, breathable mesh cover, motion isolation, pressure-relief technology, anti-allergy fabric, durable construction, anti-microbial treatment., Similarity: 0,6107 Product ID: 16, Name: AirFlow Tech Hybrid, Description: King size, hybrid springs and foam, airflow channels, medium-firm, ergonomic design, orthopedic support, durable frame, anti-bacterial cover, temperature control, reinforced edge support., Similarity: 0,5984 Product ID: 2, Name: SleepWell Hybrid Comfort, Description: King size, hybrid (foam + springs), medium-firm, breathable fabric, motion isolation, orthopedic support, reinforced edges, dust-mite resistant, zoned pressure relief, temperature-regulating cover, moisture-wicking material., Similarity: 0,5964 Product ID: 5, Name: EcoSleep Organic Latex, Description: Queen size, natural latex, medium firmness, organic cotton cover, eco-friendly materials, hypoallergenic, durable support, breathable construction, cooling airflow design, anti-dust-mite protection., Similarity: 0,5874 Product ID: 1, Name: DreamSoft Memory Foam, Description: Queen size, memory foam, medium firmness, cooling gel layer, hypoallergenic cover, pressure-relieving design, motion isolation, anti-bacterial protection, reinforced edges, eco-friendly materials, breathable fabric., Similarity: 0,5836 We can see that Product 13 has the highest similarity, as it is both a king-sized and hypoallergenic mattress. Even though it doesn't exactly match the search query, it closely aligns with what we were looking for. All of the other recommended mattresses are either king-sized or hypoallergenic. Conclusion Spring AI is a great tool that helps developers smoothly integrate with different AI models. At the moment of writing this article, Spring AI supports 10 embedding models, including but not limited to Ollama and Open AI. On the other hand, Amazon Bedrock offers a choice of high-performing foundation models (FMs) from leading AI companies like AI21 Labs, Anthropic, Cohere, DeepSeek, Luma, Meta, Mistral AI, poolside (coming soon), Stability AI, and Amazon through a single API, along with a broad set of capabilities you need to build generative AI applications with security, privacy, and responsible AI. I hope you found this article helpful and that it will inspire you to explore Spring AI and AWS Bedrock more deeply.

By Danil Temnikov CORE

Monitoring journald is essential for keeping systems running smoothly and securely. By regularly checking logs generated by systemd, administrators can catch potential issues like failing services or resource constraints — before they turn into major problems. Beyond performance and troubleshooting, journald is a powerful tool for security and compliance. It helps track login attempts, privilege escalations, and unusual service behavior, making it crucial for detecting unauthorized access or potential cyber threats. For organizations that need to meet regulatory requirements, monitoring system logs ensures proper tracking of system changes and security policies. About the Module ansible.eda.journald is an Event-Driven Ansible (EDA) plugin that listens to journald logs in real time and triggers automated responses based on log events. This makes it useful for tasks like automatically restarting failed services, detecting security threats, or alerting administrators when critical system issues occur. Demo In this article, we explore how the ansible.eda.journald module monitors journald messages and prints debug output whenever a sudo command is issued (condition: match: "_EXE=/usr/bin/sudo"). However, this module can be used to track all journald messages, making it versatile for various logging and monitoring needs. YAML --- - name: Journald Demo hosts: localhost sources: - name: range ansible.eda.journald: match: "_EXE=/usr/bin/sudo" rules: - name: "Print Journald Event message" condition: event.journald._comm == 'sudo' action: print_event: pretty: true var_root: journald.message: journald.message To execute the sample rulebook, run the command, ansible-rulebook -i localhost -r journald.yml, which will start monitoring journald logs in real time. Whenever it detects the use of a sudo command, it will trigger the rule and display a message on the console. This setup provides an easy way to track sudo usage, and you can customize the rulebook to monitor other journald events based on your requirements. Conclusion The ansible.eda.journald module provides a powerful way to monitor journald logs in real time and automate responses based on specific events. By leveraging Event-Driven Ansible (EDA), administrators can efficiently track system activities, detect security events, and automate actions such as alerts or service restarts. This tutorial demonstrated how to set up and run a rulebook to monitor sudo commands, but the same approach can be extended to various other system logs. With its ability to customize rules, ansible.eda.journald is a powerful tool that enhances system monitoring, strengthens security, and automates responses to important events. Note: The views expressed in this article are my own and do not necessarily reflect the views of my employer.

By Binoj Melath Nalinakshan Nair CORE

When developing an Event-Driven Ansible rulebook to automate tasks like handling a server outage or responding to a failed CI/CD job, testing the logic can be tricky if we don’t have a live system constantly generating events. That’s where the ansible.eda.generic source plugin comes in handy. It allows us to define mock events and inject them directly into the EDA workflow. This makes it easy to simulate real-time scenarios, test the rule conditions, and ensure the playbooks run as expected in a safe and controlled environment. In this article, I’ll walk you through how to include payloads directly within an Ansible EDA rulebook, as well as how to read payloads from an external file and use that data in rule conditions. I’ll also include some of the parameters like loop_count and loop_delay, which will help to control the number of times an event is triggered and the delay between each trigger. These features are especially helpful for simulating and managing event flow effectively during testing and development. Working With Payloads in Ansible EDA Rulebooks In this demo, we’ll look at two different ways to work with payloads in Ansible EDA rulebooks. The first rulebook, generic-payload.yml, includes the payload directly within the rulebook itself, making it simple and self-contained. The second, generic-payloadfile.yml, reads the payload from an external YAML file, allowing for better organization and reuse. The external payload is stored in events.yml, which makes it easy to manage test data separately. Both rulebooks trigger the same playbook, generic-handle.yml, which prints the payload details passed from the rulebook. Examples of generic-payload.yml and generic-payloadfile.yml Rulebooks Below are examples of the generic-payload.yml rulebook as well as the generic-payloadfile.yml rulebook. Screenshots of each outcome are also found below. generic-payload.yml YAML - name: Generic Source Payload hosts: localhost sources: - ansible.eda.generic: payload: - { service_name: "webapp", status: "unhealthy", timestamp: "2025-03-30T12:00:00Z" } display: true loop_count: 3 loop_delay: 30 create_index: i rules: - name: Check if the service is unhealthy condition: event.status == "unhealthy" action: run_playbook: name: generic-handle.yml generic-payloadfile.yml YAML - name: Generic Source Payload File hosts: localhost sources: - ansible.eda.generic: payload_file: "events.yml" display: true loop_count: 3 loop_delay: 30 create_index: i rules: - name: Check if the service is unhealthy condition: event.status == "unhealthy" action: run_playbook: name: generic-handle.yml events.yml YAML service_name: "webapp" status: "unhealthy" timestamp: "2025-03-30T12:00:00Z" generic-handle.yml YAML - name: Handle Unhealthy Service Event hosts: localhost gather_facts: false tasks: - name: Print service issue debug: msg: > Detected that '{{ ansible_eda.event.service_name }' is '{{ ansible_eda.event.status }' at '{{ ansible_eda.event.timestamp }', current system timestp '{{ now(fmt='%Y-%m-%d %H:%M:%S') }' Output Screenshot From thegeneric-payload.yml Execution Below you can find the resulting screenshot from leveraging the generic-payload.yml execution: Output screenshot from generic-payloadfile.yml execution Conversely, you can now see the output from the generic-payloadfile.yml execution. Conclusion The ansible.eda.generic module is a valuable tool for developing and testing event-driven automation workflows in Ansible EDA. It enables the simulation of events through static payloads, allowing for easy validation of rule conditions and playbook behavior without needing live external systems. This approach is particularly useful during the development phase, where generating real-time events can be difficult. Leveraging the ansible.eda.generic plugin, we can design, test, and fine-tune the automation logic before integrating it with actual event sources. Note: The views expressed in this article are my own and do not necessarily reflect the views of my employer.

By Binoj Melath Nalinakshan Nair CORE

Modern authentication protocols, such as SAML and OpenID Connect (OIDC), rely heavily upon federation as the guiding principle to secure front-door authentication. Federation is an elegant approach for web-based applications to isolate authentication from the application using a trust established between the centralized identity provider (IDP) and a subscribing application. Armed with asymmetric key-based digital certificates, federation ensures that an application can securely leverage an external IDP service for authentication and free itself from the burden of handling user interaction during the authentication process. With federation comes the concept of single sign-on (SSO). Suppose the centralized IDP has already established a secure authentication session. In that case, multiple applications can benefit from being able to single sign-on and bypass redundant login, improving user experience and reducing authentication frictions. Limitation With Current Protocols However, federation exhibits limitations with modern applications, especially native mobile applications. Consider the scenario of an insurance provider's mobile application using biometric authentication with a central IDP. Once a user logs in to the application, she might want to go to a banking partner web application, for instance, by clicking a link inside the application. For a seamless user experience, the expectation is to transparently log the user in with SSO to the partner web application. The partner web application can be configured to use the same central IDP, but federation does not work since the mobile app does not have any easy way to share an existing IDP session with the web app. The de-facto technique for web SSO is using browser cookies, something that the native mobile app can not share with the mobile's system browser. As a result, the partner application that opens in the system browser does not know there has been an existing session, and SSO does not happen. Instead, the user would have to re-authenticate to the partner app. A potential solution is to use a shared identifier other than a browser cookie. That approach works well for SSO between mobile apps. Since both apps reside on the same device, they can securely share a session identifier using other forms of secure storage, such as the keychain in iOS devices. There is a standard specification for native-to-native SSO with OIDC. Unfortunately, there is no obvious way to implement SSO in a native-to-web scenario using industry standards. Often, individual applications resort to insecure ad hoc approaches. Identity Bridge Concept The identity bridge framework attempts to provide an architecture that applications can use to implement native-to-web SSO securely, staying close to the industry standard OIDC protocol. Since the protocol does not have a mechanism to support SSO out of the box, it needs a few additional constructs. First, the bridge relies on the central IDP's ability to delegate authentication to another IDP. This capability is known as inbound federation. Most commercial and open-source IDPs support inbound federation. Technically, communication between the two IDPs can use any federation protocol (SAML or OIDC) independently. However, the framework recommends OIDC since the industry is increasingly adopting it for new applications. Also, a service that we will call the Bridge service needs to be deployed. It will act as the inbound IDP communicating with the central IDP using OIDC. The bridge does not need a user interface; it will simply work as a proxy redeeming the mobile app authentication token for a web SSO session from the central IDP. A Model Bridge Framework Here is a model of the basic architecture for the bridge: There is a lot to unpack here: The user opens the mobile app and authenticates with the central IDP.Central IDP issues an authentication token to the application. For OIDC, the ID Token can be considered as the authentication token.The user then clicks on a web link (for the target web application) inside the mobile application.The web link opens in the system browser. The link also contains the authentication token as a parameter.The web application extracts the authentication token.The web app application initiates an OIDC authentication with the central IDP. First, it redirects to the IDP's /authorize endpoint. It also passes the authentication token in the login_hintparameter.The central IDP initiates another OIDC authentication flow, with the bridge acting as the inbound IDP. It passes on the login_hint parameter, which contains the authentication token from the mobile app.The bridge then generates a temporary authorization_code for one-time use and redirects back to the central IDP with the authorization code.The central IDP makes an HTTP POST call to the bridge's /token endpoint.The bridge validates the authentication token obtained from the mobile app passed through the login_hint parameter in the previous step. Using information from the source authentication token, it generates a new JWT token, signs it using its private key, and returns it to the central IDP.Next, the central IDP calls the keys endpoint of the bridge to obtain the public key to verify the signed JWT token.After the JWT is validated, the central IDP creates a web session and completes the authentication process by redirecting back to the web application. Security Considerations and Limitations Security Risks and Challenges Although the framework was designed using the standard OIDC protocol, it is not without its limitations. A proxy service must be deployed and maintained by adding an additional component to the solution. The vanilla architecture does not deal with many token security aspects. If additional measures are not taken with a leaked mobile authentication token, bypassing authentication in the web application is possible. Security Enhancements One implementation consideration for protecting the token is not using the original authentication token from the mobile application. Mobile applications tend to have long-lived tokens, and using them to perform SSO with a web application significantly increases the risk of session compromise. For example, the following strategy can be adopted: Before starting the web SSO, obtain a separately scoped ultra-short-lived ID token from the primary IDP. Use the new token to perform SSO instead of the original token for the mobile application. The ideal solution would be direct protocol support for native-to-web SSO. This would help avoid additional components and reduce the implementation complexity. Several promising works are underway to create an industry specification in this space. Implementation This section details a prototype implementation using Okta as the primary IDP. The bridge essentially acts as an OIDC server and implements three primary APIs. 1. /authorize This is the OIDC authorize endpoint. Okta will redirect to this endpoint using HTTP 302. The endpoint accepts the parameter login_hint, which carries the native token generated when the native app authenticates with Okta. For the prototype, the ID token issued by Okta is used as the native token. JavaScript app.get("/authorize", (request, response) => { customNonce = request.query.nonce; response.redirect( request.query.redirect_uri + "?code=" + request.query.login_hint + "&state=" + request.query.state ); }); Instead of generating a transient authorization code, the native token itself is passed back to the Okta redirect endpoint using the code parameter. Okta also generates a nonce value in the response. The nonce must later be included in the token. 2. /token OIDC token endpoint. Okta calls this endpoint to redeem the authorization code for a token. Communication occurs between Okta and the bridge. The resulting token is not reused in the application context. JavaScript app.post("/token", async (request, response) => { let originalClaims = jwt.decode(token); let claims = {}; claims.nonce = customNonce; claims.sub = originalClaims.sub; claims.ver = originalClaims.ver; claims.iss = originalClaims.iss; claims.aud = originalClaims.aud; claims.email = originalClaims.sub; customKeystore = jose.JWK.createKeyStore(); let result = await customKeystore.generate('RSA', 2048, {alg: 'RS256', use: 'sig' }); publicKey = result.toJSON(); privateKeyPEM = result.toPEM(true); publicKeyPEM = result.toPEM(false); customJWK= jwt.sign(claims,privateKeyPEM, { algorithm: 'RS256', header: { typ: 'jwt' } } ); var responseData = { access_token: customJWK, token_type: "Bearer", expires_in: 3600, scope: "openid", id_token: customJWK, }; response.send(responseData); }); In the prototype, the implementation effectively copies the claims of the native token to create a new JWT and includes the nonce value generated during the authorization step. It then signs and sends the token to Okta. To sign the token, it generates an ephemeral key pair for a one-time use. 3. /keys OIDC key endpoint. Okta uses this endpoint to fetch the public key of the bridge to verify the signed token issued at the /token endpoint. The implementation should return the ephemeral public key and then discard the keypair. JavaScript app.get("/keys", (request, response) => { let keys = {"keys":[publicKey]} response.send(JSON.stringify(keys)); }); A working prototype of the bridge service using Okta is available here. Sample applications for testing: Native app and Web app. Security Analysis The identity bridge is transparent to various applications. It communicates only with the primary IDP using OIDC, which is a secure federation protocol. The bridge must send a signed token to the IDP. It generates ephemeral key pairs for signing. Because every authentication is aided by a unique random keypair, a complex key management is not required. The bridge must ensure that the key pair is discarded after use or is in a failure condition. The authentication token used should have a sufficiently small value to reduce the potential for token leakage and guard against token replay attack. To further reduce the risk of token leakage, another idea is to use a very short duration token from the primary IDP generated just before initiating the SSO, instead of using the primary authentication token from the native application. Additionally, the bridge should be configured to accept requests only from whitelisted IPs related to the primary IDP. Real-World Use Cases Let us look at a few real-world scenarios in which native-to-web SSO flow is common. Corporate Portal A corporate mobile application can have links to authorized applications that are web-based and open in a system browser. After employees log into their corporate web portal, they typically single sign on to the applications they are authorized for. To provide a similar feature when they access the portal through the company's mobile application, a native-to-web SSO flow is required, particularly for web-based applications. Online Travel Agency The mobile app for an online travel agency can have web links to its partner airlines and hotels. Customers can then log in to the mobile app and click on their preferred airline or hotel to directly access and manage their bookings from their respective websites. Healthcare The mobile app for a medical provider or hospital can allow access to the web-based patient portal (for example, Epic MyChart) without the patient needing to be authenticated in the patient portal again. Streaming and E-Commerce Many consumer-facing streaming and e-commerce applications provide core features through mobile applications such as streaming videos or allowing consumer shopping. They redirect users to the web interface for other features such as account and subscription management. native-to-web SSO will allow consumers to switch to the web interface without re-authentication, thereby improving the user experience. Vendor Portal Similar to corporate portals, organizations typically create mobile applications for B2B portals, such as vendor applications. Vendors can have access to several web-based applications through the portal and hence will benefit from the native-to-web SSO ability. Conclusion Today, applications increasingly use different platforms and devices to provide flexibility to users and allow them to access an application from any place and device. The idea is to bring the applications close to users and allow them to access them from any digital platform that they might be using. Properly authenticating and authorizing users without disrupting their experience and productivity in such an environment is critical. The OIDC bridge complements web-to-web federation and native-to-native SSO standards to provide authentication and SSO services across applications in all possible devices and platforms.

In this tutorial, we consolidated some practical approaches regarding OpenTelemetry and how to use it with Spring Boot. This tutorial is composed of four primary sections: OpenTelemetry practical conceptsSetting up an observability stack with OpenTelemetry Collector, Grafana, Loki, Tempo, and PodmanInstrumenting Spring Boot applications for OpenTelemetryTesting and E2E sample By the end of the tutorial, you should be able to implement the following architecture: OpenTelemetry Practical Concepts As the official documentation states, OpenTelemetry is: An observability framework and toolkit designed to create and manage telemetry data such as traces, metrics, and logsVendor and tool-agnostic, meaning that it can be used with a broad variety of Observability backends.Focused on the generation, collection, management, and export of telemetry. A major goal of OpenTelemetry is that you can easily instrument your applications or systems, no matter their language, infrastructure, or runtime environment. Monitoring, Observability, and METL To keep things short, monitoring is the process of collecting, processing, and analyzing data to track the state of a (information) system. Then, monitoring is going to the next level, to actually understand the information that is being collected and do something with it, like defining alerts for a given system. To achieve both goals, it is necessary to collect three dimensions of data, specifically: Logs: Registries about processes and applications, with useful data like timestamps and contextMetrics: Numerical data about the performance of applications and application modulesTraces: Data that allow to estabilish the complete route that a given operation traverses through a series of dependent applications Hence, when the state of a given system is altered in some way, we have an Event, which correlates and ideally generates data on the three dimensions. Why Is OpenTelemetry Important, and What Problem Does It Solve? Developers recognize by experience that monitoring and observability are important, either to evaluate the actual state of a system or to do post-mortem analysis after disasters. Hence, it is natural to think that observability has been implemented in various ways. For example, if we think of a system constructed with Java, we have at least the following collection points: Logs: Systemd, /var/log, /opt/tomcat, FluentDMetrics: Java metrics via JMX, OS Metrics, vendor specific metrics via Spring ActuatorTracing: Data via Jaeger or Zipkin tooling in our Java workloads This variety in turn imposes a great amount of complexity in instrumenting our systems to provide information, that a- comes in different formats, from b- technology that is difficult to implement, often with c- solutions that are too tied to a given provider or in the worst cases, d- technologies that only work with certain languages/frameworks. And that's the magic about the OpenTelemetry proposal: by creating a working group under the CNCF umbrella the project can provide useful things like: Common protocols that vendors and communities can implement to talk to each otherStandards for software communities to implement instrumentation in libraries and frameworks to provide data in OpenTelemetry formatA collector able to retrieve/receive data from diverse origins compatible with OpenTelemetry, process it and send it to...Analysis platforms, databases, and cloud vendors able to receive the data and provide added value over it In short, OpenTelemetry is the reunion of various great monitoring ideas that overlapping software communities can implement to facilitate the burden of monitoring implementations. OpenTelemetry Data Pipeline For me, the easiest way to think about OpenTelemetry concepts is a data pipeline, in this data pipeline you need to Instrument your workloads to push (or offer) the telemetry data to a processing/collecting element — i.e., OpenTelemetry Collector-Configure OpenTelemetry Collector to receive or pull the data from diverse workloadsConfigure OpenTelemetry Collector to process the data — i.e., adding special tags, filtering dataConfigure OpenTelemetry Collector to push (or offer) the data to compatible backendsConfigure and use the backends to receive (or pull) the data from the collector to allow analysis, alarms, AI... pretty much any case that you can think about with data Setting up an observability stack with OpenTelemetry Collector, Grafana, Prometheus, Loki, Tempo and Podman As OpenTelemetry got popular various vendors have implemented support for it, to mention a few: Self-hosted platforms ElasticGrafanaHyperDX Cloud platforms AmazonOracle CloudSplunkDatadog Hence, for development purposes, it is always useful to know how to bootstrap a quick observability stack able to receive and show OpenTelemetry capabilities. For this purpose, we will use the following elements: Prometheus as a time-series database for metricsLoki as a logs platformTempo as a tracing platformGrafana as a web UI And of course OpenTelemetry collector. This example is based on various Grafana examples, with a little bit of tweaking to demonstrate the different ways of collecting, processing and sending data to backends. OpenTelemetry Collector As stated previously, OpenTelemetry collector acts as an intermediary that receives/pull information from data sources, processes this information and, forwards the information to destinations like analysis platforms or even other collectors. The collector is able to do this either with compliant workloads or via plugins that talk with the workloads using proprietary formats. As the plugins collection can be increased or decreased, vendors have created their own distributions of OpenTelemetry collectors, for reference I've used successfully in the real world: Amazon ADOTSplunk Distribution of OpenTelemetry CollectorGrafana AlloyOpenTelemetry Collector (the reference implementation) You can find a complete list directly on the OpenTelemetry website. For this demonstration, we will create a data pipeline using the contrib version of the reference implementation, which provides a good amount of receivers, exporters, and processors. In our case, Otel configuration is designed to: Receive data from Spring Boot workloads (ports 4317 and 4318)Process the data, adding a new tag to metricsExpose an endpoint for Prometheus scraping (port 8889)Send logs to Loki (port 3100) using otlphttp formatSend traces to Tempo (port 9411) using otlp formatExposes a rudimentary dashboard from the collector, called zpages. Very useful for debugging. otel-config.yaml YAML receivers: otlp: protocols: grpc: endpoint: 0.0.0.0:4317 http: endpoint: 0.0.0.0:4318 processors: attributes: actions: - key: team action: insert value: vorozco exporters: debug: prometheus: endpoint: "0.0.0.0:8889" otlphttp: endpoint: http://loki:3100/otlp otlp: endpoint: tempo:4317 tls: insecure: true service: extensions: [zpages] pipelines: metrics: receivers: [otlp] processors: [attributes] exporters: [debug,prometheus] traces: receivers: [otlp] exporters: [debug, otlp] logs: receivers: [otlp] exporters: [debug, otlphttp] extensions: zpages: endpoint: "0.0.0.0:55679" Prometheus Prometheus is a well known analysis platform, that among other things offers dimensional data and a performant time-series storage. By default, it works as a metrics scrapper, then, workloads provide a http endpoint offering data using the Prometheus format. For our example, we configured Otel to offer metrics to the prometheus host via port 8889. YAML prometheus: endpoint: "prometheus:8889" Then, whe need to configure Prometheus to scrape the metrics from the Otel host. You would notice two ports, the one that we defined for the active workload data (8889) and another for metrics data for the collector itself (8888). prometheus.yml YAML scrape_configs: - job_name: "otel" scrape_interval: 10s static_configs: - targets: ["otel:8889"] - targets: ["otel:8888"] It is worth highlighting that Prometheus also offers a way to ingest information instead of scrapping it, and, the official support for OpenTelemetry ingestion is coming on the new versions. Loki As described in the website, Loki is a specific solution for log aggregation heavily inspired by Prometheus, with the particular design decision to NOT format in any way the log contents, leaving that responsibility to the query system. To configure the project for local environments, the project offers a configuration that is usable for most of the development purposes. The following configuration is an adaptation to preserve the bare minimum to work with temporal files and memory. loki.yaml YAML auth_enabled: false server: http_listen_port: 3100 grpc_listen_port: 9096 common: instance_addr: 127.0.0.1 path_prefix: /tmp/loki storage: filesystem: chunks_directory: /tmp/loki/chunks rules_directory: /tmp/loki/rules replication_factor: 1 ring: kvstore: store: inmemory query_range: results_cache: cache: embedded_cache: enabled: true max_size_mb: 100 schema_config: configs: - from: 2020-10-24 store: tsdb object_store: filesystem schema: v13 index: prefix: index_ period: 24h ruler: alertmanager_url: http://localhost:9093 limits_config: allow_structured_metadata: true Then, we configure an exporter to deliver the data to the loki host using oltphttp format. YAML otlphttp: endpoint: http://loki:3100/otlp Tempo In similar fashion than Loki, Tempo is an Open Source project created by grafana that aims to provide a distributed tracing backend. On a personal note, for me besides performance it shines for being compatible not only with OpenTelemetry, it can also ingest data in Zipkin and Jaeger formats. To configure the project for local environments, the project offers a configuration that is usable for most of the development purposes. The following configuration is an adaptation to remove the metrics generation and simplify the configuration, however with this we loose the service graph feature. tempo.yaml YAML stream_over_http_enabled: true server: http_listen_port: 3200 log_level: info query_frontend: search: duration_slo: 5s throughput_bytes_slo: 1.073741824e+09 metadata_slo: duration_slo: 5s throughput_bytes_slo: 1.073741824e+09 trace_by_id: duration_slo: 5s distributor: receivers: otlp: protocols: http: grpc: ingester: max_block_duration: 5m # cut the headblock when this much time passes. this is being set for demo purposes and should probably be left alone normally compactor: compaction: block_retention: 1h # overall Tempo trace retention. set for demo purposes storage: trace: backend: local # backend configuration to use wal: path: /var/tempo/wal # where to store the wal locally local: path: /var/tempo/blocks Then, we configure an exporter to deliver the data to Tempo host using oltp/grpc format. YAML otlp: endpoint: tempo:4317 tls: insecure: true Grafana Loki, Tempo and (to some extent) Prometheus are data storages, but we still need to show this data to the user. Here, Grafana enters the scene. Grafana offers a good selection of analysis tools, plugins, dashboards, alarms, connectors and a great community that empowers observability. Besides having a great compatibility with Prometheus, it offers of course a perfect compatibility with their other offerings. To configure Grafana, you just need to plug compatible datasources, and the rest of the work will be on the web ui. grafana.yaml YAML apiVersion: 1 datasources: - name: Otel-Grafana-Example type: prometheus url: http://prometheus:9090 editable: true - name: Loki type: loki access: proxy orgId: 1 url: http://loki:3100 basicAuth: false isDefault: true version: 1 editable: false - name: Tempo type: tempo access: proxy orgId: 1 url: http://tempo:3200 basicAuth: false version: 1 editable: false apiVersion: 1 uid: tempo Podman (or Docker) At this point, you may have noticed that I've referred to the backends using single names. This is because I intend to set these names using a Podman Compose deployment. otel-compose.yml YAML version: '3' services: otel: container_name: otel image: otel/opentelemetry-collector-contrib:latest command: [--config=/etc/otel-config.yml] volumes: - ./otel-config.yml:/etc/otel-config.yml ports: - "4318:4318" - "4317:4317" - "55679:55679" prometheus: container_name: prometheus image: prom/prometheus command: [--config.file=/etc/prometheus/prometheus.yml] volumes: - ./prometheus.yml:/etc/prometheus/prometheus.yml ports: - "9091:9090" grafana: container_name: grafana environment: - GF_AUTH_ANONYMOUS_ENABLED=true - GF_AUTH_ANONYMOUS_ORG_ROLE=Admin image: grafana/grafana volumes: - ./grafana.yml:/etc/grafana/provisioning/datasources/default.yml ports: - "3000:3000" loki: container_name: loki image: grafana/loki:3.2.0 command: -config.file=/etc/loki/local-config.yaml volumes: - ./loki.yaml:/etc/loki/local-config.yaml ports: - "3100" tempo: container_name: tempo image: grafana/tempo:latest command: [ "-config.file=/etc/tempo.yaml" ] volumes: - ./tempo.yaml:/etc/tempo.yaml ports: - "4317" # otlp grpc - "4318" At this point, the compose description is pretty self-descriptive, but I would like to highlight some things: Some ports are open to the host -e.g. 4318:4318 - while others are closed to the default network that compose will be created among containers -e.g. 3100-This stack is designed to avoid any permanent data. Again, this is my personal way to boot quickly an observability stack to allow tests during deployment. To make it ready for production, you probably would want to preserve the data in some volumes Once the configuration is ready, you can launch it using the compose file Shell cd podman podman compose -f otel-compose.yml up If the configuration is ok, you should have five containers running without errors. Instrumenting Spring Boot Applications for OpenTelemetry As part of my daily activities, I was in charge of a major implementation of all these concepts. Hence, it was natural for me to create a proof of concept that you can find at my GitHub. For demonstration purposes, we have two services with different HTTP endpoints: springboot-demo:8080- Useful to demonstrate local and database tracing, performance, logs and OpenTelemetry instrumentation /books — A books CRUD using Spring Data/fibo — A Naive Fibonacci implementation that generates CPU load and delays/log — Which generate log messages using the different SLF4J levelsspringboot-client-demo:8081- Useful to demonstrate tracing capabilities, Micrometer instrumentation and Micrometer Tracing instrumentation /trace-demo - A quick OpenFeing client that invokes books GetAll Books demo Instrumentation Options Given the popularity of OpenTelemetry, developers can also expect multiple instrumentation options. First of all, the OpenTelemetry project offers a framework-agnostic instrumentation that uses bytecode manipulation, for this instrumentation to work you need to include a Java Agent via Java Classpath. In my experience this instrumentation is preferred if you don't control the workload or if your platform does not offer OpenTelemetry support at all. However, instrumentation of workloads can become really specific — e.g. instrumentation of a Database pool given a particular IoC mechanism. For this, the Java world provides a good ecosystem, for example: QuarkusHelidonPayara And, of course, Spring Boot. Spring Boot is a special case with TWO major instrumentation options OpenTelemetry's Spring Boot starterMicrometer and Micrometer Tracing Both options use Spring concepts like decorators and interceptors to capture and send information to the destinations. The only rule is to create the clients/services/objects in the Spring way (hence via Spring IoC). I've used both successfully, and my heavily opinionated conclusion is the following: Micrometer collects more information about spring metrics. Besides the OpenTelemetry backend, it supports a plethora of backends directly without any collector intervention. If you cannot afford a collector, this is the way. From a Micrometer perspective, OpenTelemetry is just another backend.Micrometer Tracing is the evolution of Spring Cloud Sleuth, hence, if you have workloads with Spring Boot 2 and 3, you have to support both tools (or maybe migrate everything to Spring boot 3?)The Micrometer family does not offer a way to collect logs and send these to a backend, hence devs have to solve this by using an appender specific to your logging library. On the other hand OpenTelemetry Spring Boot starter offers this out of the box if you use Spring Boot default (SLF4J over Logback) As these libraries are mutually exclusive, if the decision were mine, I would pick OpenTelemetry's Spring Boot starter. It offers logs support OOB and also a bridge for micrometer Metrics. Instrumenting springboot-demo With OpenTelemetry SpringBoot Starter As always, it is also good to consider the official documentation. Otel instrumentation with the Spring started is activated in three steps: You need to include both OpenTelemetry Bom and OpenTelemetry dependency. If you are planning to also use micrometer metrics, it is also a good idea to include Spring Actuator XML <dependencyManagement> <dependencies> <dependency> <groupId>io.opentelemetry.instrumentation</groupId> <artifactId>opentelemetry-instrumentation-bom</artifactId> <version>2.10.0</version> <type>pom</type> <scope>import</scope> </dependency> </dependencies> </dependencyManagement> ... <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-actuator</artifactId> </dependency> <dependency> <groupId>io.opentelemetry.instrumentation</groupId> <artifactId>opentelemetry-spring-boot-starter</artifactId> </dependency> There is a set of optional libraries and adapters that you can configure if your workloads already diverged from the "Spring Way" You need to activate (or not) the dimensions of observability (metrics, traces and logs). Also, you can fine-tune the exporting parameters like ports, URLs, or exporting periods. Either by using Spring Properties or env variables Properties files #Configure exporters otel.logs.exporter=otlp otel.metrics.exporter=otlp otel.traces.exporter=otlp #Configure metrics generation otel.metric.export.interval=5000 #Export metrics each five seconds otel.instrumentation.micrometer.enabled=true #Enabe Micrometer metrics bridge Instrumenting springboot-client-demo With Micrometer and Micrometer Tracing Again, this instrumentation does not support logs exporting. Also, it is a good idea to check the latest documentation for Micrometer and Micrometer Tracing. As in the previous example, you need to enable the Spring Actuator (which includes Micrometer). As OpenTelemetry is just a backend from Micrometer's perspective, so you just need to enable the corresponding OTLP registry, which will export metrics to localhost by default. XML <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-actuator</artifactId> </dependency> <dependency> <groupId>io.micrometer</groupId> <artifactId>micrometer-registry-otlp</artifactId> </dependency> In a similar way, once Actuator is enabled, you just need to add support for the tracing backend. XML <dependency> <groupId>io.micrometer</groupId> <artifactId>micrometer-tracing-bridge-otel</artifactId> </dependency> Finally, you can fine-tune the configuration using Spring properties. For example, you can decide if 100% of traces are reported or how often the metrics are reported to the backend. Properties files management.otlp.tracing.endpoint=http://localhost:4318/v1/traces management.otlp.tracing.timeout=10s management.tracing.sampling.probability=1 management.otlp.metrics.export.url=http://localhost:4318/v1/metrics management.otlp.metrics.export.step=5s management.opentelemetry.resource-attributes."service-name"=${spring.application.name} Testing and E2E Sample Generating Workload Data The POC provides the following structure ├── podman # Podman compose config files ├── springboot-client-demo #Spring Boot Client instrumented with Actuator, Micrometer and MicroMeter tracing └── springboot-demo #Spring Boot service instrumented with OpenTelemetry Spring Boot Starter The first step is to boot the observability stack we created previously. Shell cd podman podman compose -f otel-compose.yml up This will provide you with an instance of Grafana on port 3000 Then, it is time to boot the first service!. You only need Java 21 on the active shell: Shell cd springboot-demo mvn spring-boot:run If the workload is properly configured, you will see the following information on the OpenTelemetry container standard output. Which basically says you are successfully reporting data. Shell [otel] | 2024-12-01T22:10:07.730Z info Logs {"kind": "exporter", "data_type": "logs", "name": "debug", "resource logs": 1, "log records": 24} [otel] | 2024-12-01T22:10:10.671Z info Metrics {"kind": "exporter", "data_type": "metrics", "name": "debug", "resource metrics": 1, "metrics": 64, "data points": 90} [otel] | 2024-12-01T22:10:10.672Z info Traces {"kind": "exporter", "data_type": "traces", "name": "debug", "resource spans": 1, "spans": 5} [otel] | 2024-12-01T22:10:15.691Z info Metrics {"kind": "exporter", "data_type": "metrics", "name": "debug", "resource metrics": 1, "metrics": 65, "data points": 93} [otel] | 2024-12-01T22:10:15.833Z info Metrics {"kind": "exporter", "data_type": "metrics", "name": "debug", "resource metrics": 1, "metrics": 65, "data points": 93} [otel] | 2024-12-01T22:10:15.835Z info Logs {"kind": "exporter", "data_type": "logs", "name": "debug", "resource logs": 1, "log records": 5} The data is being reported over the OpenTelemetry ports (4317 and 4318), which are open from Podman to the host. By default, all telemetry libraries report to localhost, but this can be configured for other cases like FaaS or Kubernetes. Also, you can verify the reporting status in ZPages. Finally, let's do the same withthe Spring Boot client: Shell cd springboot-client-demo mvn spring-boot:run As described in the previous section, I created a set of interactions to: Generate CPU workload using Naive fibonacci: Shell curl http://localhost:8080/fibo\?n\=45 Generate logs in different levels: Shell curl http://localhost:8080/fibo\?n\=45 Persist data using a CRUD: Shell curl -X POST --location "http://localhost:8080/books" \ -H "Content-Type: application/json" \ -d '{ "author": "Miguel Angel Asturias", "title": "El señor presidente", "isbn": "978-84-376-0494-7", "publisher": "Editorial planeta" }' And then retrieve the data using a secondary service: Shell curl http://localhost:8081/trace-demo This asciicast shows the interaction: https://asciinema.org/a/692968 Grafana Results Once the data is accessible by Grafana, the what to do with data is up to you. Again, you could: Create dashboardsConfigure alarmsConfigure notifications from alarms The quickest way to verify if the data is reported correctly is to verify directly in Grafana explore. First, we can check some metrics like system_cpu_usage and filter by service name. In this case I used springboot-demo which has the CPU demo using naive fibonacci, I can even filter by my own tag (which was added by Otel processor): In the same way, logs are already stored in Loki: Finally, we could check the whole trace, including both services and interaction with H2 RDBMS: Conclusion In conclusion, implementing OpenTelemetry with Spring Boot provides a robust solution for observability, offering comprehensive insights through metrics, traces, and logs. By integrating tools like Prometheus, Grafana, Tempo, and Loki, you can easily monitor and troubleshoot your applications. Whether you choose OpenTelemetry's Spring Boot starter or Micrometer, both provide powerful instrumentation options, allowing you to gain deeper visibility and improve application performance.

The Challenge: Overloaded QA Teams Every software development company demands rapid growth and continuous innovation. With this, they also need to make sure that the products shipped are of high quality. Usually, all companies have QA (quality assurance) engineers assigned to each team. They are mainly responsible for ensuring that the products going in the customer's hands are of high quality and don't have any defects that could hamper the customer experience. However, when development cycles are very active during a release, the QA resources are constrained, and two major problems arise: Delayed product launches: A backlog of bugs keeps piling up, causing launch delays.Quality compromises: Overextended QA teams struggle to maintain the same standard of quality, allowing trivial bugs to slip through and requiring multiple retesting cycles. When developers rely on QA to detect even trivial issues, the overall time to market increases, and product quality suffers. We are proposing a cultural shift in the software development lifecycle that could help fix the root of these challenges. Once implemented with the available bandwidth, the QA team can focus more on building automation suites and better processes that will help deliver high-quality products on time. The Value of Early Bug Detection Early bug detection is the cornerstone of achieving the most efficient software development lifecycle and thus offers several advantages. Once we have identified the benefit, we can identify the strategies for finding the bugs early in the development itself. There are a lot of advantages to finding bugs early in the software development lifecycle, but based on our experience here, the one that we can see benefits most: Fixing the bugs early in development is significantly cheaper than addressing them in later stages or after the release of a product. It streamlines the development and leads to faster product launches to gain a competitive edge with other businesses. Placing high-quality guard rails, such as unit and integration tests, to catch bugs enhances the software quality and leads to better user experience and increased satisfaction. This benefits not only the company but also the software developers themselves because it boosts their morale and engagement with the feature they are developing. It ultimately empowers them to take ownership of quality and, thus, fosters a sense of pride and accomplishment. Strategies for a Left-Shifted Culture Early bug detection is a cornerstone to achieve the most efficient software development life-cycle and offers several advantages. Once we have identified the benefits we can identify the strategies to find the bugs early in software development itself. A shift-left culture involves both technical and organizational practices. Here are four strategies that can make an immediate impact: 1. Comprehensive Testing by Developers What it is: Leadership should encourage and provide enough bandwidth to developers for writing unit and integration test cases as part of the initial deliverable for every feature or bug fix. They should also provide enough artifacts from local functional testing in the code review description.Why it works: By the time QA receives the build, most trivial defects are already resolved, reducing back-and-forth cycles. 2. Static Code Analysis What it is: There should be automated hooks (e.g., SonarQube, Checkstyle, FindBugs) that run while creating the code review to run static code analysis. These tools will check for code smells, security vulnerabilities, and coding-standard violations before the code merges.Why it works: Potential defects and security gaps are flagged early, giving developers immediate feedback and reducing rework later. 3. Code Review Templates What it is: There should be a template that every code-reviewer should always follow to make sure they are raising the bar and shipping high-quality code that has good documentation, correct artifacts from testing, and has ensured that potential issues are getting addressed.Why it works: Consistency in code reviews ensures no critical step is overlooked, and fosters a culture of continuous improvement among developers. 4. Continuous Integration/Continuous Delivery (CI/CD) What it is: Continuous integration and development pipelines are automated to build and test the features and land to QA testing only when they are ready in beta environments.Why it works: QA can focus on higher-level testing and acceptance criteria, knowing the basic functionality has already been validated. The Role of Leadership in Driving Cultural Change Cultural transformations succeed when leadership champions and consistently enforces new processes. Here are four leadership-driven initiatives to support a shift-left plan: 1. Communicate the Vision What to do: The leadership should clearly communicate the vision to all the developers and QA on this shift in culture and their benefits to the organizations. They should also establish a core team that would be advocating for this shift throughout the organization and will track progress of the adoption.Outcome: When team members understand why they are changing habits, they are more motivated to adopt new practices. 2. Empower and Train Developers What to do: Provide training sessions on writing effective unit tests, using static code analysis tools, and performing robust peer reviews. But apart from this leadership should also provide developers autonomy to make adjustment based on the individual team dynamics.Outcome: Developers feel confident about their ability to uphold quality, leading to fewer defects escaping into later stages. 3. Foster Collaboration and Define Metrics What to do: QA and developers should work together well in-advance to create a test-suite that can mark as acceptance criteria for any feature built by the developers.Outcome: Metrics such as the number of defects found in QA vs. in development—and the time from discovery to resolution—reveal the effectiveness of the shift-left strategy. 4. Establish a Feedback Loop and Recognize Achievements What to do: Encourage continuous feedback on how well the new processes are working. Reward teams or individuals who demonstrate exceptional adherence to the new quality standards.Outcome: Recognition drives culture change. Positive reinforcement cements new behaviors as part of the organization’s DNA. Conclusion: Long-Term Benefits for Faster, Higher-Quality Releases By embracing the culture of early bug detection and continuous improvement, any software development organization can overcome the challenges around QA resourcing that can help ship high-quality products faster. This is a culture change plan that is driven by leadership that empowers developers to work towards building high-quality features that can help reduce bug detection in later stages of the software development cycle and thus help faster time-to-market and optimized resource utilization. With a reduced number of bugs, QA has to report that they get more bandwidth to invest in automation test-suites and better processes to increase the bar of quality of product. This long-term investment strategy will pay the dividends in faster releases, increased customer satisfaction, and sustained growth.

Building a Highly Generic Tool for Copying Transactional Data Years ago, I set out to build a tool to copy transactional data from one environment to another. A single transaction could span 350+ tables, though not all transactions used all tables. Different transaction types would touch different subsets of these tables. Given this complexity, coding this in Java seemed like a massive undertaking. It was my pet project that I wanted to do during weekends, etc., besides my other important projects, so I had to find shortcuts and ensure high reusability of code. The Challenge? Writing 100,000+ lines of code to handle individual table reads and inserts.Maintaining this code as table structures changed frequently to add new features almost every month.Ensuring key values were correctly generated, as they relied on Oracle sequences rather than direct copies.Minimizing manual effort, complexity, and long-term maintenance. I needed a solution that required minimal code, could adapt dynamically to schema changes, and eliminated ongoing maintenance. First Attempt: Scripts and Data Pump Utility Initially, I explored using scripts and the Oracle Data Pump utility, which supports complex queries. While this seemed like a viable option, I hit a political roadblock — the DB team didn’t allow non-DB personnel to run complex queries or try their ideas on the DB as DB was handled by dedicated DB developers. Teams in large corporations can be territorial, and I had to find another way. The Breakthrough: A Highly Generic Approach I had to design this such that there is high re-use of code. I followed one of my core principles of genericity: If you write even a single line of code, ensure it gets reused by wrapping it inside a function. With that in mind, I designed the solution with a main orchestrator class, a few supporting classes, and a class that implemented the database operations around just two functions with some supporting functions inside the class: A function to run a SELECT query.A function to run an INSERT query. No individual queries for 350+ tables, just a handful of highly generic functions! However, the queries needed to come from outside the code to avoid constant modifications. Dynamic Query Generation Using a Config File Instead of hardcoding queries, I structured everything using a configuration file that: Contained SELECT statements for each table in the correct sequence of insertion.Used subqueries to relate data back to the main primary key — sometimes with nested dependencies.Ensured foreign key relationships were handled dynamically.Eliminated code changes when tables evolved — only the config needed updating. Handling Schema Changes at Runtime Since the tool worked dynamically at runtime, I couldn’t rely on an object model. But that wasn’t a problem. Every result set contained field names, effectively allowing dynamic object modeling. The next challenge? Inserting data with the correct datatype. Oracle’s sysCols, sysColumns, and other metadata tables provided field details.I mapped data types properly to prevent query failures.Special handling for BLOBs, CLOBs, and other non-standard types was added. This approach meant we looped over every field in every table, determining its type dynamically and constructing the correct INSERT statements at runtime. Performance Bottleneck and Optimization The first run took over 40 minutes, and this was totally unacceptable. The solution? Multi-threading. However, I strictly followed another personal principle for multi-threaded programming: Do not share data or resources between threads if you want true parallel execution. The existing config file wasn’t structured for parallel execution, so I: Grouped tables logically, allowing independent execution.Designed threads to run in parallel without dependencies.Ensured data integrity despite concurrent operations. This restructuring took a while to analyze 350+ table relationships, but the payoff was enormous — execution time dropped from 40 minutes to under 1 minute! Connection Management I didn’t use Hikari connection pooling or any other similar JAR (I can’t recall why), but I had extensive C# experience handling database connections manually. So, I implemented a lightweight connection pooling mechanism — keeping connections open for a limited number of operations before refreshing them. I noticed this connection pooling was more beneficial as it was tailored to my use case. Impact & Value Delivered This tool dramatically improved the productivity of developers and QA teams: Drastically reduced test data setup time from hours to mere minutes. Enabled easy replication of test scenarios across environments. Adapted dynamically to schema changes without modifying code. Required just ~5,000 lines of code instead of 100,000+ — a 95% reduction! Whenever a new table was added, only a single line was added in the config file. The code remained untouched — a true victory in generic, maintainable software design. And yes, for those curious, the UI was built in AngularJS. Final Thoughts This was one of my favorite pet projects because it embodied high genericity, efficiency, and maintainability. I love designing solutions that eliminate unnecessary work, reduce technical debt, and maximize long-term value, and this tool was a perfect example of that. I wanted to give it to other groups with other applications, as the code did not have any application-specific implementation. The config file needed changes as this is a different database. Also, the connection configuration is needed to point to the new database to populate the drop-down. So, it was essentially a product that could be used by any team utilizing any Oracle DB schema. Hope you learnt a thing or two — I always look back to it with a sense of pride and satisfaction. My new pet project is a no-code, low-code digitization platform; check it out here.

A detailed website QA checklist helps make sure every aspect of the website is tested, whether through manual or automated testing approaches. It usually covers parameters like functionality, performance, usability, security, and compatibility across various browsers and devices. By following the website QA checklist, testers can test the website step-by-step, making sure everything works well without any bugs. This approach keeps the website running smoothly and meeting both user expectations and business needs. Why Is Website QA Checklist Important? A website QA checklist acts as a detailed guide for testers to ensure everything on a website works correctly before it launches. Using this checklist helps guarantee that the website functions well, providing a smooth and error-free experience for users. Here’s why a website QA checklist is important: Tests thoroughly all key components of the website.Checks functionality, usability, performance, security, and compatibility.Improves user satisfaction by ensuring a smooth experience.Prevents missing important testing steps.Aligns website quality with business goals and user needs.Identifies issues early, avoiding expensive fixes after launch. Website QA Checklist A website Quality Assurance (QA) checklist is a way to evaluate various aspects of a website that helps ensure if the website meets functional, performance, and user experience standards or not. By following the website QA checklist, the team can identify potential issues before the website is launched; this pre-identification of bugs or issues can help enhance the overall website quality and user satisfaction. Below are the website QA checklists that you should use as a guide to ensure the quality and functionality of the website. QA Planning Planning your test project is essential for managing resources effectively and ensuring the QA team knows exactly what needs to be done to achieve website goals. Here’s what a test plan should include: Objective: Testing Goals: Define what you aim to achieve with your tests, such as verifying the payment gateway’s functionality.Features to Test: Identify specific functions to evaluate, like user registration and product search.Success Criteria: Determine how you will measure success, for instance, through successful transactions and accurate data validation. Approach: Testing Methods: Decide on the techniques you will use, such as exploratory and regression testing.Levels of Testing: Outline the different testing stages required, like unit testing for individual components and integration testing for system components.Methodologies or Frameworks: Choose the methodologies or frameworks that will guide your testing process. Scope: Included Testing Areas: Specify what will be tested, such as the front-end interface and back-end database.Excluded Areas: Note what won’t be tested, such as incomplete third-party integrations.Constraints: Mention any limitations or constraints, like restricted access to production data. Test Deliverables: Document Outlining the Test Plan: What should your test plan document cover? For example, test goals and strategies.Test Cases and Scripts: How will you create test cases or scripts? For example, using a test management tool and writing scripts in a programming language.Reports and Summaries: What reports or summaries will you need? For example, test summaries and defect reports with priority levels. Dependencies: External Factors: Identify any external factors that may impact testing, such as test environment availability and third-party data.Prerequisites: List the necessary prerequisites, like completed UI design and backend integration.Handling Dependencies: Plan how to manage dependencies, such as coordinating with the UI team on specifications. Test Environment: Hardware and Software Needs: Specify the required hardware and software, like specific browsers and system requirements.Setting Up the Environment: Outline how to establish the test environment, including setting up virtual machines and installing necessary software.Required Tools: Identify any tools needed, such as Selenium for browser testing and JMeter for performance testing. Risk Management: Potential Risks: What risks and uncertainties might you face? For example, lack of test data or resource limitations.Risk Assessment: How will you evaluate risk? For example, a risk matrix can be used to measure impact and likelihood.Risk Management Strategies: What strategies will you use to manage risks? For example, creating backup data or adding resources for key tasks. Schedule: Testing Timeline: Define the overall testing schedule, like testing from week 3 to week 5.Milestones: Set key milestones, such as completing test cases by week 4 and starting test execution by week 2.Task Allocation: Plan how to allocate time for various tasks. UI Testing UI testing is a critical part of website QA to ensure that the interface and user experience meet expectations. You can follow the below-mentioned website QA checklist while performing UI/design testing to ensure the website is easy to navigate and visually appealing across all devices. Layout and Design: Ensure elements like headers, footers, and sidebars are consistent. Check that everything aligns properly and follows brand guidelines for colors, fonts, and images.Navigation: Test menus for clarity and functionality. Make sure links and buttons work correctly and that the navigation flows logically.Responsiveness: Ensure the website adapts well across different devices and screen sizes, with all elements adjusting appropriately.Content Presentation: Review text readability, including font sizes and spacing. Verify that images, videos, and audio are displayed correctly.Forms and Input Fields: Test all form elements to ensure they function properly and validate input. Check that error messages are clear and helpful.Accessibility: Perform tests to check the site meets accessibility standards, works with screen readers, and supports keyboard navigation. Content Testing Content testing is crucial for website QA to ensure that all textual and multimedia material is accurate, uniform, and meets user expectations. You can follow the below-mentioned website QA checklist while performing content testing to ensure the website aligns with SEO guidelines and provides valuable content for users. Correct Spelling and Grammar: Check that there are no spelling or grammar mistakes in the content of any text shown on the website.Correctness of Information: The information added to the website should be verified to ensure it is correct and present.Consistency in Branding: Verify that the content is consistent with the brand's identity, including its voice, messaging, and visual components.Presentation and Design: Ensure that the formatting and display of text, images, videos, and other multimedia elements are correct. They should also be the same across devices and screen sizes.Adherence to Laws and Regulations: Ensure that the website adheres to copyright regulations and contains essential disclaimers, privacy policies, and terms of service. Functional Testing Functional testing ensures that your website operates as expected and meets all specified requirements. You can follow the below-mentioned website QA checklist while conducting functional testing to ensure the website operates as expected and meets all functional requirements. Navigation and Links: Check Navigation Menus: Make sure all your main and submenus are visible and accessible.Test Links: Click on each link to ensure it directs to the right page. Look out for broken links and fix any redirects.Anchor Links: Confirm that anchor links correctly scroll to the intended sections.BreadCrumbs: Verify that breadcrumb navigation works consistently.External Links: Ensure these open in a new tab or window if that’s how you set them up.Keyboard Accessibility: Test that navigation is easy for users who only use keyboards.Responsiveness: Make sure the menu works well on various devices and screen sizes. Forms and Input Fields: Required Fields: Ensure all required fields are marked and can’t be submitted empty.Validation Rules: Check each field for proper validation (e.g., email formats and character limits).Error Messages: Make sure error messages are clear and helpful for correcting mistakes.Optional Fields: Test that leaving optional fields blank doesn’t cause issues.Input Sanitization: Prevent code injection and unintended characters.Field Usability: Verify tab order, focus, and visibility of placeholder text.Special Characters: Ensure the form handles special characters and whitespace properly.Data Submission: Confirm that form data is correctly processed and sent to your systems. User Registration and Login: Registration: Test the registration process with valid details.Login: Verify that logging in works with the correct credentials.Error Handling: Check how the system responds to incorrect login attempts.Password Recovery: Ensure the password reset process works smoothly.Account Activation: Test account activation if it’s part of your process.Security: Verify security features like two-factor authentication and encrypted passwords. Search Functionality: Search Results: Ensure search results are relevant and accurate.Filters and Sorting: Test search filters and sorting options.Pagination: Check if pagination or infinite scrolling works properly.Performance: Test how the search performs with large datasets.Search Suggestions: Verify that auto-complete and search suggestions function correctly.No Results: Ensure the system handles searches with no matches gracefully. Images and Videos: Display and Loading: Confirm that images and videos load correctly and display as expected.File Formats: Check compatibility with different file formats.Responsiveness: Test image and video resizing on various devices.Galleries and Sliders: Verify the behavior of galleries and sliders.Playback: Ensure video playback controls (play, pause, volume) work as intended.Performance: Test the loading speed of large or high-resolution files. Interactivity: Dynamic Content: Validate that content updates and notifications appear in real-time.Interactive Features: Test drag-and-drop, sliders, and carousels for smooth operation.Animations: Ensure animations and transitions are working correctly.User Feedback: Check hover effects and tooltips for accuracy.Interactive Elements: Verify that maps, charts, and other interactive features function properly. Usability Testing Usability testing is essential to make sure your website offers a smooth and effective user experience. You can follow the below-mentioned website QA checklist while performing usability testing to ensure the UI is intuitive and easy to navigate. Demographic Information: Know who your users are—consider their age, gender, location, etc.User Objectives and Actions: Determine the goals that users want to achieve when visiting your website.Preferences for Devices and Platforms: Identify if users favor desktop or mobile devices and which operating systems they prefer.Accessibility Needs: Consider the needs of users with disabilities or specific accessibility requirements.Language Preferences: Determine the languages that your website should offer for optimal user experience.Content Interests: Determine the types of content your users are looking for or expect to see.Frequency of Use: Consider if users access your website consistently or infrequently.Customer Segmentation: Segmenting users help improve audience targeting through the analysis of various user groups.Stakeholder Feedback: Gather feedback from stakeholders or current users to align with their needs and preferences.Legal and Compliance Standards: Ensure your website complies with all required legal or regulatory criteria, including age limitations. Regression Testing After updating the website, perform regression testing to ensure that any changes have not caused any negative impact on the existing features and functions. You can follow the below-mentioned website QA checklist to perform regression testing effectively and ensure everything works as expected. Conduct Post-Update Testing: Run regression tests after making any changes or updates to your website to ensure it remains compatible across different platforms.Check New Features for Compatibility: Ensure that any new features or fixes do not cause compatibility issues with various browsers, devices, or operating systems.Maintain a Comprehensive Test Suite: Keep a detailed regression test suite that covers compatibility scenarios across all the platforms your website supports. Accessibility Testing It is very important to ensure that your website is inclusive to all, including individuals with disabilities. You can follow the below-mentioned website QA checklist while performing accessibility testing to ensure your website adheres to WCAG standards and is accessible to everyone, including people with disabilities. Test Accessibility Features: Evaluate the accessibility features of your website across different platforms to ensure compliance with the necessary standards.Keyboard Navigation: Test navigation through a keyboard, ensure it’s compatible with screen readers, and verify the functionality of other assistive technologies.Inclusivity on All Platforms: Ensure users with disabilities can effectively interact with your website across all platforms.Color Contrast: Confirm the color contrast on your site meets the required readability standards. Cross-Browser Testing Compatibility testing plays a key role in making sure your website performs well across all kinds of operating systems and devices. You can follow the below-mentioned website QA checklist while performing cross-browser testing to ensure your website functions consistently across different browsers. Cross-Platform Testing: Check how your website functions on platforms like Windows, macOS, iOS, and Android.Browser Testing: Make sure your site behaves consistently across different browsers and their various versions.Mobile Device Testing: Test your site on multiple mobile devices to ensure users have a smooth experience. This includes checking touch interactions, device-specific features, and both portrait and landscape modes.Network Speed: Test performance under various network conditions and verify smooth loading and data transfer even on slower connections. Performance Testing Performance testing is essential for spotting and fixing issues that might affect how users experience your website. You can follow the below-mentioned website QA checklist while performing performance testing to ensure the website responds quickly and remains stable, even under heavy traffic. Average Response Time: Measure how quickly the site responds to typical user actions.Response Time During Peak Load: Check response times during high-traffic periods.Transaction Throughput: Track how many transactions are processed each second.Server CPU Usage: Monitor CPU usage to keep it within safe limits under load.Memory Usage: Review memory use and allocation for potential inefficiencies.Network Latency: Evaluate response times across different geographic regions.Concurrent User Capacity: Determine how many users the site can handle before performance drops.Connection Pool Efficiency: Evaluate how connection pooling affects response times.Page Load Time: Measure load times for various page types and sizes.Database Query Performance: Look at database query efficiency and optimization opportunities.Caching Effectiveness: Analyze how well caching reduces response times.Error Rates: Track error rates and handling during high-traffic periods. API Testing API testing is important for websites that use third-party services or have intricate back-end systems. You can follow the below-mentioned website QA checklist while performing API testing effectively. Focus on the following areas while performing website testing: Request Validation: Check parameters, headers, and payloads to ensure they are correct.Response Validation: Verify status codes, headers, and data for accuracy.Error Handling: Test error responses and error codes to ensure proper handling.Authentication and Authorization: Confirm that mechanisms are correctly implemented.Rate Limiting and Throttling: Ensure APIs handle traffic limits and prevent abuse.Data Validation: Check for data integrity and correctness.API Methods: Test various API methods such as GET, POST, etc.Endpoints and URL Structures: Validate API endpoints and their URL formats.Query Parameters and Filters: Test how the API handles various parameters and filters.Caching: Assess API caching and cache control headers.Security: Verify API security features such as SSL/TLS encryption.Concurrent Requests: Test the API’s performance with multiple concurrent requests and limits.Load and Performance: Evaluate and test the performance of the API across different load scenarios.Integration with Third-Party Systems: Consider the level of integration of the API with external systems or services.Versioning and Compatibility: Ensure that API version handling is managed and that backward compatibility is maintained.Webhook and Notifications: Test webhook functionality and event notifications.Edge Cases and Boundaries: Assess the API’s handling of edge cases and boundary conditions.Documentation: Ensure API documentation is accurate and complete. Database Testing Any data entered, modified, or removed on a website must be accurately reflected in the backend database. You can follow the below-mentioned website QA checklist for performing database testing effectively. Integrity: Ensure data accuracy and consistency throughout its lifecycle, verifying that what’s shown on the website aligns with the backend database.Performance: The website must manage multiple database queries efficiently without causing delays, particularly for high-traffic sites. Cookie Handling Handling cookies involves checking if cookies work for managing sessions and tracking, ensuring a consent method, and assessing privacy practices. You can follow the below-mentioned website QA checklist for cookie handling during website testing. Cookie Functionality: Check if cookies are used appropriately for managing sessions, storing user preferences, and tracking activities.Consent Mechanism: Ensure there is a functional consent mechanism for cookies, particularly if adhering to privacy laws such as GDPR.Data Privacy: Review how data collected by cookies is managed, ensuring it complies with data protection regulations.Expiration and Deletion: Verify that cookies have proper expiration settings and allow users to delete them easily.Secure Transmission: Confirm that sensitive cookies are transmitted securely via HTTPS.Documentation: Keep detailed records of cookie types, their purposes, and how data is managed.Regular Auditing: Conduct periodic audits to stay compliant with changing privacy standards. Security Testing Ensuring security on your website is crucial to protect sensitive data and maintain user trust. You can follow the below-mentioned website QA checklist while performing security testing to help you identify vulnerabilities and strengthen security measures effectively. Identifying Vulnerabilities: Spot potential weaknesses that hackers could exploit.Common Issues: Test for SQL injection, XSS, CSRF, and ensure data encryption.Protection and Trust: Safeguard the website and users from breaches, maintaining trust and reputation.Encryption: Verify SSL implementation to protect data like personal info and credit card numbers.User Authentication: Ensure secure and user-friendly registration, login, and password recovery processes.Payment Gateways: Test for compliance and security in online transactions, ensuring smooth, error-free payments.Secure Configuration: Look at server and app settings to spot and fix any security weaknesses.Security Headers: Confirm that security headers are in place to guard against common web threats.Vulnerability Scanning: Regularly scan for security flaws using automated tools and manual checks. For a comprehensive approach to quality assurance, explore this web application testing checklist to ensure your web applications deliver a seamless and bug-free experience across browsers and devices. Looking to cover mobile applications, too? This mobile app testing checklist dives into essential testing practices for performance, usability, and compatibility on various mobile platforms. Both checklists are must-reads for delivering top-notch user experiences! Conclusion Having a website alone is not enough for online success. To ensure a flawless and user-friendly experience, organizations must conduct thorough website QA testing. This step is crucial for developing high-functionality and quality software applications. To ensure this in a better way, the QA checklist provided will guide teams in addressing key aspects of website testing, helping them deliver robust web applications.