Today on How we built it.
We take a look at a real world example of a migration from
On-premises monolithic application
going to cloud services and micro services based architecture.
We'll go behind the scenes of British on-line fashion retailers
ASOS with it's customer base spanning 230 countries world wide.
And, we'll take a look at their previous and current technical architectures,
their design goals and approach from moving from a locally operated monolith
to a fully built for cloud online retail system,
and their shift to micro services architecture
to help expedite the release of new features.
Joining me to today is Dave Green, a lead architect for ASOS.
Welcome.
Thank you for having me.
So if you're not familiar with ASOS, it's a great example of a successful online retail store.
A big reason for this is your scale and worldwide footprint.
But you didn't start in the cloud, did you?
That's right, we started about 17 years ago in the UK
Cloud really wasn't an option for us back then.
Since then we've scaled to over 14 million customers world wide
A lot of that has been international growth.
So we've had to overcome technical constraints around
single language support and multiple currencies.
That's a massive requirement in terms of infrastructure
and the growth that you've seen over the last 17 or so years.
What are you actually coming from?
We were in a single data center based in London
and that housed everything that we had in there.
we had the websites, the checkout systems, our content management systems.
All of the middle wear and reports and even our warehouse management system were housed in there.
That grew over time to have more than 200 servers in it.
So all of this was pretty successful
in terms of all the compute you've got there, you've got a lot of horse power running it.
So what then spurred the shift and the movement into cloud?
Why were you thinking about that?
So it wasn't just a compute and a performance thing.
Our architecture was starting to hold us back and it was slow to change.
We had a monolithic application
that meant all of our transactional eCommerce systems,
the product reference data, all the content systems and all the customer systems
were all locked in together.
And on top of that 17 years ago the only way to view a website was desktop browser.
And with the upcoming change, that was all that we could really support.
So you had to shift to a more modern types of devices and be able to support those as well, right?
That's right.
Because this was difficult to change, we had to look around for alternative solutions.
So we started layering on third party solutions to do things like
reformat the HTML to be mobile friendly,
or even dynamically translate language on the fly.
So what are some of the business challenges?
You mentioned some of the systematic ones.
What are some of the business challenges you had to overcome?
The main problem was how inflexible and brittle this was.
Every time you tried to change something it had a ripple effect up and down the stack.
And that just meant it was slow for us to deliver new features
to keep up with the needs of the business.
So when things like the birth of mobile and native apps took off,
it was really hard for us to support that.
So you've got this monolith and it's working, but not quite where you want it to.
How do you go about breaking this apart?
What we did was we separated out the front end concerns so that we had a set of
clean APIs representing our back end services.
Then we looked to develop our native and web apps
so that we make use of these new services
and roll those out in a phased process country by country to minimize the impact on our customers.
And let us get real production testing in the services.
The only thing we didn't move out was our payment systems.
We didn't feel comfortable moving into the cloud with those just yet
until we got some more experience under our belt as to how to operate these sort of things in the cloud.
So all these things here are micro-services
that are running on an API set.
What's an example of a micro-service that you've built out
for your new app approach?
Let's take the bag services as an example.
The purpose of the bag services is to hold the shopping.
So customers add things throughout their bag as they go throughout their shopping journey.
For a compute here, where are logic is we use Azure cloud services.
The micro service manages it's state and it's data independently of the others.
So everyone of these APIs has it's own data store and looks after it.
The services can talk to each other and other services
by either using RESTFul APIs or asynchronously using using the Azure service bus.
So to give you an example,
as a customer adds something to their bag
the bag service needs to go and get some product information about that.
So it would make a RESTFul call across to the product
and retrieve it and add state to the bag in the database.
For performance reasons and scalability and resilience purposes,
we'll cache that data for a short period of time making use of Azure cache.
One of the great advantages here of using micro-services
is that you can use that to scale to multiple data centers and regions
so you don't have to worry about any peak times or traffic, how does that look?
That's right, so we've got about 30 of these services.
But we wanted to simplify the operational estate once we gained experience with running in the cloud.
We've deployed mainly into the European data centers.
We've still got our data center, but based in London.
Which is where we still keep our payment solution.
Most of our customers are European based.
So we've deployed all the services into the paired data centers of EU north and EU West.
And because they are a paired data center,
that means it easy to replicate data back and forth
such as things like DR or HA functionality.
We also want to make sure that our customers in Australia
and America where we are getting a great experience.
So we looked at the services that are critical for latency.
And we deployed those into the America cloud region.
And the South Asia cloud region.
That's resulted in us having things like
our identity service,
and our internal search service deployed globally.
Great, so now you've got services running in all these different regions.
But, how do you actually manage the connections
back to your Azure based services?
We make heavy use of the Azure traffic manager.
And it's responsible for taking the customer traffic and routing it
to the right cloud region.
Typically that would be the one that is closest
to the customer for the best possible performance.
It's this flexibility combined with the micro-services that let's us deploy
things like payment options or delivery choices
to the customers in our key markets really quickly.
As our market grows,
our cloud footprint will also grow with it.
If we wanted to go in Brazil in a big way,
we'd look at deploying our services to
the South American data center.
So let's switch gears for a second in terms of scale.
How do we actually manage big traffic
peak times like maybe cyber Monday or black Friday?
Knowing that these things are coming, what do you do in terms of managing scale?
Since we've moved to the cloud based micro service approach,
we found that we can cater for far more traffic than we ever could with the on-prem system.
Just to give you an idea of scale, on our previous peak on the on-prem system
We were topping out about 9 orders per second.
Last black Friday in 2016
the new stack was catering to things like 33 orders per second.
Our product API
was getting hit around 3,500 times per second.
Overall on that day we had something like 67 million page views.
We can cope with the scale and we know the systems can scale and cope with that.
But we tend to run in two different modes.
We either run in day to day scale mode,
or when we know there is a big peak coming, we'll scale up.
We use a product workload model
to understand what we should scale up to.
And we are constantly refining that with real customer traffic and data to make that the model is accurate.
Are you monitoring every single transaction
and every single API use, etc?
Absoutely, we are obsessed with making sure the customer has the best possible experience.
And that means checking the front end
and making sure the performance of the website is what you would expect it to be.
When we're monitoring trends we're looking at how things are performing in different countries.
We can also see how we did it compared to the activity last week.
And obviously we are doing that on the back end as well.
We're looking at how all the different services are reacting.
And all of this is linked into our operational monitoring and alerting stack.
And if anything were to go out of the parameters we'd expect to see
that would trigger an alert and the teams would come in and start looking to diagnose what was going on
and take action.
So now you've got all this real time data to make decisions around scale.
But have thought about using some of the automation around scaling that Azure can provide?
As part of our next gen compute approach,
we're looking at moving away from cloud services to one of the new models that Microsoft supports.
So we are looking at things like Azure service fabric,
or Azure container services.
We think as we move into that world then it will have the responsiveness to make use of the order scale.
So we are looking at micro-services here and how it relates to scale.
But it also does things in terms of making it easier to
release new features and capabilities.
Are there some examples that we are using to make release management easier?
The micro-services approach let's us combine features and functionality
together and to create new experiences for the customer.
Because it's a loosely coupled architecture, that means we can scale the development teams as well
so they can all be working on multiple features at once.
Let me know show you something that we've been working on.
This is our new visual search for apps.
The premise here is that you see some clothes that you might want to buy or that you like the look of.
You can take a photo of it or you can scan a photo of it in a magazine.
Here we are using something that might already be in your library.
You can focus in on the detail that you think makes that sort of unique.
Then you submit that and we will give you back a list of products that
Asos sells that looks like the thing that you are trying to buy.
How does something like this work behind the scenes from a micro-services stand point?
All of this works by making use of the micro-services.
When the customer uploads the image, it get sent to an image recognition service.
This is using machine learning and it's
consumed all the data from the product catalog and the product services.
That product data allows it to tag meta data to the products
so that it can join that up with the image that has been submitted.
Then it's doing things like a real time inventory check
to make sure we are not offering products that are already out of stock to the customer
and returns that list back to the client.
So it's really interesting to see how you've moved your monolithic on-premises application,
one that is built for cloud using micro-services.
But, for the folks watching at home
are there any tips you can give them for their moves into the cloud?
Sure, I would think about how to simplify the estate as much as possible
before you move into the cloud.
Work with the simplest run estate that you can, once you get that cloud experience.
I would also think about how you design for failure.
Because failure in the cloud can be different then designing for failure in an on-premised solution.
Then finally I would bring it back to that dev ops approach to monitoring.
Monitor everything because telemetry is life when you are operating in the cloud.
So keep it simple and make sure you're designing for failure that might be different in the cloud.
And also making sure that you can monitoring to keep that dev ops process across the life cycle.
Thanks for joining us today, Dave.
You can catch up with Dave and the entire Asos team
on the Microsoft Tech Community.
Details for that are at the link below.
That's all we have for this episode of How We Built It.
Thanks for watching.
Microsoft Mechanics
www.microsoft.com/mechanics