MongoDB 3.3.8 has been released. As a reminder, 3.3.8 is a development release and is not intended for production use. The 3.3 series will evolve into 3.4, which will be for production.
New/fixed in this release:
- SERVER-1393 Support decimal numbers
- SERVER-23043 Community and Enterprise builds on Ubuntu 16.04 LTS (Xenial Xerus)
- SERVER-23115 Include the prefixes of the indexed fields that cause index to be multikey in explain output
- SERVER-23644 Add additional tests for validate()
- SERVER-23697 Release shell as separate download
- SERVER-23725 Implement $graphLookup
- SERVER-23938 Include startup warning if running without access control
As always, please let us know of any issues.
-- The MongoDB Team
Building Modern Applications with Microservices: Part 2
In the previous post , I discussed the background behind microservices and their advantages. In this post, I will talk about how MongoDB enables microservices, as well as considerations to keep in mind before implementing a microservices project. How MongoDB Enables Microservices There are some fundamental technology principles that are required to ensure companies can reap the advantages of microservices, specifically around a flexible data model, redundancy, automation, and scalability. Flexible Data Model: MongoDB’s dynamic schema is ideal for handling the requirements of microservices and continuous delivery. When rolling out a new feature that changes the data model, there’s no requirement to update all of the existing records, something that can take weeks for a relational database. Developers can quickly iterate and model data against an ever changing environment, resulting in faster time to market and greater agility. Redundancy: Due to the distributed nature of microservices, there are more potential failure points, such as more network links, and thus, microservices need to be designed with redundancy in mind. MongoDB is well suited for this requirement, as it provides built-in redundancy through MongoDB replica sets . Replica sets not only provide greater resilience to failure, but also provide disaster recovery with multi-data center deployments and the ability to isolate operational workloads from analytical reporting in a single database cluster. Monitoring and Automation: With a small number of services, it is not difficult to manage tasks manually. As the number of services grow, productivity can stall if there is not an automated process in place to handle the growing complexity. Choosing technology that handles monitoring and automation is key to ensuring devops teams can remain productive, especially as the environment becomes more complex. MongoDB Ops Manager (also available as the hosted Cloud Manager service) features visualization, custom dashboards, and automated alerting to help manage a complex environment. Ops Manager tracks 100+ key database and systems health metrics including operations counters, CPU utilization, replication status, and any node status. The metrics are securely reported to Ops Manager where they are processed and visualized. Figure 1: Ops Manager provides real time & historic visibility into the MongoDB deployment IIntegration with existing monitoring tools is also straightforward via the Ops Manager RESTful API, and with packaged integrations to leading Application Performance Management (APM) platforms such as New Relic. This integration allows MongoDB status to be consolidated and monitored alongside the rest of your application infrastructure, all from a single pane of glass. Scalability: Scaling to meet extra demand is a requirement of any IT environment, and microservices are no exception. MongoDB provides a scalable solution that automatically partitions and distributes the database across nodes, which can easily serve IT infrastructures that require dynamic and high-performance capabilities. Additionally, MongoDB is ideally suited to scale-out on commodity hardware with auto-sharding, which, if needed, allows the service to be easily distributed across different geographic regions. This is better from the monolithic, scale up design of traditional RDBMS because scaling in MongoDB is automatic and transparent. Manage Multiple Database Instances: In a microservices architecture it is best practice to dedicate a separate database for each service. This leads to multiple database instances, which can be difficult to manage. At MongoDB World 2016 , we announced MongoDB Atlas , which is hosted MongoDB as a Service. Developers don’t need to worry about provisioning, configuration, patching, upgrades, backups, and failure recovery of the database. MongoDB Atlas offers elastic scalability, either by scaling up on a range of instance sizes or scaling out with automatic sharding, all with no application downtime. Additionally, you can view, monitor, and manage all your MongoDB clusters from a single GUI, streamlining the management of your database clusters. To capture more business benefit, many organizations are also shifting microservices to the cloud. The dynamic nature of the cloud allows enterprises to spin instances up and down, while providing continuous availability in case of any failures. Considerations Before Moving to Microservices Though microservices offer many advantages, they are not appropriate for all deployments. There are several considerations to keep in mind before implementing a microservices project: Though microservices offer many advantages, they are not appropriate for all deployments. There are several considerations to keep in mind before implementing a microservices project: Monitoring Challenges: One of the biggest challenges for microservices is effectively monitoring the overall system. Monitoring one or two services is relatively straightforward, but effectively monitoring many services can be very challenging. Not only are there are more servers to monitor, but there are also more log files to analyze, as well as additional opportunities for network partitions. Traditional approaches to monitoring stats, such as CPU, memory, and network latencies are important, but enterprises also need to expand ways to view metrics about the system and how it behaves over a long period of time. Automating the monitoring process can help mitigate some of these challenges and reduce operational overhead. High Developer Skillset: Microservices is implemented on distributed systems, which are necessarily more complex. Network latency, hardware failures, unreliable networks, asynchronicity, and fault tolerance need to be dealt with gracefully and appropriately. In order to handle the added complexity, developers need to have a strong operations and production background. Developers can no longer create the application and hand it off to the operations team; they need to understand the interdependencies between DevOps, testing, and release in order to properly design a service. Before implementing a microservices architecture, it is important to determine if your team has the right capabilities to handle the associated complexities. More Operations Overhead: For a given monolithic application, it may require one application server cluster with a few processes, while a microservice application may comprise 50 services and 200 processes after adding in resiliency. Operating and monitoring all these new process can be a daunting task. Additionally, services need to be tested and quickly propagated through the continuous delivery pipeline, which requires proper tooling and skills. Incorrect Service Boundaries: It is imperative to establish the proper service boundaries during the design phase. A common problem is to create services from internal components without considering the proper service boundaries. As more functionality gets added, there is a risk that the team ends up building a giant distributed monolith. Getting the service boundaries incorrect may result in higher costs, overcoupled services, and more testing complexity. MongoDB Microservice Deployments MongoDB is deployed by thousands of organizations around the world, including over half of all Fortune 100 companies. Many enterprises use MongoDB in a microservices architecture to achieve their business and deployment goals. Comparethemarket.com is a one of the UK’s leading providers for price comparison services and uses MongoDB as the operational database behind its large microservice environment. Service uptime is critical, and MongoDB’s distributed design is key to ensure that SLA’s are always met. Comparethemarket.com’s deployment consists of microservices deployed in AWS. Each microservice, or logical grouping of related microservices, is provisioned with its own MongoDB replica set running in Docker containers , and deployed across multiple AWS Availability Zones to provide resiliency and high availability. MongoDB Ops Manager is used to provide the operational automation that is essential to launch new features quickly: deploying replica sets, providing continuous backups, and performing zero downtime upgrades. fuboTV is a streaming service in North America that streams sports content from soccer leagues all over the world and uses MongoDB as the core database for its microservices architecture. The traffic profile of the fuboTV streaming service is extremely bursty with the site typically handling 100x normal traffic volumes ten minutes before a match. To keep pace with business growth and demanding software release schedule, fuboTV migrated its MongoDB database to Docker containers managed by the Kubernetes orchestration system on the Google Cloud Platform. Figure 2: fuboTV Microservices Architecture This brings high levels of flexibility, efficiency, and uptime to fuboTV. Using containers managed by Kubernetes, fuboTV can provision all of its environments – development, test, QA and production – to a single cluster of physical hosts. Kubernetes scheduler is used to precisely control resource allocation across all of its apps, enabling fuboTV to maximize utilization and reduce costs. Kubernetes replication controller automatically reschedules containers if an instance fails — enabling fault resiliency and continuous availability. Data redundancy is provided by MongoDB replication within the replica set. This enables fuboTV to have zero downtime as it deploys and upgrades its applications OTTO is top German retailer for fashion and lifestyle goods that has two million daily site visitors. The problem was that OTTO had parallel teams spanning multiple business domains (business, project management, IT) that had various business problems but all needed to deliver results quickly. Independently, all the teams chose MongoDB as the best tool to quickly and easily achieve results. With loosely coupled teams, architecture, and operations, OTTO removed the bottleneck to deploy and test. Teams could quickly and iteratively correct errors and support continuous delivery. MongoDB was the driving force to enable OTTO’s business, IT, and project management teams to deliver fast results, drive development agility, and allow teams to innovate risk-free. Summary A microservices architecture provides many advantages over a monolithic architecture, but this does not imply microservices do not come without their own challenges. Proper planning and application decoupling is required to ensure that a microservices architecture will achieve your desired results. MongoDB is well suited for a microservices architecture with its ability to provide a flexible schema, redundancy, automation, and scalability. Together, MongoDB and microservices can help organizations align teams effectively, achieve faster innovation, and meet the challenges of a demanding new age in application development and delivery. Learn more about MongoDB and microservices. Read the white paper. Microservices: The Evolution of Building Modern Applications About the Author - Jason Ma Jason is a Principal Product Marketing Manager based in Palo Alto, and has extensive experience in technology hardware and software. He previously worked for SanDisk in Corporate Strategy doing M&A and investments, and as a Product Manager on the Infiniflash All-Flash JBOF. Before SanDisk, he worked as a HW engineer at Intel and Boeing. Jason has a BSEE from UC San Diego, MSEE from the University of Southern California, and an MBA from UC Berkeley.
Transitioning from Teacher to MongoDB’s New Enterprise Modernization Team: Meet Gabriela Preiss
As a global company, MongoDB has amazing employees with interesting backgrounds and stories. I recently sat down with Gabriela Preiss, an Enterprise Modernization Consultant, to learn more about her journey across the globe from the U.S. to Barcelona, Spain, and her experience transitioning from teaching to becoming the first hire for MongoDB’s brand-new Enterprise Modernization Team, shifting enterprises toward innovation and generating a ton of compelling content along the way. Andrew Bell: Thank you for sharing your story, Gabriela. I’d love to know how you got to where you are today in your role. What skills are important for someone on your team to be successful? Gabriela Priess: My career journey has been from one end of the spectrum to the other. Originally, I studied English and education, and I was a high school teacher for four years. I loved teaching, and I encourage anyone who wants to pursue it to do just that, but eventually, I hit a block and craved more mobility. So I moved from the U.S. to Portugal and studied web and mobile development. Finding myself back as a junior in a new industry, I worked my way up by freelancing as a web developer, building a curriculum for a coding school, and then quickly finding my way into a lead tech support role with a popular web application organization, where I also led the QA process. So, how does all of this add up to working in and with data? I truly believe every professional experience is the chance to extract something positive — a learning takeaway. This diverse background has challenged me and shaped me, as well as helped me to be confident in my choices, to trust I’m taking steps in the right direction, because ultimately each career move has been better than the last and has led me to where I am now, with MongoDB, as an Enterprise Modernization Consultant. Ultimately a career risk led me to a job that didn’t even exist a year ago on a new team. So, we can never truly say what the future holds for us; we may be headed toward a killer career that hasn’t even been invented yet. When it comes to being successful on my team, I think this role is open to so much diversity. I’m trying to narrow down any specific skills, but I think anyone who is ambitious, independent, takes ownership with what they produce, and is curious will succeed here. Curiosity is a huge asset — someone who is open to learning and diving deep into what they don’t yet understand, eager to keep growing, and tech-curious. A big part of what we do involves us keeping our finger on the pulse of tech and data innovation, so we can confidently discuss, debate, or write about it. This means feeding ourselves with the right tech news content. AB: I’d love to know more about the modernization team. What’s your role and your day-to-day like? GP: Our reach is quite broad, but if I had to define it, I’d say the Enterprise Modernization Team (EMT) assists, educates, and helps inspire large enterprises to move toward modernization and innovation. Often, large enterprises have the most complex, costly legacies in their systems and need macro and micro aid and insights to not only modernize but also to visualize and tally the endpoint. EMT Principles and Consultants have the industry expertise and capability to translate our value proposition to senior executives and engineering management. This includes generating training content for internal teams; meeting with other teams for potential and ongoing accounts; delivering webinars, published content, and interactive exposition presentations; and meeting with clients so they have a stronger understanding of how MongoDB helps them to modernize from the most basic format, such as adopting the document model, to truly leading in innovation, such as data science, machine learning, and real-time analytics. So, EMT is a bridge between sales, technical sales, and marketing for complex industry use cases and solutions. These are the teams we collaborate most often with, working closely with sales reps and solutions architects, collaborating with solution providers, and closely aligning with the marketing team producing diverse content and product alignments. So, if you ask me what exactly is my role, I’d say it’s all of the above. Our team is small, although it’s growing quickly, and we have big plans to expand exponentially in the near future. That said, we have a democratic way of dividing the work. We’re made up of our Global Head, Boris Bialek, our Principal, Steve Dalby, and the two Consultants, including myself and Vanda Friedrichs. And we’re all expected to bring equally to the table, despite who has more seniority. This lets us all have an idea of what everyone is working on, and we frequently dip into each other’s projects either to help out or request aid. Each project is free roaming for all: as long as we’re aware of the objective and deadline, we can get creative with how we reach the endpoint. My projects are constantly evolving and regenerating, and I could joke that the only thing they have in common with each other is they all have to do with MongoDB. However, when I was hired, Boris was very clear and direct that each day would be different, and his promise has held true. I don’t have a day-to-day like most others might in regard to consistent projects, but the objective is always the same for each: how can we showcase MongoDB’s value in modernization and innovation in regards to data and tech? Because my projects are so diverse, and often more creative-oriented than anything else, I make up for what some may call a “lack of structure” by being very structured in how I plan my day. Before each day, I predetermine how my next day is going to be divided hourly by projects, tasks, and follow-ups, and I reserve some time for “self-learning,” where I take time to continue my training curriculum, since that’s an ongoing track. AB: Since this is a new role, what tools and resources (e.g., Sales Bootcamp) were you given to help you ramp up? GP: True, this was a new role when I first stepped in, so I didn’t totally know what to expect. There was a running joke I was learning by a fire hose, just having everything blasted at me, and something was bound to stick. MongoDB sets all employees up with boundless learning resources, so I created a curriculum for myself. I prioritized from the top down, based on what I needed to understand ASAP, such as MongoDB’s services and functions, and from there I had freedom to roam based on what interested me the most and what my weak spots were, and was given time to dive in deep technically. For example, I ran POVs to see the data in action from a locally set up database. I know other teams within the company have established curriculums for onboarding, but because this was a new role, I used the resources available and that worked for me. I was given a lot of liberty with my learning because it was mostly autonomous and self-driven, but that’s not to say my learning is over. The company really promotes a learning culture, and every week there are new resources with webinars, learning materials, training materials, and so on. Early into my onboarding, I participated in what’s called our Sales Bootcamp. It’s a two-week intensive training that dives deep into MongoDB’s services as a whole and lays a strong foundation to build on. It’s usually something that’s done in person at MongoDB’s headquarters in New York City, but since this is the COVID-19 era, it was done virtually, with a big cohort of new hires included from Europe and the Americas. This was a cool experience, because I got to meet a lot of new faces. Professionally, my background is originally in education, so I used to write my own curricula for my students, and I’ve been impressed with what I find the MongoDB enablement and Learning & Development teams generating. AB: What content have you and will you create? What is the purpose of this content? How is it leveraged? GP: Among many other roles, the EMT is a content-generating team, so we’re constantly working on creating something new, or collaborating with other teams to create new content. As of today, I’ve been with MongoDB for four months, and in that short time, I’ve been able to generate a lot of interesting, challenging pieces. Each project I’m given is a chance to dive deeper into that subject and expand my understanding of it — like data science or fintech, for example. One of the first projects I had was the chance to write a blog about MongoDB’s partnership with Iguazio , and how our data platform is the ideal persistence layer for Iguazio’s data science and MLOps platform, which is used to develop, deploy, and manage AI applications. Clearly, each project is a team effort, but this gave me the opportunity to dive into a topic I find personally interesting, while building connections with some of our most innovative partners. My first or second week I was introduced to an internal deck created by one of our Solutions Architects, Pascal Jensen. It was a sort of think piece on how data is being driven by the growing uncertainties of the world, in a political, social, and economic sense, and how the most innovative leading companies are responding. We decided to turn this into a more holistic, complete white paper to reach a wider audience. With that, after really digesting the deck that was available and multiple interviews with the Solutions Architects that contributed to it, I built an extensive paper around it, giving breath to the expression “digital by default.” This was something I was quite proud of, because it was so early on in my time with MongoDB, and it let me dive into truly interesting topics. I was able to build on the holistic elements of data and how it’s reshaping even the most mundane elements of the world, propelling us into the future with innovative technologies and solutions for some of the most crucial global concerns, such as hunger or healthcare. Last month, I presented my first corporate webinar with MongoDB, discussing transitioning from a relational database to MongoDB’s document model. It was a huge opportunity, because we were focusing on Spanish-speaking countries in Latin America. For me, this was almost a beta project, because I didn’t know what to expect in regard to reception. In the end, it was a massive success: overall, we had more than 6,500 registrants. That was a really exciting experience, because I knew as a team and a company we were clearly doing something right, engaging with the right audience, and connecting with the right people. There is a really positive response still outpouring from that webinar, and I was happy to be a part of it, especially as a rookie. Again, it just speaks to how much autonomy and freedom to create I’ve been given. My manager never holds me back from any opportunity and really encourages our success. In the spring, we’ll repeat the same endeavor with another webinar, covering a different topic I’m currently preparing in Spanish. AB: What was it like starting in a new role on a new team, especially during the pandemic? How do you stay connected to the team despite living in different countries? GP: Despite the pandemic, there was a lot to dive into because the company was running full speed ahead. It can be slightly intimidating being the new person on a fast-paced team, but I felt very included and seen from day one, and there was more than enough work and training to keep me busy. I haven’t really considered what it would’ve been like to work with MongoDB prepandemic, because at this point, this is all I’ve known. Staying connected with my direct team, though, has been the easiest part for me. I’ve never once felt disconnected despite never having met them in person. As of now, we’re dispersed across Dublin, London, Zurich, and Barcelona, and we’re growing. Plus, our backgrounds are even more diverse considering where we’ve lived, where we’re from, and the languages we speak. It’s refreshing to be part of a team that doesn’t feel limited to one geographic region, because it opens our minds and team discussions to diverse views and ideas. AB: How would you describe the team’s culture? And how do you maintain this culture during COVID-19? GP: The team culture is really positive, inclusive, and ambitious. Every team meeting feels like a brainstorming session, because part of our job is innovation. We’re all given a voice and are expected to use it as we shuffle through ideas and ongoing projects. But overall, our team culture is casual, in the sense that we engage with each other informally, but we all recognize what we need to be working on and by when. We’re each expected to take ownership of our work, and we’re given a lot of creative and structured autonomy. This means independently owning whatever it is we’re working on, and this goes for professional learning too. MongoDB creates a lot of resources internally that I take advantage of, from guided training and courses to reading material, interactive training, webinars, and so forth. I was paired up with one of our Solutions Architects, Benjamin Schubert, and he patiently made himself available to help guide me through some of the more technical aspects of our databases as I was learning how to maneuver through it myself, and I am eternally grateful. Of course, we have support any time we need it, and I can easily seek out resources or set up a Zoom call with an internal expert if I have any questions, but at the end of the day, the ticker moves forward only if everyone is doing their part, so each of us takes our part seriously. Interested in pursuing a career at MongoDB? We have several open roles on our teams across the globe , and would love you to build your career with us!