9 posts tagged with "case study"

Company Background​

Aryon Security is a preventative cloud security platform that enforces security policies at the point of deployment, stopping misconfigurations before they ever reach production rather than flagging them after the fact. Acting as a source-agnostic gatekeeper across AWS, Azure, and GCP, Aryon applies the same protection whether infrastructure is provisioned through IaC, ClickOps, or third-party providers, letting security and platform teams define a policy once and ensure only compliant infrastructure is ever deployed.

Getting Ahead of Migration Struggles​

Omri Tcherner joined Aryon when it was little more than a handful of employees and an idea. He came in having experienced the pain schema migrations can cause from a previous role and made an important decision. "I had very bad experiences with schema migrations, so my goal for us was to do them correctly from day one," Omri said. Rather than let schema management become a pain point once the company scaled, they treated it as something to get right from the very start.

Atlas was one of the first tools Omri researched while setting up Aryon's stack. It was easy to onboard and worked for their planned setup, so Aryon adopted it before it even had a single production workload to migrate. 18 months later, it's still the only tool the company has used for the job. "We never thought about looking elsewhere because it's done exactly what we need it to do since the beginning," Omri said.

Rolling the Kubernetes Operator Out to Five Environments​

While the core tool met all of Aryon's initial needs, their workflow scaled further when they moved from basic Helm charts to a more declarative architecture. "We used Helm charts for deployment in our original setup, but when Atlas’s Kubernetes Operator came out, we were one of the first to jump on the chance to use it," Omri said. The Kubernetes Operator opens the door to managing your database schemas with Atlas from within your Kubernetes cluster. This allows developers to focus on the desired state of their cluster and let Kubernetes handle the complexities of how to get there. As early adopters running a multi-environment setup, Omri and the team worked closely with Atlas, sharing real-world feedback to help catch edge cases in the newly released feature.

Today, that workflow is woven directly into Aryon's engineering pipeline. Day to day, engineers define their schema in their application code, and Atlas generates versioned migration files directly from it. Before any code is merged to dev, Atlas's CI checks catch non-linear migration histories before they can compromise the database.

Once a pull request is approved, the Operator takes over for deployment. Aryon runs a separate instance of the Operator across five distinct environments: dev, staging, an integration testing cluster, and two production regions. The Operator treats database migrations like any other declarative Kubernetes resource, applying them automatically during deployment without a single engineer needing to run anything by hand.

This workflow extends all the way down to local machines. Aryon's backend and research teams spin up local Kubernetes clusters managed by the same Operator setup. For the research team writing Aryon's security policies, that consistency matters: to validate a new policy, they deploy Aryon's full stack locally, let the Operator migrate the database, and test their work against live cloud sandboxes.

The Outcome​

Now, the Kubernetes Operator has become invisible infrastructure for Aryon. Schema changes just ship as part of every deployment, in every environment, without engineers thinking about them.

• A Frictionless Developer Experience. Schema management stays out of the engineers' way entirely. With their internal setup, new engineers run a single command that generates protobufs and Atlas migrations together. "It connects to our models and people don't even have to think about migrations, they just happen," Omri said.
• Consistency Across Teams and Environments. The same migration workflow scales across the whole organization. Two backend teams and a research team all follow the same process, while the Kubernetes Operator applies it uniformly across five environments as well as local development.
• Layered Testing and Guardrails. Atlas's checks run in CI to catch nonlinear migration history before it merges, and Aryon also uses Atlas to run randomized migrations inside its unit tests, adding another layer of confidence before schema changes ship.
• Responsive Support When It Matters. When a CI misconfiguration once pushed a bad migration toward production, Omri worked through the fix directly with the Atlas team over Slack. "Every time we need anyone from the team, they're always available to help," he said.

Looking ahead, Aryon is continuing its track record as an early adopter by serving as one of the frontrunners for Atlas's new ad-hoc data migration feature. "That’s something we’re really looking forward to," says Omri. "It will give us another layer of interaction with the product that will further improve our workflow."

At the same time, Aryon is preparing to expand beyond its lean PostgreSQL setup by adding ClickHouse to its architecture. Atlas’s native support for ClickHouse means the team can seamlessly bring another database engine under the exact same automated Operator workflow without adding operational complexity or breaking stride.

Getting Started​

If you're running Kubernetes across multiple environments and want schema migrations to deploy automatically and safely as part of your existing rollout process, the Atlas Kubernetes Operator can fold database changes into the same pipeline you already use to ship everything else.

If your team is trying to build good migration habits before schema management becomes a bottleneck, or needs one consistent workflow across dev, staging, and multiple production regions, Atlas is the solution for you.

"The biggest win of any tool is when you don't need to look at it ever again and it just works."

– Wai Ho Choy, Infrastructure Lead, Gumloop

Company Background​

Gumloop is a collaborative platform that empowers anyone in a company to build AI agents using their preferred models and integrations, while giving IT enterprise-grade visibility and control. Whether these agents are deployed in Gumloop's secure environment or within your own infrastructure, your data always stays entirely in your systems.

Company Background​

EliseAI transforms complex housing and healthcare systems, helping property managers and healthcare providers handle leasing, maintenance, and resident engagement. By deeply integrating into workflows and automating operations, it cuts costs for all parties. EliseAI powers 1 in 6 rental apartment units in the U.S., processing hundreds of thousands of messages and thousands of voice calls per day.

"Atlas just works behind the scenes. We don't need to pay attention to it – we can trust that it's getting the job done."

– Armon Avrahamy, CTO and Co-Founder, Wenrix

Company Background​

Wenrix is the AI infrastructure for profitable growth in air. Since 2018, leading travel agencies have relied on Wenrix to help them grow revenue, protect margin, and scale more efficiently in an increasingly complex and competitive air retail landscape.

Company Background​

Yad2 is the most popular online marketplace in Israel for buying and selling second-hand items. Since launching in 2005, Yad2 has offered an organized platform for the sale of various goods, including vehicles, housing, rentals, furniture, electronics, and more. With millions of users and listings, Yad2 handles a significant amount of data and requires a robust database management system.

"I rely on Atlas because I know it works and it gets the job done."

– Hicaro Adriano, Principal Software Engineer, Beck's Hybrids

Company Background​

Founded in 1937, Beck's Hybrids appreciates the farmers who have helped them grow to become the largest family-owned retail seed company and third-largest seed brand in the United States. This position gives Beck's access to the best genetics and trait technologies from suppliers worldwide. Beck's strives to provide all customers with the tools, support, and resources they need to succeed.

The Obstacle: Unreliable Migrations​

The Beck's Hybrids IT department began with a few engineers managing mainframes. Over the years, the development team has grown in an effort to provide customers and internal users with various applications that help power all aspects of the business. These systems include "FARMServer®", a precision farming platform that helps farmers make decisions based on optimal planting windows and growth stage modeling.

FARMServer is a complex, Microsoft SQL Server-based application that has grown to include a wide range of features and functionalities. Its codebase heavily utilizes stored procedures, views, and custom types to handle the intricate logic required for precision farming.

Beck's has traditionally developed its technologies in-house, and that includes their schema management system for these applications. Their system was a semi-automatic process that required manually written migrations, which can be quite fragile.

Their process required developers to manually track which revisions had been applied, carefully compare that to the current state in production, and then apply the remaining changes one-by-one - "hoping they wouldn’t fail." With no batch transactions or safety mechanisms in place, even a small mistake often left production in an inconsistent state.

"When I came across Atlas and saw it described as Terraform for your database, it immediately resonated. That’s exactly what we needed. Just like Terraform solved our AWS problems, we needed something to bring that same level of control to our data."

– Maciej Bukczynski, Director of Technology, Darkhorse Emergency

Company Background​

Darkhorse Emergency is a SaaS decision analytics platform for public safety services, primarily fire departments, that uses data and predictive analytics to optimize operations and resource allocation. Their platform allows for decisions to be simulated and assessed before being made, creating more transparency amongst public service teams and those that depend on them.

The Bottleneck: Evolving a Logic-Heavy Postgres Schema​

"For us PostgreSQL isn't just storage. It's the core of our business logic. "

Darkhorse Emergency's platform is built on a complex PostgreSQL database that serves as the backbone for their application. It is an elaborate system that processes many types of data, including 911 calls, census reports, and other public data sources.

By maintaining a carefully designed chain of views, functions, custom types, and triggers, the team is able to offload complex calculations and logic to the database. This ensures that their application can efficiently handle the demands of public safety services. "For us PostgreSQL isn't just storage. It's the core of our business logic," said Maciej Bukczynski, Director of Technology at Darkhorse Emergency.

However, this complexity presents a significant challenge when it comes to evolving the database schema. With so much happening within the database itself, the team very quickly ran into the limitations that come with common migration tools. "For example, we might have a view that feeds into 50 other views; if we want to make a change to that, we need to carefully recreate dependencies and ensure that everything remains consistent", Bukczynski explained.

The team initially tried to use classic migration tools like Flyway and Liquibase, but found that manually planning and applying migrations in such an intricate system was not only time-consuming but error-prone.

Prepared for an Atlas Community Webinar, October 2024

Introduction​

In recent years, the shift to declarative resource management has transformed modern infrastructure practices. Groundbreaking projects like Terraform, for infrastructure as code, and Kubernetes, for container orchestration, have exemplified the power of this approach. By focusing on what the end state should be rather than how to achieve it, declarative methods make systems more scalable, predictable, and easier to maintain—essential qualities for handling today's complex environments.

However, when it comes to managing database schemas, the industry has been slow to adopt declarative workflows. Atlas was created almost four years ago to address this gap.

Atlas supports two kinds of database schema migration workflows:

• Versioned Migrations - each change to the database is described as a migration script, essentially a SQL file containing the SQL commands to apply the change. Migrations are versioned and applied in order.

  Contrary to most existing migration tools, Atlas relies on users defining the desired state of the database schema in code Atlas generates the necessary migration scripts to bring the database to the desired state.

• Declarative Migrations - the database schema is described in a declarative way, and changes are applied by comparing the desired schema with the current schema and generating the necessary SQL commands to bring the database to the desired state.

To date, most teams that used Atlas in production have used it's versioned migration workflow which synthesizes the simplicity and explicitness of classic migration tools with the benefit of automated migration generation.

Recent improvements to Atlas have addressed many of the challenges and concerns teams have expressed around using declarative migrations in production in the past. In this post, we'll take a deep dive into the declarative migration workflow

"Everything on Atlas is just making too much sense for us."
— Kaushik Shanadi, Chief Architect

Conceal, a cybersecurity company, creates a secure browsing experience using a browser extension. With a lean engineering team, When Conceal shifted from serving individual consumers to working with managed service providers (MSPs), their clients' security requirements drove the need for a robust, multi-tenant architecture to ensure data isolation and scalability.

Kaushik Shanadi, VP and Chief Architect, led the charge in finding that solution.