Clone Yourself Through Automation to Get That Next Job

If you could clone yourself, you could get your work done a lot faster, right? And that would free up time for you to pursue new projects and advance your career.

It's an idea that Kong Vice President of Products Reza Shafii discussed recently as part of Destination: Automation, a free digital event that explored ways organizations can embrace automation to make applications and underlying technology stacks more efficient, secure and resilient.

Perhaps automation can be thought of as a form of cloning, or an alternative to cloning, that can help you get your work done faster, thereby enabling you to take on new challenges or a new job.

What it comes down to, Shafii said, is: How do we perform our craft in a more automation-friendly way?

Digital Evolution

According to Shafii, the key question of how those involved in digital transformation can perform their craft in a more automation-friendly way really comes down to: How do we more easily consume APIs to automate the things we do? And how do we, as we consume APIs, create interfaces and digital touchpoints that are themselves automatable?

As Shafii explained, APIs are the latest stage in digital evolution. Twenty years ago, with the rise of the World Wide Web, the question was "Is there a website for that?" Beginning around 2008, with the rise of smartphones, the question shifted toward "Is there an app for that?" And beginning around 2015, the question shifted toward "Is there an API for that?"

That, he said, was a critical shift in the way digital touchpoints and digital experiences are created. Along with the shift toward APIs came a shift from the monolithic to the distributed and an increased emphasis on automation.

Those involved in digital transformation should focus on creating "delightful" APIs that can create a great experience at the API level, Shafii advised. Through the distributed way of doing things, elements of that API can help create the next great API experience.

API Management Software

The different stages of digital evolution were accompanied by different generations of API management software, Shafii noted. The first-generation API management software was popular from about 1998 to 2008. That era was dominated by companies such as Oracle, and the interfaces involved were essentially what are commonly known as web services and services based on simple object access protocol (SOAP).

The second generation of API management was popular in the period 2008 to 2015 and was followed by the third generation based on microservices, accompanying the shift from monolithic to distributed. The microservices approach allows developers to abstract the responsibilities of different teams and decouple them and create cohesive interfaces between microservices.

As this has occurred, the number of different components that form the backbone of today's applications is increasing almost exponentially. These different components or processes need to talk to each other. Every team developing a microservice needs to be concerned with connectivity, and that means connectivity concerns also are increasing at an exponential rate.

Shafii cited several examples of those connectivity concerns.

Everyone writing a microservice needs to worry about how to secure it and must make sure that the microservice connects to other microservices in a reliable manner. The operation of the microservice shouldn't be affected if there is a failure on another microservice. Additionally, each microservice needs to be able to scale as the load on it increases.

That means that developers are now in the business of not just worrying about building business logic into every microservice but about building service connectivity as well.

Three Flavors of Connectivity

App connectivity comes in three flavors, according to Shafii, including edge connectivity, cross-app connectivity and in-app connectivity.

Edge connectivity involves enabling mobile applications, IoT devices, developers and partners to consume APIs.

Cross-app connectivity enables internal cross-team and cross-application connectivity to consume each other's APIs and services.

In-app connectivity enables individual applications to connect the microservices that support them.

All these types of connectivity need to be protected and secured.

Connectivity logic should be developed within the app, which means within the building blocks of the actual application (i.e., within the microservices), Shafii said. And that, he said, means a shift to a very high order of connectivity needs.

Today's Concern

Shafii offered several examples of the sorts of concerns that businesses had about API management seven to 10 years or so ago. The businesses asked questions such as:

• How do I protect a three-tiered app with a database and middleware and a web app?
• How do I manage connectivity?
• How do I move something running on virtualized infrastructure to a single cloud provider?
• How do I move from SOAP-based interfaces to REST (representational state transfer) interfaces?
• How do I bring in a single API management layer that protects all my APIs?

Today's questions are quite different, Shafii said.

• How do we move our monolith to microservices?
• How do we start with a microservices architecture?
• How do we adopt Kubernetes properly?
• How do we containerize existing applications?
• How do we create microservices that can easily be containerized and run on Kubernetes?
• How can we manage the lifecycle of our APIs consistently across multiple cloud providers?

What Shafii has observed nowadays is not just multi-cloud - it's multi-Kubernetes on multi-cloud. He sees services built on top of multiple Kubernetes providers. The focus also has shifted at the protocol level, from SOAP and REST to protocols such as GraphQL and Kafka, which are categories used for gRPC.

Developers need to be able to leverage their tooling of choice, working with Git as their primary system of record while being able to focus on business logic as opposed to connectivity logic, Shafii said.

The way to do this is to use API specs as the source of truth for exposing services and the lifecycle of those services. You then automate validation of those services, the deployment of those services to the three types of connectivity, and publication of those services to the right places so that they are consumable and discoverable.

All this needs to happen in a decentralized way across multiple teams, and it must be able to scale.

Kong's goal is to enable this decentralization at scale and to let development teams focus on their platform and on Git, their interface of choice, while also making sure that the teams follow guidelines and build proper interfaces and consumable interfaces.

Shafii said he truly believes that by enabling developers to build applications powered by APIs better and faster, we will be able to take our day-to-day experiences to another level. We're going to be able to build a better network operations center for managing forest fires. We're going to be able to get to commuter-based smart cars to decrease our carbon footprint. And we're going to be able to manage farms of turbines for generating power.

Kong customers already are achieving these things - and being involved in achieving things like these is a great path to career advancement. By helping you use automation to achieve more things and do so in a secure manner, Kong wants to help put you on that path as well.