Slashdot Mirror


Ask Slashdot: What Are Some Hard Truths IT Must Learn To Accept? (cio.com)

snydeq writes: "The rise of shadow IT, shortcomings in the cloud, security breaches -- IT leadership is all about navigating hurdles and deficiencies, and learning to adapt to inevitable setbacks," writes Dan Tynan in an article on six hard truths IT must learn to accept. "It can be hard to admit that you've lost control over how your organization deploys technology, or that your network is porous and your code poorly written. Or no matter how much bandwidth you've budgeted for, it never quite seems to be enough, and that despite its bright promise, the cloud isn't the best solution for everything." What are some hard truths your organization has been dealing with? Tynan writes about how the idea of engineering teams sticking a server in a closet and using it to run their own skunkworks has become more open; how an organization can't do everything in the cloud, contrasting the 40 percent of CIOs surveyed by Gartner six years ago who believed they'd be running most of their IT operations in the cloud by now; and how your organization should assume from the get-go that your environment has already been compromised and design a security plan around that. Can you think of any other hard truths IT must learn to accept?

17 of 421 comments (clear)

  1. The Cloud is your enemy. by Anonymous Coward · · Score: 5, Insightful

    The Cloud is your enemy. Fire anyone who offers a "cloud" solution before offering an in-house solution, because I can guarantee you that "cloud" services are only half as efficient as running the hardware in-house. The question really is where do you want your data to be.

    If you have privacy concerns (eg credit cards), then machines dealing with credit cards should be co-located in a high-security data center that you know who has physical access to it. If you are simply serving cat videos, then cloud-away, because nobody is going to care if a cat video is slow due to bad provisioning.

    But every time, it seems like I have to fight someone as to why it's cheaper to own or lease the hardware in-house rather than "cloud it", because cloud services are not as scalable as you believe it to be. The "cloud" only scales two things efficiently. CPU "TIME" and "Storage Capacity". If your IT is not concerned about these, then it doesn't belong in the cloud. If you are concerned about security or latency, those must never go into the cloud.

    If you are crunching numbers, it is cheaper to borrow the CPU power of 500 computers for one day than it is to buy two computers and have them take one year. That is where "cloud" computing is supposed to be used.

    Instead we have the morons of IT management trying to put everything into the cloud so they can eliminate IT staff, and the cost of doing this is that when mistakes are made (eg equifax) , nobody knows how to fix it, and it costs substantially more to fix by hiring new staff just to solve one problem.

    1. Re:The Cloud is your enemy. by Whiney+Mac+Fanboy · · Score: 5, Insightful

      Fire anyone who offers a "cloud" solution before offering an in-house solution, because I can guarantee you that "cloud" services are only half as efficient as running the hardware in-house.

      But then give a bunch of examples where the cloud is actually better than in-house - eg:

      * If you are simply serving cat videos, then cloud-away
      * it is cheaper to borrow the CPU power of 500 computers for one day than it is to buy two computers and have them take one year.

      Fact is, buying computer services off other people (which is essentially all the cloud is), makes a ton of sense for all sorts of applications.Be sensible, and see if your use case fits the model of your vendor.

      If you're as absolutist as "The Cloud is your enemy," then you're not suited for a job in modern IT.

      --
      There are shills on slashdot. Apparently, I'm one of them.
    2. Re:The Cloud is your enemy. by GuB-42 · · Score: 4, Insightful

      If you have privacy concerns (eg credit cards), then machines dealing with credit cards should be co-located in a high-security data center that you know who has physical access to it. If you are simply serving cat videos, then cloud-away

      I would argue the opposite, especially if you are a small company.
      You probably can't afford a team of security experts, or have any control on who accesses the data center where your machines are. Large, reputable cloud companies can.

    3. Re:The Cloud is your enemy. by Strider- · · Score: 5, Informative

      I would argue the opposite, especially if you are a small company.

      This exactly. I work with a midsized non-profit (roughly $3,000,000/year revenues), and we didn't do credit cards for years because we didn't have the ability (or desire) to have to deal with the security hassles associated with them. We finally found a good partner/vendor and were able to outsource the credit card portion of our online operations to them, and with the long delayed arrival of proper EMV terminals in the US, we can finally handle them on-site without having to take absurd security precautions.

      In effect, the unencrypted/unsecured cardholder never, ever, touches our networks or computers. All we get from the payment processor is a hash that confirms the payment, and allows us to reconcile and/or reverse the charge if needed. It works great, and is far more secure than something I could have rigged up as a volunteer.

      --
      ...si hoc legere nimium eruditionis habes...
    4. Re:The Cloud is your enemy. by Darinbob · · Score: 4, Interesting

      If you don't care that all your data vanishes and can never be recovered, then the cloud may be a good idea. But most companies don't fall into that category.

      I agree that being an absolutist is bad, and often I see the cloud being used as an absolutist solution to downsizing IT staff and resources. The flaw is in not thinking when the latest buzzword is worth adopting or not. There are not many uses where the cloud works, because of the security concerns, not just security of keeping eyes away but security of keeping the data intact.

      If you do use the cloud, do not use it as a substitute for having backups. Make your own backups and have them stored off-site. Always have a plan on what to do when the cloud service fails; can you switch to another service quickly, or rely on slower local computers? Even if the internet goes down for several hours, you should still be able to get work done locally, phone calls can be made, products can be shipped, etc. Believe me, from experience it is annoying to be stuck without access to your own data and documents that you thought were local, while waiting for the local telecomm company to fix the lines that got cut.

      (Yes, DARPA researched networking protocols as a way to route around problems, but the modern internet sometimes seems like more of a loose collection of star networks)

  2. Answer by Anonymous Coward · · Score: 5, Insightful

    >> What Are Some Hard Truths IT Must Learn To Accept? ...that IT is not engineering, and that engineering is not IT.

    1. Re: Answer by lucm · · Score: 4, Funny

      most developers these days couldn't develop themselves out of a "hello world" problem.

      hello world is easy: just do serverless micro-services with an api in the cloud and docker-compose machine learning using babeljs. The only tough part is picking the right spotify playlist while you code your brains out on that macbook.

      --
      lucm, indeed.
  3. Programmer time isn't fungible. by tietokone-olmi · · Score: 4, Insightful

    Software engineering cannot be squeezed into formulas for plugging and chugging.

  4. We are blue collar workers by gurps_npc · · Score: 4, Insightful

    If you don't work for a tech company, you are a blue collar worker not a white collar worker.

    Even if you do work for a tech company, if you are not a manager or a high level designer, you are a blue collar worker.

    Basically, we are more like plumbers than doctors.

    We really should unionize.

    --
    excitingthingstodo.blogspot.com
  5. Re:If it aint' broke by Ichijo · · Score: 4, Informative

    But if you don't understand why it works, then it may fail in a mysterious way at the worst possible time.

    --
    Any sufficiently unpopular but cohesive argument is indistinguishable from trolling.
  6. Agile is bullshit by Anonymous Coward · · Score: 5, Insightful

    1) Agile is bullshit
    2) You do not need to have meetings every day
    3) Standing up for a meeting is utterly ridiculous
    4) Iteration Managers are a very poor replacement for Project Managers
    5) Scrum Masters are a crock. You should not hire these people
    6) Kanban is a bullshit methodology
    7) Hotdesking sucks. Treat your staff well and give them their own desk.

    1. Re:Agile is bullshit by mhkohne · · Score: 4, Insightful

      Yea...And you use, what? Traditional waterfall? Make-it-up-as-you-go?

      Yes, the people trying to SELL you Agile are full of shit, and NO, it won't fix your problems. It IS a useful way to look at things, if you apply it like a human being with brains instead of a procedure monkey.

      I'm gonna give you the hotdesking one - I can't envision where that isn't a completely pain in the ass.

      --
      A thousand pounds of wood moving at 300 feet per minute. Don't get in the way.
  7. Microservice Hype by Tablizer · · Score: 5, Insightful

    "To truly take advantage of the cloud, software needs to be architected and implemented differently, using microservices instead of monoliths."

    You mean convert all your API's into JSON calls and spin up gajillion web services? Why? That increases complexity. Native-app-language-to-native-app-language is much easier than app-language-to-JSON-back-to-native-app-language.

    Can't cloud do monolith? If not, what's stopping it? The performance bottleneck usually is and should be the database anyhow for must CRUD apps. Kajillion web services won't solve that. The CAP Theorem (Eric Brewer) limits your options and probably shouldn't be an app-side concern anyhow, but mostly a database side issue.

    This kind of hype created a bloated stack in our org that requires dealing with 4x more code than a normal stack would. Nobody can give practical examples of the use of such splitting: they just spit out vague buzzwords stolen from Dilbert's boss, or dreamy shit like "what if we grow to Amazon.com size"? -- Yeah Right. We are more likely to get hit by a meteor while buying a lottery ticket on a unicycle.

    Plus, these extra web layers seem a security risk: more doors for hackers to pick the locks of. Who is spreading this microservice rumor/hype? Russians? Microsoft marketers? Wrox? Knock-it-off!

    Martin Fowler said:

    So my primary guideline would be don't even consider microservices unless you have a system that's too complex to manage as a monolith. The majority of software systems should be built as a single monolithic application. Do pay attention to good modularity within that monolith, but don't try to separate it into separate services.

    As far as general IT advice:

    1. Data tends to outlive application software, so focus on good data.

    2. Be wary of wasteful hype. Let somebody else be the guinea pig. When that somebody else has it running well, THEN borrow the idea.

    3. Books are judged by the cover for good or bad, so throw the executives a pretty bone for a few high-visibility parts of a system, but keep most of the regular stuff (grunt screens) in something easy to create and maintain. Don't drag down the entire system chasing eye-candy and UI fads. By the time you're finished, it'll be obsolete anyhow.

    4. "Separation of Concerns" is a myth. Most non-trivial concerns inherently inter-weave among each other. You want to manage concerns well, not outright separate them with thick Trump Walls.

  8. Hard Truth: Be a lifelong learner or get out of IT by ErichTheRed · · Score: 4, Insightful

    I'm 42, so I'm officially an old fart when it comes to my IT job. I'm in a senior engineering/systems architect job and one of my favorite aspects of it is my unofficial duty to impart wisdom on the newbies. My "hard truth" about IT that surprisingly few people truly grasp is that you can't get comfortable being the expert at one particular thing and coast. Even 10 years ago you could do that...I know so many people who make more than I do jumping from contract to contract doing CCNP-level router work or being the "EMC/HPE/IBM storage wizard." The formula for success used to be to pick a vendor, steep yourself in the technology, then get and keep certifications while learning what's new every few years. This is rapidly going away...regardless of what you think of cloud, CIOs hear the magic word "OpEx" and suddenly all that on-premises hardware and knowledge is out the window. For years, I did a combination of Windows Server, Citrix XenApp and System Center as my core skills, while trying to learn as much as I could about other areas. Even that has changed so much in the past couple of years...desktop apps are being replaced with web apps, containers, APIs, anything that abstracts the client layer and makes it look and act like a smartphone.

    These days, one of my jobs is to do the systems design for a huge project in Azure. Anyone thinking they can just pick up a cloud provider's stack of tools overnight is in for a bit of a shock. Couple that with the fact that all the cloud vendors are releasing whole new features every week and existing features change almost as often. Part of my job has been trying to get as many of our engineering staff on board for learning cloud stuff, and it's been a challenge with a couple of people.

    Keeping up with all the knowledge needed to be the guy they keep on staff when all the routine work is offshore is hard. I have had to dedicate a lot of off-work time to it, because no company trains their staff anymore...one of the things I hate about IT not being recognized as a real profession. The reward for doing this is a very interesting job and, not surprisingly, a higher-pressure firehose to learn from. :-) Being a dad on top of this is tough also...it requires lots of time management, late night reading and watching videos at 2x speed to do this and be a functioning parent.

    So yeah...if you want to keep an IT job, especially as things get more and more abstract, broaden your skill set and learn as much as you can get your brain around.

  9. Re:People matter most, and there aren't enough by lucm · · Score: 5, Funny

    I'm sure those blog posts from 2008 are fascinating, but when I see someone plugging twice his own blog in a Slashdot comment, it's an immediate SEO red flag.

    This led me to google "Bruce F. Webster", and wow, dude did you really create your own Wikipedia entry using your own blog as source?

    There's nothing in your bio that even remotely justify a wikipedia article, that's more like a LinkedIn profile.

    https://en.wikipedia.org/wiki/...

    if I wasn't a lazy bastard I'd edit your page to flag it as a WP:PROMO.

    https://en.wikipedia.org/wiki/...

    Where are the wikipedia nazis when we need them.

    --
    lucm, indeed.
  10. Re:People matter most, and there aren't enough by Nethead · · Score: 5, Funny

    Where are the wikipedia nazis when we need them?

    They became write supremacists .

    --
    -- I have a private email server in my basement.
  11. Re:If it aint' broke by scsirob · · Score: 4, Insightful

    Everything is broken. The fact that you have not noticed it yet doesn't change this.

    --
    To Terminate, or not to Terminate, that's the question - SCSIROB