Containerisation in the enterprise - VMware Tanzu: Superfood syndrome & rubberducking
As businesses continue to modernise their server estate and move towards cloud-native architectures, the elephant in the room is the monolithic core business application that cannot easily be rehosted without significant risk and disruption.
These days, it is more efficient to deploy an application in a container than use a virtual machine. Computer Weekly now examines the modern trends, dynamics and challenges faced by organisations now migrating to the micro-engineered world of software containerisation.
As all good software architects know, a container is defined as a ‘logical’ computing environment where code is engineered to allow a guest application to run in a state where it is abstracted away from the underlying host system’s hardware and software infrastructure resources.
So, what do enterprises need to think about when it comes to architecting, developing, deploying and maintaining software containers?
This pair of posts comes from Bas Lemmens, VP and general manager for VMware Tanzu and (with some commentary on rubber duck debugging) from Derek Lee Boire, senior member of technical staff at VMware Tanzu Labs.
Lemmens writes as follows…
Container technology was once the domain of developers. Now, IT operations teams are taking control and Kubernetes is out in front. According to our The State of Kubernetes 2020 report, although it’s early days for enterprise adoption – more than half of respondents (57%) operate fewer than 10 Kubernetes clusters and 60% run less than half of containerised workloads on Kubernetes – momentum is increasing.
Superfood syndrome
As the adoption of Kubernetes moves beyond the experimental phase, it’s imperative for IT teams to be fully aware of the value added by adoption, before investing millions in container technologies. This can be likened to the hype surrounding superfoods – such as kale. Kubernetes is often seen as a ‘fix all problems’ product with massive potential. Similar to superfoods though, it’s about how you use it that really counts.
It’s important for IT teams not to rush into buying kilos of Kubernetes – assuming naively it’s the only solution for achieving agility, positive customer experience and innovation. Defining business outcomes before investing time, energy and money is the best approach to maximise investments.
Lemmens: K stands for kale and for Kubernetes – both can be super if consumed correctly.
It requires more than just Kubernetes to achieve business outcomes. Hype surrounds the technology and term Kubernetes. A lot of false expectations exist too. Some companies may have heard on the IT grapevine that Google, AWS, Netflix and Microsoft bet on Docker as a container format and Kubernetes as the orchestration engine – that the technology can scale and provide infrastructure at the same level as the big players. Simultaneously they may not be aware that the whole business model of such companies focuses on making infrastructure fluid and immediately available.
Regular customers have a very different business model, with solutions based on trusted platforms by trusted partners that have solved virtualisation in the past, and those partners now have solutions to achieve the same outcomes with containerisation.
Automation & standardisation
Of course, Kubernetes technology also has its benefits. Businesses can become more efficient in their use of IT and achieve better results, faster, from development life cycles. They’ll produce better software because via more automation and standardisation. Organisations can then use software to explore new business opportunities, experiment with the best ways to profit from ideas and evolve accordingly. In contrast, a ‘non-K competitor’ will have a harder time evolving software quickly and the software supply chain will become a bottleneck for helpful ideas they have.
Once large organisations switch over to a cloud native platform, developers can get more productive and create more sustainable streams of software updates. This means that these organisations can start to explore new features and approaches to solving business problems with software, every week. While a week’s worth of code might seem small, it adds up over time to major changes. Best of all, because organisations are testing features out with real-world feedback, changes are validated with data: software is only getting better.
The beneficiaries of Kubernetes
Developers get the most tangible benefits from Kubernetes. According to VMware’s Kubernetes 2020 report, the top two benefits are improved resource utilisation (56%) and shortened software development cycles (53%). Instead of waiting weeks or months for the simple infrastructure needed, let alone complex clouds to run applications in, developers can now get those environments quickly and through self-service.
Operations equally benefit. Less time is spent on mundane tasks and production is stable and reliable. Once business teams know how to take advantage of a weekly release cycle to test new features, they benefit as well by getting a fast time-to-market, and a tool to evolve the business with validated data.
There are many traditional ways to design and run software. This variability adds extra expense, time and risk to the software process – as years of over-budget, over-schedule and under-featured software shows. Adopting Kubernetes technology in containers may well be the right way forward for your company – just like incorporating kale into your diet may be better for your health. Kubernetes puts in place one way to design and run software, removing waste for you to focus on the actual software, eradicating the hassle of managing it whilst worrying about ever-extending timelines.
From ducks to developers
Implementing containers can take a lot of elbow grease in terms of developer debugging practices, in his position as senior member of technical staff at VMware Tanzu Labs, Derek Lee Boire offers some essential advice for working to apply new technologies at the coalface.
Lee Boire writes from this point forwards…
Lee Boire: Pairing up can be peachy, but duck-out if you feel the need for some rubber love.
Perhaps appearing as an oddity to outsiders, Andrew Hunt and David Thomas’ famous method of rubber duck debugging (RDB) helps developers solve coding problems by explaining them, line by line, to a rubber duck. As a result, developers must not only think about how the problem could be understood by someone without any programming knowledge, but also benefit from the opportunity to simply verbalise the problem that’s been floating so far solely in their minds.
While RDB is a useful way of avoiding workflows being interrupted by developers searching for someone to physically review the code, it also has its drawbacks. For one, developers working in an office or in a public space can understandably feel uncomfortable speaking with inanimate objects for fear of ridicule. Secondly, RDB is more a tool of overcoming psychological barriers for developers, rather than a method of having code reviewed by someone other than yourself.
Pair programming is peachy
Another tried and tested method, pair programming has become a more mainstream method of real-time code.
Two developers, two keyboards and one screen – these are the ingredients of pair programming. With a pair of developers working simultaneously on the same feature, not only do issues such as target fixation melt away, but the quality of code increases significantly as two heads work together to come up with a solution that neither one may have originally foreseen at the outset.
Teams actively employing the practice of pair programming, combined with rotating developers between pairs regularly, understand the benefits of having that domain knowledge shared throughout the team. This enables teams to move quickly when building new features and maintain a predictable velocity.