When a new client comes to Container Solutions, the very first thing we do is take them through the CS Cloud Migration Maturity Matrix. The Maturity Matrix is a custom tool to analyse and describe organisational status in order to design a custom migration roadmap. We use it to create an accurate snapshot of an enterprise along nine different axes, including architecture, infrastructure, culture and product/service design and delivery. Every axis contains a spectrum of “stages” that range from no process (single server infrastructure, manual provisioning) to cloud native ready (hybrid cloud, Kubernetes) -- and beyond. All points are constantly re-assessed as the migration progresses, with ever-fresh data allowing us to customise transformation goals and monitor progress while keeping watch for problem areas and sticking points.
Our previous blog post explored the Maturity Matrix itself in depth, and now we will look at some cloud migration case studies from real-world companies to see practical examples of each axis. For a more detailed view and the full story on each, you can download our free e-Book The Cloud Native Attitude: Case Studies
Culture is typically the most difficult axis to assess and progress because it is the most abstract, and the slowest to change. All the successful cloud migrations I have seen, both internally at CS and in the wild, were all led from the top. In each case, the decision was made at the board level to make the entire organization more experimental, the culture and mindset you need to have in place for cloud native. It is important to bear in mind that an enterprise is comprised of human beings as well as technology, so the Culture axis addresses this human aspect of the transformation.
Nearly ten years ago, the executives at The Financial Times of London recognized that the physical newspaper business model was declining -- but no one really knew what would replace it. The FT’s board decided the company needed a complete restructuring to survive; at the time, the decision was not to be cloud native, but to be culturally flexible and ready to respond to whatever came next. In fact, cloud native technology barely existed when they started, and so early on they even attempted to build their own cloud (they eventually landed on AWS).
A decade later, the FInancial TImes is recognized as a pioneer in digital publishing. Key to the FT’s fully successful transformation was the organization-wide acceptance of a certain amount of uncertainty and risk -- things traditional corporate culture strives mightily to avoid -- as part of the journey. They mitigated these by making incremental but constant steps as part of a deliberate plan to transform into a technologically agile company. A plan that was embraced fully and responsively at every level of the organization. The FT’s move to the cloud was as much an enterprise-wide culture shift as it was a technical one.
The cloud native case study for ITV illustrates another venerable media entity remaking itself in order to remain relevant in a rapidly evolving marketplace. ITV (formed by the early 21st century merger of several independent British television franchises) recognized that the key to survival lay in feature velocity-- i.e., rapid delivery of entertainment products in a robust online environment, and on an increasing number of platforms.
ITV’s first step into the cloud came with the creation of ITV Hub, their video streaming service. The company had been running on legacy technology, but for this major step into the competitive world of consumer-facing tech they first built faster Agile processes into their service design. This was quickly followed by using DevOps which, in combination with cloud services, significantly sped up the development of online platforms and products. With and end result that was, said Head of Common Platform Tom Clark, “As iterative and fast as we intended.”
In the cloud native world, every team member can manage at least part of every project responsibility -- for example, a designer can also train to provision a machine. This is DevOps/SRE, a radical shift from traditional hierarchical organisation structure where instructions came from the top down to specific experts.
Skyscanner, the global travel search site, was founded in 2003. The company made the move to cloud native as a means of keeping ahead of the competition in a crowded field, and their team structure reflects this forward thinking attitude. Skyscanner’s developers drive and test their own releases, and the company has further empowered their devs by granting them certain ops team authority. For example, to shift the burden of constant upgrading of the latest library versions in the build system and production instances off of Ops’ shoulders, developers can now bundle their chosen environment into their production deployments using containerisation.
Embracing this responsive and decentralized team structure helped Skyscanner increase their deployment speed 500-fold. Details about their specific cloud native choices and strategies can be found in the free eBook.
In the old world, we had the luxury of a lot of knowns. We planned things up front, then executed that plan, and didn’t change much after -- the Waterfall stage of Process evolution. Agile shortened the product iteration cycle to weeks instead of months or even years -- but this still is not fast enough. In Cloud Native, developers need Process in place that allows them independence as well as the ability to deliver every day.
Starling Bank -- the mobile-only challenger bank founded in 2014 -- was essentially born cloud native. They created their core process on AWS in 2016, and adopted a CI/CD deployment approach for operations where all backend services are deployed to production four to five times per day.
This is the point on the Maturity Matrix to examine whether an enterprise is a Monolith or Microservices driven.
We continue looking at Starling Bank as an example of the need to consider context when making architectural choices, and that not every enterprise needs to make identical choices for their cloud native migration.
Starling currently use a microservices architecture of independent services interacting via clearly defined APIs. Many companies take a Conway’s Law architectural approach of assigning responsibility for specific microservices to designated teams. Starling, however have chosen to assign services by functional responsibility rather than team so that any service can be developed on by multiple teams. This fits the organization’s relatively small size and culture of innovation, which allows Starling to reconfigure very quickly and responsively. Larger enterprises, or those starting from an existing monolithic architecture (not always a bad thing) often benefit from smaller microservices and a more Conway-like model.
Comprehensive maintenance is an absolute necessity for Cloud Native. The complexity of distributed systems demands intelligent, responsive monitoring that looks after itself. Too many companies still rely on ad-hoc monitoring -- i.e., going in to take a look to make sure the server is up and what the response time might be.
Cloud native platform providers these days take on much of the monitoring and maintenance load, thankfully. The Financial Times, for example, run large Docker containerised instances on AWS, and this allows them to replace traditional pre-deployment acceptance testing with automated monitoring in production. Yet another benefit of releasing small changes more often with microservices, of course, but doing this also moved the FT from a 20% deployment rollback rate to ~0.1% (reducing their error rate by two orders of magnitude).
The Delivery axis measures an enterprise’s ability to roll out deployments in terms of speed and automation, from traditional Major Version releases to Monthly, to the cloud native goal of Continuous Integration and Continuous Delivery.
The order of introduction for CI/CD on the Delivery axis, with regard to other Maturity Matrix axes, is particularly vital. We typically look to move to CI/CD as early as possible in a client migration, building a base for quick introduction of changes and for experimentation that accelerate the other areas of effort. In fact CI/CD is so essential to cloud native architecture that every enterprise we interviewed for our “lessons learned” case studies implemented a CI/CD pipeline and automated testing to accelerate development speed. These enterprises’ implementations otherwise varied in many other ways -- just not this one.
These closely related axes deal with how -- and how quickly -- your organization creates new infrastructure/machines and then deploys everything, how you control things, and how automated the whole process is.
Zoover, an up-and-coming travel booking site, came to Container Solutions for help completing a cloud migration that had run into difficulties. The absence of an automated process, coupled with lack of experience, had stalled their progress. We used the Maturity Matrix to map their situation and began getting Zoover moving again. Zoover’s small operations team needed to focus on features, not infrastructure, and a managed solution was in order. We helped them build new a production environment using Google’s hosted version of Kubernetes (GKE), with a Continuous Delivery pipeline based around CircleCI and Google Stackdriver for monitoring.
With this infrastructure in place, Zoover could easily operate within, not to mention maintain, their own cloud native environment. All while removing friction from their development process -- and significantly reducing operating costs.
Zoover’s case is an example of how Container Solutions specialize in not only delivering full cloud native migrations, but unblocking stalled ones. Every enterprise that comes to us is ready to move to the cloud, or at least interested. Each one is also the living result of a unique combination of real-world factors that will influence and drive -- or possibly sink -- the transition.
Our first step is always to apply the Maturity Matrix to gain a precise overview of their situation, and then use the data to build an effective, and swift, migration.