Last month, MongoDB unveiled a new “serverless” option for its Atlas MongoDB database service.
The company says Atlas Serverless, now in general availability, can support a wide range of application requirements “with little to no initial configuration and ongoing capacity management.” It can be deployed on all three major cloud providers — Amazon Web ServicesMicrosoft Azure and Google Cloud Platform, with tiered pricing and no upfront commitment.
Shum explained the serverless paradigm by comparing it to Uber. Just as some people prefer cars for extended uses, businesses also tend to buy or rent dedicated servers, or virtual server instances, to run their workloads. But there are many people who only occasionally need an automobile, so there is no need to buy and maintain an automobile. In these cases, a ride-sharing service may be better suited financially. Likewise, serverless services make more sense.
Professional users and free market users can determine what works best for them. There’s a premium in having on-demand car service, but there’s something to be said for never looking for parking in Manhattan or defrosting a windshield.
Who makes the change?
Shum explained that customers in all categories have shown interest in migrating to serverless; he developed a few potential use cases. A specific fit for serverless is for finance and accounting customers where the bulk of their workloads occur at the end of the week, month, or quarter.
Another unique fit for serverless development are development applications where developers work during the day and return home at night or with gaps between feature development. Currently, the main options for these apps are dedicated clusters or a feature that launches something when the developers start working and kills it at the end of the day. Serverless now presents a new possibility.
Legacy applications may also be suitable for serverless development as part of a company’s modernization efforts. “I’m going to modernize and create a brand new app, then I better use the latest and greatest technology,” Shum said. Mission-critical legacy applications looking to include serverless as part of their modernization include massively known HR, payroll, and tax systems around the world.
A new pricing structure for an emerging market
MongoDB saw the serverless options on the market and concluded “it would look weird if we had a serverless offering that always charged you some kind of minimum or required you to get less pre-provisioned server because it would look like a dedicated server,” Shum said.
It refers to other serverless database vendors that require a minimum number of computes to persist data or require high workload customers to pre-purchase a certain number of tiered serverless units provisioned.
Rather than model other serverless offerings, MongoDB went back to what was working now – their dedicated clusters. Research and modeling after dedicated clusters has yielded a few revelations, including that any pricing structure will essentially force a customer to switch to dedicated once they reach a certain volume of usage due to the exorbitant cost.
MongoDB was not eager to present a product to customers they liked, but to price them once their applications really took off. “We want a healthy business with good margins, but fundamentally it’s about the developer experience because we’ve all been there,” Shum said.
MongoDB offered a tiered pricing structure that charges for reads and writes per unit and can start at $0 monthly fees, but: “If you’re doing enough serverless load, it makes sense to us as a business, to encourage that and to try to make that more economically feasible,” he explains. With that, MongoDB lowered the overall price from 30 cents per million to 10 cents per million by 90%. More than Serverless pricing details can be found here.
Not only was the pricing model the biggest challenge in terms of designing the serverless model, but it was also a challenge in terms of adding another level of complexity and granularity to how customers understand their bills. Billing would not be a monthly fee, but billing for reads and writes per unit.
It also gave way to one of the biggest technical challenges of the feature. The database was not configured to track these units and pass them through the cloud control panel and into a billing system, as they never needed to be. So far. This new challenge brought the team back to its fundamental understanding of the database itself.
Shum shares that there are very few people who understand the database in such an intimate way that they can answer questions such as how to track the number of documents scanned and the index keys used to answer a query followed by how to implement, track, and push this data upstream to the cloud control plane and into a billing system.
During the pandemic, meetings were held with all MongoDB veterans, including EVPs and VPs of Query, Engineering, and Storage, to resolve this challenge and challenges like this- this.
Shum said, “Everyone sat in a zoom room and we wondered how can we do this? Where are we going? What are we instrumenting? How do we start collecting? »
Serverless is a very important feature for MongoDB. There are four dedicated full-time engineering teams with serverless in their title, but at any given time there are three to four other engineering teams on database, cloud, automation lasers and billing teams that also work serverless.
Of what Shum said. “I’m lucky to benefit from two things. a) this wave of developers of people who really like serverless and b) lots of people convincing my CPOs and CTOs together that it’s an important concept.
What’s next for Serverless?
Shum confirms that the serverless preview period has been incredibly helpful. There have been huge learning gains on the operations of a serverless product and fleet. The MongoDB team is confident in the current version and recommends it to customers if they are looking for a serverless option.
Currently, the team is working to make serverless functionality closely match that of dedicated clusters. “How can we make sure that the look and feel of serverless is just as complete as this full dedicated offering so you don’t have to feel like you have to choose between the two,” said Shum. The way engineering teams are addressing this challenge right now is to work through the list of serverless documentation limitations.
Over time, Shum explains that MongoDB would like customers to view serverless as a consumption model rather than a concept. If a user doesn’t know its load or volatility, they can consider something serverless. The investment in serverless is not just in a product that developers hope to love, but also in recognition of a broader serverless developer who is gearing up.
There is currently a three to five year roadmap for serverless projects, with most projects being large-scale projects. No new feature release date is available at this time.