When you set up alerts in MongoDB Management Service, you now have the option to send them to PagerDuty. Like MMS, PagerDuty helps you increase application uptime and identify performance issues. With this new integration, you can set up multiple on-call schedules in PagerDuty to rotate your MMS alerts to different members of the team.
MongoDB Management Service tracks dozens of different MongoDB-specific metrics, providing you with visibility into the performance of you MongoDB system. Using MMS, you can create alerts when particular statistics are out of range. While previously you were limited to setting email and mobile alerts to individual members of the team, you can now rotate those alerts around your team, giving everyone time off by easily scheduling on-call rotations. And with PagerDuty, there are automated escalations so you can be sure that you’ll never miss an alert.
Meet Alvin Richards: Technical Director for Performance and Quality
Meet Alvin Richards, MongoDB’s Technical Director for Performance and Quality. What is your role at MongoDB? I’m MongoDB’s Technical Director for Performance and Quality. I work in the engineering department, but my job is cross-functional across all our products. I make sure everything we produce is high quality, acceptable, correct, and performant. Where were you before MongoDB? Why did you choose to come to MongoDB? I’ve worked at a variety of small companies and startups. Right out of college I started at Oracle, a little company building this new thing called a relational database. Soon Oracle became the market leader in that space; we’d completely changed how people thought about data. After sixteen years I left to work at a variety of startups and pursue a second degree. When I joined MongoDB, I felt like it was the way Oracle had been in the eighties; we were disrupting the ways people thought about their data. We were fixing areas where relational theory had broken down and now we’re reinventing the industry. I’ve been here for four years and we’ve just only started. What’s your hometown? That’s a good question. My heart says San Francisco, but my birth certificate says London. Right now I live in Belmont, California. Did you have previous experience using MongoDB before you arrived? If so, how are things different now that you work at MongoDB? My education was Dwight asking me to build a 100-node cluster for a conference in 6 weeks. So it was a baptism of fire in learning the technology, how to deploy something that size on EC2, figuring out LVM versus MD and many other issues. I love we now have a formal education program… but sometimes I think the new employees are missing out on an experience. Have you had any personal projects where you’ve used MongoDB? I’m hacking my Linn Magik DS at home. I think I can do better than the Frankenstein set of technologies the vendor thinks I have to use to simply play music over a network. Bike or public transportation to work? Electric car. I get to hack the system by being in a car alone and using the carpool lane. That’s California! What’s a typical day (or week) for you? We work in a form of organized chaos because we’re developing a new product and disrupting an existing space. You need to be able to think on your feet but keep the mission in mind. Each day starts with a triage of what happened overnight, covering everything from customer cases, performance runs in the lab, requests from the field or partners. It’s then trying to find the balance of keeping the short term moving but make progress on your strategic goals (i.e. keep your eyes on the prize). What do you love most about MongoDB? The people. There were only twelve of us when I joined and now we’re 340. Part of the joy of being here is watching the growth of not only the organization but also the people. New hires mature and take on new roles and opportunities. It’s very exciting to watch. What’s the most challenging aspect of your job? Solving the next problem. I could say starting as the initial employee in California and building that team from scratch. Then going to Europe for two years and doing the same thing for a whole continent. We had to go to community events, contact existing customers and find new ones, join meetups, and try to figure out what was happening when and where and why. You have to do literally everything. I’m doing the same with my new team, starting from scratch and building in three locations (New York, Palo Alto and Austin) at the same time. What’s one of the most rewarding experiences you’ve had working here so far? Random people coming up to me after to talk or meetup to tell me that I’ve helped them think through the problems they have been having. What’s your favorite Seamless lunch order? BLT from ‘wichcraft Name one secret skill you have, unrelated to work. Debugging a 1965 Datsun Fairlady. A rare but critical skill to ownership. Kindle or book? What’s your favorite book? Always a book, preferably on a beach. I’m not sure if this is my favorite but I enjoy “Season of Blood” by Fergal Keene immensely. Describe your perfect weekend. The kids don’t wake me up too early (they’re 11 and 8). Southampton wins a soccer game. I get to spend time with the family and dog (a 2 year old Hungarian Vizsla). Maybe playing some Apex Twin or Underworld a little too loudly on the turntables. So what did you get that second degree in? I graduated with a degree in computer science when I was 19. I worked at Oracle for about 7 or 8 years, and then I realized that tech was here to stay, and I could really do this job for the rest of my life. So I decided to go out and do what I wanted before things got too complicated (worrying about a family, marriage, etc.) I got a degree in photography, then went off to travel the world and take photos. I did a lot of work for the IRCR (International Committee of the Red Cross). They were fun times and a great way to collect stories to tell the grandchildren, but the bug of technology was never far away for me. If you're interested in joining the MongoDB Team there many open positions available in Engineering, Sales, Marketing, and Business Development. To learn more about open roles at MongoDB, please visit the MongoDB Careers Page .
4 Common Misperceptions about MongoDB
One year ago, in the middle of the pandemic, Dev Ittycheria, the CEO of MongoDB, brought me on as Chief Technology Officer. Frankly, I thought I knew everything about databases and MongoDB. After all, I’d been in the database business for 32 years already. I’d been on MongoDB’s Board of Directors and used the products extensively. And of course I’d done my due diligence, met the leadership team, and analyzed earnings reports and product roadmaps. Even with all that knowledge, this past year as MongoDB’s CTO has taught me that many of my preconceived notions were just plain wrong. This made me wonder how many other people might also have the wrong impression about this company. And this blog is my attempt to set those perceptions straight by sharing my four major revelations of the last year. My first revelation is that MongoDB is not trying to become this generation’s relational database. For years I assumed that MongoDB basically wanted to be a better, more modern version of Oracle when it grew up. In other words, compete with the huge footprint of Oracle and other commercial RDBMSs that have been the industry archetype for so long. I was way off. The whole point of MongoDB is to leave all those forms of archaic, legacy database technology in the historical dust. This was never supposed to be an evolution, but instead a revolution. Our founders not only envisioned the world's fastest and most scalable persistent store, but also one that would be programmed and operated differently. The combination of embedded documents and structures combined with automatic high availability and almost-infinite distribution capability all add up to a fundamentally different way of working with data, building applications, and running those applications in production. Oracle and (SQL*Server, etc) still hang their hats on E.F. Codd’s 51-year old vision of rows and columns. To obtain high availability and distribution of data, you need add ons, options packages, bailing wire and duct tape. And you need a lot of database administrators. Not cheap. Even after all that, you’re still trailing the technological edge. This is how wrong I was. Our durable competitive advantages over these legacy data stores make competing with those products almost irrelevant. We instead focus on the modern needs of modern developers building modern applications. These developers need to create their own competitive advantage through language-native development, reliable deployments to production, and lightning fast iteration. And the world is noticing; just check out the falling slope of Oracle and SQL*Server and the rising slope of MongoDB on the db-engines website. Which brings me to my second revelation: MongoDB was built for developers, by developers. I always knew that MongoDB was exceedingly fast and easy to program against. One time while I was bored in a meeting (yes, it happens here as well!), I built an Atlas database, loaded it with 350MB of data, downloaded and learned our Compass data discovery tool, built-in analytics aggregation pipelines, and our Charts package, and embedded live charts in a web page. This took me all of 19 minutes, end to end. To build something like that for engineers , it just has to be built by engineers , ones that are free to focus on all the rough edges that creep into products as features are added. I was first exposed to software planning and management over 40 years ago, and my LinkedIn profile shows a pretty diverse tour around the industry. Now, one year in, I can emphatically state that engineering and product at MongoDB are both different and better than any company I’ve ever had the privilege to work at. Our executive leadership gives engineering and product broad brushstokes of goals and desired outcomes, and then we work together to come up with detailed roadmaps, updated quarterly, that meet those goals in the way we think best, with no micromanagement. And we’re not afraid of 3-5 year projects, either. For example, multi-cloud was more than three years in the making. Also unlike any other company I’ve been at, we embrace the creation and re-payment of tech debt, rather than sweeping it under the rug. We do this through giving our product and engineering teams huge amounts of context, delivered with candor and openness. And one more essential thing; we have an empowered program management team that improves processes (including killing them) as fast as we create them. In short, we paint the targets for our teams and let them decide how and when to shoot. They even design the arrows and bows. It’s true bottoms-up engineering. Our engineers feel valued and understood. And that, in turn, empowers them to develop features that make our customers feel valued and understood, like a unified query language, or real-time analytics and charting directly in the console, or multi-region/multi-cloud clusters where all the networking cruft is taken care of for you. And this brings me to my third revelation: MongoDB is built for even the most demanding mission critical applications. Fast? Yes. Easy? Of course. But mission-critical? That’s not how I saw MongoDB when I used Version 2 for a massive student data project 10 years ago. While it was the only possible datastore we could have chosen for the amount of data and the speed of ingestion and processing needed, it was pretty hard to set up and use in a 24 x 365 environment. MongoDB had gotten ahead of itself in the early 2010’s. There was a gap between our capabilities and the expectations of the market. And it was painful. Other databases had had more than 30 years to solidify their systems and operations. We’d had five. But with Version 3 we added a new storage engine, full ACID transactions, and search. We built on it with Version 4. And then again with Version 5, released this week at our .Live conference. I knew about all this progress intellectually of course when I joined, but not viscerally. I came to realize that the security, durability, availability, scalability, and operability our platform offers (of course in addition to all the features that developers love too) was ideal for architecting fast-moving enterprise applications. And I found the proof in our customer list. It reads like a Who’s Who of major global banks, retailers, and telecommunications companies, running core systems like payments, IoT applications, content management, and real-time analytics. They use our database, data lake, analytics, search, and mobile products across their entire businesses, in every major cloud, on-premises, and on their laptops. And that leads me to my fourth and final revelation. MongoDB is no longer just a database. Of course, the database is still the core. But MongoDB now provides an enterprise-class, mission-critical application data platform. A cohesive, integrated suite of offerings capable of managing modern data requirements across even the most sprawling digital estates, and scaling to meet the level of any company’s ambition, without sacrificing speed or security. Since the day I was first introduced to MongoDB’s products, I’ve had tremendous respect and admiration for the teams and their work. After all, I’m a developer, first and foremost. And it always felt like they “got” me. But had I known then what I know now, I would have jumped on this train a long time ago. In fact, I might have camped out on their doorstep with my resume in hand. And who knows? Maybe a bunch of people reading this will do just that, and have their own revelations about how fulfilling and exciting it can be to be at a great company, with a great culture, producing great products. I’ll write another letter a year from now, and let you know how it’s going then. In the meantime, please reach out to me here, or at @MarkLovesTech .