Tips, Expertise, Articles and Advice from the Pro's for Your Website or Blog to Succeed
This is an article from DZone's 2023 Software Integration Trend Report.
For more:
Read the Report
As organizations look to enable integration, innovation, and digital experiences through their IT teams, they often build APIs and expose them by leveraging a full-lifecycle API management system. Historically, these API management systems provided tooling such as:
This is an article from DZone's 2022 Microservices and Containerization Trend Report.
For more:
Read the Report
Does your organization use a microservices-style architecture to implement its business functionality? What approaches to microservices communication and orchestration do you use? Microservices have been a fairly dominant application architecture for the last few years and are usually coupled with the adoption of a cloud platform (e.g., containers, Kubernetes, FaaS, ephemeral cloud services). Communication patterns between these types of services vary quite a bit.
I've been pretty invested in helping organizations with their cloud-native journeys for the last five years. Modernizing and improving a team (and eventually an organization's) velocity to deliver software-based technology is heavily influenced by its people, process and eventual technology decisions.
A microservices approach may be appropriate when the culmination of an application's architecture has become a bottleneck (as a result of the various people/process/tech factors) for making changes and "going faster", but it is not the only approach.
You may also like: What's a Service Mesh? And Why Do I Need One?
Recently I wrote a piece for DZone and their Migrating to Microservices Report on the challenges of adopting service mesh in an enterprise organization. One of the first things we tackle in that piece is “whether or not you should go down the path of adopting a service mesh” Here’s what I said:
Start with an answer of “no”. If you’re just getting started with microservices and a handful of services, make sure you have the foundational pieces in place first. Microservices and its associated infrastructure are an optimization enabling you to make changes to your application faster. You can make a lot of strides toward going faster without a service mesh. You may even want some of the goodness that a service mesh brings without all of the complexity. Check out something like Gloo, an API Gateway built on Envoy proxy.
Solo.io Squash is a distributed debugger that supports multiple languages. When running in a container environment like Kubernetes, debugging applications can be difficult, especially when distributed into multiple containers with implementations in potentially different languages.
Squash can be used to set up language-native debuggers, provide all the plumbing through Kubernetes, and expose that to your native IDEs like Visual Studio Code, Eclipse or IntelliJ/GoLand.
Service mesh is an important set of capabilities that solve some difficult service-to-service communication challenges when operating a services-style architecture. Just as Kubernetes and containers helped to provide a nice set of abstractions to deploying and running workloads on a fleet of computers, so too is service mesh emerging to abstract the network in a way that gives operators and developers control over request routing, observability, and policy enforcement. This provides a lot of potential.
The only problem is, although Kubernetes has emerged as a powerful API for abstracting underlying infrastructure for scheduling workloads, there is no one, single pragmatic API that surfaces the capabilities needed in a service mesh.
This is part 4 of a series that explores building a control plane for Envoy Proxy. Follow along @christianposta and @soloio_inc for the next part coming out in a week.
In this blog series, we'll take a look at the following areas:
As the spectrum of operating environments varies wildly, so too could the components needed to implement a control plane for Envoy. For example, at one extreme, if you have Envoy files statically generated at build time and shipped to your Envoy, you will need components like:
On the other hand, if you opt to use the gRPC streaming xDS implementation, you'll need: