The Case for a Single Cloud Investment From an Abstraction Addict

By Bill Salak, CTO of Brainly

Foreword by Thomas Blood, AWS Leader of Digital Innovation in EMEA

As a former Enterprise Strategist and Leader of Digital Innovation in EMEA, I frequently talk to business executives and IT leaders. Leaders sometimes ask me about creating a single-pane-of-glass interface to manage multiple cloud providers. I always tell them that this is not a good idea. Allow me to introduce Bill Salak, the CTO of Brainly, a peer-to-peer learning community. Bill pursued such an abstraction strategy at first, and then changed his mind. Here’s why.

The Case for a Single Cloud Investment From an Abstraction Addict

Hi, my name is Bill Salak, and I’m an abstraction addict.

I’m also the CTO at Brainly, the world’s largest social learning community, with over 150 million users per month and growing.

Today, the tools for abstracting away cloud provider dependence and lock-in are better than they’ve ever been. The promise of these abstractions is the ability to easily migrate traffic and systems over to a new cloud provider. The touted benefits of this are enhanced ability to negotiate costs with cloud vendors, improved disaster recovery via cross-provider fail-over, the ability to cherry-pick the best services from each cloud vendor, and more.

The support for more than one cloud provider is known as a Multi-Cloud Strategy, and as a self-confessed abstraction addict, I was once a practitioner and proponent of this approach. However, not all abstractions are good, and as the term “abstraction addict” implies, abstractions must be used responsibly.

Getting Hooked

I can’t say that I remember my first time using an abstraction, but I can tell you that my addiction started early in my career as a software engineer.

I can hazily recall the rush of those first years, building codebases with cleanly decoupled components, tightly defined interfaces, and lightweight abstractions that allowed for easier refactoring.

I can recall with more clarity the many productive years after that, as I designed abstractions into the interfaces and versioning systems of the public APIs I architected. As my career grew, so did my ability to influence the design of the systems I was working with. As a Software and Systems Architect, I employed abstractions heavily during design and development and relied upon them to ensure forward compatibility as business needs changed and systems were evolved to keep pace.

I May Have a Problem

I can recall with clarity the first time I realized that I might have a problem.

I was heavily using database abstractions at that point in my career, as were most web application engineer/architects. These software-based database abstraction layers generally came with a performance hit in the applications that used them but always with the promise that should one ever need to change databases, the process would be nearly painless. An easy mental tradeoff; of course every system I build will be so popular as to require this scalability challenge to be addressed!

After using software-based database abstraction layers in many (30-plus?) projects, I finally had my first need to actually cash-in on the promise of value. I had a live web application that was pushing the limits of the FOSS database solution we had chosen, and it was time to start paying for one of the big commercial solutions. This was back in the early days of FOSS databases and frankly, there weren’t many good options for high-load and big datasets. Back in those days, it was generally accepted that there was only one database technology that could handle the biggest problems when it came to high-load with big datasets.

To keep a long story short, the result was a self-inflicted disaster. The abstraction layer had held us back from optimizing for our FOSS solution by requiring us to stick to the lowest common denominator in the use of our database’s capabilities. This was done to ensure our ability to “easily” swap out our technology choice when we needed to. This caused our FOSS-based solution to have a lower ceiling for load, and we needed to switch to a new database solution sooner than we would have if we had simply exploited our FOSS choice for all of its native and proprietary capabilities.

When we migrated to the new, more powerful (and expensive) database technology, we initially saw a drop in performance! Ultimately, we had to ditch our abstraction layer and redesign our database schema to take advantage of all of the capabilities of our new technology choice. In short, we had to fully embrace the differences that made this new technology perform at its best.

I learned many lessons from this event, not the least of which is that sometimes it’s better to embrace a choice and invest in it fully than to abstract myself away from it in anticipation of someday needing to switch.

My Second Wake-Up Call

Fast forward to 2016: my career has progressed and I’ve found myself in a position to be the final decision maker/seat-at-the-table-stakeholder regarding IaaS provider selection and strategy at more than a handful of companies.

At this point in my thinking, I’m deeply entrenched in the multi-cloud mindset. My reasoning for supporting this strategy was the same you’ll hear or read anywhere today: cost-hedging, the ability to take advantage of best-in-breed solutions, and avoiding vendor lock-in.

At re:Invent 2016, I had my second wake-up call regarding my abstraction addiction. I had thought I was a responsible abstraction user; I had thought I had kicked the unhealthy part of the habit. But I came away from the conference with a totally different perspective.

The sheer amount of progress, capabilities, and pace of improvement happening in the Amazon Web Services ecosystem was my intervention. Each talk I attended exposed me to emerging and proprietary capabilities within AWS that had real-world value to my teams. It became clear to me that I had been operating at the lowest common denominator in my approach, much as I had many years earlier in my database abstraction strategy. My multi-cloud strategy was a new form of abstraction that was setting me up for a repeat of my previous hard-learned lesson.

Worse than the mental abstraction that had held me back from adopting proprietary, and valuable, services being offered by AWS was my literal investment in software and tooling to ensure cloud provider abstractions for my automated systems—abstractions for systems administration workflows, allowing systems to migrate live traffic between providers, and the necessity of spreading teams thinly across different offerings and technologies—rather than investing to build expert capabilities for a single provider.

The Benefits Weren’t Tangible

My eyes were open and my follow-up research drove the point home: perceived cost benefits were not tangible. Adding up the costs for compliance, audit support, systems administration investments, and loss of efficiency and efficacy by not taking advantage of AWS-specific technologies and capabilities were opportunity costs as well as cash costs.

Assuming teams would select best-in-breed solutions across the supported providers in a multi-cloud environment was never realized. Analysis showed that the teams were shallow in their understanding and expertise because they couldn’t afford to specialize in an environment where specialized features meant violation of portability conventions.

The avoidance of vendor lock-in resulted in avoidance of vendor partnership. Only after leaning into the relationship with AWS were the biggest benefits realized. By committing to and investing in a single cloud provider we were able to take advantage of AWS-specific trainings, support, and reference architectures that heavily supported solutions in the AWS ecosystem.

Today

Today I’m a proponent of a single-cloud investment for all of the reasons I’ve stated here and more. By focusing on AWS alone, my teams have the ability to go deep and stay focused on creating business value. With a well-chosen, fast-moving, innovative partner, I have an extension of my in-house team moving our technology limitations far into the future. I have the ability to develop cost-management solutions tuned very deeply to my chosen provider and to take full advantage of my provider’s offerings and ecosystem.

At the end of the day, I’m not advocating against the multi-cloud strategy; it’s best to be pragmatic about these things and know that in some cases, it will be the best strategy for a build. However, I hope I’ve made a case for other abstraction addicts that a single-cloud investment strategy is a compelling reason to question the addiction and go back to responsible use.

About Brainly

Brainly is the place to learn—for students, by students. We are the world’s largest social learning community, bringing middle school and high school students together, along with parents and teachers, to make learning outside the classroom highly engaging, effective and rewarding. Students connect with their peers to help strengthen their skills, from math to science to history and beyond. Our community is over 150 million users per month and growing!