Organizations have now seen the value of building microservices. They deliver applications as discrete functional parts, each of which can be delivered as a container or service and managed separately. But for every application, there are more parts to manage than ever before, especially at scale, and that’s where many turn to an orchestrator or a Kubernetes framework for help. While Kubernetes is one of the most popular container orchestration projects on GitHub, many organizations are still intimidated by its complexity.
Kubernetes solves many problems by providing an extensible, declarative platform that automates containers’ management for high availability, resiliency, and scale. But Kubernetes is a big, complex, fast-moving, and sometimes confusing platform that requires users to develop new skills, organizations to invest in building a new team to manage Kubernetes, platform teams to create a framework/interface for their developers on top of Kubernetes, and more. Often, this leads to slow adoption, increased costs, and a long list of frustrations.
As these Enterprises start adopting Kubernetes, one key ask for their DevOps and Platform Engineering teams is to “operationalize” Kubernetes. While powerful, Kubernetes is a platform that, at scale, can easily blur the lines between developers and operations teams, can introduce challenges around security and controls, can quickly scale to the state of containers and services sprawl, can lead to unnecessary resource consumption, can drive developer experience and speed down, and more. Overcoming these challenges and getting your organization to a state where they are comfortable with Kubernetes and where your software development and delivery teams can scale is not easy.
As we build Shipa, we talk to many organizations going through that “operationalization” process. As our roadmap is heavily driven by user input and use-cases, we wanted to share some of the common issues faced and the options on how we see users leveraging Shipa to overcome them to ultimately “Operationalize Kubernetes”:
Share on email
Email
Share on twitter
Twitter
Share on linkedin
LinkedIn
1. Building and automating compliance
It can be a tremendous job to ensure that a cluster’s desired configuration is set and maintained, especially when you provide Kubernetes as the interface for your developers to deploy and manage their applications directly.
In addition, enforcing compliance across networking, resource utilization, permissions for multiple teams, utilization of external services, security scans, and more can be overwhelming because these components are, many times, completely independent from one another and managed by different teams. Trying to build an automated compliance model on top of all this ends up being a daunting task for the DevOps or Platform Engineering team. It only leads to more time spent on building something that is not core to the business.
Kubernetes Framework: To tackle that problem, we designed Shipa to leverage what we call Frameworks. The DevOps and Platform Engineering teams can use frameworks to build and automate compliance around the items below:
The focus for the team is now building the compliance framework that should be applied automatically to applications and services deployed using it rather than building a myriad of custom scripts, Helm charts, and Kustomize, hiring more people to build and manage it, and so on.
Through the framework, the team is now focused on what should be enforced at the application or service level and, as the framework can be bound to any Kubernetes cluster, the team can finally focus on the business requirements rather than building policies for the local cluster, Rego policy files, and more, which can drastically change if you decide to move to different cluster provider, cluster version, policy enforcement model, and others.
With the frameworks created, you can then attach these frameworks to different clusters:
You can create multiple frameworks per cluster, and each framework can have a completely different configuration, so you can tackle use-cases such as Dev, QA, and Prod environments, different projects, and more where each may require a different level of RBAC, Network policy, and other compliance requirements.
2. Managing workload configuration deployed on the cluster
One common concern we see from DevOps and Platform Engineering teams is the number of resources being consumed by applications and services deployed by the different development teams they support. We talk to companies that say they could easily reduce their compute utilization by ~30 or even ~40% if they could easily enforce resource utilization automatically for applications and services deployed. Still, they report issues identifying who owns a specific app or service, wasting time managing and maintaining a huge amount of YAML files, and more.
Thinking about these issues, we created a component called Plans. As a DevOps or Platform engineer, you can create multiple plans where you can set a specific amount of memory, CPU, and Swap that can be consumed by applications and attach that plan to a specific framework:
If you attach a plan to a framework, every time an application is deployed using that framework, the plan limits will automatically be enforced, and through Shipa, you can monitor closely how much of these resources the apps or services are actually using, who owns them, and more. If you need to adjust the plan for a specific app or service at any time, you can directly attach a new plan to it, without the need to change YAML files, Helm charts, or Kustomize scripts.
3. Multi-tenant and multi-clusters
As you scale the clusters required by your company to run all the services your developers are deploying, it becomes more difficult to manage and control what’s deployed, where, and how across the different clusters and sometimes, different providers.
At this point, most people agree that multi-tenancy is not an easy thing to manage on Kubernetes, especially at scale and across multiple clusters and cluster providers.
Thinking about that, Shipa incorporated the concept of multi-tenancy at the framework level, which makes it incredibly easy for you to enforce roles and permissions for teams and users.
When using Shipa, Kubernetes clusters are no longer the interface given to your developers for development and deployment of apps and services, so Shipa facilitates the enforcement of multi-tenancy at the right level for the different teams and users within your organization:
In addition to RBAC and detailed permission options at the framework level, Shipa also provides an enhanced multi-tenancy level through its frameworks, which creates a namespace in your cluster for each framework, so apps and services deployed across different Shipa frameworks will be isolated by different namespaces across your clusters.
4. Security and agility
The pressure is on for organizations to continue to innovate at a pace never seen before, making it easy to treat security as an afterthought. Many organizations think container and microservice security can be simply interpreted as security scanning of your images and code. Still, security goes well beyond that and should be incorporated into your workflow.
To ensure that your organization implements best practices, we embedded security as part of the framework workflow, incorporating security scanning, network policies, registry control, RBAC, and more. That workflow embedded into your CI/CD pipeline can be a powerful way to enforce security while enabling velocity for your developers.
We embedded a holistic approach to security into Shipa’s framework so that it can be tied to your CI/CD pipelines, allowing developers to simply focus on delivering application code and updates while Shipa’s framework enforces the different security settings automatically. With Shipa’s dashboard, you can observe security reports, deployment information, application ownership, application lifecycle, logs, and more. Combined, this becomes a powerful way for you to support your application post-deployment while enabling developers with better observability and velocity.
It’s terrific to see Kubernetes and its community growing and more companies adopting it and scaling their deployments. Here at Shipa, we believe that a structured workflow leveraging a Kubernetes framework can help these organizations to adopt Kubernetes and microservices architecture at scale, at the pace they are looking for.
Resources:
Shipa Website: https://www.shipa.io
Shipa Documentation: https://learn.shipa.io
Getting Started with Shipa: https://learn.shipa.io/docs/getting-started-with-shipa
Try Shipa today!
Share on email
Email
Share on twitter
Twitter
Share on linkedin
LinkedIn
