Hello, thank you for attending
my talk - Building a serverless
startup to manage enterprise
serverless solutions. My name is
John Liu, I'm a founder of a new
startup, and I've been a
Microsoft MVP in the Office 365
and the Power Platform space.
This is my personal story. I had
been a 20 year enterprise
developer and a consultant based
in Sydney. I do mostly Office
365 customizations and
integrations, and from that
I do a lot of user groups and
talks about .NET, Office 365,
how to integrate that with
everything. I do, a lot of Power
Platform talk. My first job 20
years ago, it was not successful
startup and at the end of the dotcom boom
the founders decided that they
will close down. I've always
appreciated and admired founders
that build startups, so 20 years
later I get to, I, I found a
niche to take that leap
and make that a reality for me.
So hopefully this is something
that could be inspiring for you
at the various parts of this
journey and hopefully, and let me
know if there's something that
resonated with you, or is this
something that you have some
feedback for me as well. So this
talk is broken into three parts.
Firstly, I want to talk about
what is the actual business
problem. So there are two parts
of the title building the serverless
startup and the goal of it is to
monitor enterprise serverless
solutions. And the part of the
enterprise server solutions are
really want to talk about is in
this first part, which is the
enterprise serverless solutions
that are rapidly being built
within enterprises that are
using Microsoft platform,
particularly using Microsoft's
Power Platform. So if you're not
familiar with the Power Platform
there is a little bit of
introduction about what that is
and why I think that's a big
deal. The second part is what is
then the technical, the actual
technical stack for my startup
and of course, why is it serverless
Serverless solves many challenges
that my startup needs in
and it's a very deliberate
decision about why we choose the
serverless stack to build our
startup. And finally, I
wanted to talk a little bit
about something that I wish I
knew, right? There, there's just
so many things that you don't
know when you just get started.
But I wish I knew some of these
things. Maybe you're in a
situation where you're nodding
your head, or maybe you're in a
situation where you about to
take your first step and this
could be useful nuggets of
wisdom. So lessons I wish I
knew when I started. What is
actual business problem?
and to describe this, I'll
describe a bit about Microsoft
Power Platform. So the Microsoft
Power Platform is currently
there are four products in a
Power BI, Power Apps and Power
Automate, and become popular mostly
in the last three years. I'm
particularly focused on Power
Apps and Power Automate, and
particularly Power Apps is for
building front end applications
so certain developers can build
front end applications very
quickly, integrate with
a variety of data sources they
could deploy that to web and to
mobile, and then Power Automate
is a sibling to another
Microsoft product in the Azure
stack called Azure Logic Apps.
Now if you're not familiar with
either Power Automate or Logic
Apps, Logic App is similar to
something in AWS called step
functions. So in step functions
you have basically a serverless
way of doing orchestration of
your various function. So
imagine you have lots of
Lambdas, or you have lots of
Azure Functions and you needed
the way to orchestrate it to say
hey if this action were to
error, I want that to retry and
when I retry I wanted to do an
exponential scale out or if that
action could potentially fail
then I want to continue with the
file path whereas if it was
successful I'll do a success
path. So that kind of
orchestration of your serverless
functions. Now, in both Logic
Apps and Power Automate, so on
the Microsoft side, in addition
to just the orchestration
constructs the branching
constructs, parallels, the fan
out and fan in.
There are also 370 connectors so
these are prebuilt connectors
with loads of actions that will
connect easily to Office 365,
Dynamics 365, Azure. So those are
first party but also the third
party to AWS, to Google
Apps, to SAP and then if you go
beyond what out of the box with
these connectors you also have
direct HTTP, so you could just
call HTTP with any, any,
any API, most API endpoints that
have an API or rest endpoint you
can call them. You can call XML,
XML web services from over a
decade ago. You can call
anything that implements an Open
APIs or swagger definition.
There is also support for on
premises proxy, so if you wanted
to bridge the futuristic serverless
online world with your legacy
Enterprise on-premises systems
that are talking old XML web
services, there is also on-prem
proxy that will bridge that gap
as well so very very flexible in
terms of building
very complex orchestrations, but
then also give you that very
visual view of how your
automation is happening.
Similar to Functions as a
service, Logic Apps and Power
Automate can be used to create
these workflows and we call
them flow, so both in Logic Apps
as well as in step functions
the workflow that's created is
called a flow and the execution of
this flow is called a run. So,
that there is a particular focus
for me to look at
as enterprises are scaling out
an taking advantage of the Power
Platform which is
yeah, taking advantage of Power
Platform then there should be a
way to monitor and control the
Power Apps and flows that we're
creating. There's some insane
crazy numbers because Power
Platform is bundled with existing
Office 365 and Dynamics
customers have already access to
these products, so what we're
seeing then is that in the last
three years we have seen a 3.5
million low-code developers have
started using the Power Platform
and in 2020 alone we have
seen an additional 1 million.
In terms of companies we are
looking at currently as of
2020, 300,000
enterprise companies have
adopted the Power Platform,
so it's a big massive
numbers.
This is a problem I kind of 
alluded to. So imagine that in
the past you have professional
developers building integration
between say, Office 365 and your
CRM Dynamics 365 that
used to be something built by it
with a professional developers
team. But now the pieces are so
easy to put together you would
have maybe someone
that has, maybe, this is now a
system that's being built by the
business using. Once
they build these tools are
there then expect IT to manage
them or maintain them going
forward. So there is this issue
where if you think about,
if you take the picture of this
map right, this is a picture of
Sydney and you have these
buildings. Imagine these
buildings are the applications
in your enterprise, so this
could be Office 365. This could
be Exchange Server. Another one
could be your SQL Server
database. Another one could be
the Google Docs that you use.
Another one is QuickBooks or
Xero where you do your
accounting and so on and so
forth and then you have
connected them using flow.
Or something similar to flow.
So imagine that you have these
buildings being products, but
then you have roads being these
automations or the serverless
automations that are listening
to a webhook and sending that
data into another system or
looking at a drop folder and
then taking that CSV file,
importing that into a different
system. So you basically are in a
stage where there's all these
roads connecting all these
systems, but then let's cast
over this fog over Sydney
and suddenly you can barely see
the applications that you have,
but you really could not see the
integrations and you could not
really see this integrations are
happening correctly or if they
have failed overnight. So if
something if there was a
bottleneck of there was an error
that happened with one of the
integrations, that could be
quite critical to your business.
Say if a sales opportunity for
your website was lodged in the
website, but it never made it
through to a CRM to be followed
up by employee.
That could be potentially
leading to a loss lead or
lost project.
Something like that could be,
you know, quite business
critical. So what I saw was
that OK, increasingly so many
businesses are going to have
so many serverless automations
they really need a way to
quickly see all this and then
bring that forward, identify
what are business critical and
then make sure those are
monitored correctly.
So Chapter 2. What is the actual
technical solution? And, of
course, why is the serverless? If
these flows are all serverless,
then the solution to monitor and
scale with them should also be
serverless. That's how I imagine.
We talked to some customers. One
of the customers we were trial,
that were trialling. We had a
chat with IT and we asked oh,
how many users have currently
created Power Apps or Flow and
they don't really know. So they
made the guess they say, well...
We have couple 1000 users, we
think probably 100 have started
using Power Apps and Flow, but
we're not really sure and that's
part of why they're thinking at
this stage to putting some sort
of monitoring and governance
around this. So we say, well, no
worry if we don't know the
number once we start scanning we
will see everything and then
we'll be able to do some pull
from that and then be able to
work from from that that
baseline. So we did a full scan
and the full scan for this
company took about 40 minutes to
finish and then we could look at
all the Flows and the Power Apps
that created and it turns out
the number of users that have
already created a flow in this
company was 300. So three times
more than what IT thought. There
are also challenges when
these business critical flows
are created perhaps under one
employee's user account, but that
employee has then since left the
company, so some business
critical flows may begin to fail
because they can no longer
connect to that system because
that employee has been disabled.
So that was kind of a eye opener
situation for one of our trial
companies who are like, OK, you
know, we should really look at
putting in some governance
earlier. Right the technical
stack. There are several
components of it. I want to look
at the storage aspect. The
storage for us, we mainly are
using just reliable cloud
storage. We do have a no SQL
database. We have several
requirements because we're
scanning different companies. We
need the all the data to be
partitioned correctly. Some
companies, particularly in
talking to European customers
there are additional GDPR
requirements and we think about
OK. A lot of these privacy
issues are easier if we don't
actually host that data. So if
we just provide the scanning
service but they bring their own
an Azure Resource Group and then
we just write into that resource
group. So that's how we see
this. Cloud storage is very
cheap now. Being serverless, you
could easily redesign or change
part of your design so you can
have data ingested into a
transactional database or
No SQL database, but large
amounts of these flow runs are
historic so they don't even need
to live in the database. You can
snapshot them monthly into
static JSON files and then just
file them into archive
storage. So lots to think about.
Our serverless compute is using
Azure Functions and this is our
standard function-as-a-service
that we write a single purpose
worker functions to do a
specific thing. Maybe to look at
the flow, then to look at
whether that flow has many runs
and then to look at, oh, some
runs have failed then let's go
deeper and see if there are
errors in that that flow run and
then capture that error so we
can service these and say OK of
this particular one flow which
runs several times
a day we have several hundred
runs and then out of that, 2% of
them are fails and then the
errors that you see are these
errors that are happening with
these flows. So we capture all
that and report those. We also use
Azure Bunctions to build a
Graph QL using Apollo Server and
this really is so that we have
the ultimate flexibility in
providing a rich API to our
frontend and our reporting
components, but at the same time
Apollo shelters from our
decisions that we are making on
the back end data storage. So
the Graph QL server figures out
how to fetch the data
and it will feed it back. Graph QL
let us extend that schema
overtime, which is really really
flexible. So I highly recommend
using Graph QL for that
purpose. If you are not using
Graph QL you tend to end up
designing lots and lots of
different sets of REST API
endpoints. I would caution
against that as Graph QL
is just a much easier way to
manage. Our frontend is using
Angular and that is just
something that we are really
good at. We've been
doing Angular for a very long
time. These are deployed using
Azure Static Websites.
Recently there is a new product
called Azure Static Web Apps which
deploys from your GitHub repo.
We are using the previous
iteration Azure Static
Websites and we deploy that
through Azure DevOps. I still
remember the first version we
build, it was just right-click
and deploy. I know I'm
violating all sorts of DevOps
rules, but that was what we
started. We just
build the application, run it
locally, right-click and deploy
and it was running in Azure and
we were really happy. Now we're
going to build a separate Dev
Build and Prod Build. That was
the point that we put everything
into DevOps. As we roll out to
multiple data center regions in
US and Europe the DevOps
pipeline really helps us
synchronize that you don't have
to do anything manual, you just
run the job and it deploys it to
several Azure data centers. So
Cloudflare manage the CDS, ah
the CDN and then that points
it to our static website.
So this is a very high level
picture. I draw this picture
using a SaaS product called Isoflow.
I just like how everything is in
the same isometric, but not many
icons. So you'll see our user
end up using the same icon for
almost everything. But basically
I wanted to focus, and I color
coded this. Our core product
looks like this - the purple
lines here. We have our Azure
Angular Static Website. It is
connected to an Azure Functions
proxy which is also
functioning as an API gateway
and that is sitting in front of
our Apollo Graph QL.
And that talks to our storage,
and that storage could be 
NoSQL, could be blob storage
is just things that happen in
the back end. So that is the
main product that we built
initially. We needed this blue
line, which is actually a
separate set of tasks. These are
also serverless functions, and
they talk to the Microsoft API's
so that we can collect the
information we need to report
whether these integrations, these
flows, are running correctly.
Then we build the green line,
which is our rules engine.
Which is really upon events that
are happening within the Graph
QL, which is generally because
it was a scan from the system.
We can send alerts to say hey,
these flows have become often or
this super business critical
flow is now erroring, so we
can call out to webhooks. So
that was an additional system
that we built and I labelled that
green and then also we built a
custom connection. In the Power
Platform, custom connection
is an OpenAPI file or swagger
file, and that lets anyone using
the Power Platform, so you can
actually use Power Platform to
talk to our system which scans
your Power Platform. So it's
kind of a,
yeah, it's, it's an interesting
kind of recursive thing that
developers like to do. Also, if
you're coming from Power BI, you
can access our Graph QL. So we
expose our Graph QL API access
point that different systems,
both us and our customers, can
access that. That's a high level
map of what we, this is kind of
the stack that we built. Now
we're pretty happy with the
stack because, and we're happy
that we build it with serverless,
because this ends up being a
stack that grew with us overtime
and you can see the different
lines that we added to the
system. A lot of the individual
pieces that are Functions, but
it is not just Functions. The
stack is made up of a buffet of
serverless components. We have the
static websites, we have
orchestration, so the serverless
orchestration. We have serverless
databases and in Azure we have
Azure SQL serverless, but we
also have customer's DB that's
now serverless as well. Outside of
the address that we've also
looked at Google's Firebase,
which is an excellent serverless
database, as well as AWS Dynamo
DB that is also really good. We
look at event pipeline, so we
have actual Event Grid, the API
routing, so the API Gateway
product. That's also serverless.
Serverless is so cost effective
to experiment. So for us you
know it makes sense for us to
try using Cosmos DB and load that
with a bunch of real data and
then run that for two weeks and
then for four weeks just to see if
you know it has the performance
benefits as well as what does it
look like from the cost
perspective and how will we, it
gives us ideas about how to use
this. And also
it gives us a way to back out,
like if that component does not
work so well, then we can roll
back and say, no, for now we will
stay on blob storage and storage
accounts as well. So the third
chapter. I want to talk about
something that I wish I knew
before I started. What I wish I
knew, and from my consulting time
I knew many of the technical
components, right? So I kind
of knew, look, I need serverless
function here, I need some
Logic Apps here. I need a
database over there, but I've
never tried to put everything
together end to end. So that is
actually super exciting and
something that I really enjoy.
What I didn't know and these are
things that they were mostly not
technical problems. They
were just things that I just did
not know? I don't have startup
vocabulary so I thought we will go
through a little quick check of
the rules of a startup. Why do
we build startup and why it is
the point of a startup and I
wanted to boil it down to these
three. We start here. I start here
if you haven't started, I would
like to inspire you to start on
step one. I have this amazing
idea that I want to bring to
life. You dream and then you
want to bring that life. Now
the real rules of a startup
is, you need to build something
that people will pay for,
because if you build something
that nobody wants to buy, you
will run out of money and then
you have to sadly shut down your
startup. So you need to get to 2. If
you can get this loop happening
then you get your successful
startup and you need this to
happen before you run out of
money. This is the end state.
Don't want to go here, you want
this to be the cycle. So how do
you go from the amazing idea to
something that people will pay
for? There a really 2 words here.
One is called experiment. You
need to build lots and lots of
experiments, different
experiment, they could be tweaks
of the product. It could be
talking to customers with a
sketch of an idea. But if 
that idea is really not
working and you need to flip
that idea upside down. That's
when we call them. We use a
different word - it's called a
pivot. So you pivot to the
correct idea, not the original
idea, but the correct idea. So
lots of experimentation will get
in this loop. And then,
ideally, hopefully you will get
to build something that people will
gladly pay for.
OK, that's the rules of how
startup works and you want to make
this loop as short as quickly
and your main benefit is able to
experiment quicker and be able
to execute quickly.
So, abuse that as your starter
advantage. Now, second thing I
wish I knew is marketing, and
as a developer minded person and
perhaps as a consultant, always
building projects for other
customers. There was always the
thought that well, if we build a
well enough then people will
come. Right, if you build it and
there's no adoption, then that
just means you didn't,
you didn't build it well enough.
If you build it well then surely
people will use it? In reality,
that's probably not so true.
If you build it, they won't
come. You have to talk about it
and that could be as far as
building entire marketing
pipeline. So you know, talk to
people about it. Talk to your
potential customers about it.
Build awareness that you're
building this product. Give a
talk in serverless days about
your product and do all these
things and then additionally,
you need to actually build
systems to measure that pipeline
too, so you're building all
these marketing pipeline, the
lead-in signals, and maybe
they're leading people to your
website. Maybe they're leading
people to your YouTube channel
and then from there are they
leading people to your product
and they are leading people to that
trial page, alright, so all that.
Measure that pipeline, if you
measure the pipeline, it gives
you the ability to tweak
what you doing in your marketing
and we'll talk about that in a
minute. Similar to marketing
you have a different pipeline.
It's called the sales pipeline
or the sales funnel. You have to
go and sell then and I have
nearly two years now was when I
first integrated Stripe payment
system with our first product and
for some reason it just took me
weeks, several weeks to make that
work and I think the main reason
is my mind is so much in the I'm
building my core product.
This getting Stripe integrated
as an auxiliary function and my
heart was just not in it so I
dragged and dragged and finally
I put everything in and it's all
working. And then it's been
working ever since, right?
The people are able to
trial the product, I will manage
the trial period and it is
working so well for the last two
years. It felt like a struggle
when I wrote it, but afterwards
it was like, well, I should have
wrote that a lot earlier. Build
yourselves pipeline, integrate
sales into your product, and
then also regularly reconsider
your pricing. You know pricing
is not a thing that is set and then
forget and you never change.
Particularly early startups if
you come across a startup
that's in that stage with they
still trying to figure out their
pricing, then generally you can
get away with very cheap
discounts. So support your
favorite startups while they're
young, usually they reward you
with some sort of, you know
grace period of the cheap price,
which really will help your
business as well. That's the
third three points. One more
point. I thought I'm building a
product and that goes back to
maybe, I come from a
consultant, I thought I'm just
building a product. If I build
product people will love my product,
they buy my product. Uh, no,
actually you're building a
startup and the startup is less
about the product than it is
about the business. Building a
startup is building a business,
but there are a lot of strong
parallels and I kind of want to
drag this out. When we think
about product or project. It has
technical components, it has
this React or Angular libraries
that we attach. There's Apollo
library that we use here. There
is an Azure Function here and
there is a Cosmos DB there.
They're technical components
then ties to product.
A business, though, has processes
and I talked about some of them
earlier, your marketing pipeline
or your marketing funnel use a
process. Your sales funnel use a
process. A business is made up
of these processes and it makes
the entire machine work, right.
If you just think about a
product you end up building a
product that has no customers.
You need the processes to
bring in the marketing, the
awareness, to teach people about
your product and then bring them
to try your product.
And then bring them to buy your
product, right? So it is the
process is that makes the startup
at work because the startup is
more like a business than purely
a product. So processes, hold on
the processes because we're
about to talk about processes.
Many of these processes can be
fastly improved if you find the
right size solution to help us.
Right, so you you come up with a
way of doing your marketing or
you come up with a way of doing
yourselves. You don't have to
build all that from scratch. You
could usually find a SaaS
solution that will plug very
neatly into that position. So we
should focus on what we can
provide and everything else,
billing, handling credit cards,
doing marketing, tracking your
users as they use your
application. This should be just
SaaS products that you purchased
and plug into your system. Don't,
don't build things that are not
core to your product, just
buy SaaS - that will help you. OK,
this actually leads me back to
that starting point, right?
As we start to build this out we
need integration, right? These
different SaaS applications that
we're using we need them to
integrate together. All this is
to help that idea of how can we
experiment something fast. If a
component in our product doesn't
work, whether it's the Azure or
AWS component, we just
replace that component. If it's
a SaaS product that doesn't fit
our pipeline, our process is
then we replace that SaaS
product. So ultimately many
businesses from the beginning, I
talked about many businesses use
a lot of SaaS applications.
Anyway you, I realize that every,
many, business, including my own
business, use a bunch of
SaaS applications and we live, we
all live in a world where we are
you choosing the best of breed
products that helps our
business. And then we're using
serverless to connect them
together. So I'm back to Isoflow
again and that this is a
different diagram, so the
earlier diagram was about one of
my products. This diagram is
actually about my entire
startup, and here you can see
these are two of our products
currently in studio that we
sell. We do application insights
we use mixpanel to track user
engagement and then these are
integrated this green line,
these are flows that integrate
them into our core database.
From there we take information
off to HubSpot which is our
CRM. We take information off to
Office 365 and then this is also
connected to our DevOps, so our
teams are here, our Planner
which are task boards are here
in Office 365 and then our Teams
are notified when we do DevOps
which does the push out to our
products. Over here we also have
our blog and YouTube feeding
through Google Analytics into ou
database. We have Stripe
payments feeding information for
webhooks. We have our
QuickBooks feeding information
into both documents and also to
our database and then we have
Mailerlite which does our monthly
newsletter and then whether
people unsubscribe or engage or
click with those newsletters we
feed that also back to our
database. So the setup is made up
of process is each one using a
SaaS application. But all these
are integrated together, right?
And so as I look at the green
lines which are actually flows
that we've written for our own
startup. We can see when the
flow fails, then there is
actually integration
problem between say Google
Analytics in our database.
OK, see this red line, so that's
really what the North star of
the problem that my startup
set out to solve, which was when
their business integrates all
their systems together using
something like Microsoft flow.
Then we could clearly visualize
and blow away that fog that
you see at the beginning of the
talk, or blow away that fog,
and then make it clear where are
the critical process is. So are
they being monitored. A very
quick summary of the three
chapters. Microsoft Power
Platform. It is created 3.5
million serverless local
developers. They don't know
this, but they're all using
serverless technology. Two - I talk
about our stack and the main
point there I wanted to make
was that it really gave us the
freedom to pick and choose
multiple components. We can
experiment with products that
were created by Azure or AWS
quickly to see which one is the
best fit. So that help us
experiment quicker. The three
is you should let serverless
handled the technology side
because you are trying to make
your dream come true. For that
to come true your startup
needs to be successful and for
your startup to be successful you
must focus on how can you
experiment quicker so that you
can get the product market fit
and produce the product that
your customers will pay for,
right? So you need to be focused
on building and growing
and executing all the process is
for your startup. Let
serverless worry about the tech.
It is exciting the build serverless
startup, but is also super
flexible to change with.
And that's the end of my talk.
You can contact me on Twitter at
@johnnliu, so there's an
extra 'n' and you can have a
look at my product at PowerClarity.app
I have a few links I
wanted to share. If you're keen
to try the Power Platform, go to
aka.ms/TryPowerApps and
you can learn that for free.
There is a whole tutorial where
you could follow through and you
can also try Azure Functions if
you're pro developer and wanted to
see what it's like to
experience, to create serverless
functions on the Azure stack.
Join the community newsletter.
Make sure you go to 
aka.ms/AzureServerlessSwag and claim
your free swag. Thank you very
much, I had a load of fun
preparing for this talk. I'm
sure some of you would have been
building startups for way longer
than I have, so I'm very keen to
hear any feedback you have for
me. I reach out to me. If you
have any questions for me or let
me know, give me any feedbacks.
I hope you enjoy the rest of
Serverlss Days. Enjoy many of the
sessions. And I'll see you
soon. Bye, bye!
