Hey there everyone!
DJ here and unless you've been living under a rock, you've heard the latest coding buzzword
"microservices".
Microservices, microservices, microservices.
In this video we'll go over what is a microservice, why people are moving to microservices, and
finally what you need to do to make an effective microservice.
So what is a microservice?
Ask 20 developers what is a microservice, and you're likely to get 25 different answers.
Here's my best answer.
A microservice is basically a self contained process that provides a unique business capability.
Different microservices act in concert as one larger system, but behind the scenes,
it's microservices all the way.
Take Amazon.com for instance.
All we see is the website.
Behind the scenes, Amazon has a service for accepting orders, a service for determining
a list of recommended items to buy, a service to handle wish lists, a service for authenticating
credit cards, and so on.
All of these services are really mini applications performing a single business capability.
What makes this organization interesting is, it is not organized around software layers.
We don't create a web microservice, business logic microservice or database microservice.
We are creating microservices around business capabilities.
So we have a wish list microservice, a order microservice, and a processing microservice.
Microservices communicate with each other through a well-defined interface, usually
REST or a messaging queue.
The communication is almost always stateless.
The microservice data is federated as well.
That means every microservice is responsible for its own data model and data.
I think that statement just caused heart palpitations for some DBAs.
There might be good business reasons to standardize the data platform for all microservices, but
the idea is if we're on the team building the microservice, we should know best which
persistence model we need.
It's the latest buzzword, so why not?
Seriously though, microservices make our system loosely coupled.
If we need to upgrade, repair, or replace a microservice, we don't need to rebuild our
entire application.
Just swap out the part that needs it.
Rebuilding isn't a big deal for a small desktop app, but it can be a killer for a whole enterprise
system.
Breaking our system into small parts also allows each microservice to focus on a single
business capability.
One benefit of this is we can have a small team focused on a simple task.
Jeff Bezos from Amazon created the two pizza rule, the ideal size for a microservices team
is one you can feed with two pizzas.
Single benefit capabilities also help drive the focus of what our group is trying to accomplish.
It becomes very easy to determine if a feature is in or out if our goal is focused.
A simple interface means we can use different languages and tools.
If we've got a great well-defined interface, it doesn't matter what language or architecture
we use.
We could write our service in Visual Basic if we wanted.
As long as we publish how other services are to communicate with our service, we're good
to go.
That's why the most common methods for communication between mircoservices are HTTP and messaging.
Everybody supports that.
So what makes a great microservice?
We've touched upon a few things already.
First, I'll say it again.
It focuses on a single business capability.
That isn't to say it does only one thing.
Just one business thing.
It does not mean we divide into a web capability, logic capability, and database capability.
That's going back to what we had before.
Each microservice should have it's own datastore.
This limits what can change under the microservice.
If another group is responsible for the data model, they can also change the data model.
That can force downstream changes for many microservice teams.
Changes that might not help our team at all.
Make communication stateless.
If our communication is stateless, we can add more copies of the microservice at will.
Stateless communication gives our microservice the ability to scale effortlessly.
Each interaction with our microservice can be handled by a different instance.
Since the communication is stateless, great microservices should be able to continue if
another microservice fails.
That means if we can't communicate with another service, our service should be able to make
due.
If we're trying to get a list of suggested titles from another service, we'll have a
default ready just incase.
Our service should never break, just because another service broke.
Finally, a good team makes a good microservice.
We need all parts represented.
That's a designer, web developer, coder, database admin, and operations all on our microservice
team.
Not representatives.
On the team.
It's everyone we need to make a fully functional application.
Up to two pizzas of course.
And that doesn't mean find lots of developers who hate pizza.
Hey!
Thanks for watching the video.
If you like what you're seeing or have any questions, let me know in the comments or
on DeegeU.com!
New videos come out each week, so make sure you subscribe.
You don't want to miss a video!
In fact, lets go watch another DeegeU video.
See you there!