devopsy.kinsta.cloud

Author: Zach Jory

Enabling the Financial Services Shift to Microservices

The financial services industry historically has been riddled with barriers to entry. Challengers found it difficult to break through low margins and tightening regulations. However, large enterprises that once dominated the market are now facing disruption from smaller, leaner fintech companies that are eating away at the value chain. These disruptors are marked by technological agility, specialization and customer-centric UX.

To remain competitive, financial services firms are reconsidering their cumbersome technical architectures and transforming them into something more adaptable. A recent survey of financial institutions found that about 85 percent consider their core technology to be too rigid and slow. Consequently, about 80 percent are expected to replace their core banking systems within the next five years.

Emerging regulations meant to address the new digital payment economy, such as PSD2 regulations in Europe, will require banks to adopt a new way to operate and deliver. Changes such as PSD2 are aimed at bringing banking into the open API economy, driving interoperability and integration through open standards. To become a first-class player in this new world of APIs, integration and open data, financial services firms will need the advantages provided by microservices.

Microservices’ 3 Key Advantages for Financial Services

Enhanced Security

Modern fintech requirements create challenges to the established security infrastructure. Features such as digital wallet, robo-advising and blockchain mandate the need for a new security mechanisms. Microservices follow a best practice of creating a separate identity service to address these new requirements.

Faster Delivery

Rapidly bringing new features to market is a cornerstone of successful fintech companies. Microservices make it easier for different application teams to deliver new functionality independently to meet emerging customer demands. Microservices also scale well to accommodate greater numbers of users and transactions.

Seamless Integration

The integration layer in a modern fintech solution needs a powerful set of APIs to communicate with other services, both internally and externally. This API layer is notoriously challenging to manage in a large monolithic application. Microservices make the API layer much easier to manage and secure through isolation, scalability and resilience.

Service Mesh: Simplyfing Management of Complex Microservice Architectures

In the face of rapidly changing customer, business and regulatory requirements, microservices help financial services companies quickly respond to these changes. But this doesn’t come for free; companies take on increased operational overhead during the shift to microservices. Technologies such as a service mesh can help manage that.

Service mesh provides a bundle of features around observability, security and control that are crucial to managing microservices at scale. Previously, existing solutions such as DNS and configuration management provided some capabilities such as service discovery, but didn’t provide fast retries, load balancing, tracing and health monitoring. The old approach to managing microservices requires that cobbling together several different solutions each time a problem arises, but a service mesh bundles it all together in a reusable package. While it’s possible to accomplish some of what a service mesh manages with individual tools and processes, it’s manual and time-consuming.

Competition from innovative fintech startups, along with ever-increasing customer expectations means established financial services players must change the way they deliver offerings and do business with their customers. Delivering on these new requirements is difficult with legacy systems. Financial services firms need a software architecture that’s fit for purpose—agile, adaptable, highly scalable, reliable and robust. Microservices make this possible, and a service mesh makes microservices manageable at scale.

— Zach Jory

August 14, 2018
How Service Mesh Addresses 3 Key Microservices Challenges
I was recently reading the “Global Microservices Trends” report by Dimensional Research and found myself thinking, “A service mesh could help with that.” Let’s look at three key challenges listed in the report.

A couple key points in the report make it clear microservices are seeing widespread adoption. It’s also clear that along with the myriad benefits they bring, there are also tough challenges that come as part of the package. From the report:
- 91 percent of enterprises are using microservices or have plans to.
- 99 percent of users report challenges with using microservices.
Major Microservices Challenges

The report identifies a range of challenges companies are facing.

Companies are seeing a mix of technology and organizational challenges. We’ll focus on the technological challenges a service mesh solves, but it’s worth noting that one thing a service mesh does is bring uniformity so it’s possible to for all teams to have the same view, reducing the need for certain skills.

Each Additional Microservice Increases the Operational Challenges

Not with a service mesh! A service mesh provides monitoring, scalability and high availability through APIs instead of using discrete appliances. This flexible framework removes the operational complexity associated with modern applications. Infrastructure services were traditionally implemented as discrete appliances, which meant going to the actual appliance to get the service. Each appliance is unique, which makes monitoring, scaling and providing high availability difficult. A service mesh delivers these services inside the compute cluster itself through APIs and doesn’t require any additional appliances. Implementing a service mesh means adding new microservices without adding complexity.

It is More Difficult to Identify the Root Cause of Performance Issues

The service mesh toolbox gives you a couple of things that help solve this problem:

Distributed Tracing: Tracing provides service dependency analysis for different microservices and tracking for requests as they are traced through multiple microservices. It’s also a powerful way to identify performance bottlenecks and zoom into a particular request to identify which microservice contributed to the latency of a request or which service created an error.

Metrics Collection: With service mesh you also get the ability to collect consistent metrics across your mesh. Metrics are key to understanding what has happened in your applications, and when they were healthy compared to when they were not. A service mesh can gather telemetry data from across the mesh and produce consistent metrics for every hop. This makes it easier to quickly solve problems and build more resilient applications.

Differing Development Languages and Frameworks

Another major challenge that report respondents noted facing was the challenge of maintaining a distributed architecture in a polyglot world. When making the move from monolith to microservices, many companies struggle with the reality that, to make things work, they have to use different languages and tools. Large enterprises can be especially affected by this, as they have many large, distributed teams. Service mesh provides uniformity by providing programming language agnosticism, which addresses inconsistencies in a polyglot world where different teams, each with its own microservice, are likely to be using different programming languages and frameworks. A mesh also provides a uniform, applicationwide point for introducing visibility and control into the application runtime, moving service communication out of the realm of implied infrastructure, to where it can be easily seen, monitored, managed and controlled.

Microservices are cool, but service mesh makes them ice cold. If you’re on the microservices journey and are finding it difficult to manage the infrastructure challenges, a service mesh may be the right answer. Let me know if you have any questions on how to get the most out of service mesh, I’m happy to talk and you can find me @zjory.

— Zach Jory
July 30, 2018
Knowing What Your Microservices Are Doing
Microservicin’ ain’t easy, but it’s necessary. Breaking your monolith down into microservices is a must in a cloud-native world, but it doesn’t automatically make everything easier. Some things actually become more difficult. An obvious area where it adds complexity is communications between services; visibility into service to service communications can be hard to achieve, but is critical to building an optimized and resilient architecture.

The idea of monitoring has been around for a while, but observability has become increasingly important in a cloud-native landscape. Monitoring aims to give an idea of the overall health of a system, while observability aims to provide insights into the behavior of systems. Observability is about data exposure and easy access to information which is critical when you need a way to see when communications fail, do not occur as expected or occur when they shouldn’t. The way services interact with each other at runtime needs to be monitored, managed and controlled. This begins with observability and the ability to understand the behavior of your microservices architecture.

A primary microservices challenge is trying to understand how individual pieces of the overall system are interacting. A single transaction can flow through many independently deployed microservices, or pods, and discovering where performance bottlenecks have occurred provides valuable information.

It depends who you ask, but many considering or implementing a service mesh say that the No. 1 feature they are looking for is observability. There are many other features a mesh provides, but those are for another blog. Here, I’m going to cover the top observability features provided by a service mesh.

Tracing

An overwhelmingly important thing to know about your microservices architecture is specifically which microservices are involved in a user transaction. If many teams are deploying their dozens of microservices, all independently of one another, it’s difficult to understand the dependencies across your services. Service mesh provides uniformity, which means tracing is programming language-agnostic, addressing inconsistencies in a polyglot world where different teams, each with its own microservice, can be using different programming languages and frameworks.

Distributed tracing is great for debugging and understanding your application’s behavior. The key to making sense of all the tracing data is being able to correlate spans from different microservices related to a single client request. To achieve this, all microservices in your application should propagate tracing headers. If you’re using a service mesh such as Aspen Mesh, which is built on Istio, the ingress and sidecar proxies automatically add the appropriate tracing headers and report the spans to a tracing collector backend. Istio provides distributed tracing out of the box, making it easy to integrate tracing into your system. Propagating tracing headers in an application can provide nice hierarchical traces that graph the relationship between your microservices. This makes it easy to understand what is happening when your services interact and if there are any problems.

Metrics

A service mesh can gather telemetry data from across the mesh and produce consistent metrics for every hop. Deploying your service traffic through the mesh means you automatically collect metrics that are fine-grained and provide high-level application information since they are reported for every service proxy. Telemetry is automatically collected from any service pod providing network and L7 protocol metrics. Service mesh metrics provide a consistent view by generating uniform metrics throughout. You don’t have to worry about reconciling different types of metrics emitted by various runtime agents or add arbitrary agents to gather metrics for legacy apps. It’s also no longer necessary to rely on the development process to properly instrument the application to generate metrics. The service mesh sees all the traffic, even into and out of legacy “black box” services, and generates metrics for all of it.

Valuable metrics that a service mesh gathers and standardizes include:
- Success rates.
- Request volume.
- Request duration.
- Request size.
- Request and error counts.
- Latency.
- HTTP Error codes.
These metrics make it easier to understand what is going on across your architecture and how to optimize performance.

Most failures in the microservices space occur during the interactions between services, so a view into those transactions helps teams better manage architectures to avoid failures. Observability provided by a service mesh makes it much easier to see what is happening when your services interact with each other, making it easier to build a more efficient, resilient and secure microservice architecture.

— Zach Jory
June 14, 2018
The Road Ahead for Service Mesh

If you’re struggling to manage microservices as architectures continue to scale, there’s a good chance you’ve at least heard of service mesh. For the purposes of this blog, I’ll assume you’re familiar with the basic tenets of a service mesh.

I believe that service mesh is advancing microservice communication to a new level that is unachievable with the one-off solutions that were previously being used. DNS patterns, configuration management and other technologies provide some capabilities such as service discovery, but they don’t provide fast retries, load balancing, tracing and health monitoring. The old approach also requires that you cobble together several things each time rather than bundle everything into a reusable tool.

While it’s possible to accomplish much of what a service mesh manages with individual tools and processes, the process is a pain in the ass. The image below provides a good idea of how a mesh simplifies the management of microservices.

Right Around the Corner

So what’s in the immediate future? I think we’ll see the technology quickly mature and add more capabilities as standard features in response to enterprises realizing the efficiency gains created by a mesh and look to implement them as the standard for managing microservice architectures. Service mesh is likely immature for production deployments, but the road map is progressing quickly and it seems we’ll be to v1 in short order. Security is a feature provided by service mesh, but for most enterprises it’s a major consideration and I see policy enforcement and monitoring options becoming more robust for enterprise production deployments.

A feature I see on the near horizon—and one that will provide tremendous value—is an analytics dashboard to show insights from the huge amount of telemetry data in a service mesh. I think an emerging value proposition we’ll see is that the mesh allows you to gain and act on data that will allow you to more efficiently manage your entire architecture.

Further Down the Road

There is a lot of discussion on what’s on the immediate horizon for service mesh, but what is more interesting is considering what the long term will bring. My guess is that we ultimately come to a mesh being an embedded value-add in a platform. Microservices are clearly the way of the future, so organizations are going to demand an effortless way to manage them. They’ll want something automated, running in the background that never has to be thought about. This is probably years down the road, but I do believe service mesh will eventually be a ubiquitous technology that is a fully managed plug and play config. It will be interesting to see new ways of using the technology to manage infrastructure, services and applications.

We’re excited to be part of the journey, and are inspired by how users are leveraging service mesh to solve direct problems created by the explosion of microservices and also find new efficiencies with it. I look forward to seeing what the community comes up with that I have not yet even imagined.

— Zach Jory

April 11, 2018
Service Mesh: The Best Way to Scale Enterprise Apps

Microservices are great for DevOps, but the service-to-service communication these architectures depend on are complex to run and manage at production scale. Enter service mesh: the best way for enterprises to scale, secure and monitor apps. A service mesh is a dedicated infrastructure layer enabling service-to-service communication to be quick, secure and reliable. If you’re building cloud-native applications, you need a service mesh.

After talking to development and operations teams it became clear that microservices are great for development velocity, but the complexity and risk in these architectures lies in the service-to-service communication that microservices depend on. Service mesh is an application-first approach to provide a communication fabric for microservices, giving DevOps teams the flexibility and autonomy they desire while providing the policy, visibility and insights into their microservice environment that operations teams demand for production-grade applications.

A service mesh provides a robust microservice communication fabric to enable the best possible path to scaling containerized apps whether in the data center or in the cloud (or both). There has also been a recent emergence of enterprise-grade meshes to address the needs and complexity of enterprise production environments. A service mesh needs to do more than just scale apps; it also needs to monitor and secure them. A supported infrastructure allows DevOps teams the flexibility and autonomy they desire while providing the policy, visibility and insights into microservices that operations teams demand for production-grade applications.

Advantages of a Service Mesh

Think about your plans for microservices. Maybe you plan to have 10, 50, 100 or 1000’s of services running in your Kubernetes cluster. How do you get all of those services in your new microservice and container environments in an efficient, uniform way?

Do you know who is talking to whom and if they are allowed to? Is that communication secure? How do you debug something when it goes down? How do you add tracing or logging without touching all of your applications? Do you know what the performance or quality impacts of releasing a new version of one of those services is on the upstream and downstream services?

A service mesh helps answer those questions. As a transparent infrastructure layer that is inserted between your microservice and the network, it gives you a single point in the communication path of your applications to insert services and gather telemetry. You can do this without requiring changes to your applications.

2018: The Year of the Service Mesh

The concept of service mesh is relatively new. In fact, until 2018 was declared “The Year of the Service Mesh” at KubeCon in December 2017, most people had never heard of a service mesh. There are now several open source offerings such as Istio, and several companies building out supported meshes to take the burden out of managing microservices. It will be interesting to see how a service mesh enables organizations to further capitalize on containers and microservices.

— Zach Jory

March 8, 2018