As we discussed in our last WTL Blog , containers are the future of application development in the age of the cloud. However, there are some factors you need to be aware of as you make the transition – here are thirteen to consider when building a container strategy that works.
1. Management buy-in will take time
Containerisation is a paradigm shift for development, so don’t be surprised if non-technical executives don’t understand the concepts. Expect to receive the same basic questions repeatedly, along with more frequent requests for progress updates, as your business gets to grips with the new technologies.
2. Your existing operating model won’t work
As containers are created and destroyed with every code change, your current escalation process will quickly become overwhelmed. As you roll out Kubernetes, investigate building a team of site reliability engineers who can develop a system to automate the management process.
3. The skills gap is greater than you think
Kubernetes is a relatively new technology, so skills remain in short supply. You already know that your team will not be fully up-to-speed but be under no illusion that they are probably further behind the curve than you realise. Make sure that you invest heavily in training as well as container technologies to address the shortfall.
4. Data volumes will explode
Encapsulating every application and service in its own container will result in far more nodes than your current virtual server environment. And when each generates its own data and logs, the volumes of data generated will increase exponentially. Automation will again be key, helping you to manage data and telemetry and uphold compliance.
5. Container sprawl is a fact of life
As your developers grasp the potential of Kubernetes they will want to deploy containers everywhere, on premise and in the cloud. Although a potential management headache, your business will be better served implementing a control plane and data fabric that supports Kubernetes anywhere, than trying to reign in the ambitions of your developers.
6. Your Kubernetes cluster won’t scale automagically
Because it is relatively new, Kubernetes is not the easiest technology to deploy. Containers do not necessarily scale automagically, and the sheer volumes of data being produced exacerbates an existing challenge. You will also need to investigate how containers are deployed to endpoint devices that may not be connected to the corporate network.
7. A “one cloud” strategy is doomed to fail (initially)
Choosing a single cloud provider helps simply infrastructure management, but it also goes against the experience and knowledge of your team. People know how to work with some providers and not others for instance. Rather than trying to force a single cloud platform of choice, investigate the potential for using a single control pane that allows you to deploy and manage Kubernetes containers in any cloud service.
8. Kubernetes version adoption will be inconsistent
The Kubernetes platform is undergoing rapid development with new releases shipping very quickly – faster than your whole team will adopt them. As a result, there are three officially supported versions in circulation at all times. This means that you will need to implement a control pane capable of managing multiple Kubernetes versions and a rolling upgrade program as new versions are released.
9. The container model will break your firewall networking segments
Firewalling the various nodes of your current VM environment is challenging but manageable. But once you deploy containers there will be too many nodes trying to communicate with each other for traditional firewall rules to cope. You will need to review and update your networking strategy to protect this new network paradigm correctly.
10. Agility is king – don’t tie your developers down too early
Kubernetes containers are specifically designed to support agile development, usually by breaking the structures and conventions that underpin traditional waterfall techniques. Consequently, trying to impose a rigid development structure will limit development agility. Instead you should simply focus on giving developers the tools they need to build containers where they are best suited.
11. Avoid vendor lock-in at all costs
One of the benefits of containers is their portability. But if your development is tailored to a specific platform, you compromise that ability. You must embrace platform-agnostic development to avoid reducing your strategic options in future.
12. Containers are not VMs
Conceptually, containers are similar to virtual server, operating on shared hardware. But because they are created to fulfil a single task, they are much more lightweight. They are also intended to be disposable, being created and destroyed with every code release. Your team needs to change their approach to development, adopting stateful and stateless apps as required.
13. Kubernetes won’t solve all your problems
Kubernetes is invaluable for rapid development and portable applications – but it can’t do everything. Some of your legacy systems will never be suited to containerisation and will have to remain hosted in virtual servers. Do not waste time and resources forcing applications into containers when you gain nothing from the exercise.
Conclusion
Containerisation is the future of rapid application development in the cloud era. As a rapidly developing technology, your team will need to adapt a mindset of constant change and improvement. As you move forward, don’t forget to address these 13 factors when building a container strategy that works for your business. And if you need further advice and guidance on building a successful Kubernetes containerisation strategy, don’t hesitate to contact the WTL team.
Useful Links
The Doppler – The State of Container Adoption Challenges and Opportunities