Over the past three years Container Solutions has built experience by successfully guiding a range of enterprises into the cloud. Through experimentation and observation, we have distilled the practical process of successful cloud migration into six iterative steps. Some of these steps can occur in somewhat different order, but we have observed -- and some unfortunate enterprise migrations have learned first hand — that step number six (orchestration/Kubernetes) must always be the last one.
Previously we examined each of these six steps in-depth in an earlier post, “When is the WRONG time to use Kubernetes?”. Now we will move through them again, this time through the lens of enterprise organisations that have successfully completed cloud native migrations.
In part one, we will look at the first three migration steps with via the experiences -- and lessons learned -- of these companies as they moved onto the cloud (Step 1), began implementing automation (Step 2), and worked to align internal culture with cloud native philosophy. Next week, in Part 2, we will examine the final three steps in the same manner.
For comprehensive coverage of these cloud native concepts, plus a thorough grounding in fundamental concepts and practices, download the free Container Solutions eBook, Cloud Native Attitude, Part 1.
Step 1: Step to the Cloud, De-risk Infrastructure.
Cloud native migration begins by putting a few machines on AWS or another public cloud hosting platform. This initial step often ends up with companies feeling confused: they moved their infrastructure to the cloud, only to find operating expenses actually went up somewhat.
This is common but also short sighted thinking. The true lesson of step one is risk reduction, not cost reduction. Looking only at hardware expenditures it is true the cost will typically go up. However, cloud native strategies fundamentally shift infrastructure planning from high to low risk. Extremely fast access to flexible, virtual resources that scale effortlessly at need, while only paying for actual resources consumed, mitigates every major traditional infrastructure-related risk. It also significantly reduces the operational load for the enterprise’s technical teams.
Both these factors inspired ASOS, the global eCommerce fashion retailer founded in 2000, to undertake a cloud native migration two years ago. Their major goals were increased feature velocity, improved scalability (to handle spike events like Black Friday sales), and the ever-faster site response times crucial to online sales conversion. The clear path to achieving these was to transition from the ASOS proprietary in-house platform that included in-house, owned and self-managed servers, to cloud hosting. Over two years, ASOS was able to migrate 100 percent of their services from their own data centres to Azure.
A huge benefit of the move was freedom: ASOS technical staff were freed from managing infrastructure and able to focus on features and other areas of direct business advantage. They chose Azure’s “Cloud Services” PaaS to make use of fully managed VMs provided, monitored, patched and supported by Microsoft. ASOS just deploy applications to those VMs, using them as “units of isolation”. This significantly reduced their operational overheads out of the gate -- and so the company went even further, transitioning to fully managed databases (Database-as-a-Service) wherever possible. ASOS now host their own stateful services only when Azure does not offer a fully managed alternative.
Moving to the cloud helped ASOS meet and then exceed their business goals, and 2017’s Black Friday beat all previous records for scale and responsiveness across their applications. ASOS are extremely happy with the progress made by moving infrastructure to the cloud.
Step 2: Automation.
If even small tasks within your tech organisation require manual processes or, even worse, high-friction handovers between multiple parties then considerable cost and elapsed time is added to every project. For example, the developer who writes the code may have to wait days for their comrade on the ops team to provide a test environment. Multiple handovers can easily delay deployment by weeks. This is an area where a Cloud Native strategy could help by automating or simplifying some of the handover processes to reduce friction.
Cloud native brings the ability to take advantage of automation in conjunction with other steps (Microservices/Step 4, Containerization/Step 5) to optimize efficiency and truly maximize product velocity.
ITV plc -- a commercial television network created by the merger of several venerable British TV franchises -- is a major international broadcasting presence. Online, pay & interactive services make up a growing share of their business. To deliver that consumer-facing tech, ITV embarked on an ambitious legacy migration from mainframes to cloud microservices.
After ITV successfully completed Step 1, transferring existing (legacy) code and databases to the cloud, the enterprise decided the next step to increase feature velocity was to try using DevOps for their online products. They experimented with allowing the development teams to provision their own machines for test and production on Amazon Web Services (AWS) through a series of proof of concept (PoC) deployments. These PoCs were a huge success. So, they decided to step back and re-assess their tech strategy once again.
It was clear the combination of Cloud and DevOps could have a significant, positive impact on the speed of development of their consumer facing products, and that ITV should embrace these for online. However, ITV’s legacy internal systems -- like talent payment, content delivery and rights management -- were falling behind. ITV decided the Agile, Cloud and DevOps strategy they had trialled for consumer products needed to be extended to the legacy services their business had relied on for decades.
Having used their digital services to learn and build expertise in the cloud, ITV decided to extend the new infrastructure across their entire organisation. They elected to use a “Common Platform” build on AWS for help with automating product-based development, testing and deployment.
The ultimate result, ITV says, has been so successful that they plan to extend their cloud migration beyond infrastructure and automation to the next step, containers with an open source orchestrator. The process has been a fascinating journey from extreme legacy (50 year old systems!) to cloud native. The full story, along with details from other enterprise case studies discussed here, can be found in the free Container Solutions eBook, The Cloud Native Attitude Part III: Case Studies.
Step 3: Culture.
When embracing the Cloud Native philosophy, companies quickly come to realize it requires a completely different culture to take advantage of the cloud and automation. The traditional model is for organisations to be massively risk averse, to minimise uncertainty at all costs. Ultimately, wholesale risk aversion becomes embedded in the company culture so that it becomes impossible to even recognise the value of reducing risk — much less try experimental approaches that take advantage of them.
Experimental culture is the new low risk. It used to be that “low risk” meant “don’t experiment.” Cloud Native can’t just be bolted on top of existing company culture. An enterprise needs to shift its collective culture and mindset to match: to be ready to constantly iterate, step back, try again and try differently. New ideas, new processes, new products — the goal is to shift from a culture of finding the “right” answer to an open approach to exploring and testing many possible answers.
Early adopters of cloud native, such as the Financial Times, seem to naturally understand, embrace and embody this culture.
Based in London, the newspaper has an average worldwide daily readership of 2.2 million. The FT was a pioneer of content paywalls and was the first mainstream UK newspaper to report earning more from digital subscriptions than print sales. Their forward-thinking desire to use technology to optimize that evolution from print to online publication led the organization to go cloud native.
The seeds of cloud native transformation within an enterprise are often planted internally by a keen technical champion, often a developer inspired to try containers or microservices by a meetup or a conference. Once this person starts playing with the technology internally other engineers see the attraction, particularly for faster software delivery. They run more experiments, get excited and often decide to try bigger projects. Unfortunately, this sort of bottom-up transformational drive founders not because the technology is wrong for the organisation -- but because the organisation is not yet right for the technology.
The FT’s digital transformation was, in fact, explicitly driven by the board. Nearly 10 years ago the execs knew that the physical newspaper business was going to change; unfortunately, no-one really knew what was to come next. At the time, cloud native -- even the cloud itself, really -- barely existed. So it was with impressive long-term vision that the board chose to restructure their organisation to be culturally flexible. (Thus, the cultural change led first -- a valuable lesson for other enterprises seeking to pursue cloud native migrations).
Eventually, technology began to catch up with their forward-thinking philosophy. Over the past three years, The FT have been gradually adopting microservices, continuous delivery, containers and orchestrators.
Sarah Wells, content platform tech lead, called the FT’s three year journey to become a technologically agile cloud native enterprise “a major success.” For other enterprises contemplating that same journey, the organisation is leading by example in many ways -- but particularly on the culture front.
To Be Continued...
Come back next week for a visit to Step 4, Microservices; Step 5 (Containerization) and Step 6 (Orchestration) as we further investigate the experiences of companies who have successfully gone Cloud Native.
Previous article
