2056 results

A Hub for Eco-Positivity

In this guest blog post, Natalia Goncharova, founder and web developer for EcoHub — an online platform where people can search for and connect with more than 13,000 companies, NGOs, and governmental agencies across 200-plus countries — describes how the company uses MongoDB to generate momentum around global environmental change. There is no denying that sustainability has become a global concern. In fact, the topic has gone mainstream. A 2021 report by the Economist Intelligence Unit (EIU) shows a 71% rise in the popularity of searches for sustainable goods over the past five years. The report “measures engagement, awareness and action for nature in 27 languages, across 54 countries, covering 80% of the world’s population.” The EIU report states that the sustainability trend is accelerating in developing and emerging countries including Ecuador and Indonesia. For me, it’s not a lack of positive sentiment that is holding back change; it is our ability to turn ideas and goodwill into action. We need a way of harnessing this collective sentiment. In 2020, the decision to found EcoHub and devote so much time to it was a difficult one to make. I had just been promoted to team leader at work, and things were going well. Leaving my job with the goal of helping to protect our environment sounded ridiculous at times. Many questions raced through my mind, the most insistent one being: Will I be able to actually make a difference? However, as you’ll see in this post, my decision was ultimately quite clear. What is EcoHub? When I created EcoHub, my principal aim was to connect ecological NGOs and businesses. Now, EcoHub enables users to search a database of more than 10,000 organizations in more than 200 countries. You can search via a map or keyword. By making it easier to connect, EcoHub lets users quickly build networks of sustainably minded organizations. We believe networks are key to spreading good ideas, stripping out duplication, and building expertise. Building the platform has been a monumental task. I have developed it myself over the past few months, acting as product manager, project manager, and full-stack developer. (It wouldn’t be possible without my research, design, and media teams as well.) During the development of the EcoHub platform on MongoDB, the flexible schema helped us edit and add new fields in a document because the process doesn’t require defining data types. We had a situation in which it was necessary to change the schema and implement changes for all documents in the database. In this case, modifying the entire collection with MongoDB didn’t take long for an experienced developer. Additionally, MongoDB’s document-oriented data model works well with the way developers think. The model reflects how we see the objects in the codebase and makes the process easier. In my experience, the best resource to find answers when I ran into a question or issue was MongoDB documentation . It provides a good explanation of almost anything you want to do in your database. Search is everything In technical terms, my choices were ReactJS, NodeJS, and MongoDB. It is the latter that is so important to the effectiveness of the EcoHub platform. Search is everything. The easier we can make it for individuals or organizations to find like minds, the better. I knew from the start that I’d need a cloud-based database with strong querying abilities. As an experienced developer, I had previous experience with MongoDB and knew the company to be reliable, with excellent documentation and a really strong community of developers. It was a clear choice from the start. Choosing our partners carefully is also important. If EcoHub is to build awareness of environmental issues and foster collaboration, then we must ensure we make intelligent choices in terms of the companies we work with. I have been impressed with MongoDB’s sustainability commitments , particularly around diversity and inclusion, carbon reduction, and its appetite for exploring the way the business has an impact globally and locally. EcoHub search is built on the community version of MongoDB , which enables us to work quickly, implement easily and deliver the right performance. Importantly, as EcoHub grows and develops, MongoDB also allows us to make changes on the fly. As environmental concerns continue to grow, our database will expand. MongoDB enables our users to search, discover, and connect with environmental organizations all over the world. I believe these connections are key to sharing knowledge and expertise and helping local citizens coordinate their sustainability efforts. Commitment to sustainability When it came down to it, the decision to build EcoHub wasn’t as difficult as I initially thought. My commitment to sustainability actually started when I was young: I can remember myself at 8 years old, glued to the window, waiting for the monthly Greenpeace magazine to arrive. Later, that commitment grew as I went to university and graduated with a degree in Environmental Protection and Engineering. Soon after, I founded my first ecology organization and rallied our cityagainst businesses wanting to cut down our beautiful city parks. Starting EcoHub was a natural and exciting next step, despite the risks and unknown factors. I hope we can all join hands to create a sustainable future for ourselves, our children, and our animals and plants, and keep our planet beautiful and healthy. MongoDB Atlas makes operating MongoDB a snap at any scale. Determine the costs and benefits with our cost calculator .

May 11, 2022

Shared Responsibility: More Agility, Less Risk

The tension between agility, security, and operational uptime can keep IT organizations from innovating as fast as they’d like. On one side, application developers want to move fast and continually deliver innovative new releases. On the other side, InfoSec and IT operations teams aim to continually reduce risk, which can result in a slowed down process. This perception couldn’t be further from the truth. Modern InfoSec and IT operations are evolving into SecOps and DevOps, and the idea that they want to stop developers from innovating by restricting them to old, centrally controlled paradigms is a long-held prejudice that needs to be resolved. What security and site reliability teams really want is for developers to operate with agility as well as safety so that risks are appropriately governed. The shared responsibility model can reduce risk while still allowing for innovation. The challenge of how to enable developers to move fast while ensuring the level of security necessary for SecOps and DevOps is to abstract granular controls away from developers so they can focus on building applications while, in the background, secure defaults that cannot be disabled are in place at every level. Doers get more done Working with a cloud provider, whether you’re talking about infrastructure as a service (IaaS) or a hyperscaler, is like going into a home improvement store and seeing all the tools and materials. It gives you a sense of empowerment. That’s the same feeling you get when you’re in front of an administrative console for AWS, Google Cloud, or Azure. The aisles at home improvement stores, however, can contain some pretty raw materials. Imagine asking a team of developers to build a new, state-of-the-art kitchen out of lumber, pipes, and fittings without even a blueprint. You’re going to wind up with pipes that leak, drawers that don’t close, and cabinets that don’t fit. This approach understandably worries InfoSec and IT operations teams and can cause them to be perceived as innovation blockers because they don’t want developers attempting do-it-yourself security. So how do you find a place where the raw materials provide exactly what you need so that you can build with confidence? That’s the best of both worlds. Developers can move faster by not having to deal with the plumbing, and InfoSec and IT operations get the security and reliability assurance they need. This is where the shared responsibility model comes in. Shared responsibility in the cloud When considering cloud security and resilience, some responsibilities fall clearly on the business. Others fall on public cloud providers, and still others fall on the vendors of the cloud services being used. This is known as the shared responsibility model. Security and resilience in the cloud are only possible when everyone is clear on their roles and responsibilities. Shared responsibility recognizes that cloud vendors, such as MongoDB, must ensure the security and availability of their services and infrastructure, and customers must also take appropriate steps to protect the data they keep in the cloud. The security defaults in MongoDB Atlas enable developers to be agile while also reducing risk. Atlas gives developers the necessary building blocks to move fast without having to worry about the minutiae of administrative security tasks. Atlas enforces strict security policies for things like authentication and network isolation, and it provides tools for ensuring secure best practices, such as encryption, database access, auto-scaling, and granular auditing. Testing for resilience The shared responsibility model attempts to strike a balance between agility, security, and resilience. Cloud vendors must meet the responsibilities of their service-level agreements (SLAs), but businesses also have to be conscientious of their cloud resources. Real-world scenarios can cause businesses to experience outages, and avoiding them is the essence of the shared responsibility model. To avoid such outages, MongoDB Atlas does everything possible to keep database clusters continuously available; the customer holds the responsibility of provisioning appropriately sized workloads. That can be an uphill battle when you’re talking about an intensive workload for which the cluster is undersized. Consider a typical laptop as an example. It has an SLA in so far as it has specifications that determine what it can do. If you try to drive a workload that exceeds the laptop’s specifications, it will freeze. Was the laptop to blame, or was it the workload? With the cloud, there’s an even greater expectation that there are more than enough resources to handle any given workload. But those resources are based on real infrastructure with specs, just like the laptop. This example illustrates both the essence and the ambiguity of the shared responsibility model. As the customer, you’re supposed to know whether that stream of data is something your compute resources can handle. The challenge is that you don’t know it until you start running into the boundaries of your resources, and pushing the limits of those boundaries means risking the availability of those resources. It’s not hard to imagine a developer, who may be working under considerable stress, over-provisioning a workload, which then leads to a freeze or outage. It’s essential, therefore, for companies to have a test environment that closely mimics their production environment. This allows them to validate that the MongoDB Atlas cluster can keep up with what they’re throwing at it. Anytime companies make changes to their applications, there is a risk. Some of that risk may be mitigated by things like auto-scaling and elasticity, but the level of protection they afford is limited. Having a test environment can help companies better predict the outcome of changes they make. The cloud has evolved to a point where security, resilience, and agility can peacefully coexist. MongoDB Atlas comes with strict security policies right out of the box. It offers automated infrastructure provisioning, default security features, database setup, maintenance, and version upgrades so that developers can shift their focus from administrative tasks to innovation when building applications. By abstracting away some of the security and resilience responsibilities through the shared responsibility model, MongoDB Atlas allows developers to move fast while giving SecOps the reassurances they need to support their efforts.

May 11, 2022

Survey of 2,000 IT Professionals Reveals the Importance of Innovation, and Its Challenges

We all know that innovation is hard. Yet innovation is high on the strategic agendas of most organizations, partly because there is no choice. Highly innovative organizations are more successful across a number of measures, including profitability. Increasingly, that innovation must be delivered through software. Early in the digital age, just using software was enough to set a company apart. But today, off-the-shelf software (or off-the-shelf cloud services) doesn’t provide a lasting competitive advantage, because your competitors have access to the exact same software and services. It’s up to internal teams to build the innovations that set organizations apart. The 2022 MongoDB Report on Data and Innovation surveyed 2,000 developers and IT decision-makers in the Asia Pacific region, covering Australia, China, Hong Kong, India, New Zealand, South Korea, and Taiwan. The report details our findings on the importance of innovation, the technical challenges to building new things, and the consequences when you fail to do so. Some of the important discoveries we uncovered are: Fully 73% of respondents agreed that working with data is the hardest part of building and evolving applications. 55% say their data architectures are complex. In fact, 38% of organizations surveyed use 10+ databases. 28% of developers’ time is spent building new features or applications, versus 27% maintaining existing data, applications, and systems. Top blockers of innovation include developer workloads, data architecture, legacy technologies and technical debt To unlock all our findings and understand more about the need for an increased attention on innovation, download the full report .

May 9, 2022

Semeris Demystifies Legal Documents Using MongoDB

Sorting through endless legal documents can be a time-consuming and burdensome process, but one startup says it doesn’t have to be that way. Semeris strives to demystify legal documentation by using the latest artificial intelligence and natural language processing techniques. Semeris’s goal is to put the information its customers need at their fingertips when and where they need it. Semeris aims to bring structure to capital market legal documents, while providing a first-class service to customers and blending together the disciplines of finance, law, natural language processing, and artificial intelligence. In this edition of Built with MongoDB, we talk with Semeris about how they use MongoDB Atlas Search to help customers analyze documents and extract data as quickly as possible. Built with MongoDB spoke with Semeris CEO, Peter Jasko , about his vision for the company, working with MongoDB, the company’s relationship with venture capital firm QVentures , and the value of data. In this video, Peter Jasko explains how MongoDB Atlas's fully managed service and support has been a key factor in helping Semeris scale. Built with MongoDB: Can you tell us about Semeris? Peter Jasko: We help our investor banking and lawyer clients analyze legal documentation. We help them extract information from the documentation that they look at. A typical transaction might have 500 to 1,000 pages of documentation, and we help them to analyze that really quickly and pull out the key information that they need to be able to review that documentation within a couple hours, rather than the 7 or 8 hours it would normally take. Built with MongoDB: What is the value of data in your space? Peter: Data is essential in what we do because we build models around the publicly available documentation that we see. We store that data, we analyze it, we build machine learning models around it, and then we use that to analyze less seen documentation or more private documentation that our clients have internally. Built with MongoDB: How has your partnership with QVentures helped Semeris? Peter: Our partnership with QVentures is not just a financial one where they’ve invested some money into our firm; they’ve also helped us uncover contacts within the market. They introduced us to the MongoDB partnership that has helped us get some credits and build out our technology onto the MongoDB platform. Built with MongoDB: What has it been like using MongoDB’s technology? Peter: We chose MongoDB because it’s a scalable solution, and it has a strong developer following. It’s easier for us to hire tech developers who understand the technology because MongoDB has such a strong following in the community. If we have small issues with the technology, we’re very quickly able to search and find the answer to learn how we need to resolve that. Additionally, scalability is really important to us. And, what we found is that the MongoDB platform scales both in compute and also in storage seamlessly. We get a notification that more storage is required, and we can upgrade that online and with no customer impact and no downtime. It's really, really seamless. Another reason we chose MongoDB is that it’s cloud agnostic. We're on AWS now, but we're almost certainly at some point going to be asked from customers to look at Azure or Google. So it's really beneficial to us that MongoDB works on all the different platforms that we look at. Built with MongoDB: What are some of the features you use within MongoDB? Peter: We use MongoDB Atlas Search because of its ability to retrieve thousands of data points from multiple documents. We use the indexing capability there, and the key thing that we find is that our customers want to retrieve thousands of data points from multiple different documents. A lot of our customers are analysts or investment portfolio managers, and they want that information in their hands as quickly as possible. Built with MongoDB: What is some advice you’d give to aspiring founders and CEOs? Peter: Try lots of things and try them quickly. Try lots of little spikes, and take the ones that work well, and eventually put those into production. Really focus on what your customers want. Ultimately, we tried a lot of different ideas, some of which we thought were great. But you have to put it in front of your customers to be able to decide which ones are really worth spending time on and putting into production quality and which ones you should just let fall by the wayside as research done but not ultimately used. Find out more about Semeris Docs . Interested in learning more about MongoDB for Startups? Check out our Startups page .

May 4, 2022

From Enterprise Account Executive to Regional Director: How Lucile Tournier Has Accelerated Her Career with MongoDB France

Lucile Tournier joined MongoDB France as an Enterprise Account Executive in 2020. From learning new technology to becoming a new mom and taking on a leadership role, Lucile has had an incredible journey over the past two years. In this article, I talk with Lucile to learn more about her experience on the Enterprise Sales team in France and how she has grown her career to become a Regional Director at MongoDB. Click here to read this blog post in French . Jackie Denner: Hi, Lucile. Thank you for sharing a bit about your career journey. How did you come to join MongoDB, and why were you interested in the company? Lucile Tournier: MongoDB is my first experience working in the software industry. My previous roles were with French services companies, where I had very different experiences in terms of sales cycles, corporate culture (MongoDB being an American company), and even technicality (databases — the only stack I had never discussed). I was certainly in my comfort zone in my previous positions. I said to myself, “If I am looking for a new challenge, why not try the software industry? Is it for me? Is it possible to switch from a services company to a software vendor?” I decided to contact Alexandre Esculier , Regional VP of France for MongoDB (at the time Regional Director) who experienced such a shift. Who better than him to answer my questions? After many discussions with him and other members of the MongoDB team in France, I was convinced and decided to go through the recruitment process. You might wonder why I chose MongoDB in particular. Three years ago, I co-founded a market finance startup within a services company. It was an exciting experience, in a fast lane, and full of challenges and great successes. I liked the “speed boat” aspect (fast and adaptable) within an established company. For my next chapter, I wanted to join a company that was fast-paced and innovative. I really found the best of both worlds at MongoDB: An established company with clear processes and disruptive technology, all while having a startup spirit with hypergrowth and agility. I made the right decision. JD: Tell me a bit about your experience in the Enterprise Account Executive role. LT: Like a roller coaster. Throughout six months of intensive onboarding, I was able to quickly go into the field alongside very valuable teams: My manager, Solutions Architects, Customer Success, and Partner teams (to name a few). I started to improve my skills, sign my first contracts with major accounts who trusted me (just like my management), open up new territories, and expand existing ones. I learned a lot about the technology, the sales process (based on MEDDIC, co-built by John McMahon, who is a member of the MongoDB board), and especially about myself thanks to a feedback culture that is at the very heart of MongoDB. Learning about yourself is not so easy. It requires being able to question yourself every single day, but what a great opportunity to grow. JD: What makes enterprise sales at MongoDB a unique career opportunity? LT: It is unique on several levels: The technology, the processes, the fast pace, the results of the company, and the people! Everything is amazing. What I particularly remember is the benevolence. During my first year at MongoDB, I had the immense joy of becoming the mother of a little boy, Dorian. Starting a new job and becoming pregnant in the process is not quite what I had planned. I am grateful that the leadership team was open-minded, supportive, and more than happy for me. I was able to successfully carry out my two great journeys: Performing at MongoDB and becoming a mom. I don't think it could have gone better anywhere else. JD: You were promoted from Enterprise Account Executive to Regional Director. What learning and development opportunities helped you achieve this, and how did sales leadership support your transition? LT: If I hadn't had the trust and support of my entire line management, this transition would have been very difficult, if not impossible. I already had a team management role at my previous company. However, it was important for me, as for MongoDB, to go back to the field before returning to a team management position. Coming from a completely different world, how would I have been able to properly guide a team without going through the field first? So, I honed my skills, I proved I was 100% committed, I listened as much as possible to the feedback I was given; I tried; I lost; I won. I did things differently, and I started again and again. In summary, I had confidence in my environment, and I was able to give my all while being well guided. I had regular development sessions, training, and, above all, an attentive ear from Alexandre Esculier and Jérôme Delozière, VP for continental Europe, who helped me to be self-aware and ask myself the right questions. After 18 months as an Enterprise Account Executive, I successfully transitioned to a Regional Director role managing five Enterprise Account Executives. JD: What is most exciting about being part of the Enterprise Sales team at MongoDB? LT: Everything! First, MongoDB’s technology is amazing. It is important to emphasize this, because it is impossible for me to work for a company where customers are not happy with our products. I want to be able to believe in what I am selling, and I believe in it. The R&D teams are always looking for the latest developments that allow us to be 5 years ahead of the market. Additionally, selling through the MEDDIC methodology has taught me a lot. I had the art and MongoDB gave me the science. Even after 10 years of sales, I keep learning. Most importantly, the people! Everyone is trying to be the best version of themselves and one of the builders of this great adventure. It's really nice to work with so much emulation. JD: What is our Sales team culture like? LT: To describe it in one word: Transparent. In transparency we can progress. We have to share with each other, help each other, point out our weaknesses, and listen. The same goes with customers. Transparency is the key. JD: What skills and qualities make someone successful on the Enterprise Sales team? LT: I think success comes from hard work. Nothing comes ready-made in this environment and there is no relying on luck. You have to work, learn, question yourself, and move things forward. Luck comes later. JD: Is there anything else that you think someone should know about our Enterprise Sales team in France? LT: I'm hiring, so do not hesitate to reach out to me via LinkedIn ! Interested in joining MongoDB’s Sales team? We have several open roles across the globe and would love for you to transform your career with us!

May 3, 2022

How MongoDB Could Have Changed Star Wars and Saved the Jedi

May the 4th be with you! Here at MongoDB, lots of us love Star Wars. It got us thinking about how the events that unfolded throughout the movie franchises could have been different had MongoDB products and features been available. So to celebrate Star Wars Day, this article will take a light(side)-hearted look at exactly that! MongoDB Atlas: How has nobody heard of the Jedi? One of the questions that was asked a lot by fans when Star Wars: Episode VII – The Force Awakens was released was how Rey, Finn, and many others in the Star Wars universe didn’t know that the Jedi were real, let alone still existed. This can be explained by Emperor Palpatine ensuring that all Jedi Knights, temples, and traces of the Jedi were erased. But what if this information had been stored in MongoDB Atlas , our application data platform in the cloud? One of the core features of MongoDB Atlas is a document database-as-a-service (DBaaS), which allows for storing data as JSON-like documents in collections in the cloud, accessible from anywhere with a connection to the internet. Under the hood, this database supports high availability using replica sets , which are sets of nodes (the minimum and default value is three nodes), with one acting as the primary node and two or more as secondary nodes. The data is replicated across these three nodes, with availability handled by Atlas automatically. If the primary node goes down, the replica sets promote a secondary node to primary. Imagine if, following Emperor Palpatine and Darth Vader destroying evidence of the Jedi Order, the data could have recovered itself thanks to the high availability of clusters on Atlas. Atlas cloud recovery would have also helped prevent deleting of data in the Jedi Archives. In Star Wars: Episode II – Attack of the Clones , Obi Wan-Kenobi visits the Jedi Archives on Coruscant to locate the planet Kamino, where they expect to find answers on who attempted to assassinate Senator Padmé Amidala. However, Obi Wan-Kenobi finds himself having to call for the help of the librarian, Jocasta Nu, because he cannot find any traces of the planet in the archives. She famously says that if the planet is not in the archives then it simply does not exist. Atlas’ database gives the ability to store data in the cloud, available anywhere as long as you can access it. Therefore, you could also argue that the information in the archives would have been available from anywhere, not just in the one server within the Jedi Archives. Luminous beings we might be, but database specialists, the Jedi were not. Security: You don't belong here! In a world with ever more data being consumed and stored, people are becoming more aware of how secure their data is (or is not). When looking to use MongoDB Atlas, developers are often concerned about how safe their data is in the cloud. MongoDB Atlas comes with a lot of security features pre-configured from the start. This includes isolation, authorization, and encryption. Security stack showing Isolation, Authorization and Encryption We firmly believe that your data should be private and only visible to those with the rights to see it. In Star Wars: Episode VI – Return of the Jedi , the Alliance learns of the construction of a second Death Star and discovers that an energy shield generator to protect the new Death Star is on the forest moon planet Endor. Leia, Han Solo, Chewbacca, R2-D2, C-3P0, and the Ewoks fight in the Battle of Endor for access to the bunker containing the generator. Thanks to R2-D2 and C-3P0 drawing away the Imperial Army, the enemy is attacked by the Ewoks. Chewbacca is then able to steal an AT-ST and rescue his allies, who are attempting to hack into the bunker. They successfully gain entry to the bunker, plant explosives, and expose the new Death Star, allowing it to be destroyed by the Rebel Fleet. However, if MongoDB security had been involved, the rebels wouldn’t have gained access to the bunker and the energy shield protecting the Death Star would have remained, meaning the Empire could have won. Death Star II was able to travel across the galaxy and strike fear into the hearts of many, and perhaps this might have prevented the creation of Starkiller Base in The Force Awakens and its destruction of the entire Hosnian system, saving millions of lives. While the Empire could have wiped out the Alliance and taken control of the galaxy with the second Death Star, it would have had to remain within range of its shield generator on the forest moon of Endor, unable to terrorize the galaxy at large as Starkiller Base eventually did. The First Order and Kylo Ren may never have risen to power. Luke Skywalker may not have escaped the Emperor or redeemed his father. Life would probably look very different for those millions of lives saved in the Hosnian system. We may have, in fact, seen Darth Vader and Luke Skywalker rule the galaxy as father and son. Scary thought! Data API: Bye-Bye, R2-D2 MongoDB Atlas Data API is a new feature, currently in preview, that allows developers to access their Atlas hosted database cluster via HTTP calls over the web using just a unique endpoint URL and an API key. This opens up the possibility of using the power of the MongoDB document database model in more ways and more scenarios. You might choose to use it because you don’t want the overhead of installing and using a driver for your chosen language or platform. This could be because you are prototyping or just prefer the API approach. You may not even have a driver for that scenario but can make HTTP requests. One example of this scenario is the Internet of Things (IoT), where you often won’t have a driver as an option but can easily make calls over the web. Another scenario is from a SQL stored procedure. That might sound controversial, but what if you want to push data to both a relational database and an Atlas cluster at the same time to help with migrating over to the most popular non-relational database in the world? A driver is a programming interface, allowing for use with whatever the driver is intended for. The MongoDB driver , available for multiple programming languages, allows communication with a MongoDB database via a connection string. It simplifies that process and handles the communication so developers don’t have to write complicated low-level code. In the Star Wars universe, you can think of droids as an interface to the data in the world around them. R2-D2 is an astromech droid, whose primary function is to provide navigational abilities but is able to do far more, including interfacing with other computers via a SCOMP link, disabling autopilot on the Naboo starfighter, picking up distress signals, locating Emperor Palpatine on Grievous’s ship, and, of course, sharing the Death Star plans with the Alliance. So, if there was MongoDB Atlas Data API in the Star Wars universe, what might that look like? This could be a simple data pad, similar to a smartphone. Instead of relying on R2-D2, BB-8, or Chopper to act as an interface to the information in different computers around the galaxy, the data pads could do this instead, providing the ability to access the data stored in Atlas. Using MongoDB, the Death Star plans might have been added to a collection in the database and accessible to all those who were authorized. This would have prevented some of the danger seen at the start of Star Wars: Episode IV – A New Hope , when Princess Leia had to upload the plans into R2-D2. Of course, R2-D2 would still have proved useful in other situations, such as in battle, putting out fires in the Millenium Falcon, or throwing Luke his lightsaber during a battle in Star Wars: Episode VI – Return of the Jedi . But some of the key roles he played could have been made redundant if the Data API–enabled data pad had been available instead. Sharding: Where art thou Anch-to Speaking of R2-D2, another event he was involved in could have been different had there been a feature of MongoDB in the Star Wars universe, sharding . When you have a really large data set, like, I don’t know, all the information in the galaxy’s HoloNet, you might want to break it down into smaller pieces in order to make it faster and easier to search through. Sharding is a perfect example of this in action. Sharding works by segregating your data into smaller pieces based on a field in your document. A common real-world comparison would be a library. In a library, books aren’t all just thrown on a shelf in the order they were acquired by the library. They are instead broken down into different shelves, sorted by author surname. The equivalent of this in the database world is a sharding key, which tells you exactly where to head first, saving you time and effort. In Star Wars: Episode VII – The Force Awakens , the Alliance including Rey want to find Luke Skywalker. If the galaxy information had been sharded, it would be possible for it to have been searched to find Luke’s location much faster, without the need to find a particular map to fill out a local data set. Access to Ahch-to, the location of the ancient Jedi Temple and the galaxy’s only green-milk-producing thala-sirens, would be just a query away.. This also ties in nicely to the previous section about the Data API. Without the need to use R2-D2 for the missing piece but instead use a data pad to query all the known information on the galaxy, the Alliance may have found Luke much sooner — especially if they were able to use MongoDB’s powerful query language to perform complex queries on the data using the aggregation pipeline . MongoDB is a non relational database that can be used by all living things. It surrounds docs, penetrates analytics, and binds the galaxy together. There we have it, a trip through the galaxy and the events of Star Wars to see how the timeline might have been different had MongoDB been around. MongoDB is a non-relational database that can be used by all living things. It surrounds documents, penetrates analytics, and binds the Galaxy together. The knowledge of the Jedi wouldn’t have been erased and their reputation tarnished had MongoDB Atlas and its high availability been available. The energy shield generator on Endor would have survived, meaning Death Star II may never have been destroyed, allowing the Empire to take full control of the galaxy but thwarting the rise of the First Order. R2-D2 might not have been so important had MongoDB Atlas Data API been available on data pads, allowing direct access over the internet to the data instead of requiring a driver. Luke Skywalker may have been found much sooner had sharding been available alongside powerful querying functionality such as the aggregation pipeline to bypass the need to find a map and get the missing piece from R2-D2. How can you use the power of MongoDB Atlas today to change your own universe? Get started today with our free forever M0 tier . MongoDB World returns this June to NYC and in honor of May the Fourth we are offering tickets at only $400 May4-6. Register now and join us for announcement packed keynotes, hands on workshops, and more June 7-9.

May 3, 2022

D’Enterprise Account Executive à Regional Director : comment Lucile Tournier a accéléré sa carrière en France

Lucile Tournier a rejoint MongoDB France en tant qu'Entreprise Account Executive en 2020. De l'apprentissage de nouvelles technologies à son nouveau rôle de maman tout en assumant des fonctions de leader, Lucile a eu un parcours incroyable au cours des deux dernières années. Apprenez-en plus sur son expérience au sein de notre équipe commerciale en France et sur la façon dont elle a su développer sa carrière pour devenir Regional Director chez MongoDB. Jackie Denner: Bonjour, Lucile. Merci de partager ton histoire ! Comment as-tu rejoint MongoDB et pourquoi étais-tu intéressée par l'entreprise ? Lucile Tournier: MongoDB est ma première expérience dans le monde de l’édition logiciel. En effet, mes expériences précédentes étaient des ESN françaises.Rien à voir en termes de cycles de vente, de culture d’entreprise (MongoDB étant une société américaine) ou encore de technicité (les bases de données - la seule stack que je n’avais jamais abordée !). Ayant l’impression d’avoir fait le tour de mon précédent poste, je me suis dit “Si je cherche un nouveau challenge, pourquoi pas le monde des éditeurs ? Est-ce fait pour moi ? Est-ce possible de passer d’une ESN à un ISV?” J’ai alors pris contact avec Alexandre Esculier , VP France MongoDB, à l’époque Regional Director, qui lui-même avait réussi un tel virage. Qui de mieux placé pour répondre à mes questions? Au fur et à mesure de mes échanges avec lui, mais aussi avec l’équipe MongoDB France, j’ai été conquise et j’ai décidé de me jeter dans le grand bain ! On pourrait se demander pourquoi MongoDB en particulier ? 3 ans auparavant, j’ai co-fondé une start up en Finance de marché au sein d’une ESN. Une expérience exaltante, à 1000 à l’heure, pleine de challenges, de difficultés et de belles réussites. J’aimais le côté “speed boat” (rapide et adaptable) à l’intérieur d’un grand groupe. Aussi, pour mon prochain challenge, je ne voulais pas rentrer dans une compagnie “paquebot”, où tout est long et fastidieux. J’ai vraiment retrouvé le meilleur des deux mondes chez MongoDB : à la fois grand groupe, avec des process clairs, une technologie disruptive, tout en ayant un esprit start up avec une croissance forte et de l’agilité. Et j’ai bien fait ! JD: Raconte-moi en davantage sur ton rôle d’Enterprise Account Executive. LT: Un vrai rollercoaster ! En parallèle de 6 mois d’onboarding poussés, j’ai pu rapidement aller sur le terrain, accompagnée bien sûr d’équipes à très grande valeur : mon manager, des architectes, les équipes post-sales etc. J’ai commencé à monter en compétences, à signer mes premiers contrats sur de grands comptes qui m’ont fait confiance (tout comme mon management), à ouvrir de nouveaux périmètres, à faire grossir les existants. J’ai énormément appris sur la technologie, sur le processus de vente ( basé sur le MEDDIC, dont John McMahon, co-inventeur de celui-ci, est au board de MongoDB ! ) et surtout sur moi-même grâce à une culture du feedback qui est la base chez MongoDB. Apprendre sur soi n’est pas si facile… Cela demande de savoir et de pouvoir se remettre en question quotidiennement. Mais quelle superbe opportunité pour grandir ! JD: Qu’est ce qui rend une carrière chez MongoDB unique ? LT: Elle est unique à plusieurs niveaux: la technologie, les process, le côté 1000 à l’heure, les résultats de la société …LES PEOPLE. Tout est fou.Ce que je retiens particulièrement c’est la bienveillance. Durant cette première année, j’ai eu l’immense joie de devenir maman, d’un petit garçon - Dorian. Commencer un nouveau job, tomber enceinte dans la foulée, ce n’est pas tout à fait ce que j’avais prévu. J’ai eu la chance d’avoir un management à l’écoute et ravi pour moi. Et j’ai pu réussir à mener de front mes deux belles aventures: réussir chez MongoDB et devenir Maman. Je ne pense pas que cela aurait pu aussi bien se passer ailleurs. JD: Tu as été promue d’Enterprise Account Executive à Regional Director. Comment as-tu réussi à atteindre cet objectif, et comment tes managers t'ont-ils soutenu dans cette démarche ? LT: Si je n’avais pas eu la confiance de toute ma ligne managériale, ce passage aurait été difficile, voire impossible. J’avais déjà un rôle de Manager dans mon “ancienne vie”. Cependant, il était important pour moi, comme pour MongoDB, de repasser par le terrain avant de revenir sur un poste de manager. Comment bien orienter ses équipes sans être passé par le terrain, en venant d’un monde complètement différent ? J’ai donc fait mes armes, j’ai prouvé, je me suis donnée à 100%, j’ai essayé d’être au maximum à l’écoute des feedbacks qu’on me donnait, j’ai testé, j’ai perdu, j’ai gagné, j’ai revu, j’ai recommencé et encore recommencé... Bref, j’avais confiance en mon environnement, et j’ai pu tout donner, tout en étant bien encadrée. J’avais des sessions régulières de développement, des formations, et surtout une oreille attentive de la part d’Alexandre et de Jérôme Delozière, VP Europe Continentale, qui m’aidaient à me poser les bonnes questions. JD: Qu’est ce qui est le plus passionnant au sein de MongoDB ? LT: Tout ! Déjà, la technologie est folle. C’est important de le souligner, car impossible pour moi d’aller dans une société où les clients ne sont pas satisfaits du produits une fois mis en place. Je veux pouvoir croire en ce que je vends. Et j’y crois ! Les équipes R&D sont toujours à la recherche des dernières évolutions qui nous permettent de garder nos 5 ans d’avance sur le marché ! Le fait de vendre à travers la méthodologie MEDDIC m’a énormément appris. J’avais l’art et MongoDB m’a apporté la science. Même après une dizaine d'années de vente, j’ai continué d’apprendre ! Et le plus important: les People ! Tout le monde cherche à se dépasser, à être un des constructeurs de cette belle aventure - et c’est vraiment agréable de travailler avec autant d’émulation. JD: Comment tu définirais la culture de vente chez MongoDB ? LT: Transparence ! En transparence on peut progresser, il faut se dire les choses, s’entraider, annoncer ses faiblesses, être à l’écoute. Comme avec les clients ! La transparence est la clef. On peut tout dire, avec les formes et au bon moment. JD: Quelles seraient - selon toi - les qualités pour réussir en tant que commercial au sein de MongoDB ? LT: Le travail. Rien n’arrive tout cuit. Il n’y a pas de périmètre facile, il n’y a pas de “chance” dans ce milieu. Il faut travailler, apprendre, se remettre en question, faire avancer les sujets. La chance arrive après. JD: Autre chose que nos candidats doivent savoir ? LT: Je recrute, alors n’hésitez pas à m'écrire sur LinkedIn ! Si vous souhaitez rejoindre l’équipe MongoDB, nous avons plusieurs rôles disponibles partout dans le monde et nous serions ravis que vous transformiez votre carrière avec nous !

May 3, 2022

MACH Aligned for Retail: Microservices

MACH is an approach to architecting modern applications through open tech ecosystems. It is an acronym representing Microservices, API-first, Cloud-native SaaS, and Headless. With the accelerating digitalization of retail experiences requiring new technology stacks that provide agility, flexibility, and performance at scale, MACH is especially relevant for retail and ecommerce , a far cry from current legacy, monolithic architectures. The MACH Alliance is an organization, of which MongoDB is a member, dedicated to educating and driving the adoption of the MACH framework and to “future proof enterprise technology and propel current and future digital experiences.” This is the first of a series of blog posts dedicated to MACH and how retail organizations are leveraging this framework to gain a competitive advantage. Let us begin with the first letter of MACH: microservices. What are microservices and why should I care? In simplest terms, microservices are 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 independence means the failure or outage of one microservice will not affect another. Each service serves a particular business function or objective. For a deeper look into technical details about microservices, check out MongoDB’s specific guides dedicated to this topic. The benefits of a microservices-based architecture are clear. The modular approach of microservices provides companies with quicker time to market and value, ultimately leading to a better customer experience. Development teams can work independently on different app functionalities, consequently shortening development cycles to get more features deployed in less time, which means the reaction to changing customer demands improves dramatically. Also, since services are deployed in independent environments, scalability concerns are managed in a much more convenient (and efficient) way, and resilience is strengthened significantly because there is no single point of failure, as there would be with monolithic applications. Microservices provide a modern architecture for app development, which ultimately delivers the best experience for customers. Learn how Boots modernized its stack with MongoDB and Microservices . Applying microservices for retail What does a microservice-based application look like in a real-world scenario? Let’s say an ecommerce application is being built. Microservices will greatly optimize the following challenges: Dynamic product catalog: An ecommerce app might involve a large number of products (maybe from different suppliers) with changing availability. With each supplier and/or product category as a part of a microservice, it becomes easier and more efficient to manage and provide an always up-to-date product catalog for users. Changing customer needs: A microservice-based architecture increases speed of development and testing, ultimately allowing new features to be deployed faster and enabling developers to quickly pivot to new customer needs. Different teams can work in parallel and independently, with little to no dependencies, rolling out or rolling back features as needed without risk. Scale flexibly: Independently scale app functionalities up during peaks or down for valleys with on-demand cloud-based microservices. The world before microservices Before microservices were an option, the typical data infrastructure would look like a data access layer on top of a database in order to get all the datasets containing information needed for running the application, as seen in Figure 1. There would be many databases to pull data from and various information silos, making for a painful process. Business logic had to be generated to transform these datasets to perform specific functions, namely a product catalog, cart, checkout, payments, and the like. Before building any application, the relational data objects would need to be mapped out to match an object-oriented programming paradigm. Figure 1: The monolithic application diagram before microservices This is not easily scalable or flexible for modern applications because every change in a dataset needs to be pushed upstream, and every new feature request for the app implies a data schema change downstream. This complicates life for developers and makes adaptation to customer needs a nightmare. Decoupled app functionality with microservices With microservices, business functions are decoupled as much as possible in order to create a bounded context that is clearly independent of the others, meaning a failure or outage in one does not affect the others. This often means having a separate database per service, as seen in Figure 2. Figure 2: A first approach to microservices In this first approach to microservices, decoupled application functionalities can be developed, maintained, and scaled independently. However, having a separate database for each business functionality is not the ideal. It adds operational complexity, defeating the purpose of a microservices approach since maintaining and scaling a distributed system is not a simple task. But there is light in all of this: a middle ground between strong decoupling and operational efficiency can be found with MongoDB. MongoDB and microservices MongoDB is built under a number of fundamental technology principles that ensure companies can reap the advantages of microservices, specifically around a flexible data model, redundancy, automation, and scalability. MongoDB can be deployed in any environment (on-premises or cloud for example), but all industries are moving or have already moved toward the cloud, with its lower cost of ownership and flexibility. Retail is no exception. The cloud is again the natural next step for microservices. It provides dynamic scalability and high availability, freeing teams of the operational burden of maintaining a distributed system in-house. This is why MongoDB clients are choosing MongoDB Atlas as their cloud database-as-a-service to deploy applications based on microservices. As a step to modernization , MongoDB can be used as an operational data store, as seen in Figure 3. Legacy data silos are needfully connected via change data capture (CDC) and/or ETL processes in order to have an up-to-date copy of the data, stored as JSON documents. This is a first major advantage, since now applications can be developed against a data model that fits how developers think and code, therefore providing unprecedented agility to the development cycle. Figure 3: Microservices with MongoDB, acting as an operational data Store. Applications can be developed taking advantage of its flexible data model and scalability MongoDB Atlas allows for all of the benefits and flexibility of a fully managed, API-driven database. It allows for environment automation without dealing with every detail of database operation and scalability. This makes development teams more agile so that they can evolve applications at the pace customers expect and require today. Learn more about how MongoDB and MACH are changing the game for retail , and stay tuned for the next blog in this series, in which we will discuss how an API-first approach helps retailers simplify development processes, increase interoperability, and reduce inefficiencies.

April 28, 2022

Building Together: A Look Into MongoDB’s Newest Location in Barcelona

MongoDB may be headquartered in New York City, but our company has offices spanning the Americas, Europe, the Middle East, and the Asia-Pacific region. We are currently made up of more than 3,600 employees and are continuing to grow. On October 1, 2021, MongoDB opened a new office in Barcelona, a city that is quickly becoming an important European business hub. Hear from some of our Barcelona employees to learn about life at MongoDB in Barcelona and why it’s an exciting time to join this expanding location. An overview of MongoDB Barcelona MongoDB has a variety of teams making an impact in Barcelona. From Sales and Customer Success to Engineering and Industry Solutions, there are numerous career opportunities for individuals from different backgrounds. Our Barcelona team is currently made up of 40 employees, 10 of whom relocated from other countries. Whether you’re a Spaniard or an expat, Barcelona is a great place to continue growing your career with MongoDB. Silvia Tropea , Employee Experience Manager for Southern Europe and the Middle East Our new office in Barcelona is located in the Aticco Bogatell coworking space within 22@, Barcelona’s booming technology and innovation district. The building has a nice distribution of entrepreneurs, startups, and large companies and includes all the facilities and services necessary for a great working environment. The spacious common areas are perfect for enjoying moments of relaxation and organizing social and business events. The space is a great representation of our team based in Barcelona: dynamic, innovative, creative, and eager to learn! Our goal is to build a strong sense of community within the Barcelona team, along with the rest of the Southern European teams. We aim to have people embrace the power of diverse living and working in a stimulating multicultural environment. In order to achieve that, MongoDB’s Employee Experience and Workplace teams are actively working together with the local managers and leadership to organize team-building activities and events so our employees will feel connected and develop a strong sense of belonging. Aside from being part of a multicultural team in an ever-evolving city, take a look at some of the benefits offered to our employees in Spain: Above-standard 27 days of annual leave A fully funded group medical plan for employees and their dependents Employer-funded pension plan Permanent disability, life, and travel insurance Twenty weeks of fully paid parental leave (regardless of gender) for employees who have passed their one-year work anniversary At least $20,000USD for fertility and adoption assistance through Carrot, plus personalized new parent support through Cleo A generous equity package and employee stock purchase program with opportunities for ongoing grants Local and global company initiatives to support physical and mental well-being, including mental health resources, a free subscription to Headspace, gym benefits through Gympass, and an employee assistance program Our Barcelona office Meet some Barcelona team members Carlo Sicoli , Manager, Sales Development MongoDB’s Sales Development team is on the front lines of the customer journey and is one of the main drivers of our Sales organization. Our Barcelona team is made up of more than 25 professionals from all over Europe, and we are one of the fastest-growing teams and regions at MongoDB. We foster a strong culture of collaboration and growth, holding ourselves accountable for our business while having fun together as well. Our team is always willing to learn, progress, and grow both personally and professionally. MongoDB is an incredibly fast-paced environment with many opportunities for career growth. What I find most beneficial is our BDR to CRO program , an initiative sponsored by our CRO, Cedric Pech, to build a direct path between Sales Development and leadership roles. We truly care about career progression and aim to provide multiple career pathways for our reps, whether that be within sales or across other departments like Customer Success, Sales Operations, Marketing, or Sales Enablement. Barcelona is a great place to grow your career in tech sales. Not only is the city attracting large investments from tech companies, but it’s also an incredible international environment with high quality of life. Our Barcelona teams regularly get together for outdoor and sport activities, along with a weekly Thursday get-together on the office rooftop surrounded by amazing views of the sea and Sagrada Familia! There is truly no better time to join the MongoDB Barcelona team. Our overall business is growing over 50% YoY and our flagship product, MongoDB Atlas, is growing 85% YoY. What’s more, our total addressable market is estimated to be $119B by 2025 and has only claimed a 1% market share. This is just the beginning! In addition, our team is growing in Barcelona across multiple functions: Sales Development, Corporate Sales, Customer Success, and leadership roles. There is a lot of mobility to tailor your career path in the direction of your interests. Last but not least: flexibility. COVID-19 brought a lot of changes to the way we work as a company, and MongoDB is embracing flexible policies such as a blend of working from home and in-office. Flexibility is a key driver for us and we are always working to make things better for our employees. Above all, I believe that Barcelona is one of the most beautiful and exciting cities in Europe. Join us! The Sales Development leadership team in Barcelona Marion Duplan , Account Development Representative I had been living in Dublin for two years when I joined MongoDB as an Account Development Representative. While I love Ireland and the experiences I had there, I wanted to be closer to my home country (France) and have a bit more sun! Joining MongoDB was a great experience, from a thoughtful onboarding process to support from my new teammates, who made me feel extremely welcome. I had the opportunity to relocate from Dublin to Barcelona and take some time to get settled in. It was a game-changer and made me much more relaxed knowing that I could take my time finding the perfect place to call home. The Sales Development team in Barcelona is the perfect opportunity to build a sales career and balance a great work experience with a really nice way of life (great tapas, lots of sun, and a dynamic city!). Our team has many opportunities to connect, from sharing tips on the market we work within or how to organize our day-to-day work. We also have some new managers who bring new knowledge from previous experiences, which is great. Outside of work, we get together for weekly meet-ups, and some of my brave colleagues get together at 6 AM to go to the gym before work! We are at the beginning of a new adventure here in Barcelona and it feels really nice to build it all together. Thomas Chardac , Cloud Account Executive I joined MongoDB as an Account Development Representative (ADR) in June 2020. I had the chance to work for a region in France where the reps were amazing and really invested a lot of time into making me become better every day at doing my job. Sales Development management supported me and were really open to feedback, always willing to assess and grow the impact of ADRs on the business. In August 2021, I was promoted to Cloud Account Executive, and I am now managing between 100 to 150 accounts all over Europe. I am also on track to soon work on a team managing one of the biggest European customers. In a nutshell, things go fast at MongoDB! Before coming to Barcelona, I was located in Dublin. I decided to relocate to Barcelona to be part of something new and be at the beginning of an office that will grow at scale in the coming months and where I can help build the culture and onboard new hires. Additionally, I come from Limoges in France, so I am way closer to my family and friends here in Barcelona, which made a big difference in the decision. I had no idea so many companies were present in Barcelona. I am discovering every day how big the tech scene is here, and it is growing super-fast! I foresee many interesting leadership and senior sales positions opening here in the future. Knowing three different MongoDB offices — Paris, Dublin, and Barcelona — pretty well, I can say that the common trait of salespeople at MongoDB is that everyone is here to put the effort into getting better every day. It’s a never-resting, exciting, and stimulating environment. Also, anytime you need help you’ll find some amongst your peers. The growth MongoDB is experiencing, the quality of life here, and the opportunity to experience a new culture and meet people from all over the world is not something you want to miss! Gabriela Preiss , Industry Solutions Manager The Industry Solutions team at MongoDB is a fast-growing team that educates and aids large enterprises in modernizing their data infrastructures based on the needs, wants, and challenges of their specific industry. We are the industry subject matter experts. The bulk of our team is globally dispersed, but we made a strategic decision to start building out a sector of our team in Barcelona. This city is full of inspiration and innovation as a tech hub and has a hard-to-beat climate and nature that coexists with the bustling city. The overall team culture in Barcelona is great. You can always find something to do, and although these times are tricky with COVID-19, we try to regularly make time for casual meetups for tapas, drinks, and lunches. We’ve planned hikes, rooftop meetups, futbol games, and more. I feel very fortunate to work at MongoDB. I’ve always felt encouraged to grow and share ideas, and I feel like my work and initiative are noticed. In a short amount of time, I went from an entry-level Industry Consultant to building my own team in Barcelona. That growth culture may be marketed by every company, but it is still quite hard to find in an organization. MongoDB really sets the tone for individual growth through their leadership and the example they set. This is a very exciting time to join MongoDB in Barcelona. We’re growing exponentially, and to see that journey from the beginning has been incredible. For me, it’s a perfect fusion of a city I love with a career that excites me every day. During these last few years, a lot of people were forced to reevaluate where they live and what they dedicate their life to. I’ve only been reassured that Barcelona offers a high quality of life, while MongoDB has grown stronger than ever, in quantity and quality, despite having to quickly shift and adapt to meet changing global demands for their employees. Learn more about Gabriela’s career story and the Industry Solutions team. Gabriela and her team Tommaso Tocci , Lead Software Engineer, Sharding Before joining MongoDB, I was working as a researcher in the high-performance computing field. After two years of performing investigations and publishing papers, I was getting a bit frustrated. I really wanted to build something that would make a difference, something that would be used by thousands, even millions of people, something that would have a great impact. I also really wanted to write open source code, because I’m convinced that sharing knowledge is one of the key aspects of human evolution. When MongoDB contacted me, I didn’t hesitate: the company was building an innovative and open source database used by millions of people. It was exactly what I was looking for. I joined MongoDB as the second Software Engineer on our Sharding team in Barcelona. The sharding capabilities of MongoDB have received increased interest over the past few years. One of the main reasons we decided to build out the Sharding division in Barcelona was to attract new talent from all over Europe to join us on this incredible journey. Our intuition was correct, and in the past two years, we’ve grown the team to more than 15 brilliant engineers. One of the things I’m most proud of about MongoDB is the culture. When I first joined, I was really impressed by the fact that everyone was incredibly friendly and came from diverse backgrounds. It didn’t take long to realize that this was not an isolated case — MongoDB welcomes open-minded people who share our core values. In the Barcelona office specifically, there is an incredibly nice atmosphere focused on collaboration, inclusion, and trust. We always help each other and share our knowledge as much as possible, and we never forget to celebrate when we close a project. I personally really enjoy our brainstorming sessions; it’s where all our great ideas came from. Every day, more and more developers and companies shard their databases to achieve more flexibility. We have great plans for the Sharding team and numerous exciting features on our roadmap. To make all these dreams come true and improve sharding even more, we need talented engineers who will join us in this effort. Allison Easton , Software Engineer, Sharding I started my career with MongoDB in the summer of 2019 as an intern on the Replication team in the NYC office. I loved MongoDB and the work I was doing, but I didn’t want to live in New York City full-time. I knew that I wanted to go somewhere different after college and continue working on distributed systems, but didn’t really know where or what role. I talked to my recruiter and we discussed the possibility of me joining the newly started Sharding team in Barcelona. There were no guarantees since the team was so new and small, but I came back the next summer to intern for the Sharding team in NYC to see if it would be a good fit. After interning for the Sharding team in NYC remotely, I was offered a position in Barcelona after graduation. In the summer of 2021, I started full-time on the Sharding team here in Barcelona. Moving to Barcelona was pretty scary. I had never been to Spain before, and I didn’t (and still don’t really) speak any Spanish. MongoDB helped me get my visa and connected me with Kal Manassiev , who suggested places to stay in the city while looking for apartments. Everyone here has been super welcoming, and it’s been great living in such a different place. Since joining the team, my focus has been on improving the balancing process for sharded clusters. As the only new grad on the Barcelona team, I have a lot of great people to learn from. Everyone works together on projects and there is a focus on knowledge sharing that makes it easy to ask questions and learn about different projects. Having the new office space has also allowed us to interact in person, and utilizing whiteboard sessions to come up with ideas and learn more about how sharding works is really valuable. Barcelona is an amazing city. It’s lively and very different from the U.S. With the growth MongoDB is experiencing in Barcelona and the number of new team members moving here, it’s exciting to be able to explore the city (and the country for that matter) with other people who are excited to be here. Learn more about the Sharding team in Barcelona. Sara Escribano Slowey , Manager of Customer Success Our Customer Success (CS) department in EMEA is currently a team of over 50 passionate Customer Success Managers (CSMs) who work day in and day out with our customers, leading them from onboarding through their adoption lifecycle and up to their renewal. A CSM at MongoDB has many responsibilities, but the main one is ensuring that our customers adopt our technology, are aware of and employ best practices, and are able to grow their business with MongoDB. Our CS EMEA team is distributed across all of Europe. CS at MongoDB is increasingly investing in our Barcelona hub. We are hiring for our Onboarding, Scaled, and High Touch CS teams, along with fluent second-language speakers in our Barcelona and Dublin hubs. You can expect a growing CS team of skilled peers and additional openings out of sunny Barcelona throughout this year. We use a flexible working model to support our teams, whereby CSMs collaborate and decide the days they will work from home versus days they will be in-office with the rest of the team. Our team communicates daily via Slack and weekly team meetings, and we run virtual social events now and then driven by our CSMs themselves. They have the best ideas! Our main values revolve around expertise, collaboration, and accountability. We are a team focused on continuous self-enablement and hungry to become high-level experts for our customers. We are a highly collaborative team. We take pride in helping each other, have solid ramping and coaching programs for new starters, and ensure this collaboration culture is maintained regardless of our scale. Last but not least, we are a team that plays a key role within MongoDB’s account teams, and we deliver for our customers consistently. Joining the CS team in Barcelona opens up a realm of career opportunities for our employees. As a CSM you have a central role within the company. From collaborating closely with our Sales teams to working through technical milestones with Product teams and our field technical teams (Solutions Architects and Professional Services) to driving the customer’s experience, all angles of this role will give you an ample view of the business. At MongoDB and within CS, we have a well-structured development path around core competencies to continuously increase your skills. In my own tenure, I’ve developed in the company from an individual contributor into leading our Southern CS Enterprise team, which has been a career lifetime experience that can only come within a company that is laser focused on growing, challenging, and rewarding its internal talent. All in all, don’t think twice, now is a great time to join our team in Barcelona! Interested in joining MongoDB in Barcelona? We have several open roles and would love for you to transform your career with us!

April 27, 2022

Democratizing Data Access With Plain English, Cogram, and MongoDB

Access to information is important for our world and the applications that power it. Today, the disparity in access has narrowed, but not enough. The proliferation of the document database and its flexible data model has unlocked a velocity and freedom that SQL systems will never unlock. It’s time to remove the burden of query languages for users early in their journey. That’s why we are launching an early pilot with Cogram, the startup building the world’s first Mongo Query Language (MQL) generation platform for natural language. The early-stage company is on a mission to democratize data access by allowing users to query data irrespective of their technical background. Cogram is working toward a future in which humans can access and manipulate any data through natural language. Cogram is partnering with MongoDB to enable language-driven data exploration. While it is still early days, users can log in to the tool, enter an English-language question for five collections from our sample dataset, and execute the generated MQL to see the results. Here are some questions to get you started on the Sample Supply Store dataset: Find one sale. What's the average customer satisfaction in Denver? What's the percentage of customers in Denver who used a coupon? How many users have an email address that contains ‘’? Find two sales. Get the last inserted sale. Show all store locations. Show all unique tags. What are the top five tags? Find all customers who use gmail. Show me all customer email addresses that end on ‘.sh’ What are the three most common store locations? What's the average price of all items? How many customers used a coupon? How many times was each item sold? Additionally, we’re excited to have Cogram included in MongoDB for Startups , our program for early-stage, high-growth startups. Designed to help founders and CTOs build and grow data-driven organizations with MongoDB, the program provides a wide range of resources, including MongoDB’s best-in-class data platform, personalized technical advice, and access to our robust developer community. Get a first look by signing up for a Cogram account and testing it out.

April 22, 2022

Celebrating Earth Day With Three MongoDB Customers

Every April 22nd, citizens across the globe come together to celebrate the environmental movement on Earth Day. This year’s official theme is " Invest in our Planet ." According to the Earth Day organization, “for Earth Day 2022, we need to act (boldly), innovate (broadly), and implement (equitably). It’s going to take all of us. All in. Businesses, governments, and citizens — everyone accounted for, and everyone accountable. A partnership for the planet.” On this important day, we’re highlighting three MongoDB customers that have taken great strides to make a positive impact on our environment. They are shining examples of the power of MongoDB and what it means to be eco-friendly. University of Bremen At Germany’s University of Bremen , the Collaborative Research Center (CRC) initiative Farbige Zustände is a cross-disciplinary effort to reinvent an entire field of research: the discovery of new materials. “It’s not just harder, lighter, strong materials,” Dr. Nils Ellendt, CEO of the CRC, says. “It’s finding materials that need less refining, that are more compatible with a sustainable environment. How few elements can we use, not how many.” When the CRC first planned its data infrastructure, the company looked at standard structured databases, but it quickly realized that the datasets researchers would be using were quite heterogeneous and better suited to unstructured database techniques. That’s where MongoDB came in. MongoDB proved it could handle unstructured data at scale, so the CRC built its entire testing process around it. Soon after, the company determined that MongoDB was well suited for its unique approach. The Centre has its sights on pioneering a complete revolution in materials science, not simply in the creation of a massive new catalog of potential engineering materials, but also in pioneering data and automation in creative engineering. Read our full profile of the CRC “Farbige Zustände.” Journey Foods Journey Foods is a machine learning–powered software platform for food companies, designed to revolutionize the future of food. Just a few years after its launch, Journey Foods has raised more than $2.5 million from investors and partnered with global consortiums such as Future Food Network, FoodTank, and the University of Chicago on sustainability and data. “We are trying to focus on developing our service to accurately provide nutrition insights, sustainability insights, and help save our customers money,” said Riana Lynn, CEO. “We are prioritizing partnerships that will help us build out a big and dynamic ecosystem.” Lynn said the company chose MongoDB because of its seamless user experience, ease of scalability, and recommendations from other companies. She cited the consistent and always available support and follow-up from MongoDB; because of that, her developers appreciate how easy it is to use the platform, and to share and collaborate on different projects. Read our full interview with Journey Foods’ CEO. Kode Labs The commercial and real estate markets are being transformed by new technologies that reduce the carbon footprint of these energy-intensive businesses. Kode Labs was born because its founders recognized the importance of sustainable buildings, and how they rely on advanced software to achieve LEED and other sustainability certifications. Kode Labs launched in 2017 to provide intuitive, easy-to-use software for building management that enables sustainability, operations efficiency, and comfort. The company uses MongoDB Atlas for a fully managed database that allows it to effortlessly deploy new projects, infrastructure components, and more when starting to work with a new client or building out further projects with an existing one. “Everyone wants to be more energy efficient, healthier, and have modern places to live and work,” says Etrit Demaj, co-founder of Kode Labs. With MongoDB Atlas, "we help building managers and construction firms deliver on these growing expectations.” Read more about Kode Labs’ mission to support sustainable buildings.

April 21, 2022

The 5-Step Guide to Mainframe Modernization for Banks

Enriched, convenient, and personalized are the watchwords for any business building a modern, digital customer experience. It’s no different for traditional retail banks, especially as they try to fend off challenger banks and design their own online banking and in-branch experiences to win new business and retain existing customers. But in order to beat the competition and build experiences that best those offered by neobanks, established retail banks need to master their data estate. Specifically, they need to free themselves from the rigid data architectures associated with legacy mainframes and monolithic enterprise banking applications. Only then can established banks have their developers get to work building high-quality customer-facing applications rather than managing thousands of SQL tables, scrambling to rework schema, or maintaining creaky legacy systems. The first step on this journey is modernizing the mainframe. Enriched modernization in 5 phases The best way to modernize is through a phased model that uses an operational data layer (ODL). An ODL acts as a bridge between a bank’s existing systems and its new ones. Using an ODL allows for an iterative approach, allowing banks to see progress toward modernization at each step along the way while still protecting existing assets and business-critical operations. Banks can see rapid improvements in a relatively short amount of time while preserving the legacy components for as long as they’re needed to keep the business running. MongoDB’s five-phase approach to modernization enables banks to modernize iteratively while balancing performance and risk. If banks are eager to modernize and their customers are demanding modern banking experiences, what’s taking banks so long to move away from the legacy systems that are restricting their ability to innovate? And why do so many legacy modernization efforts fall short? Download The 5 Phases of Banking Modernization to start plotting your path forward. Mainframe modernization techniques With an ODL, the legacy infrastructure can be switched off piece by piece and retired as more functionality is added. In this scenario, database operations become much more efficient because objects get stored together rather than in disjointed locations. Reads are executed in parallel via the nodes in a replica set. Writes are largely unaffected. To bring similar benefits to writes, banks may choose to implement an ODL with sharding and regional shards , bringing writes closer to the actual user. Workloads can then be gradually moved from legacy systems to the ODL, with the ultimate goal to decommission the legacy system. The beauty of this approach to modernization is that it starts with the use case: What problems does the bank face in its data management and what functionalities are customers requesting? If the first priority is giving customers access to historical transaction data, then banks can tackle that problem immediately by building a repository (or domain) to offload customer data from the mainframe. If the priority is cost reduction, then an ODL can act as an interim layer, allowing applications to access the data they need without the need to run expensive queries against mainframe data. The advantages of an ODL MongoDB’s application data platform is ideal for connecting legacy mainframes and databases to newer architectures, such as a data mesh, by way of an ODL. An ODL has a number of advantages. Combined, these advantages make data massively easier to access and use — and applications easier and faster to build. An ODL allows an organization to process and augment data that resides in separate silos, and then use that data to power a downstream product, such as a website or an ATM. With an ODL, data is physically copied to a new location. A bank’s legacy systems remain in place, but new applications can access data through the ODL rather than interacting directly with legacy systems. An ODL can draw data from one or many source systems and power one or many consuming applications, unifying data from multiple systems into a single real-time platform. An ODL relieves the mainframe of workloads. One useful by-product is in avoiding consumer service interruptions brought about by maintenance windows on legacy systems, like Oracle Exadata. An ODL can be used to serve only reads, accept writes that are then written back to source systems, or evolve into a system of record that eventually replaces legacy systems and simplifies the enterprise architecture. Because of its ability to work with legacy systems, or to gradually replace them, and its ability to support an evolutionary approach to legacy modernization, many banks find that an ODL is a critical step on the path to full modernization of their enterprise architecture. In terms of architectural setup, some banks may want one ODL for each of their data domains but others may find certain domains can share an ODL. The ODS/ODL template can be applied in a variety of ways — without breaking the bank’s internal standards. For example, imagine an ATM terminal connected to a MongoDB-based ODL. With the ODL in place, data from the mainframe is replicated in real time and made available for the consumer to check their most recent transactions and account balance on the ATM. Customer balance information, however, also still resides on the source system. Using the ODL to replicate and display information from the mainframe avoids customers having to face annoying delays while they wait for the information from a mainframe to load. At the same time, risk management and regulatory reports can still be run against a mainframe as a batch “end of day” process. With an ODL in place, data can flow from the mainframe to a newer architecture, giving the ATM broader capabilities that expand customers’ banking experiences, such as the ability to pay invoices, change addresses, or even open additional accounts. Nightly batch, bulk load, or real-time updates: MongoDB is flexible enough to connect to any data source, be it classic DB2 for zOS, Oracle, SQL Server, Hadoop-based legacy, or even Excel spreadsheets. MongoDB has the appropriate connectivity to ingest any data at any time from anywhere. Enrichment, data domains, and data marketplaces: With its document data model, MongoDB has the capability to bring data into data domains versus using convoluted table schema and ETL processes. The domains emerge naturally based on the application and user community requirements. Security, schemas, and validation: MongoDB has multiple layers of security, including password protection over encryption in flight and at rest, plus granular field-level encryption. All with external key management. MongoDB can be used as an operational data layer Take the next step in mainframe modernization Because many core banking capabilities are transactional and can be handled with daily batch processing, mainframes remain the backbone of our financial system. Mainframe modernization might sound daunting, but it doesn’t have to be. Banks can choose to proceed along a straightforward and predictable path that allows them to modernize iteratively. They can receive the benefits of modernization in one area of the organization even if other groups are earlier in their modernization path. It’s possible to do this while supporting increasingly complex data privacy regulations and, importantly, minimizing risk. Banks and other financial institutions that have successfully modernized have seen cost reductions, faster performance, simpler compliance practices, and rapid development cycles. New, flexible architectures have accelerated the creation of value-added services for consumers and corporate clients. If you’re ready to learn more about how you can accelerate your digital transformation and minimize risk, “ The 5 Phases of Banking Modernization ” now.

April 21, 2022