Complexity rules the day within the world of data systems and pipelines. A goal for any observability practice is to help reduce complexity and give users and administrators a clear view of what’s happening in any system. This is the path to unified observability, a mature system where monitoring and troubleshooting are streamlined. This has been difficult to achieve for many organizations.

Recently I've had the great privilege of working on creating a distributed WordPress deployment that leverages GCP compute and services alongside containers running on the Cycle platform. This blog dives into a bit of the history of why WordPress is difficult to deploy in a distributed way, how we approached it, some really interesting things we found, and finally, the solution we put in place.

At Qovery, we are closely following the development of EKS Auto Mode, a new feature from AWS designed to simplify Kubernetes management by automating various foundational components. While we recognize the effort AWS has put into this, our initial evaluation shows that EKS Auto Mode is still in its early stages and does not yet offer sufficient value to be a strong consideration for our users.

For scaling businesses, transitioning from PaaS (Platform as a Service) to IaaS (Infrastructure as a Service) is less about a choice and more about necessity. Staying on PaaS too long can result in skyrocketing costs, limited flexibility, and performance bottlenecks — challenges that only grow as your workloads and team scale.

Autonomic IT is the pinnacle of IT evolution. Inspired by the human autonomic nervous system, it refers to self-managing IT systems that autonomously monitor, optimize, and resolve issues. By integrating data, advanced AI and machine learning (ML), and automation, Autonomic IT enterprises can predict, prevent, and resolve IT issues more proactively, enhancing efficiency and reliability. However, Autonomic IT is more than just a framework for machines to fix themselves.

Picture this: A chic Barcelona seaside hotel, gusty autumn winds, endless tapas, and the Rioja flowing. Could there be a better setting for a FinOps conversation? That was the setting for FinOpsX Europe! It brought together 500 practitioners from EMEA, APAC, and even LATAM. Everyone was in the mood to learn and interact: exchange ideas, share challenges, and find solutions. Here’s a peek at the hottest discussion topics.

Microservices architectures empower individual teams to choose their own programming language, tools, and technologies, resulting in more independence and the ability to develop and release features faster. While there are various types of integration patterns that can facilitate microservice communication, many organizations choose to adopt event-driven architectures (EDAs) because of their scalability, agility, and resilience.

Today, every enterprise is digital. Regardless of industry, every business must incorporate digital technologies and strategies into its operations to remain competitive. Maintaining reliable IT infrastructures and digital services while minimizing downtime due to unplanned outages is critical to business success.

In this blog series, we will explore the importance of merging DevOps best practices with MLOps to bridge this gap, enhance an enterprise’s competitive edge, and improve decision-making through data-driven insights. Part one discussed the challenges of separate DevOps and MLOps pipelines and outlined a case for integration.

You may have wrestled with a web application attempting to call an offsite web service, such as an OpenTelemetry Collector, and gotten an odd error with the word CORS in it. Something like: Or, maybe you got a generic thrown error from your fetch statement that states Error: Failed to fetch …and you wondered, “What’s the problem, and how can I fix it?” These kinds of errors are called CORS errors, and they can be a bit confusing.