Every time we guide another enterprise client onto the cloud, Container Solutions gains new experience and insights. We used this knowledge to refine the successful migration process into six steps. Previously, we examined each step in depth in “When is the WRONG time to use Kubernetes?”. We then returned to consider them again in conjunction with case studies from organisations, like the Financial Times and Skyscanner, who have successfully adopted cloud native in production.
Part 1 examined the first three migration steps: moving onto the cloud, implementing automation, and internal culture shift. Now, in Part 2, we will explore the final three steps of a successful cloud migration -- microservices, containerisation, and orchestration -- in conjunction with the experiences of three new companies who have stepped successfully into the cloud.
The free Container Solutions eBook series, Cloud Native Attitude, delves even deeper into the six steps, fundamental cloud native concepts and related case studies.
Step 4: Microservices.
The heart of Cloud Native architecture is regrooming the monolith into smaller chunks. Parallelising team efforts to write code independently and deploy independently. The microservice concept is a deceptively simple one: breaking down complex, multi-purpose -- i.e., monolithic -- applications into small, single-purpose self-contained services.
In theory, microservices are robust, scalable, and easier to develop and update while being cheaper to operate and support.
However, these benefits are not trivial to deliver. How to architect microservices is a difficult thing to get your head around. Microservices can achieve several competing objectives and it’s very important to think carefully about your existing reality and then identify your goal -- or you could end up with a mess. To demonstrate microservices done deliberately and well, let us return to our ASOS case study. Having completed Step 1 by moving their infrastructure to the cloud, ASOS were ready to embrace a Cloud Native-style approach with heavy use of Microservices.
A microservices-oriented architecture on flexible cloud infrastructure has been core to their improved feature velocity. However, ASOS have also sometimes chosen to prioritise other goals. Like FT and Skyscanner, ASOS create their microservices to “do one thing”. Unlike the other two however, in some instances ASOS group, link and deploy multiple microservices as a single process.
The majority of the ASOS estate consists of the more usual discrete services communicating over (typically) REST, but ASOS group and deploy their services together where performance is particularly critical. This improves the responsiveness of these service groups, which is good, but the increased coupling does have a negative impact on ASOS’s agility and ability to change those particular services, which is bad. In most cases, ASOS choose to prioritise agility and feature velocity over performance and therefore they deploy using the more common single-decoupled-microservice model in the majority of cases.
This is a good demonstration that microservice experts still make judgements and balance tradeoffs on how they will implement a Cloud Native approach. This is true even on a service-by-service basis.
Step 5: Containerisation.
Skyscanner is a global travel search site with more than 50 million monthly users. Their self-built technology, which includes websites like www.skyscanner.com and a mobile app, supports over 30 languages and 150 currencies. Skyscanner successfully use some highly advanced Cloud Native strategies in a mixed environment: they have a monolithic core system and a fast-growing range of supplementary microservices, hosted partly on their own servers and part on AWS.
Skyscanner have now been using containers and orchestrators in production for around two years and their new code is generally “Cloud Native” i.e. microservice-based, containerised and orchestrated. The decision to move towards Cloud Native was jointly made between their operations and their development teams and their motivation was increasing deployment frequency and velocity According to visionary ex-Amazon CTO Bryan Dove, Skyscanner’s goal is to “react at the speed of the internet”.
“Back in 2014 we were making around 100 deploys a month. We adopted continuous delivery and that helped us deploy more quickly but it didn’t solve all our problems - developers were still limited by which libraries and frameworks were supported in production,” said Stuart Davidson, head of Skyscanner’s build and deployment teams. “Moving to containerisation plus CD was the game-changer: It increased our deployment rate by a factor of 500. For us, containers were the enabler for cloud native.”
Skyscanner’s goal was to achieve “idea to user inside an afternoon,” Davidson said, adding that they have mostly achieved this: over the past two years, their delivery time has dropped from 6-8 weeks to a few hours.
Intelligent application of Containerisation has also been at the heart of other successful enterprise cloud migrations. Download the free Container Solutions eBook, The Cloud Native Attitude, for more real-life case studies.
Step 6: Orchestration.
A true enterprise-level application will span multiple containers, which must be deployed across multiple server hosts. The containers function within a comprehensive container infrastructure that includes security, networking, storage and other services.
An orchestrator -- such as the popular open source Kubernetes -- deploys the containers, at scale, for required workloads while scheduling them across a cluster while scaling and maintaining them -- all the while integrating everything with the container infrastructure. However, using an orchestrator effectively is a highly complex endeavour; getting that right often depends on the flexibility, speed and ability to iterate you have put in place first. The foundation of Cloud Native is cloud infrastructure (Step 1), automation (Step 2) and an experimental culture (Step 3). All these pieces must be actually be in place before you can start working to effectively orchestrate them.
Starling Bank’s journey to cloud native is an example of getting those pieces in place and waiting to use Kubernetes at the right time. Founded in 2014, Starling are a challenger bank who describe themselves as a “tech business with a banking licence.” Starling’s full service bank accounts are solely accessed from Android and iOS mobile devices.
Starting in 2016, Starling created their core infrastructure on Amazon Web Services (AWS) inside just 12 months. Or, as CTO Greg Hawkins likes to say, “We built a bank in a year”. They use a microservices architecture of independent services interacting via clearly defined APIs. In terms of deployment and operations, whilst services can be deployed individually Starling usually use a simultaneous deployment approach where all services in the backend are deployed at once. This is a trade-off that has evolved between minimising the small amount of overhead around releases and keeping release frequency up.
From the start, the bank used Docker containers as a packaging format, and EC2 instances as their “units of isolation” (i.e. to separate one running service from another). They do not yet use containers as their primary form of isolation, although they do use them to isolate some specific processes such as components of their monitoring application Prometheus. They also don’t currently use an orchestrator. (With one exception: Starling built a rudimentary orchestrator in-house to drive rolling deploys based on version number changes -- scale up AWS, create new services on the new instances, expose those new services instead of the old ones, turn off the old ones and scale down their AWS instances).
However, they are looking closely at Kubernetes. Specifically they are interested in the abstraction it provides to machines and applications, which helps with portability (going cross-cloud) as well as the sophisticated additional deployment options that K8s provides. The cost savings and improved performance they would get from using containers as their units of application isolation and running on larger VM instances are another attraction.
However, Starling have been deliberate in regards to making the final move to Step 6 only when the situation is at last right. Starling have made a strategic decision not to take on the operational overhead of managing Kubernetes themselves on AWS, but they are closely watching the progress of AWS’s managed K8s service (EKS) and are likely to use that in the future once it reaches their required level of functionality and stability.
That is not a crazy decision: there is significant ops work involved in managing Kubernetes on AWS yourself.
Which is exactly what our quick visits to the experiences of these five different early adopters of cloud native have shown. Cloud Native is more than a checklist. It’s an attitude: experimental and iterative, taking it one small, low-risk step at a time -- but taking those steps quickly and nimbly.
Previous article
