Joining the fray
One of the most predictable surprises in the public IaaS market recently has been DigitalOcean’s public launch of their own managed Kubernetes service, at KubeCon Europe last May. In my opinion, it was predictable for at least three reasons. First, customers. DigitalOcean is one of the largest and most prominent public-cloud providers, and an extremely user-focused company. Its users were asking for this capability, so that they could try out Kubernetes on their existing and favorite provider.
Second, competition. Since the announcement of Amazon's EKS and Fargate in late 2017, we've seen a flurry of reaction from what I call "tier 1.5" and "tier-2" providers (compared to the top-3 of AWS, Azure and Google Cloud), such as IBM, Rackspace, Alibaba, T-Systems and literally dozens of others. Not playing this game would be detrimental to any provider's competitive position in this rapidly-consolidating market.
Third, it just makes sense, if you're following this market. IaaS companies build services that help users spin up more machines, and Kubernetes is no different. With an impressive pedigree from Google, a vibrant and strong community in the CNCF, and tailwind from the top-3 clouds, Kubernetes is the dominant container orchestration technology. If your users are writing microservices apps, they'll be using Kubernetes much more often than they will any alternatives.
Cloud 66 ♥ DigitalOcean (as well as all our other cloud provider partners)
Cloud 66 has had a long and fruitful partnership with DigitalOcean. On average, our joint users spin up hundreds of new "Droplets" a month to deploy their Rails, Node, or microservices apps—with many thousands more still running. Many of these joint customers even use Maestro, our own multi-cloud lifecycle management tool, itself backed by Kubernetes.
Is the abundance of managed Kubernetes services good news? Kind of. As we've said in a previous post, if you're a cloud provider who is not enabling users to spin up Kubernetes clusters in 10 minutes through a friendly UI, then most likely another provider will.
More options is a good thing, but in our experience, some of these services are better (more robust, feature-rich, performant) than others—which will be important to production users. Also, a wealth of options is valuable if it helps you get the most out of the Kubernetes promise of portability. In this case, you will need to make sure that you use managed Kubernetes services that don't lock you out of a multi-cloud or hybrid architecture (again, that is where tools like Maestro come in handy).
So yes, it can definitely be good news for the savvy user, but at the same time, it's not really interesting news, because this is ultimately a solved problem, and a distraction from the greater operational challenges embedded into Kubernetes, which we've discussed in this post.
Dev friendly can also be Ops-friendly
While it's great for everyone to have a Kubernetes cluster on their cloud of choice with a few clicks, ultimately it is in an ops-friendly environment (IaaS), while the challenges are how to add a dev-friendly experience to that layer, that operators can trust.
So if managed-public-Kubernetes is a given, what are the next problems? From our experience running thousands of customer workloads on containers, they are mostly around security (container and code vulnerabilities, runtime access, secrets management etc.); lifecycle management (multi-cloud deployment, leveraging stateful workloads, network management etc.); and container pipeline (delivery and deployment).
We've had to solve most of these issues ourselves over the years by developing tools, and have been offering some of them in our container toolchain and our open source products. With regards to the pipeline, your challenges might revolve around things like:
- Building images in a container-native way, with CI tools that understand how your 20 services and 3 databases interact within one app;
- Taking configuration and secrets management out of the developers' hands;
- Curating an easily-maintainable set of configuration files, with version control and role-based access, for both external/off-the-shelf and complex internal services;
- Creating a mechanism for devs to do one-click deployments to multiple Kubernetes environments;
- and much more.
In the end, an operator's job about thinking what will happen when scale comes. What won't scale is bespoke manual processes, reliance on custom tech in a commoditizing market, un-portability, processes that make people wait, rusty knobs that are not fit for the new purpose, or wobbly ones that don’t work first-time, every-time.
What will scale is tested infrastructure, repeatable and reliable automation, self-service for developers that operators can trust, abstracted workload portability, and above all, tools that facilitate the shared world view that Kubernetes mandates.
The latter list has driven our product development since we started Cloud 66, and is embedded into our tooling. Check out Skycap, Maestro and our open source products as the best complement to whatever Kubernetes, hosted or on-prem, you are using.