MongoDB Blog
Articles, announcements, news, updates and more
Data and the European Landscape: 3 Trends for 2022
December 21, 2021
Developer
Engagement Management at MongoDB: Meet Lalitesh Pal
I sat down with Lalitesh Pal , Senior Engagement Manager at MongoDB, to learn more about the Engagement Manager role and why joining the EMEA team is an exciting opportunity. Jackie Denner: Hi, Lalitesh. It’s great to meet you! Thanks for sharing some insight into Engagement Management at MongoDB with me. Can you start by telling me a bit about the Engagement Manager role? What are Engagement Managers responsible for? Lalitesh Pal: Engagement Management is a services sales role within the Professional Services organization at MongoDB. We ensure customers understand the value of MongoDB technology and drive the adoption of our technology in line with MongoDB best practices. Engagement Managers are engaged in the sales cycle early on in the process, typically right after the Account Executive has done their qualification. An Engagement Manager will then help gather the learning needs, drive the right services proposal, and determine how MongoDB can help customers develop applications on top of our data platform. Since a lot of MongoDB customers are new, or are new business units within existing customers, Engagement Managers also prepare tailored enablement plans to enable them with our technology, helping them become self-sufficient in the long run. JD: What skills and experience make someone successful in the Engagement Manager role? LP: Engagement Manager is a key role that enables our Sales team and helps further proliferate MongoDB product adoption in our customer base. To be really successful, you need techno-functional skills combined with strong commercial proposal and sales experience. If you have a winning and stretch mindset , you can ensure success is guaranteed. Needless to say, an Engagement Manager needs to have the collaborative spirit and be able to orchestrate things amongst multiple stakeholders - both internal and external. Finally, Engagement Managers need to feel confident working hand-in-hand with Account Executives to ensure that MondoDB is well-presented and positioned with the customer. I have been in services sales for about 7 years out of my 14 years of work experience. Engagement Managers need to understand technology on a high level. At the end of the day, the most successful Engagement Managers have a sales mindset and are able to connect with business stakeholders and explain the value of MongoDB Professional Services. It’s important to note that Engagement Management is not a delivery role. There are two aspects of Professional Services at MongoDB: one is services sales, the other is delivery. Engagement Managers work with a customer up until the deal is closed and have their own individual quarterly quotas. Once the deal is closed, an internal kickoff takes place with a Regional Delivery Manager and Project Manager who handle all aspects of delivery. JD: What is interesting and exciting about this role? LP: As an Engagement Manager, you’re not just a champion to your Account Executives and MongoDB, you’re also adding immense value to the customer and are their trusted advisor. In some cases, customers may reach out to you before reaching out to their Account Executive. For the customer, you are someone who is turning their ideas into reality by providing a way to make it happen. What really excites me about this role is the impact Engagement Managers have on our customers and the trust that we are able to build, which further reinforces the partnership spirit with them. JD: What learning and growth opportunities are there for someone in Engagement Management? What does the next career step look like? LP: Engagement Managers are currently aligned to Regional Vice Presidents and work at all levels of accounts, from our strategic “POD” accounts to the enterprise and the mid-market. From the Engagement Manager role, there is an opportunity to become a Senior Engagement Manager and eventually a Principal Engagement Manager. We offer career paths for those who want to remain individual contributors and those who are interested in managerial roles leading a team. MongoDB is also very committed to internal mobility, and there is an opportunity to transfer to other roles such as Customer Success or Practice Leads, both of which are global teams. JD: What is the team culture like? LP: Our EMEA team currently consists of six Engagement Managers who report to the Director of Engagement Management, and we’re growing rapidly. We have regular team catch-ups where we discuss weekly forecasts, what’s working and what’s not within our accounts, and share best practices with one another. There is a true open door policy across the entire team -- everyone is just a ping away! We also have a very defined onboarding program for Engagement Managers. Onboarding is spread over five weeks, and new hires will participate in our Sales Bootcamp, new hire technical training, and a services-specific onboarding program where you’ll be assigned to a buddy who is responsible for helping you get settled in. JD: The Professional Services function at MongoDB is still taking shape. What has the Engagement Management team’s journey been like so far? LP: I joined MongoDB a year ago, and we’re always looking for Engagement Managers to change the way MongoDB sells professional services. When I started, we were doing volume-based selling with small deal sizes and packages or “off the shelf” offerings for customers. Now, it’s much more strategic and we’re selling bespoke offerings with project or program-based delivery. Instead of merely advising on how to set up our data platform, we now engage in developing the complete application and working with customer contacts such as C-levels and VPs instead of just architects. We are working on end-to-end projects that innovate on top of MongoDB, showing customers how to deliver faster and better thanks to our technology. All of this results in MongoDB’s reputation as a strategic partner. JD: Why did you join MongoDB, and what makes you stay? LP: What really got me excited initially was MongoDB’s well-structured hiring process that helped me understand the culture, people, and products. It was the culture at MongoDB that made the difference. The people here are truly fantastic, and the hiring process allowed me to interact with a lot of individuals. The second thing is the product. MongoDB’s products are amazing, and there’s nothing else like it on the market (at least nothing that’s competitive). You also receive a lot of autonomy here in general, but in the Engagement Manager role specifically, you’re given the freedom to reach out to customers directly, run your own pipeline generation plan for accounts in line with account strategy, and many times speak to customers one-on-one without an Account Executive present. Employee recognition is an important part of our culture as well. If you are good at what you do, MongoDB will applaud you at all levels. I saw that I could really contribute and add value here, and I still feel that to this day. Interested in pursuing a career in Professional Services at MongoDB? We have several open roles on our teams across the globe and would love for you to transform your career with us!
Joyce, a Decentralized Approach to Foster Business Agility
Despite all of the tools and methodologies that have arisen in the last few years, many companies, particularly those that have been in the market for decades, struggle when it comes to leveraging their operational data to build new digital products and services. According to research and surveys conducted by McKinsey over the last few years, the success rate of digital transformations is consistently low, with less than 30% succeeding at improving their company’s performance. There are a lot of reasons for this, but most of them can be summarized in a sentence: A digital transformation is primarily an organizational and cultural change and then a technological shift. The question is not if digital transformation is a good thing nor is it if moving to the cloud is a good choice. Companies need (badly, in some cases) a digital transformation and yes, the pros of moving to the cloud usually overcome the cons. So, let’s try to dig deeper and analyze three of the main problems companies face when they go on this journey Digital products development Products by nature are customer-driven but companies run their businesses on multiple back-end systems that are instead purpose-driven. Unless you run a very small business, different people with different objectives have ownership of such products and systems. Given this context, what happens when a company wants to launch a new digital product at speed? The back-end systems (CRMs, E-commerce, ERP, etc.) hold the data they need to bring to the customer. Some systems are SaaS, some are legacy, and perhaps others are custom applications created by the company that disrupted the market with innovative solutions back in the days, the perfect recipe for integration hell. The product manager needs to coordinate and negotiate multiple change requests with the system’s owners whilst trying to convince them to add their needs in the backlog to meet the deadline. And things get even worse, as the new product relies on the computational power of the source systems, and if those systems cannot handle the additional traffic, both the product and the core services will be affected. Third-party integration “Everybody wants the change, (almost) nobody wants to change.” In this ever-growing digital world, partnering with third parties (whether they are clients or service providers) is crucial, but everyone who has tried to do so knows how challenging this is: non-standard interfaces, CSV files over FTP with fancy update rules, security issues… The list of unwanted things can grow indefinitely. SaaS everywhere The Software-as-a-Service model is extremely popular and getting the service you want without worrying about the underlying infrastructure gives freedom and speed of adoption, but what happens when a big company relies on multiple SaaS products to run their business? Sooner or later, they experience loss of control and higher costs in keeping a consistent view of the big picture. They need to deal with SaaS internal representations of their own data, multiple views of the same domain concept, unplanned expenses to export, and interpret and integrate the data from different sources with different formats. Putting it all together All the issues above fall into a well-known category of information technology. They are integration problems, and over the years, a lot of vendors promised a definitive solution. Now, you can consider low-code/no-code platforms with hundreds of ready-made connectors and modern graphical interfaces. Problem solved, right? Well, not really. Low-code integration platforms simplify implementation. They are really good at it, but doing so oversimplifies the real challenge: creating and maintaining a consistent set of APIs shaped around the business value over time, and preventing the interfaces from leaking internal complexities to the rest of the company, something that has to be defined and maintained through architectural choices and proper skills (completely hidden behind the selling points of such platforms). There are two different ways to solve integration problems: Centralized using adapters. In this case, the logic is pushed to the central orchestration component, with integration managed through a set of adapters. This is the rather old school SOA approach, the one that the majority of market integration platforms are built on. Decentralized, pushing the logic to the edges, giving autonomous teams the freedom to define both the boundaries and the APIs that a domain must expose to deliver business value. This is a more modern approach that has arisen recently alongside the rise of microservices and, in the analytical world, with the concept of data mesh. The former gives speed at the starting point and the illusion of reducing the number of choices and skills to manage the problems, but in the long run, inevitably, this begins to accumulate technical debt. Due to the lack of necessary degrees of freedom, you lose the ability to evolve the integration points over time, the same thing that caused the transition from SOA to microservices architectures. The latter needs the relevant skills, vision, and ability to execute but gives immediate results and allows you to flexibly manage the evolution of the enterprise architecture over time. Old problems, new solutions At Sourcesense in the last 20 years, we have partnered on hundreds of projects to bring agility, speed, and new open-source technology to our customers. Many times through the years, we were faced with the integration challenges above, and yes, we tried to solve them with the technology available at the time, so we have built some integration solutions on SOA (when they were the best of breed) and interacted with many of the integration platforms on the market. Then, we struggled with the issues and limitations of the integration landscape and have listened to our customers’ needs and where expectations have fallen short. The rise of agile methodologies, cloud computing, new techniques, technologies, and architectural styles has given an unprecedented boost to software evolution and the ability to support business needs, so we embraced the new wave and now have growing experience in solving problems with these tools. Along the way, we’ve seen a recurring pattern when we encountered integration problems, the effectiveness of data hubs as components of the enterprise architectures to solve these challenges, so we built one of our own: Joyce. Data hubs This is a relatively new term and refers to software platforms that collect data from different sources with the main purpose of distribution and sharing. Since this definition is broad and vague, let’s add some other key elements that matter and help define the contours of our implementation. Collecting data from different sources can bring three major benefits: Computational decoupling from the sources. Pulling (or pushing) the data out of the originating systems means that client applications and services interact with the hub and not directly with the sources, preventing them from being slowed down by additional traffic. Catalog and discoverability. If data is collected correctly, this leads to the creation of a catalog, allowing people inside the organization to search, discover, and use the data inside the hub. Security. The main purpose of the hubs is distribution and sharing. This leads immediately to focus on access control and security hardening. A single access point simplifies the overall security around the data because it significantly reduces the number of systems the clients have to interact with to gather the data they need. Joyce, how it works The cornerstone concept of Joyce is the schema. It allows you to shape the ingested data and how this data will be made available to client services. Using the same declarative approach made popular by Kubernetes, the schemas describe the expected result and the platform performs the actions to make it happen. Schemas are standard JSON schema files stored and classified in a catalog. Their definition falls into three categories: Input – how to gather and shape the source data. We leverage the Kafka Connect framework to provide ready-made connectors for a wide variety of sources. The ingested data can be filtered, formatted, and enriched with transformation handlers (domain-specific extensions of JSON schema). Model – allows you to create new aggregates from the data stored in the platform. This feature gives the freedom to model the data the way needed by client services. Export – bulk data export capability. Exported data can be any query run against the existing data with an optional temporal filter. Input and model data is made available to all the client services with the proper authorization grants through auto-generated REST and GraphQL APIs. It is also possible to subscribe to a dedicated topic if an event-driven approach is more suitable for the use-case. MongoDB: the key for a flexible model and performance at scale We heavily rely on MongoDB. Thanks to its flexibility, we can easily map any data structure the user defines to collect the data. Half of the schema definition is basically the definition of a MongoDB schema. (We also auto-generate one schema per collection to guarantee data integrity.) Joyce runs in a Kubernetes cluster and all its services are inherently stateless to exploit the full potential of horizontal scaling. The architecture is based on the CQRS pattern. This means that writes and reads are completely decoupled and can scale independently to meet the unique needs of the production environment. MongoDB is also the backing database of the API layer so we can keep the promise of low latency, high throughput, and continuous availability along all the components of the stack. The platform is available as a fully managed PaaS on the three major cloud providers (AWS, Azure, GCP) but if needed, it can be installed on an existing infrastructure (in cloud and on prem). Final considerations There are many challenges leaders must face for a successful digital transformation. They need to guide their organizations along a process that involves changes on many levels. The exponential growth of technological solutions in the last few years adds more complexity and confusion. The evolution of organizational models and methodologies point in the direction of shared responsibility, people empowerment, and autonomous teams with a light and effective central governance. The same evolution also permeates the novel approaches to enterprise architectures like the data mesh. Unfortunately, there’s no silver bullet, just the right choices for the given context. Despite all the marketing and hype around this or that one solution to all of your digital transformation needs, a long term successful shift needs guidance, competence and empowerment. We’ve built Joyce with the aim of reducing the burden of repetitive tasks and boilerplate code to get the results faster and catch the low hanging fruits without trying to replace the necessary architectural thinking to properly define the current state and the evolution of the enterprise architectures of our customers. If you’re struggling with the problems enlisted at the beginning of this article you should give Joyce a try. Learn more about Joyce
FHIR Technology is Driving Healthcare's Digital Revolution
Technology supporting healthcare’s digital transformation is so pervasive that the question isn’t what technology to choose, but rather, what problems need to be solved. Advancing technology and access to secure and real-time data analytics will vastly improve patients’ health and happiness, and growing interoperability standards are pushing organizations forward in their digital transformations. Together with the Healthcare Information and Management Systems Society (HIMSS) and leading healthcare insurance provider Humana , MongoDB recently released a three-part podcast series chronicling the ways Fast Healthcare Interoperability Resources (FHIR), AI, and the cloud are reshaping healthcare for the better. Here’s a quick roundup of our discussions. Data is the future of healthcare . Whether providers are driving patient engagement through wearable devices, wellness programs or connected care, data will take healthcare to the next digital frontier. We’ll see these advancements through AI, FHIR, and the cloud. FHIR is revolutionizing healthcare technology . Not only is FHIR implementation a requirement, it’s also a crossroads for data architects. Choosing the right approach has deep implications for healthcare IT. The operational data layer (ODL) approach to interoperability makes the impossible possible . Through Humana’s digital transformation journey, it became clear that meaningful progress isn’t possible using core legacy database systems. AI, FHIR, and the cloud: Why data is the future of healthcare In this episode , we dive into what a digital transformation would look like for the healthcare industry, and what are some of the biggest technology challenges facing healthcare today. A digitally transformed healthcare industry will weave real-time data analytics with more personalized care. Patients today want a more modern healthcare experience that includes telemedicine, digital forms and touchless mobile check ins. The end goal is simple: maximize the human experience while advancing away from legacy technology systems that slow down both healthcare practitioners and patients. When it comes to today’s biggest healthcare challenges, the cloud stands out as a key driver of promise and peril. The promise is that we can build applications, go to market and reach patients through wellness programs more quickly. The peril lies in the infrastructure, which is unknown to many healthcare organizations. This presents a unique challenge for the architects and certainly the developers at organizations with older legacy systems. The challenge here is avoiding a simple left hand shift or cloud for the sake of cloud, and moving from simple modernization to actual transformation. Listen below to hear the entire conversation Your browser does not support the audio element. Bring the FHIR inside for digital transformation In episode 2 , HIMSS and MongoDB take a closer look at why FHIR is a change agent in healthcare technology, and how healthcare organizations globally are using the new data standard to jump start legacy modernization and digital transformation. What is FHIR? The FHIR standard is a common set of schema definitions and APIs that helps providers and patients manage and exchange healthcare data. Using FHIR, records provided by healthcare organizations are standardized into a common data model over rest-based APIs. It makes the data that healthcare providers and payers use easier to exchange. Growing regulatory pressure has accelerated U.S. FHIR adoption among healthcare organizations and technology vendors.The Centers for Medicare and Medicaid Services (CMS) started a rolling deadline for FHIR compliance in 2020, with fines for institutions that fall behind. As a result, for most U.S.-based healthcare providers, payers, and their technology vendors, the past few years were a headlong race to adopt FHIR. Here are three reasons why FHIR is hugely significant for healthcare technology leaders: It’s a federal mandate from the Centers for Medicare & Medicaid Services. It’s a complex data integration challenge. Legacy systems built before the mid 2010s are not interoperable with the FHIR mandate. FHIR implementation approaches For large organizations with huge data requirements, data architects can experience paralysis from the sheer volume of legacy systems to unwind. These groups have all of their patients’ electronic healthcare record information, payer information and more bound up in legacy systems, none of which is interoperable with FHIR. The second challenge is cloud migration, which can be skirted by organizations using a checkbox compliance approach. In those cases, API layers are used to ingest and serve data to legacy systems, but are not really integrated with the legacy system in real time. The most successful approach to tackling this challenge is not to rewrite, unwind or replace legacy systems completely, but keep them contained. We recommend bringing in an operational data layer that exposes the information in the legacy system and keeps it in sync with the legacy system, but then lands it in an ODL in the FHIR standard. With the FHIR API, patients and providers can interact with data in real time and access records in milliseconds after a diagnosis. Real-time records synced with legacy systems and patients’ private data is protected. Delve into the full conversation below Your browser does not support the audio element. FHIR and the future of healthcare at Humana You don't have to take the rip and replace approach when modernizing your legacy systems with an ODL method. This was a key to successful modernization for Humana, as discussed in the third and final episode in our series. For large enterprises that may have decades’ worth of acquired legacy systems, often pulling similar datasets from disparate databases, the pursuit of modernized interoperability begins to look like an impossible task. Listen to the final episode of our podcast series to here how Humana’s ODL approach met the company’s data velocity requirements, and next steps for personalized healthcare and interoperability at Humana. Listen to the entire conversation below Your browser does not support the audio element. More related FHIR and healthcare resources [ White paper ] Bring the FHIR Inside: Digital Transformation Without the Rip and Replace [ On-demand webinar ] Building FHIR Applications with MongoDB
Corporate Sales at MongoDB: Meet the Reps
MongoDB Corporate Account Executives sell into some of the world's highest growth and IT-focused companies, with a goal of securing net new logos in organizations of up to 1500 employees. They drive and build solutions that serve the best interest of our customers to help them innovate faster than ever before, often working directly with CTOs, Engineering/IT leaders, and technical end users. A majority of our Corporate Sales team sits in Austin, Texas, with other reps and leaders spread across the U.S. Meet three Corporate Account Executives to learn about their experience in the role and why our Corporate Sales org is a great place to grow your career. Sebastian Cañizares , Sr. Corporate Account Executive, Austin I joined MongoDB as a Cloud Account Executive back in 2019 to build a career. Not knowing it at the time, I felt I had reached a personal sales career plateau. I wanted a challenge in an industry that was vastly different from what I was accustomed to, with a sales process that could help me create a strong foundation. MongoDB sold me on three things: The “Sales MBA” : I didn't know of any other company investing as much time and resources on an individual as MongoDB was. A sales team with a formalized sales process and a full-fledged sales enablement team caught my eye. Leadership : The leaders at MongoDB come from diverse backgrounds. Going through the interview process I spoke with multiple leaders that challenged me intellectually and at the same time were so selfless. I was leaning in further. Market opportunity : At the time, MongoDB was a tiny piece of a growing database pie. Noticing the trends in the market, I wanted to be a part of a company that was positively influencing how technology was being made. Data was at the crux of it all, and MongoDB was challenging a legacy mindset while at the same time establishing incredible groundswell among its core community: developers. Now it was a matter of capitalizing on it and MongoDB was. I was fully bought in. I’m so glad I joined MongoDB back then, and truly believe it was a career altering decision. After nine months in the Cloud role, I transitioned to a Corporate Account Executive. If you haven’t read about our BDR to CRO program , the transition from Cloud to Corporate was one of the first internal sales promotion tracks that the Corporate Sales org built out. There was a promotion path in place with clear guidelines on what was needed to not only reach the next step but also excel in it. During the transition, I had the benefit of following reps that had gone through the process before me and were successful in that next role. They never hesitated in offering their time, helped whenever anyone asked, and created an environment that was both collaborative and positive. Additionally, the leadership team challenged me every step of the way. I was developed in the Cloud role by a former sales rep (who became my manager) who enabled me with the information and knowledge to foundationally succeed at MongoDB. He invested time and resources, and I’ll be forever grateful for the opportunity he prepared me for. Not only that, I had support from other leaders that wanted to see me succeed. They met with me on a regular basis, mentored me, and helped me gain a footing in the Corporate role. MongoDB’s leadership fosters a merit-based culture all while supporting you along the way. I experienced that in my transition from Cloud to Corporate and still see it in my current role today. It is rare that a company holds up to the things they say during the recruiting process, let alone over-deliver. MongoDB has done just that. I’ve been able to grow my sales career while also getting to talk to people daily that are creating things that are changing the way we interact with technology. It’s the perfect blend of career opportunity, intellectual curiosity, and enablement that I don’t believe I could get anywhere else. Now, why should someone join the Corporate Sales team? You get to witness a company that is fundamentally changing the status quo at the highest level You receive an enormous investment in sales enablement You collaborate with a team that is hungry, competitive, and best in class You work for an established company that is constantly innovating and growing You learn from some of the best sales leaders out there You grow your career at a company that values meritocracy and promotes from within You get to help build history Paige Springfield , Sr. Corporate Account Executive, Austin I took a leap and joined MongoDB in April 2020. When evaluating the opportunity, I had three top criteria. Market opportunity : MongoDB is a leader in the database industry and we’re just getting started. The product is best-in-class and mission critical to customers across all industries - this means uncapped opportunity and earning potential. The team : It was extremely important to me to be surrounded by colleagues who would uplevel and challenge me. Growth and development potential : MongoDB (especially the Corporate Sales org) is just getting started. We’re positioned to grow exponentially in the next two years and the number one focus across the leadership team is people development and promoting from within. At previous companies, I never felt invested in from a sales enablement perspective. Ramping typically meant a couple 1-hour training sessions and then it was off to the races. Here at MongoDB, I was blown away by the onboarding and training process from day one. I’d compare the experience to getting your MBA in sales. I think it speaks to leadership’s commitment to invest in people, their development, and ultimately their long term success. Our Sales Enablement team set me up with all the tools I needed to master the complex technology and a repeatable sales process. I’ve been on the team for a year and a half and seen a ton of success. Recently, I was promoted to a senior-level sales role and accepted into leadership upskill as part of our BDR to CRO program. Working at MongoDB has been the most transformative, rewarding time in my career. If you’re looking to uplevel yourself (both professionally and personally), the Corporate Account Executive role is an incredible opportunity. Drew Oros , Corporate Account Executive, New York City I joined MongoDB for three key reasons. Professional Development : My long-term goal is to become a professional executive for pre-IPO tech companies. I see a tremendous opportunity to build that expertise in the cloud infrastructure/services space. I know to get there, I need a great story selling technology that’s mission critical and best in class - that’s without a question MongoDB, and it has given me a great opportunity to start writing that story. Leadership and people : It was important to me to be around leaders and sellers I feel I could learn from, as I'm a firm believer that your network is equal to your net worth. At MongoDB, I feel like I’m surrounded by current and future household names in the software industry. Product and market opportunity : I only want to sell best in class, mission critical technology. It also has to be the right timing, and have a huge, total addressable market, and strong go-to-market motion. I knew if I found that, magic would happen. MongoDB is the most downloaded NoSQL database , and it fits a wide variety of use cases for mission critical applications. The TAM is estimated to be $82 billion by 2022 , and MongoDB’s sales org and process are key differentiators. Ramping into the Corporate Account Executive role can be challenging, however, you are amongst some of the best people in the software industry to learn from. I identified the skills that were key to becoming a great seller and met with three to five of the top reps to learn how they created a pattern of success in each of those areas. Ultimately, I identified pipeline generation best practices, meeting preparation, discovery calls, New Business Meeting excellence, champion building, and paper process as the key skills fundamental to creating, moving, and closing pipeline. “Build together” is one of MongoDB’s core values and a big reason why colleagues are so open to sharing what makes them successful. If you put in the time and effort, there’s no shortage of resources to learn from here. Overall, this year has been a great success story for me as I’m 200%+ of my yearly number and won the Most New Logos award in Q3. We believe in a culture of promotion - internal promotions are core to MongoDB’s culture and strategic to how the company scales. MongoDB does not get in the way of your personal growth, but rather accelerates it. The BDR to CRO program lays out what good versus great looks like and what you need to do in order to move farther down that path. Whatever your career goals are, MongoDB is a company that supports your interests and provides the investment to help get you there. Interested in pursuing a career in Corporate Sales at MongoDB? We have several open roles on our teams across the globe and would love for you to transform your career with us!
Introducing Pay as You Go MongoDB Atlas on AWS Marketplace
We’re excited to introduce a new way of paying for MongoDB Atlas . AWS customers can now pay Atlas charges via our new AWS Marketplace listing . Through this listing, individual developers can enjoy a simplified payment experience via their AWS accounts, while enterprises now have another way to procure MongoDB in addition to privately negotiated offers, already supported via AWS Marketplace. Previously, customers who wanted to pay via AWS Marketplace had to commit to a certain level of usage upfront. Pay as you go is available directly in Atlas via credit card, PayPal, and invoice — but not in AWS Marketplace, until today. With this new listing and integration, you can pay via AWS with no upfront commitments . Simply subscribe via AWS Marketplace and start using Atlas. You can get started for free with Atlas’s free-forever tier , then scale as needed. You’ll be charged in AWS only for the resources you use in Atlas, with no payment minimum. Deploy, scale, and tear down resources in Atlas as needed; you’ll pay just for the hours that you’re using them. Atlas comes with a Basic Support Plan via in-app chat. If you want to upgrade to another Atlas support plan , you can do so in Atlas. Usage and support costs will be billed together to your AWS account daily. If you’re connecting Atlas to applications running in AWS, or integrating with other AWS services , you’ll be able to see all your costs in one place in your AWS account. To get started with Atlas via AWS Marketplace, visit our Marketplace listing and subscribe using your account. You’ll then be prompted to either sign in to your existing Atlas account or sign up for a new Atlas account . Try MongoDB Atlas for Free Today!
10 Signs Your Data Architecture is Limiting Your Innovation: Part 2
With the massive amounts of data organizations now ingest, store, and analyze comes a massive responsibility to monitor, manage, and protect it. Unfortunately, many businesses are functioning with little insight into how their data is stored and who is accessing it — and their overly complex data architecture can turn those challenges into Frail security can lead to unnecessary risk, and if you are not in control of your data architecture, the next big compliance offender or data breach victim could be you. These risks — and the time and resources required to address them — make up part of a hidden tax on your innovation. We call it DIRT — the Data & Innovation Recurring Tax . Our experts have identified 10 symptoms that can indicate your business is paying DIRT — read about them all in our white paper 10 Signs Your Data Infrastructure is Holding You Back , and check out Part 1 of this blog series. Here, we highlight two signs of this innovation tax that are all about security. Symptom #3: That last big data breach — or the next one — is on you The more complex your data architecture, the more threat vectors you need to cover and the more complicated and time-consuming it becomes to maintain security. Each data store and application may have its own security framework and requirements — its own access controls, role definition, and login procedures. Each database may in turn be connected with multiple other technologies and vendors, further adding to the time and complexity needed to keep everything secure. That’s a drag on your team: Some 30% of IT managers spend more than 16 hours a month just on patching, and 14% spend more than 48 hours a month. Often, it’s impossible to keep up: 42% of breaches are the result of an attack for which a patch was available but not applied, according to a Ponemon Institute study of IT professionals. On average, 28% of vulnerabilities remain unaddressed. Our Solution: With an application data platform, you have one set of database and data service components that share the same developer experience and the same underlying operational and security characteristics, making it a lot easier to defend. Organizations can use a single overarching security policy and implementation without having to reinvent the wheel every time someone has a new use case for the data. Maintaining audit logs and access is dramatically streamlined. You get both security and speed. Symptom #4: Rampant data duplication makes compliance a nightmare In a modern organization, every part of the business should have access to the data and insights that help optimize performance and meet customer demand. But most data is trapped in silos, each with its own formats, access, and authorization controls. Attempts to address data silo issues often create their own web of separate niche data technologies, each trying to solve the problem. That can create a lot of data duplication — so even your IT leaders may not know who has copies of which data, or even how many copies there may be. That’s obviously a problem for security reasons. It also makes it extremely difficult to comply with regulations such as GDPR and the California Consumer Privacy Act, or to respond effectively to audits. How can you tell your regulators exactly where personally identifying information sits, or where it has been, when you don’t even know how many copies exist? Our Solution: Eliminate silos in the first place by using an application data platform, which addresses many of the use cases that would otherwise spur teams to duplicate data. And, with MongoDB, you can federate queries across multiple sources so you don’t have to move data into different formats. Our next installment will focus on your developers’ time, how it’s spent and the price you pay when they can’t find the time to develop and roll out best-in-class features. For a complete view of DIRT, read our white paper DIRT and the High Cost of Complexity .
MongoDB x Screaming in the Cloud: A Discussion
Held in Las Vegas every winter, AWS re:Invent features booths and exciting new demos from the biggest names in tech; a slate of fun, engaging activities; and inspirational keynotes by thought leaders and pioneers. Along with being one of today’s top tech expos, re:Invent is also the ideal venue for thinkers to meet and exchange ideas. At this year’s conference, Sahir Azam, Chief Product Officer at MongoDB, sat down with Corey Quinn, Chief Cloud Economist at Duckbill Group (and one of the most interesting men in tech), for a deep, wide-ranging conversation. Their chat covers everything from the state of databases today to the true definition of an application data platform. Read on for some highlights and listen to the episode here . How is MongoDB adapting to the cloud? Corey kicks off the talk with a big-picture question: How has MongoDB, a mainstay in the database world, evolved to match the rapidly changing demands of the market? Given the rapid proliferation of databases and related technologies, this question is especially timely. “What do you do these days?” Corey asks. “What is MongoDB in this ecosystem?” “Today, MongoDB has become one of the leading cloud database companies in the world,” Sahir replies. “The majority of [our] business comes from our cloud service. That’s our flagship product.” One database to rule them all? “[That] leads to the obvious question,” Corey continues. “What’s your take on the whole idea of a different database for every problem/customer/employee/API request?” “[Many] customers clearly moved to the cloud because they want to be able to move faster, innovate faster, be more competitive,” Sahir replies. Although it’s impossible for a single database vendor to address every customer need, Sahir also mentions that “cobbling together 15 different databases” forces teams to focus on troubleshooting instead of innovation. Instead, Sahir points out, the ideal database would fit “80% of [an organization’s] use cases, with niche technologies serving as specialized solutions for particular needs.” What is the nature of MongoDB's relationship with AWS? “You mentioned that you are a partner with AWS,” Corey asks. “But how do you address the idea of partnering with a company that also heavily advantages its own first-party services?” Sahir’s reply — that MongoDB has a complex, multifaceted relationship with AWS but not an adversarial one — cites the two companies’ mutual interests and partnerships. “The idea of working with major platform players...being a customer, a partner, and a competitor is something that any organization at our scale and size [has to] navigate,” Sahir explains. “Honestly, there’s a lot more collaboration, both on the engineering side and in the field. We jointly work with customers and get them onto our platform way more often than the world sees.” And much more... Corey and Sahir’s discussion also covers how international customers use MongoDB, how potential users and customers perceive MongoDB, and what’s in store for future MongoDB products. Check out the full podcast!
MongoDB is One of Battery Ventures' 25 Highest-Rated Public Cloud Computing Companies to Work For
Crain's recently recognized MongoDB as one of the best places to work in New York City. Today, Battery Ventures announced that MongoDB is also one of the best places to work in the cloud; specifically, Battery named us one of the " 25 Highest-Rated Public Cloud Computing Companies to Work For ." Battery compiles the list based on Glassdoor ratings and reviews left by employees. In other words, MongoDB's inclusion in the recognition depends upon current and past employees rating MongoDB highly. This makes sense to me, as I fit into both camps. I worked for MongoDB from 2013 to 2014, and loved it. I recently returned, and continue to find it the best place I've ever worked. Apparently I'm not alone in loving MongoDB. Indeed, in addition to this most recent honor from Battery, MongoDB also ranks high on Inc.'s " best led" and "best workplaces " lists, not to mention BuiltIn's " 100 Best Large Companies to Work For ." Why do people love working for MongoDB? For me, it's a combination of great people and great products. When I joined MongoDB back in 2013, it was because of its fresh, open approach to data. MongoDB was so approachable, so easy to use. Developers adored it and quickly became productive with it, making MongoDB one of the most popular databases on the planet. Since that time, MongoDB has added things like full-text search, data visualization, and more, making it the industry's leading application data platform. Which is cool, but incomplete. As much as I love to work for a market leader, it's the people of MongoDB that make it a near-perfect employer. Many of the people I loved to work with back in 2013 are still here, and they've been joined by other outstanding, humble people. MongoDB really is the perfect confluence of great technology and great people. Here is what a few of my MongoDB colleagues shared as to their reasons for working here. Annie Dane, Strategic Account Marketing MongoDB is an incredible place to build your career with a tremendous amount of support to do so, including a Learning and Development team that provides a multitude of training opportunities. Additionally, people at MongoDB really care about each other: we encourage a healthy work/life balance and new parents (and their babies) are very welcome at MongoDB, as evidenced during Covid. Mat Keep, Product Marketing Every organization’s success is now defined by software, and that software’s success is defined by data. MongoDB eliminates many constraints developers have faced working with data, which makes it such an exciting place to work as I get to help customers build new applications and modernize existing ones. At MongoDB we get to help address some of today's toughest challenges and most interesting initiatives shaping our world. Angie Byron, Community Management MongoDB is filled with humble, wicked-smart people who make a concerted effort to lift each other up. These traits hold true across departments, across org chart levels, and across levels of technical depth. Additionally, as a queer person, I've never been part of a company that takes diversity and inclusion so seriously and backs it up with real action. Just in the last few months, we've had a panel to talk together about our coming out experiences, trans-specific programming with amazing guest speakers, and more. At MongoDB, we are passionate about our mission of freeing the genius within everyone by making data stunningly easy to work with. We'd love to have you be part of our team. Interested in joining MongoDB? We have several open roles on our teams across the globe and would love for you to transform your career with us!
Ready to get Started with MongoDB Atlas?
Start FreeThat page could not be found.