At the beginning of one of our current engagements, the client asked us to evaluate and provide a recommendation on which cloud provider they should use to build their new IoT platform. Since this is a common request from our customers, we’ve developed a framework for approaching the decision.

Evaluating a cloud provider can be a daunting process, major providers have upwards of 200 services with features being added every day so doing a feature dump and ranking is, in my opinion, a losing battle. In order to make a recommendation, we evaluate each provider across 4 major areas that not only consider the technical alignment but also the realities of corporate IT, governance, and any system dependencies.

Architectural Alignment

The architectural alignment section ensures that the expected patterns and use cases can be easily supported by the selected cloud provider. You can break down the requirements as follows:

  1. Category

  2. Description

  3. Some examples

  4. Core architecture

List out the core architectural requirements and expectations of the system to build

  • Heavy usage of async/event-driven patterns

  • Low latency, continuous messaging between platform services

  • Low latency querying of data

Interaction models and sample use cases 

List the various interaction points within the platform and between it and its consumers/producers

  • Continuous updates from external parties

  • Notifications to external consumers

Component requirements

Based on the above categories, list out the service components that best match the architecture

  • Event streams

  • Queues and Notifications

  • Caching

  • NoSQL Store

Once you have a clear idea of the requirements and possible services, you can proceed to evaluate each cloud offering’s service that matches it (e.g. AWS Kinesis for streams or Azure CosmosDB for NoSQL) highlighting the specific features and capabilities they each have that can simplify or add friction to the build-out of our platform. This last point is critical; the point of this exercise is not to go through every cloud provider offering and come up with a matrix on how each service ranks but rather, select which capabilities are needed to build the platform and how each offering helps or adds friction.

Interaction with Dependencies

In the architectural section, you take into consideration the dependencies of the various components that make up the platform. Here, we evaluate, identify, and categorize the interaction with 3rd party (internal or external to the company) dependencies. You should come up with a metric that makes sense for your system and use it to rank the importance and criticality of each dependency. This gives you an easy method for determining what dependency should influence your decision one way or another. For example, you might need to generate and drop data for a 3rd party in a specific cloud provider (and do not want to pay any egress cost) or need to communicate directly with a help desk system located in cloud A; these might have enough of an impact on the overall system that can sway the direction in one way or another.

Corporate Governance, IT Control and Support Organization

Applications and platforms do not live in a vacuum; there are usually requirements, guidance, and agreements that can dictate which cloud can be used (e.g. contractual agreements, government compliance, etc.). In addition, you need to consider operational aspects like support and maintenance, troubleshooting, and SLAs.A new cloud provider involves a certain amount of ramp-up which can include account setup, monitoring, automation, incident remediation, security and vulnerability scans, etc. This process is not trivial and should be incorporated as part of your evaluation regardless of whether the ownership is on the team building the service or your existing IT organization (if you are asking them to support a new cloud).In addition, you should consider the staffing involved in running your service. While cloud providers offer managed services for most components, it is not set and forget. I have worked with organizations that start with a very small support team, and quickly have to grow it as their usage increases (automation, processes, and guidelines help mitigate this drastically).

Alignment with the Developer Ecosystem

Lastly, you should consider the alignment with your current and future developer ecosystem. This involves looking at the technology stack you chose for your products, the knowledge that already exists within your team and what cloud can provide more mature tooling or services to match that. The cost of (re)training your staff is an important metric to weigh as part of the evaluation.

Conclusion

When evaluating cloud platforms, there are numerous ways you can go about dissecting the dimensions that should inform your decision. In our case, we use the above and couple it with our professional experience building these types of architectures.

The reality is that most large organizations end up with multiple hosting environments (private + public) so even within one platform or product, the specific requirements and use cases of each component might be different enough to warrant breaking it up.

Hopefully, this framework can help you as you evaluate what cloud provider is a good fit for your project and if you have any questions, we would love to help!