Um and I'm pleased to intro introduce to

you uh Charlie Shu, John Lewis and Venat

Surupani later on to have a conversation

and we're learning about integrating

MongoDB Atlas with your internal

developer platform. Please give it up

for them. Thank you.

[Music]

That's it.

All right, welcome everybody. Uh as uh

Alex already said, we are from MongoDB.

Both of ourselves here. Charlie is a

senior product manager on our Atlas

team. Uh I'm a product marketing uh

manager here at our team. My mic's not

on.

>> I'm good.

>> All right. Thank you. All right. Sorry.

Uh yeah, so Charlie and I are both at

MongoDB on a really unique and

interesting team uh that we've been

working with uh over the last couple

years around uh working with some of

MongoDB's largest customers with tens of

thousands of employees and and

developers um learning how to run

MongoDB Atlas and MongoDB in general at

just massive scale and the things that

you need to do to not just you know

deploy really large applications but

also handle all the kind of the

behind-the-scenes magic the the

organizational challenges the automation

and and operational challenges is uh to

make that possible with tens of

thousands of developers and at the

beating heart of that is integrating

MongoDB Atlas with some sort of intell

uh internal developer platform and

that's going to be the heart of our

conversation today.

Uh so I'm going to give a little bit of

a preamble a little bit of a teaser as

to why this is like actually important.

Uh there's a lot of hype around building

new things but sometimes the the kind of

the forgotten story forgotten heroes are

actually managing these things and and

running the operations behind the

scenes. So we're going to talk a little

bit about cloud landing zones, mongd

Atlas uh landing zones and how to fold

those into your internal developer

platform and why building one matters,

how you can drive kind of consistency

with your deployments, uh operational

efficiency, developer speed and agility.

um you know kind of some key outcomes

for actually building these things and

Charlie is going to walk us through some

very practical demos on how to actually

get started with this uh you know kind

of start the art of the possible and you

know start beginning some of these best

practices and implementations to bring

this into your enterprise.

So let's kind of set the stage as to why

we are talking about this. Uh the shift

left mentality is not a new concept.

It's been around for several years

really coined kind of with the the boom

of cloud many years ago. Feels like a

very long time at this point. Um, and

the promise when cloud really started

coming to to fruition was that it was

easier for application teams to start

owning more of their stuff, uh, whatever

that stuff may be, operating those those

services, the management of those

services, the security of those

services. Uh, the the promise was that

developers can kind of spin up their own

things, manage their own things, and

take that load off to, you know, just

could be a little bit more autonomous, a

little bit more uh, self- serving. But

there was a bit of a double-edged sword

with that and many enterprises have

realized that that promise. But there

were also a lot of organizations, I'm

sure many of you in the the audience

today, uh, experiencing this cloud

sprawl where there were antiatterns that

emerged from developers doing their own

thing, a lot of operational challenges

that emerged. And candidly, and why I I

put this up on the screen is I think

that this is only going to get harder.

It's only going to become more important

as this AI explosion starts to happen.

uh there's just new technologies, new

development cycles. There's more

pressure to just build more things,

autonomous things. Uh this this is

exponentially more complex. Uh so this

these problems aren't going away. Uh but

I think the opportunity for our teams,

our operations leaders out in the in the

audience are that opportunity is still

here. It's getting even more important

uh you know as this era really comes uh

comes to fruition.

So, you don't have to raise your hands

for this because I know this is a little

uh sometimes a little bit sensitive, but

I will see it in your eyes. The the

horror that emerges, but these are some

of the horror stories that we hear from

some of the biggest enterprises in the

world that run any technology at massive

scale uh across again tens of thousands

of developers. you know, developers

running their own instances and maybe

spinning up a a huge cluster for testing

and then they never turn it off for a

day or weeks or months and then you

never learn about it until you have an

angry CFO uh you know ringing you up or

you know pinging you on Slack asking why

there's this crazy cloud bill coming out

of nowhere. uh or you do an audit and

you see on on your landscape you you do

this audit and you see that there is

just misconfigurations and and shadow

tools everywhere and nobody likes to see

that you know seeing those those audit

results um and I think just more closer

to home operations team is just being

drowned in developer access tickets Jira

tickets manual processes uh and really

it's those manual processes at the end

of the day that we're trying to solve

with internal developer platforms and

and folding Atlas into those

uh but we don't really choose choose to

get to this kind of terrifying horror

state. Um, a great quote I heard from

one of our our customers who leads a

large architecture review board uh kind

of told me that you know all these like

manual operations, these poor developer

experiences, we don't do this on

purpose. Nobody seeks out this

complexity. uh this all kind of happens

from one good decision at a time where

you know one day it's a security process

it's a it's an automation checkpoint

it's a review board it's a a Jira ticket

here you know runbook there and each one

is solving a very important operational

or security consideration at the time

but then what happens is over years or

maybe even decades you take a step back

and then you realize that a developer

experience that we are kind of the

stewards of managing uh is maybe not the

best one and there's this really just

complex manual process behind the

scenes, dozens of various operations and

security and networking type teams uh

who are involved in this important uh

provisioning process but then developers

at the end of the day it might take them

weeks if not months to get that into

some sort of technology. Maybe it's

MongoDB Atlas, maybe it's something else

and that is just not that's a

non-starter for how fast uh software

development is getting and how important

all of us are in you know running our

businesses. Uh so this is really where

we are trying to you know find solutions

with these with these teams. Uh cloud

landing zones and internal developer

platforms are the the solution for this

and that's that's the playground that we

get to play in. So again why does this

matter? I hope I'm really just stressing

this super hard cuz I want to you know

get everybody excited for the day and

make sure that uh you know we're talking

about more than just developers and

development. We're talking about

operations uh because again I think

cloud operations teams have an

increasingly important role as this AI

explosion really starts to come to life

the table stakes of you know ensuring

the security the availability the

performance of your cloud infrastructure

is not going to go away that is that's

table stakes that job is super important

it will always be important uh but I

think what's really interesting talking

to some of these massive enterprises is

that uh the remit of operations teams is

getting larger and I think that's super

exciting like devops and platform

engineering is is an obvious one. Um,

but I'm seeing more and more

architecture and cloud leaders asking

about developer enablement, becoming

coaches and trainers to the developers

that are using their software. They're

not just giving them things, they're

also teaching them how to use them and

use them correctly. Uh, they're also the

leaders in, you know, newer or more

important domains of operations,

emerging domains of operations like

financial operations and AI operations.

You know, they're not just kind of

coming in and solving this problem

multiple years in the future. They're

building a landing zone. they're folding

these operations into their their

foundational posture which is again

making sure that as this AI explosion

happens uh operations is not you know

kind of a a follow on thought or

something that can is going to be

thought about later on. So I'll kind of

leave my preamble to set the stage

really for Charlie to start talking

about the meat of how to build these

things uh by kind of just sharing what

we believe our mission is or the mission

that we see with cloud operations teams

uh these days. Um there's really a

spectrum that we see between speed and

control and there's that spectrum.

Everybody's going to fall on a different

kind of piece of that spectrum here. Uh

but this is what a landing zone and an

internal developer platform lets you

really realize. Uh on the one hand you

might be really interested in speed.

Making sure that developers can build as

fast as possible with as little friction

as possible. Maybe that means

self-service access into something like

MongoDB Atlas. you know, standardized

workflows, guidance, runbooks, all of

these things are designed to help

developers be autonomous within some

level of control and guardrails. Um, if

that sounds terrifying, many

organizations definitely lean on the

other side of control. Things like

enforcing those security and compliance

requirements that are just so important

and cannot be forgotten. You know,

making sure that infrastructure is

rightsized, all the teams that matter

like operations, finance, procurement

have visibility into what's going on

with a very large fleet. Uh so I think

really the point of this this session

this the point of landing zones and

internal developer platforms is

understanding what this spectrum is.

This is our mission and how do we

actually make this real in the

enterprise instead of just you know

theory. Um so with that you know Charlie

I'm going to pass it over to you and

have you double click into what a

landing zone actually is and how you

should get started uh building one in

your organization.

>> Yeah absolutely couldn't have said it

better myself John. So a natural

question arises, how do we balance speed

and control in the enterprise? And our

answer is using Atlas landing zones.

Landing zones are a framework that

allows us to define pre-approved Atlas

environments for developers upon

request. And these become the default

starting points for new infrastructure

that's provisioned. So set in a simple

way, it's a template. Now what can this

template comprise? And we as platform

engineering teams care about security,

governance, and compliance of all of our

cloud infrastructure. So templates give

us the ability to predefine many layers

of parameters for the cloud

infrastructure along areas such as

sizing networking security and

access, but still gives developers the

ability to configure the parameters that

most impact their application's

performance.

Now let's talk through one example

configuration template and let's say

that it's focused on a specific use case

a database with restricted data. So when

a new MongoDB cluster is required that

has data that we as an organization has

have flagged as restricted we as a

platform engineering team might say all

clusters of this type need things like

atlas authentication via SSO in the

corporate directory. It might require a

replica set and allow the customer or

the application team to manage the keys.

But we also might say there are a couple

elements of configuration that this

development team can and should be able

to configure. They should be able to

configure a t-shirt instance size for

the cluster tier and we'd map that to an

Atlas M50. And they might also be able

to select AWS as the provider and say

that the region that the cluster should

be in is Zurich and they might be able

to choose from a very small number of uh

permitted options for this template.

So if the landing zone gives us the

ability to define these templates, the

developer platform is how we make these

templates available to developers.

So we'll talk through a layer a couple

different layers of the stack here and

then go into the demo. In my experience,

these developer platforms have many

different shapes and sizes, but they

always contain a couple common layers of

the stack. The first is a developer

control plane. So this developer control

plane uses a developer portal to give

developers the ability to define their

infrastructure as code. Using an IDE,

developers uh make changes to this infra

as code and use something like GitHub to

version control it. Now when a change is

picked up in GitHub, a CI pipeline will

pass this configuration change to let's

say a Docker uh instance that is running

an instance of Argo CD as a CD pipeline.

And this is what allows the changes in

the code definition of infrastructure to

be passed to the resource plane.

Now what cannot be forgotten is the

concept of observability with a tool

like data dog and secure and secrets and

identity management using something like

Kashi core vault. And these layers

together allow us to provide

infrastructure to developers in a

seamless way while still providing speed

and a balance of control by giving us as

the platform team the ability to enforce

standards across all of our cloud

infrastructure.

Now going into our demo a little bit,

we're going to focus a little bit less

on observability and security. Obviously

important, but focus less here. and

we'll demo a little bit about how um

infrastructure can be defined as code

changes picked up and then passed to the

resource plane. So to structure this a

little bit um well I guess before we

move into that what I wanted to first uh

share a thought on is why build all of

this why invest in building a developer

platform and it's really to enable

what's on the right there reducing

developers cognitive load so that they

can move faster and speed them up but

still maintaining and protecting our

organizations security posture and

providing visibility for operations

teams in finance. And we do this all by

streamlining our operations via

automation via this developer platform.

So the structure of our demo is going to

comprise a couple different areas. We'll

do a little bit of an overview of um the

platform team developer workflows. Talk

a little bit about our user personas.

We'll walk through configuration of an

example developer platform. We'll walk

through the workflow of how a de a a

development team can use this platform

to automatically create infrastructure

and then finally make a config change

after that day zero day one activity.

How do we change and manage the

configuration of this infrastructure

over time?

So our two main personas here first the

appdev users we'll call them the

development team at the top left there

and the platform engineering team.

They're using the developer platform

backstage.io IO which creates a GitHub

repo for the developers maintains the

code and configuration change and

changes and passes these to terraform to

have these changes reviewed and applied.

So focusing first a little bit on the

platform engineering team. What I as a

platform engineering team what I as a

platform engineering team care most

about is making different layers of

cloud infrastructure available to my

developer base. I as a team might uh

provide or manage dozens or even

hundreds of different layers of the

stack and backstage.io as an example

developer platform is really useful to

me because it provides a single place

for all the developers to go to in order

to provision, discover and manage

infrastructure.

And I'm going to configure this

backstage instance to create a GitHub

repo on behalf of developers that

contain their elements of configuration,

but also standards that I want applied

to every single cluster or piece of

infrastructure across the estate and

then enable them to use a GitHub pull

request flow in order to manage their

infrastructure. So let's go look at a at

a YAML file here that could be passed

into Backstage. So a couple different

important components here. The first is

the types of parameters that we want to

expose to the development team. You can

see in the YAML file here that region is

something that we as a platform

engineering team might say developers

can configure. And there's a subset of

regions that we allow them provision.

Maybe we want all of our data to be in

the continental US. So we expose US

East1 and US West one as two regions

that are accessible to our developers to

when they use Atlas. The second is

instance size. We might have guard rails

on the types of instance on the types of

instances that developers should be able

to provision. And in that example there,

I had chosen M10, M20, and M30 as the

three that are allowed. But we know that

Atlas supports many different types. And

then finally, setting up this GitHub

repo involves creating a number of

different automation steps. An important

one being copying GitHub actions into

the repo, creating the repo and also

pushing the skeleton Terraform templates

to this repo. So we're enabling a lot on

behalf of developers through this

preconfiguration and automation steps.

And when I go into the backstage portal

and ingest this YAML file, what this

means is I as as a platform team have

given developers the ability to

provision components. And when we go

ahead and create click the create button

there, they're able to select the Atlas

production Terraform template which is

the example we were looking at on the

right, they can choose that one and then

start the development team workflow that

we'll cover next. So the key takeaway

here is I as a platform engineering team

have determined a number of sensible

defaults but also given the appdev team

the ability to configure certain

elements of configuration.

So moving on to the application

development team. The development team

I as a developer on um a feature

building team really care about building

my application and want easy and simple

access to layers of infrastructure that

enable me to do this. But I know that

perhaps at my company there might be

again dozens or hundreds of pieces of

infrastructure that are approved and I

don't know the nuances of all of them.

And I want to make sure that any

infrastructure that I provision still

conforms to the platform engineering

team's security, governance and

compliance requirements and just want to

configure the portions that are most

useful to me. So backstage is useful to

me as a developer because it gives me

all of that. It gives me that

discoverability and um the ability to

tune and configure those different

parameters there. And it also sets up

the pull request so that I can ask John

and my engineering team to approve any

changes that I'm proposing as part of

this. So when I go to backstage and want

to provision a component that represents

a layer of my stack again um I will go

ahead and click that create button um

that creates components that essentially

represent layers of the stack or entire

applications similar to the prior video.

I'll go ahead and click the production

Terraform template uh because this is

the one that my team has assessed as

most relevant to our needs and fill out

the pieces of configuration that are

important to my application. Let's say

that I know that most of the users of my

new feature in in maybe let's say a

prototyping phase are going to be in the

East Coast. So, we're going to choose US

East1 and we're also going to choose an

M10 cluster tier because this is the

prototype. So I fill in a a couple

pieces of metadata and the automation

that my platform engineering team has

defined for me runs and you can see a

couple different important steps in

there. Some being like creating that

repo like we saw in the YAML definition,

bringing in the Terraform skeleton and

opening a pull request for this cluster

creation. I can review the logs of this

automation and then go to my feature

repo uh that is owned by my wonderful

solutions architect. go to the landing

zone demo repo and see the repo that has

been created for me. And this is done

live seamlessly by backstage because of

the automation steps that have been um

defined by my platform engineering team.

There's some content in here reflecting

the GitHub workflows and and crucially a

pull request has been open for the

creation of my new cluster. So when I go

into the pull request, you can see it

start to show um some elements of

Terraform that you're probably familiar

with. It's validated the syntax of my

Terraform scripts. It has initialized

the Terraform project. It has run a plan

and it is showing that the configuration

options that I as a dev team have chosen

are in this plan. but also maybe like a

dozen or more sensible defaults

configured by the platform team are also

injected and injected into the plan for

this um new piece of infrastructure I'm

provisioning and when I go ahead and

merge that pull request after say John

has reviewed and approved I go to the

GitHub action and can see that it is now

being applied. So um I've create I'm

using the GitHub uh approval workflow

that all of us are familiar with to

manage my infrastructure as well and

using Terraform to enable the actual

application of those code definitions of

infrastructure to Atlas. So now say some

time down the line we John and I worked

on a feature for a month and it went

really well. It's a prototype. Uh we we

developed it in a hackathon and we now

uh want to start bringing more users

onto this prototype. You can imagine

like 1 2 3 months down the line that

there are configuration changes that we

we might want to make to this

infrastructure. So as as a development

team what I want to do now is use the

backstage instance and the repo that was

created to modify the uh configuration

of the infrastructure that has been

defined. So I'm going as a as an app

team going to open a pull request,

change the configuration, have John

approve it, and then have those changes

applied. So if I go into my repo again,

you can see the original cluster

creation Terraform apply has run and it

has created the cluster in Atlas on my

behalf. So if we click open terraform

apply, you can see that after some time

the cluster was created. takes a little

bit to provision the compute.

And once I'm happy with this, I can go

into the code definition of my

infrastructure. And you can see that

this step created a Terraform folder

that has definitions of, among other

things, my Atlas cluster, which I'm

going to change,

but also database users, IP access

lists, our Terraform provider, all

syntax that you're probably familiar

with. Crucially, it has the Terraform

state that is maintained for all of my

infrastructure in Atlas. And the file

that I'm going to change in order to

change the instance size is my TF varss.

And this file will probably look

familiar from a configuration

perspective. It is the small set of

configuration items that my platform

team has said I can configure and also

provides me simple access to just the

resources and syntax that is familiar to

me from an application perspective. So,

I'll go ahead and say that I want this

to be an M20. Now, we want a little bit

more storage space. We want a little bit

more compute capacity. And we're going

to create this as a new branch to start

the review process. So, I'm going to

create this branch um and create the

pull request.

And after a little bit, our GitHub

action to run the Terraform plan and

validate this syntax change. Make sure I

chose a valid cluster tier, for example,

will run. And this is a good time for me

as an engineer to add my peers such as

John to review this poll request to make

sure that the changes that I'm proposing

as part of this match will be we agreed

to as a team as a team in our spec. And

when I open that show plan, you can see

that it confirms I'm modifying that

landing zone demo cluster. And

crucially, only the instance tier is

changing from an M10 M20. And all of the

other defaults, all of my other

configuration is remaining the same. and

it's confirming that I want to change

here. And then once John, for example,

has approved this change, I can go ahead

and um merge that pull request

after it's been reviewed by by the rest

of the engineering team.

And scroll down,

merge that pull request, and then it's

going to um run the same GitHub action

to apply these changes to our

infrastructure. So we've used that same

GitHub approval workflow that we all

know and love and have modified our

infrastructure as part of that. So

bringing it all back, ask yourselves why

do we want to do this? How do like why

is this balancing speed and control?

It's really doing this by uh using

building platforms and processes that

enable our organization's requirements

to be built into automation and not be

something that we all need to go through

and review every single time a change is

made. Landing zones are the framework

that give us the ability to define these

templates and developer platforms are

how we make it available to our

developers to consume and um become

discoverable as part of all of the

different layers with the stack that we

our development teams have access to.

And one last thought that I'll share is

we went through a pretty built out demo

here using automation, GitHub, um

backstage. You don't need to go the

whole enchilada. You can start small.

You can start with processes and scripts

um that run on a developer's laptop and

start with lower environments and slowly

scale these up all with a focus of

helping your uh management of

infrastructure via automation mature. So

with that, I'll hand it back over to

John.

>> Yeah, and I think that that last point

about just the focus on increasing

maturity, I think that's really the name

of the game, 1% everyday type

improvements where you don't need to go

out and build this massive internal

developer platform. We've seen

enterprises that have really

sophisticated teams and really

sophisticated platforms, but it takes

time to get there. Uh so something that

we've been investing in at MongoDB is

just a variety of resources and programs

uh in addition to our products and our

automation products and our operations

products. Uh trying to build more

resources to help you get started with

this. Uh so the one of the most one of

the more interesting uh launches that

I've had my the privilege to work on

over the last several years at uh

has been the the well architected

framework for Atlas and the Atlas

architecture center uh which went live a

little bit earlier this year. And in

this it's an extension of our

documentation and it has a lot of very

practical hands-on um you know overviews

and components and best practices

Terraform scripts and you know

automation scripts. There's a lot of of

of good content in there to help you

start understanding, you know, if I want

to increase my maturity with MongoDB

Atlas specifically, you know, what can I

get started with? What can I do in

security? What can I do in operational

efficiency? And that's a that's a

resource that we're investing in all the

time. Uh there's a really robust version

log on there. So, if you're looking to

start bringing some of these these

practices specifically to MongoDB Atlas

into your your organization, it's a

fantastic starting point. Um, and of

course, if you do need help with this,

we have a variety of programs and and

teams who can help you build this

hands-on as well. You know, we have a

pretty robust methodology for figuring

out how to, you know, design your your

processes, your frameworks, uh, design

your landing zone and then start

building it and running it with your

developers in in in the real world. uh

you know whether that's actually

building all this stuff or again just

creating documentation, creating

training programs, helping you spread

the word and kind of put you into that

position where you're not just again

providing infrastructure to developers,

but you're actually helping them be

successful uh whether it's with us or

with other technologies.

So with that, I know we got a few more

minutes left in our our little session

here before we bring on Venat to talk

about uh what they're doing at Avalara.

So I'll pause here for some Q&A. Um, is

there anybody who has any questions

about kind of what we've been talking

about here or getting started with

building landing zones? Um, you know, in

the meantime, I'll leave some QR codes

for some of these resources that we

have. Um, some of our tooling and some

of our learning paths, but uh, yeah, are

there any questions about getting

started with this in your organization?

Thank you. All right. just just trying

to get my head around this this uh

framework, right? Um so in a scenario if

I have like uh hundreds of

clusters, so will I end up having uh one

repository per each cluster with this

kind of a model?

>> It's definitely customizable based on

your organization's requirements. We

have seen uh customers where a DB team

is responsible for maintaining all

clusters have the definition for all of

these be in one repository and have a

process using pull request reviews to

allow um the application teams to open

pull requests for these changes. In more

dispersed organizations where the

application teams own the infrastructure

as well, um you could have a world where

uh each application has its own repo

with its own cluster or perhaps like one

team would have a repo for all of its

clusters. So using our API and

Terraform, it's fully customizable.

>> Okay. So the the Terraform is making use

of your APIs to create the clusters

essentially.

>> That's right.

>> Okay. Thank you.

>> Yeah, of course. Great question.

Do we have any other questions or

>> All right. Well, in that case then, um,

Denat's asking a question.

>> U, thank you, John and Charlie. Um, I

just wanted to, you know, appreciate the

way that

uh the demo actually uh worked great. So

the the thing is, isn't it amazing that

your entire infrastructure has been uh

scripted out into a Terraform state

files and then stored in your GitHub

repository and then using the internal

developer platform tool to deploy all of

those policies in in a single click of a

button that you know think about imagine

you know you have your clusters running

uh in AWS and you just wanted to deploy

them to GCP or move to move from Atlas

cloud to an on-prem cloud. Now you have

all of your infrastructure scripted out

as a policy and you have a CI/CD

pipeline to just deploy it. It's just a

matter of changing few parameters and

run it wherever you wanted to. So that's

then amazing uh you know scripted and

platform way of deploying the things in

easy way.

>> Yeah 100%. I think you hit hit the nail

on the head changing something like a

provider adding nodes for example is all

a code change that will be executed by

the uh platform provider and API. Yeah,

I think what's really important with

this, we were kind of saying this at the

beginning is, you know, this is the

tooling and that is the tooling is what

makes this real. It's what makes

developers actually, you know, access

these things. Um, but building a landing

zone and the well architected framework

and all that is is really also a

strategic kind of choice. It is the the

very first step is designing like what

are those steps or those processes,

those constraints, those limitations and

sometimes those are just found in, you

know, random documentations or wiks or

Jira processes or whatever it is. Uh but

the idea to your point over time is

codifying that into these modules into

these automation scripts putting it into

the platform to make it you know part of

the product that you manage instead of

being a process that's kind of managing

you.

>> Right. Absolutely.

>> Awesome. Well with that if you do have

any additional questions Charlie and I

will be floating around after the

session uh to you know we can always

answer your questions there. Uh but for

now I guess I'll bring up Venat from

Avalara to talk a little bit more about

their use with Mugab.

Thank you, John.

>> All right.

I think I'm supposed to put on that one.

Perfect. All right. Well, welcome back.

Uh, you know, if you want to, you know,

kind of kick us off here and tell us a

little bit about yourself and Avalara to

again set the stage for, uh, how you've

been using MongoDB.

>> Sure. Thank you, John and Charlie, uh,

for inviting me here and I'm very

pleased to be with you all today this

morning. Uh before we dive in um I just

wanted to tease the audience quick show

of their hands. How many of you have

heard of Avalara or have you worked with

Avalara tax compliance products in in

some integrations along the way? Does

any of you uh have know about Avala or

worked with Avala in the past?

All right. So there is one raise hand.

So and and those of you who have seen um

our TV advertisement or know our brand

uh do you happen to remember our tagline

like what is the Avalar tagline on the

bottom?

All right. So the tagline is very uh

simple. So we make tax compliance less

taxing and more relaxing. So if you look

into the real advertisement it's more

relaxed. So, so that's what the story is

all about today. So, how we scaled that

mission uh with MongoDB server millions

of global um transactions um in real

time across multi cloud platforms. So,

that's what I'm going to talk about

today. Um so,

um so Avalara

is a cloudnative um global tax

compliance organization. So at core of

our mission is to help our businesses

um enabling the um the tax compliance uh

easily, efficiently and accurately. So

the businesses need not to worry about

uh the changes of the tax complex tax

rules or the deadlines of the you know

tax returns filing. So it's it's it's

make our uh makes the business uh

business's tax compliance life easy. So

our vision is to be a part of every

transaction in the world and helping our

businesses of all sizes addressing the

tax compliance needs. So what I do at

Avlara so um I'm a principal architect

at Avlara um I so where I lead the large

scale data platform engineering um and

the AI architecture initiatives. So our

shared platform services team is

responsible for building scalable,

resilient and highly intelligent systems

um

that uh Avlar's um supporting the global

uh tax compliance services including you

know some of the services like Avatax

and returns. So in core at Avlara we

build the principles of simplicity,

ownership and innovation ensuring that

you know we support all the uh the

Avala's global tax compliance

initiatives. I'll back to you John.

>> Thank you Vanc. I think uh you know

before we kind of move on to your use

case I do have to say as a marketer

myself I really do appreciate your your

company's tagline. I think building

planet scale systems like this is very

very hard. I think just right below that

in terms of difficulty is naming things

and coming up with really good marketing

taglines. So I do have to say I really

deeply appreciate that. Um so you know

tell us a little bit more about uh what

brought Avalara to MongoDB in the first

place. So what was that major project or

major uh you know application that you

know really made you say you know we

need MongoDB for this?

>> Yeah sure John. So we um

so the problems uh that we were solved

with within our legacy technology

systems is our back in the days uh of in

2020. So we were running our um largest

global tax compliance system transaction

store running on the SQL um the legacy

SQL systems were limited our ability to

go or expand into into our planet scale

uh to hundreds of billions of

transactions. So the OLTP workloads were

failing to meet our uh you know P99 and

P95 latency or SLA requirements. uh the

tax domain and compliance industry

itself has a very strict requirements on

ultra low latency and a very massive

data growth and high availability

requirements um and then also like you

know analytics and and reporting systems

are uh you know timing out on the legacy

systems having um a customer delays. So

all of that uh you know we need a

platform to uh um and also like you know

our platform need to support uh geo

redundancy and resiliency across various

clouds um and regions. So we need to

replplatform um our avatax into a modern

intelligent uh global edge computing uh

to support our real-time AI co-pilots

and decision-m systems. So as part of

that uh replplatforming architecture um

um we chose MongoDB Atlas um as the

foundation layer in our uh global

architecture team um as part of our

project polaris and project active

active um due to this flexible MongoDB

schema and then uh the high availability

architecture and then and then

supporting the multicloud geo redundancy

infrastructure. So that's how we we

chose MongoDB as our one one of the

foundational uh platform component um in

our data infrastructure stack.

>> Awesome. Thank you Vic. And can you

maybe double click a little bit more on

what project Polaris specifically was um

and kind of how you approached doing a

project of that scale.

>> Sure. Um so as I explained MongoDB Atlas

was chosen as a foundational layer uh in

the project project Polaris. Um so the

project Polaris which we uh you know

started around back in 2020 which was a

modernization effort uh for the Avalar

uh monolithic data infrastructure um

moving into a unified distributed

platform um using MongoDB Atlas um and

also other modern systems like Snowflake

and Kafka and other um other systems to

support our um low latency and um and

high availability based tax compliance

and analytics systems. So that that's

the first project that we use MongoDB as

a backend and we successfully

transitioned from our legacy systems

into our MongoDB atlasbased systems uh

at at the middle or end of the 2022.

That's about project polaris.

>> Yeah. And I recognize that was a very

large migration project. So what was

some of the uh some of the benefits that

kind of came out of that? I know you're

already touching on them a little bit,

but what were some of like the business

impacts or the customer impacts that you

your team has found by moving to MongoDB

Atlas from your legacy SQL monolith?

>> Absolutely. So the the business benefits

or the impact uh has been substantial.

So we created a unified real-time

platform. MongoDB Atlas enabled um us to

consolidate the legacy systems into a

modern um operational data layer uh that

supports uh the scalable ingestion, low

latency based queries and then flexible

data modeling. And then we actually

improved the global resiliency um and

availability uh by deploying um into uh

multiple regions uh and then failing

over uh you know beyond a single region

and also increasing our durability uh

beyond a single node. And then we also

uh did a um uh we also achieved a cost

optimization as well. Consolidating

workloads into MongoDB reduced our

operational burden and then cost

associated with managing desperate data

sources has improved a lot and finally

the developer velocity. So now Atlas

flexible schema and manage services

allowed us to onboard the engineers

faster reduce the operational toil um

and then the the focus on the

innovation. So those are the key

benefits that we have realized after we

migrating into an Atlas data Atlas

developer data cloud platform from the

legacy SQL systems.

>> Awesome. So I know that was already one

very large migration project and you are

currently looking at doing a very

another very large project with this

active active kind of multi cloud

architecture you're looking to build

out. Now I know you have a session on

that later today. So uh don't want to

spoil it too much. Anybody here who

wants to to join that you know make sure

you tune in uh later this afternoon for

that. uh but do you want to give a

little bit of a teaser on what that

project is and you again like why you're

choosing MongoDB to be for that uh for

that project?

>> Absolutely John. So as I explained

project Polaris was our u um the

foundational uh uplift on our um

platform on our storage platform

migrating from legacy SQL into a

modernized data platform distributed

data platform MongoDB. Um and uh and as

part of that um as I said we migrated

into a single central cloud um located

in AWS where all the customer data is

located over there and now we are

building uh layering on top of the

project polaris. If you double click on

that that is called as a project active

active. So while the project polaris

laid the uh the foundation of

modernizing our data stack and enabling

the AIdriven insight, the project active

active takes that transformation into

the next level. The the initiative is

all about building true cloud resilience

um and global scale for our flagshiping

product Avatax and expanding it into

other uh Avlar systems. So um so the

operational um so at at its core active

active enables uh simultaneous real-time

operations across multiple cloud

providers across AWS OCP and OCI and GCP

and and soon Azure uh so we can serve uh

our global customers uh from the nearest

active active uh sites with a minimal

latency as you all remember uh the Dave

was talking in the morning so we meet

the customers at the edge

Uh and then also the uh Bor is talking

about uh uh one database all

environments that's exactly what we're

trying to do. So um active active

project is about um serving our

customers where they are located

bringing Avalara systems close to the

customers where they are located by

helping them to uh you know do the tax

compliance at the edge. Um so we can

serve the global customers from the

nearest active site with the active

sites with minimal latency, hot failover

and no downtime. So and also the think

about ransomware protection and

crosscloud disaster recovery, AI ready

vector search and intelligent traffic

patterns like all working in real time.

So this isn't this isn't just about an

uptime migrating from one cloud to other

cloud. It's about delivering the

intelligent tax compliance at the edge

uh wherever our customers do the

business. So um if you if you happen to

uh if you wanted to know uh more about

this so I'll be diving deep into the uh

the actual architecture use case and our

journey into uh active active platform

uh in our afternoon video recording

session with the customer marketing

team. uh once it's it's not a live

session but it's a recorded uh session

once it is available um you know you can

uh listen to it later on.

>> Awesome. Thank you so much. And I think

uh something that I'm I'm I'm really

interested in hearing about is how uh

when you look at projects of this scale,

you know, bringing Mongd Atlas to

critical workloads, you know,

international workloads, tons of

developers. uh you know like what's like

one tip that you would give to uh a a

technology team looking to maybe adopt

MongoDB for the first time or do a very

large project a migration project on

their own you know what's what's that

one tip that you would uh that you've

learned that you would like others to

>> right that's a great question so we were

also listening about the application

modernization platform migration from

legacy systems to a modern data systems

so this is all music to our ears but the

the biggest piece of advice that I can

give while migrating ing a largest uh

you know migrations into the modern

distributed database systems like

MongoDB is is to balance speed,

performance, time and cost governance.

So uh large migrations especially the

cohort-based migrations like you don't

want to do a lift and shift of all of

your customers from a legacy systems

into a new system. you wanted to split

your customers into cohorts and you

wanted to migrate each cohort them uh

cohort them and then understanding your

business risk of each customer and

migrate each one of them separately. So

when you do the cohort by cohort

migrations where the old systems and the

new systems are running in parallel so

that can balloon your infrastructure

cost that is like you know you would be

uh you know paying a bubble cost for a

short period of time. So if you're not

careful with those uh you know planning

of those cost so uh the cost will

increase significantly. So my

recommendation is be realistic about

migrations timelines um and then um and

then do a you know thorough testing um

with the human resources and the budget

impact and the performance trade-offs.

So build um build time for the valuation

cycles and roll backs. So it's not just

about a technical challenge, it's it's

about the operational and financial one.

So getting that right can make the

difference between a smooth roll out and

a runway project. So be careful about

those migrations and and prep for the

large migrations ahead of time. Awesome.

Thank you so much. Yeah, I music to my

ears hearing about you know it's not

just about doing the work but you know

building a framework and a process

around balancing the trade-offs between

kind of going fast and you know adding

in some some some testing and and

breaking things down so you can fail

back if you need to. So it's very

exciting exciting project. Um so that

does leave us with our time here. So if

you do have any questions for Venad or

ourselves after the session uh

definitely we're going to be hovering

around after to uh you know if you want

to learn a little bit more about these

projects project Polaris Avalara um and

what they're doing with this act of

active architecture or you want to learn

a little bit more about internal

developer platforms and how to get

started with those you know find Charlie

myself and Venet after the session and

we're more than happy to to double click

on you on double click with uh on that

with you uh we'll also be at the product

booth for going to be at the end um

which we will double click a little bit

more into this as well.

>> Yeah. So whoever have they raised hands

uh for the interest of time so I would

love to talk to him off off the stage

because uh the next session is going to

start here soon. So I would be happy to

answer your questions.

>> Awesome. Thank you. Thank you so much.