Rutuja Rajwade

7 results

Introducing MongoDB Atlas Service Accounts via OAuth 2.0

Authentication is a crucial aspect of interacting with the MongoDB Atlas Administration API , as it ensures that only authorized users or applications can access and manage resources within a MongoDB Atlas project. While MongoDB Atlas users currently have programmatic API keys (PAKs) as their primary authentication method, we recognize that development teams have varying authentication workflow requirements. To help developer teams meet these requirements, we’re excited to announce that Service Accounts via OAuth 2.0 for MongoDB Atlas is now generally available! MongoDB Atlas Service Accounts offer a more streamlined way of authenticating API requests for applications, enabling your developers to use their preferred authentication workflow. Addressing the challenges of using programmatic access keys At some point in your MongoDB Atlas journey, you have likely created PAKs. These API keys enable MongoDB Atlas project owners to authenticate access for their users. API keys include a public key and a private key. These two parts serve the same function as a username and a password when you make API requests to MongoDB Atlas. Each API key belongs to only one organization, but you can grant API keys access to any number of projects in that organization. PAKs use a method of authentication known as HTTP Digest, which is a challenge-response authentication mechanism that uses a hash function to securely transmit credentials without sending plaintext passwords over the network. MongoDB Atlas hashes the public key and the private key using a unique value called a nonce. The HTTP Digest authentication specifies that the nonce is only valid for a short amount of time. This is to prevent replay attacks so that you can’t cache a nonce and use it forever. It’s also why your API keys are a mix of random symbols, letters, and numbers and why you can only view a private key once. As a result, many teams must manage and rotate PAKs to maintain application access security. However, doing this across multiple applications can be cumbersome, especially for teams operating in complex environments. As a result, we’ve introduced support for an alternate authentication method through Service Accounts via OAuth 2.0, which enables users to take advantage of a more automated authentication method for application development. Using Service Accounts with an OAuth 2.0 client credentials flow OAuth 2.0 is a standard for interapplication authentication that relies on in-flight TLS encryption to secure its communication channels. This prevents unauthorized parties from intercepting or tampering with the data. The MongoDB Atlas Administration API supports in-flight TLS encryption and uses it to enable Service Accounts as an alternative method for authenticating users. MongoDB Atlas Service Accounts provide a form of OAuth 2.0 authentication that enables machine-to-machine communication. This enables applications, rather than users, to authenticate and access MongoDB Atlas resources. Authentication through Service Accounts follows the same access control model as PAKs, with full authentication lifecycle management. Service Accounts use the OAuth 2.0 client credentials flow, with MongoDB Atlas acting as both the identity provider and the authorization server. Like PAKs, Service Accounts are not tied to individual MongoDB Atlas users but are still ingrained with MongoDB Atlas. Figure 1. How it Works - MongoDB Atlas Service Accounts Experiencing benefits through Service Accounts Using Service Accounts to manage programmatic access offers a number of advantages: Automation Service Accounts offer an automated way to manage access. Users don’t need to manually manage authentication mechanisms, like recreating a Service Account to rotate the “client secrets.” Instead, they only need to regenerate the client secrets while keeping the other configuration of the existing Service Account intact. Furthermore, Service Accounts are broadly supported across many platforms, enabling easier integration between different services and tools and facilitating easier connections across applications and infrastructure components, regardless of the underlying technology. Seamless integration with MongoDB Atlas Service Accounts enable developers to manage authentication in the workflow of their choice. Users can manage the Service Account lifecycle at the organization and project levels via the MongoDB Atlas Administration API, the provided client library (currently, the Atlas Go SDK) , and the Atlas UI . They integrate with MongoDB Atlas via the OAuth 2.0 client credential flow, enabling seamless authentication using cloud-native identity systems. Granular access control and role management Service Accounts also have robust security features, providing a standardized and consistent way to manage access. Each organization or project can have its own Service Account, simplifying credential management and access control. Additionally, you can define granular roles for a Service Account to limit its access to only the necessary resources. This reduces the risk of over-permissioning and unauthorized access. Ready to uplevel your user authentication? Learn how to create your first Service Account by visiting our documentation . Not a MongoDB Atlas user yet? Sign up for free today.

April 2, 2025

Reintroducing the Versioned MongoDB Atlas Administration API

Our MongoDB Atlas Administration API has gotten some work done in the last couple of years to become the best “Versioned” of itself. In this blog post, we’ll go over what’s changed and why migrating to the newest version can help you have a seamless experience managing MongoDB Atlas . What does the MongoDB Atlas Administration API do? MongoDB Atlas, MongoDB’s managed developer data platform, contains a range of tools and capabilities that enable developers to build their applications’ data infrastructure with confidence. As application requirements and developer teams grow, MongoDB Atlas users might want to further automate database operation management to scale their application development cycles and enhance the developer experience. The entry point to managing MongoDB Atlas in a more programmatic fashion is the legacy MongoDB Atlas Administration API. This API enables developers to manage their use of MongoDB Atlas at a control plane level. The API and its various endpoints enable developers to interact with different MongoDB Atlas resources—such as clusters, database users, or backups—and lets them perform operational tasks like creating, modifying, and deleting those resources. Additionally, the Atlas Administration API supports the MongoDB Atlas Go SDK , which empowers developers to seamlessly interact with the full range of MongoDB Atlas features and capabilities using the Go programming language. Why should I migrate to the Versioned Atlas Administration API? While it serves the same purpose as the legacy version, the new Versioned Atlas Administration API gives a significantly better overall experience in accessing MongoDB Atlas programmatically. Here’s what you can expect when you move over to the versioned API. A better developer experience The Versioned Atlas Administration API provides a predictable and consistent experience with API changes and gives better visibility into new features and changes via the Atlas Administration API changelog . This means that breaking changes that can impact your code will only be introduced in a new resource version and will not affect the production code running the current, stable version. Also, every time a new version two resource is added, you will be notified of the older version being deprecated, giving you at least one year to upgrade before the removal of the previous resource version. As an added benefit, the Versioned Atlas Administration API supports Service Accounts as a new way to authenticate to MongoDB Atlas using the industry standard OAuth2.0 protocol with the Client Credentials flow. Minimal workflow disruptions With resource-level versioning, the Versioned Atlas Administration API provides specific resource versions, which are represented by dates. When migrating from the legacy, unversioned MongoDB Atlas Administration API (/v1) to the new Versioned Atlas Administration API (/v2), the API will default to resource version 2023-02-01. To simplify the initial migration, this resource version applies uniformly to all API resources (e.g., /backup or /clusters). This helps ensure that migrations do not adversely affect current MongoDB Atlas Administration API–based workloads. In the future, each resource can adopt a new version independently (e.g., /cluster might update to 2026-01-01 while /backup remains on 2023-02-01). This flexibility ensures you only need to act when a resource you use is deprecated. Improved context and visibility Our updated documentation provides detailed guidance on the versioning process. All changes—including the release of new endpoints, the deprecation of resource versions, or nonbreaking updates to #stable resources—are now tracked in a dedicated, automatically updated changelog. Additionally, the API specification offers enhanced visibility and context for all stable and deprecated resource versions, ensuring you can easily access documentation relevant to your specific use case. Why should I migrate to the new Go SDK? In addition to an updated API experience, we’ve introduced version 2 of the MongoDB Atlas Go SDK for the MongoDB Atlas Administration API. This version supports a range of capabilities that streamline your experience when using the Versioned Atlas Administration API: Full endpoint coverage: MongoDB Atlas Go SDK version 2 enables you to access all the features and capabilities that the versioned API offers today with full endpoint coverage so that you can programmatically use MongoDB Atlas in full. Flexibility: When interacting with the new versioned API through the new Go SDK you can choose which version of the MongoDB Administration API you want to work with, giving you control over when breaking changes impact you. Ease of use: The new Go SDK enables you to simplify getting started with the MongoDB Atlas Administration API. You’ll be able to work with fewer lines of code and prebuilt functions, structs, and methods that encapsulate the complexity of HTTP requests, authentication, error handling, versioning, and other low-level details. Immediate access to updates: When using the new Go SDK, you can immediately access any newly released API capabilities. Every time a new version of MongoDB Atlas is released, the SDK will be quickly updated and continuously maintained, ensuring compatibility with any changes in the API and speeding up your development process. How can I experience the enhanced version? To get started using the Versioned Atlas Administration API, you can visit the migration guide , which outlines how you can transition over from the legacy version. To learn more about the MongoDB Atlas Administration API, you can visit our documentation page .

February 12, 2025

Introducing: Multi-Kubernetes Cluster Deployment Support

Resilience and scalability are critical for today's production applications. MongoDB and Kubernetes are both well known for their ability to support those needs to the highest level. TA single Kubernetes cluster is typically limited to a single region, so to better enable developers using MongoDB and Kubernetes, we’ve introduced a series of updates and capabilities that makes it possible to manage MongoDB across multiple Kubernetes clusters. Since those Kubernetes clusters can be located in different regions, this offers new levels of resilience and control over where your data lives. In addition to the previously released support for running MongoDB replica sets and Ops Manager across multiple Kubernetes clusters, we're excited to announce the public preview release of support for Sharded Clusters spanning multiple Kubernetes clusters (GA to follow in November 2024). Support for deployment across multiple Kubernetes clusters is facilitated through the Enterprise Kubernetes Operator. As a recap for anyone unaware, the Enterprise Operator automates the deployment, scaling, and management of MongoDB clusters in Kubernetes. It simplifies database operations by handling tasks such as configuration, resizing, upgrades, and failover, whilst ensuring consistent performance and reliability in the Kubernetes environment. Multi-Kubernetes cluster deployment support enhances availability, resilience, and scalability for critical MongoDB workloads, empowering developers to efficiently manage these workloads within Kubernetes. This approach unlocks the highest level of availability and resilience by allowing shards to be located closer to users and applications, increasing geographical flexibility and reducing latency for globally distributed applications. Deploying replica sets across multiple Kubernetes clusters MongoDB replica sets are engineered to ensure high availability, data redundancy, and automated failover in database deployments. A replica set consists of multiple MongoDB instances—one primary and several secondary nodes—all maintaining the same dataset. The primary node handles all write operations, while the secondary nodes replicate the data and are available to take over as primary if the original primary node fails. This architecture is critical for maintaining continuous data availability, especially in production environments where downtime can be costly. Support for deploying MongoDB replica sets across multiple Kubernetes clusters helps remove the Kubernetes cluster itself as a single point of failure. Deploying MongoDB replica sets across multiple Kubernetes clusters enables you to distribute your data, not only across nodes in the Kubernetes cluster, but across different clusters and geographic locations, ensuring your deployments operational (even if one or more Kubernetes clusters or locations fail) and facilitating faster disaster recovery. To learn more about how to deploy replica sets across multiple Kubernetes clusters using the Enterprise Kubernetes Operator, visit our documentation . Sharding MongoDB across multiple Kubernetes clusters While replica sets duplicate data for resilience (and higher read rates), MongoDB sharded clusters divide the data up between shards, each of which is effectively a replica set, providing resilience for each portion of the data. Crucially, this also helps your database handle large datasets and higher-throughput operations since each shard has a primary member handling write operations to that portion of the data; this allows MongoDB to scale up the write throughput horizontally, rather than requiring vertical scaling of every member of a replica set. In a Kubernetes environment, each shard can now be deployed across multiple Kubernetes clusters, giving every shard higher resilience in the event of a loss of a Kubernetes cluster or an entire geographic location. This also offers the ability to locate shards or their primaries in the same region as the applications or users accessing that portion of the data, reducing latency and improving user experience. Sharding is particularly useful for applications with large datasets and those requiring high availability and resilience as they grow. Support for sharding MongoDB across multiple Kubernetes clusters is currently in public preview and will be generally available in November. Deploying Ops Manager across multiple Kubernetes clusters Ops Manager is the self-hosted management erver that supports automation, monitoring, and backup of MongoDB on your own infrastructure. Ops Manager's most critical function is backup of MongoDB deployments, and deploying it across multiple Kubernetes clusters greatly improves resilience and disaster recovery for your MongoDB deployments in Kubernetes. With Ops Manager distributed across several Kubernetes clusters, you can ensure that backups of deployments remain robust and available, even if one Kubernetes cluster or site fails. Furthermore, it allows Ops Manager to efficiently manage and monitor MongoDB deployments that are themselves distributed across multiple clusters, improving central oversight of your deployments. To learn more about how to deploy Ops Manager across multiple Kubernetes clusters using the Enterprise Kubernetes Operator, visit our documentation . To leverage multi-Kubernetes-cluster support, you can get started with the Enterprise Kubernetes Operator .

October 10, 2024

MongoDB Enterprise Advanced in Google Distributed Cloud Hosted

Today, we’re excited to strengthen our "run anywhere" approach and deepen our relationship with Google Cloud by announcing that MongoDB Enterprise Advanced is now available for use within Google Distributed Cloud Hosted (GDC Hosted). "Google Cloud is happy to welcome MongoDB as a preferred partner for our Google Distributed Cloud Hosted product," said Rohan Grover, Director of Product for GDC Hosted. "MongoDB's powerful document database aligns with our data analytics focus, empowering our shared customers to unlock the full potential of their sensitive data in an air-gapped private cloud." GDC Hosted is Google Cloud’s air-gapped private cloud that does not require connectivity to Google Cloud or the public internet to manage the infrastructure, services, APIs, or tooling. GDC Hosted enables public sector organizations and regulated enterprises to address strict data residency and security requirements, while continuing to deliver innovation to their users. MongoDB Enterprise Advanced combines the power of MongoDB —– the leading NoSQL, document-oriented database that supports a variety of data structures — with an industry-leading offering catering to customers with the most advanced security and data sovereignty needs. As a flexible and scalable solution, MongoDB allows diverse datasets to be stored in dynamic schemas, ensuring easy data manipulation and real-time analytics. Together, GDC Hosted and MongoDB Enterprise Advanced offer a solution that enables users to scale their operations while adhering to the strictest data governance and security standards. The bridge between GDC Hosted and MongoDB Enterprise Advanced is Kubernetes : GDC Hosted is built on Kubernetes allowing teams to self-manage MongoDB through the use of the MongoDB Enterprise Kubernetes Operator. The MongoDB Enterprise Kubernetes Operator is the only officially supported way to run Enterprise Advanced deployments of MongoDB in Kubernetes. To enable customers to manage deployments within their environment of choice (GDC Hosted in this case), the operator works in conjunction with the MongoDB self-hosted Ops Manager, which the operator can also install and manage in Kubernetes. This gives customers the ability to deploy, monitor, back up, and scale MongoDB. The Enterprise Operator drastically simplifies both the setup and day-two operations like upgrades, making it possible to run MongoDB in Kubernetes with far less Kubernetes expertise. Creation and configuration of database deployments can be managed via a Git repo, saving developers from needing the permissions or knowledge needed to work directly with Kubernetes. By leveraging the Enterprise Kubernetes Operator, users can manage their MongoDB deployments with even greater power and scale, and maximize their investment in both MongoDB and Google Cloud. GDC Hosted is built to meet high regulatory, durability, and availability requirements, which aligns with MongoDB Enterprise Advanced’s commitment to giving users the tools and support they need to have complete control over the management and security of their self-managed MongoDB environments. While MongoDB Atlas is the best way to run MongoDB on Google Cloud, MongoDB Enterprise Advanced in GDC Hosted is the best option for teams that need absolute self-managed control over data governance and compliance, while still allowing for scalability. Once you have GDC Hosted up and running, you can get started with MongoDB Enterprise Advanced through the MongoDB Enterprise Advanced listing in the GDC Hosted Marketplace. Alternatively, teams can access MongoDB Enterprise Advanced through the Google Cloud Platforms Marketplace. MongoDB customers who want to get started using Enterprise Advanced in their GDC Hosted environments will need to sign up for a MongoDB Enterprise Advanced license through MongoDB first. For more information, reach out to gcp@mongodb.com . To learn more about the Enterprise Kubernetes Operator, visit our documentation . To learn more about Enterprise Advanced, visit our product page or download the latest version .

February 6, 2024

Leveraging MongoDB Atlas in your Internal Developer Platform (IDP)

DevOps, a portmanteau of “Developer” and “Operations,” rose to prominence around the early 2010s and established a culture of incorporating automated processes and tools designed to deliver applications and services to users faster than the traditional software development process. A significant part of that was the movement to "shift left" by empowering developers to self-serve their infrastructure needs, in theory offering them more control over the application development lifecycle in a way that reduced the dependency on central operational teams. While these shifts towards greater developer autonomy were occurring, the proliferation of public clouds, specific technologies (like GitHub, Docker, Kubernetes, Terraform), and microservices architectures entered the market and became standard practice in the industry. As beneficial as these infrastructure advancements were, these technical shifts added complexity to the setups that developers were using as a part of their application development processes. As a result, developers needed to have a more in-depth, end-to-end understanding of their toolchain, and more dauntingly, take ownership of a growing breadth of infrastructure considerations. This meant that the "shift left" drastically increased the cognitive load on developers, leading to inefficiencies because self-managing infrastructure is time-consuming and difficult without a high level of expertise. In turn, this increased the time to market and hindered innovation. Concurrently, the increasing levels of permissions that developers needed within the organization led to a swath of compliance issues, such as inconsistent security controls, improper auditing, unhygienic data and data practices increased overhead which ate away at department budgets, and incorrect reporting. Unsurprisingly, the desire to enable developers to self-serve to build and ship applications hadn't diminished, but it became clear that empowering them without adding friction or a high level of required expertise needed to become a priority. With this goal in mind, it became clear that investment was required to quickly and efficiently abstract away the complexities of the operational side of things for developers. From this investment comes the rise of Platform Engineering and Internal Developer Platforms (whether companies are labeling it as such or not). Platform engineering and the rise of internal developer platforms Within a developer organization, platform engineering (or even a central platform team) is tasked with creating golden paths for developers to build and ship applications at scale while keeping infrastructure spend and cognitive load on developers low. At the core of the platform engineering ethos is the goal of optimizing the developer experience to accelerate the delivery of applications to customers. Like teaching someone to fish, platform teams help pave the way for greater developer efficiency by providing them with pipelines that they can take and run with, reducing time to build, and paving the way for greater developer autonomy without burdening developers with complexity. To do this, platform teams strive to design toolchains and workflows based on the end goals of the developers in their organization. Therefore, it’s critical for the folks tasked with platform engineering to understand the needs of their developers, and then build a platform that is useful to the target audience. The end result is what is often (but not exclusively) known as an Internal Developer Platform. What is an IDP? An IDP is a collection of tools and services, sourced and stitched together by central teams to create golden paths for developers who will then use the IDP to simplify and streamline application building. IDPs reduce complexity and lower cognitive load on developers - often by dramatically simplifying the experience of configuring infrastructure and services that are not a direct part of the developer's application. They encourage developers to move away from spending excess time managing the tools they use and allow them to focus on delivering applications at speed and scale. IDPs enable developers the freedom to quickly and easily build, deploy, and manage applications while reducing risk and overhead costs for the organization by centralizing oversight and iteration of development practices. An IDP is tailored with developers in mind and will often consist of the following tools: Infrastructure platform that enabled running a wide variety of workloads with the highest degree of security, resilience, and scalability, and a high degree of automation (eg. Kubernetes) Source code repository system that allows teams to establish a single source of truth for configurations, ensuring version control, data governance, and compliance. (eg. Github, Gitlab, BitBucket) Control interface that enables everyone working on the application to interact with and manage its resources. (eg. Port or Backstage) Continuous integration and continuous deployment (CI/CD) pipeline that applies code and infrastructure configuration to an infrastructure platform. (eg. ArgoCD, Flux, CircleCI, Terraform, CloudFormation) Data layer that can handle changes to schemas and data structures. (eg. MongoDB Atlas) Security layer to manage permissions in order to keep compliance. Examples of this are roles-based compliance tools or secrets management tools (eg. Vault). While some tools have overlap and not all of them will be a part of a specific IDP, the goal of platform engineering efforts is to build an IDP for their developers that is tightly integrated with infrastructure resources and services to maximize automation, standardization, self-service, and scale for developers, as well as maximizing security whilst minimizing overhead for the enterprise. While there will be many different terms that different organizations and teams use to refer to their IDP story, at its core, an IDP is a tailored set of tech, tools, and processes , built and managed by a central team, and used to provide developers with golden paths that enable greater developer self-service, lower cognitive load, and reduce risk. How does MongoDB Atlas fit into this story? Developers often cite working with data as one of the most difficult aspects of building applications. Rigid and unintuitive data technologies impede building applications and can lead to project failure if they don’t deliver the data model flexibility and query functionality that your applications demand. A data layer that isn’t integrated into your workflows slows deployments, and manual operations are a never-ending drag on productivity. Failures and downtime lead to on-call emergencies – not to mention the enormous potential risk of a data breach. Therefore, making it easy to work with data is critical to improving the developer experience. IDPs are in part about giving developers the autonomy to build applications. For this reason, MongoDB’s modern database is a natural fit for an IDP because it serves as a developer data platform that can easily fit into any team’s existing toolstack and abstracts away the complexities associated with self-managing a data layer. MongoDB’s modern database is a step beyond a traditional database in that it helps organizations drive innovation at scale by providing a unified way to work with data that address transactional workloads, app-driven analytics, full-text search, vector search, stream data processing, and more, prioritizing an intuitive developer experience and automating security, resilience, and performance at scale. This simplification and broad coverage of different use cases make a monumental difference to the developer experience. By incorporating MongoDB Atlas within an IDP, developer teams have a fully managed modern database at their disposal that enables them to build and underpin best-in-class applications. This way teams won’t have to worry about adding the overhead and manual work involved in self-hosting a database and then building all these other supporting functionality that come out of the box with MongoDB Atlas. Lastly, MongoDB Atlas can be hosted on more cloud regions than any other cloud database in the market today with support for AWS, Azure, and Google Cloud. How can I incorporate MongoDB Atlas into my IDP? MongoDB Atlas’ modern database offers many ways to integrate Atlas into their IDP through many tools that leverage the MongoDB Atlas Admin API. The Atlas Admin API can be used independently or via one of these tools/integrations and provides a programmatic interface to directly manage and automate various aspects of MongoDB Atlas, without needing to switch between UIs or incorporate manual scripts. These tools include: Atlas Kubernetes Operator HashiCorp Terraform Atlas Provider AWS CloudFormation Atlas Resources Atlas CDKs Atlas CLI Atlas Go SDK Atlas Admin API With the Atlas Kubernetes Operator, platform teams are able to seamlessly integrate MongoDB Atlas into the current Kubernetes deployment pipeline within their IDP allowing their developers to manage Atlas in the same way they manage their applications running in Kubernetes. First, configurations are stored and managed in a git repository and applied to Kubernetes via CD tools like ArgoCD or Flux. Then, Atlas Operator's custom resources are applied to Atlas using the Atlas Admin API and support all the building blocks you need, including projects, clusters, database users, IP access lists, private endpoints, backup, and more. For teams that want to take the IaC route in connecting Atlas to their IDP, Atlas offers integrations with HashiCorp Terraform and AWS CloudFormation which can also be used to programmatically spin up Atlas services off the IaC integrations built off the Atlas Admin API in the Cloud environment of their choice.. Through provisioning with Terraform, teams can deploy, update, and manage Atlas configurations as code with either the Terraform Provider or the CDKTF. MongoDB also makes it easier for Atlas customers who prefer using AWS CloudFormation to easily manage, provision, and deploy MongoDB Atlas services in three ways: through resources from the CloudFormation Public Registry, AWS Quick Starts, and the AWS CDK. Other programmatic ways that Atlas can be incorporated into an IDP are through Atlas CLI, which interacts with Atlas from a terminal with short and intuitive commands and accomplishes complex operational tasks such as creating a cluster or setting up an access list interactively Atlas Go SDK which provides platform-specific and Go language-specific tools, libraries, and documentation to help build applications quickly and easily Atlas Admin API provides a RESTful API, accessed over HTTPS, to interact directly with MongoDB Atlas control plane resources. The fastest way to get started is to create a MongoDB Atlas account from the AWS Marketplace , Azure Marketplace , or Google Cloud Marketplace . Go build with MongoDB Atlas today!

January 4, 2024

MongoDB Atlas AWS CloudFormation and CDK Integration Expansion

At MongoDB, we meet our developers where they’re at and offer multiple ways to get started and work with MongoDB Atlas . Since our GA launch of the MongoDB Atlas integration with the AWS CloudFormation Registry at the start of this year, users have had the freedom to manage their MongoDB Atlas resources using familiar YAML or JSON CloudFormation Templates. This provided developers and DevOps teams the core Infrastructure as Code (IaC) benefits: enhanced automation, version control, infrastructure consistency, and improved compliance. In addition to these updates, we went further and announced support for CDK at MongoDB.Local NYC in June 2023, which allowed development teams to leverage MongoDB Atlas resources natively in the language of their choice: JavaScript, TypeScript, Python, Java, Go, and C#. Today, just ahead of AWS re:Invent , we are excited to announce several key improvements and expansions to our AWS CloudFormation and CDK integrations that we hope will continue to make developers' lives even easier. New MongoDB Atlas resources on the AWS CloudFormation Registry Nine new MongoDB Atlas Resources have been published including Federated Database Instance , Serverless Private Endpoint , Programmatic API Keys Management , MongoDB Atlas Gov Support , and MongoDB Atlas Organization Management . This brings the total MongoDB Atlas Resources count on CloudFormation Registry to 42 and allows developers to do more with MongoDB Atlas and AWS CloudFormation. AWS region expansion Are you a developer based in or have your end customers in Hyderabad India , Melbourne Australia , Spain , Switzerland , or the UAE ? The good news, we have published all 42 Atlas Resources in each of these new AWS regions as well. Benefits include reduced latency and improved compliance with data sovereignty regulations. This brings the total MongoDB Atlas availability from 22 to 27 AWS regions on the AWS CloudFormation and CDK. New CDK level 3 resources The CDK provides different levels of abstraction for defining cloud resources: L1 constructs, which are direct mappings to AWS CloudFormation resources, and higher-level constructs like L2 and L3, which can provide high levels of abstraction. L3 constructs, also known as "Design Patterns" or "High-Level Constructs," combine multiple resources together in commonly used architectures with intelligent defaults, saving developers from manually having to glue L1 and L2 constructs together each time. Hence, we are happy to announce several new AWS CDK L3 resources including support for MongoDB Atlas Serverless . Migration to the Atlas Go SDK Lastly, we are delighted to have migrated our AWS CloudFormation resources to the new Atlas Go SDK . This is the middle layer that translates AWS CloudFormation calls to the Atlas Admin API (which is ultimately responsible for provisioning your MongoDB Atlas infrastructure). This migration goes a long way in accelerating our internal development velocity and enabling us to publish more MongoDB Atlas Resources on AWS CloudFormation soon after they go GA. Learn more about the key benefits of the Atlas Go SDK . Start building today These MongoDB Atlas integrations with AWS CloudFormation are free and open-source, licensed under the Apache License 2.0 . Users only pay for underlying MongoDB Atlas and AWS resources created and can get started building with the Atlas always-free tier ( M0 clusters ). Getting started today is faster than ever with MongoDB Atlas and AWS CloudFormation. We can’t wait to see what you will build next. Learn more on our MongoDB Atlas and AWS CloudFormation page.

November 27, 2023

MongoDB Gives Users a Simple Way to Install Atlas Kubernetes Operator and Import MongoDB Atlas Clusters via the Atlas CLI

As time to market and rapid innovation get ever more critical to business success, the last thing your team needs is to spend more time than necessary managing infrastructure. In our most recent update to the MongoDB Atlas Kubernetes Operator , we’ve made it even easier to manage Atlas through the same mechanism that your team is using to manage their applications in Kubernetes. The Atlas Operator enables teams to deploy simple yaml configuration to Kubernetes, where the Operator automates the use of the Atlas Admin APIs to make the changes. It's now possible to install the Atlas Operator through a single command via a tool they already have: the Atlas CLI. Additionally, we’ve given users the optional ability to import existing Atlas projects and deployments into management through the Operator, as part of the installation or as a stand alone operation, making it easy to adopt existing Atlas deployments into management through the Operator. Keep reading to learn how your team can automate the installation and import of Atlas projects in order to enable easy self-service use of Atlas for your engineering teams. But first, a little context The MongoDB Atlas Kubernetes Operator enables teams to manage Atlas from within Kubernetes the same way they would any other service in their Kubernetes stack. By doing this, the Operator removes the need for custom scripts and switching between UIs in order to use the two together. Instead, teams are able to manage their Atlas projects, deployments and database users through yaml that can either live in their Kubernetes cluster, or, more commonly, in a repository alongside their other infrastructure as code configuration. Many customers choose to use a deployment tool like ArgoCD or Flux to automate applying those into Kuberentes, where the Atlas Operator picks them up and uses APIs to make the changes to Atlas. All your teams need to worry about is the yaml in their repo! Previously, setting up the Atlas Kubernetes Operator was a multi-step, manual process. First teams had to use Kubernetes tooling to install the Atlas Kubernetes Operator within a Kubernetes cluster. Teams then had to create an API key in Atlas and a corresponding Kubernetes secret required to authenticate the Atlas Kubernetes Operator to Atlas. It was only after all of that work that they could then create a database or import existing Atlas deployments into the Atlas Kubernetes Operators control. While exporting Atlas configuration into Kubernetes was generally a simple process, it still required some manual steps to bridge the Atlas CLI (which offered a compatible export of Atlas configuration) and Kubernetes (where the configuration needed to be imported). Because of this, secrets either had to be exported in plaintext onto the user’s machine, or entered manually later. All of this to say, it was possible… it just wasn't a piece of cake. Enter a more simplified approach Now, it’s easier than ever to get started with Kubernetes-native management of Atlas. First, we’ve made the installation of the Atlas Kubernetes Operator a simpler process by enabling teams to use the Atlas CLI to install the Atlas Kubernetes Operator. Through a single command in the CLI, Atlas users are able to easily install the Atlas Kubernetes Operator into their currently connected Kubernetes cluster. Including the automated creation of an Atlas API key and storing it in a Kubernetes secret for use by the Operator. Additionally, users can now export Atlas configuration for projects, deployments and users directly into Kubernetes, either as part of the install or as a separate operation. This saves users from needing to always having to export to their own machine before applying to Kubernetes, though exporting like this is still available to support GitOps workflows. With these options, it’s much easier for teams to take control of their projects and clusters and manage them through the Atlas Operator. By simplifying the use of the Atlas Kubernetes Operator with these updates, we have significantly reduced the amount of toil that went into getting started with Atlas. Get started with the Atlas Kubernetes Operator today. Head to the MongoDB.local hub to see where we'll be showing up next.

June 28, 2023