Following a successful IPO, Elanco is in a unique position to rebuild IT from the ground up, covering the architecture, processes, and people. As a technologist, this is an incredibly exciting opportunity, where the weight of legacy architecture and technical debt is lifted, presenting a clean start to build a modern IT ecosystem.
Where possible, I plan to document this journey, highlighting some of our key architecture and technology decisions. I have already written several articles in this series, which can be viewed below.
This article will focus on our proposed cloud architecture, highlighting our philosophy, key technology decisions, and positioning.
Over the past ten years, the Public Cloud market has seen massive growth. I wrote a short article in 2013, highlighting the dominance of Amazon Web Services (AWS). At the time, AWS was a clear leader, however, the market has matured, resulting in three key players: Amazon Web Services (AWS), Microsoft Azure, and Google Cloud Platform (GCP).
As to which Public Cloud provider is “best” depends on multiple factors, specifically, business requirements, user-base, budget, existing investments and supporting architecture. To simplify the landscape, I often use the LEGO range as a way of describing the differences between the providers.
LEGO = AWS: Like LEGO, AWS is the most popular, with the largest eco-system, highest-rate of innovation and customer engagement. AWS is incredibly versatile, with thousands of services that can be connected to create/support a wide range of solutions. Similar to LEGO, AWS has a strong focus on the eco-system (via its API-Centric strategy), therefore, services tend to target technology-centric customers with software engineering expertise.
DUPLO = Azure: Building on their history as an enterprise-focused company, Microsoft often complement their services with enterprise-specific features. Like DUPLO, the “building blocks” tend to be “larger” and therefore, easier to consume for business-centric customers with limited software engineering expertise. Finally, similar to the connection between DUPLO and LEGO, Azure services are often tightly integrated into the wider Microsoft eco-system (e.g. Office 365).
LEGO Technic = GCP: Google is very much about engineering excellence, with a strong emphasis on custom/proprietary compute, storage and networking architecture (e.g. TPU). Similar to LEGO Technic, Google is often the first to pioneer new/innovative services (e.g. Kubernetes), allowing for the creation of more “exotic” solutions. In regards to market share, Google is in third place, resulting in a more tightly defined eco-system, which attracts customers with a strong appreciation for engineering excellence.
This analogy is far from perfect and is not designed to articulate the value of each provider. It does, however, recognise the different philosophy, target audience and market size of each provider, highlighting that a one-to-one comparison does not tell the full story.
As part of our IT Principles and Declarations, we have defined a clear direction regarding a “Cloud First” strategy, prioritising Public Cloud for applications and data, with a focus on Cloud Native architecture.
The words “Cloud First” are important, as they clearly articulate our direction, but also recognise that we are not “Cloud Only”. This is driven by the realities of our business, which will force us to support workloads that are not commercially or architecturally a good fit for Public Cloud. As a result, we plan to provision multiple highly-converged Colocation Data Centres, as well as support Edge Computing at specific locations (primarily R&D and Manufacturing).
Regarding the Public Cloud itself, we have built our foundational architecture to be provider agnostic, as we anticipate workloads running across multiple clouds. Therefore, it is fair to state that our cloud strategy is “Hybrid Multi-Cloud”.
To ensure efficiency and consistency, we plan to leverage a fully decoupled DevOps Automation layer, supported by techniques and technologies such as “Software Defined” and Infrastructure-as-Code (e.g. Terraform, etc.) I plan to cover our proposed DevOps Automation strategy in a future article.
Although our agnostic approach is highly flexible, supporting any cloud, there are clear commercial benefits to standardisation. As a result, we have selected Microsoft Azure as our preferred Public Cloud provider. This decision can be summarised by two factors:
Although Elanco has a greenfield opportunity from a technology perspective, the company itself is over 50 years old. As a result, we have a human legacy, with t our user-base having a long history using Microsoft productivity and collaboration services. Therefore, Office 365 was a logical decision to ensure business continuity and to help reduce the organisation change management impact. The use of Office 365 opened the door to a wider commercial deal with Microsoft, allowing us to maximise our investment across productivity, collaborations, and cloud.
Recognising that Elanco was previously reliant on Eli Lilly for enterprise IT, we are still growing our technical competency. For example, we have limited Solution Architect and Software Engineering expertise, therefore we are currently dependant on service integrators for solution delivery. Our goal is to rapidly grow our technical competency, enabled through up-skilling and recruitment, as well as key partnerships to provide software engineering horsepower. Recognising our business-centric skill-set, Azure felt like the right fit, with a focus on enterprise outcomes vs. engineering enablement.
With this positioning in mind, the diagram below highlights our proposed hosting patterns, covering SaaS, Public Cloud, Colocation Data Centres, and Edge Computing.
Highly-industrialised/commodity workloads will be positioned for SaaS. Examples would include Productivity, Collaboration, Service Management, Customer Relationship Management (CRM), etc.
Public Cloud will be prioritised for all application/data hosting, emphasising “up the stack” services. For example, FaaS and PaaS will be prioritised over IaaS.
The Colocation Data Centres provide support for workloads that are not commercially or architecturally a good fit for Public Cloud. For example, specialised capabilities from R&D and Manufacturing, which require specific hardware. The Colocation Data Centre architecture will be highly-converged, running VMware Software-Defined Data Centre (SDDC) architecture.
Edge Compute supports latency-sensitive applications, predominantly at R&D and Manufacturing sites. Where possible, these will run in hyper-converged infrastructure, leveraging the same VMware SDDC architecture as the Colocation Data Centres.
In conclusion, we believe our Hybrid Multi-Cloud strategy will provide a strong foundation for the enterprise, emphasising modern architecture, but providing options for almost any workload.
I hope this balance of innovation and pragmatic-design, which will be incentivised via streamlined governance model and budgeting, will push 70% of our workload into the Public Cloud, even targeting areas that have historically been conservative regarding cloud adoption.
A key enabler for the Public Cloud will be our DevOps Automation layer, which I plan to cover in a future article.