 |
VOOZH | about |
|
VOOZH | about |
We’re so glad you’re here. You can expect all the best TNS content to arrive Monday through Friday to keep you on top of the news and at the top of your game.
Check your inbox for a confirmation email where you can adjust your preferences and even join additional groups.
Follow TNS on your favorite social media networks.
Become a TNS follower on LinkedIn.
Check out the latest featured and trending stories while you wait for your first TNS newsletter.
Cloud Native Computing Foundation sponsored this post, in anticipation of the virtual KubeCon + CloudNativeCon North America 2020 – Virtual, Nov. 17-20.
DevOps promises faster engineering teams by managing both infrastructure and code. But the reality for most who adopt Kubernetes and DevOps best practices, is that platform or SRE (site reliability engineering) teams need to keep control over infrastructure. How then do you bridge the gap between these teams without compromising on velocity — or worse, security?
While the benefits of Kubernetes and other cloud native technology are well known and include an increase in operational productivity and scalability, getting there can mean dealing with an increase in configuration complexity. In most cases, this complexity can be solved through centralized self-service developer platforms.
GitOps is an efficient way for development teams to go faster, even if they are not experts in Kubernetes. Implementing a self-service developer platform that is automated with GitOps can provide your application engineers with the autonomy to increase deployment frequency and reliability.
But before exploring strategies for self-service platform adoption, it is worth discussing what GitOps means. At its core, GitOps is these two things:
For GitOps to be implemented correctly, there needs to be a mechanism in place that can compare the desired state — which is kept in Git — with the running state and alert on a drift. If teams can observe their system at any point in time and get alerted when the system diverges from the desired state, then mitigation can occur. With GitOps, your entire system is described declaratively and versioned in Git. This gives teams a sole source of truth from which everything is derived and driven. GitOps also makes use of software controllers to ensure correctness, which alert on any divergence — setting up a feedback and control loop for application and operational tasks.
Operations teams can implement self-service Kubernetes platforms by allowing application engineers to choose from a set of cluster add-ons and other tools, which solve common uses such as monitoring and CI/CD deployment pipelines from Git. This is possible because not only is Kubernetes described in declarative configuration, but so is its ecosystem of cloud native tools. With declarative configuration versioned in Git, developers and operators have a method to spin up correctly configured clusters based on their use cases, through pull requests.
Implementing a self-service platform and automating it through pull requests supplies several significant benefits for both platform and development teams — such as a common developer experience for operations and application development teams, built-in audit trails, guardrails, and security guarantees. For a practical discussion on self-service developer platforms and how to implement them, listen to Steve Wave and Cornelia Davis discuss the topic in this recent podcast.
Here are five practical strategies to use when onboarding and educating development teams who are adopting GitOps for self-service Kubernetes platforms.
At the onset, it is critical to build a documentation paradigm that is kept up-to-date and that works for your organization. To keep information flowing, you may create a wiki site to document common cloud native patterns; for example, design abstractions and primitive definitions, or even guidelines on how to implement and manage secrets.
Remember, there will be a learning curve for the teams to understand the differences between doing things the old way and using this new model.
Transparency is the key. Document and supply support for your strategies on how to manage security, secrets and how you might go about using persistent data. It is important to document the security you have in place and why it needs to be there, as well as to enforce those security requirements.
One of the best ways to start is with a part that you are already familiar with and which has a small impact on the larger workflow. If that one thing does not work out, then it is not going to be too difficult to course-correct. Starting out with a more ambitious project could have far greater negative consequences and can be much harder to undo.
You could begin with the platform workload, for example, leaving aside the developer workloads. Or you can focus on how to update the platform itself. Iterate on a few different approaches for different aspects, such as how to deploy the ingress controller or how to deploy the monitoring and alerting stack.
Start out small and roll out minor changes to staging and development environments first. This is especially important when you are just beginning to add GitOps tools like Flux to your Kubernetes environments. If you enable them on staging clusters first, you can get a feel for the features you like and do not like. This allows you to decide which features tie in better with your environment and how you are going to integrate them.
Develop some sort of sandbox environment on the developer machines, so they can experiment with processes on their own. There are many tools to choose from in this space, such as Kind, kubeadm, eksctl, Minikube and Ignite. In addition to those tools, you can also take advantage of public Helm charts and public Docker images for experimentation. Once you have built a first pipeline, developers will better understand and follow the processes better.
People often learn in diverse ways, so recognizing that and developing a plan to meet the needs of your team early on can have lasting dividends. This is particularly important now that so much work is virtual. Normally, you could hold information sessions in the office, but now those meetings will need to be held over Zoom or Teams. But you can record them and make these sessions available for those who would like to follow along and learn at their own pace.
Communicate. Communicate. Communicate. Remember, you are adopting a new way of doing things. You will learn along the way and there will be setbacks that you will learn from. You can never over-communicate these lessons and the changes you make. Feel free to experiment with different communications methods, like virtual meetings, wikis, Slack chats and (hopefully one day soon) in-person meetings.
To create autonomy among the development team, you will need to select the tools and languages that work best. GitOps can be extended beyond YAML and works with Python, Typescript, cdk8s and jkcfg to express your declarative configurations. Even though GitOps has Git in the name, you can use any version control system — so don’t throw away your existing systems. And lastly, GitOps is not just about deploying your applications, but also applies to infrastructure, and complete cluster platforms.
“Today you might be targeting Kubernetes because you’ve got replicaSet controllers and deployment controllers. But we can extend those targets beyond that to include things like the cloud, bare-metal, and many other environments. That means not only can I GitOps cloud native applications, but I can also GitOps my entire infrastructure.” — Cornelia Davis, Chief Technology Officer, Weaveworks
To learn more about Kubernetes and other cloud native technologies, consider coming to KubeCon + CloudNativeCon North America 2020, Nov. 17-20, virtually.
The Cloud Native Computing Foundation is a sponsor of The New Stack.
Feature image via Pixabay.
