Hi, I'm DJ Spiess.
The speed at which we deploy our microservices is critical for creating a functioning system.
If we can't deploy fast, we can't scale.
In this video we're going to look at a few scaling issues we must to address when deploying
our microservices.
When you think of a microservice, think of a cat.
A little effort, and you probably can get it to do what you want.
Now imagine adding another cat.
It's a takes a bit more effort, but you could probably manage them.
Now think of adding hundreds of cats, maybe even thousands.
That's the challenge we face with large microservice systems.
Lots little slinkies with fur, and without a plan to manage them it's chaos.
There's many areas to discuss when scaling your microservices, and we'll eventually discuss
all the ones I know about, but for now we're going to focus on one pain point at a time.
In this video we're going to address scaling issues while deploying microservices.
To succeed at cat herding, I mean, microservice architecting, we need a controlled way to
introduce new microservices into our system.
Here's the first area we need to focus.
Continuous integration.
The way this works is our developer issues a pull request for a Git repository.
To keep the workflow simple, we'll assume this work was for an approved feature or bug
fix.
The pull request triggers a workflow, usually executed by something like Jenkins, but we
can insert our favorite scheduler here.
The pull request then goes to a peer review.
That's why I'd use a pull request instead of just pushing code.
Pull requests make the peer review simple.
On approval the code gets built and packaged into a Docker container, it's tested, stored
into an artifact repository, and then it gets deployed.
Every step in this process we make automatic will make our lives much better.
Once the code is accepted, it should be automatic all the way to production.
So what does this buy us?
Well, with an automatic workflow we can shepard new code into our system very quickly.
This is true for any system, not just microservice architectures.
Here's why it's critical for deploy mincroservices.
Continuous Integration allows us to deploy to production hundreds of times a day.
The more automatic we make deploying to production, the less it's a pain point for us.
That's important because, we're trying to deploy hundreds of microservices.
Our process should not take days, weeks, or heaven forbid months, to deploy a release.
If it takes longer than the time it takes to push a button, our deployment process is
too long and it will kill us.
Push button deployments will also make it easy for us to rollback if we need to.
Just push the button to deploy the previous version.
Kill the new version instance.
Done.
This also allows us to forget about instances that are going sideways.
If the container has a glitch, or the machine the service is running on is failing, kill
it.
Start new instances on another machine.
Done.
Putting our code into Docker containers makes the act of deployment the same for every microservice
every time.
The action is, "run this container".
We can specify compute requirements, but at the end of the day we don't care where it's
run.
At some point in our system's life, our system administrator will come to us and say, we
don't have any more room for compute.
We can't scale until we get more hardware, and that process takes weeks.
If we don't care where our microservice is run, we can deploy anywhere.
Running in containers allow us to do something called cloud bursting.
That means when we run out of compute in our datacenter, we can scale up on cloud services
like Amazon or Google.
We'll use something like Kubernetes to orchestrate scaling up, scaling down, and cloud bursting.
Another thing we'll need to do to keep deployments easy is more of an architectural issue to
address.
When we design our microservices, they need to be stateless with zero dependencies.
I don't mean the data the microservice processes cannot be in a state.
Stateless means that any microservice instance can handle any request at any time.
It doesn't need to be a particular instance.
If our sales microservice needs to talk to a particular order microservice and only that
microservice, we'd have to replace both just to replace one.
This makes the two microservices, pretty much one microservice.
Keep doing that for all your microservices, and suddenly you're replacing the whole system
everytime.
That's no good because it forces us to deploy more than we need to.
We do not want deep dependencies between microservices either for almost the same reason.
The more coupled our microservices are, the harder it is to deploy one without coordination
with the other.
The more this happens in our system, the more our system looks less like microservices and
looks alot more like the monolith system we're trying to escape.
This means we need to design our microservices to fail gracefully, and function when other
microservices fail.
To make deployments truly independent, each microservice must be able to function in a
vacuum and wait until other services are available.
So that's a few things we need to be able to scale easily.
I'm sure I've missed a few things.
Let me know what I've missed in the comments below!
If you liked this video, make sure you like and share.
This helps get the video in front of other viewers!
New videos come out each week, so make sure you subscribe.
You don't want to miss a video!
Thanks for watching, and I'll see you in the next video!