Before we delve deep into the world of microservices design patterns, I want to talk about the jargon that I will use when discussing microservices. When I discuss microservices, I use these terms often, and as such, I just want to define them so that you understand where I'm coming from.

These are just some of the terminologies I learned:

Service Types

The first set of terms that I want to define is service types. These will be critical to understanding how various patterns are implemented.

Data Service

A data service is something that connects to a data source within the system and this does not mean databases alone. On the contrary, any valid source can be served through a microservice. Data services are usually bound by domains defined within the global architecture of the system.

Examples of these services are plenty, but a simple one to understand is a product service that deals with a product domain. Usually, these domains have details about products but not inventory or orders, so they are built as individual data services.

Business Service

A business service is a higher level of abstraction that builds on data services. Often, we need to define business domains that transcend individual data services in order to be aligned with the business perspective. Business services can be built around a single data domain if there is more complex business processing that needs to be done in order to operate correctly within the system.

One of the best examples of this is an order domain. To place an order, you need to have product and customer data. You also need the inventory data to ensure that the product is available, and then, as the order is placed, you need to charge the customer information while decreasing your inventory counts. As you can see, these are usually much more complex systems than a simple data domain.

Translation Service

A translation service is an abstraction of a third-party operation that you want to encapsulate under your own facade. Think of this as something like an email sending service. You may actually consume this service from various parts within your system as a whole, but you want to integrate that with sending logs and specific credentials that you don't want to be littered throughout your overall system. As such, you encapsulate the service with your own translation service.

The beauty of these services, and why I really like them, is that when you change vendors, or versions, of the third-party system, you can maintain your service API and consume the new underlying service without any other code having to change.

Edge Service

Edge service is responsible for serving data to users and external services. These services can be used to provide a web view, a service that delivers that content, and other services that deliver to mobile devices. Often, we use edge services to slim down our payloads to make them more mobile-friendly, or provide modified payloads that meet the need of a third-party contract. While edge services aren't always used, they can be a powerful layer in a complete microservices architecture.

Platform

When describing a platform, there are many different things that people can think of. From the perspective of this blog, I will consider the platform as the all-encompassing arena for all service operations across multiple data centers, but thinking of it as a whole.

Runtime for services

First and foremost, and definitely what people consider in the platform is the runtime itself. This can include bare metal servers, virtualisation through VMs, either public or private, or containerized runtimes like Kubernetes or Cloud Foundry. I have spent time working with each and every one of these runtimes and I will be the first to admit that none of them is perfect. Running on bare metal servers definitely is the most performant, but there's a lot of pain associated with that.

Kubernetes, on the other hand, is one of the most flexible, but, again, it has its own pain points and I cannot recommend it one way or another, but I will tell you this if you are running on multiple data centers, especially public and private mixed, containerization starts to become a more and more attractive prospect.

Ancillary Services

There are also a host of ancillary services that you don't write, but that you run within the runtime that is included in that platform definition. These can be things like message queues, cash services, authentication and authorization services, amongst various others. Some of these may be first-class services for your organization. In my example, authentication and authorization is a first-class services that we build upon. The key here is that the platform should include everything that your applications need to get work done.

Operational Components

Also included are operational components. These are things like log aggregators and shippers, metrics aggregators and shippers, and various other operations that you need to have running in your platform in order to maintain operational integrity. If I have learned anything, especially in the move to more mission-critical systems, it's that operational components should never be overlooked in a platform.

Diagnostic Components

And, finally, I want to talk about diagnostic components!

These are anything from simple shell scripts that you execute on your local machine to containers running in your runtime that enable you to connect and perform operations from within the runtime itself to diagnose, troubleshoot, and improve system performance.

For instance, we need to run a container in our runtime that our team needs to connect internally to the Kubernetes runtime itself in a secure fashion. This allows testing both low-level components like DNS as well as testing the network and associated services within the runtime.

Conclusion

This article was to get you started on microservices and some of the important jargon that are used. These are important to understand as they will be used quite extensively in the upcoming articles. So now that we understand the jargon and perspective of the terms service types and platforms, I'll be adding details on Cloud Native in my next article.

Thank You :)