What architects need to know about managed Kubernetes
Everybody is talking about microservices and 12 Factor Apps, but opinions about the necessary infrastructure to support them differ widely. Understanding the full picture is essential for your project's success.
Modern development projects often start with Kubernetes as the base platform for running and orchestrating services. However, its built-in functionalities are not sufficient for most projects. When thinking about developing a Kubernetes-native application, you should think about other requirements, too.
Modern applications need a lot more than just containers and orchestration. They're built with an API-first approach and utilize service discovery and invocation provided by a platform mechanism. They can scale to heal from outages while supplying site reliability engineering (SRE) teams with enough information about what's going on to enable seamless operations. Ideally, all of these attributes should be incorporated into the development process using change and version management that follows a modern continuous integration/continuous delivery (CI/CD) model.
Other components that play an important role in a project's success are hidden inside the umbrella term "Kubernetes." There's compliance, networking, disaster recovery, and change management, to name a few.
To make this even more challenging, there are plenty of alternatives for individual requirements. That means responsibility for creating a cohesive development platform falls on architects and their project teams. This task can be managed and mitigated with enough experience, but it becomes difficult if you're looking for a fully managed platform that provides everything you need within your project budget.
Instead of taking on full responsibility and management of the platform, architects should evaluate the implications before choosing between assembling their Kubernetes stack or adopting a managed platform such as Red Hat OpenShift.
[ Examine 10 considerations for Kubernetes deployments. ]
Here are some of the decision factors to consider:
- Extend your view beyond the Kubernetes platform and treat your project requirements as platform requirements.
- Evaluate and define your project's support and responsibility matrix and the required components.
- Managed cloud services still require internal expertise to maximize your return on investment—they should supercharge the IT team, not take its place.
This responsibility matrix is modeled after the ARO responsibility matrix and the AKS support policies. It illustrates the most important differences between a managed development platform and a plain managed Kubernetes. This is a broad view that gives a better understanding of the areas involved and how to compare them, but there are specific developer advantages to draw from a complete platform approach.
What a managed Kubernetes platform gives you
Consider your developers' needs and how the following factors would or would not benefit them:
Centralized information
Composing and orchestrating the individual pieces of a software project require deep and seamless insights into the resulting system's desired behaviors. For frictionless development, it's smart to collect relevant information in one central place. For example:
- Quarkus contains a Developer user interface (UI) with integrations for runtime, messaging, and log inspection.
- Red Hat integrated development environment (IDE) plugins support developers with local and remote debugging and deployment and deeply integrate with CI/CD on OpenShift.
- OpenShift Developer Console provides a developer-centric view of distributed applications.
- OpenShift Service Binding allows for automated wiring of components.
- OpenShift Database Access integrates data storage seamlessly into applications.
[ Download this eBook for a detailed look at container orchestration with Kubernetes. ]
Self-service options
While processes help to control resource consumption and budgeting, they can also slow development projects with unnecessary approvals and wait times. The self-service approach (as is the case within OpenShift) gives developers the freedom to create their own resources as necessary within predefined standards:
- Developers can provision their own projects based on templates.
- Integrated CI/CD functionality allows efficient cross-team collaboration.
- GitOps is at the core of cross-functional teams with ArgoCD.
Develop once, deploy everywhere
Single platform solutions usually mean vendor lock-in. A commitment to a defined set of technologies and runtimes can be effective for governance, but it limits flexibility and, sometimes, deployment targets. Requirements from both technical and business perspectives are changing rapidly and constantly. It's more important than ever to enable the flexibility to deploy where necessary from on premises to edge:
- Advanced Cluster Management enables flexible deployments and movements onto hybrid cloud targets.
- Red Hat App Studio gives developers full access to standardized application definitions that can be moved between targets as necessary.
Less time writing YAML
Meaningful guardrails are useful for preventing errors, but roadblocks only slow development. Developers need the freedom to choose command-line tools, highly integrated utilities, or specialized development IDEs. OpenShift provides safe default configurations, meaning developers spend less time writing YAML and more time writing code:
- Quarkus offers streamlined code for 80% of most common usages, and it's flexible for the other 20%.
- Red Hat IDE tooling is based on standards but not limited by them.
- OpenShift Local serves as a production-near-development environment.
- OpenShift Developer perspective lets developers visually interact with applications, components, and services associated with them within a project and monitor their deployment and build status.
- Devfile support helps synchronize project definitions across environments.
- Advanced application import and export (YAML, Helm charts, Git repos, across cluster) is available.
- JKube provides a collection of plugins and libraries that helps build container images using Docker, JIB, or S2I build strategies. It also generates and deploys Kubernetes/OpenShift manifests at compile time.
Built-in security
Managing security is a continuous process. As applications are deployed or updated, providing dynamic security controls is critical. You can use Red Hat OpenShift to apply security controls to the software supply chain, helping to manage applications without reducing developer productivity:
- IDE integrations provide source code security.
- CodeReady Dependency Analytics is built in.
- Built-in KubeLinter analyzes Kubernetes YAML files and Helm Charts, and it checks them against various best practices with a focus on production readiness.
- The Universal Base Image (UBI) serves as a trusted foundation for all workloads.
- Clair provides container vulnerability scanning.
[ Try our interactive scenarios to learn Red Hat OpenShift at your own pace. ]
Manage your business, not Kubernetes
I'll stop with these few examples. When you talk about managed Kubernetes, it's essential to understand that there's more than just the underlying orchestration implementation that's important to a successful implementation. When you pay attention to all the relevant requirements and extend the scope to everything required for modern, cloud-native solutions, you can prevent many mistakes and set yourself up for success early.
Markus Eisele
Markus is a Developer Strategist Red Hat EMEA and Java Champion. He's a former Java EE Expert Group member, founder of German JavaLand Conference, reputed speaker at Java conferences around the world, and a very well-known figure in the Enterprise Java world. More about me
Navigate the shifting technology landscape. Read An architect's guide to multicloud infrastructure.
OUR BEST CONTENT, DELIVERED TO YOUR INBOX