ANDREW HARVEY: Hi. My name is Andrew Harvey.
I'm a Principal Program Manager
for Microsoft for Startups.
Today, we're going to talk a little bit
about architecting your startup stack.
We think a lot about architectures and often they're
really big architectures and enterprise architectures,
but even in a startup,
it's really important to think about how
you're architecting the product that you're building.
Today we're going to talk
through a few things to help you do that.
We're going to start off by talking through the stages
of a startup and stages of innovation,
and we're going to use those to
help us drive the architectures that we're going to make.
We're going to talk a little bit about
some technologies and some tools.
Then I'm going to show you a little bit
of something that we've created for you
so that you can maybe get started and see how things can
go together. Let's get into it.
Let's talk about some startup stages.
Now, startup stages are important
because knowing where you are,
helps you know what you need to do.
Thinking about the stage you're at is
going to help you understand
what architecture you want to
build and how you want to focus on that.
What I want to start off with when we talk about
stages is maybe some graphs.
I love graphs and I think
everyone in startups likes this graph.
Everyone loves a hockey stick.
It's that great up and to the right feeling.
Now the problem is
your x-axis is always going to be
time, and that's always moving on.
The only thing you control is heading up.
But I've seen a lot of
these graphs in pitch decks and that kind of thing,
and they honestly are
the Instagram selfie of graphs and startups.
They don't really tell you the whole picture, and it
doesn't really tell you all of the work that
goes into creating something great,
creating a great startup.
The bad news is,
is that the hockey stick is only part of the picture.
But it's also good news because understanding
this whole progression that your startup
takes is going to help you make
better choices at every stage.
It's very true as engineers,
that we can get focused on building the thing,
writing the code, keeping it running,
and we don't look around at
the context of the business that we're in.
Being able to do that is going to help us
make better decisions as we architect our startup stack.
Get used to this curve.
Get acquainted with it.
We're going to get into it a little bit more.
A gentleman called Kent Beck
described these three stages of innovation.
It really maps well to
this sigmoid curve that we've got here.
He starts off with explore, and then expand and extract.
These help us understand the different stages
that a startup goes through.
Let's start off with explore.
Explore is really that stage where
it's early on, when you haven't yet found
product-market fit or even problem-solution fit
where you're trying to find out what works in market.
Now, when we're exploring,
we're really trying to test ideas.
We're trying to find what's going to fit.
That's what we need to optimize
for with our architecture.
Really, it's about finding what works, but quickly,
because every moment we spend here,
we're not doing
the scaling that we really want to be doing.
We want to try our ideas quickly.
We want to understand what works
and truly understand what works.
We need to be ready to scale or pivot; scale if things are
working and we've found
the right thing, or pivot if we realize that we haven't.
That leads us to the second stage of
innovation, and that's expansion.
What we want to do here when we're
expanding is we want to
be able to acknowledge
that the things that we did before were good,
but we need to do more to
keep on moving and to keep on scaling.
What got us here won't get us there, if you will.
What we need to do is we we need to
reduce any friction for growth.
We need to take the engineering decisions that we've
previously made that might have been
good at the time, or maybe they weren't.
We need to re-look at those and reassess
them so that we can scale and we can
grow with our business.
We need to eliminate scaling bottlenecks.
We need to be able to
find them and eliminate them quickly.
We need to spend time investing in and
developing our architecture and
processes to enable the scale that we want to have.
The final stage is one that we call extract.
It's really about stabilizing
and getting ready for the next round.
Now, this is not one
that we really encounter that much in startups;
it is really more of a thing that we
encounter in mature businesses.
If you have reached the point of extraction,
Microsoft has a wonderful slew
of people who can help you out.
But really, when we're talking about startups,
it's very much about those explore and expand stages.
But just for completeness' sake,
what we're doing in that extract stage
is we're increasing operational efficiency.
What we want to do is we want to consolidate
the position we have and reduce risk.
The game has changed from trying to find what works,
from we know what does, and we want to keep it working.
We want to defend against competition. You know what?
The great thing is, the way we get there is by spinning
out more and new ideas and
returning to that exploration stage.
How do we use these business stages
to help us drive our architectures?
Well, I want to talk just about
the explore and the expand stages, and some of
the things that we can do and some
of the tools that we can use
to be able to drive that architecture
with that business stage.
Now, we've said that exploration is about
testing these hypotheses and testing these ideas.
What we need to optimize for
when we're exploring is for speed,
for cost and options.
When we're thinking about speed,
what we want to do is be able to have fast iteration.
We want to be able to test one idea, then the next,
then the next, as most of our ideas
just unfortunately aren't going to be the greatest.
We need to be able to test, and we need to be able
to move quickly through those tests.
In that case, simple beats complex.
It's far better for us to have
a simple architecture that allows us to quickly
move to the next thing than over-investing
in a complex architecture which is going to limit us.
We want to optimize for developer velocity,
because in the end it's the developers that are
creating these different ideas.
They're bringing them into the world and we
need to allow them to move quickly.
Choosing the tools correctly and optimizing our
architectures for developer velocity
is very important at this point.
Now, the second thing that we want to think
about when we're exploring is cost.
We want to avoid over-investment.
Not just in terms of monetary investment,
but also in terms of time investment.
We don't want to spend a whole lot
of time, because honestly,
your payroll is going to be
far greater than your cloud bill at this point.
You want to be thinking about that.
You want to be thinking about the time you're
spending and that your people are spending.
But if you're thinking about services
as well in your architecture,
you want to think about how much do you really need?
How many customers do you really have at this stage?
How much, or even better,
how little can you spend to test these ideas?
Then you want to be able to scale on demand.
You don't want to have a whole lot
of resources allocated that you're not using.
You also don't want to get caught out.
Be ready to scale on-demand and
choose services wisely for that.
The third thing you want to do is you
want to optimize for options.
You want to give yourself options and not paint
yourself into a corner with an architecture.
Often, when we build
sophisticated and really robust architectures,
they can lead us down a certain pathway.
The problem with doing this at
the explore stage is we don't
quite yet know where we're going.
You want to allow for divergent exploration,
and you need to make choices in
your architecture that allow you to do that.
You want to avoid
tunnel vision that is going to restrict you and
restrict your ability to take a good idea that you might
find and run with it into expansion.
What about expansion? What do we need to optimize for
when we are building
our architectures when we're expanding?
Well, scalability is probably
number one in everyone's minds,
but also security and
observability become really important as we hit
this stage, because the game changes
and we need to think a little bit
differently about what we're doing.
Scalability. Now, there's lots of ways to approach scale,
but I think for us, as we're expanding,
the best thing to think about is being able
to scale in small increments.
That means choosing services and
instance sizes that allow you to take
little bits and add them together rather
than having huge monolithic changes.
Scale in small increments and embrace asynchrony.
As you split out into microservices,
which is often what happens at
this expand stage, you want to be
able to have services talk to each other asynchronously,
which is going to allow you to massively increase
your performance without necessarily
having to spend a huge amount of money.
The third thing that you want to think about when you're
scaling is not just scaling your infrastructure,
but also your team.
What's probably happening as you're
expanding is that you've hired
a whole bunch more developers, and you can't have them
all working on one code base all at the same time.
Things are probably starting to split apart,
so you want to think about how do you scale
ownership of services and
even micro architectures themselves
to different people within your team?
That's important when you're thinking
about architecture at this stage.
Now, we want to think about security as well.
Security is always important,
but especially at this stage where you're expanding,
you're becoming a bigger target, and it's
really important to have this front of mind.
My main recommendation to a lot of
startups is buy, don't build.
If security is not your primary competency,
you really want to be able to bring in expertise,
and the best way to do that is buy that, and
using products which are trusted.
Whether it's products like Azure Sentinel or
maybe investing more in
identity services using Azure Active Directory,
think about using those rather than building your own.
The second thing you want to do
is choose your tolerance level.
There are a lot of ways to spend a lot of money
building an incredibly secure infrastructure,
which is potentially not
necessary for the industry that you're in.
If you're in a high regulation environment,
then yes, you need to invest heavily in this.
But finding that tolerance and
that risk level is really important for doing this well.
The third thing that is really going
to help you out is thinking about zero-trust services.
Perhaps in the explore stage,
the way that you did service authentication
was maybe a little bit fast and loose.
As we head into this stage of expansion,
as you are a bigger target,
you really want to think about how
your services are interacting, and really
working towards zero-trust networking
so that even if one thing gets breached,
you actually managed to restrict
the damage and the blast radius of that thing.
Now finally, for the expand stage,
you really want to think about observability.
You want to find your bottlenecks early.
To do that, you need to have a good vision
over what's going on inside your stack.
You want to have good vision for what
your users are doing and where the load is.
Investing in observability at
this stage can be really valuable.
You want to enable exploration
by finding the different things that are
happening inside your stack and the different ways that
your users are using your products.
You also want to be able to expect the
unexpected, and a good observability system
allows you to see ahead of what's happening,
rather than having problems
come to you when they're already on fire.
Those are the things that we're optimizing
for when we're architecting.
What are the tools and
the technologies that we can use that
are really going to allow us to do this the best?
Well, when we're exploring,
there's three services that I really love to lean on.
The first is Azure App Service,
which allows you to really quickly and easily deploy
applications in a multitude of
different languages into
a really robust environment that scales well.
Azure Static Web Apps lets you take
your react or view or other static website
and get it deployed really quickly
using GitHub actions for continuous integration.
I'm really excited about Azure Container Apps.
It allows you to build great microservices
infrastructure without having to
worry about all of the things that
come with standing up your own Kubernetes.
That's exploring; what about expanding?
It's actually remarkably similar.
That's what you want. You want services that are
going to last with you the whole way through.
Think about App Service again and Container Apps,
but maybe adding into those thinking about really taking
control of your identity services
using Azure Active Directory,
and also really optimizing
your observability using Azure Monitor.
There are more services than these that you can use.
Obviously, Azure has a plethora and there are
others all around that you can use,
but think about the services that you use and
how they fit into the stage that you're in.
Now I've talked a lot, I want to show you some things.
I would like to show you
the startup stack that we have developed for you so that
you can see how we might approach
this kind of problem. Let's have a look now.
This is our core startup stack repository.
This is where we've taken an app, and it's
a Ruby on Rails app because that's my background.
I've taken that and I've
set it up in such a way that it is going to create
an infrastructure and an architecture that allows me to
quickly scale, so to optimize for
all of the things that I've talked about before.
Now, in terms of startup stages,
this is probably heading towards that expansion stage.
This is maybe not something that I would recommend to you
if you're just trying to start out and experiment.
But as you're looking for something more robust,
this can be really helpful to think about.
We integrate systems like Azure CDN, App Service,
Azure database for PostgreSQL, and bring it all together
using Bicep for infrastructure as
code, and GitHub actions for continuous integration.
This repository includes all the files you need
and all of the instructions for deploying this stack,
and hopefully to get you started to
deploying your own stack in a similar way.
You'll go through, you'll create
service principles, and you'll eventually have
a fully-fledged continuous integration stack
that will allow you to deploy
not just your application code,
but also redeploy your
infrastructure with every commit.
I want to highlight a couple of things for you in here.
The first thing is that we've
used Docker really extensively.
We've used containers really
extensively for applications,
and that's for a couple of reasons.
The first is it allows us to have those options.
It allows us to take our application
between different services.
Maybe you might start out on
App Service and move to container apps.
Maybe you want to move
towards Kubernetes in the long term,
but having that core
in containers is really going to help you out.
The other thing that we've done
is we've extensively used Bicep.
Now, Bicep is a language that allows you to write
really robust and powerful infrastructure as code,
basically the blueprint for your infrastructure.
Now our Bicep template will take a couple of
parameters from you and put
them together and create
your infrastructure with just one command.
In fact, you don't even have to
worry about the command once you've got it set up.
GitHub actions will continue to
deploy this Bicep template for you.
What that will do is will deploy your virtual network,
your private DNS zones,
your app service, your database, and all of those,
and put them together
so you don't have to think about it.
Which is really important because again,
we're talking about developer velocity.
You don't want your developers worrying
about how do I connect
to this database or how do I expose this?
It's all done for you in this template.
Have a look at that and see how that helps you.
If you do have issues, we
would love for you to raise a GitHub issue
and for us to start a conversation about that
and to help you scale your architecture.
If you're interested, have a look,
go to aka.ms/StartupStack
and you can see all the code that we have there.
You can see how we're deploying it, and you can even see
our own continuous integration pipeline.
Hopefully, this has been helpful for you, and you can use
these business stages to better
architect your startup stack based on where you are at.
My name is Andrew Harvey, and I'm really
excited to see what you build.