I wrote about the key concepts about service mesh and how to evaluate the requirements for a service mesh in my previous post here: Deciphering the hype of Service Mesh . This post is a follow up from there covering the technical aspects. Part 1: Deciphering the hype of Service Mesh Part 2: Understanding The Ingress and The Mesh components of Service Mesh. Part 3: Uderstanding the observability component of Service Mesh (TBD in another post). Almost all popular service mesh technologies/tools (eg: Istio, LinkerD) have both ingress and mesh capabilities. Conceptually, I see them as 2 mutually exclusive domain (integrated nicely by the underlying tool). Understanding the ingress and the mesh components individually, such as what they offer, what I can do with them etc, was the basic building block to my understanding of service mesh technology as a whole. This is arguably the most mis-represented topic in the internet. So, I thought, I will share my point of view. Note: The ob
Software development and release processes continues to improve to deliver value to the users faster and better to support business growth and relevance in this competitive market. To achieve this we focus on automating the path to production and any people or process related obstacles of a software on its way to the user. Generally, some of the goals of the golden paths, are: Remove interdependency and promote self service and provider & consumer relationship. Shift left - from people & process to technology & automation . Treat Platform-as-product and provide PaaS Secured and standardised by design In this post, I will describe how Crossplane and ServiceBinding can help achieve these goals in the context of applications development and delivery and their consumption of external resources / services in the process. Note: Crossplane and ServiceBinding both are capable of covering beyond just database connectivity. In this blog post I am describing Database connecti