More and more companies are eager to move their operations to the cloud. Yet, there's quite a bit of ambiguity on what moving to the cloud actually means. Is your business running in the cloud while you host your database on another platform or while you rely on a third-party service to handle your payments? That's a good start for moving to the cloud, but there are many other aspects to consider when building a cloud native infrastructure.
The Cloud Native Computing Foundation (CNCF) defines a cloud native infrastructure as one with "[c]ontainers, service meshes, microservices, immutable infrastructure, and declarative APIs" as typical characteristics.
This begins with isolating services within your application and moving towards decoupled and secure microservices. Further, a cloud native infrastructure requires automation through continuous delivery. Lastly, your ability to leverage containerization will go a long way toward moving you to the cloud. In this post, we'll take a closer look at these key features of a cloud native infrastructure.
When it comes to architecting an app, there are often two competing organizational methods: monoliths and microservices. A monolith is a form of organizing software in a single codebase; every feature and aspect of your app is self-contained. Designing microservices involves setting up separate, smaller applications. Each small app controls a single aspect of your app's functionality.
Cloud native infrastructure doesn't need to be a collection of microservices. But sooner or later, you might find yourself needing to scale out one part of your application. Monoliths are easy to get started with, but after a certain growth stage, microservices become easier to administer and configure.
This almost forces you to think about application design in different terms—redundancy and message queuing, anticipating and recovering from errors—aspects which a monolithic application obscures. In other words, the failures on one service do not affect any other that makes up your application.
Learn more about the process for transitioning from a monolithic to a microservices-based architecture. Download this eBook >>
Microservices communicate by passing messages and data through APIs. We don't typically expose those APIs to the public. Nonetheless, you could set up an API gateway through Kong Konnect to help route external requests to internal services.
The communication protocol used in a cloud-native infrastructure doesn’t matter much. You could use REST, gRPC, GraphQL or anything else. What does matter is using a consistent standard and ensuring all commands pass through these channels.
Isolating your app's functionality into microservices provides other security benefits as well. Earlier, I mentioned how buggy code would only affect one microservice. The same is true for larger problems, such as security issues. If an external agent gains control of one server, they're less likely to hop to another server due to network isolation rules. You can apply these rules across your entire infrastructure and manage them from one location.
In a true cloud native infrastructure, even your database acts as a microservice. It prevents storing user data locally. Kong Mesh and the CNCF's open source Kuma grant observability of traffic rules, logs and permissions to maintain the strength of your cluster.
How can a service mesh help you achieve bank-grade security for microservices? Find out in this eBook >>
Deployment and delivery for a monolithic application can be cumbersome, brittle and time-consuming. Moving toward a cloud native infrastructure means moving toward a DevOps approach. That means automating all aspects of application delivery.
With your services separated, you can now update each one independently. Here again, is another advantage of microservices over the monolith. A monolithic app might have thousands of tests that take time to complete. The deployment might also take a long time, as services restart and dependencies update. With microservices, your application separates into individual code repositories. Updating one aspect of your app is much faster because everything is scoped and isolated. Your test suites are smaller, and language dependencies are fewer.
You've likely already embraced a DevOps mindset, which is a requirement for a cloud native application. In this setup, all aspects of infrastructure management—deploying the code, load balancing your servers, scaling your resources, etc.—are performed with scripts. This turns your processes into testable, versionable pieces of code, and it helps ensure that applications are modified and upgraded consistently.
For a cloud native app, all of your datastores, servers and other resources should be able to expand (or reduce) at any moment. If you run out of disk space on one microservice, the process of enlarging the disk should be repeatable for any other microservice, too. This will lead to a situation where infrastructure management could even tie into your monitoring software. As your monitoring solution detects the need for more resources, it alerts your infrastructure management system to scale up the necessary resources.
For example, imagine a situation where your monitoring system sees increasing traffic for a certain service. With scripts in place for automated processes, the monitoring alert can trigger a service deployment to additional nodes to handle the uptick of activity. Or perhaps an erroring incident occurs on a service. The monitoring system can trigger the process for locking down that service for troubleshooting while spinning up a separate service to handle subsequent requests.
All of this is possible because each of your microservices focuses on one task. You can modify the behavior of each microservice through API calls.
By understanding the above requirements, containerization becomes a more reliable approach for setting up and running your app. Running your application in a container allows you to build software with greater consistency, elasticity and predictability. The operating system and any system packages are explicitly defined and managed by code through Docker. A container is built from a Dockerfile, and docker-compose is used to coordinate the starting of multiple containers.
In production, however, orchestrating your microservice containers will lead you to Kubernetes as a way to manage all of your nodes. It comes with many advantages out of the box. For example, if one node fails, Kubernetes can automatically replace it with a healthy one; Kubernetes can handle load balancing across your network, and it can scale out resources based on usage.
The interesting thing about Kubernetes is that it's driven by APIs and CLI tools. This is immensely helpful for automation, but it's less useful if you're a human trying to get an overall picture of your network health and operation. This is a gap that Kong Konnect fills. Kong Konnect (and most Kong services!) keep Kubernetes' open protocols in mind. Rather than replacing Kubernetes, Kong works alongside it. The main focus of Kong Konnect is to ensure services are reliable and performant. Kong Konnect does this by providing observability into services, giving insights on uptime and traffic patterns, as well as the devices your users are connecting with.
By 2022, more than 90% of enterprise companies will rely on cloud infrastructures. Several platform-as-a-service (PaaS) companies—like Azure and Google Compute—encourage developers to take a cloud native approach when designing their applications. Moving to a cloud native architecture should be a priority for your teams.
While it may seem intimidating to make the move, you can stand on the shoulders of giants. We have an article that provides more conceptual information on what a cloud native lifecycle looks like. When you're finished with that, you can build a demo app in under ten minutes using our Kong Konnect quickstart to see how advantageous a cloud native infrastructure can be.
Ever feel like you're fighting an uphill battle with your API strategy? You're building APIs faster than ever, but somehow everything feels harder. Wasn’t API-first supposed to make all this easier? Well, you're not alone. And now industry analys
In this article, which is based on my talk at VueConf Toronto 2023, we'll explore how to harness the power of Vue.js and micro frontends to create scalable, modular architectures that prioritize the developer experience. We'll unveil practical strate
Survey Says: Google LLMs See Usage Surge, Most OK with DeepSeek in the Workplace Enterprise adoption of large language models (LLMs) is surging. According to Gartner , more than 80% of enterprises will have deployed generative AI (GenAI) applicatio
Kafka delivers massive value for real-time businesses — but that value comes at a cost. As usage grows, so does complexity: more clusters, more topics, more partitions, more ACLs, more custom tooling. But it doesn’t have to be that way. If your tea
A Practical Look at When (and When Not) to Use Ambient Mesh The word on the street is that ambient mesh is the obvious evolution of service mesh technology — leaner, simpler, and less resource-intensive. But while ambient mesh is an exciting develop
I'm commonly asked by customers for advice on how they can build a good platform cross-charging model for their organization. And my gut reaction is nearly always "don't." We'll come back to why I think that later, but first let's look at what cross
Unify the API and Eventing Developer Experience with the Kong Event Gateway and API Platform Introduction: The EDA and API worlds are converging . . . finally For the past several years, there have been murmurs of an incoming convergence between API
