Should development firms support multiple clouds for their serverless client projects?

I’ve talked before about how establishing a serverless capability is especially advantageous for software services agencies/dev shops. Your company builds and supports a serverless application for a client company, and you both get to reap the rewards of the faster time to market and lower ongoing costs.

Today I want to explore whether it makes sense for you, as a solutions provider, to offer the capability of building a serverless solution on different clouds (AWS, Azure, GCP). To be clear, I’m not talking about building a single multicloud application using services from different providers to mitigate dependency on any single one. Rather, I mean the ability to decide on which cloud to build a particular client’s application on a case-by-case basis.

Impact to your firm of supporting multiple clouds

Before we cover the reasons why you might want the ability to choose between clouds for your client solutions, let’s first look at what this would involve for your company.

Let’s say you want to support both Azure and AWS. The main impact is that your engineering team will need the skillset to work in both of these clouds. While this has been a point of debate since the early days of cloud, the issue is even more pronounced with serverless solutions. If you’re building a container-based architecture, most concepts will stay consistent across providers. But with serverless, services are more heterogeneous, requiring more provider-specific knowledge.

You could approach this by having two separate teams, one specialising in each provider. This would mean that you should still be able to hire specialists with deep knowledge in one. But it also makes your project resourcing difficult. If 90% of your projects are on AWS, how are you going to keep the Azure team busy?

The alternative is to establish a single pool of cloud polyglots who are comfortable working in either environment. This will come at the cost of productivity and hireability though. Finding engineers with significant experience in multiple clouds will be more difficult and they may end up having to get up-to-speed after they’re hired.

Another point to consider is that many developers like to specialise — whether that’s in a particular programming language or cloud stack — and asking them to move to a new project on a different stack after getting productive in one can be frustrating.

Some tools (e.g. the Serverless Framework) do support multiple clouds and offer some level of familiarity, but cross-cloud abstractions can be leaky and it’s often more prudent to just use the platform’s native tools/APIs, etc.

Why should your firm support multiple clouds?

Here are a few reasons why you might consider this:

1. To hedge your business against the longer term fortunes of any single cloud provider.
2. A specific technical requirement can only be achieved with a service only available from one provider.
3. Some clients/prospects voice a preference for a particular cloud provider (or a dislike of one) during the sales process.

Let’s address each of these individually. I’m going to assume your firm already has a single cloud provider that you build most/all of your projects on.

As a strategic hedge

The arguments against going all-in with a single cloud provider as a dev agency are similar to those around vendor lock-in concerns of using serverless to build a single solution. What happens if this provider’s service degrades, prices increase, starts behaving morally reprehensibly? If any of these happens, how would you migrate away from them and what would be the cost of doing so?

The difference in the case of a dev agency is that it’s your engineers’ skillsets that are being “locked” to a particular cloud over the course of multiple client projects. If the time comes that you deem your current single cloud provider to be somewhat of a liability to your business in terms of the delivery (and/or sales) of your client projects, then you need to invest in cross-skilling your team in a new cloud environment.

Is this potential future cost sufficiently damaging to warrant adopting a multicloud strategy today?

For a particular feature or service

So maybe you’re working on a client project that requires a specialised service that one of the particular providers is considered best-of-breed for. Say for example, you normally build on AWS, but want to use GCP for machine learning. In this case, you may decide that the significant advantages of keeping an entire solution within a single cloud provider warrant using GCP for everything, not just the machine learning part. Or you could simply treat machine learning as a third party service to be integrated with, and keep the rest of the architecture within AWS.

Prospective client prefers/insists on a specific provider

This point is a harder one to navigate as it goes to the sales rather than the delivery aspect of your business. The concern is that, by only building solutions on one cloud provider, you will lose sales of picky clients.

As the development expert party in the relationship, it can be frustrating to have your technologies or tools dictated to you. Nevertheless, these objections do exist and many have a valid business motivation.

Your first step should be to listen and (gently) push back on the client in order get a proper understanding of where they’re coming from. Are their concerns well founded? Is there an unstated underlying concern about a particular aspect of a vendor that you could mitigate in a different way that doesn’t involve using a different cloud provider for the entire solution?

If the prospect is not for budging, you have a few options:

• Say no, and pass on the business.
• Do it as a one-off. Maybe you need the revenue or there is another strategic advantage to winning the project. Just remember though, this project will still need to be supported in the long term. In 2 years from now, who in your team will have the skills (or desire) to maintain it?
• Do it and build a capability for the new cloud provider. This might make sense if you’re in a market where a large proportion of your prospects have an existing relationship with a particular vendor or actively avoid a particular one. But if this is the case, why not just switch all your new projects over to the new cloud provider?

Always bring it back to focus

If “focus is the why of serverless”, then by adopting serverless your firm is already at a significant advantage. You’ve chosen to prioritise delivering business value to your clients and their users.

But by choosing to establish a multi-cloud capability in your firm, you are giving up a lot of this advantage. Your team’s focus gets dispersed into tasks such as resourcing, hiring and context switching. Simply put, you will not be able to deliver projects as fast and with the same quality levels as you do with a single provider focus.

— Paul