Public cloud computing has finally started to make sense to me now. A recent conversation with a fellow sysadmin had me rocking back and forth in a corner muttering "that's illogical". When I emerged from my nervous breakdown I realised that capitalising on the irrationality of the decision-making process within most companies …
A Well written article, and an interesting read :)
However, I think there is a slight skew in some of the maths - Most Test / Dev environments are kept on all the time because:
1 - The kit is from decommissioned live environments (and therefore there is no Cap-Ex), and is therefore so old the tech's are afraid to turn it off.
2 - Tech's are too lazy to spin it all up again as (and when) needed. Much easier just to have an RDP session available for use when you can grab a spare few minutes (or have an hour to kill on a friday ;-) )
Test / Dev tends to costs only power and space...... meaning its a soft target for transition to cloud if you have a hippie-friendly Carbon reduction scheme on the go....
That might be the case in some business models, but in a truly agile environment delivering customer facing systems, test environments must reflect the live setup, and not just be dumped on retired tin. Having your customer facing systems (i.e. transactional website) on a cloud environment allows for seasonal scaling (managed by a team to avoid the holiday issue mentioned!), and temporary provision of "like-live environments" for performance and volume testing (which should be carried of on a very regular basis).
Whilst Trevor's thoughts may be applicable for many backend systems (finance, etc.) which do just plod along, many industries require burstable systems. This bursting can easily be scripted and triggered using monitoring tools. Whilst I agree, this is not a panacea, it isn't the purely political solution implied either.
The right tool for the right job!
How many ?
"many industries require burstable systems."
Would you mind name at least 5 ?
Re: How many ?
"many industries require burstable systems."
Would you mind name at least 5 ?
What confronts me and my team are:
Time and expense systems - at end of month everyone logs on to do all the work they should have done in the month
ERP systems when doing end of month reporting, or trying new cube/datamart based data analysis
And separately ERP systems when people do very large MRP roll ups
Transactional web sites when the company is offering sudden discounts or at the end of bidding by subcontractors. These aren't general public facing
Less so as this can be predicted - mathematical modelling of business processes and trying different parameter sets.
Re: How many ?
Well, for starters:
* Education - to handle clearing, exam results days, freshers week, etc.
* Government - tax return deadlines, new public services (census data, etc.)
* Retail industry - Christmas, other busy shopping days
* Research - burst processing capabilities for data analytics
* Entertainment - on-demand services handling evening peaks
* Gambling - for major sporting events (Grand National, Cup Finals, etc.)
* News sites - for major breaking stories
In fact, the more you look at it, the fewer industries you find that *don't* have variations in demand. The problem is that very few enterprise workloads are built to scale horizontally, which is why cloud services are (currently) better suited to newly developed services rather than traditional ones - but this is changing slowly.
Re: How many ?
"In fact, the more you look at it, the fewer industries you find that *don't* have variations in demand. "
In fact all you cited can be called in one word - webserver. So "industry" is just one.
Re: How many ?
"What confronts me and my team are:"
So tell me one thing - are you running in normal mode your systems at 100% capacity that you need add more systems at peak load ? How about databases? Are you also spawning new instances just for peak load ?
I really doubtful about that.
Re: How many ?
"In fact all you cited can be called in one word - webserver. So "industry" is just one."
webserver an industry? Surely it's a technology? And most of the industries I highlighted need more than just webserver technology - databases (structured and nosql) to hold the data, middleware to handle the business logic and integration with other services (payment processing, order fulfilment, media encoding), analytics for, well, analytics, user management systems to handle AAA, etc. All of these need to scale (to different proportions) in response to changing demand on the systems.
If you disregard the advertising and PR hype around "cloud", the concept of technology services that scale up and down rapidly and on demand are logically sound (and have been used in more manual ways, such as recruiting seasonal workers, for decades). The problems organisations face relate to the lack of capability of a "traditional" application stack to easily make use of this type of flexibility, together with the business analysis to understand when there are benefits of using cloud v in-house technology. For these reasons, cloud delivery of some services are often (much) more expensive than alternatives, as the article highlights.
Going forward, more enterprise apps will be built with a cloud delivery model in mind. In the same way that it's possible to generate your own electricity, and historically you had to build your own generators, nowadays most people buy power from a utility provider. Similarly, the time will come when it is both easier *and* cheaper to buy commodity IT services from a utility provider. In-house delivery of technology will be done for edge-cases only.
This move to commoditisation will be competitive and brutal, and be based primarily on scale; in the same way that there are only a small number of national electricity providers in the UK, a similar thing will happen (and is happening) to cloud providers as the industry matures. Take Rackspace, which have already dropped out of the cloud price wars. I would put a bet that in 5-10 years time their main focus (and revenue) will be on their managed services, rather than their infrastructure.
Disclosure: I work for an SME managed services provider, that runs its own cloud infrastructure - but there will come a time in the future when it makes more sense, technically and commercially, to use commodity IaaS providers (plural), managed properly, to deliver some of these services.
"in a truly agile environment delivering customer facing systems, test environments must reflect the live setup, and not just be dumped on retired tin"
Bullshit. Even working at one of the biggest companies in the world, they don't have the dough to duplicate the live setup for dev/test/stage/buildtest/uat/psr/whathaveyou. It's still retired tin.
Re: How many ?
Somewhat challengely put, I can see you are in management.
So tell me one thing - are you running in normal mode your systems at 100% capacity that you need add more systems at peak load ?
Sort of, they will be running above 50% I guess, and yes load at all tiers of the application will go up, asymmetrically of course because it depends on which of the examples I have given.
How about databases?
We will do that depending on the task and the architecture of the application,and add more stuff to existing db servers
Are you also spawning new instances just for peak load ?
Well peak, mmmm, depends what you mean. Some of the above examples do not arrive at a pointy peak as characterised by the Matterhorn shape. Many are more Aconcagua in form. So we will add to respond to expected loads and try and add quickly if odd stuff is detected. Sometimes the extra is left in place for days as the demand goes on and on.
I am interested in what answers you were expecting? Do these match with your experience in managing variable loads?
All the above is helped by having your software designed at least in part to be able all these shenanigans to happen.
The ERP system I am referring to is stateless and asynchronous and so can scale up and out without batting an eyelid.
Please answer, as I have spent time writing this and I had paint to watch dry
It's the old pendulum
After a few years of cloud, the next big marketing thing will probably be 'hyperlocal'. Or some other such buzzword. Because the cloud will be the established thing, the kit-buying bureaucracy will probably have atrophied somewhat, and so there'll be fewer roadblocks in the way of buying hardware. instead the bureaucracy will probably have moved on to lock-in to the existing cloud provider, and resisting moves to anyone else.
Then IT will be able to say, "look how much we can save by bringing this stuff back in-house."
I still love the IT industry use of 'small' business to be anything under 1,000 people. What does that make us? We have 6 people, scattered over one office, 3 houses and whatever car or train our road-warriors happen to occupy at any given moment. For me the options are cloud or do without. I looked with envy at certain IT goodies that only 'small' companies used to be able to afford. Now we can go and rent something cloudy. Even a badly managed cloud service is better than what we can do ourselves. Obviously it's a totally different calculation for larger companies. Or should be.
Cloud = A form of managed hosting
"""The public cloud is attractive because it is – for the time being at least – a shortcut around bureaucracy. It may seem illogical or even irrational to many of us, but it will continue to sell."""
I will add it is attractive because to some people cloud="switch brain off"
Most people prefer to pay rather than think.
TLDR. But does any company put core compute into the cloud ? Putting a project in there is one thing, but if you cloudify a compute function your business can't afford to lose, and the provider goes down/bankrupt/whatever, you cease trading 3 days later. It's no good bleating about your contract or SLA, you are are out of business already. I must be missing something.
We have several customers taking a cloud-first approach to core infrastructure services, it depends on the level of confidence they have in their service providers (including us). Some of them are so cloud-focused they are even buying cloud-managed networking/wireless/security and getting someone else to manage that for them as well. We've got a lot of businesses on our hosted Lync service and have had great results and growth in that area. Putting VoIP in the cloud is a big commitment, but it seems to be working out well.
A lot of it boils down to cost. I can put 10 medium instances of Windows Server or RHEL in our cloud for 5 years for less than the cost of a single server with local disks (never mind licensing etc). Since most of our smaller customers are running less than 10 distinct workloads (and simply using hosted services for common workloads like email and the aforementioned collaboration), many of them don't even bother with a server at all.
"But does any company put core compute into the cloud ?"
I agree with M.B. says and I will add, geographical spread
Lets say you have shipping in Singapore, sales offices in Sydney, Munich, and Dayton, Ohio (eeeuughh!) and accounts in Luxembourg and you have to tie that lot together.
A global cloud provider is giving you the links, the fail over and the servers in one package.
And yes this is core like nowt else
Sort of related. When hurricane Katrina hit my team was involved in helping some customers get started again, that changed a lot of minds for the customers, they never wanted their own kit in one location again. They wanted to be able to ship the employees across country and start again in a hotel room. Soon after they have found them again.
We're doomed I tell you....
Having looked at alternative hardware for exactly this purpose I'd suggest that the less expensive options have compromises not mentioned here. Sometimes acceptable, sometime not. often not, actually.
An aspect not mentioned is all those expensive sysadmins and hardware engineers you no longer have to employ when someone else is doing "that stuff" for you and the in-house "expertise" consists of point and click in a web interface.
Re: We're doomed I tell you....
But that's actually not true: cloud systems require sysadmins, too. Basically, your sysadmin needs will always be proportional to your IT needs, regardless of whether you outsource the physical datacenter (whic his all IaaS is...) If you think going Cloud means cutting staff, you're wrong. You might get rid of some box-monkeys when you outsource boxes, but they probably make minimum wage anyway (and each looked after hundreds of servers, so you had very few of them.)
Trouble is, you have to operate that "point and click" interface from somewhere. So you need reliable and secure networks, desktops/notebooks, firewalls etc. or else you'll find that whatever you do on your cloud servers is being monitored by all sorts of competitors, identity thieves, etc. And all your data's been corrupted, stolen, and/or encrypted for ransom.
If maintaining terminals is all you ask your platform support folks to do, they'll either become very bored, incompetent, or both. So there are other returns to scale from bringing IT in house, not just equipment savings. And if you think all your sysadmin problems have gone away because you rented server space somewhere, you're wrong.
I suppose you could rent office space in a corner of your cloud provider's data center and not encounter any of those internet risks, but it might not be very convenient. Or cheap.
Thank you Trevor for the thoughts.
Thank you. It is items like this that keep me reading your writings. I would also suggest that the some decision makers do not see the near by people as useful so a "shortcut around bureaucracy" is seen as being efficient.
Management don't want to manage staff. That is work. They don't want to manage buying bits of tin. That is work. They do however like meetings where they can talk about work. Outsourcing any function means management can talk about it and leave someone else to actually worry about it.
Sadly, Managers spend their time trying to build an empire so that the bits of paper and meetings they used to have that talked about work can be handled by some new previously unrequired sub-manager.
A business that outsources soon ends up with a department full of people fit only to be politicians :)
- Review Apple iPhone 6: Looking good, slim. How about... oh, your battery died
- Review + Vid iPhone 6 Plus: What a waste of gorgeous fat pixel density
- +Comment EMC, HP blockbuster 'merger' shocker comes a cropper
- Moon landing was real and WE CAN PROVE IT, says Nvidia
- Apple's iPhone 6 first-day sales are MEANINGLESS, mutters analyst