Tips, Expertise, Articles and Advice from the Pro's for Your Website or Blog to Succeed
From a career perspective, the two things I appreciate the most are solving problems through technology and creating technical publications. The former often drives the latter: results presented in inspired-based publications are derived from a recent problem that I had successfully solved.
Along my three-decade journey, I also discovered that I enjoy making lists. Early in my career, I used quad-ruled notebooks to establish lists to work from daily.
Many developers and DevOps engineers have been deploying Kong Gateway in front of their microservices-based applications. While the extensive library of built-in plugins can add a lot of flexibility and power to your deployments, you might encounter the occasional use case where you need a custom plugin that’s just not found in the library.
Fortunately, you can use Go to create and run plugins for Kong Gateway. This post will cover how to get set up for writing Kong plugins. We’ll look at the parts of the request/response lifecycle that you can tap into, and we’ll walk through an example of how to put it all together.
This post recaps my talk with Scott Lowe, principal field engineer at Kong, about what a service mesh does and when to use it, among other common mesh-related questions. Check out the transcript and video from our conversation below!
Question: Could you just give us a quick introduction of what exactly service mesh is and how it relates to common connectivity challenges?
Insomnia is a desktop app from Kong that’s great for building, debugging, and testing backend APIs. While ad hoc manual testing is nice, wouldn’t it be even better to include our API tests in our continuous integration (CI) pipelines? With Inso, Kong Insomnia’s CLI tool, we can!
Inso allows you to run your automated API tests directly from the command line, which means setting up a workflow with GitHub Actions is a snap.
If you’ve done any reading about service meshes, you’ve probably come across mentions of an open-source project named Envoy. And if you’ve done any reading about Envoy, you’ve probably seen references to service meshes. How are these two technologies related? How are they different? Do they work together? I’ll attempt to answer all those questions in this blog post’s first and second parts, plus possibly a few more.
As companies are increasingly re-architecting their applications and embracing a microservices-based approach, the need for solutions to traffic management, observability, security, and reliability features increases. A service mesh is one approach to adding these features to the underlying platform instead of individual applications or services.
For the DevOps-averse developer, lambdas are heaven. They can focus on writing self-contained and modularized pieces of code, deploying these functions for on-demand execution without being concerned about resource management or infrastructure. Lambda execution, however, can be tricky.
Serverless security with the AWS API Gateway can feel daunting, especially when all you want to do is call a simple function as an API endpoint. For this, there's the ease of Kong Gateway.
We’re seeing a massive shift in how companies build their software. More and more, companies are building—or are rapidly transitioning—their applications to a microservice architecture. The monolithic application is giving way to the rise of microservices.
With an application segmented into dozens (or hundreds!) of microservices, monitoring and consolidated logging become imperative. At any given moment, one of your microservices could fail or throw an error or begin hogging resources. You need to monitor for this so that you can respond quickly and appropriately. In addition, your ability to troubleshoot errors and understand system behavior depends heavily on the existence and effectiveness of your logging tool.
There are events in our life that seem to be just routine, but then unexpectedly they have a profound impact on our journey. For me, one event was attending the 2008 Gartner conference in Orlando, Florida.
That event not only introduced me to the Salesforce ecosystem for the very first time but also to concepts like:
API gateway request transformation policies are incredibly powerful. There are many situations when an API developer can take advantage of request transformations to adjust the shape and values of a request to cleanly fit their API.
Let’s say you’re deprecating a certain endpoint for your API, but you still need to support the old specification for a transition period. Request transformations let you accept requests according to the old specification, transform them to fit the new specification and then forward them.
A common architectural design pattern these days is to break up an application monolith into smaller microservices. Each microservice is then responsible for a specific aspect or feature of your app. For example, one microservice might be responsible for serving external API requests, while another might handle data fetching for your frontend.
Designing a robust and fail-safe infrastructure in this way can be challenging; monitoring the operations of all these microservices together can be even harder. It's best not to simply rely on your application logs for an understanding of your systems' successes and errors. Setting up proper monitoring will provide you with a more complete picture, but it can be difficult to know where to start. In this post, we'll cover service areas your metrics should focus on to ensure you're not missing key insights.
Kubernetes has become the name of the game when it comes to container orchestration. It allows teams to deploy and scale applications to meet changes in demand while providing a great developer experience.
The key to handling modern dynamic, scalable workloads in Kubernetes is a networking stack that can deliver API management, a service mesh and an ingress controller. Kong Ingress Controller allows users to manage the routing rules that control external user access to the service in a Kubernetes cluster from the same platform.
For the last 10 years, I have been building RESTful services as the feature team member on projects assigned to me via consulting opportunities or as a full-time corporate employee. This represents one-third of my career and is what I have enjoyed the most.
However, in all of those years, when the system is part of an application modernization initiative, I feel like I'm learning the same lessons over and over:
