Okay, let's take a look at an example of what a microservice architecture actually looks like. In our fictitious example, you have some type of web application that you want to serve, and that has a backend API that you want to communicate with or perhaps a public API that your customers can interact with.

So we have a client, your customers, and then they will have to hit some type of endpoint and this is usually managed by an API gateway. This can be done through AWS API Gateway or Google API Gateway, or even managed within Kubernetes with a component called Ingress, which we'll talk about later.

The microservices themselves are all managed and orchestrated via Kubernetes. So depending on the endpoint that your client hits, it will point to the correct microservice within your Kubernetes cluster. In this example, there's communication between other microservices within the cluster. It's important to note that each one of these are independent though.

The last thing I want to cover before we move on, is my microservice methodology. When I'm designing a new service, these are the three things I try to keep in the back of my mind. The first is, keep things small. We're not looking for a monolith. Keep it decoupled. If I notice I'm pulling in a class or an object from another package in my repo, then there's something wrong and I'll need to look at service communication instead.

Lastly, microservices should embrace the Unix philosophy and if you're unfamiliar with what the Unix philosophy is, it's do one thing and do it well. I believe this to be very true when designing a microservice. If you take away anything from this, it's that microservice should be doing one thing and they should do it very, very well.