Getting Started With Istio

Getting Started With Istio

Understanding what a service mesh is and how it can be used effectively in a microservices architecture.

The last few years have brought about immense changes in the software architecture landscape. A major shift that we have all witnessed is the breakdown of large monolithic and coarse-grained applications into fine-grained deployment units called microservices, communicating predominantly by way of synchronous REST and gRPC interfaces, as well as asynchronous events and message passing. The benefits of this architecture are numerous, but the drawbacks are equally evident. Aspects of software development that used to be straightforward in the ‘old world’, such as debugging, profiling and performance management, are now an order of magnitude more complex. Also, a microservices architecture brings its own unique challenges. Services are more fluid and elastic, and tracking of their instances, their versions and dependencies is a Herculean challenge that balloons in complexity as the service landscape evolves. To top this off, services will fail in isolation, further exacerbated by unreliable networks. Given a large enough system, parts of it may be suffering a minor outage at any given point in time, potentially impacting a subset of users, quite often without the operator’s awareness. With so many ‘moving parts’, how does one stay on top of these challenges and ensure the system is running smoothly without impacting the customer and driving the developers out of their wits?

With the increased adoption of microservices, the industry has been steadily coming up with patterns and best-practices that have made the entire experience more palatable. Resiliency PatternsService DiscoveryContainer OrchestrationCanary ReleasesObservability PatternsBFFAPI Gateway… These are some of the concepts that practitioners will employ to build more robust and sustainable distributed systems. But these concepts are just that — abstract notions and patterns — they require someone to implement them somewhere in the system. More often than not, that ‘someone’ is you and ‘somewhere’ is everywhere.

Read the rest of the article on Medium.

要查看或添加评论,请登录

Emil Koutanov的更多文章

  • Contrasting Kafka with Akka

    Contrasting Kafka with Akka

    My software architecture consulting gigs take me places ranging from startups to more established organisations, having…

  • The Design of an Event Store

    The Design of an Event Store

    The topics “event-driven architecture” “event stream processing” and “event sourcing” have enjoyed quite a buzz as of…

    1 条评论
  • Combining strict order with massive parallelism using Kafka

    Combining strict order with massive parallelism using Kafka

    Having been involved in several large-scale Kafka projects for different clients across a broad range of industries, I…

  • Logging on the Cheap

    Logging on the Cheap

    To log or not to log? Writing new code is a relatively small part of application development. A much larger part of a…

    1 条评论
  • Contrasting NATS with Apache Kafka

    Contrasting NATS with Apache Kafka

    TL;DR Kafka is an Event Streaming Platform, while NATS is a closer to a conventional Message Queue. Kafka is optimised…

  • Apache Kafka in a Nutshell

    Apache Kafka in a Nutshell

    So, you’ve heard of this Kafka thing that’s popping up all over the shop. From green-sprout startups to greedy…

    1 条评论
  • Why Kafka Is So Fast

    Why Kafka Is So Fast

    Discover the deliberate design decisions that have made Kafka the performance powerhouse it is today. The last few…

    2 条评论
  • Kafka Gotchas

    Kafka Gotchas

    I've assisted several large clients in building a microservices-style architecture using Kafka as a messaging backbone,…

  • Introduction to Event Streaming with Kafka and Kafdrop

    Introduction to Event Streaming with Kafka and Kafdrop

    Event sourcing, eventual consistency, microservices, CQRS..

社区洞察

其他会员也浏览了