In this series of articles, we will dig into the OpenShift Service Mesh world. In this post we will go through some introductory questions like “Why someone would need a Service Mesh?“, “Do I really need it?”, “How is the OpenShift Service Mesh architecture?”.
In this series of articles, we will dig into the OpenShift Service Mesh world. In this first post we will go through some introductory questions like “Why someone would need a Service Mesh?“, “Do I really need it?”, “How is the OpenShift Service Mesh architecture?”.
In next articles, we will go through the steps to setup the OpenShift Service Mesh platform and start configuring and testing some of its main features.
So, let’s begin from the beginning….
People have changed their priorities as consumers. Nowadays we appreciate innovation more than in the past, maybe because we also changed the pace at which we consume new products/content.
We also have changed the way that we consume, we have been moving from “physical” to “digital” business in multiple industries and that movement blurred some of the existing barriers for newcomer companies which implied having more providers that we, consumers, can choose, making a much harder competition for companies.
Companies reacted to those challenges. A highly innovative and competitive market makes it necessary that businesses can adapt quickly to customer and market changes. That means that they have to be aware of the customer needs, and react to their behavioral changes and requirements. Companies do that by listening more about what people are actually looking for and what they like/dislike about products/services from their company and from their competitors.
In addition to that, you can also probably have noticed that over the last years many businesses have moved from a product-centric approach to a customer-centric model while trying to deliver value. The difference is that in a product-centric approach, the focus is to try to sell a product to as many people as you can, while in a customer-centric approach the focus is trying to sell as many services as you can to a customer (or customer “type”). That also forces companies not only to adapt quickly to changes but also to create completely new services/products at a fast pace, that means a complete change in how they operate, a change in how they organize, and, at the end of the day, a change in their culture.
This shift in business has a name, some people find it an overused buzzword, but is the most common way to describe it: Digital Transformation.
Enterprise Software applications are one of the supporting pillars of any business nowadays, so all those business implications mentioned above had a big impact on applications, from the development lifecycle (think about the Agile methodology) to the application architectures. Those changes in the application architecture due to Digital Transformation are one of the key factors why Service Mesh solutions have been expanding over the last years.
As you probably are aware, most of the application architectures in the past were based on what is called a Monolithic design pattern, where all components of the application were included in a single entity (single-tiered software), running on a single platform (server). This is a simple approach that has been working for multiple years, but the new business requirements made arise some of its limitations, for example, what happens if a new feature needs to be added to a monolithic approach?
Our original Kubernetes tool list was so popular that we've curated another great list of tools to help you improve your functionality with the platform.
In this article, take a look at the service mesh in the microservices world. The software industry has come a long journey and throughout this journey, Software Architecture has evolved a lot. Starting with 1-tier (Single-node), 2-tier (Client/ Server), 3-tier, and Distributed are some of the Software Architectural patterns we saw in this journey.
Reading Time: 3 minutes Service mesh is a dedicated infrastructure layer for handling service to service communication. Basically, it's a way to control how different micro services deployed on kubernetes will manage secure communication and traffic between them with lot's of cross-cutting concerns like logging, security, etc.
In this blog post, we will learn about Istio and Linkerd architecture, moving parts, and compare their offerings.
For teams to monitor, support, and to maintain these services is becoming a challenge so most enterprises have invested in some kind of microservices management tool.