Posted on mongodb google news. Visit mongodb google news

Presented by MongoDB

“Identity is the new security perimeter,” says Shiv Ramji, chief product officer at Auth0. “Think about how many applications you logged into just this morning. All of those need a seamless, highly secure login experience.”

Ramji spoke about how mission-critical user identity and authentication has become during his fireside chat at at VB Transform 2022, “How to re-engineer global platforms for our multi-cloud reality.” 

This issue today is that too many companies rely on custom integrations to implement secure login, single sign-on (SSO) and other identity needs across each of their touchpoints. From there, issues like inconsistencies in the user experience, which can create friction or even barriers for access, can creep in. And as customer identity (CIAM) technology has evolved, many also have struggled to easily add multi-factor authentication and passwordless or social login. And all those challenges together mean everything from lower conversion rates to security issues and increased developer costs.

Auth0, which was recently acquired by Okta, was built to meet these challenges for its customers. The platform currently powers login experiences for consumer and SaaS applications that are built from the start on the MongoDB developer data platform. Okta now serves more than 15,800 customers globally.

“As the company started scaling, we had to make sure that our login service can scale to billions of logins per month — we have customers with millions of consumers who are constantly logging in to access services,” Ramji says. “We have to be able to support that level of scale.”

The database is obviously not the only part of the stack. But it is the foundation, making it possible to more easily build the application and the database that powers it behind the scenes, end to end, with security best practices built in. Here’s a look at Auth0’s database journey.

Choosing a database layer

Choosing the right database provider has been key to the company’s success from the start. The database layer sits in a critical part of the Auth0 stack, as a piece of the platform’s authentication and authorization pipeline. Customers can be deployed in either a shared or multi-tenant environment, or in dedicated environments, depending on their needs and what makes sense for their architecture. The service was initially on AWS primarily, but they have also embraced Azure, and Ramji expects they will continue to expand.

“When we thought about the database technology that we were using or picking, we wanted to make sure we could use the same technology regardless of the cloud provider,” he says. “In the future, as customers demand support for other clouds, we should be able to support that with technology that works.”

The other areas in which their choice of database was critical were availability and geo-failover capabilities — especially given the SLA commitments they’ve made to their customers. And the last piece is scale.

“We wanted the database technology to be able to scale as our customers scale or as we scale. It was critical for us to work with a database technology that’s going to be able to scale,” he says. “And like any other SaaS platform, we’re always looking to have operational efficiencies, removing any undifferentiated heavy lifting that we’re doing, and working with vendors who can take that on for us.”

From self-managed to automation

Auth0 began with a self-managed solution, with MongoDB instances — and that became a bottleneck. Initially, when scaling with different geographies and customers, a big need was the ability to launch new environments. But the time for environment creation kept creeping up, until it was taking three or four months in some instances.

When Ramji joined Auth0, part of his goal was to methodically bring that down from three months to three weeks. He’s surpassed that goal. Recently, between replatforming their private cloud offering onto Kubernetes and adopting MongoDB Atlas, a fully managed database service, that time is now down to two hours.

“Just think about the orders of magnitude impact that we can have in terms of the ability to spin up new environments and meet our customers’ needs,” he said.

The operational burden on the engineering teams has lifted significantly, and now they’re able to meet their commitments to an RPO target of less than one minute, and an RTO target of less than 15 minutes. Atlas has also helped Auth0 embrace migrations as a core capability for its customers, which are constantly right-sizing their environments, launching in new geos or markets, and needing to spin up new environments and migrate customers over quickly.

“Some of our customers in the dedicated environment could have 30,000 tenants,” he said, “We want to be able to seamlessly move them over into a new environment. That was why we went down this route of moving to a managed service, so that we could serve our customers the way we want to.”

Meeting the challenges of migrations at scale

In large-scale migrations, with thousands of customers, who then have thousands of tenants, and then millions of consumers who are logging in, production scenarios are always a very delicate balance, Ramji said. 

The first challenge was to right-size its large collections in its self-managed and self-hosted environments, because some of those services were storing far too much unnecessary data. From there, they ironed out the kinks in a staging environment before moving to the production environment. It took a tremendous amount of testing, and initially launching in smaller or lower traffic regions to lower the impact of any quirks. Eventually that progressive rollout strategy helped them grow skilled enough to make rollouts invisible to customers.

The MongoDB team helped Auth0 manage the process of replatforming and rolling out seamlessly, Ramji said, from developing a strategy and testing support to feedback on challenges and offering internal or external resources.

Best practices and lessons learned

Whether you’re beginning database migrations, or taking on a big platform re-architecture or modernization, there are some key things to keep in mind before you ever start. Lesson number one for Ramji was reframing the objective of the project to ensure executive buy-in. Rather than positioning it as a way to pay down the tech debt, which was slowing the company down, they looked at it as a way to unlock future value.

“We really made sure that the positioning of this was focused on customer value, as opposed to internal hurdles,” he explained. “In our case, future value means we can deploy to a new cloud, Azure. We can deploy features faster because we have parity across both deployment types.”

And secondly, when you’re taking on a big database migration, cut the problem down into smaller bites. For instance, Auth0 reduced the size of their collections before starting the migration, and made sure they had tested it in different environments before starting the production migration.

“And where we didn’t have the answers, we partnered with teams like MongoDB to ensure that if there were things we didn’t know, we were able to get the right contextual help that was required to do that,” Ramji said.

Learn more here about MongoDB Atlas, our multi-cloud developer data platform and try it free forever here.

Sponsored articles are content produced by a company that is either paying for the post or has a business relationship with VentureBeat, and they’re always clearly marked. Content produced by our editorial team is never influenced by advertisers or sponsors in any way. For more information, contact sales@venturebeat.com.

Article originally posted on mongodb google news. Visit mongodb google news