back to article So you're already in the cloud but need to come back down to Earth

We generally think of a transformation to a hybrid infrastructure as one where you're going from a completely private setup to one that spans the public cloud and your private installation. But what if you started life as a small company with your systems entirely in the cloud? It's not an unusual approach, as running up your …

Stop

Plus...

This article seems to have confused one key item and missed another, both of which are important considerations.

Firstly, whilst a bit pedantic (and even debatable), it confuses "on premise" with "running your own kit in someone else's data centre". Yes, I guess someone else's data centre still counts as "on premise" and this will be the route that many take, but the article completely skips like, y'know, actually running stuff "on premise" and related issues... like where to put your kit if it's in your offices, how to power it and how to secure it, and so forth. Not everyone will want to run it in a data centre (for most people, most of the time, that's what Clouds are for!)

Secondly, if you start "in the cloud" and want to migrate apps "on premise", will it be even possible? It's all about the apps, and this point is completely skipped. Most smaller or startup organisations that use the cloud are using specific applications and services, not plain IaaS. Can those apps even run on-premise? You're going to have a hard time moving Salesforce, Box, Slack or AWS's development stack on-premise. This is only going to work smoothly if you're running conventional apps on IaaS in the cloud (or, arguably, move from Office 365 to a hybrid Microsoft platform).

13
1
Anonymous Coward

Re: Plus...

Owning your own equipment in another DC is often referred to as "Co-location".

On premises would normally imply the company owns the data centre.

Once the costs of using cloud are properly accounted for there can be large savings by going on premises or co-location. The benefits have often been oversold which combined with lack of flexibility can mean moving away from cloud more efficient. When combined with the support and development issues it can be better to keep everything in house.

1
0
Silver badge

Re: Plus...

"there can be large savings by going on premises or co-location"

I've never seen a properly costed plan that shows this. They all tend to ignore staff costs, opportunity cost, decommissioning cost or all three.

1
0
Silver badge

Re: Plus...

I wish I could share with you the one that my manager put together. It showed that cloud was so much more expensive for what we wanted to do that the CIO signed off on a multi-million sum of money.

0
0
Silver badge
Meh

I think on premises is probably going to start becoming more popular again, especially as we're starting to see more and more troubles in the cloud sector.

I basically see "cloud" as being a fancy way of saying "time-sharing". It kind of feels like the 1960s all over again - the cloud is a new, shinier, more buzzword-friendly mainframe, but at the end of the day, it's still very much the mainframe mindset from a business point of view.

And the whole point of on premises was to cut costs and break away from vendor lock-in. It's the cycle of re-invention, once more.

As Yogi Berra once said, it's like deja vu all over again.

9
0
Bronze badge
Coat

As Yogi Berra once said, it's like deja vu all over again.

I rather like "deja poo" as an alternate term- it's the feeling we've done this crap all over again. /rimshot

Mines the brown one.

4
0
Silver badge
Thumb Up

deja poo

This phrase is genius and I intend to steal it forthwith.

0
0
Bronze badge
Linux

Private hybrid public cloud

The 'cloud' a virtualized PC running on someone elses server farm that you pay for by the CPU cycle. The rest you have to do it yourself.

1
1

Re: Private hybrid public cloud

Err, not really. Yes, there's plenty of use of compute Infrastructure-as-a-Service, which is basically what you describe, but most use, I qualitatively believe, of the cloud is 'Platform-as-a-Service' or 'Software-as-a-Service'.

E.g. if you're using Salesforce SaaS then (rubbish as it is) you get a fully managed application/service where you never see the virtualised OS. If you're using AWS Lambda, API gateway and RDS to deploy your custom-build apps, it's similar.

Not to mention that even when you're using IaaS, it's much more than renting CPU cycles. VPC gets you virtualised datacentre networking, and EBS/S3/EFS respectively get you managed enterprise block, object and NAS storage respectively. None of which are easy to run well and in most enterprises are ... problematic...

For me, being able to set this stuff up, programmatically and repeatably via API, in minutes is the real benefit. No waiting about for weeks for your infrastructure team to extract finger from fundament and give you what you need.

This isn't to say that private cloud *can't* be done well. I just have never seen it. It may be something to do with the fact that running a cloud is complicated, and most of the people who can do it well are employed by AWS, Microsoft, Google etc. on salaries to match.

1
0

Rather than reading some fantasy story, read up on a company that's actually done the move from AWS 2 Co-lo, Dropbox moved 500PB of data. ;)

2
0

"evolve to a two-site setup" - if you're only using one availability zone ("site") in the cloud you're almost certainly doing it wrong. For anything important, you probably want a 2-AZ setup at a minimum, possibly 3-AZ with data replication to a completely separate region (snapshotting to S3 will achieve the latter).

The premise of the article appears to be that you run all apps on the public cloud with a backup on-prem, or vice versa. That's an option, but in many cases you'll be better dividing your workloads by their characteristics. Custom build services that need to be rapidly developed suit the public cloud, as it's generally more convenient and flexible for development teams, who can use advanced cloud services without having to wait on anyone else for their infrastructure (of course, that means the dev teams have to have good embedded platform specialists). Commodity products that have a slow upgrade cycle and just need a Linux server and a bit of storage are probably best on-prem/colo running on converged infrastructure. Bursty workloads suit the cloud; you could perhaps put the base load on-prem/colo, but then you're running a split cluster which is often awkward.

Replicating more than the IaaS element of a cloud on site is expensive and difficult for all but the largest enterprises, who have the scale that might make it worthwhile. But unfortunately, large enterprises usually have politics, and probably either had their IT outsourced to one of the usual, woeful, suspects ages ago, or a CIO who is thinking about it so they can make themselves look great in the short term at the expense of stuffing things up longer term. The natural effect of that is that the outsourced IT provider will spend three years building a 'Cloud', which is actually a converged infrastructure that offers a fraction of public cloud functionality at 5x the cost. And doesn't work.

Don't get me wrong, on-prem IaaS is useful and done well can be valuable. Deploying Kubernetes et al gets you closer to where the public cloud was about three years ago. But don't fool yourself it will be the equivalent of the big public clouds, which are deploying new services at the rate of knots and are essentially impossible to catch up to at the moment.

At some point innovation will slow and most services that most people need will have good-enough, commoditised on-prem equivalents that can be easily deployed, at which point the equation changes. But my guess is that's probably still a good few years away.

0
0

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Forums

Biting the hand that feeds IT © 1998–2017