 |
VOOZH | about |
|
VOOZH | about |
We’re so glad you’re here. You can expect all the best TNS content to arrive Monday through Friday to keep you on top of the news and at the top of your game.
Check your inbox for a confirmation email where you can adjust your preferences and even join additional groups.
Follow TNS on your favorite social media networks.
Become a TNS follower on LinkedIn.
Check out the latest featured and trending stories while you wait for your first TNS newsletter.
APIs are now the essential building blocks of digital businesses. The advantages they offer DevOps today include:
WSO2 API Manager 3.0 helps to improve API-management capabilities while addressing both API developer and consumer requirements. Notable among all the new functions of version 3.0 are the built-in Kubernetes Operator and API Microgateway, which elevate APIs to first-class citizens in Kubernetes.
Kubernetes is designed for automation. But when increasing the complexity of applications, it raises the burden on DevOps and the likelihood of errors. By combining custom resources and custom controllers, the Kubernetes Operator enables a developer to write code to automate a task beyond what Kubernetes itself offers. Custom resources provide APIs to users and custom controllers help implement API functions. With this extensible architecture, a user can extend the behavior of the Kubernetes cluster without modifying the code in Kubernetes.
Microservices is an architectural style that structures an application as a collection of services organized around business capabilities. Now, smaller teams within an organization can analyze, develop and test these services while focusing on business problems. WSO2 API Microgateway, which considers an open API definition as a single source of truth, can be used as an enforcement point for API governance policies. The open API definition contains all of the required information regarding an API. By including this definition in the WSO2 API Microgateway toolkit, users can create an API microgateway.
Containers and Kubernetes might not particularly interest API developers, nor will most of these professionals want to spend time learning how to deploy a Kubernetes pod or add a Kubernetes service. However, they most likely are familiar with:
Additionally, their expectations will include the ability to accomplish one or more of the following tasks:
The API Operator for Kubernetes takes out all the complexity of managing a full API management solution while delivering on the above expectations. It provides a rich user experience for API developers and DevOps to manage their systems on Kubernetes.
By providing the open API definition to the apictl (API Controller) toolkit, WSO2 API Operator enables users to deploy an API microgateway with the required policy enforcement.
The API Operator for Kubernetes introduces four new custom definitions (CRDs): security, rateLimiting, targetEndpoint andAPI. The `Security` CRD holds security-related information and the `RateLimiting` CRD contains details for rate limiting.
The “TargetEndpoints” definition supports three API deployment patterns: shared, private-jet and sidecar. (Refer to this API microgateway article for more information.) If a company’s backend service is already running and it needs to be exposed via a microgateway, developers can define the target URL in Swagger, itself. If the backend service is not running, but the team plans to run it in the same Kubernetes cluster, developers can use the `TargetEndpoint` with its relevant Docker image. Then, API Operator will spin-up the corresponding Kubernetes deployment for the defined backend service with the microgateway. In shared and private-jet mode, the backend service can be run in separate pods. However, in sidecar mode, the gateway will run in the same pod adjacent to the backend service.
The API CRD holds API-related information. API takes the open API definition as a configMap along with the replica count and the microgateway deployment mode. When the custom API Controller is triggered, it will receive an open API definition from the attached configMap and create a Kaniko job by attaching a multistep Dockerfile along with the open API definition. Kaniko is a tool for building container images from a Dockerfile inside a container or Kubernetes cluster. This Dockerfile is used to pre-build the Docker image that has the API microgateway toolkit. The microgateway toolkit will generate the API microgateway runtime with the corresponding swagger file passed. Finally, Kaniko builds a new API microgateway Docker image and pushes it to the configured Docker registry.
After finishing step one, the API Controller will start creating relevant Kubernetes artifacts corresponding to the API definition. Depending on the defined API mode, it will create Kubernetes deployments for both the API microgateway and backend services.
The API Controller takes out the complexity from DevOps and automates deployment, with best practices to deploy an API microgateway in a microservices landscape.
Installing WSO2 API Manager 3.0 is now merely a matter of running a kubectl command against the Kubernetes cluster and it will take care of the rest. Developers can download apictl and configure their machines to take control of all API management functionalities. More information is available on the Kubernetes API Operator Git repo.
Kubernetes is rapidly becoming the de-facto cloud orchestration platform standard. WSO2 API Manager 3.0 is a full lifecycle API management platform that natively supports Kubernetes through a Kubernetes Operator. This means that managing and configuring APIs becomes a core part of the Kubernetes platform, closely integrating with existing management tools. The result is higher productivity for developers, DevOps and cloud administrators when building, deploying and managing APIs.
Feature image via Pixabay.
