Cloud-native transformation: containers in the enterprise

A few weeks ago, I attended a talk about moving to microservices, in which the speakers, both of them DevOps program/delivery managers at a large online retailer, mentioned a rule they had. Tooling, they said, was not the answer to a Devops culture problem, but tools can be effective in slowing down or accelerating that very human effort.

This probably resonates well with anyone trying to drive technological change within an organization, and even more so with regards to cloud-native transformation in the enterprise, by which I mean the move to a microservices-based architecture and container-based infrastructure. It’s the right tools, that support the right human expertise, that get the job done.

Take delivering code to production as an example. In the old world (i.e., before containers…), CI tools took code from a repo, delivered an artefact, and then initiated some testing (essentially, using a framework-specific set of commands to execute a user-defined test). Then a set of scripts would configure servers, databases and load balancers would rev up, and off you went. “Simple”, said nobody, ever; that is, at least until containers came along!

Now though, your app is broken down into parts, and those parts move quickly, and by the way, your code still lives in your repo but also in a Docker repo, so they all need complex version control mechanisms, traceability/audit, and orchestration in order to be herded into production.

In delivery, many tools still deliver the same functionality as before, adapted for containers, but this isn’t enough anymore if you want to get from point C (images built) to point Z (production running). What about binding artefacts to the application as services? What about reducing runtime for efficiency but also IP protection? What about automated stop/start and redeployment hooks? What about observability for this complex system?

In deployment, there is a rising class of CaaS tools (see our post here for how that term can be mis-used), but they mostly focus on getting Kubernetes clusters up and running quicker than through a command line. But infrastructure is only as good as its support of the app layer: what about dynamic scaling? What about non-container workloads like databases? What about firewall management? What about control over what gets deployed where?

Cloud 66 has been running containers in production since 2012, so we know what the production issues are. We’ve written a white paper to encapsulate what we think you can consider along this journey to production. If you want to learn more about container-native CI/CD and pipelines, click below.

Lastly, if you’re an SI or MSP, come talk to us in person about your views and experiences at AWS Re:invent in Las Vegas, NV, and Kubecon in Austin, TX. [Contact us](mailto: to book a meeting.

Originally published on the Cloud 66 blog and then on LinkedIn. Reposted with permission.

CaaS: Hope or Hype?

In searching for inspiration for this post, I decided to bottom out an old suspicion of mine. After a brief but brave foray into the meme rabbit holes of the internet, I can confirm that indeed, “Everything-as-a-Service” remains a remarkably under-utilized as a buzzword. Something to strive for, I guess.

A shortage of memes might be behind the proliferation of the “-aaS” suffix in various areas. For example, let’s talk about Containers-as-a-Service, or “CaaS”. If containers are infrastructure, why do we need a new acronym, rather than using IaaS? And if your answer is “because IaaS is for VMs”, then why don’t we have VMaaS for virtual machines, BMaaS for bare metal, ARMaaS for ARM servers, and so forth?

So, is it just marketing hype, of the same variety that promotes “serverless” when most enterprise workloads are not even on the public cloud (yet), and those running on containers in production are just starting to emerge?

Or is one reason that actually, containers are different? It’s great to have these ephemeral little Docker things, but to be usable they need orchestration, and tooling on top that is built-for-purpose, bridges Devs and Ops, and considers the architectural differences between the world of apps until now and microservices. And in this case, what is the scope of a CaaS offering?

For any cloud provider that isn’t in the top-5 bracket, this isn’t necessarily an amusing hypothetical question. As clouds like AWS and GCP add services and capabilities around containers, and expand into verticals and regions that were once strongholds for these regional providers, this becomes existential.

So let’s ask again, more accurately: what could CaaS mean, as an effective competitive tool, for your medium-sized cloud provider? The annoyingly obvious answer is, “it depends” on the provider’s overall competitive strategy and how containers fit into it. I see broadly two approaches.

For some, just having a UI on Kubernetes, or a minimal integration with a variety of open source services, would cover the urgent and visible need. This approach will likely run into problems once your usage goes from an experiment, to production workloads at scale. There’s a reason why Google, the originator of Kubernetes, has a managed offering—they understand the complexity! The top clouds will no doubt be waiting patiently for these scenarios to unfold, taking advantage of the lack of customer added value of this approach.

For other providers, this will be about finding a way to emphasize their USPs. For example:

  • Features that support specific use cases, such as compliance with financial or data sovereignty regulation (this is where I get to namedrop GDPR): e.g., observability, security permissions and firewall management.
  • Functionality that supports/encourages a hybrid environment (multi-tenant/single-tenant/on-prem and server/VM/container): e.g., hosted, dedicated and on-prem installations.
  • Capabilities that don’t just match that of GKE/ACS/ECS, but look to go beyond them.

This is a more thoughtful approach to product strategy in general, and as such, will likely require long-term thinking and commitment from the provider. It will also probably deliver much more value to you, the enterprise user.

Cloud 66 has been running its own stack on containers in production since 2012, and since then we (pragmatically) swapped out our own orchestration engine for Kubernetes. We come from the cloud-native production angle, and have run into many of the problems most enterprises haven’t yet considered. Most importantly for providers, working with partners and providers is core to our strategy.

Find out more about Cloud 66 Skycap, our container-native continuous deployment pipeline, and Cloud 66 Maestro, our application lifecycle management tool, or contact us at

Originally published on the Cloud 66 blog and then on LinkedIn. Reposted with permission.

New beginnings in an exciting growth area

After over three years at Canonical, I’ve decided to join Cloud 66 as VP of Sales & Business Development. I start today!

In a way, this continues my transition from the hardware level, to the operating system, and now to the software that sits on top. Put another way, I moved from server environments, to virtualization, and now to containers.

Working at HP at the beginning of this decade, I powered through the Windows 8 launch and the emergence of cloud-focused form factors such as the Chromebook and the Surface. Wanting to be part of that transition, I looked for software companies on the bleeding edge of cloud.

I was lucky to have been hired into Canonical by Chris Kenyon in mid-2014, and to have had such amazing experiences growing the public cloud business exponentially. Apart from our business achievements, and Ubuntu’s continued dominance in every scale-out architecture, I have to say it’s rare to find a company full of people who, despite being so talented, are generally still so nice to work with.

But I digress. One of the strongest currents in IT in the past few years has been the emergence of containers as a viable alternative to virtualization. But the industry is only at the start of this journey, with not many companies running production. At a risk of contributing to over-use of the vending machine analogy, I like to classify the marketplace this way:

  • Vendors that enable customers to build great shelves, or perhaps you even build the shelves for the customers. In other words, they are focused on container infrastructure, perhaps with a sleek UI/installer, but not on the app. Still a fragmented and not very enterprise-y space with lots of DIY-stacks. Devs rejoice; Ops worry.
  • Vendors that deliver a fully-stocked vending machine to customers, leaving them no choice in what gets sold through it. In other words, these are the highly opinionated/structured PaaS vendors, as well as GKE, ECS, and ACS. Devs feel constrained; Ops might worry about lock-in but hey, at least the thing runs reliably.
  • Vendors that deliver machines continuously specified by Ops, used by Devs, and managed by the vendors. In other words, this isn’t just about bringing up clusters, but also about how to deploy apps to that infra, and how to keep it all running intelligently at scale—with native databases, networking, firewall options and a good balance of flexibility and governance. This is what will need to happen for Kubernetes to be the new vSphere. This is where Cloud 66 shines.

At Cloud 66, KhashVic and their team have been providing solutions for this problem for years, and with the end-to-end container stack of Cloud 66 Skycap and Cloud 66 Maestro, backed by Kubernetes, I believe we are positioned extremely well to accelerate container adoption in production, at scale, in the enterprise. We will be looking for partners on this journey:

  • System Integrators and Cloud/DevOps Consultancies that want to complement their services with a proven product set.
  • IaaS providers who want to add an integrated, feature-rich container engine to their compute business.

Contact us at, or DM me on LinkedIn. Request a demo here!

Original post