Fireside Chat with Amazon

Share with

Transcript

Hello, everyone. Thanks for coming. My name is, Philip Hack. I'm the solution account manager for Amazon.

I work with Salesforce. I'm Salesforce employee, and I have up here with me, Nikhil Reddy from Buy With Prime. Sure. Excited to have him up here.

So, Nikhil, may start.

Telling us a little bit about yourself for the audience.

Sure. So I started working for Amazon for over two and a half years, and, this is my second team working in Amazon. And now I work for Bovid's Prime. I work with a lot of Salesforce, implementation in the past as well as release management in the past, for different companies.

And, that's the reason why I love DevOps so much, and, adoption of DevOps is one of my key, and that's why we're here.

Awesome.

You mentioned buy with prime. I know prime because I have boxes constantly showing up to my house. There's probably like two waiting for me when I get home. Can can you tell everyone else in the audience that might not know what buy with prime is a little bit more about buy with prime?

Sure. And thanks for being our prime member.

So so prime is one of the main important thing that grew up Amazon. Look, Amazon's so big. And with buy with prime, we're expanding that to merchants so that they can implement on their own DTC websites and drive their traffic as well. So think about you're shopping on a different website, but using buy with using prime, shipping, prime promise of customer support there, and you get, like, free shipping and, two day shipping from a different website. How cool is that?

As long as it doesn't go on certain websites that my wife shops at, that's great. Otherwise, it's just gonna go right through.

Hey. I think it's gonna be holding the holding the pocket for you for sure. Oh my god.

No. That's great. That's, it's great to hear that you guys are moving out from kind of that internal it seems like Amazon builds something internally and then rolls it out for everyone externally.

So they had Prime as a differentiator, and now they're rolling it out Prime for every other of their customers to be you know.

Right. Like, yeah.

We we end choosing by with Prime for everyone else too so that they can use private prime in their websites to drive traffic to the website as well as use Amazon's promise to ship the products to them.

That's great. Tell me a little bit more about you had mentioned you've been with Amazon for two and a half years. You've been working in regards to Salesforce. Can you tell me a little bit more about Salesforce at Amazon?

Sure. So when I when I when I was came when I came to Amazon, I thought, like, there would be one big Salesforce arc, like, with two hundred thousand people in the users in there. But once I came into Amazon and then I realized, oh, no. It's not like that.

It's like there are two hundred live arcs right now. Wow. And the users vary anywhere under hundred to about ten thousand and every arc works independently. So it's like multiple arcs sitting in one company is Amazon.

Wow.

So I'm sure there's probably some challenges there with just sharing all of all that you have and in terms of all the technical knowledge and moving teams and like tell me a little bit more about how that at Amazon works.

So the good thing about Salesforce at Amazon is that we have a central portal where we get all the information or what are the products that we have available and we order everything from there. So if you wanna spin up a Salesforce instance, I don't directly talk to Salesforce. We already have like a centralized portal in our system. We have our own support.

We have our Amazon, conservation team that supports us. That helps us build a Salesforce system as well. So we have a centralized way to process to create our own Salesforce instance. And that's why you see so many Salesforce instance spin up in our org.

Wow.

No. That's great. And so you've you're working with Buy with Prime now and but this is not your first Salesforce org you've worked with. You worked with w w CRM. Can you tell me a little bit more about that group and then maybe the difference between the two groups and how they do DevOps?

Yeah. Absolutely.

So so whenever I consider dev ops, it's like it has to be independent for there there should not be a a standard process for every every team and there has to be a certain guideline, I guess, because depending upon the size of the team, depending upon the process they want, depending upon upon how the business is, the dev ops can be modified for their own needs. So our world where CRM is one of the biggest arc. It's like more than five thousand users there. Everything was implemented. It's been one of the oldest arc as well.

Integrations are there.

Gerson was already there for like DevOps too. And I was there to implement, chain management process over there again and, we introduced the version controlling using code comment.

It was not supported first, then we got that support. Again, thanks to, they listened to us and they implemented code commit there.

And then the process is streamlined there. Okay, so and there are a lot of integrations, so we gotta think about the security as well as the new introducing new tools. And Virus Prime is like a baby arc. I mean, it just started with ten users in May. Now we have more than two hundred users, I believe so, and we're growing very rapidly.

So that one I just a already established arc to a new arc is that in the new arc you can introduce new technologies, already upgraded versions so that you know that no integration is gonna break because you're gonna introduce integrations after the fact you're building the system.

So also a lot of learnings from bigger arc like how can I improve the scalability from the starting level itself? How can I improve security?

So there are two different, like one is the biggest arc, one is the small arc that we're growing and we're trying to scale it. Interesting.

I I think this is a question that always comes up for me, from customers is, like, how many, admins and developers and Salesforce folks should support in order. So maybe just to help the team understand or the folks here in the audience understand the size of the teams, like, how how many folks were working on worldwide CRM, and then how many folks do you have buy with Prime? Like, where'd you start, and where are they where are you growing?

Sure, so if you're talking about the admins, so we try to limit the admin visibility anyway. So we don't use system admin user for anyone. Even an admin has to use a separate specified cloned system admin where it says so and that's how some restrictions were there. So, I think around every single time there are only two or three at the top in even with five thousand users there.

In this new arc, like we are three admins, but it's only like one system admin that can do a lot of changes into the system. But everything is gated, like profiles are gated and, I like the system with the least privilege almost all the time. So we try to keep as less possible, permissions to anyone there. Okay.

Like like even even with the security implementer for now, right now, I can't export few things because we blocked I blocked my cell phone there not to do that.

Yeah. Okay. That makes sense.

And then in terms of like number of folks behind the scenes, so you said there's three at the top. Like how big are those development teams in those orgs roughly speaking?

So currently we are around eight to ten people in the private prime. I think, worldwide worldwide CRM grew big as well. I think they are around fifteen to twenty people I guess over there. Even with supporting like so many, users. So we are just like twenty people. Okay.

Yeah. That's crazy.

And it's only under one arc. So it's like they're not working around different arcs to implement in one sale for system. They're they're under one umbrella. Okay.

And so there those are two orgs using gear set and then, so and there's like two hundred orgs you were mentioning. So can you speak to kind of the DevOps posture at Amazon in general? I know you do a lot of internal Wiki documentation. You've got centralized security policies.

Can you maybe explain or share a little bit more on on how DevOps is used at Amazon?

Sure.

So even before talking about DevOps, like security is one of our key to implement any Salesforce system. So our our security for Salesforce already had particular guidelines how to implement Salesforce system. In that, it asks you how to have CICD process, you have to release process, change management process, or anything that you think about in the security perspective as well as the release perspective, we already have that squared off.

But our security is, lenient about like what kind of DevOps you use, you can use it. It's like how your team is comfortable and what your team is comfortable with. So if you wanna go with Versus code, you can use that. If you wanna go with, Gear Set, you can go with that. If you wanna use if you wanna build your own native system, you can use that. So, but the process is the same. It's like what kind of tool you wanna use, you you got that independence over there.

That's great.

If there's anyone listening, maybe let's not rebuild the the wheel again. Right? Like Yep. Yep. We've got some good tools out there and, you know, that's always great.

But, Yeah.

And also, always there is like, as you mentioned, there's always this Wikis in Amazon. Like, everyone when when they're trying to implement a Salesforce system, they absolutely go and search for the wikis. And the wikis there is like everyone, expresses their learnings from what what from their implementations in the past and what are the tools that are you they're using, what are the challenges they face when they're implementing Salesforce. So they'll learn from there and they'll they'll see, like, what are the tools and they go with, each and everything there.

Yeah. That makes sense. Because I think the first time I ever got exposed to Gearset is that, an Amazonian brought them to me and said, hey, like, someone else is using them. I heard about them in a Slack channel.

They had a Wiki page. And so it's really like an organic way to find and build these different, Salesforce and technologies. Yeah. Absolutely.

Yeah. It's great. So especially right now, I mean, we're kind of ending the work from home, work anywhere and and still have that still taking those core things. But I think with COVID, it's kind of people are kind of coming back into the office.

And so, to that end, you know, that's it's helpful to be in the office. But I think still with any team, you're always gonna be globally distributed. So how is your team overcoming that challenge of not being in the office, and what are some of the things that maybe you miss, from from that in person?

Sure. So it's a funny story. So I was I think I was in the first few people in Amazon who joined right in the COVID. So I joined, like, remotely and, you know, like, there were a lot of issues when when you joined getting from your computer to your access to everything.

And even in Salesforce, there were a lot of issues that we thought we thought about which we did not think. It's like we used to do white boarding when you're in the office. You used to train the users or train everyone making them sit in one of the room and that's how easy it was easy when you're there and collaborative in the office at that point of time. There were there were challenges hundred percent when when we when we just started work from home, but we also get we also adapt it to that. And now, we're doing a lot of, documentations. That's one of the one of the Amazonian thing that we do. Like, we write a lot of, a lot of tech docs, training docs right now.

Also like we have enablement teams and everything. We train the users about the new features that we are releasing, for our team. So that's for the users, right? So about the collaboration in Salesforce.

So we have our demo calls almost all the time when when there's a new, release that we wanna do. We have gated releases almost all the time. We have peer to peer reviews. There's a lot of collaboration represent, like every every single time there is some If if I'm trying to change someone else code, I would know that because we already talked about it in our prior calls.

Yeah. That is one thing I missed. I remember so when I did my first project at Amazon or maybe my first tour of duty there, it was like a nine month implementation. We were in a war room with, I think, John Frum's here, and we would stare at each other, across the table, and we would be in our, you know, our our dev teams would be right there.

And so it's did you push the change set? Yes. I pushed the change set. Okay.

Test it. Oh, you're missing one thing. Push the change set again. But with these global teams, that just is not the case anymore.

It's much more of a, you know, you're you need the ability to see what's the difference, what's the deltas. And then if there are things that you need to triage, it's you're moving these conversations to, you know, Slack or asynchronously. Like, is that how are you handling that communication today without being on the whiteboard?

Yeah. It's it's it's always a challenge because like, even when you're sitting in a global team, everyone works in different time zones. So that's one of the biggest challenge. Right? So couple of things we wanna do is we we do is like, we still do ad hoc release. We don't we don't we still don't have the process to be we didn't want to set up like to release on this day because we don't wanna wait, we don't want someone to wait for someone else changes to go, right? So we don't want to do ad hoc changes because our team was very small.

So still like, if there are any changes that are missing, if there's any bugs that we implemented, we we have a triaging process in our We have We still have Slack channel as you mentioned. We're talking about Slack channel, hey, this is that this is what we're missing, so let's fix it. And we do the bug fixes instantaneously.

Ninety percent of the time, we don't try to implement bugs into production, which is not a good practice. So most of the bugs we implement is in test environment.

And our users are amazing that test everything in the test environment like production.

We refresh our test environment every three months, every quarter. Whenever a Salesforce release happens, we refresh it. So that we have the data, we have every code, every change that's in there.

So mostly like our users still think test environment as production, which is amazing, and they try we tell them to break everything in test environment. Interesting. So anything anything that they break is amazing so that we can fix them, before it goes to live. That's great.

And what kind of, sandbox do you use for that testing environment?

A full sandbox.

So you use a full sandbox that just mirrors production.

You're refreshing that monthly and or, quarterly, excuse me. And then you're really doing a lot of that testing in there before it ever gets to sales or production.

Yeah. But still, you know, like, there there are ways that we can sneak the box into production without, even though user tested it, there are still manual errors that we do. So for those kind of things, we are very very proactive to, minimize those bugs. Okay. No. That's great.

No. I love that you're using a full copy sandbox. I love the testing and the mirroring and having folks go and break things. Like and I it's, it's always good when you have that that that mentality. I think Amazon is is pretty, tenacious in that sense of, like, let's go find the problem. Where's the where's the fix that we need to make? So that's great.

Right.

So, you were mentioning kind of, or we're talking about these improvements and so, and we're talking about system improvements. But just in terms of DevOps improvements, you know, what are some things that, your team's looking to improve on?

Sure. So in just couple of months, our team, I mean our development team and admin team grew from like two to three, two people, three people to ten people directly. So, the DevOps was rudimentary for the two or three people because one person can do the release for everyone. And will start going through version control still and we have the backups go through the version control every day. So if there's any change that happens in production automatically, it's all always captured.

But now as a growing team, we wanted to improve most of the things like version control approval processes first thing, because we wanna see, like, I know you're doing a peer to peer review, but we still wanna see, like, what are the changes that's been happening. The next thing we I saw was pipelines, which we wanted to get it. We just don't wanna deploy from dev directly into production, which is a possibility at any point of time. So we want to get those things. You can't scale kind of gate like, we wanted to do the service account, which is only responsible for deploying. Not we can restrict other accounts not to deploy. So that's one of the other things that that we're trying to do.

Again, CICD automations because there are so many people, we we wanna make sure that at least to the test environment, if we push anything to the repository, it goes into the test environment automatically.

They're kind of like, other improvements I think about basically on the dev ops is about creating a release process first. If there are one or two persons, creating a complete release process was not that viable. But right now, like, we are as the team is growing, we have to have a really standardized release process instead of doing ad hoc release this, combine release this at once and deploy it. So that, like, we know that who is overriding those changes again in the test environments and everything too. So that's one of the other things that we want to improve to.

Interesting. Yeah. I think, one of the earlier topics we were there talking about building in that muscle of as you're deploying that feature, like building in that automation, that CICD so that you're it's it's part of that user story to really say this feature is is truly complete. So, love that you're you're implementing that. You know, last question maybe before we we jump to some open q and a is, what are some of the goals and strategies or, excuse me, some of the goals that you have for your next twelve months, in regards to DevOps and Salesforce?

Oh, absolutely. So in regards to Salesforce, Amazon is very high in security. So our security bar is very high. And every team also wants to improve more security than the Amazon security bar.

So our primary goal is to improve the security. So, I mean, the first thing that comes to my mind, like, we improved one of the security, which, is like exporting the PII data out of Salesforce. So sales teams, we we restricted exporting PII data. We use shield encryption that Salesforce provides.

So that like, we protect the data more. So data protection is one of our main main goal. The next plan we are thinking about is automation again, like like the CICD I talked about, the sales process automation, so that like, improve the sales process using tools like product or even even existing sales for tuning flows or whatever new features that are coming through. Lot lot of, other automations that I think about is data data integrations, with other teams so that we get the right data, and enriching a lot of data too.

So those are our plans for the next twelve months in Salesforce.

And going to DevOps, again, like we want we wanted to work with, Kier said, again, we talked to few other engineers that we want to implement pipelining using a service account, so that the deployment goes through one unified account to reduce bugs, introducing bugs into production as I talked. But I mean, there's a way you can flip any time. You don't know, but we wanna make sure that we we minimize the risk of, deployments, have a unified deployments, have a, cadence set up to deploy, combined deployment at once. So so those are those are couple of things in our road map for the next twelve months.

It's great. Those sounded like some of the best practices that we're hearing kind of throughout the day and probably gonna be throughout tomorrow. So it'll be good.

Yeah. And also like payload times is like one of our, not just payload. Performance, improvements is our main main concern because the data in our system grows exponentially. It can it it it goes from zero to one million records in like in in day in days to month. So we wanna give our users the experiences on the day one, how it was. So our day one mentality is still there, like, we wanna have the performance not degrade at all. We wanna show, like, even with, like, a billion records in the system, we wanna have the same performance when it was, when it was built initially.

Yep. Love that. Love bringing in that day one, mindset that Amazon has. It's always great to hear. So, well, Nikhil, thanks for spending some time and and chatting with me. I think we have some potentially some questions, from folks in the audience.

Hi. My name is Aniket, and I'm a Salesforce admin, with Amazon. And I can pretty much relate to everything Nikhil just spoke about regarding the the orgs and the security and stuff like that. So my question to Nikhil is, do you have any plans of integrating your instance of Salesforce with any other Amazon applications like, like Seller Central or the SIM integration like, the SIM ticketing tool? And if so, what is your plan on maintaining these integrations?

Great question. So, my old org, which I talked about, was integrated to seller central. So that was there. The new org, we we wanted to integrate with we did not integrate with, Seller Central or anything right now, but we are we are trying to integrate with, the AWS applications like.

So right now, we already have integration with AppFlow, Redshift, where we take our data backups and everything. We we are trying to do a lot of other integrations for our portals, like we have our own private prime portals. So we are trying to integrations, we are trying to do the integrations. So, if you're trying to talk about the support and how we are trying to maintain those things, mostly the integrations are on the production right now.

And again, like, we wanted to introduce everything to our lower set environments as well, though the test environment, so that we can we can find out the issues even before it's too late in production.

So that's there, but it it it's it's still in our next year plan.

Thank you.

Hi. I'm wondering how you deal with cross pollination there. If you have two hundred orgs, I imagine the larger ones have already gone through a number of pain points. And as new ones come up, you need to make sure they're following best practices that you deal with big data, doing skinny tables and indexing fields. And do you have so two parts of that question.

Are there playbooks that are like, this is the go to market, this is how we do go to market regardless of the org that we're in?

Sure. So great question. So we have the go to market thing, like, anytime if we wanna introduce a Salesforce into Amazon, there's a whole playbook about these are the hundred steps you need to you need to follow to even launch your org. Like, even to launch your org, you need to follow all the security policies, introduce the threat models to everything.

So we have that process in place. And now, the next thing you're talking about about like skinny tables, indexing, that depends upon team to team anyway. Right? So, so let's say if my team had a pain point and we know that we have to introduce to the whole, whole company.

There are a couple of ways we do it. One is our wikis. Our Amazon wiki is very huge and you can search for anything and you get there. The second thing is like we have internal Salesforce community chats, like which we have, like one of Slack channels.

The second thing is that we have a monthly calls again, with large Salesforce team. People voluntarily join in that and everyone tries to tell one new feature that they implemented or like maybe, so let's say like someone implemented a very good automation that they think it's very useful for the other team and they don't have to spend too much time or reinvent the wheel over there. So they they explained that in that in that meeting and they give us the code so that we can implement. We can change the code, for our use case and we can implement there.

So we got like, monthly lunch and learns, and also Salesforce has monthly lunch and learns as well. So we have Amazon month Amazon Salesforce monthly lunch and learns and Salesforce Salesforce monthly lunch and learns. So you can go to any of those things and we also have like, lunch and learns for like the new features that come in like every release. So that's one of the other important things that we think about because, we we tend to skip, like, if you're if you're working on the same arc for so long, we we tend to skip, like, what are the new features that are coming in.

Like, one example I think about is Salesforce natural language search. That's one of the best important thing that I saw, but I missed it in one of the releases, and I did not introduce for, like, next two quarters in one of the team there. So kind of that. So we do have all those gates in place.

Yeah. And I'd say so, there definitely is folks there's, cross pollination would be desirable. Right? So folks would start, kinda taking and and building, and then you have basically two hundred dev teams, you know, operating as one and maybe pushing to, you know, bigger features that other people need.

What what we see is people maybe recreating the wheel. So what we try to do is they do it different teams do different, or better or worse at at kind of documenting that, but that's where we're pushing them to. We have, one thing that we've done, the last two years is Amazon Day. So we bring a whole lineup of folks like Nikhil, and and they share their experiences with each other because we find that they learn better from themselves, and we also learn a lot from them.

So, that if that's something of interest, like, I talk to your Salesforce account rep and see if they would, do something similar with your company so that you can share. It's a great way, to get your executives also aligned and see the community behind, your projects. They're they're typically pretty big. So those are some some things that we do as well to to help foster that.

Just curious if, any of the orgs, that you guys have, have such critical business functionality that that needs to be monitored. And how do you deal with that given your stringent security policies?

Like, if something breaks, it's it's an emergency, and you have to know about it.

Great. So so one of the security thing is event monitoring. So we have event monitoring in place even before we launch Salesforce Arc. So we have, I think I think at least eighteen months of, even logs we need to store, like anything that breaks in, we have everything that is stored. And the even monitoring, we just don't typically use exactly the one that is in Salesforce because if Salesforce is gone, like, we can't figure it out, like, so we back it up to some other tool or s three buckets or anything so that we have a secondary backup of all the events that we have that are happening. But that's even before we launch Salesforce, we have those gate in place.

Okay. Thank you.

Yeah. It's part of so every org there gets, shield and and implements it, and it's a requirement within the policies. And so that's again, it's really around policies, and they have now, I think you were saying earlier, auditing and Yep. And monitoring. So, that's that's really how we're we're working with that.

And then I think you also mentioned that you have a concierge team. Right?

Yeah.

As well. So, the concierge team also is able to respond to requests and and bubbled up outside of just the normal Salesforce requests as well.

Yeah. I mean, if there are any, like, little Salesforce issues internally, and, we'd directly reach out to our concierge team. And, our concierge team is first line of defense and they they answer most of the questions. And if they can't figure out, then it goes to the next level of support and everything there.

I think that's it. Alright. Well, thank you, everyone. If you have any other questions, we'll be around afterwards.