MongoDB Atlas, the fully managed cloud database, provides customers with pre-built and customizable alerts that can easily be configured for different channels, including Slack, Hipchat, PagerDuty, Flowdock, and more.
Due to popular demand, we’ve recently added Datadog as an optional endpoint for Atlas alerts. An increasing number of companies are using Datadog to monitor their entire application estate; this new integration will allow them to quickly get a sense of any database alerts from a dashboard they regularly view.
Setup is simple. Select a MongoDB Atlas Project, and click on “Settings” in the left-hand menu. Scroll down to “Datadog Settings” and paste in your Datadog API key.
Next, click on “Alerts” in the left-hand menu. You will see a screen that shows all alerting activity. Click on the green “Add” button in the upper right corner of your screen to create a new alert. You can now customize a new alert and specify “Datadog” as the endpoint.
To send an existing alert to Datadog, simply click on “Alert Settings” in the top navigation of your main Alerts screen. This will show you all of your existing alerts, and allow you to edit them using the same UI you use to create new alerts.
And that’s it. You should now start seeing MongoDB Atlas alerts in Datadog.
Not yet a MongoDB Atlas user? Create an account and get a free 512 MB database.
The Best Solutions Architects Work At MongoDB
Despite the bravado in the title, the purpose of this article is not to say that MongoDB Solutions Architects (SAs) are better than those working at other organizations. Rather, this article argues that the unique challenges encountered by SAs at MongoDB imply that successful MongoDB SAs are some of the best in the business. This assertion is derived from the unique challenges encountered by both supporting MongoDB customers and the MongoDB sales organization and breadth and depth of skills and knowledge required to be successful. To see why this is the case, let’s explore the role of an SA at MongoDB and the wide range of skills a Solutions Architect must master. A MongoDB SA (sometimes called a Sales Engineer in other organizations) is an engineer that supports the sales organization. The role is multi-faceted. A solutions architect must have: In-depth technical knowledge to both understand a customer’s technical challenges and to articulate how MongoDB addresses them Communication skills to present technical concepts in a clear and concise manner while tactfully dealing with skeptics and those more familiar with other technologies Sales skills to engage a prospect to learn their business challenges and the technical capabilities required to address those challenges Design and troubleshooting skills to assist prospects with designing solutions to complex problems and getting them back on track when things go wrong. The description above may make the MongoDB Solutions Architect role sound like other similar roles, but there are unique features of MongoDB (the product) and its competitive situation that make this role extremely challenging. We will explore this in the sections below. Technology While the strength of MongoDB and a major factor in its success has been the ease with which it can be adopted by developers, MongoDB is a complex product. Presenting MongoDB, answering questions, brainstorming designs, and helping resolve problems requires a wide range of knowledge including: The MongoDB query language Application development with MongoDB’s drivers in 10+ different programming languages Single and multi-data center architectures for high availability Tuning MongoDB to achieve the required level of performance, read consistency, and write durability Scaling MongoDB to manage TBs of data and thousands of queries per second Estimating the size of a cluster (or the cloud deployment costs) required to meet application requirements Best practices for MongoDB schema design and how to design the best MongoDB schema for a given application MongoDB Enterprise operations tools: Ops Manager , Compass , etc. Atlas : MongoDB’s Database as a Service Offering MongoDB’s various connectors: BI , Spark , and Hadoop Migration strategies from RDBMS (and other databases) to MongoDB This is a lot to know and there is a lot of complexity. In addition to the core knowledge listed above, knowledge of the internal workings of MongoDB is essential when working on designs for applications with high performance and scalability requirements. Therefore, most Solutions Architects understand MongoDB’s internal architecture, such as how the WiredTiger storage engine works or how a MongoDB cluster manages connections. To make the SA role even more challenging, organizations often choose MongoDB after failing with some other technology. (Maybe their RDBMS didn’t scale or it was too difficult to expand to handle new sources of data, or Hadoop processing did not meet real-time requirements, or some other NoSQL solution did not provide the required query expressibility and secondary indexes.) This means that MongoDB is often used for bleeding-edge applications that have never been built before. One of the roles of an SA is to understand the application requirements and help the application team come up with an initial design that will ensure their success 1 . It is probably obvious to experienced SAs, but SAs need to understand the capabilities, strengths, and weakness of all competing and tangential solutions as well. MongoDB’s biggest competitors are Oracle, Amazon, and Microsoft – all of whom are constantly evolving their product offerings and marketing strategies. An SA must always keep their knowledge up to date as the market evolves. Communication Being a great technologist is not enough. An SA spends at least as much time communicating with customers as they do working with technology. Communication is sometimes in the form of a standard presentation or demo, but it most often entails detailed technical conversations about how MongoDB works or how MongoDB can be used to address a particular problem. Concise technical explanations that address customer questions using language tailored to their particular situation and frame of reference are the hallmark of an SA. MongoDB SAs have to be comfortable communicating with a wide range of people, not just development teams. They must engage operations, line of business stakeholders, architects, and technology executives in sales discovery conversations and present the technical aspects of MongoDB of most concern at the appropriate level of detail. For example, an SA must be able to provide technology executives with an intuitive feel for why their development teams will be significantly more productive with MongoDB or will be able to deploy a solution that can meet scalability and performance requirements unattainable with previous technology approaches. Similarly, an SA must learn an operations team’s unique challenges related to managing MongoDB and describe how tools like Ops Manager and Atlas address these requirements. Public speaking skills are also essential. Solutions Architects deliver webinars, speak at conferences, write blog posts, and lead discussions and MongoDB User Groups (MUGs). Sales An SA is a member of the Sales organization and “selling” is a big part of the role. Selling involves many aspects. First, SAs assist the MongoDB Account Executives with discovery and qualification. They engage the customer in conversations to understand what their current problems are, their desired solution, the business benefits of the solution, the technical capabilities required to implement this solution, and how they'll measure success. After every customer conversation, SAs work with their Account Executives to refine their understanding of the customer’s situation and identify information that they want to gather at future meetings. Once the required technical capabilities are understood, it is the SA’s role to lead the sales activities that prove to the customer that (1) MongoDB meets all their required capabilities and (2) MongoDB meets these capabilities better than competing solutions. Most of the time this is accomplished via customer conversations, presentations, demonstrations, and design brainstorming meetings. Finally, customers sometimes want to test or validate that MongoDB will meet their technical required capabilities. This is often in the form of a proof of concept (POC) that might test MongoDB performance or scalability, the ease of managing MongoDB clusters with its operations tools, or that MongoDB’s BI Connector provides seamless connectivity with industry standard BI Tools, such as Tableau , Qlik , etc. SAs lead these POC efforts. They work with prospects to define and document the scope and success criteria and work with the prospect during the course of a POC to ensure success. Design and Troubleshooting I alluded to this in the “Technology” section: helping prospects with creative problem solving distinguishes SAs at MongoDB. Organizations will choose MongoDB if they believe and understand how they will be successful with it. Imparting this understanding (a big part of the Solutions Architect’s role) is typically done by helping an organization through some of the more thorny design challenges and implementation decisions. Organizations will choose MongoDB when they understand the framework of a good MongoDB design for their use case and believe all their design requirements will be met. Designing a solution is not a yes or no question that can be researched in the documentation, but is found through deep technical knowledge, careful analysis, and tradeoffs among many competing requirements. The best answer is often found through a collaborative process with the customer. SAs often lead these customer discussions, research solutions to the most challenging technical problems, and help craft the resulting design. Solutions Architects are also a source of internal innovation at MongoDB. Since Solutions Architects spend a significant amount of time speaking with customers, they are the first to realize when marketing or technical material is not resonating with customers or is simply difficult to understand. The pressure of short timelines and desire to be successful often results in innovative messaging and slides that are often adopted by MongoDB’s Product Marketing organization. Similar innovation often occurs with respect to MongoDB feature requests and enhancements. SAs are continually working with customers to help them solve problems and they quickly identify areas where MongoDB’s enhancements would provide significant value. The identification of these areas and specific recommendations from SAs on what product enhancements are required have played a big role in focusing the feature set of future MongoDB releases. Project Management Lastly, SAs often support a number of Account Executives and work on several dozen sales opportunities per quarter. This means that SAs are working a large number of opportunities simultaneously and must be highly organized to ensure that they are prepared for each activity and complete every follow-up item in a timely manner. It is not possible for an SA manager to track or completely understand every sales opportunity so SAs must be self-motivated and manage all their own activities. Summary Solutions Architecture at MongoDB is a challenging and rewarding role. The wide range of technical knowledge plus sales and communication skills required to be successful is common to SA roles. When you combine this with the need for SAs to design innovative solutions to complex (often previously unsolvable problems), the SAs have the set of skills and the track record of success that makes them the “best” in the business. If you want to join the best, check out the MongoDB Careers page . About the Author - Jay Runkel Jay Runkel is a principal solutions architect at MongoDB. For over 5 years, Jay has worked with Fortune 500 companies to architect enterprise solutions using non-relational document databases. Before MongoDB, Jay was a key team member at MarkLogic and Venafi, where he worked with financial services, medical, and media organizations to develop operational systems for analytics and custom publishing. He also has experience guiding large financial institutions, retailers, health care and insurance organizations to secure, protect, and manage their encryption assets. Jay has a BS in Applied Mathematics from Carnegie Mellon and a Masters in Computer Science from the University of Michigan. 1. My favorite part of the job is to get locked in a conference room and whiteboard for 4 hours with a development team to brainstorm the MongoDB solution/design for a particular use case. The most valuable end product of this session is not the design, but the development’s belief that they will be successful with MongoDB and that the development process will be easier than they expected. ↩
MACH Aligned for Retail (Microservices, API-First, Cloud Native SaaS, Headless)
Across the Retail industry, MACH principles and the Mach Alliance are becoming increasingly common. What is MACH and why is it being embraced for Retail? The MACH Alliance is a non-profit organization fostering the adoption of composable architecture principles. It stands for Microservices, API-First, Cloud-Native SaaS and Headless. The MACH Alliance’s Manifesto is to: “Future proof enterprise technology and propel current and future digital experiences" The MACH Alliance and the creation of this set of principles originated in the Retail Industry. Several of the 5 co-founders of the MACH Alliance are technology companies building for retail use cases: for example commercetools is a composable commerce platform for retail (built completely on MongoDB). MongoDB has been a member of the MACH Alliance since 2020, as an “enabler” member, meaning use of our technology can enable the implementation of the MACH principles in application architectures. This is because a data layer built on MongoDB is ideal as the basis for a MACH architecture. Members of our Industry Solutions team sit on the MACH technology, growth and marketing councils, and actively are involved with furthering the adoption of MACH across the Retail Industry What is MACH, why is it important for retail? The retail industry has long been a fast adopter of technology and a forerunner in technology trends. This is because of the competitive nature of the business leading a drive towards innovation- its vital that retails are able to react quickly to new technologies (e.g. NFTs, VR, AI) to capture market share and stay ahead of the competitors. Retailers have realized that to be able to deliver new and value-add experiences to their customers, they have to cut back on operational overhead that leads to increased cost and build standard functionality that can either be bought or re-used. This is where the benefits of MACH comes in- it's all about increasing the ability to deliver innovation quickly while lowering operational costs & risk. Microservices: An approach to building applications in which business functions are broken down into smaller, self-contained components called services. These services function autonomously and are usually developed and deployed independently. This means the failure or outage of one microservice will not affect another and teams can develop in parallel, increasing efficiency. API-First: A style of development where the sharing and use of the data via API (application programming interface) is considered first and foremost in the development process. This means that services are designed to aid the easy sharing of information across the organization and simple interconnectivity of systems. Cloud-Native SaaS: Cloud-native SaaS solutions are vendor-managed applications developed in and for the cloud, and leveraging all the capabilities the cloud has to offer, such as fully managed hosting, built-in security, auto-scaling, cross-regional deployment and automatic updates. These are a good fit for a MACH architecture as adopting them can reduce operational costs and frees up developers for value-add work like new unique customer experiences. Headless: Decoupling the front end from the back-end so that front ends (or “heads”) can be created or iterated on with no dependencies on the back end. The fact that the layers are loosely coupled decreases time to market for new front ends, and encourages the re-use back-end services for multiple purposes. It also de-risks change in the long term as services can function independently. Where does MongoDB come in? MongoDB is an enabler for MACH, meaning that using MongoDB as your data layer helps retailers and retail software companies. achieve MACH compliance. Our data model, architecture and functionality empower IT organizations to build in line with these architecture principles. During a digital transformation, where a retailer is modernizing a monolith into a microservices based architecture, they're looking for a data layer which will enable speed of development & change. MongoDB is the "most wanted" database 4 years running on Stack Overflow's developer survey- this is because our document model maps to the way developers are thinking & coding, and the flexibility allows for iterative change of the data layer. When looking at API based communication, the standard format for APIs is JSON, which again maps to MongoDB's document model. The idea with API-first development is to develop with the API in mind- why not store the data the way you're going to serve it by API. This reduces complexity and increases performance. Cloud Native and SaaS products have become the norm as retailers wish to reduce maintenance and management work. MongoDB Atlas, provides a database-as-a-service, guaranteeing 99.995% uptime, automatic failover and self-healing and allowing DevOps engineers to spin up databases in minutes or by API/ script. Many retail software companies are also built on MongoDB Atlas- for example commercetools, which provides an ecommerce solution as a SaaS product. Headless architectures require a data layer that is able to adapt and change for new workloads. The ability to change the schema at runtime, with no downtime, makes MongoDB's document model ideal for this. Performance and the ability to scale for new "heads" is also important. MongoDB is known as a high performance database and can scale vertically automatically or scale out horizontally seamlessly. So MongoDB becomes a great choice for retailers choosing to adopt a MACH architecture (see figure 1 below). As a general purpose database with high performance, a rich expressive query language and secondary indexing, MongoDB is a really good fit as a data layer as it is capable of handling operational and analytical needs of the application. FIgure 1: Example of a MACH architecture Want to know more? Are you interested in a transition to MACH? Dive into our four part blog series exploring each topic in detail and how MongoDB supports each of these principles: Microservices API-First Cloud-Native SaaS Headless