In part 1 of this series on Kubernetes, we discussed how companies like VMware offer the necessary tools to launch, monitor, create and destroy virtual machines. In this post, we review how – much like virtual machines – containers need to be created, monitored, destroyed and relaunched to account for the health of the physical or virtual machines on which they run.
In the last blog post, we discussed the need for both speed and quality for your API delivery and how APIOps can help achieve both. In this part of our blog post series, we’ll walk through what the API lifecycle looks like when following APIOps. We’re still following the best practice we’ve established in the industry over the years, but what you’re going to see is that the processes we follow at each step of the API lifecycle – and between each step – have changed.
In part 1 of this series, we started a journey from the planet-spanning infrastructure layer to what happens inside a single Kong worker, similar to an office building in complexity. In this second part, we’ll dive a bit deeper—we’ll see who the occupants of that office building are and the kind of life they live.
Today, we’re thrilled to announce the general availability of Kong Ingress Controller 2.0 (KIC) – the most robust, scalable, and extensible version of our Kubernetes Ingress Controller to date. This is a major milestone both for the KIC product as well as for the Kong community as a whole. In addition to KIC 2.0’s new features, it also sets the foundation for us to more rapidly improve the user experience and add more capabilities.
Today, Application Programming Interfaces (APIs) and microservices are the de-facto standard for building and connecting modern applications. APIs are no longer just a delivery mechanism but have become the product itself. API lifecycle management refers to the comprehensive, step-by-step process of planning, developing, implementing, testing, and versioning an API.
These days, a lot of companies are moving towards cloud native applications and declarative configurations. This is also true for the traditional API gateways (e.g., MuleSoft, Axway, etc). Customers are looking for new technologies which fit better in their cloud environments and also are faster and cheaper. The main challenge here is how to migrate the existing APIs to the new platform.
