A lot of what we do at Buildly depends on containers and a way to manage or orchestrate them through Kubernetes. Yes it's a funny word, greek for helmsman or pilot, but it's an important open source project that allows developers to build massively scaleable, as well as little itty bitty tiny applications and deploy them almost anywhere.
Kubernetes, also known as K8s, is an open-source system for automating deployment, scaling, and management of containerized applications.
It groups containers that make up an application into logical units for easy management and discovery. Kubernetes builds upon 15 years of experience of running production workloads at Google, combined with best-of-breed ideas and practices from the community.
What that means for the rest of us, is that if you build a microservice application, or really any application that has an API and needs to talk to one or more other APIs, Kubernetes can hook that up for you. In it's most simplest form, it abstracts the server and server configuration or "compute instances" away from your application so you can deploy as few or as many instances of each service as you have more or less traffic hitting your application.
The best part is almost every cloud hosting service now provides a way to manage Kubernetes in their hosting environments. So you can build a service or application with a bunch of containers, like this one here that runs the Buildly Core to help you connect all your services with one authentication layer, and then deploy it do AWS, Google Cloud, Azure or just about any cloud host and it will run and perform just like it does anywhere else.
The Buildly Core, a cloud native Gateway +, acts as a bridge between pre-configured and custom frontend clients and the backend services in a Kubernetes environment. The Buildly core api service provides multiple light weight services such as a configurable and flexible API gateway (Core), data mesh aggregation service (Mesh) and an authentication and authorization layer (Users). It’s built around a decoupled Microservice architecture pattern but offers more flexibility then most, by giving the developer the option to pick and choose the parts of each Share Nothing, Proxy or Shared Data Microservice pattern they want to use with each independent service.