Hi, I'm Matt from AWS.
And on today's episode of 'This is My Architecture',
I'm joined by Andy from OutSystems.
Thanks for joining us.
Thanks for having me.
So, tell us about OutSystems.
OutSystems is a leading low code application development platform, and we're building our new platform on AWS.
Great.
Thank you.
So Architects, like us like to talk about monolith decomposition,
it's one of those favorite topics, but there's more to decomposing a monolith than just the application or the microservices part.
Is that right?
Right, it's really the data, the data really. It has a gravity to it,
That makes it really difficult for you to scale and also write and also build a high-performance low-cost platform,
and especially as we're going multi-tenancy,
that's where a lot of the services in AWS really benefit us.
We have in our platform, we have several different kinds of data.
We have a whole segment of binary data.
Yeah.
We have a bunch of relational, correlational items that that go to defining the applications we give our customers.
Okay.
We have a bunch of data that's really configurational,
really it's key value pairs.
And then the last part is a bunch of encrypted, encrypted data for sensitive information.
So as part of your journey to microservices and decomposing this monolith,
you're looking at the different types of data within your applications and then putting them in the different storage and database services that AWS offers.
Is that right?
Yes, and the great thing about all these different services,
Like we will take binaries, you know, S3 is a natural location for unstructured, blob data.
Yeah.
It's also a great place to store document or structured data.
That is just accessed by a key,
effectively a key value store, yeah?
Exactly, exactly.
And it's something that scales.
It's something that's resilient.
We still have a lot of data, which really should still be relational.
Yeah.
and that's where using Aurora Serverless really comes in comes into play.
Because one of the things that we're doing during our decomposition,
is that each of our customers - each of our tenants - will have their own instances of these different services.
So, you don't have sort of a giant centralized database, you have,
applications team owning their own Aurora Serverless instances, is that right?
Exactly.
And that's the really, the power of this serverless.
These request-based kind of data services, is that you can have
different services, each having their own instances of these,
to let my teams manage their own data but also run independently.
Okay, so relational data, in Aurora, Aurora Serverless.
You have key value and more sort of blob like data in S3.
How are using Dynamo?
And I see Secrets Manager here, too.
Yeah.
So a lot of as we're looking at all the data that we're storing inside of the relational.
One of the things that we evaluated as how much of the configuration or the key/value pair data that we have,
If we could use and leverage something that's a little bit less expensive,
but also scales a little better.
So you're offloading some of the data out of the relational database to DynamoDB.
Yeah, it's not it's not that we're worried necessarily about Aurora's performance.
It's more of the idea of the relational databases inherently that,
singleton and an architecture from a performance and scale perspective,
and leveraging some of the other services.
It gives us some, some more agility.
I mean, it makes total sense to sort of tier your data and choose the purpose-built database to best meet your needs.
I'm curious to know how using Secrets Manager, you know, you normally wouldn't associate it with database and storage services.
But in this case,
Yeah, and so, you know our current product is based on an enterprise architecture.
Yeah.
Where the only kind of predictable well-maintained storage, you have would be a relational database,
so it became a catch-all for where we put things.
Now we don't store secrets inside of our the relational store.
But we do store encrypted data,
Okay.
You know, some of the different RDS,
or relational instances give you the ability to manage it.
And, then we also have our own app level,
but that's where Secrets Manager comes in,
where instead of us having to manage it.
We can we can offload that.
And then, you know, use a service to securely store those items.
So instead of pre-encrypting and then loading into the relational database, you could just put it into Secrets Manager directly.
Exactly.
And then through the use of like IAM roles and other things, it allows us to ensure, you know, that tenancy boundary for our customers.
Okay.
You said tenancy a few times and multi-tenancy.
Is that how you're using KMS, you know.
You have KMS down here.
It's our last icon.
How is that being used in this data architecture?
And the great thing about a lot of these services, right?
And AWS provides some really good best practices.
It provides also, you know, the pattern way in which you could then encrypt data.
And so, you know, one of the things that's key to know, the customers especially will ask in a multi-tenant world is,
how do I know my data safe from other people,
you know, we have the IAM roles as a way to kind of segregate from a permissions perspective,
But then, using the built-in encryption mechanisms, that each of the services have,
we can generate a per-tenant key or multiple keys for that tenant.
And then applied to the each of the different services.
This also gives us a very straightforward path to do a BYOK strategy as well.
Bring your own key strategy.
Yeah, exactly.
Nice.
So I like how you're applying, you know, from the not only the data side and picking the right stores service and database service to meet your needs.
In addition to Secrets Manager,
but you're also enabling microservices based architecture and multi-tenancy with bring your own key and KMS based encryption that works well with these services,
it's really a nice extension of what we traditionally associate with a monolith decomposition.
Yeah.
It's something in the other one of the other things that's really empowering,
is that most of these services have a very easy way for you to do local development with them to allow developers to work detached and then independently.
Nice.
And ultimately that's what we're trying to do, empower developers, so they can be more productive and ship more code, right?
Mmm.
That's great.
Thanks for sharing this architecture with us.
Thank you.
And thanks for watching,
'This is My Architecture'.