rt to look like “serverless”, where there is a shift in focus away from individual servers and more towards distributed computing.</p><p id="52cf">My complexity rating level is: high to very high.</p><p id="a829">Pros:</p><ul><li>Over 100 independent service providers are certified to provide paid support</li><li>Computers join a pool compute and are workloads are scheduled according to capacity and load</li><li>Dozens of paid products and open source projects exist in the ecosystem to address: storage, networking, security, governance and more</li><li>In 2020 over a dozen local Kubernetes solutions exist for Windows/Mac and Linux. Every self-respecting IaaS/cloud vendor has a managed K8s offering.</li><li>It can even be run at the edge on low-end hardware such as Raspberry Pi using Rancher’s k3s distribution</li><li>It is possible to extend and customize Kubernetes heavily</li></ul><p id="c0b3">Cons:</p>
<figure id="3953">
<div>
<div>
<img class="ratio" src="http://placehold.it/16x9">
<iframe class="" src="https://cdn.embedly.com/widgets/media.html?type=text%2Fhtml&key=a19fcc184b9711e1b4764040d3dc5c07&schema=twitter&url=https%3A//twitter.com/alexellisuk/status/1234902965695197186&image=https%3A//i.embed.ly/1/image%3Furl%3Dhttps%253A%252F%252Fpbs.twimg.com%252Fprofile_images%252F1134783444079259648%252FlP1sBvo1_400x400.png%26key%3Da19fcc184b9711e1b4764040d3dc5c07" allowfullscreen="" frameborder="0" height="281" width="500">
</div>
</div>
</figure></iframe></div></div></figure><ul><li>Many teams are scared of Kubernetes due to its reputation for being complex, others are stuck on last-gen technology because it appears to still work.</li><li>Some are just not willing to try Kubernetes because the ecosystem is so broad and that causes confusion</li><li>It’s not trivial to operate Kubernetes and customizations are difficult to maintain due to breaking changes in the APIs</li></ul><h2 id="e104">Where are you in this journey?</h2><p id="8e56">The CNCF defined a Cloud Native “trail” to help companies navigate the ecosystem that has been developed around cloud, containers, and Kubernetes.</p><figure id="8a65"><img src="https://cdn-images-1.readmedium.com/v2/resize:fit:800/1*e-Bjh5SA0hXE34RsHfaOOA.png"><figcaption><a href="https://github.com/cncf/trailmap/blob/master/CNCF_TrailMap_latest.png">CNCF’s TrailMap</a></figcaption></figure><p id="aaec">You’ll note that the journey begins with containers, and it would be great if we could all start there, but as noted, some teams will benefit from moving workloads to the cloud. Application frameworks and stacks such as LAMP and Ruby on Rails can be deployed to the managed cloud and scaled without containers. There are also managed services such as AWS Lambda, which do not require any containerization to be exploited, but which come with their own set of tradeoffs.</p><p id="d08a">Other teams that have already built-up muscle memory around deploying applications to the cloud, maybe ready for containerization and should spend time getting comfortable here. It may be as far as you need to go for the time being. I recently launched
Options
the <a href="https://github.com/openfaas/faasd">“faasd” project</a> which combines several of the key technologies used in upstream Kubernetes such as CNI and containers to provide a “Serverless” deployment model for APIs, websites and async processing.</p><p id="11d6">When static scaling of your workloads becomes a pain point, and you need more advanced capabilities around storage, networking, governance, and security, it may be time to consider Kubernetes. But beware, there be dragons. You may benefit from an application stack akin to <a href="https://en.wikipedia.org/wiki/LAMP_(software_bundle)">LAMP</a> or <a href="https://rubyonrails.org">Ruby on Rails</a>, but for Kubernetes. For me, that was the <a href="https://www.openfaas.com/blog/plonk-stack/">PLONK stack — Prometheus, Linux/Linkerd, OpenFaaS, NATS and Kubernetes</a>. For you, it may be something else, but it is worth thinking through whether you want to deal with low-level configuration files and toolings like <a href="https://helm.sh/">Helm</a>, or higher-level concepts such as “services”, “secrets” and “auto-scaling”.</p><p id="705d">In conclusion, I believe there are benefits to using the cloud (whether private, hybrid or public), containers and to Kubernetes. The more these are compounded together, the greater the complexity, but the greater the potential.</p><blockquote id="57d4"><p>So yes, you may not actually need Kubernetes, yet.</p></blockquote><p id="825a"><a href="https://twitter.com/alexellisuk/">Connect with me on Twitter </a>and subscribe to my <a href="https://www.alexellis.io/">premium newsletter at alexellis.io</a> if you’d like to read more content on Cloud Native, containers and Kubernetes.</p><p id="7999">You may like some of my other recent stories about Kubernetes:</p><ul><li><a href="https://readmedium.com/5-tips-for-troubleshooting-apps-on-kubernetes-835b6b539c24">5 tips for troubleshooting apps on Kubernetes</a></li><li><a href="https://readmedium.com/deploy-your-first-serverless-function-to-kubernetes-232307f7b0a9">Deploy your first Serverless Function to Kubernetes</a></li><li><a href="https://readmedium.com/kubernetes-apps-the-easy-way-f06d9e5cad3c">Kubernetes apps, the easy way 😎</a></li></ul><figure id="1ef4"><img src="https://cdn-images-1.readmedium.com/v2/resize:fit:800/0*Piks8Tu6xUYpF4DU"><figcaption></figcaption></figure><p id="9b5e"><b>Follow us on <a href="https://twitter.com/joinfaun">Twitter</a> </b>🐦<b> and <a href="https://www.facebook.com/faun.dev/">Facebook</a> </b>👥<b> and <a href="https://instagram.com/fauncommunity/">Instagram</a> </b>📷 <b>and join our <a href="https://www.facebook.com/groups/364904580892967/">Facebook</a> and <a href="https://www.linkedin.com/company/faundev">Linkedin</a> Groups </b>💬<b>.</b></p><p id="c972"><b>To join our community Slack team chat </b>🗣️ <b>read our weekly Faun topics </b>🗞️,<b> and connect with the community </b>📣<b> click here⬇</b></p><figure id="95c8"><img src="https://cdn-images-1.readmedium.com/v2/resize:fit:800/1*6P3WpLjGv5v1ucm5dgkucg.png"><figcaption></figcaption></figure><h2 id="3062">If this post was helpful, please click the clap 👏 button below a few times to show your support for the author! ⬇</h2></article></body>
Your team might not need Kubernetes
For some teams, Kubernetes is the new hotness, a must-have — either because of bottom-up pressure (developers want to play with cool tech) or from top-down — because your CIO heard that it will solve all your problems. You may not actually need Kubernetes.
It turns out that just moving an existing solution to the cloud doesn’t automatically fix inherent issues in its design (who would have known?) There are however some benefits, so let’s look at a stepped approach to technology vs complexity.
Move to the cloud
On the continuum, moving some applications to the cloud can leverage benefits without a large up-front investment.
My complexity rating level is: low to average.
Pros:
Easy to get redundancy and cheap to start — compare the up-front cost of 10 EC2 instances vs 2x Dell PowerEdge servers.
Elastic capacity means it’s easier to handle spikes and simple to bring on new hardware
Managed services, dashboards for visibility and built-in compliance for SSO/audit trail
Cons:
Unpredictable spend, many SaaS services start low and ramp up exponentially, according to usage
Requires expertise in cloud automation, often using APIs specific to a single vendor
Move to containers
The use of containers can standardize a bespoke, complex build and deployment pipeline into something that is easier to maintain.
My complexity rating level is average.
Pros:
Docker’s motto of “Build, ship, run” does check out, you build an image, ship it efficiently by only moving the delta of its layers and then deploy it to a machine
Developer-friendly
Repeatable build artifacts for local dev, CI, staging, and production
Widely used and recommended by ThoughtWorks to avoid or reduce vendor lock-in
Can be used to bring a Linux-style development environment to Windows users in enterprise IT
Local builds with Docker can be slow, and difficult to optimize
Elastic scaling requires additional software such as Kubernetes
Move to Kubernetes
Many teams will move to Kubernetes without first evaluating “cloud” and “containers”. Generally, both are beneficial when adopting Kubernetes, but not strictly required.
Kubernetes brings clustering to containers and when run on a managed cloud can start to look like “serverless”, where there is a shift in focus away from individual servers and more towards distributed computing.
My complexity rating level is: high to very high.
Pros:
Over 100 independent service providers are certified to provide paid support
Computers join a pool compute and are workloads are scheduled according to capacity and load
Dozens of paid products and open source projects exist in the ecosystem to address: storage, networking, security, governance and more
In 2020 over a dozen local Kubernetes solutions exist for Windows/Mac and Linux. Every self-respecting IaaS/cloud vendor has a managed K8s offering.
It can even be run at the edge on low-end hardware such as Raspberry Pi using Rancher’s k3s distribution
It is possible to extend and customize Kubernetes heavily
Cons:
Many teams are scared of Kubernetes due to its reputation for being complex, others are stuck on last-gen technology because it appears to still work.
Some are just not willing to try Kubernetes because the ecosystem is so broad and that causes confusion
It’s not trivial to operate Kubernetes and customizations are difficult to maintain due to breaking changes in the APIs
Where are you in this journey?
The CNCF defined a Cloud Native “trail” to help companies navigate the ecosystem that has been developed around cloud, containers, and Kubernetes.
You’ll note that the journey begins with containers, and it would be great if we could all start there, but as noted, some teams will benefit from moving workloads to the cloud. Application frameworks and stacks such as LAMP and Ruby on Rails can be deployed to the managed cloud and scaled without containers. There are also managed services such as AWS Lambda, which do not require any containerization to be exploited, but which come with their own set of tradeoffs.
Other teams that have already built-up muscle memory around deploying applications to the cloud, maybe ready for containerization and should spend time getting comfortable here. It may be as far as you need to go for the time being. I recently launched the “faasd” project which combines several of the key technologies used in upstream Kubernetes such as CNI and containers to provide a “Serverless” deployment model for APIs, websites and async processing.
When static scaling of your workloads becomes a pain point, and you need more advanced capabilities around storage, networking, governance, and security, it may be time to consider Kubernetes. But beware, there be dragons. You may benefit from an application stack akin to LAMP or Ruby on Rails, but for Kubernetes. For me, that was the PLONK stack — Prometheus, Linux/Linkerd, OpenFaaS, NATS and Kubernetes. For you, it may be something else, but it is worth thinking through whether you want to deal with low-level configuration files and toolings like Helm, or higher-level concepts such as “services”, “secrets” and “auto-scaling”.
In conclusion, I believe there are benefits to using the cloud (whether private, hybrid or public), containers and to Kubernetes. The more these are compounded together, the greater the complexity, but the greater the potential.
So yes, you may not actually need Kubernetes, yet.