Which cloud is better – Azure or AWS?

Ever come across the question, which cloud is better? It is a common question and the answer is not that easy. The battle for cloud dominance is a fierce 3-way race among AWS, Azure, and Google. The consultant does say “it depends” and this answer does not get you anywhere in the first place. In coming up to an answer, there are three areas you need to explore.

• Ecosystem
• Scope
• Capabilities

Before we dive into these areas let me clarify that this post is not about how to decide which application should go to the cloud and to which degree (cloud hosted, cloud container, cloud native). You should drive these decisions based on your cloud strategy and a deep workload assessment.

Ecosystem

It makes a huge difference whether you act in an existing ecosystem like an established enterprise or a new environment like a startup.

In the latter situation, though your ecosystem considerations are along the same lines as in the established one, you define what you want rather than being bogged down by what is already there. So, let’s look at the more complex established enterprise.

The ecosystem consists of your existing environment in the first place. This ranges from geography of your offices and your customers to how you have implemented you current IT, e.g. IAM (Identity and Access Management). In no case, the whole established ecosystem can and will be replaced. So how does that impact the decision of choosing a cloud service provider?

It appears rather simple. If you need services in country A and only provider X offers these, then the decision may seem simple. But as a matter of fact, it is not. Cloud providers cover the same geos and we need to look at the next layer in the ecosystem. In many cases, I meet customers who have taken a strategic decision to work with a software vendor and have created their ecosystem or essential parts of that ecosystem based on this.

Example 1: Microsoft ecosystem

An existing Microsoft technology based on-premises ecosystem, from IAM through software distribution to software development tools and business applications, will fit more easily with a Microsoft-based cloud. Knowledge of the technologies, an existing relationship with the vendor and an established partner landscape that knows the provider well are all available. So, the hook-up and the evolution to cloud-based services is easy.

Example 2: Oracle investment

A core element of sticking to an ecosystem is previous investment in licenses. I have met customers who have clearly expressed their unhappiness with a software vendor over licensing issues and blocking the use of cloud. Nevertheless, the change away from a technology is deemed too risky and not optimizing the existing investment is too painful. As a result, enterprises stick to their technology.

I have not seen anybody moving to Oracle cloud who has not been invested into Oracle before. It is a great example for an ecosystem play.

An existing ecosystem can drive your decision for a cloud provider and needs to be considered. It is though not the only driver for a cloud provider decision.

Scope

You need to know what is in it!

And what is more important — you need to know what you want. The sourcing advisor in me is pushing to start working with you on requirements lists and matching these to the service descriptions and technologies. But the cloud evangelist in me is pushing back and says, “You just have to get started, try it, no upfront investment”.

They are both right and the challenge now is to find the right mix.

In doing so, we need to be clear about the differences in cloud provisioning. The truth is that on basic cloud services, compute, storage and often database, there is no major difference between the main cloud providers and their services on a technical level. If you just go for an IaaS approach and move virtual machines from on premises to the cloud, criteria like the ecosystem are more important.

Requirement groups to check for in any case are:

• Network capabilities
• Price models (e.g., hourly vs. by the minute)
• Licensing
• Support plans
• Container support
• Management capabilities (in the service and through existing management environment)
• Compliance with regulation and laws
• Reporting and dashboard (incl. API) approach

Once we move beyond IaaS into the world of middleware, instantiated or as platforms, we can see differences emerge. Different cloud providers have different strengths. You can compare and evaluate against your requirements of today and those projected for the future. In coming back to the question that started all this, I must tell you about the downside of this approach to evaluation. The development speed of cloud providers (at least the ones that create their own code) is so high that the level of fitness to your requirements can change overnight.

Exploring the scope of a cloud provider and matching it to the requirements is a fluid process. Not only do the services change. The requirements are also going through an evolution from rough to detailed. In many innovation projects the scope of the provider and requirements stimulate each other. This is where sourcing advisors struggle to come up with answers in the format of RfP processes. The iterative nature and trialing of services call for a more flexible approach.

While the speed of innovation is propelling the digital transformation forward, it also poses a challenge to the enterprises. How could they stay on top of things and where to find the people to do so?

Capabilities

You might want to use a cloud provider, but you struggle to find the right people in your department or in the market, or you find a brilliant hire, e.g. for AI, but this person only works with a cloud provider not in your scope. The capabilities in IT and Development can be a limit to your decision for a cloud provider

While you can absorb a lot of that using partners, there are some important tasks that remain with you. One is what I call the design authority, others name it excellence center. You need to set the guardrails, consult your project managers and stakeholders and drive decisions and manage exceptions from the start. This can be kick started with external resources, but to maximize control, accountabilities will need to be internal to your organization. In design authority you do need employees deeply familiar with the services in use (and the marketplace). This can drive the decision for a cloud provider to minimize risk through experience of the existing team.

The other topic arising about your internal capabilities is how to keep the individuals abreast of the cloud provider abilities. Models like playgrounds with limited budgets have been successful in giving developers the opportunity to try and test out new capabilities. In many ways, these playgrounds and dedicated time to use them have led to new ideas, products and services. The challenge is that you cannot provide playgrounds to all cloud players. You will do this for the cloud provider you use. If you use more than one provider, its challenging to provide more playgrounds. If you just use one provider today, you might want to have a small-scale playground in the environments of potential future cloud providers not only to be prepared but also to stay informed on their innovations. The reality over time will be a multi-cloud scenario for most enterprises. This does not necessarily mean that you will procure comparable services from two or more providers, but rather in having complementing services. It also means, that you will play in more than one ecosystem and need to get your team and your own ecosystem prepared to do so.

Conclusion

Now, do we know how to choose the right cloud provider? Are we any closer to the answer to the question “Which cloud is better?”

I believe so. First, we have established that the simple question does not work. The answer might differ based on a range of factors. Second, we have defined a range of topics to consider when trying to answer the question.

The existing on-premises IT ecosystem considering the following factors

• Partner landscape
• Licensing
• Architecture – enterprise and solution
• Existing relationship to provider
• Previous investment
• Budget
• IAM
• Network
• Existing Toolsets

The scope of the requirements

• Pre-defined requirements
• Fluid requirements
• Scope needed immediately
• Scope needed in the short/medium/long term future

Your team, internal and extended

• Existing knowledge
• Speed and amount of upskilling
• Partner resource available to kick start cloud use

Most importantly, you need to apply more than one approach. While the classic sourcing approach towards requirements helps you establish a requirement baseline, there is also a scope to define on the go. And be prepared, that this fluid approach can also make changes deep into the baseline.

So which cloud is the best? It is a complex question. Much like with “Which do you like more, Audi, BMW or Mercedes?”, the answer can be more emotional than strategic.

You would be surprised how many individuals on a technical level object to different providers. This is the cultural challenge of the decision – make sure you cut out the emotion without losing the people on the way.