MARTIN OMANDER: Hi, Dina.
DINA GRAVES PORTMAN: Hi, Martin.
How's it going?
MARTIN OMANDER: Going great, because today, we
are designing an application that deals with money, I hear.
DINA GRAVES PORTMAN: Oh.
Oh yeah, that's true, for our event planners.
MARTIN OMANDER: Right.
So it's going to be a serverless application that
deals with money.
We're going to go through exactly what products you
use in this thing.
Are you ready?
DINA GRAVES PORTMAN: I am.
MARTIN OMANDER: Let's do it.
[MUSIC PLAYING]
DINA GRAVES PORTMAN: OK.
So we have three users.
We have our event planners, our accountants, and our vendors.
And our event planners need to register the vendors.
They need to create purchase orders
so that the vendors deliver whatever
it is that they're delivering.
The accountants need to view and approve invoices
so the vendors get paid.
And the vendors need to be able to submit their invoices.
MARTIN OMANDER: Very good.
So I see we have them here on the left-hand side.
Looking good.
And let's see.
Some of these are inside our company
and some are outside, eh?
DINA GRAVES PORTMAN: Yes, exactly.
We can think of this as like two groups.
One is internal and one is external.
MARTIN OMANDER: Got it.
And the internal ones-- that's, it
looks like, event planners and accountants.
DINA GRAVES PORTMAN: Yeah, exactly.
So, we're going to build a web app.
But yeah, it's worth starting by thinking,
how are we going to ensure that only
the people inside our company access this web app?
MARTIN OMANDER: Ah, right.
So for a project I recently was on,
we used identity-aware proxy for that.
It is super simple to set things up.
People within our domain, they get in.
Everybody else is kept outside.
And you can even set levels within that.
But yeah, for this, super easy.
Let's do it-- Identity-Aware Proxy.
DINA GRAVES PORTMAN: Awesome.
OK, so the next question is, what do we use for the web app?
MARTIN OMANDER: Yeah.
So web app-- OK, serving HTML, JavaScript, and so on.
I think App Engine would work well here.
You and I both know App Engine well.
It's also-- again, on my last project,
it was like a two or three click integration to put it together
with Identity-Aware Proxy.
DINA GRAVES PORTMAN: Even better and super classic.
Love it.
OK.
Whoa, this is easy.
MARTIN OMANDER: So we're done.
DINA GRAVES PORTMAN: We're done.
No.
Next, we come to possibly the first difficult decision.
We have to start thinking about storage, because the event
planners are going to be filling out a form
and saying these are the vendors,
and that needs to go somewhere.
And I like to think about storage options
always as relational databases versus nonrelational databases.
And in this case, we're talking about--
we're talking about money.
We're talking about, these are the purchase orders
and then these are the invoices, and we're
going to need to be able to run reports against these things.
Say like, this is like the money that we pledged.
This is the money that we paid.
And so for something like that, I really
think that we absolutely have to use a relational database.
MARTIN OMANDER: Yeah, I agree.
Like you're saying, sum up like 1,000 documents,
1,000 invoices, and get their sum-- super easy and quick
to do.
And I think we could do Spanner.
We could do various other things.
I think Cloud SQL is right here, because we
will have on the order of gigabytes and not terabytes
or petabytes here.
So Cloud SQL, which is well-known.
You and I are both familiar with MySQL and Postgres,
so that'll be easy.
DINA GRAVES PORTMAN: Oh my gosh.
I feel like it's 2010.
App Engine with a Cloud SQL database?
I love it.
MARTIN OMANDER: [LAUGHS] Yeah.
Well-known technology.
OK, cool.
So let's see.
Everybody's got-- oh no.
Vendors aren't connected to anything.
DINA GRAVES PORTMAN: Yes.
OK, so the first thing that we need to think about
is the fact that they are external
and they're coming from anywhere and possibly everywhere.
So how do we ensure that they are able to access our service
and do appropriate things on the service, but nobody else is?
MARTIN OMANDER: Right.
So we need to know that they are who
they say they are and so on.
I think for that, Identity Platform is a great choice,
because then they can login with their Gmail accounts,
or from various other identity providers, they can login.
It's self-service to setup their own accounts.
But we do know who is who.
If somebody logs in as fluffybunny@gmail.com,
we know that that really is fluffybunny,
the vendor, or sonomawinery.com, maybe.
DINA GRAVES PORTMAN: More likely.
MARTIN OMANDER: Yes.
[LAUGHTER]
So Identity Platform there, I think that's a shoo-in.
That would be easy to do.
But now what platform serves up HTML and JavaScript
and CSS to them?
DINA GRAVES PORTMAN: Yeah.
I think let's go with App Engine again.
I don't think that we need to do Cloud Run for this
because we're not using any special runtimes
or anything like that.
I think just your standard App Engine would work great.
MARTIN OMANDER: Yep.
I agree.
I love Cloud Run, but it's smarter
to keep it to only one product here for computing.
OK, so these folks upload invoices.
It says here, submit invoice PDF.
Is that what the vendors are doing?
DINA GRAVES PORTMAN: [SIGHS] Yes.
OK, so we always need to consider
that we need to meet our users where they are.
And, in this case, our event planners
work with vendors from all over the place.
Sometimes, it's like a giant hotel chain
that has very standardized systems that can plug and play
really easily with whatever we want.
And then sometimes, it's mom and pop from a Sonoma vineyard
and they're going to maybe send their invoice
on the back of a postcard.
I don't know.
[LAUGHTER]
Or they even fax them sometimes.
So yeah, we need a system that allows
the vendors to keep using whatever system works for them.
Maybe it's a PDF.
Maybe they have a handwritten invoice.
And it'd be really cool if they could just
take a picture and upload it.
MARTIN OMANDER: Yeah, with their phone, right?
DINA GRAVES PORTMAN: Yeah.
Yes.
Yes, exactly, which means we're back to the storage question.
But this time, it's not columns and rows.
It's not numbers.
It's bytes.
It's rather difficult decision.
MARTIN OMANDER: Binary files, right.
DINA GRAVES PORTMAN: Yeah.
MARTIN OMANDER: And we could theoretically store them
in a relational database.
But there are products that are better at it, right?
DINA GRAVES PORTMAN: Yes.
Yeah.
And we don't want to store them for too long, either.
So I was thinking that maybe we could use something
like a Cloud Storage bucket.
MARTIN OMANDER: I love that.
Google Cloud Storage, because you
said we don't want to keep them around for too long.
On a previous project I worked, we set things up so
after six months-- you can do this
very easily with a few clicks in Cloud Storage.
After six months, delete the files.
So it's nice and clean.
Everything's automated.
You have automated controls.
DINA GRAVES PORTMAN: Yep.
Yes.
MARTIN OMANDER: This is good.
DINA GRAVES PORTMAN: Yes, and you
can set kind of like granular permissions per storage bucket.
So I think using Cloud Storage is really great.
Are we done?
MARTIN OMANDER: All right, so the vendor took a picture
with their cell phone of the postcard they'd
written their invoice on.
They send it up.
It's now sitting in a storage bucket in Google Cloud Storage.
Now what?
DINA GRAVES PORTMAN: We need to get this data from the bucket
somehow into Cloud SQL.
So we don't want to have a system where somebody's
got to login and look at all these images
and then input it into a form, because, well,
what's going to happen is it's just
going to take for take forever.
It's going to sit there for a really long time.
People are going to make mistakes.
And then the vendors are going to get really angry when
their payments are super late.
So I think we need to do some kind
of event-driven development here,
so that as soon as the image goes into the storage bucket,
something happens that starts us on our pipeline
into the Cloud SQL.
What do you think?
MARTIN OMANDER: OK.
Yeah, I like that.
And we can easily setup a Cloud Function to do that.
So if a new document drops in this bucket,
then trigger this Cloud Function.
And the Cloud Function gets the document so it can work on it.
OK, so the Cloud Function now has
access to this image taken in-- a PDF or image taken
with a phone.
And now we need to pull data out of that.
How do we do that?
DINA GRAVES PORTMAN: With machine learning.
MARTIN OMANDER: Of course.
I like your enthusiasm, but I'm not really a machine learning
expert, Dina.
DINA GRAVES PORTMAN: Oh my gosh, neither am I.
But the great thing is, you don't have to be.
Now we use machine learning, not just because it's cool
and because it's a buzzword.
Machine learning is the tool to use
when you need to make decisions on things that you
don't know about yet.
You have seen examples of it in the past
and you need your system to be able to look at it
and make a decision without having
an exact recipe, a list of steps to follow.
And so this is a perfect example.
Because we don't know what fields
are going to be on this form, we don't
know if they're going to be writing
little handwritten messages with hearts on it.
So we need some kind of machine learning
API to be able to go in and parse the information.
Now luckily, Google has a lot of products
that already have prebuilt models for you,
because I do not want to go in and build
my own model for this.
MARTIN OMANDER: Google has probably
seen far more documents than you or I have seen
or can come up with, yeah.
DINA GRAVES PORTMAN: Exactly.
Exactly.
And I don't have the time to collect a million examples
to be able to train a new API.
So I think we should use the Vision API,
because the Vision API has a feature that
lets you parse forms.
MARTIN OMANDER: Oh excellent.
Cool.
So Vision API there.
We run that, and then the output of that is like--
it can tell things like tax was $100,
the total was $500, that sort of thing?
It'll pull its properties?
DINA GRAVES PORTMAN: Exactly, exactly.
So it'll go through and it'll find the labels
and then it'll find the values.
And then you have this structured data.
But the only thing is, we need to be
careful about trying to put this directly into something
like a relational database because we don't
know all the fields that are going
to be on the form in advance.
MARTIN OMANDER: Ah, right.
I think I have just the right thing.
So we have documents with certain properties.
We don't know exactly what properties.
There is a database product built for that, Firestore.
It's a document database.
So each document can have different properties
from other documents, as well.
So it's sort of semi--
it's more ordered than just an image,
but is not as strictly ordered as a SQL database.
DINA GRAVES PORTMAN: Perfect.
Perfect.
OK, so then we have the event triggering the Cloud Function.
The Vision API looks at it and says, hey,
this is the name of the event.
This is the vendor.
This is how much it costs.
It puts all of that into Firestore.
And then when our accountants log onto our App Engine web
app, we'll pull up that document from Firestore Firestorm,
and then they'll be able to look at it
and they'll be able to approve it
or to be able to edit it slightly.
Maybe look at the image and say like, oh no.
This wasn't for Mom and Pop Vineyard.
This was for Sonoma.
I don't know.
[LAUGHTER]
MARTIN OMANDER: Right, or one image,
one number was a little smudged.
And then in that one out of 100 cases, they can go in and tweak
DINA GRAVES PORTMAN: It.
Yeah.
MARTIN OMANDER: I like that.
And that would do that from App Engine.
And you said then that feeds into SQL, right?
DINA GRAVES PORTMAN: Then we're done.
MARTIN OMANDER: Yay.
I like this.
It's sort of order out of chaos.
Chaotic data comes in and gradually gets
more ordered along the way.
And finally, it's ordered enough for the accountants
to issue a payment.
DINA GRAVES PORTMAN: Yeah Yeah.
No, the great thing is that there's these two
different work streams.
One is just your very, very classic App Engine Cloud SQL.
And the other really takes advantage
of all of these new event-driven,
and machine learning, and Firestore,
and all these new technologies and ways of coding and ways
of thinking.
And then we put them together and, like you
said, order out of chaos.
MARTIN OMANDER: Thank you, everybody, for watching.
If you would like to see me or Dina design
another serverless app, please let us know in the comments,
or if you have questions about this one.
Also, let us know what other topics
you would like to see in this video series
about serverless computing.
Until next time.
[MUSIC PLAYING]