Let's boldly go where no one has gone before. Get ready, Star Trek fans! Jean-Luc Picard will be representing our [microservice](https://konghq.com/blog/learning-center/what-are-microservices)microservice.

Once we have Jean-Luc in our ship (microservice in production), what happens on day 2? We still need to add authorization, load balancing, rate limiting, etc.

With an API gateway, like [Kong](https://konghq.com/kong)Kong Gateway, you don't have to know how to do this because a set of program components, called [plugins](https://docs.konghq.com/hub)plugins, allow you to implement this without any problem. Kong Gateway is the system that provides you with some additional augmentation, like in Star Trek's Borg Collective. They were pursuing perfection in terms of how this species would communicate.

If you want to have a fancy augmentation for your faceplate, you can get it. If you're going to have a fancy augmentation for your arm, you will get it free from the Borg Collective. Similarly, we get all these superpowers of the Kong Gateway for free.

## **Gateway Admits!**

With Kong Gateway, we can enable all this required functionality on the side of the API gateway. That way, your consumer API calls engage through the API gateway, and Kong translates specific calls to your service. There are hundreds of plugins available with Kong.

What happens when you have thousands of services? They'll need to communicate with each other. That's where a service mesh comes into play in this log.

## **Road to Service Mesh**

Resistance is futile. You will be assimilated. What I mean by that is all of our microservices, including Jean-Luc Picard, will be a part of the Borg Collective hive mind via a [service mesh](https://konghq.com/blog/learning-center/what-is-a-service-mesh)service mesh, like [Kuma](https://kuma.io)Kuma. That way, they'll always be connected and leverage a unified set of tools.

All these components are plug-and-play. Kuma supports deployments across multiple platform types as an open source service mesh.

A service mesh manages communication and configurations via a data plane, like Envoy. Data planes, in this case, are the Borg queen, and the microservices are her drones.

### ***Kuma Mesh Architecture***

The control plane is the brain of the microservices operation. It can operate over multiple zones or multiple work Kubes. Communications happen over a proxy, which provides a similar set of functionalities as the API gateway, such as authentication and rate limiting. New microservices, or Borg Collective members, don’t need to know anything going on behind the scenes because the control plane provides it automatically.

Within the service mesh, you can create fancy mutations, enable advanced policies around communication, have submerges. Everything can happen through the control plane.

And this is where we go into space with different quadrants within our service mesh global control plane. We could have some on AWS, Azure or somewhere else. No matter where we're hosting it, our applications will communicate with each other. The drones from one Kube can communicate to drones through another Kube via proxy.

From the real-world perspective, you can have deployments in different places, and you'll see them all in the same UI.

## **What About Kafka?**

Kafka can be used as a bus to help microservices communicate in a data-aware mode.

My friend and former colleague, [Gwen Shapira](https://twitter.com/gwenshap)Gwen Shapira, compared service mesh to Kafka. She mentioned that communicating between microservices can quickly become a tangled mess. And one of the approaches to untangle this communication is providing a unified bus.

For example, events are happening in this log, and we can restore the system's history based on those events. Each event will have a time and be stored somewhere.

The same concept of a log that you’re using in your application development was taken as a data structure and implemented as a distributed log inside Kafka. Kafka captures all events that happened in the system, providing indirect communication with the consumers of your service.

For example, if service 1 pushes into topic 1, there would be multiple interested consumers. Instead of getting data from service 1, they communicate through the topic. Therefore, they don’t need to know about each other.

## **Let's Talk Patterns**

### ***Event Collaboration Pattern***

Most Kafka developers are likely using the [event collaboration](https://developer.confluent.io/patterns/compositional-patterns/event-collaboration)event collaboration pattern. Essentially, you have a message box that stores events and services that provide data to the different topics.

That's OK, but it's not enough in today's microservices world where you need to have control of the communication between systems. What you need now is an API gateway as an external conduit proxy to allow things to enter your system. Once inside your application ecosystem, you'll need a service mesh to communicate between applications.

You could run Kafka and your data awareness services inside the service mesh. Some filters allow the service mesh proxy to understand Kafka protocol. You don’t go in for your adventure without friends, so bring in friends, like your service mesh and API gateway, to have observable and reliable connectivity.

### ***Event Gateway Pattern***

In the future, we may be interested in data that we produced through this [event gateway](https://developer.confluent.io/patterns/event-source/event-gateway)event gateway pattern. With Kong's new Kafka plugin, we can produce the Kafka topic and systems that we may not have yet. We'll read and process the data from the beginning of time from the event store.

## **Conclusion**

For those looking for the tl;dr version of this blog, here it is: API gateway admits. Service mesh connects. Kafka streams.

**Gateway Admits!**

Kong Gateway brings traffic from outside clients to our applications. It's a fancy door to our application functionality that brings traffic to and from the clients of our application.

**Mesh Connects!**

Kuma provides connectivity between microservices. It connects your application's microservices to allow reliable communication and policy enforcement.

**Kafka Streams!**

Kafka streams your data, allowing asynchronous communication for use cases where you don’t know the consumer or the data they'll need. Publish it in a Kafka topic to handle.

Feel free to reach out to me on Twitter if you have any questions as you get started with these three solutions @gAmUssa.

Are you interested in learning more about Kong's products? Check out our [Kong Summit session demos and recordings](https://konghq.com/kong-summit/2021-videos)Kong Summit session demos and recordings.