There are good reasons for spreading workloads and applications across multiple clouds. Options include using a combination of public and on-premises cloud platforms, a strategy known as hybrid cloud—or using more than one public cloud provider, a strategy known as multi-cloud. What are those benefits? And what are some of the best strategies for achieving them? Let’s explore that.
Changing the technology an organization works with is a bit like taking up a new sport. Your initial excitement leads you to buy the most expensive equipment you can find, leaving you soon to realize that your new tools have created a steep learning curve. Transitioning out of monolithic applications to microservices is quite similar.
Have you ever found yourself in a situation where all your service mesh services are running in Kubernetes, and now you need to expose them to the outside world securely and reliably? Ingress management is essential for your configuration and operations when exposing services outside of a cluster. You need to take care of the authentication, observability, encryption and integration with other third-party vendors alongside other policies.
Disaster Recovery (DR) is crucial to every organization. Business continuity is important whether you live in an area prone to natural disasters or need to prepare for unseen events like a data center outage. But how do you ensure that the changes behind the scenes don’t impact the end user? Red Hat Ansible Automation Platform (AAP) is the automation tool of choice for many enterprises.
Event Hooks is a new Kong Enterprise feature launched in the Kong Gateway 2.5 Release. This feature sends you notifications when certain events happen on your Kong Gateway deployment. Kong Gateway listens for events, like routes, services, consumers, certificates, plugins, workspaces and RBAC roles created, updated or removed. You can also create or extend Kong Plugins and add the Event Hooks functionality for custom use cases.
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.
