As the world moves to a self-servicing platform infrastructure, especially in cloud-native environments, Kubernetes plays a crucial role in building flexible, resilient, and scalable infrastructure.
In this blog, we will take our conversation forward on how Kubernetes ecosystem is helping engineering teams build these cloud-native platforms. We will specifically talk about some of the architecture-related questions that are crucial to answer to build a resilient self-service platform on Kubernetes.
Let’s start with the overall broad approach to architecting the platform.
“You cannot scale an efficient engineering organization on bash-scripts, you’ll die.” Jason Warner, CTO of GitHub
Why architecture and tooling matters
The reason Platform Engineering became popular in software companies is because it helped developers focus less on infrastructure and more on application development.
The goal of any platform is to abstract the tooling so much that the developers would be able to use a UI or the exposed APIs to get the infrastructure ready. This is goal of a solid “Internal Developer Platform” or IDP. So, the more IDP overlaps with the developer’s comfort zone, the better the architecture and more effective the platform. This Twitter thread explains it well.
The idea is to bring more aspects of IDP under developers’ core skills so that they can self-service their needs from the platform without relying on the platform team. The below image explains the macro picture well:
How tools in the Kubernetes ecosystem help
The CNCF landscape consists of all the tools from the bare metal layer to the observability layer. All the CNCF-graduated tools work very well with Kubernetes.
Kubernetes is one of the key products under CNCF and Cloud-native platforms can be built using purely Kubernetes-compatible tools. This would help improve portability and interoperability between the different tools in the platform.
One example of such an architecture could be a Kubernetes-native Operating model architecture, as suggested in this IBM article. The core idea is to use tools in the CNCF landscape with Kubernetes for maximum compatibility and interoperability.
The different categories of tools required in a cloud-native IDP are:
- Platform orchestrators like Taikun.
- Developer Portals like Compass from Atlassian.
- CI/CD tools like Jenkins or Argo CD
- Cloud Databases like AWS RDS or Azure SQL or Google CloudSQL.
- Image Registries like DockerHub or ones from AWS/Azure or Google Cloud.
- In-cluster resources like RabbitMQ or Redis
- Infrastructure-as-Code like Terraform
- Kubernetes – Self-hosted or managed, along with Kubernetes Control planes.
- Monitoring tools like Grafana, New Relic or Prometheus
- Security tools like Cisco Cloudlock or Splunk
A lot of these tools can be automatically managed by using Kubernetes orchestration tools like Taikun.
Managing Platform as a Product
When it comes to the Internal Developer Platform (IDP), there are 3 main goals:
- Improved Developer Experience (DevEx)
The platform must reduce the cognitive load on the developer and eliminate repetitive manual work for both the platform team and the developer.
- Standardize the mundane
A lot of workflows in the software delivery cycles can be standardized. For eg. security, compliance, monitoring and many other supporting infrastructure.
We do not want separate tools for each layer of the software workflow. Standardizing common aspect of developer cycles can reduce the cognitive load on both the platform team and the developers. It will pave the way for easier management and, thus shorter development times.
- Self-service capability
Self-service capability is possibly the most important aspect of an Internal Developer Platform. The goal is to bring down turn-around times for the developers to get the required infrastructure for application development.
Internal Developer Platform (IDP) with Kubernetes
To bring the kind of flexibility and scalability in IDP, it is important to approach the Internal Developer Platform as a product. The difference is that the platform team’s customers are their own organization’s internal team members.
Therefore, just like product management of a software product, the platform team must gain a comprehensive understanding of the requirements and pain points of the development team.
The architecture of the IDP must be designed for standardization. This can be either achieved to clear well-documented APIs or through UI orchestration platforms like Taikun.
Taikun Kubernetes Management dashboard
These UI-based platforms allow developers or platform teams to abstract complex Kubernetes configurations and focus on core business problems to be solved. Here is how a UI-based orchestrator like Taikun would interact with other platform components.
Kubernetes cluster management with a product mindset
As Kubernetes forms the core of platform architecture, there are some common pitfalls that you must avoid to ensure a more robust architecture:
- Ensure health probes are configured
A common mistake in K8s cluster setups is missing readiness, liveness and startup probes. You need to have effective health checks in the cluster to ensure pods are able to process the requests.
Active monitoring with health probes is essential to avoid such issues.
- Resource limits must be bounded
Another common mistake in designing K8 clusters is that pods are defined without resource limits on memory, CPU etc. This can impact other applications in the same cluster and can result in the failure of active nodes, there by, degrading application performance.
This problem is commonly known as the noisy neighbor problem. It can easily be avoided by defining quotas for resource management at pod and namespace levels.
Taikun has a feature to assign resource quotas for each team based on their project requirements. In fact, we can also have project-based billing for each team. Such transparency and accountability help reduce the costs of running a cloud-native platform.
- Images must be environment-agnostic
Another common pitfall is that the images registry will have environment-specific docker images. This means that moving from testing environments to production will have many unknown gaps and may result in failures during deployment. Such scenarios can easily be avoided by using ConfigMaps and Secrets.
- Use RBAC and service accounts
The access to K8 clusters must not be the same for all team members. It must be different depending on the experience and expertise of the team member.
Taikun has a robust access control system that provides granular control to team members and managers on the cloud resources.
- Using separate clusters for different environments
Clusters used for production and non-production environments must be different to create a logical division of clusters. This avoids inadvertent mistakes in using namespace and accidental failures in environments.
All of these issues can be avoided entirely by using Kubernetes management tools like Taikun.
3 Tips while building a Kubernetes-based platform architecture
We spoke about the common pitfalls, but before we close, let us share 3 tips that can help you create a flexible, scalable platform that developers use:
- Define your application suite
Kubernetes universe is large and it is easy to feel overwhelmed with all the options available to you. We suggest that you pick 1 or 2 tools for each layer, which you feel serves 80-90% of your developers’ needs.
This will help you standardize the suite you work with. Avoid the temptation of adding more tools for incremental benefits. This approach will also help your development team to focus on improving their skills on a few tools and get more out of them.
- Have an active feedback loop
This is very important. Developer needs change and your platform should also adapt to those changes. Hence, it is vital to have an active feedback loop with your development team to ensure their needs are getting fulfilled.
- Abstract and simplify
The goal of every platform is to make the developer self-service their infrastructure needs. For this to happen the IDP must abstract the complexities of the Kubernetes cluster and other infrastructure deployments in a way that developers are comfortable with.
The graph below explains it very well. This is your aim. Use Kubernetes management tools for such abstractions.
Taikun – Platform Engineering on Kubernetes
At Itera, we believe Kubernetes management must be easy. You team should be able to create the kind of Internal Developer Platform that suits your organization’s needs without getting into the complexities of managing powerful Kubernetes clusters.
That is why our product Taikun is one of the best tools for Kubernetes management. It abstracts most of the complicated aspects of K8 deployment and lets you experiment much faster.
Within a few minutes, you can get up and running with your first Internal Developer Platform on Kubernetes using our Taikun dashboard.
Taikun works with all kinds of clouds – On-prem, hybrid, private or public. It has built-in, on-demand, self-service capabilities for resources. So, you never have to start from scratch.
The large application marketplace in Taikun also helps you automate the build, deployment, and management of Kubernetes and applications.
Taikun Kubernetes Platform Engineering
You can sign up at Taikun.cloud and start your platform engineering journey today. If you have questions, let’s talk! Schedule a quick demo with us, and we will help you quickly start your Platform Engineering journey with Kubernetes.
