Cloud Architecture

The fast growth of artificial intelligence (AI) has created new opportunities for businesses to improve and be more creative. A key development in this area is intelligent agents. These agents are becoming critical in transforming DevOps and cloud delivery processes. They are designed to complete specific tasks and reach specific goals. This changes how systems work in today's dynamic tech environments. By using generative AI agents, organizations can get real-time insights and automate their processes. This helps them depend less on manual work and be more efficient and scalable. These agents are not just simple tools — they are flexible systems that can make informed decisions by using the data they collect and their knowledge base. As a result, they provide great value, by optimizing how resources are used, lowering the risk of errors, and boosting overall productivity. A Smarter Approach to DevOps In traditional DevOps, automation is very important for success, yet it often depends on static rules and predefined scripts. While this method works well, it can have problems when there are unexpected changes in workloads or environments. AI agents can help with this. They bring a layer of adaptability that can deal with these potential issues. AI agents look at current conditions and use lessons learned from past experiences to suggest or make changes. For example, in cloud delivery, they can improve how resources are used. This helps make sure systems have just the right amount of resources, so they are not over-provisioned or under-resourced. This change not only cuts costs but also keeps things running smoothly during critical operations. Moreover, AI agents can access and use information from their knowledge base. This helps them predict challenges and suggest solutions. This way, systems stay resilient even when things are uncertain. How to Use AI in DevOps One great use of AI agents in DevOps is managing cloud environments. Google Cloud is using AI automation to improve scalability, security, and efficiency. What really makes cloud delivery better are the different types of AI agents made for specific tasks. Real-Time Resource Management AI agents are great at adjusting resources based on changing needs. They look at traffic patterns, application performance, and user demand. For example, when a new product is launched, they make sure cloud resources scale to handle the surge in visitors. Once the traffic calms down, the resources can go back to normal levels. This use of AI helps organizations deal with changing workloads easily. It gives a smooth user experience and keeps costs under control. Proactive Security Security is another important area where AI agents have a big effect. They look at activity logs and how systems behave in real-time. This way they can spot unusual activity and flag potential threats before they get worse. This proactive way of identifying threats helps reduce risks and keeps sensitive data safe, even in dynamic cloud environments. AI in Development The development phase usually includes tasks some repetitive tasks, such as writing test cases, debugging code, and preparing for deployments. These manual processes can make productivity slower, introduce errors, and raise costs. AI agents help make repetitive work easier by automating it and offering valuable insights. For example, testing teams can use generative AI agents to automate the test case creation. This helps in comprehensive coverage of all new features without needing a lot of manual work. These agents can also give product recommendations for changes in configuration or optimizations, by looking at historical data, which helps improve the overall quality of the application. Their ability to give real-time feedback helps developers spot problems quickly. They do not have to wait for scheduled reviews. This quick response speeds up development. It also makes sure that the final product is robust and reliable. Intelligent Decision-Making in DevOps One strong point of AI agents is they can make smart decisions autonomously. They use collected data along with what they know in their internal model of the world. This helps them look at different options and make the best decisions. How AI Agents Think and Act To better understand how AI agents operate, let's break down the iterative process they follow, which enables them to adapt and improve all the time: Observation: AI agents collect data from logs, user interactions, and system metrics.Analysis: They use machine learning to process different data sources. They also rely on their knowledge base to find patterns and spot differences.Decision-making: After analysis, they consider possible outcomes and pick the best action to take based on the insights and relevant information.Adaptation: Feedback from their decisions refines the agent’s internal model for continuous improvement. This process of observing, analyzing, making decisions, and adapting helps AI agents stay useful. They can adjust as tasks change or new problems arise. The Human Element: Collaboration Between Teams and AI AI agents are here to help humans, not take their place. For example, a sales team can use AI to understand customer behavior better. This helps them adjust their approach and improve customer engagement. DevOps teams can also use AI to manage simple, but also complex tasks. This gives them more time to innovate and make strategic choices. This partnership goes beyond just giving out tasks. AI agents offer helpful insights. These insights help teams make better and quicker decisions. Whether it is about using resources wisely or identifying inefficiencies in a pipeline, the teamwork between people and AI agents leads to amazing productivity. Best Practices for Integrating AI Agents To get the most out of AI agents, organizations need to have a smart plan for how to include them. Here are some best practices to follow: Starting small: Start with clear workflows where AI can show real benefits.Ensuring security: Set strong rules for managing data to keep sensitive information safe.Continuous monitoring: Use analytics in real-time to track agent performance and find ways to improve them.Training teams: Provide employees with the skills they need to work well with AI agents. By using these practices, companies can reach the full benefits of AI. They can lower risks and increase their return on investment (ROI). The Future of Intelligent Automation As more companies use AI in DevOps and cloud delivery, there are many opportunities for new ideas. From reducing the risk of errors to improving customer engagement, AI agents are becoming very important for businesses that want to stay ahead. Organizations can use technologies like generative AI, natural language processing, and real-time decision-making. This will help them build systems that are efficient. These systems will also be adaptable and smart. The future is for those who embrace these new ideas today and transform their workflows to get ready for the challenges of tomorrow. Conclusion AI agents are a big step forward for how businesses handle DevOps and cloud delivery. They can take care of specific tasks, adjust to new environments, and make informed decisions. This makes them essential in today’s work processes. As businesses keep using AI solutions, they should focus on using these technologies in a strategic way. This can help them grow, work better, and be more creative. It’s important that their teams feel strong and ready to do well during this process. The question is no longer if AI will change the future of DevOps. It is about how fast companies can harness AI's potential to shape that future.

By Marija Naumovska CORE

Operators are a powerful way to extend Kubernetes functionality by acting as custom controllers. They leverage the Kubernetes control loop to manage application lifecycles using declarative custom resources. In this guide, we’ll create a simple “Hello” Operator with the Operator SDK, deploy it on Minikube, and see it in action. Prerequisites Before we begin, make sure you have the following installed and set up on your machine: Minikube You can grab Minikube from the official docs. Start Minikube by running: Shell minikube start Verify the Minikube cluster: PowerShell kubectl cluster-info Go (1.19 or Later) You can download and install Go from the official website. Operator SDK Follow the Operator SDK installation docs to install. Confirm the version: Shell operator-sdk version Docker (Or Similar Container Runtime) We’ll use Docker for building and pushing container images. With these tools in place, you’re all set for a smooth Operator development experience. Project Setup and Initialization Create a Project Directory Let’s begin by creating a fresh directory for our project: Shell mkdir sample-operator-project cd sample-operator-project Initialize the Operator Next, we’ll initialize our Operator project using the Operator SDK. This command scaffolds the basic project layout and configuration files: Shell operator-sdk init --domain=example.com --repo=github.com/youruser/sample-operator Here’s what the flags mean: --domain=example.com sets the domain for your Custom Resources.--repo=github.com/youruser/sample-operator determines the Go module path for your code. You’ll see a freshly generated project structure: Shell sample-operator-project/ ├── Makefile ├── PROJECT ├── go.mod ├── go.sum ├── config/ │ └── ... ├── hack/ │ └── boilerplate.go.txt ├── main.go └── ... Creating the API and Controller Add Your API (CRD) and Controller Our next step is to create the Custom Resource Definition (CRD) and its associated controller. We’ll make a resource called Hello under the group apps and version v1alpha1: Shell operator-sdk create api --group apps --version v1alpha1 --kind Hello --resource --controller This command generates: A new API package under api/v1alpha1/A controller source file in controllers/hello_controller.go Define the Hello CRD Open the file api/v1alpha1/hello_types.go. You’ll see the Hello struct representing our custom resource. We can add a simple Message field to the Spec and a LastReconcileTime field to the Status: Go package v1alpha1 import ( metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" ) // HelloSpec defines the desired state of Hello type HelloSpec struct { // Message is the text we want our operator to manage. Message string `json:"message,omitempty"` } // HelloStatus defines the observed state of Hello type HelloStatus struct { // Stores a timestamp or an echo of the message LastReconcileTime string `json:"lastReconcileTime,omitempty"` } //+kubebuilder:object:root=true //+kubebuilder:subresource:status // Hello is the Schema for the hellos API type Hello struct { metav1.TypeMeta `json:",inline"` metav1.ObjectMeta `json:"metadata,omitempty"` Spec HelloSpec `json:"spec,omitempty"` Status HelloStatus `json:"status,omitempty"` } //+kubebuilder:object:root=true // HelloList contains a list of Hello type HelloList struct { metav1.TypeMeta `json:",inline"` metav1.ListMeta `json:"metadata,omitempty"` Items []Hello `json:"items"` } Once you’re done, run: Shell make generate make manifests make generate regenerates deepcopy code, and make manifests updates your CRDs in the config/ directory. Implementing the Controller Open controllers/hello_controller.go. The core function here is Reconcile(), which defines how your Operator “reacts” to changes in Hello resources. Below is a minimal example that logs the message and updates LastReconcileTime: Shell package controllers import ( "context" "fmt" "time" "github.com/go-logr/logr" ctrl "sigs.k8s.io/controller-runtime" "sigs.k8s.io/controller-runtime/pkg/client" appsv1alpha1 "github.com/youruser/sample-operator/api/v1alpha1" ) // HelloReconciler reconciles a Hello object type HelloReconciler struct { client.Client Log logr.Logger } //+kubebuilder:rbac:groups=apps.example.com,resources=hellos,verbs=get;list;watch;create;update;patch;delete //+kubebuilder:rbac:groups=apps.example.com,resources=hellos/status,verbs=get;update;patch //+kubebuilder:rbac:groups=apps.example.com,resources=hellos/finalizers,verbs=update func (r *HelloReconciler) Reconcile(ctx context.Context, req ctrl.Request) (ctrl.Result, error) { log := r.Log.WithValues("hello", req.NamespacedName) // Fetch the Hello resource var hello appsv1alpha1.Hello if err := r.Get(ctx, req.NamespacedName, &hello); err != nil { // Resource not found—likely it was deleted log.Info("Resource not found. Ignoring since object must be deleted.") return ctrl.Result{}, client.IgnoreNotFound(err) } // Print the message from Spec log.Info(fmt.Sprintf("Hello Message: %s", hello.Spec.Message)) // Update status with current time hello.Status.LastReconcileTime = time.Now().Format(time.RFC3339) if err := r.Status().Update(ctx, &hello); err != nil { log.Error(err, "Failed to update Hello status") return ctrl.Result{}, err } // Requeue after 30 seconds for demonstration return ctrl.Result{RequeueAfter: 30 * time.Second}, nil } // SetupWithManager sets up the controller with the Manager. func (r *HelloReconciler) SetupWithManager(mgr ctrl.Manager) error { return ctrl.NewControllerManagedBy(mgr). For(&appsv1alpha1.Hello{}). Complete(r) } This snippet ensures each time the custom resource changes, the operator logs a message and updates the status to reflect the time it was last reconciled. Building and Deploying the Operator Set the Container Image In the Makefile, locate the line: CMake IMG ?= controller:latest Replace it with your desired image name (e.g., a Docker Hub repo): CMake IMG ?= your-docker-username/sample-operator:latest Build and Push To build and push your operator image: CMake make docker-build docker-push docker-build compiles your Operator code into a Docker image.docker-push pushes it to your specified image repository. Deploy Onto Minikube Install CRDs: CMake make install This applies your CRD manifests to the cluster. Deploy operator: CMake make deploy This command sets up the operator in a dedicated namespace (usually <project>-system), creates a Deployment, and configures RBAC rules. Check that your deployment is running: Shell kubectl get deployments -n sample-operator-system You should see something like: Shell NAME READY UP-TO-DATE AVAILABLE AGE sample-operator-controller-manager 1/1 1 1 1m Testing Your Operator Create a Hello Resource We’ll now create a sample custom resource to watch the operator in action. Create a file named hello-sample.yaml with the following content: YAML apiVersion: apps.example.com/v1alpha1 kind: Hello metadata: name: hello-sample spec: message: "Hello from my first Operator!" Next, apply the resource: Shell kubectl apply -f hello-sample.yaml Check the CRD's Status Shell kubectl get hellos You should see something like the following: Shell NAME AGE hello-sample 5s Verify Logs and Status Take a look at the operator’s logs: Shell kubectl get pods -n sample-operator-system # Identify the sample-operator-controller-manager pod name, then: kubectl logs sample-operator-controller-manager-xxxxx -n sample-operator-system --all-containers Next, you should see something like: Shell 1.590372e+09 INFO controllers.Hello Hello Message: Hello from my first Operator! You can also inspect the resource’s status: Shell kubectl get hello hello-sample -o yaml Final Project Layout Here’s how your project folder might look at this point: Shell sample-operator-project/ ├── Makefile ├── PROJECT ├── config/ │ ├── crd/ │ │ └── bases/ │ │ └── apps.example.com_hellos.yaml │ ├── default/ │ │ └── kustomization.yaml │ ├── manager/ │ │ ├── kustomization.yaml │ │ └── manager.yaml │ ├── rbac/ │ │ ├── cluster_role.yaml │ │ └── role.yaml │ ├── samples/ │ │ └── apps_v1alpha1_hello.yaml │ └── ... ├── api/ │ └── v1alpha1/ │ ├── hello_types.go │ ├── groupversion_info.go │ └── zz_generated.deepcopy.go ├── controllers/ │ └── hello_controller.go ├── hack/ │ └── boilerplate.go.txt ├── hello-sample.yaml ├── go.mod ├── go.sum └── main.go Conclusion You have just developed a simple Kubernetes Operator that watches a Hello custom resource, prints its message into the logs, and changes its status every time it reconciles. On top of this basic foundation, you can extend the behavior of your Operator for real-world scenarios: managing external services, complex application lifecycles, or advanced configuration management. Operators natively bring Kubernetes management to anything — from applications to infrastructure. With the Operator SDK, everything you need to rapidly scaffold, build, deploy, and test your custom controller logic is right at your fingertips. Experiment with iteration, adapt — and then let automation take over in an operator-driven environment!

By Sai Sandeep Ogety CORE

Monitoring system behavior is essential for ensuring long-term effectiveness. However, managing an end-to-end observability stack can feel like sailing stormy seas — without a clear plan, you risk blowing off course into system complexities. By integrating observability as a first-class citizen within your platform engineering practices, you can simplify this challenge and stay on track in the ever-evolving cloud-native landscape. Entering the world of monitoring distributed systems is a journey made up of several stages which we will cover in the rest of this article. Let's start at the beginning, where organizations attempt to navigate the observability seas and discover the complexities involved. In the Beginning Initially, attempts at a cohesive platform usually start with a basic monitoring strategy that simply tells you when something isn’t working. Over time the system evolves to gather more detailed insights, trying to answer the why of what went wrong. The ultimate goal is to become proactive, collecting enough data to intervene before a problem occurs. Prevention is always better than the cure. Navigating Platform Complexity As the system matures, it allows us to make our applications more resilient, but it also becomes more complex. We can break down this complexity into three main areas. The first area is adding more tools to the stack, increasing the difficulty of managing them. This struggle is well known by platform engineering teams and a constant pain for the developer teams trying to keep up with this escalating volume of tools. The second is the volume of telemetry data, growing exponentially so that it's easy to find ourselves struggling to stay afloat. This problem is well documented in how it's not readily apparent in our monolithic application architectures but quickly raises its head in a cloud-native application architecture. Lastly are the people, how they interact with monitoring tools where the challenge lies in ensuring the system delivers relevant information without overwhelming. As almost everyone in the organization has some level of interest in the insights provided by monitoring systems, we'll have to make sure we are tailoring uncovered insights to these users' specific needs. An IDP Observability Journey Using an Internal Developer Platform (IDP) as a guide during the journey into observability helps address the above challenges while mitigating issues along the way. An IDP enables the creation of clearly charted routes for developers — whether in the form of templates, containers, or APIs — that simplify the management complexity of observability tools. For example, there can be clearly defined configurations for certain tools ensuring they work seamlessly for every developer. For a developer using the platform, it shouldn't matter which monitoring tool is being used as their primary focus is building applications and services. Everything else is abstracted away through the charted routes provided by the IDP. Should at any time in the future the monitoring tools change, the goal is a transparent transition from the developer's perspective. Centrally managing data on the platform allows for efficient organization and simplifies the visualization of connections between data from various components of a distributed architecture. This enables a paradigm shift, moving from passively collecting monitoring data in the hope that it may one day prove useful, to a more purpose-driven approach. Analyzing data flows that govern the architectures being monitored, identifies specific data needed for effective insights. This minimizes the collection of unnecessary data while maximizing the actionable insights that can be generated. Lastly, the IDP serves as a crucial center for governance and centralization, especially when it comes to data visualization. It allows for the configuration of a single location where observability data can be accessed, eliminating the friction that arises when having to switch between different tools. This unified approach streamlines the user experience and makes it easier to access and act on valuable insights. Finding Tranquility How great would it be to work in an organization, as a platform engineer or a developer, where teams started projects with observability as a top priority? They would dedicate time and resources to creating a comprehensive telemetry strategy from the outset.They would prioritize observability just as they would prioritize testing, continuous integration, and continuous deployment from day one. The logical starting point to achieve this is to focus on open standards and open protocols for your observability solutions. Using Cloud Native Computing Foundation (CNCF) projects to explore your options ensures that your eventual architecture is using standard components. Prometheus is a well-known monitoring system and time series database that powers your metrics and alerts with the leading open-source monitoring solution. OpenTelemetry provides high-quality, ubiquitous, and portable telemetry to enable effective observability. Fluent Bit provides you with an end-to-end observability pipeline, with a super fast, lightweight, and highly scalable logging, metrics, and traces processor and forwarder. Perses is the new kid on the block, providing an open specification for dashboards focused on Prometheus and other data sources. This hands-on, free, self-paced observability workshop collection takes you through all of the above tooling. Start leveraging the synergies between observability and platform engineering today, helping your developers create better cloud-native applications while simultaneously enhancing their experience working on your platform.

By Eric D. Schabell CORE

Kubernetes has become the de facto standard for container orchestration, offering scalability, resilience, and ease of deployment. However, managing Kubernetes environments is not without challenges. One common issue faced by administrators and developers is pod crashes. In this article, we will explore the reasons behind pod crashes and outline effective strategies to diagnose and resolve these issues. Common Causes of Kubernetes Pod Crashes 1. Out-of-Memory (OOM) Errors Cause Insufficient memory allocation in resource limits. Containers often consume more memory than initially estimated, leading to termination. Symptoms Pods are evicted, restarted, or terminated with an OOMKilled error. Memory leaks or inefficient memory usage patterns often exacerbate the problem. Logs Example Shell State: Terminated Reason: OOMKilled Exit Code: 137 Solution Analyze memory usage using metrics-server or Prometheus.Increase memory limits in the pod configuration.Optimize code or container processes to reduce memory consumption.Implement monitoring alerts to detect high memory utilization early. Code Example for Resource Limits Shell resources: requests: memory: "128Mi" cpu: "500m" limits: memory: "256Mi" cpu: "1" 2. Readiness and Liveness Probe Failures Cause Probes fail due to improper configuration, delayed application startup, or runtime failures in application health checks. Symptoms Pods enter CrashLoopBackOff state or fail health checks. Applications might be unable to respond to requests within defined probe time limits. Logs Example Shell Liveness probe failed: HTTP probe failed with status code: 500 Solution Review probe configurations in deployment YAML.Test endpoint responses manually to verify health status.Increase probe timeout and failure thresholds.Use startup probes for applications with long initialization times. Code Example for Probes Shell livenessProbe: httpGet: path: /healthz port: 8080 initialDelaySeconds: 3 periodSeconds: 10 readinessProbe: httpGet: path: /ready port: 8080 initialDelaySeconds: 5 periodSeconds: 10 3. Image Pull Errors Cause Incorrect image name, tag, or registry authentication issues. Network connectivity problems may also contribute. Symptoms Pods fail to start and remain in the ErrImagePull or ImagePullBackOff state. Failures often occur due to missing or inaccessible images. Logs Example Shell Failed to pull image "myrepo/myimage:latest": Error response from daemon: manifest not found Solution Verify the image name and tag in the deployment file.Ensure Docker registry credentials are properly configured using secrets.Confirm image availability in the specified repository.Pre-pull critical images to nodes to avoid network dependency issues. Code Example for Image Pull Secrets Shell imagePullSecrets: - name: myregistrykey 4. CrashLoopBackOff Errors Cause Application crashes due to bugs, missing dependencies, or misconfiguration in environment variables and secrets. Symptoms Repeated restarts and logs showing application errors. These often point to unhandled exceptions or missing runtime configurations. Logs Example Shell Error: Cannot find module 'express' Solution Inspect logs using kubectl logs <pod-name>.Check application configurations and dependencies.Test locally to identify code or environment-specific issues.Implement better exception handling and failover mechanisms. Code Example for Environment Variables Shell env: - name: NODE_ENV value: production - name: PORT value: "8080" 5. Node Resource Exhaustion Cause Nodes running out of CPU, memory, or disk space due to high workloads or improper resource allocation. Symptoms Pods are evicted or stuck in pending status. Resource exhaustion impacts overall cluster performance and stability. Logs Example Shell 0/3 nodes are available: insufficient memory. Solution Monitor node metrics using tools like Grafana or Metrics Server.Add more nodes to the cluster or reschedule pods using resource requests and limits.Use cluster autoscalers to dynamically adjust capacity based on demand.Implement quotas and resource limits to prevent overconsumption. Effective Troubleshooting Strategies Analyze Logs and Events Use kubectl logs <pod-name> and kubectl describe pod <pod-name> to investigate issues. Inspect Pod and Node Metrics Integrate monitoring tools like Prometheus, Grafana, or Datadog. Test Pod Configurations Locally Validate YAML configurations with kubectl apply --dry-run=client. Debug Containers Use ephemeral containers or kubectl exec -it <pod-name> -- /bin/sh to run interactive debugging sessions. Simulate Failures in Staging Use tools like Chaos Mesh or LitmusChaos to simulate and analyze crashes in non-production environments. Conclusion Pod crashes in Kubernetes are common but manageable with the right diagnostic tools and strategies. By understanding the root causes and implementing the solutions outlined above, teams can maintain high availability and minimize downtime. Regular monitoring, testing, and refining configurations are key to avoiding these issues in the future.

2025 is knocking on the door, and software development is changing at a rapid pace due to advanced technologies. Tech advancements like AI have transformed how developers create, deploy, and scale software. To stay ahead of the curve, developers need to stay on top of the latest software development trends. In this blog post, I am going to shed light on software development trends you need to watch in 2025. Software Development Trends to Look Out For AI-Powered Development Artificial intelligence (AI) is not just a trendy term but a vital component of software development these days. By increasing productivity, automating tedious processes, and boosting code quality, AI-powered solutions are revolutionizing the way developers work. We can anticipate that AI will become much more important in software development by 2025. With AI-driven code generation, debugging, and testing, developers will have more time to concentrate on more complex projects and creative endeavors. Low-Code and No-Code Platforms In recent years, low-code and no-code platforms have been increasingly popular, and in 2025, this trend is expected to continue. These platforms democratize software development by allowing consumers to create applications with little to no coding experience. Companies can cut development time and expenses by using low-code and no-code solutions to rapidly build and deploy applications. This trend will encourage creativity and teamwork by enabling non-developers to participate in software initiatives. Cloud Development These days, it is standard practice to design software applications that are cloud-native. Even more cloud-native technology usage is anticipated by 2025. Containerization, microservices architecture, and serverless computing will remain the mainstays of software development. These technologies are perfect for developing and implementing cloud applications because they provide scalability, flexibility, and cost-effectiveness. To manage and orchestrate their cloud-native apps, developers will depend increasingly on platforms like Kubernetes. Integration of DevSecOps Security will become the main focus of software development processes in 2025. Integrating security procedures into the DevOps pipeline, or DevSecOps, will become commonplace. By using a "secure by design" methodology, developers will make sure that security is incorporated into each phase of the development process. Real-time threat identification and mitigation will be greatly helped by AI-powered security solutions, which will improve software applications' overall security posture. Sustainability in Software Development Sustainability is going to be a major factor in software development as the world grows more environmentally concerned. Organizations and developers will concentrate on writing code that uses less energy and lessens the impact of software on the environment. Tools that assist in tracking and lowering carbon footprints will become more popular, and cloud providers dedicated to renewable energy will be given preference. In addition to helping the environment, green software development techniques will improve companies' reputations. Remote Work and Collaboration Tools Remote employment has been more popular since the COVID-19 epidemic, and this tendency is only going to continue. Many software development teams will operate remotely by 2025. Platforms and technologies for collaboration will keep developing, facilitating smooth communication and workflow management among remote team members. Technologies like virtual reality (VR) and augmented reality (AR) will improve remote communication by adding an immersive and interactive element. Cross-Functional Engineering Teams The lines separating the security, operations, and development teams are becoming less distinct. Cross-functional engineering teams that work together harmoniously to produce high-caliber software will become more prevalent by 2025. To increase productivity and streamline development processes, these teams will make use of DevOps techniques and agile approaches. Faster time-to-market and more creative solutions will result from the integration of varied talent sets. AI-Powered Customization One of the main factors influencing customer satisfaction and engagement nowadays is personalization. AI-powered personalization will become the main focus of software development in 2025. To provide individualized experiences, AI systems will examine user behavior and preferences. AI will allow developers to design software that caters to each user's specific needs, from personalized recommendations to adaptable user interfaces. This tendency will boost customer satisfaction and propel company expansion. Computing at the Edge By processing data closer to the source, edge computing is becoming more popular as a means of lowering latency and enhancing performance. The use of edge computing in software development will grow in 2025. Edge computing will be useful for applications that need real-time processing, such as Internet of Things devices and driverless cars. Edge computing will be used by developers to create applications that operate more quickly and consistently. Development Based on APIs Application programming interfaces, or APIs, are now the foundation of contemporary software programs. API-first development will become commonplace by 2025. Prior to developing the program itself, developers will design and construct APIs, guaranteeing that the application is scalable, modular, and simple to interface with other systems. Faster development cycles and easier cooperation between various teams and organizations are two benefits of API-first development. Responsible Development and Ethical AI Ethical issues will become increasingly important in software development as AI grows more widespread. By 2025, developers will give ethical AI practices top priority, guaranteeing that AI systems are impartial, equitable, and transparent. Establishing trust with stakeholders and users will need the implementation of responsible development techniques. Organizations will set up frameworks and rules to ensure that AI applications are in line with society's values and regulate the ethical use of AI. Continuous Integration and Continuous Deployment (CI/CD) CI/CD procedures are now necessary to produce software quickly and with good quality. CI/CD pipelines will be increasingly advanced and automated by 2025. The CI/CD process will be optimized using AI-powered tools that can spot bottlenecks and provide fixes. Ongoing testing and monitoring will lower the possibility of errors and increase overall quality. Design With Humans in Mind In software development, user experience (UX) has always been important, and in 2025, its significance will increase. Software applications will be developed according to human-centered design principles, guaranteeing its usability, accessibility, and intuitiveness. To produce software that satisfies users' requirements and expectations, developers will carry out in-depth user research and usability testing. Conclusion The software development industry remains ever-changing, and some trends and new developments are sure to be expected in 2025. From AI-driven development to low-code platforms, cloud-native, and ethical AI, opportunities continue to exist for developers to create meaningful software. It is also important for developers to be aware of such trends and implement them in their work and, with the help of new technologies, to become industry leaders.

In today’s digital era, cybersecurity is a cornerstone of maintaining trust and reliability in cloud operations. A managed threat detection service by AWS, like Amazon GuardDuty, can help secure your environment by analyzing activity and identifying potential risks. This hands-on guide will help you enable Amazon GuardDuty on your AWS account and begin monitoring your resources for security threats. Amazon GuardDuty is a threat detection service that uses machine learning, anomaly detection, and integrated threat intelligence to protect your AWS environment. It continuously monitors for malicious activity, unauthorized access, and security vulnerabilities by analyzing data sources like AWS CloudTrail logs, VPC Flow Logs, and DNS logs. Benefits of GuardDuty Automated threat detection: GuardDuty identifies suspicious behavior in real time, such as unusual API calls, unauthorized access attempts, and data exfiltration activities.Ease of use: There’s no need to deploy or manage additional security infrastructure — GuardDuty is fully managed by AWS.Cost-effective: You only pay for what you use, making it an affordable solution for proactive threat detection.Seamless integration: GuardDuty integrates with other AWS security tools such as AWS Security Hub, Amazon CloudWatch, and Amazon SNS for notifications. How to Enable Amazon GuardDuty Follow these steps to enable GuardDuty on your AWS account: Step 1: Prepare Your AWS Account Before you begin, ensure that: You have an active AWS account.Your IAM user or role has the necessary permissions. Assign the AmazonGuardDutyFullAccess policy to the user or role to enable and manage GuardDuty. Step 2: Access GuardDuty in the AWS Console Sign in to the AWS Management Console.Navigate to the GuardDuty service under the Security, Identity, and Compliance section. Step 3: Enable the Service On the GuardDuty dashboard, click Get Started or Enable GuardDuty.Review the terms of use and configurations.Confirm the setup by clicking Enable. Once GuardDuty is activated, it will begin analyzing data from various sources like CloudTrail logs, VPC Flow Logs, and DNS queries to detect anomalies. Note: You can choose one of the options below to enable Guard Duty: Try threat detection with GuardDutyGuardDuty Malware Protection for S3 only Step 4: Configure Multi-Account Support (Optional) If you manage multiple AWS accounts, consider enabling multi-account support. Use AWS Organizations to designate a GuardDuty administrator account that can manage the service across all linked accounts. Step 5: Monitor and Respond to Findings After enabling GuardDuty, its findings will populate the dashboard. GuardDuty classifies findings by severity — low, medium, or high — allowing you to prioritize actions. Integrate GuardDuty with: AWS Security Hub: For centralized security management.Amazon CloudWatch: To set up alarms and trigger workflows.Amazon SNS: For email or SMS notifications about threats. Best Practices for Using GuardDuty Enable logging: Ensure that CloudTrail logs and VPC Flow Logs are active for comprehensive monitoring.Integrate with automation: Use AWS Lambda to automate responses to high-severity findings.Review regularly: Periodically review findings and update security policies based on GuardDuty insights. Conclusion Amazon GuardDuty is a helpful tool for improving the security of your AWS environment. Enabling this service will help you stay proactive in detecting and responding to potential threats. Its ease of use and robust threat detection capabilities make it a valuable option for organizations using AWS. Author's Note: Take the first step today by enabling GuardDuty on your AWS account to protect your cloud environment against modern security challenges.

By Sai Sandeep Ogety CORE

With organizations shifting at a rapid pace to the cloud, securing the infrastructure is of paramount importance in their list of priorities. Even though AWS provides a varied set of tools and services related to security and compliance. There are various other factors beyond security. Security is not just about tools but about strategy, vigilance, continuous improvement, and conformity to the industry compliance standards for secure environments, including GDPR, HIPAA, and PCI DSS. In this article we will discuss AWS security components with best practices based on a deep-down analysis. AWS Security Components AWS has a rich set of security tools for strengthening cloud environments. At the core of AWS security is a shared responsibility model, which clearly defines responsibilities between customers and AWS. AWS provides cloud infrastructure security while customers handle data and configurations. This demarcation constitutes the core of AWS security practices with some of the key security components including: AWS Identity and Access Management (IAM) IAM manages access to the AWS resources with fine-grained permissions. Least privileges are recommended to decrease security risks. AWS Security Hub AWS Security Hub provides an aggregated view of compliance and security posture, creating findings from services such as AWS Config, GuardDuty, and Inspector. AWS Key Management Service (KMS) AWS KMS manages the encryption keys, assuring in-transit safe data storage. Amazon GuardDuty AWS GuardDuty provides a threat detection service leveraging machine learning to scan logs for potential threats. AWS Config This service continuously monitors and evaluates configurations of AWS resources against specified compliance standards. AWS Security Workflow A typical flow for AWS security components begins with logging and auditing through CloudTrail and CloudWatch Logs. Events that trigger alerts are sent to AWS Security Hub, where actionable insights are derived. Threats identified by GuardDuty could trigger automation workflows through AWS Lambda that could result in isolating compromised resources or triggering the response team notifications. While these components work in tandem, an organization's strategy and practices deployed will have a great impact on deployment. AWS Security Analysis and Best Practices While carrying out our analysis, including AWS whitepapers, customer case studies, and security incidents, some trends appear that are common pitfalls and best practices that can be put into action. Vulnerabilities in "Lift and Shift" Strategies Most organizations assume that their on-premise security strategies only apply to the cloud. Statistics point out that this assumption leads to misconfigurations, which is the leading cause of security incidents in AWS. For example, improper S3 bucket configuration is given as the reason for some high-profile data breaches. (Source: Gartner). Best Practices Manage isolation between AWS and other cloud environments (if applicable). AWS Config can be leveraged to enforce compliance checks on S3 bucket policies and other resources. Prioritize Identity and Access Management According to a Verizon Data Breach Investigations Report, more than 70% of breaches stem from mismanaged credentials. Furthermore, many organizations seemingly grant IAM roles with access that is too broad simply because it's hard to configure strict IAM roles. Best Practices Use the principle of least privilege for IAM roles and users. Ensure IAM Access Analyzer has identified excessive permissions.For privileged accounts, enforce MFA. Leverage Infrastructure as Code Manual configurations can be a source of drift and offer many opportunities for human error to occur. AWS CloudFormation can be used to define sets of secure templates for infrastructure deployment. Best Practices Security baselines can be defined within IaC templates and then injected into the CI/CD pipeline. Use AWS CodePipeline to enforce code reviews and security checks on deployment. Implement Threat Detection Mechanisms Many organizations underutilize threat detection mechanisms, whether due to the difficulty or expense. In some cases, enabling Amazon GuardDuty and AWS Macie has been shown to greatly improve response times (Source: AWS Security Blog). Best Practices Enable GuardDuty and tune it to alert the security team in a timely manner.Regularly run threat simulation exercises to test their response. Data Encryption and Monitoring AWS Docs highlighted that data encryption is seen as an approach that is "set it and forget it," which causes old or badly managed encryption keys. Organizations using continuous monitoring with CloudTrail with the help of regular penetration have a higher chance of pre-vulnerability detection. The approach aligns with the 2024 Verizon Data Breach Investigations Report (DBIR), findings that highlight monitoring importance and management. Best Practices Using AWS KMS for all encryption with automatic key rotation policies Continuously monitor account activity using Conclusion AWS CloudTrail. The security of the AWS environment is not about putting every component in place; rather, it's about being strategic about reaching your organizational goals and compliance needs. AWS offers many services for a successful, well-informed implementation along with active management. However, our analysis highlights that organizations perceiving cloud security as a journey rather than an event perform better against emerging threats. Organizations using AWS components productively, practicing best practices, and constantly striving for improvement can successfully strengthen the security and compliance of their AWS environments.

In today's microservices and event-driven architecture, Apache Kafka is the de facto for streaming applications. However, setting up Kafka for local development in conjunction with your Spring Boot application can be tricky, especially when configuring it to run locally. Spring Boot application provides support for Kafka integration through the spring-kafka maven package. To work with spring-kafka, we need to connect to the Kafka instance. Typically, during development, we would just run a local Kafka instance and build against it. But with Docker Desktop and containers, things are much easier to set up than running a local Kafka instance. This article guides us through the steps for setting up the local Kafka container with the Spring Boot application. Prerequisites We need to set up Docker Desktop. To do so, we can refer to this article. Spring Boot application with spring-kafka package configured. Running Kafka Container For running the Kafka container, we will first use the following docker-compose file: YAML version: '3' services: zookeeper: image: confluentinc/cp-zookeeper:latest environment: ZOOKEEPER_CLIENT_PORT: 2181 ports: - "2181:2181" kafka: image: confluentinc/cp-kafka:latest environment: KAFKA_ZOOKEEPER_CONNECT: zookeeper:2181 KAFKA_ADVERTISED_LISTENERS: PLAINTEXT://localhost:9092 KAFKA_OFFSETS_TOPIC_REPLICATION_FACTOR: 1 ports: - "9092:9092" depends_on: - zookeeper This docker-compose file contains the configurations to pull the Kafka container and its dependency, the Zookeeper container. Zookeeper manages Kafka broker nodes in the cluster; we can find further details about this in this article. For registering the containers with Docker Desktop, we will use the following command: PowerShell docker-compose up -d This will pull the required images and launch the containers, and once the containers are launched, you can see the containers in Docker Desktop like below: Now that the Kafka container is up, we can then create the required topics using Docker Desktop console using the following command: PowerShell kafka-topics --create --topic user-notification --partitions 1 --replication-factor 1 --bootstrap-server localhost:9092 Now that the container is up and the required prerequisites have been performed, we can launch the Spring Boot application. For the Spring Boot application, configure the Kafka bootstrap address as below: Properties files kafka.bootstrapAddress=localhost:9092 When we launch the Spring Boot application, we should see the logs for connection with Kafka, depending on the type of Spring Boot application, whether it is a producer or consumer. Following the steps outlined in the article, we set up a local development environment using a Kafka container and a Spring Boot application.

By Amol Gote CORE

When we are working with a database, optimization is crucial and key in terms of application performance and efficiency. Likewise, in Azure Cosmos DB, optimization is crucial for maximizing efficiency, minimizing costs, and ensuring that your application scales effectively. Below are some of the best practices with coding examples to optimize performance in Azure Cosmos DB. 1. Selection of Right Partition Key Choosing an appropriate partition key is vital for distributed databases like Cosmos DB. A good partition key ensures that data is evenly distributed across partitions, reducing hot spots and improving performance. The selection of a partition key is simple but very important at design time in Azure Cosmos DB. Once we select the partition key, it isn't possible to change it in place. Best Practice Select a partition key with high cardinality (many unique values).Ensure it distributes reads and writes evenly.Keep related data together to minimize cross-partition queries. Example: Creating a Container With an Optimal Partition Key C# var database = await cosmosClient.CreateDatabaseIfNotExistsAsync("YourDatabase"); var containerProperties = new ContainerProperties { Id = "myContainer", PartitionKeyPath = "/customerId" // Partition key selected to ensure balanced distribution }; // Create the container with 400 RU/s provisioned throughput var container = await database.CreateContainerIfNotExistsAsync(containerProperties, throughput: 400); 2. Properly Use Indexing In Azure Cosmos DB, indexes are applied to all properties by default, which can be beneficial but may result in increased storage and RU/s costs. To enhance query performance and minimize expenses, consider customizing the indexing policy. Cosmos DB supports three types of indexes: Range Indexes, Spatial Indexes, and Composite Indexes. Use the proper type of wisely. Best Practice Exclude unnecessary fields from indexing.Use composite indexes for multi-field queries. Example: Custom Indexing Policy C# { "indexingPolicy": { "automatic": true, "indexingMode": "consistent", // Can use 'none' or 'lazy' to reduce write costs "includedPaths": [ { "path": "/orderDate/?", // Only index specific fields like orderDate "indexes": [ { "kind": "Range", "dataType": "Number" } ] } ], "excludedPaths": [ { "path": "/largeDataField/*" // Exclude large fields not used in queries } ] } } Example: Adding a Composite Index for Optimized Querying C# { "indexingPolicy": { "compositeIndexes": [ [ { "path": "/lastName", "order": "ascending" }, { "path": "/firstName", "order": "ascending" } ] ] } } You can read more about Indexing types here. 3. Optimize Queries Efficient querying is crucial for minimizing request units (RU/s) and improving performance in Azure Cosmos DB. The RU/s cost depends on the query's complexity and size. Utilizing bulk executors can further reduce costs by decreasing the RUs consumed per operation. This optimization helps manage RU usage effectively and lowers your overall Cosmos DB expenses. Best Practice Use SELECT queries in limited amounts, retrieve only necessary properties.Avoid cross-partition queries by providing the partition key in your query.Use filters on indexed fields to reduce query costs. Example: Fetch Customer Record C# var query = new QueryDefinition("SELECT c.firstName, c.lastName FROM Customers c WHERE c.customerId = @customerId") .WithParameter("@customerId", "12345"); var iterator = container.GetItemQueryIterator<Customer>(query, requestOptions: new QueryRequestOptions { PartitionKey = new PartitionKey("12345") // Provide partition key to avoid cross-partition query }); while (iterator.HasMoreResults) { var response = await iterator.ReadNextAsync(); foreach (var customer in response) { Console.WriteLine($"{customer.firstName} {customer.lastName}"); } } 4. Consistency Levels Tuning The consistency levels define specific operational modes designed to meet speed-related guarantees. There are five consistency levels (Strong, Bounded Staleness, Session, Consistent Prefix, and Eventual) available in Cosmos DB. Each consistency level impacts latency, availability, and throughput. Best Practice Use Session consistency for most scenarios to balance performance and data consistency.Strong consistency guarantees data consistency but increases RU/s and latency. Example: Setting Consistency Level C# var cosmosClient = new CosmosClient( "<account-endpoint>", "<account-key>", new CosmosClientOptions { // Set consistency to "Session" for balanced performance ConsistencyLevel = ConsistencyLevel.Session }); Read more about the consistency level here. 5. Use Provisioned Throughput (RU/s) and Auto-Scale Wisely Provisioning throughput is a key factor in achieving both cost efficiency and optimal performance in Azure Cosmos DB. The service enables you to configure throughput in two ways: Fixed RU/s: A predefined, constant level of Request Units per second (RU/s), suitable for workloads with consistent performance demands.Auto-Scale: A dynamic option that automatically adjusts the throughput based on workload fluctuations, providing scalability while avoiding overprovisioning during periods of low activity. Choosing the appropriate throughput model helps balance performance needs with cost management effectively. Best Practice For predictable workloads, provision throughput manually.Use auto-scale for unpredictable or bursty workloads. Example: Provisioning Throughput With Auto-Scale C# var throughputProperties = ThroughputProperties.CreateAutoscaleThroughput(maxThroughput: 4000); // Autoscale up to 4000 RU/s var container = await database.CreateContainerIfNotExistsAsync(new ContainerProperties { Id = "autoscaleContainer", PartitionKeyPath = "/userId" }, throughputProperties); Example: Manually Setting Fixed RU/s for Stable Workloads C# var container = await database.CreateContainerIfNotExistsAsync(new ContainerProperties { Id = "manualThroughputContainer", PartitionKeyPath = "/departmentId" }, throughput: 1000); // Fixed 1000 RU/s 6. Leverage Change Feed for Efficient Real-Time Processing The change feed allows for real-time, event-driven processing by automatically capturing changes in the database, eliminating the need for polling. This reduces query overhead and enhances efficiency. Best Practice Use change feed for scenarios where real-time data changes need to be processed (e.g., real-time analytics, notifications, alerts). Example: Reading From the Change Feed C# var iterator = container.GetChangeFeedIterator<YourDataModel>( ChangeFeedStartFrom.Beginning(), ChangeFeedMode.Incremental); while (iterator.HasMoreResults) { var changes = await iterator.ReadNextAsync(); foreach (var change in changes) { Console.WriteLine($"Detected change: {change.Id}"); // Process the change (e.g., trigger event, update cache) } } 7. Utilization of Time-to-Live (TTL) for Automatic Data Expiration If you have data that is only relevant for a limited time, such as logs or session data, enabling Time-to-Live (TTL) in Azure Cosmos DB can help manage storage costs. TTL automatically deletes expired data after the specified retention period, eliminating the need for manual data cleanup. This approach not only reduces the amount of stored data but also ensures that your database is optimized for cost-efficiency by removing obsolete or unnecessary information. Best Practice Set TTL for containers where data should expire automatically to reduce storage costs. Example: Setting Time-to-Live (TTL) for Expiring Data C# { "id": "sessionDataContainer", "partitionKey": { "paths": ["/sessionId"] }, "defaultTtl": 3600 // 1 hour (3600 seconds) } In Cosmos DB, the maximum Time-to-Live (TTL) value that can be set is 365 days (1 year). This means that data can be automatically deleted after it expires within a year of creation or last modification, depending on how you configure TTL. 8. Avoid Cross-Partition Queries Cross-partition queries can significantly increase RU/s and latency. To avoid this: Best Practice Always include partition key in your queries.Design your partition strategy to minimize cross-partition access. Example: Querying With Partition Key to Avoid Cross-Partition Query C# var query = new QueryDefinition("SELECT * FROM Orders o WHERE o.customerId = @customerId") .WithParameter("@customerId", "12345"); var resultSetIterator = container.GetItemQueryIterator<Order>(query, requestOptions: new QueryRequestOptions { PartitionKey = new PartitionKey("12345") }); while (resultSetIterator.HasMoreResults) { var response = await resultSetIterator.ReadNextAsync(); foreach (var order in response) { Console.WriteLine($"Order ID: {order.Id}"); } } Conclusion These tips are very effective during development. By implementing an effective partitioning strategy, customizing indexing policies, optimizing queries, adjusting consistency levels, and selecting the appropriate throughput provisioning models, you can greatly improve the performance and efficiency of your Azure Cosmos DB deployment. These optimizations not only enhance scalability but also help in managing costs while providing a high-performance database experience.

Automation testing is a must for almost every software development team. But when the automation suite consists of many scenarios, the running time of automation suites tends to increase a lot, and sometimes, rather than helping a team to reduce the turnaround time of testing, it doesn’t help in a much-expected way. Thus, there is a need for parallelization of the automation suite. With parallelization comes another difficult thing. Running the automation suite parallelly is not much cheaper. It requires a bigger infrastructure to run the suite. With all these things, we still have one solution that comes to mind: to reduce the cost and the running time of the automation suite, i.e., utilizing the docker technology, which will act as a different architecture but comes with a much cheaper or almost no cost. So, in today’s article, we will discuss how to achieve our goal of reducing the total turnaround time of the testing team with the help of automation testing utilizing technologies like Docker and Cucumber. Why Cucumber? There are a lot of automation frameworks available in the market today to be chosen, but in all of those, Cucumber stands out as one of the best. It allows automation tests to be written from a business-oriented perspective, concealing complex coding logic and presenting the tests as human-readable sentences. This approach ensures that even individuals without automation development expertise can easily understand the tests and grasp the expected outcomes of these tests. Combining Docker and Cucumber Docker is a containerization technology that offers a closed environment for applications to operate. Among its many benefits, reliability stands out as a key advantage. By functioning as an isolated environment, Docker ensures that the application can access all the necessary artifacts within the closed environment, making the application more efficient and reliable. In automation suites, very often we see the flaky execution of the automation scripts. With Docker, the automation scripts run in a closed environment that helps to provide consistency and reliability to the automation run and helps the testing team with consistent automation runs. The combination of Docker and Cucumber makes a good automation suite, both from the reliability and ease of understanding point of view. On top of that, Docker allows us to run the automation suite in parallel to reduce the automation suite running time. Here are some of the benefits of using Docker and Cucumber together: Docker offers parallel execution of its containers, allowing the automation suite to run concurrently, thereby reducing its total execution time.Cucumber facilitates the use of a human-readable language, thereby enhancing the clarity and comprehension of test scenario workflow.Docker offers scalability and flexibility, enabling the developers to efficiently manage extensive automation suites. Docker and Cucumber streamline the long-term maintenance of automation suites, allowing for seamless updates to dependencies and scenarios. The Architecture of the Cucumber and Docker-Based Automation Framework In this article, we will use the WDIO framework as the base automation framework, with the entire suite’s architecture built around it. To facilitate parallel execution in our automation suite, a Selenium Grid-like architecture can easily be developed using Docker. Here are some of the key aspects of the automation suite architecture: 1. Docker Selenium Grid Architecture The Docker Selenium Grid architecture can easily be formed utilizing the Docker images provided by Selenium. We can use the official Selenium Grid Hub and the browser node’s docker images to form the Selenium Grid Architecture. 2. Docker Image of Automation Suite To utilize the efficiency and reliability of docker technology in our automation suite, an image of our automation suite code can be created. This docker image of our automation code can be created by creating a Docker file that holds the information about the code and a base Node.js image, on top of which the automation suite image will be built. 3. Docker Compose File Docker-compose file is one of the best features available to handle the containerization architecture. The Docker compose file is responsible for all the internal networking and the required ports, environment variables, and volume mounting. This file can be used to scale up or down the required containers of any specific service, i.e., this file will be responsible for orchestrating the actual Selenium Grid architecture and allowing us to run the multiple instances of our automation code to connect with the different browser nodes available, just like a real Selenium Grid architecture. How to Create a Docker Image of the Automation Suite A docker image is nothing but a YAML file template that tells the machine a set of instructions. A docker image contains multiple steps to form a bundle of the whole code that fulfills a specific task. So, creating a docker image of an automation suite is not a tedious task. All the docker images require a base image on top of which the whole image would be built. In our use case, we will be using a Node.js alpine image as a base image. The alpine images are a lightweight form of an actual image that reduces the image size and makes the image build and run process very fast and memory efficient. Here’s a sample of the automation codes docker image: Plain Text FROM node:20-alpine # Install Python 3 and update PATH RUN apk add --no-cache python3 # Set the Python 3 binary as the default python binary RUN ln -s /usr/bin/python3 /usr/local/bin/python # Add Python 3 binary location to the PATH environment variable ENV PATH="/usr/local/bin:${PATH}" # Install build tools RUN apk add --no-cache make g++ WORKDIR /cucmber-salad ADD . /cucmber-salad # Install all the required libraries using npm install RUN apk add openjdk8 curl jq && npm install # Use the Feature Name as Environment Variable ENV FEATURE=**/*.feature ENV ENVIRONMENT=staging ENV TAG=@Regression ENV CHROME_VERSION=109.0.5414.74 ENV HOST=***.***.**.*** Docker-Compose File Setup The docker-compose file is the main configuration file. It represents the overall architecture of the setup and helps organize the whole suite. A traditional docker-compose file consists of different services that connect and work together to form a network. In our case, the Selenium Hub, Browser Nodes, and the automation codes image reside in the docker-compose file. These images are responsible for constructing the Selenium Grid architecture and running the automation suite in parallel. A sample of the docker-compose file: Plain Text version: "3" services: hub1: image: seleniarm/hub:latest ports: - "4442:4442" - "4443:4443" - "5554:4444" chrome1: image: seleniarm/node-chromium:latest shm_size: '1gb' depends_on: - hub1 environment: - SE_EVENT_BUS_HOST=hub1 - SE_EVENT_BUS_PUBLISH_PORT=4442 - SE_EVENT_BUS_SUBSCRIBE_PORT=4443 - HUB_HOST=hub1 - SE_NODE_MAX_SESSIONS=2 - VNC_NO_PASSWORD=1 With this docker-compose file, we can configure the Selenium grid architecture in one simple command : Plain Text docker-compose up-d --scale chrome1=2 --scale chrome2=2 hub1 chrome1 hub2 chrome2 This command runs the two hubs and chrome nodes, and these chrome nodes can accommodate one automation image for each. The Scale flag enables multiple instances of a docker-compose service. Conclusion By leveraging Docker, Cucumber significantly reduces the execution time of the automation suite, thereby reducing the overall turnaround time during the testing phase of the software development cycle. With this setup, our automation suite running instances and Grid architecture looks like this: