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?

Comments

The Cloud is your enemy.

[Anonymous Coward]

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.

Re:The Cloud is your enemy.

[Whiney Mac Fanboy]

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.

Re:The Cloud is your enemy.

[GuB-42]

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.

Re:The Cloud is your enemy.

[Strider-]

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.

Re:The Cloud is your enemy.

[Jason1729]

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

And to bring us back full circle, this is why modern IT is a disaster, the entire point of this article.

Re:The Cloud is your enemy.

[lucm]

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

And to bring us back full circle, this is why modern IT is a disaster, the entire point of this article.

Want to see to what point modern IT is a disaster: the article we're discussing comes from cio.com, the land of clickbait slideshows.

Compare:

Buzzfeed:
-25 Things That May Help Soothe Your Broken Heart
-32 Kids Who Absolutely Nailed Halloween
-19 Pictures That Are Too Real If You Only Have, Like, $7

Cio.com:
-6 hard truths IT must learn to accept
-15 essential project management tools
-10 best places to work for women in technology

Welcome to hell

Re:The Cloud is your enemy.

[Zeromous]

Never heard of an on-prem cloud? Also, serious question, after Equifax, or any number of hacks, you don't seriously think your data is any better or worse off in a private LAN, that happens to be hosted in the cloud?

I'll admit the cloud is IT's enemy. But IT has to transform in to operations in the cloud. IT is dead. Anyone who doesn't is doomed to customer support, or worse.

Anecdotal- my IT job of like 25 years at the same place just ended a couple of months ago. And I'm not even the oldest relic. I worked in a heavily IT focused shop, data, and physical datacenter operations. I touched my computers all the time, got nice new toys, fancy facilities. For a long time life was good until I closed down my whole physical operations and moved them to some remote faceless facility where I will never touch them (or admin them) again. They will be supported by someone else using my documentation. They will eventually roll it in to some on prem cloud. Sounds sad, and it was kind of like a close friend dying. Anyone with a brain saw it coming but it happened so fast. Anyway it was as depressing as shutting down my multinode BBS for good.

But like getting used to how we roll on the Internet, I found a cloud job (kinda more fun than my old job) right away. Also, it seems that my years of IT experience and skills are terribly needed by the kids running the show amok. They are smart, adaptable, but do not work smartly all the time.

So, in short I've kept my enemy close, and I've learned it's ways. I've come to see my place among their ranks as a hip grey-ish beard. That didn't happen by me fearing the enemy. And life is good for this old BOFH

Re:The Cloud is your enemy.

[darkain]

The really only one counterpoint I've been able to find where cloud has consistently been a hell of a lot better than in-house hardware is for DNS hosting. Having globally distributed DNS servers hosting queries for my various web sites has been a dream compared to having to manage a DNS server locally. Yeah, it isn't "hard" to do, but when the cost has literally been less than $10/mo, vs the time of keeping a DNS server up to date and redundant across multiple local systems? Yeah, its a no-brainer.

Re:The Cloud is your enemy.

[Chas]

If you're concerned AT ALL about "security" or "latency"? Then no, The Cloud (AKA "OTHER PEOPLE'S SERVERS") is not for you. So yes, in those instances, The Cloud *IS* your enemy.

You simply cannot guarantee the security of any hardware NOT under direct control. And if they're VMs, it's doubly bad.

As for latency, as noted, Cloud offerings generally concentrate on "CPU" and "Storage".
Now, if someone's somehow, begun offering an ultra-low latency service, I haven't heard about it. Though I SINCERELY doubt the service is lower latency than "A room next door to your office".

Cloud computing is nice if you simply don't give a shit about your data.

If you do, then you need to look elsewhere.

Re:The Cloud is your enemy.

[Darinbob]

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)

Re:The Cloud is your enemy.

[Darinbob]

People did this before the term "cloud" was invented as a new service. The danger is putting everything in the cloud, from your corporate directory to the customer contact info.

There used to be this IBM commercial that I liked that had a bunch of seemingly clueless managers sitting around a table oohing and aahing about the magic pixie dust someone is selling. In real life, there are managers who treat the cloud like magic pixie dust, a way to fire the IT staff and auction off the servers.

Re:The Cloud is your enemy.

[stephanruby]

The cloud may be the enemy of your company.

But if you're an exempt IT employee in the United States, unpaid overtime is your real enemy.

Keep that in mind the next time a clueless manager wants you to install and maintain a system internally you do not know much about.

Re:The Cloud is your enemy.

[Z00L00K]

And putting your information in the cloud is not only putting all the eggs in the same basket but all your eggs in the same basket as many other companies including your competitors. So when the basket breaks it's one really sticky mess that can take years to clean up.

Re:The Cloud is your enemy.

[serviscope_minor]

If you're concerned AT ALL about "security" or "latency"? Then no, The Cloud (AKA "OTHER PEOPLE'S SERVERS") is not for you. So yes, in those instances, The Cloud *IS* your enemy.

Latency to where? With the major providers, you can rent things in various geographical regions, to give lower latency to your users if you haven't set up shop as nearby as the datacentre.

Also, the cloud providers have a decent record on security: there's plenty of badly set up servers, but that's on the user. The infrastructure is pretty sound. And the physical security is good. AWS for example is HIPAA compliant.

Re:The Cloud is your enemy.

[Wrath0fb0b]

You simply cannot guarantee the security of any hardware NOT under direct control.

Or you could build that into your threat model. For instance, I've seen a secure setup in which a plain off-the-shelf database was used to store data that was cryptographically pinned to an HSM. The database was then replicated into the cloud for availability and synchronization purposes. If you stole the data or otherwise compromised the cloud service, you would gain nothing but encrypted files for which you didn't have the keys. If you tampered with the data, you would trigger an integrity check. And this was within the realm of a small-to-medium sized company. Imagine my shock when a major player like Equifax just kept their entire database in the clear.

So yeah, you cannot guarantee the security of hardware that's not under direct control. But you can use hardware that's not known to be secure if you model it properly.

[ Or, in other words, the art of security is in writing down all the ways that things are insecure and working through them. Not by insisting that the officer printer/copier run SELinux and get regular kernel updates (hint: they write that software once and fuggedaboutit). ]

Re:The Cloud is your enemy.

[anegg]

I worked in corporate IT for a fairly large (40k employees) company back in the first half of the 1990s. The CIO would have new ideas regularly about what "we" should be doing (i.e., corporate IT strategy). After a while, we figured out that there was a strong correlation between whatever was recently in "CIO Magazine" and what the CIO's latest ideas for corporate IT strategy were. Unfortunately, it was difficult to have a conversation with the CIO about context and why not everything in CIO Magazine would work in our environment. Fortunately, a new issue of CIO Magazine would generate a whole new set of ideas, and the previous set would generally be forgotten. The one really big idea that came out in that timeframe (using HTTP/HTML to create a corporate information service) wasn't found in CIO Magazine. My impression of CIO Magazine was that it was like "Teen Beat" for CIOs.

Re:The Cloud is your enemy.

[barbariccow]

I just wanted to expand on that last point. Sometimes you should think about using an external database. Consider if your project will ever serve multiple requests at once, or run from multiple machines where synchronization/atomicy of the data is required. You'll save yourself a lot of redesign later by using an external database (which makes easy writing atomic and is by nature synchronized across systems). You'll save a lot of redesign / maintenance time later, and increase your ability to scale even internal tasks. Yes, there are ways to synchronize data across systems, and if it's read-only even something simple like NFS and a flat file would work. But they're needlessly extra-complicated and fragile.

I think far too many folks in IT are obsessed with the constant paradigm that "it needs to be done yesterday" and rush into quick hacks, which if you consider a business as operating in quarter-year segments, spending an extra few hours at the get-go making sure that you think about both immediate and near-future requirements can save a lot of time overall.

Answer

[Anonymous Coward]

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

Re: Answer

[lucm]

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.

Re:Answer

[Anonymous Brave Guy]

Also, IT is not Management, and is not there to be in charge and tell the people doing whatever your organisation actually does how to do their jobs.

Re: Answer

[Zeromous]

LOL this is the best one I heard all day. I spend my entire day cleaning up developer's messes and re-architecting (that would imply it was architected in the first place, right) their mindbogglingly stupid bottlenecks? And then fixing their code and pulling a branch for them.
Then I fix the database they broke with massive wads of binary data. Recovering their data from "sometime, naw shur". Then I pick up the phone in the evening to save their ass and their deadline.

Your computers boot because of good IT.

Re: Answer

[JaredOfEuropa]

So where were you when that particular project started up?! Instead of bitching at their mistakes and fix them late in the project, step in and prevent them before they happen. Don't berate the devs for being stupid, coach them to make them less so.

Not being there is not necessarily your fault of course. It's a fairly common mistake: not enough priority being given at the start of the project to proper design, management and staffing. Would you commission a bridge from a company that told you: "Our materials engineer is on sabbatical, but our welder Bob knows a thing or two about steel, let me tell ya!" That's what happens all too often in IT... IT can be a great profession because you do get the chance to try your hand at a great variety of things, but there's always the danger of overconfidence on part of yourself and your PM.

If it aint' broke

[ArchieBunker]

Then don't fix it. Seriously if something has been working fine for years, don't meddle with it.

Re:If it aint' broke

[H3lldr0p]

I have to disagree. You have to move with the technology, if you don't then you'll be caught when support ends.

Support always ends.

Products change. Companies change focus. Executives decide to leave markets that aren't profitable anymore.

Any one of those and you're SOL if all you care about is "ain't broke".

What needs to change? That attitude. The world is always coming up with new fools and new ways to break things. If you aren't on the lookout for ways to keep protected and to keep pace with how and why things have changed then you're fucked. All the way fucked.

Learn. Unlearn. Relearn.

Learn what's out there. See what it can do that yours already doesn't. See if you need that or if it's a nice-to-have.

Unlearn the old ways of doing things. Mainframes were good for their day but their day has passed. Keep your people in training. Keep them vital with new things to learn.

Which is what relearning is all about. Never let yourself stagnate. Get tired of doing one thing, learn how to do another. Refresh your knowledge.

And fuck that nonsense about "Ain't broke". It'll be broke soon enough. Better to know what to replace it rather than sitting around with your hands open.

Re:If it aint' broke

[Ichijo]

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

Re:If it aint' broke

[im_thatoneguy]

"Working" doesn't mean it's secure and maintained. E.g. Equifax didn't replace one of their ad tracking scripts and as a result were delivering malware when the company serving it went bust and forfeited their domains.

Re:If it aint' broke

[HornWumpus]

No.

Companies will only pay you more when you change jobs.

Work hard, care about results etc, but always be ready to jump. Loyalty to a company that will kick you the second they think they can replace you for a penny less, is for chumps.

Also never take counteroffers. The new job always has better future raise prospects. All raises are based, at least in part, on what you got coming in the door.

Re:If it aint' broke

[MrLogic17]

That's how you create Technical Debt.
Every upgrade cycle you skip makes the next one that much harder...

Re:If it aint' broke

[ArchieBunker]

At work we have a CNC machine that runs from a Mac SE with a 9 inch monochrome screen. How do you propose I "fix" that?

Re:If it aint' broke

[Gussington]

Then don't fix it. Seriously if something has been working fine for years, don't meddle with it.

Like steam trains. They still work, so why bother with cars and planes etc...

Re:If it aint' broke

[Darinbob]

One way of putting it is, "if it ain't broke, we don't pay you to fix it".

I swear, not lying, I had to deal with three cases of the same developer changing code to "fix it" that resulted in extremely damaging bugs that hit some of the biggest customers in the face (think permanent loss of data and bricked products). And all three occurred in the same month! No one asked for the fixes, although for one of them he kept complaining over and over that it needed fixing until the manager relented. The guy also seemed to be unable to understand the K.I.S.S. principle.

Re:If it aint' broke

[HornWumpus]

And you had to put your soul into escrow.

When things are hot, they move pay grades up, without even considering raising the pay of existing employees in those grades. I've found no exceptions to this rule. They will pay what the market demands for new hires of dubious quality, while giving small raises to proven staff. Only a fool would hang around.

Just not too often, got to make the jumps worth it.

Never burn your coworkers, not the good ones anyhow, that's were good new opportunities come from. Fuck the managers though.

Re:If it aint' broke

[scsirob]

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

The world is messy

[mrwireless]

I used to be an IT person, but have spent time in the humanities too. From that experience, I'd say the biggest lesson of all is that often more technology is not the solution. And that as much as we nerds like to think we are rational, we often fall into the trap of being religious about our belief that all a situation needs is more tech. The humanities - ethnography, sociology, philosophy - have valuable insights to offer into the complexities of human society.

Now when I see thing like the blockchain I see projections of ideology, and very little real understanding of the complexities of politics, ethics and social norms. To a nerd, all of that is noise, something that ideally shouldn't be there.

To learn more about this, search for the 'technological determinism vs social contructivism' debate.

Re:The world is messy

[PPH]

The humanities - ethnography, sociology, philosophy - have valuable insights to offer into the complexities of human society.

Now when I see thing like the blockchain I see projections of ideology, and very little real understanding of the complexities of politics, ethics and social norms.

Reading that another way: You need to understand the social interactions and interpersonal relationships involved with the current process before you can re-engineer it. That guy with the overflowing in-basket through which paperwork barely flows. And what the hell does he contribute to the work process anyway? What exactly is the value of his 'APPROVED' or 'DENIED' stamp? Answer: He's the division head's golfing buddy. And if you really researched the sociological reasons for his existence, you'd understand why going around him or agitating for his removal from the workflow is political suicide. You'd be better off waiting until the BOD gets so pissed at your division's slow response that they ship the whole process to Bangalore.

Anecdote: I worked with a guy who had 'automated' a parts approval process in an aviation company. To go through the new process, you had to submit all the proper test reports, engineering and FAA approvals before the new part could be used on an airplane. The resulting rage from manufacturing was palpable. "What do you mean I can't buy parts from my buddies' company and sneak them into inventory??!!" All of the people involved in developing the new process had committed career suicide and were basically laying low until retirement.

Programmer time isn't fungible.

[tietokone-olmi]

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

We are blue collar workers

[gurps_npc]

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.

Re:We are blue collar workers

[Gussington]

Basically, we are more like plumbers than doctors.

We really should unionize.

I disagree. We are neither plumbers or doctors, but a 'blue collar' job was one with very little skill, or a skill learnt once after high school then used for the rest of your life (plumbing, mechanic, sparky etc) Under such fixed conditions, exploitation is easier so unions serve a useful protection mechanism.
But because IT moves so fast (most products I learnt at Uni were obsolete by the time I left), the game is self sustaining (ie smarter people tend to succeed) so don't need the same protection.
In this environment, protection of a union would merely hold people back.

Agile is bullshit

[Anonymous Coward]

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.

Re:Agile is bullshit

[mhkohne]

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.

Re: Agile is bullshit

[sheramil]

...the reason you stand for a meeting is to keep it short by making it physically uncomfortable for the participants. Standing is actually doing exactly what you want: reducing meeting time.

Then why not reduce meeting time further, by making it more physically uncomfortable? Set fire to anyone who shows up.

Re:Agile is bullshit

[phantomfive]

Scrum is pure shit though. That's usually what PHBs mean when they say 'Agile'.

The key realization that clarified the purpose of Scrum for me was that it is entirely designed to goad people to work. It is designed for people who will surf Slashdot all day, and not get things done. It uses both carrots and sticks, and constant prodding to get people who lack self-control to constantly refocus on the task at hand.

That is entirely why I hate it. For self-motivated people, it gets in the way.

Re:Agile is bullshit

[famebait]

Not Agile. SCRUM is waterfall wrapped in BS.
More specifically, it was designed as a way to sneak agile practices into a waterfall-organisation resistant to change, so it tries to provide at least some of what that environment demands with as low a cost as possible. It is debatable whether it achieves this.

Agile doesn't have to be scrum.
Adopting the ceremonies of Scrum does not make you agile.
If your organisation already understands agility, you don't need Scrum.

Agile is just a set of values, many of them really really important IMO.
Some of them seem like common sense now, but you have to see them in the light of the bloated old proceses they rebelled against.

The core philosophy stands up just fine and will continue to do so:
- Deliver value early and frequently. This reduces risk, maximises payoff, maximises learning, and keeps you nimble for when you need it.
- Accept uncertainty, and handle it by making sure you can adapt quickly, not by excessive up-front planning which doesn't work anyway. Sometimes you need ballistic calculations to arrive at where you want, but most of the time a steering wheel will do the job cheaper, quicker AND better.

Standup metteings have nothing to do with anything.
They are just a quick band-aid if you have a culture problem with status meetings dragging out or carrying too much overhead. They can indeed be a better quick-fix for that than just nagging (whether you're trying to be agile or not), but you should probably also be looking at whether the meeting needs to be so frequent, if everyone needs to be there, if the meeting is needed at all, and whether other information flows bothering fewer people would be a better tool.

Re:Agile is bullshit

[HornWumpus]

Scrum is formalized micromanagement with no flexibility for those employees who don't need constant short term goals.

Combine that with the only part of Agile that managers comprehend ('talk to clients all time, weather vane the plans') and you are truly fucked. Be at -4 (active sabotage) on the process immaturity model in no time.

People are expensive

[im_thatoneguy]

Throw it away, Reboot it, Buy that software, Replace that finicky ___. Don't be the "hero" who spends 3 days debugging something which can be replaced for $500.

Re:People are expensive

[mhkohne]

Careful with that - yea, 3 days debugging something that's cheaply replaceable is bad, but throwing out gear every month or two because you don't really understand what the hell is going on can be much worse, because you haven't actually solved the problem.

Re:People are expensive

[mattb47]

Unfortunately, your bosses may feel otherwise. If there's isn't a way to easily expense that $500 widget, then you're stuck doing that 3 day job.

This is horribly inefficient, but this is often typical of corporate America.

Microservice Hype

[Tablizer]

"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.

Re:Microservice Hype

[Tablizer]

Now 2 years from now when you realize there was a technology problem in fetching prior months because whatever version of Python/Ruby/Rust/Java/whatever has a security issue in a function that's used only for that part, you can move it to an arbitrary other technology

But it's less total effort to wait UNTIL such happens and split just that part out. Why bloat up 29 interfaces just to make ONE easier to split out? I don't see the effort math working for you.

It's kind of like packing for a vacation to an unknown destination such that you have to carry winter, summer, beach, scuba, snow clothes/supplies, etc. Lotta baggage to service the Crystal Ball Gods.

The idea has been around for about 2 decades in the form of XML-web-services and SOAP. They have not proven their general meddle after 2 decades. Changing protocols won't suddenly make the idea useful because the protocol wasn't the bottleneck causing their failure to begin with, but rather more complex interfaces and the language/protocol conversion overhead. (Yes, they have niches, like everything else.)

Sorry, 2 decades is long enough to test the idea already. It failed. Move on.

Re:Microservice Hype

[Shados]

For one, WSDL/SOAP web services back then weren't used the same way. They were generally used to split apps in "tiers" (eg: business logic, frontend, data layer). Sometimes someone would extract a few more for scalability or whatever.

That's why "the cloud" (things like AWS) is an enabler here. You didn't have that back then.

We're not talking splitting the app in 3-4 pieces. I'm talking splitting an app maintained by 100 devs in 2500 services. Effortlessly (thats the key and the only reason its viable).

Tools like Mesos/kubernetes and continual deployment setups make this viable.

At work, if I want to make a new service, it's not much more difficult than adding a function: Run the generator, open the service, add some code, push, hit a button or type something in slack. Done.

We're talking 2 minutes (and on that, 1 minute is the time it takes for IntelliJ to open. You can cut that down using vim, lol). We deploy services and apps to production an average of 12 times per day per developer. Because it's "free" to do.

Microservices are completely non-viable if you can't do that. If you don't have the infrastructure to do it. You need to get the benefits without paying a significant cost.

Doing it like we did it 20 years ago (yes, I was a out of college then too) would have been batshit insane. And splitting stuff in just a few pieces isn't the same.

To make an analogy, it's like comparing svn branches to git branches. I wouldn't make 15 branches a day in svn.

Some things to learn

[WillAffleckUW]

1. State actors never have your own best interests at heart.

2. Frat tech boys will always get their feelings hurt. And whine whenever they aren't winning massively.

3. Comment your code. Always. And stick to naming conventions, it saves a lot of time - for you, and for others.

4. Low cost index mutual funds and ETFs will always outperform actively managed stock and bond funds. Property will always outperform all of these in areas of high population and job growth. You can't take it with you, so don't buy a house you don't need until you actually need it, and never look back.

5. Lists are for people who have problems. Which is, quite frankly, everyone.

6. Take showers and brush teeth/hair. Don't wear shirts or underwear more than one day. Keep spares at work or a gym if that's hard to do.

Hard Truth: Be a lifelong learner or get out of IT

[ErichTheRed]

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.

Hot Take Below

[bistromath007]

San Francisco tech startups have a serious problem with gender equality nearly as bad as the one in Hollywood, but the rest of the United States doesn't, so they can shut the hell up with their hypocritical political garbage.

Re: Hot Take Below

[bistromath007]

They're the ones bothering us about it, yet they're consistently shown to be the worst examples of it whenever something leaks. Given all the other ways Silicon Valley and Hollywood seem completely oblivious about how the real world works, I am definitely inclined to believe they're huffing farts in this case as well.

2 of the hardest IT problems : poseurs and leeches

[tobybot11]

I've worked on IT problems for a very long time.. coming up on 30 years here soon. In all sorts of contexts, academic, government/miltary, ISPs, ASPs, cloud providers, SaaS entities, traditional IT departments, telcos.. you name it. Ever work at a company that has 64 different billers and no plans to ever consolidate? Ever work on an awesome tool only to have it replaced by index cards because the guy in charge was afraid of computers? Ever build a perfectly capable monitoring/management platform only to have it replaced by an entirely substandard version because yours 'wasn't invented here'? Ever watch as a vendor takes big chunks of a companies money every 3 years because no one remembers the last time said vendor couldn't deliver even though it was only 3 years ago? Ever watch project after project fail because anytime any modicum of project management is applied or development methodology attempted all progress comes to a screeching halt? I have and I can go on endlessly... with examples of IT failures and very rarely, IT's successes. To sum it all up, to me, all forward progress in IT is made by people who actually know what is going on ( both from a technical and from a business/political/social perspective) .. and generally, all hard problems associated with IT are caused by the poseurs and the leeches ( in either domain ). 2 examples of poseurs.. execs that use vendors to do everything for them, including thinking for them .. or the 'X specialist' that refuses to learn the 'Y domain' because of the 'religion/supposed magic/history/tradition around X' .. 2 examples of the leeches.. the person that blocks any attempt to introduce something new or fix lingering issues because they want to protect their job.. or generally 'project managers/scrum masters/etc.' For me, the team/module is too big if you can't run it or extend it with 8-12 people .. beyond that the overhead causes everything to cave in ( not a new concept .. see MMM's surgical team concept from 1976) .. I can go on endlessly. The low point of the poseur/leech problem is this recent love affair people have with 'imposter syndrome'... it's as if the poseurs and leeches are wanting desperately to rationalize their reason for hanging around and have created this sad justification. Let's rather focus on the 'burden of the expert'.. having to constantly claw your way thru all the artifice and detritus stood up by the imposters and instead find a way to clear these folks out, make IT into a real engineering profession, and then finally automate and converge IT away as was promised long ago .. and not have IT itself leech off the system forever with teams re-developing every possible thing over and over again in the next new fad methodology or language. Sorry for the rant.. IT could go on forever. :-)

Re:People matter most, and there aren't enough

[lucm]

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.

IT security is not a beginner's game

[gweihir]

But actual experts are expensive. Stay away from IT "security experts" that cannot code, that cannot configure a network or a firewall, that cannot administrate a system, mailserver, DNS server or webserver and that do not understand how crypto works and what it can and cannot do. I have seen far to many of these people and they universally make things worse in the long run instead of better.

Re:DevOps is out, DevSecOps is in

[Darinbob]

DevSecOpsJanitorIT?

Re:People matter most, and there aren't enough

[Nethead]

Where are the wikipedia nazis when we need them?

They became write supremacists .

Bottom of the food chain

[DerekLyons]

IT is a support function - it's job is to keep the rest of the company moving.

Re:Hard Truth: Be a lifelong learner or get out of

[swb]

I think this is right, but choosing a vendor/technology to beef yourself up on, especially on your own time, feels like playing roulette -- you have to put it all on 23 red, essentially, to develop anything remotely like "expertise" and then *hope* that whatever you've invested in is "the thing" that your management, industry to even employment region, decides is the thing they will invest in.

It used to be a higher-percentage bet that whatever you invested in would have a good chance of paying off. But I've seen too many people buying into something only to find out it doesn't pay off because it turns out to be marketing BS or winds up in reality being not the economic choice people with money want to make (or, you seldom lose betting that management is cheap).

The other thing is that I mostly reject the notion that self-investment in most technologies produces anything like expertise, with the possible exception of software languages where there's a lot more opportunity for in-depth implementation. I run into plenty of people who are certification/video/example experts but who really have zero grasp of the logic/rationale of operational choices and real-world applications. And in many cases, it's not their fault but the reality of extremely expensive equipment, restrictive software licenses, and the hard reality of separating hype from fact in real-world implementations.

For a lot of IT technology you need a lot of time and an awfully big sandbox to think you've developed any "expertise" in a particular technology. I'm increasingly convinced that only real-world production experience counts as actual expertise.