Here's a story about a developer surviving in a world of APIs, Kubernetes and rapid application modernization.

Meet Josh (a pseudonym). Josh is your typical developer. He's good at writing code in his native language, hates documentation and REALLY hates the "drag and drop" approach to developing software found in bloated API management platforms. Josh would rather write code, weave in some docs and avoid worrying about security, networking, deployment and reliability. Josh avoids venturing into newer networking technologies like Istio, labeling them unnecessarily complicated to configure and maintain. He would rather write everything in Java, Groovy or his go-to integration library: Apache Camel.

Recently Josh stumbled across an open source API platform called Kong. After 30 minutes of playing around, Josh discovered how easy it was to:

• Support both legacy and modern clients accessing different versions of the same application.
• Migrate existing apps to Kubernetes, using declarative automation to deliver immutability of the application and infrastructure.

He was so impressed with the developer-centric approach of Kong that he decided to showcase Konnect, Kong's enterprise SaaS platform, to his immediate team. The team agreed that Konnect was exactly what they needed to modernize their legacy applications and provide a consistent, shared policy layer to all enterprise APIs. And so their journey began.

Modernizing a Legacy Application

Thanks to his stellar demonstration, Josh was tasked with modernizing a legacy application that was slow and cumbersome. The application, a Pig Latin translator, is detailed in this blog post written by David La Motta. David does a great job at improving high availability and disaster recovery (HADR) using Zero Load Balancing (ZeroLB)—a design pattern implemented with Kong Mesh. Although this solved the network redundancy and HADR concerns with ZeroLB, the performance was slow. The legacy application was written in Ansible and Python scripts using asynchronous calls and takes many seconds to return a response.

How can Josh modernize this application in the most efficient way possible, improving the performance and giving it a new lease on life in a multi-cloud, platform-agnostic environment like Kubernetes? Read on or watch the below video to find out.

Design and Develop

Apache Camel has been around for 14 years. It's one of Apache's most mature projects, with over 4,000 stars on GitHub and almost 100 committers from many different vendors (Red Hat, Talend, SAP) and individuals. It is based on the concept of Enterprise Integration Patterns (EIPs) and fits nicely into the service layer tier—responsible for routing, transformation and any other integration heavy lifting.

What Camel lacks is an API gateway layer—a gap often filled by an API management or service mesh platform. Camel has a very nice RESTful Domain Specific Language (DSL) called "Rest DSL." In a couple of lines of code (either Java or XML), you can write a RESTFul service in minutes. Our developer friend Josh is a big fan of REST DSL and was able to quickly knock out the following RESTful endpoint for the Pig Latin application:

<?xml version="1.0" encoding="UTF-8"?>

<beans xmlns="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="
        http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd
        http://camel.apache.org/schema/spring http://camel.apache.org/schema/spring/camel-spring.xsd">

 <camelContext id="CamelPigLatin" xmlns="http://camel.apache.org/schema/spring">

   <restConfiguration apiContextPath="/api-doc" bindingMode="off" component="servlet" contextPath="/camel" enableCORS="true" scheme="http">
     <dataFormatProperty key="prettyPrint" value="true" />
     <apiProperty key="host" value="" />
     <apiProperty key="api.version" value="2.0.0" />
     <apiProperty key="api.title" value="Pig Latin Translator" />
     <apiProperty key="api.description" value="Camel Rest Example with Swagger that provides a Pig Latin translator service" />
     <apiProperty key="api.contact.name" value="Simon Green" />
   </restConfiguration>

   <!-- defines the rest service wrapper for a translator service -->
   <rest consumes="application/json" path="/translate" produces="application/json">
     <description>Rest service, returns the translated pig latin phrase</description>
     <put uri="">
       <description>Translate the phrase</description>
       <param name="body" type="body" description="The english phrase to translate" required="true" />
       <responseMessage code="200" message="Successful Translation" />
       <responseMessage code="500" message="Translation Failed" />
       <to uri="direct:translate" />
     </put>
   </rest>
   <route id="translate">
     <from uri="direct:translate" />
     <convertBodyTo type="java.lang.String" charset="ISO-8859-1" />
     <transform>
       <simple>${body.replaceAll('\\\"', '\"')}</simple>
     </transform>
     <transform>
       <simple>${body.replaceAll('\"\{"','\{\"')}</simple>
     </transform>
     <transform>
       <simple>${body.replaceAll('\"\}\"\}','\"\}\}')}</simple>
     </transform>

     <transform>
       <jsonpath resultType="java.lang.String">$..extra_vars.message</jsonpath>
     </transform>
     <transform>
       <method ref="sampleBean" method="translate" />
     </transform>
   </route>
 </camelContext>
</beans>

The beauty of REST DSL is that it's self-documenting. This makes it easy to include OpenAPI (Swagger) as part of his build. The runtime of choice for Camel is Spring Boot. Other choices are Quarkus or Knative, but unfortunately, they're both in their infancy with limited enterprise support. On the other hand, Spring Boot is portable and easy to get up and running in any environment.

Now that Josh has tested his new Pig Latin endpoint locally, he's inadvertently exposed Swagger documentation. Using his API design tool of choice, Insomnia, Josh's team can import the Swagger and start testing the API.

Although Josh practices the developer-centric "code-first approach" to implementing his application, he's actually created an API contract—the starting point for our API lifecycle journey:

As a result, the team completed the Design and Develop phases of our API lifecycle.

Deployment

Next up, we need to deploy our application somewhere. Currently, the existing application is written in Python and calls a RESTful API exposed in Ansible Tower, running on a bunch of VM's on Azure. Although we have network redundancy using Kong Mesh, the performance is slow due to the asynchronous architecture of the Ansible API. Unfortunately, the python client needs to make multiple requests to a) run the Pig Latin playbook and b) retrieve the result. Luckily, Josh has written the RESTful API in Camel using Spring Boot, and the design is inherently synchronous, requiring only a single call from the client.

Since the runtime is Spring Boot, we can easily deploy this to Kubernetes. An extra feature we could use is Terraform to stand up our Kubernetes cluster wherever we want. Josh decided that EKS on AWS was a good place to start this exercise. Terraform allowed Josh to declaratively specify exactly what our deployment should look like, regardless of the cloud provider. Additionally, we now have an immutable deployment that can spool up/tear down with a terraform apply or a terraform destroy.

Phase in New Version

Now that we deployed our modernized application on Kubernetes, it's time to phase in our new version. Typically we'd use the canary deployment technique, but in Josh's case, shifting from an asynchronous to synchronous architecture requires a client code change. Instead, Josh uses API versioning in Kong Konnect to include a new version of the application while guaranteeing backward compatibility for older client versions. Konnect is Josh's favorite API management platform, as it's developer-centric and leaves out the "drag and drop" nonsense that his manager craves. Perfect for any ninja developer!

Now that Josh has configured Konnect to route two different versions of David's Pig Latin application, he's able to test it out. Below you can see the Vitals for multiple versions running through Konnect:

As a result of Josh's application modernization project, the team experienced the following key improvements:

• 100 fold performance increase (from a latency of 3 seconds per request down to 30 milliseconds)
• Ability to seamlessly modernize legacy applications while supporting legacy clients

Josh's manager was so impressed that he decided to decommission the existing legacy architecture and migrate to a more microservices-based architecture using Kong Konnect and Apache Camel.

Further Reading

Hopefully, you found Josh's experience with Kong Konnect useful. Part Two of this series will focus on:

• Using Kong Mesh to decouple applications from VMs, enabling a seamless migration to any cloud provider.
• Improving HADR concerns of our newly modernized Pig Latin application.

For more information on this example, or to try it out yourself, visit my GitHub repo.

Lastly, to learn more about Kong Konnect, try one of our hands-on exercises at Kong Academy. Kong Konnect is a single platform that delivers end-to-end connectivity and visibility for services in multi-cloud environments, making application modernization seamless.