Skip to main content

Single Cloud or Multi-Cloud: The Ultimate Debate

Today, we’re going to talk about a hotly debated topic in the tech industry – whether to pick a single cloud provider or go for a multi-cloud strategy. As someone who’s been in the industry for a while, I’ve seen companies go back and forth on this topic, and I think it’s time to weigh in with some of my observations.

Let’s start with the basics. A single cloud provider means that your company uses one cloud provider to host its applications, services, and data. On the other hand, a multi-cloud strategy means that you use multiple cloud providers for the same purpose. Sounds simple, right? Well, not exactly.

While the idea of using multiple cloud providers might seem like a good way to hedge your bets, the reality is that it can quickly become a headache for your organisation. One of the biggest challenges is the overhead that comes with establishing a presence in more than one cloud provider. Each provider has its own set of tools, services, and pricing models, which means that you need to invest time, money, and resources in learning and maintaining all of them. Not to mention the added complexity of managing data across multiple clouds, which can result in increased latency, security risks, and compliance issues.

For smaller organisations, a keep-it-simple approach might be best. According to a recent survey by LogicMonitor, 87% of SMBs are using a single cloud provider, and only 13% are using a multi-cloud strategy. This is because smaller companies typically have limited resources and cannot afford to spread themselves too thin. By using a single cloud provider, they can focus on their core business and avoid the added complexity of managing multiple cloud environments.

But what about larger organisations with more resources? Surely, they can handle a multi-cloud strategy, right? Well, not so fast. A recent report by Flexera found that 93% of enterprises have a multi-cloud strategy, but only 16% of them have the expertise to manage it. This means that most organisations are struggling to keep up with the demands of a multi-cloud environment, which can lead to increased costs, downtime, and security risks.

So, what’s the solution? While it’s tempting to go for a multi-cloud strategy to take advantage of the best features of each provider, the reality is that it’s not always worth the overhead. Instead, companies should focus on finding the right cloud provider that meets their specific needs and invest in developing the skills to manage it effectively.

At cloudstep.io we created a simple three step ‘Business Case in a Box’ process that leverages our unique tooling to help organisations big or small answer these questions. Starting with a rapid assessment to provide lightweight, express validation of cloud intention through exploration and validation of different migration scenarios. The output of this assessment identifies any organisational knowledge gaps followed by focused analysis to prepare the organisation for a successful migration.

The decision to pick a single cloud provider or a multi-cloud strategy should not be taken lightly. While multi-cloud might seem like a good idea in theory, the overhead and skills requirements can quickly become overwhelming for most organisations. Like many things in life its not a simple case of one size fits all. Investing time upfront in validation of your requirements, assessment of candidate cloud providers and planning your migration could spare you a lot of sleepless nights. Thanks for reading!

The Cloud – Anagnorisis and Peripeteia

In my work here at Cloudstep we have two distinct sides to our business, a consulting practice “Jtwo Solutions” and a cloud modelling software and services practice “Cloudstep”. Working on both sides of these businesses affords me the benefit of hands on consulting, technical architecture and implementation as well as scenario based cost modelling activities with a wide range of government and commercial customers.

Recently, I’ve been reflecting on what it is that makes me happy about working with customers within these businesses.  I decided to set my self the challenge of coming up with just two words that could be used to articulate this in a concise form.

After reflecting on this for some time, two words come to mind, “Anagnorisis and Peripeteia”. After sleeping on it for a few days, these words seem to have stuck.

So what the hell is Anagnorisis and Peripeteia. . . ? In short, Aristotle made these words famous (for me anyway).

Aristotle

Anagnorisis:  the transition or change from ignorance to knowledge.

Peripeteia: a sudden or unexpected reversal of circumstances or situation.

When considering the meaning of these two words, I think they elegantly describe the two way street that is IT consulting and cost modelling. I’ve always enjoyed the excitement of the changing IT landscape, ever evolving, disruptive yet inspiring and endlessly yielding of new opportunities.

Opportunity is what business thrives on, competitive advantage can be found here. Businesses that capitalise on the right new knowledge / technology win. The trouble is, that new is only short lived and you have to stay ahead of the curve. In the fast paced, evolving IT space, anagnorisis is something you are constantly chasing.  

I repeatedly find myself in the position of educator and student, both assisting clients with the relentless learning and learning myself. This is delightful, challenging and terrifying all at the same time, but it’s what makes IT interesting and enjoyable for me.

This brings me to the second word. . . peripeteia.  Cloudstep provides customers with a multi-dimensional view of the cost of delivery of application workloads. We do this by modelling, teams of people, the functions they carry out, the applications they use, the infrastructure the applications live on and the underlying hosting costs of the infrastructure (servers, storage, networks, data centres).

With this data we can accurately articulate the true cost of a specific workload and conduct fair comparison with alternative delivery models like software as a service or a public cloud implementation.

Anagnorisis happens here too, but what is really beautiful is the peripeteia that this knowledge can enable. Cloudstep helps provide businesses with clarity and can enable them to see the most cost effective path forward. For me, I find happiness is the situation where a business can shift their focus from any undifferentiated workloads and shift the focus of their IT resources towards workloads that are specific to their core business, directing efforts towards innovation in their own space.

The future in IT that, I imagine, is one where we don’t have to spend as much time on undifferentiated workloads rather, one where we have more time to thrive on the new opportunities that are yet to come.

Planning a move to the cloud with the AWS Application Discovery Service

Here at cloudstep, we love to help our customers achieve their goals. We believe that the cloud is a tool in the toolbox and we can use that multi-facet tool to help our customers realise success. Planning for success starts with goals, and goals come in many different shapes and sizes.

For any given solution, a customers goal may be focused on achieving financial or competitive advantage. Alternatively, they may be looking to realise operational efficiency by improving a day-to-day process using automation and orchestration. No matter your goal, you need a solid plan to ensure success. More often than not, that starts with validating that you have a sound understanding of the current state environment which will enable you to move forward towards achieving your goals.

Today I want to talk about a capability provided as part of the Migration Hub offering in AWS, the Application Discovery Service. This is a tool that we regularly use and encounter when meeting with customers. The core idea behind this capability (aptly named) is to help you discover critical details about your environment. This includes performance metrics and resource utilisation data which can be used for cost modelling, in our case… cloudstep.io. The tooling can also gather detailed network metrics to help you better understand the integrations and interfaces between applications in your environment. All of this data is at your disposal once you have decided upon which deployment model you would like to utilise.

AWS offer both an Agentless Discovery service and an Agent Based discovery service. Ordinarily, we typically use the Agentless discovery service. This is a great approach for organisations that operate entirely virtualised VMware infrastructure. Using this approach allows you to quickly inventory each of your VM’s that reside within your vCenter without the requirement of installing an agent on each guest VM. Choosing this path means that the agentless discovery service will query the VMware vCenter for performance metrics (irrespective of which OS the guest is running.) It can’t actually reach inside the virtual machine, therefore it is dependent on having a compatible version of the “VMware Tools” running inside each VM.

If you have a mixture of Physical and Virtual servers in your fleet, or you run another Hypervisor (such as Hyper-V) you may need to consider the Agent based deployment model. This approach is generally considered more labour intensive to get up and running due to the requirement to get hands on with each server. There are also some constraints around which OS’s it can fetch data from. So be mindful of this. You may even find that the best approach is to run a mix of the two deployment models. The outcome of both approaches is a series of performance data metrics which is shipped outbound using HTTPS to an S3 bucket. This bucket can then be queried by the AWS Migration Hub service. Alternatively you can export the data and analyse it using tooling of your choice.

For the remainder of the article, I will focus on our experience with the Agentless discovery approach. As I mentioned earlier, this is our preferred approach because it takes about an hour to get up and running and it generally produces more than enough quality data. In our experience, this provides an excellent baseline for commencing our cloudstep.io cost modelling engagement.

The AWS Agentless discovery connector operates as a VMware appliance within your vCenter environment. AWS provide a pre-canned OVA file which is around 2GB in size. You simply deploy this, the same way you would with any other open virtualisation archive. If you run multiple vCenters for different physical locations, you will need to deploy multiple instances of the appliance to service each stack.

If you experience issues deploying the OVA image within VMware, review my other blog – here

Deploying these appliances in enterprise environments often presents unique challenges. In our experience, this is where customers tend to have issues. Sometimes they deploy the appliances to management networks which don’t provide DHCP so they need to manually bind IP addresses, or there may be firewall rules which prevent connections from an access layer switch to perform the configuration process. The appliance does offer a terminal console (sudo setup.rb) where you can configure foundation services such as IP configs and DNS servers.

Another consideration you should make is “How will my appliance get outbound access to the internet?” After all, its sole purpose is to ship data outbound using HTTPS to an AWS S3 bucket via the Migration Hub. From a firewalling perspective, this is usually quite nice as outbound TCP443 generally doesn’t warrant a discussion with your security team. However, should your security team raise concern about corporate data being shipped off to the internet, AWS provide a detailed article on exactly what information is collected – here.

A final consideration you should make is proxy servers. If you utilise upstream proxy servers to police internet access, consider any rules you may need to define here. Typically speaking, the appliance will run headless in a “SYSTEM” context so you may need to allow it unauthenticated outbound internet access. Take a moment to think through any pitfalls you may encounter and also consider how you intend on interfacing with the appliance.

Once you have deployed your shiny new VM, you can fire up a web browser and configure it using the native web interface ( http://127.0.0.1 ) There are two things you will need:

  1. Read-only credentials to the vCenter you will inventory.
  2. AWS IAM Credentials to authenticate to the Migration Hub service.

Once you have completed the wizard, you will be greeted with a summary screen that presents instance specific configuration such as the appliances AWS connector ID.

The final step in the process is to to start the data collection process. You can action this by making API calls using the AWS CLI

aws discovery start-data-collection-by-agent-ids –agent-ids <connector ID>

Alternatively, you can also navigate to the Migration Hub console and manually approve the data collection process. If you have more than one appliance, you will have multiple connector ID’s registered here. You can validate that these line up by browsing to the appliance web interface where it will list its respective connector ID. The service polls the vCenter environment every 60 minutes, therefore it is reasonable to expect that you should be able to query your data within the AWS migration hub within an hour or two assuming everything is functioning as expected. Alternatively you can export the collected data to a CSV to commence your migration analysis.

In this blog I have explored the Application Discovery Service which is a capability provided by AWS’ Migration Hub. We have talked through common pitfalls that customers often experience when working with the agentless discovery service in effort to simply the deployment process. The data collected provides powerful insights into your environment which is crucial to success when planning a cloud migration. Should you need further assistance, do not hesitate to reach out to the team at cloudstep.io. We’d love to hear from you, and to help you on the road to success

To the cloud!