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.
Building a Culture of Growth: SVP Simon Eid on MongoDB's Massive Opportunity in APAC
Simon Eid is Senior Vice President Asia-Pacific (APAC) at MongoDB and leads the sales teams across Australia and New Zealand, India, ASEAN, and Japan. Simon's go-to-market organisation in APAC is growing rapidly and has nearly tripled in size in the past three years. They are hiring in all regions . In this article, Simon discusses MongoDB’s opportunity in APAC and how he builds a culture of growth and accountability. Simon Eid, SVP APAC, MongoDB (left) and Anoop Dhankar, RVP ANZ, MongoDB (right) MongoDB's opportunity in Asia-Pacific Out of the top 13 economies by GDP in the world , five of them are located in APAC: China, Japan, Australia, India, and South Korea. And that's to say nothing of the ASEAN countries which alone have more than 650 million inhabitants. Combine this with the worldwide database market, one of the largest markets in the software industry. IDC estimates that it will grow to $137B in 2027, and MongoDB has just reached $1B in ARR. This gives you a sense of the massive market opportunity we have globally. Regardless of industry, product, or service, almost every company is becoming a technology company, which means that every company is becoming a data company. We believe MongoDB is the Developer Data Platform that is best placed to support and accelerate that trend. We’ve already captured thousands of customers around the globe, but it’s important to keep in mind that our world is still in the early stages of shifting to the cloud and changing how applications are built and run. Compared to other software, what's special about the market we play in is that the database is not a “nice-to-have”; it’s mission-critical for organisations. As our world continues to undergo this digital transformation, we have the opportunity to transform how our customers use software and data to innovate, create, and disrupt industries. For example, look at Cathay Pacific , Hong Kong's home airline carrier operating in more than 60 destinations worldwide. The company's digital team turned to MongoDB on their journey to become one of the first airlines to create a truly paperless flight deck. Flight Folder, their application built on MongoDB, consolidates dozens of different information sources into one place. Since the Flight Folder launch, Cathay Pacific has completed more than 340,000 flights with full digital integration in the flight deck. Their innovation is enabled by MongoDB. Building a team across regions and cultures Our team in APAC is unique because of the different markets and cultures within the region. What this means is that we go to market differently in India than we do in Australia, in Singapore than we do in South Korea, and so on. Each market is completely different, but within all of them, there is a huge opportunity. Different from many of our peers, in APAC we've established business leaders who run regionalized teams in India, ASEAN, and ANZ with all functions reporting to them. These teams essentially operate as their own business and implement local best practices into their strategy. But, it doesn’t mean they’re operating in a silo. At the leadership level, there is an immense amount of collaboration and sharing of experiences to identify what’s working and what isn’t within each region. We also have a fantastic global sales organisation that rolls out extensive training and best practices to help enable our local teams to best help our customers and grow the business. Members of our APAC team at a recent offsite in Phuket Culture The most important thing is culture. We have a very high standard around everything we do and how we interact with each other. We don’t entertain politics. You can teach someone new skills and coach them on how to be successful in a new role, but if they’re not aligned with the culture, they will not be a fit. It’s a non-negotiable for me and why the most important aspect of the hiring process is the cultural aspect. If you get the culture right, everything else starts to fall into place. What I hear at MongoDB and from the teams I've built at other companies is that this is the kind of culture they can really thrive and grow. At MongoDB, our culture is defined and shaped by six core values . One of the values that’s most important to my team is “Embrace the Power of Differences”. Within APAC, there are a variety of cultural identities and nuances that can often be difficult to navigate, whether it is cultural values, beliefs, or go-to-market strategy. It’s important that everyone who joins my team is respectful of each other’s regional culture. What we’ve done within the APAC region, and with teams across the globe, is take everyone on a journey to understand and embrace these cultural differences. Our role as leaders is to develop our teams, from the bottom all the way up, which is part of MongoDB’s BDR to CRO career development initiative. We need to develop the next wave of leaders so that they’re prepared to step up when the time comes. For APAC, this means that regardless of where someone is from, each team member has been coached and developed on the cultural nuances so that they can lead people and go to market in each of the different regions. It’s also important that each team member contributes to a culture of psychological safety. Being part of a high-growth tech company requires taking risks and making mistakes. We have a high standard and we hold each other accountable, but it never comes at the cost of creating an environment where people are afraid to fail. When someone faces setbacks, I encourage them to share those experiences so that we can collectively learn. Through mutual support, we foster a stronger team capable of delivering exceptional results. The future of MongoDB in Asia-Pacific For any organisation to be successful, I believe it’s critically important for the entire ecosystem to act as one. As I mentioned earlier, at MongoDB the whole country ecosystem is aligned around one set of goals, so it's not a case of different teams running off in different directions. The teams are willing to lean in and do what's required to help each other build a great business. I can confidently say that in APAC, we are one team. This means sales, marketing, customer success, solutions consulting, and professional services all working together to focus on three things: making customers successful, building technical champions, and driving new workloads. As we continue to grow our team and MongoDB’s footprint in the region, these are the three things that will drive our success. As I mentioned earlier, there's a huge opportunity for MongoDB in APAC. Despite hiring slowing down or stopping completely at many other organisations, we're continuing to invest heavily in the region. To give you a sense of that - we've nearly tripled the size of our APAC go-to-market team in the past three years, and we've got more open roles across the different functions and regions. If you want to be part of this journey, there are three things I want to reiterate: First, we are extremely passionate about our culture, from the field level up to the leadership level. As a team, this is the brand we bring to the market. Second, the opportunity here is massive based on the total addressable market and our current share. And third, we place critical importance on development. By joining this team, I can promise that you’ll be provided with countless opportunities to develop your career and make an impact. I’m confident in my team and the leadership we have in place who are ready to take MongoDB APAC to the next level. Join us !