Why Use One Cloud, When You Can Use Any Cloud?

Why Use One Cloud, When You Can Use Any Cloud?

No, seriously, why would we just use one cloud?

Let’s stop for a moment and think about what has happened over the course of the last few years in public cloud computing and the hypervisor wars on-premises.  VMware has largely dominated the data center, but we are seeing a strong push from Microsoft on the hypervisor front.  KVM and Xen continue to grow in popularity for certain sectors, and all across the spectrum we see lots of folks running more than one hypervisor.

The cloud is no different.  The reason that we are all seeking the “AWS killer” just like the elusive “iPhone killer” is that there is some bizarre need to locate a winner of the platform war. 

This isn’t a zero-sum game.  The real shift in our industry is the broad acceptance of multiple platforms inside every IT portfolio.  We jumped right past the cloud to the multi-cloud.

Why Run More Than One Cloud?

Technology is not the problem, it’s the solution.  Business challenges are being answered by technology which is what really matters.  So, why would we run more than one cloud?  The reason is a technological one usually.  Certain features, APIs, and architectures may be supported on one more than another.  There are raw economics involved as well.  There are overall availability concerns which drive businesses to disperse their IT across multiple data centres, so why not do the same in the cloud?

The reason that AWS and OpenStack are often pitted against each other is that there are capabilities to enable AWS API access within the OpenStack platform. This is something that Randy Bias and many in the community fought for over the last few years.  The reason that it becomes important is that we see the huge adoption of AWS and being able to take the same workloads and move them to OpenStack using the same API calls and interactions would be a massive win for OpenStack as a platform.

If we stick to strictly public cloud providers, we can start with what we would call the big three:  AWS, Microsoft Azure, Google Cloud Platform.  Among those three, we see a lot of parrying as we see features and pricing updates happening regularly.  Features more so than pricing lately. That results in an ever-growing set of services that can be easily consumed.  As we see common orchestration and operational platforms like Mesos, Kubernetes, and the like gaining in popularity, it gives even more credence to the commoditization of cloud.  (Author’s opinion note:  The supposed “race to zero” for cloud costs is over.  They have all agreed that pricing isn’t where they win the customers any more)

Reducing the Complexity of Multi-Cloud

Complexity is the one thing that will slow the multi-cloud adoption a bit longer.  There are clearly different ways to consume resources, and to programmatically create and destroy resources in the public cloud platforms.   Especially when you go outside of the big three.  That means consumers of the public cloud will have to start with one target and generally work up to a deep comfort there before moving to embrace a multi-cloud strategy.

Once we remove or reduce complexity from the list of barriers, that opens up the door for embracing the economic value of a multi-cloud strategy.  This is where we can embrace spot pricing and on-demand growth to tackle scaling needs, while making the workload truly portable and making sure that price becomes the real win.  Networking stacks across the clouds are rather different for a reason.  If every car manufacturer used the same exact parts, they would lower the chances of you coming back to them for up-sell opportunities.  The same goes for the cloud.  Networking and security (they should always be paired) will most likely be the greatest challenge that technologists face in architecting their single multi-cloud solutions.

Next-Generation applications are being built as cloud-native where possible.  This opens up the door for what has been talked about for years.  Supposed freedom from vendor lock-in.  I’m always rather skeptical when a representative from one cloud company says “come to us and avoid vendor lock-in” because every vendor, even public cloud ones, have lock-in.  

What we do gain by embracing the cloud-native approach to application development and deployment is that we reduce the risk of lock-in.

The more we learn from the forward-leaning development teams, the more we are able to give ourselves agility in a multi-cloud architecture.  As all of the public cloud pundits who represent one faction or another are arguing over who will be the last one to be all-in on the public cloud running cloud-native applications, they forgot about one thing:  they opened the door for their competition too.

Interview: Cyber Security Orchestration Vendor Syncurity Optimizes Cloud Costs with ParkMyCloud

Interview: Cyber Security Orchestration Vendor Syncurity Optimizes Cloud Costs with ParkMyCloud

We chatted with JP Bourget, founder and CSO of Syncurity, about how his cybersecurity orchestration company uses ParkMyCloud. 

Hi JP. Can you start off by telling us about Syncurity, what you do, and how big your team is? 

Sure. We’re a cybersecurity orchestration vendor. We are in the cybersecurity product space of SOAR which is security, orchestration, automation, and response. What we do is we facilitate the security alert handling, sometimes called triage, and then use automation to help decide if the alert is concerning, and if necessary kick off a response process for the security operations center or incident response team. We usually launch these processes with alert polling as well as run our automated analysis/enrichment with alert ingesting via security product APIs. 

I’m the founder and CSO. There’s about 25 of us on the team.

What clouds do you use, and how are you using those clouds?

We use Amazon, Azure, Google, Oracle, and Digital Ocean. We do a lot of CI using CircleCI, Travis, and some others.

The reason that we use all those clouds is because we ship images on the different cloud providers for consumption by customers. Our product is subscription-based and we share a private image with our customers, they can then go deploy our product in their environment.

Most of our work is done on Azure VMs and Amazon EC2. We also have another cloud environment which is hosted on bare metal servers that we use for VMware – I don’t get billed per VMguest in that scenario. It’s a per bare metal server cost model. We also now use spot instances quite often based on ParkMyCloud helping us understand the benefit of them, even for longer running instances. 

As for how we’re using them, most of our QA and Proof of Concepts are done in Amazon. Because we do all this automation, we have a huge integration lab up in Amazon. We also do POCs in all the other vendors based on customer requirements.

How did you decide to start using ParkMyCloud? 

We’ve been using ParkMyCloud right from the beginning – we know the team that helped build the product. 

The key benefit of ParkMyCloud for me is that I have about 75 instances at any one time that don’t need to be running all the time because it’s the lab. In some cases, I need to turn on a lab in a fashion that gives me a stack of tools, or I need to run a lab in a fashion where the machines run a schedule. 

There’s certain stuff that is dummy infrastructure or lab infrastructure like windows servers and domains that we want running most of the time, but we turn them off on the weekend. But there are other things that only ever need to be turned on when we’re using them. So what ParkMyCloud gives me is the ability to essentially have an interface that’s multi-cloud for anybody to go in and turn a box on as needed and then automatically turn them off.

How would you describe your experience using ParkMyCloud?

I like being able to see my projected savings right on the platform. The other thing that I really like is the fact that I can see how much a box costs a month instead of hourly. It’s one of those small things that provides huge value. Amazon provides that hourly information but you have to calculate the monthly cost.

We use ParkMyCloud as an alternative to some users logging directly into the AWS console, which is a lot easier. 

How much have you saved using ParkMyCloud?

Our total savings to date is more than $70,000.

Great to hear – thanks JP! 

 

More interviews with ParkMyCloud users: