If your head's not in the cloud, you're not in the right place The tiniest hint of butthurt tinged the Linux Foundation and edX's latest annual Open Source Jobs Report. For the first time, pure Linux skillz were not number one, slipping to second place behind Kubernetes. Container herding is up by 455 per cent, but you just can't get the help. Getting past the mild sulks that "of course, …
Not if you want to work in 'business'.
Even the people with a long history of hosting on-premise are looking at cloud migration, even if only as a hybrid model. Then there are all the 'application' vendors, every single one of which is trying to shift to SaaS (if they didn't just start there).
Now add in the new remote workforces, where latency to a single office is longer a material driver, take into account the benefits that cloud services offer and the lack of non-cloud options on the horizon and it's clear that cloud skills are a good investment.
If anything, even the on-prem stuff is going to move towards 'internal cloud' and start deploying AWS/Azure technologies on self-owned hardware. It'll simplify development lifecycles and boost deployment flexibility. Frankly you're already either legacy or cloud.
There are different perspectives. Accounting-wise, going cloud is seen as "cheaper" because it's an operating cost rather than a capital cost. So it looks better on the balance sheet. None of depreciation stuff to worry about.
From an infrastructure perspective, cloud provides a level of flexibility you just can't do on-prem. For example, say you're a tax company. For 1 months out of the year, you need a fleet of high powered superservers to handle the load, but then for the other 12, you could almost handle the traffic on just a raspberry pi. With on-prem, you need to own those superservers all year round, despite only needing them for 1 month.
From an operations perspective, the big benefit to cloud isn't the technology, but what the technology facilitates. Cloud practically forces you to adopt zero trust policies. Properly done, it allows you to create more fault-tolerant architecture without much effort. Setting up pipelines to rebuild entire services from scratch. Distributed access, eliminating the need for VPN and centralized networks that if compromised, would allow unfettered access to everything.
Cloud is tied very tightly to DevOps. Creating an on-premise cloud with proper pipelines would allow you to, for example, rebuild your entire on-premise infrastructure automatically in AWS if your main data centre ever got destroyed.
From an infrastructure perspective, cloud provides a level of flexibility you just can't do on-prem. For example, say you're a tax company
How many companies do require such a flexibility? Most have a quiet constant workload, may they be industries or services.
Cloud practically forces you to adopt zero trust policies
We see everyday a headline about a database left open in the cloud. There's the theory, then there is the reality. Theories are always shiny and beautiful, reality is uglier.
Creating an on-premise cloud with proper pipelines would allow you to, for example, rebuild your entire on-premise infrastructure automatically in AWS if your main data centre ever got destroyed.
Theory again. In reality bean counters go to the lower bid, and companies get stranded when a datacentre like the one of OVH becomes a bonfire.
Neither on-premise nor cloud infrastructures are perfect. Each one has advantages and inconveniences. But putting all your eggs into one basket is dangerous. When a digger gently breaks your fibre cables during a public work, how does the company work when everything is in the cloud?
You do need to set up cloud very well, but most people don't need much of it. If you have that scale, you can probably afford the tin to run it on.
It seems to me that limiting options is the way to go. For example, you may have all the encryption protocols available to you, but the best thing to do is to pretend you don't and have an "encryption on/off" option. That enables automation as consistency improves.
Do the cloud model - bang-for-buck hardware and modular infrastructure. You don't need an F5, you may need multi-tier haproxy.
The other thing to do is enforce standards. e.g. No-one deploys anything to production in a non-automated fashion. That means you force scripted builds.
The cloud has some very nice features, but mostly its about imposing discipline. You can easily do cloud wrong and make it awful.
My opinion is that hybrid makes sense for most of these at scale companies whereby they have a peaking capacity for odd times it is needed. Full cloud makes more sense for a startup moving out of the garage phase of development and hosting.
SaaS to me has always been about the ability to both charge more and dictate upgrade cycles.
"Is an internal cloud really a cloud?"
In most respects, no. You don't get the scalability or redundancy of running on a much larger set of DCs, which is one major benefit of cloud infrastructure. Often what the "internal cloud" label means is one of two things. It could just mean more virtualization of things so they're not as tied to the specific hardware. A lot of people are doing that. The second option is using an existing cloud provider's software on hardware you own, which probably shouldn't get that label, as buying software from Microsoft which gets the Azure brand attached and could run on Azure is not really much different from buying other software from them when you're running on your own hardware.
Maybe you're thinking of the OVH fire? France instead of the US but most of the rest of the facts match. They didn't move anybody and took a month to recover most of it.
The multiple DCs isn't so the cloud provider automatically moves you in case of problems, though in the case of smallish long-term problems they probably would. It is so you can have a multi-region setup which fails over without having to build multiple DCs. Having duplicate infrastructure in different countries when you're on prem takes months of planning and finding colocation facilities if not building or buying your own. Doing it on cloud can be a selection from a list box (warning, your bill will increase). Even doing it manually is a lot faster. Your company might already have computer rooms in multiple countries for you to do it, but a lot of them don't.
Cloud + on premise vs just on-premise feels like additional deployment flexibility to me.
On-demand scale without capital investment feels like deployment flexibility to me.
Single development toolchain with choice of deployment target feels like an improved lifecycle to me.
I guess I'm doing it wrong.
"On-demand scale without capital investment feels like deployment flexibility to me."
It sounds like until the day that MS tell you that you are going to have to wait a week for the scale you demanded.
Azure is just another layer of failure points that you have NO control over. We shovel millions at the cloud each year but when push comes to shove, MS doesn't even give enough of a fuck to get someone in Texas out of bed to talk to us about a failure before 3pm.
Three times the price of in-house for half the control. Oh, and the price can change from year to year depending on MS's business plan, not yours.
The reason why a lot of experienced IT people don't want to put all their eggs into 'The Cloud' bandwagon.
They've seen the trend of centralisation followed by decentralisation before.
The Cloud is just other people's infrastructure and pushing a button to 'build' a database server, does not give one the inherent skill to build that same database server from scratch if needed.
For people who can build whatever happens when someone pushes the button, there will always be a demand, while people who know which button to push, will be out of a job when the next cycle of centralisation comes along.
"They've seen the trend of centralisation followed by decentralisation before."
Centralisation and decentralisation are each valid in differing circumstances. Determining which is better requires detailed technical knowledge of both, and detailed analysis. But detailed analysis is not what we get when something is trendy, n'est-ce pas?
Is why you need specialists in different skillsets in order to manage it. Is why companies used to have separate groups of people with years of experience in development and years of experience in operations to cope with that complexity. Is why the beancounters dream of requiring the IT people to do both and calling it "DevOps" was always going to mean knowledge spread more thinly over a greater surface area of complexity.
The point of containers and "serverless" was supposed to be that developers didn't need to care about the runtime environment. But then they decided that the developers should also have to be experts in operating the much more complicated runtime environment created to enable that simplification.
That's why PHBs have been sold a load of bullshit about "one-person-fits-all" jobs. Sure you can get some good Jack O'AllTrades but that's enough to keep things ticking along, you're always going to get better service by using speciliasts, albeit ones that can turn their hand to anything to help out.
Dear PHBs, note the phrase "help out", you will NOT get someone who has 20+ years of every skill you need, if you pay good money you might be lucky and get somone who excels at system admin in Windows, has solid day-to-day Linux, core competancy in networking and some solid coding skills to hang stuff together, a good IT all rounder for an Ops dept. Don't expect them to code up your next customer facing web portal or architect your complete cloud strategy, get them involved but get some specialists or watch those allrounders walk out after you've shat on them and expected too much.
Back in the distant past - 1980s, 1990s - I worked in an environment where we had a small team working on Unix/RDBMS (mine), another on VAX/VMS and another on IBM type stuff all handling different aspects of the business. I'm not sure about the last two but in my area we didn't really differentiate between development and operations; our technical knowledge applied to both operations (which wasn't all that onerous) and development, and user support informed our knowledge of our part of the business which was essential for development. Back then it was just what we did - it didn't need a special name.
Only in the last few years before retirement was I in a mostly Windows shop where operations and development were separate. It made life harder, at least from a development point of view, not least because of the amount of ceremony involved in handing stuff over. Oddly enough the ceremony was suddenly set aside any time we had to look at the operational system to sort out the crap data my client's client (one of the Usual Suspects) had sent because their favoured Indian outsourcer had rotated in another lot of XML-deficient staff on short term visas.
I wonder if combining the two has somehow become special because of the notion that you have to crank out new stuff on a daily or even hourly basis.
This article is true of so many technical fields nowadays. Training in hard skills simply doesn't exist anymore and everybody is expected to be hired with whatever unique combination of internal tools and processes each company runs (or more often - wants), usually on short term contracts where the break room's tea bags have the longest time in post. Need a 10x developer, expert in 6 programming languages, who can administrate a high-performance computing centre while delivering world-class deep learning pipeline while landing an F14 on an aircraft carrier at night, for 3 months to transform your global profits with a supermarket laptop? No problem, apparently. Meanwhile, department managers don't have a technical roadmap for their organisation, let alone their own department and infrastructure creaks under cost savings and total resistance to change. What industry really needs is technically trained managers rather than sales, who are aware of what disruptive technology is over the horizon and are building plans to invest in actual people as well as iterate their infrastructure, instead of just buying whatever Bob in the next office bought if he gets himself promoted.
Add on top of that, the bastard PHBs sweat the metal stuff to the point it's 15+ years old, zero hardware/software support, get high on the idea of moving stuff to the cloud and then proceed to sign up to do a datacentre exit in insane timeframes.
Now you have a room full of people trying to work out how the hell to move ancient systems to the cloud in mere months, because the original techies who built it were let go years ago because 'Its cheaper to outsource and maintain'.
Give it a few years, and the PHBs will be back to square 1 because they'll be chasing the next cheapest cloud based option and haven't factored in the data exfiltration costs!
Definitely! I've seen lots of projects now where the entire team has evolved 3 times over since somebody built version 1 of ye olde corporate tkinter or fortran app that now needs to be magically transformed into a parallelised AWS hosted browser app, but nobody knows anybody who was ever connected to the original undocumented spaghetti code ball. "It's just code, right?" "no mate, it's the creative process of a team of long-dead domain experts, and everybody here has 3 days experience.... no wait, one of us has just left so that's 2 days of experience."
"That's a combination of the notion that if you're away learning you're not doing the job you were hired for, and the fear that you'll take the training and immediately demand extra pay or bugger off to a better job. Which you wouldn't do if you really liked where you worked, but this idea might as well be written in hieroglyphics in many workplaces. "
That is so true it hurts.
The complexity and scale of a proper corporate infrastructure isn't something you can knock up on a couple of Raspberry Pis and a gaming rig.
And why is that? One of the big issues with most software these days is the insane complexity of it. While some of it is unavoidable, a lot of it really isn't. A lot of complexity exists as a means for vendors to make money. Traditionally this was consultancy and training money. It changed a bit with cloud vendors as they sell computing cycles tied to specific 'services'. But they too have no interest in promoting simple solutions, that would just make you buy less of their stuff.
Not too long ago 'proper corporate infrastructure' involved complicated things like dual-socket servers with two single core CPU's both doing work at the same time. That gaming rig probably runs 8 cores and 16 threads. Even that Raspberry Pi has 4 cores. So if you can't knock it up on a gaming rig and a couple of Raspberry Pi's changes are there something wrong with the infrastructure in the first place. Some people are working at Netflix, Spotify, Facebook, etc serving 100's of millions of users, but the fast majority of corporate stuff simply hasn't got that scale.
One difference is all the connections that go into such a system. If you need to know how to set up a distributed database which survives nodes going down, you will need to actually distribute a database and fail some test nodes. If the nodes are VMs, you can learn something. If your only fail test is unplugging half of your cluster and seeing what the other half does, you don't get to test that particular use case very well. And that's just one case where something needs a lot more hardware. Whenever there is a multi-system interaction, it's not something you can simulate on a couple Pis unless you're really dedicated to creating virtual networks which match the real ones and using containers or something like that so they're running all the systems which would be in separate VMs or servers in a real deployment.
While there certainly may exist black girls who are poor and also live in council blocks, this sentence came off as unnecessarily stereotypey. Also the sentence that follows seems to imply that "sons of the shire" are neither poor nor black, nor women.
Good points about the cloud, though!
AWS & Azure have been built to make setting this up like walking through an old style installation wizard.
For me the big thing is AWS & Azure are NOT your friends
They have their hand in your pocket so yes you can spin up and scale and auto deploy
But YOUr going to pay for it big time.
Franco, it's El Reg and their renowned irreverent style .... which is odd that it should be mentioned for someone who has been long enough here to know [since 11 April 2008]
Many regulars here would admit to finding it attractive* as well as also thought provoking whenever so many other information sources fail by imagining themselves to perfectly correct rather than understanding their opinion/editorial pieces are recognised as being probably also quite politically motivated to generate the support of a particular fiat currency income group.
* Yes, I know, it's weird isn't it so many be happy with that ? :-)
I don't see what irreverence has to do with invoking stereotypes about people, or with using language that is favoured by keyboard warriors as an insult to anyone who doesn't agree with them.
I am well aware of EL Reg's style, it's one of the things that has kept me coming back here for so long because lets face, IT news is generally a bit dry, plus most other sites do tend to fvour particular brands or ecosystems in a way not dissimilar to your politically motivated analogy above.
Rupert,
Beware and be aware of the fluffer and non-bluffer who may or may not be mad, and be able to driver one to madness, whenever you meet those who can greet one whenever appropriate with a sincere and welcoming "Hello cloud levels" ...... and hope that they be much deeper and more into CHAOS and COSMIC* Competition than contentedly wedded to the spreading of Mayhem and Manic Depression.
One a Friend and Greater Good for Embracing and EMPowerment, the Other a Resident Evil Foe for Exorcism and Extinguishing/Rebellious Extinction.
* .... Clouds Hosting Advanced Operating Systems and Control Of Secret Materiel in an Internetional Command
Oh, and I second and endorse that magic wand spell you be waving, Rupert, for all that you mention is already in place and firmly embedded in both secure and secret locations and easily made freely available.
One would normally think to suggest it be put first to government for employment and deployment, and they do love to tease themselves with the likes of a National AI Strategy although the endless talking Parliamentary shop model so beloved of a Congress and Senate is far too slow and tedious for anything worthy of dynamic and agile, so the private enterprise space and the entrepreneurial market place with its trillions to churn in order to earn and learn is the firm favourite for all such novel ventures.
One is then further presented with that embarrassment of riches which has one deciding on which state one prefers or is best prepared to boldly lead with proprietary intellectual property, a piratical private sector with more to share than can ever be conventionally commanded and traditionally controlled.
:-) One could also simply keep Registering it with updates to see who's smart enough to be more than just interested and prepared to be invested in order to be able to do something/anything about it/with it. :-)
> Skills training is often seen as being for people who don't go to uni, and unis are expected to turn out oven-ready workers
Uni has never done that. Never will. Not designed for it. Never has been. People who think that unis are there to turn out workers are insane.
What unis can do is turn out people who attack problems in a different way. That independence of thought is useful in a team of mixed experience. Also you don't have to go to uni to get that independence of thought; it's just one way.
Uni has never done that. Never will. Not designed for it. Never has been.
Depends upon which uni where, I could mention a couple of unis that actually do and where original thought is strictly forbidden.
People who think that unis are there to turn out workers are insane.
Or have experience with unis that do.
With further specific regard to the Dark Mattering discussed in Tiered IntelAIgent Strata for Total Information Awareness Fanatics, the embarrassment of riches available for mining and advanced processing for future AWEsome capabilities and abilities is not without its inherent difficulties whenever it is realised everything one may want can be provided and made readily available.
Something which the US military [in the public sector] and/or Amazon Web Services [in the private sector], which one is best assuming are not wondering and pondering alone in their thinking about such as be novel fields of endeavour, clearly bravely admits to ......
Shayn Hawthorne, space technology lead at Amazon Web Services, said there are many applications for artificial intelligence and machine learning in space that have yet to be conceived.“We all know we want to do AI/ML on orbit,” he said. “We know that we want to connect to everything, but we’re not sure of all of the different missions that we want to use it for yet.”
Engineers are not limited by technology but rather by concepts of operations, he said. .... Algorithmic Warfare: AI Key to Unlocking New Space Applications
Whatever to do next for the best of all can even tend to be problematical should one have any doubts or regrets about the supply of greater facility to A.N.Others.
'Tis the Field of Angelic Play with Daemons then.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
