EA Principles Series: Maximize Cloud First
A few weeks back, we shared about how our Enterprise Architecture practice works at Chick-fil-A. We got a few requests to share more about our principles, and specifically focus on how we navigate some of the associated tradeoffs. This is part one of a seven-part series as we expound on each of our Architectural principles in greater detail.
Distilling Requirements from Opinions
Our Enterprise Architecture team is filled with some amazing people with a ton of industry experience. With those experiences come a lot of opinions about how to do things best, which we frequently share across our product, engineering, and business leadership teams.
As our company and EA practice have grown, we were faced with a question: What things are truly non-negotiable, and what things are simply our opinions? If we are honest with ourselves, we have probably pushed both of these things equally and gotten ourselves into seemingly existential debates on things that simply were not so, and thus created frustration for ourselves and those we serve. Not to mention that we are a small team that does not have nearly enough capacity to engage in everything our business is doing.
How can we give ourselves, and our organization, clarity on what is required verse our opinions that can be followed, or not?
The Preamble
All teams should adhere to Enterprise Architecture principles so that we maximize our overall organizational ability to grow while balancing velocity and health.
Sometimes we will need to go a little slower now to go much faster later (the flywheel effect).
We set up our principles by simply stating that our goal is about business growth while balancing velocity and health, both of which are important to maximizing the long-term value we get from technology in our business.
Principle: Maximize Cloud First
The first principle we will unpack is what we call “Maximize Cloud First”. This principle is about how we build and operate software at Chick-fil-A. Here is our verbatim:
Systems at Chick-fil-A should be built in a “Cloud First” manner. We promote the use of “higher order cloud services”, such as AWS DynamoDB, AWS RDS, or AWS S3, to minimize the “undifferentiated heavy lifting” that Chick-fil-A has to do.
When building applications in the cloud, we encourage use of containers for any application that will be run on Chick-fil-A managed infrastructure (usually to be run in our Kubernetes platform). Teams should only deploy applications to an approved Cloud provider.
Why? This allows us to maximize time and attention on features that benefit our business while allowing cloud providers to innovate on infrastructure and foundational services that we can benefit from. Chick-fil-A will never keep pace with the level of innovation of cloud providers on infrastructure services or support/maintenance, nor should we.
Commentary and Tradeoffs
What are the goals of the principle?
Outcome 1: Encourage the use of value-add cloud services
First, we want to encourage teams to leverage the value-add services of cloud providers. We do not want to use a least common denominator, cloud-generic, “multi-cloud ready” approach because we believe the lost value of outsourcing the “undifferentiated heavy lifting” associated in doing so is not a justifiable tradeoff.
The places where we decide to use an open source or third-party product are less about their cloud-agnostic capability and more about their features, surrounding ecosystem, and overall value add. Some examples of tools that we currently use or or considering using are Kubernetes (though we do use AWS EKS behind our platform) and Terraform.
Outcome 2: Encourage the use of containers for application deployments
Our default way to build applications is using containers. There are many other places across the internet to read about the benefits of doing so. In most cases, we push teams to put their containers in our CFA Application Platform, which is Kubernetes-based (we talked a bit about that here). That platform started VERY highly decentralized in nature, and is moving to a more consolidated, fewer-bigger-clusters approach (but still multiple production clusters divided along some logical business boundaries).
We do make tradeoffs here. Some of our teams have built systems or integrations using Serverless technologies. In some cases (especially for event-based integrations) this makes a lot of sense and we do not force compliance. To the previous point in Outcome 1, there may be cases where we can use a cloud-provider service instead of running it in K8s ourselves. There is no hard and fast rule about what is good / bad here… so we often weigh in with opinion but do not force an approach.
For business applications, we highly recommend the containerized approach. We continue to look at application deployment platforms are are seeking to further simplify what we already do, so we will likely have some additional options within this domain (still likely containerized) in the future.
Outcome 3: Require the use of an approved cloud provider
Our investments in our primary cloud provider (AWS) have been substantial. We spent a lot of time, energy, and money in building out numerous security, identity, audit, billing, etc. tools to help us operate efficiently and effectively. Our application platform is based on AWS technologies.
Today, we only allow the use of one cloud provider for building custom software internally. This removes the need for a huge investment to onboard a second cloud provider, and allows us to continue to run our “use cloud-provider services” play by developing a shared internal expertise on AWS services. If we added another cloud provider, we would have to develop organizational expertise in far more services, which we do not have the capacity to do without losing a lot of our velocity (not to mention internal portability of engineers across teams which is easier with a semi-common technology foundation).
We do also have footprints in numerous other clouds for varying reasons (ERP hosting, Email/Productivity, best-in-class APIs, etc).
We acknowledge we are making a tradeoff here — each cloud provider tends to have areas where they excel beyond the mean. We love to use what’s best but have to acknowledge that the tradeoff in doing so can’t always be justified from a business perspective.
This will likely draw questions about availability of services with an “all-in-single-cloud” approach. We believe our availability with a multi-zone, and when necessary multi-region solution is sufficient for our current business needs. Should that change in the future, we will consider adapting our cloud strategy, and this principle along with it. However, a change in that strategy has numerous ripple effects in terms of how applications are built and what investments are needed, so we would not make it lightly.
Conclusion
In conclusion, what is truly required? Using the cloud (vs legacy managed data center) for new applications and doing so with an approved cloud provider.
Generally, we want our EA principles to be long-lived. As our business grows and changes and the technology landscape changes, its possible we could make changes to this principle as well — perhaps if we decide it is right to embrace multi-cloud or add additional application platform options. This is a principle that I would consider to have a moderate-level likelihood of doing so. For now, this is how we build custom applications at Chick-fil-A.
We have been living by this principle (more-or-less) at Chick-fil-A for the last six years. I hope this post helps explain our rationale for how we maximize business value from the capabilities of the cloud, and how we manage nuance around this architecture principal. Follow us here on Medium if you’d like to see the rest of our series over the next several weeks.
