Ask Slashdot: What Are Some Hard Truths IT Must Learn To Accept? (cio.com) 421
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?
The Cloud is your enemy. (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.
Re:The Cloud is your enemy. (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.
Re:The Cloud is your enemy. (Score:4, Insightful)
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: (Score:3)
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. (Score:4, Informative)
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: (Score:3)
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 t
Re: (Score:3)
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
Re: (Score:3)
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
Re:The Cloud is your enemy. (Score:5, 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)
Re: (Score:3)
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: (Score:3)
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 int
Re:The Cloud is your enemy. (Score:5, 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.
Re:The Cloud is your enemy. (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.
Re: (Score:3)
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: (Score:2)
If you're a small company that can't afford security experts you have no business putting secure data out on the internet PERIOD.
Re: (Score:3)
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
Re: (Score:3)
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: (Score:2)
Cloud is clearly an attempt to lower headcount costs. The concept is converting the network from physical to virtual and banking on end-state automation (network elasticity, dynamic scalability, geographical redundancy and the like) to make a stronger and cheaper network to run.
Just like all snake oil - the promises have outpaced the reality due to a number of factors, including the assumption that all problems are suitable for the original design, coupled with lack of engineering when it comes to planni
Re: (Score:2)
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.
Like electricity generation, water purification and sewerage....
The hard truth is that a lot of "IT people" make stupid comments like this then wonder why no-one in the business respects their opinion.
Re: (Score:3)
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: (Score:2)
Not that I don't believe you. But if you were doing it, and doing it SUPPOSEDLY "right" on AWS, why is it that you speak about it in the past tense? Hmm?
Re: (Score:2)
But amazon has not put armored shields around the wires all the way to my computer. Accidents will happen. A backhoe will sever a line and the whole block will be without internet for a day or more. Amazon can't fix that. If you're a company that has real products to design, build, and ship then you should be able to continue working even if that accident happens because the data should be local, even if it's not as fast as it once was. If you have it all in the cloud then you may as well give everyone a
Re: (Score:2)
Answer (Score:5, Insightful)
>> What Are Some Hard Truths IT Must Learn To Accept? ...that IT is not engineering, and that engineering is not IT.
Re: (Score:3)
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: (Score:3)
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 g
Re: Answer (Score:4, Insightful)
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.
Re: (Score:2)
Also, developers are not operators, and operators are not developers.
(meanwhile both operators and developers are pissed at Gerry in IT)
Re: Answer (Score:5, 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.
Re: (Score:2)
Are you doing simple stuff? Do you have a lot of free time to do the remedial training of basic skills? Are you really hiring those C- average students?
I do embedded systems. It's very hard to find a new grad who's ever seen C or C++, much less having seen any hardware or assembler. It is quite common that they're just not cut out for the work. I remember one new coworker who would complain "I never learned how to do this!" Now I like a little whine now and then but that was pretty silly.
Re: (Score:2)
Operations gets near the production machines, IT should stay away too. Of course, a lot of companies are confusing the two these days.
There is nothing wrong with the tag (Score:2)
in HTML. There. I said it.
IT is out, DevOps is in (Score:2)
Re: (Score:2)
Is that all that is? I have long been struggling to figure out what the heck that trendilicious phrase meant. Thank you.
Re: (Score:3)
DevSecOpsJanitorIT?
If it aint' broke (Score:3)
Then don't fix it. Seriously if something has been working fine for years, don't meddle with it.
Re: (Score:3, Insightful)
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 t
Re: (Score:3)
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: (Score:2)
The hallmark of a typical programmer. Get in. Build a new app. Put it into service. Add it to your resume. Get out before the first wave of bug reports come in. Rinse and repeat.
If you don't see yourself as being responsible for a product or process, maybe this lifestyle is OK. But if you like to take responsibility for something and continuously improve it, you are more valuable to a company. And you develop a skill set that makes you even more valuable as you move from project to project. And that means
Re: (Score:3)
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: (Score:3)
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
Re: (Score:2)
This is why software engineering is still seen as an immature field compared to other engineering disciplines.
Re: (Score:3)
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 se
Re: (Score:2)
Admit it, our profession is a joke. We are con artists working for con artist peddling the latest craze.
It was true, until IT became a two-speed enabler of business outcomes using digital twins.
Re:If it aint' broke (Score:5, Informative)
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 (Score:4, Insightful)
"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 (Score:4, Informative)
That's how you create Technical Debt.
Every upgrade cycle you skip makes the next one that much harder...
Re: (Score:3)
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...
Comment removed (Score:5, Insightful)
The world is messy (Score:2)
Now when I see thing like the blockchain I
Re: (Score:3)
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 understan
VocTech is the future. (Score:2)
IT going forward doesn't need a dozen people with BS degrees. When you're building a house you only need so many civil engineers and architects. At some point you need a fleet of plumbers, electricians and general contractors. Some people insist that a BS is required so management finds the cheapest BS they can. For 10% of my job I would love to hire a 17-18 year old apprentice and just train them in the hands on tools.
I don't need a BS. I don't need an Indian. I just need someone thirsty and willing to le
Re: (Score:2)
Re: (Score:2)
HR people are the _cause_ of HR problems, not their solution.
The solution is to take hiring away from HR, they can manage benes etc. All they're good for.
Re: (Score:2)
Where did I say anything about licensing? I said a BS.
The days of taking 16 year olds and training them on the job vanished about the time we transitioned from an agrarian society to a manufacturing society. Sure - some jobs will give you job-specific knowledge - that may or may not help you at your next gig when your current employer goes bust.
I had it in the 90s. What exactly 'disappeared' about it? I learned to solder, debug embedded controllers, a host of other skills that have come in handy since.
They want employees with a broad-based industry knowledge.
How's that working out for IT? It sounds like it's a hard truth that IT must learn.
Re: (Score:2)
Using your house-building analogy, if the conventions for blueprints are non-standard or different for each house, then the skills needed by the plumbers, electricians, etc. will be higher.
You over-estimate how accurate blueprints are. The good plumbers, electricians, etc all know how to handle the edge cases. A good plumber can walk into a plant that has pipes shoestringed everywhere and fix the problem no problem.
Hands on training is actually a lot better for your 'bicycle science' stacks. Go look at the electrical and plumbing work in any building from the 1900s that is still in use as a factory. It's where thinking on your feet is a lot better than book smarts. Most PhD grads I know shut
Programmer time isn't fungible. (Score:5, Insightful)
Software engineering cannot be squeezed into formulas for plugging and chugging.
Fred Brooks knows (Score:2)
Forgot a few (Score:2)
While there are a lot of problems with the way IT is done in companies today, my experience has been that the companies who pay the least for IT (as
Your Way Doesn't Matter (Score:2)
We are blue collar workers (Score:5, 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.
Re: (Score:2)
Blue Collar Workers w/o a conscience sometimes (rarely) choose to cheat to get their "retirement." But it is the IT manager's nightmare. In other words, IT management ain't ever gonna be easy.
Re: (Score:3)
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 t
Agile is bullshit (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.
Re:Agile is bullshit (Score:5, 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.
Re: (Score:2)
Agile is a manifesto, full of truisms.
Scrum is pure shit though. That's usually what PHBs mean when they say 'Agile'.
A good team will produce results regardless of formal methodology, a bad team can't be fixed with daily standups or _any_ other simple step. They will just game it into a time waster/excuse for not getting results. (e.g. I'm hungover...don't want to work today. Gonna restart an argument in the standup, that will burn the morning. Everybody will have zero productivity, not just me.')
Re: (Score:3)
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: (Score:3)
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.
Re: (Score:3)
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 re
Re: (Score:2)
Excellent list. Here are my additions
8) If you can't afford to give your employees at _least_ 2 monitors EACH then don't be surprised when they leave
9) Likewise if you aren't willing to explore standing desks and/or other ergonomics likes keyboards/mice, you don't deserve your workers
10) People are an ASSET and INVESTMENT; not an "resource" to be strip-mined
11) There is never time to do it right the first time, but there is always time to do it over -- Murphy's Computer Law
12) Ignoring a problem doesn't ma
Re: (Score:3, Funny)
...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.
codebase is more important functionality (Score:2)
You could have a hideous frankensystem that grants golden penis wishes and you will go bankrupt trying to maintain it if you don't let those two skinny guys and that fat guy convert it to Rails, then Angular, then React every 6 months.
People are expensive (Score:3)
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: (Score:3)
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.
Microservice Hype (Score:5, Insightful)
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: [martinfowler.com]
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: (Score:2)
Can use anything, doesn't have to be JSON. Any network protocol will do.
And you don't have to use micro services. You certainly can run a monolith. But with "the cloud" you now gain the ability to spin up as many servers as you want and spin them down too. So it enables micro services as an option.
And that option has interesting benefits. It does increase complexity (drastically), but for that cost you get a decent bit. The ab
Re: (Score:2)
Microservices are an architectural style meant to solve the maintenance/deploy/tech debt issues by physically separating an implementations in a lot of pieces. It's not a solution to a business problem. It's a solution to a tech problem you create when solving arbitrary business problems. It's basically solving the same problem you solve with functions/classes/modules/folders/whatever, except with physical decoupling so you can swap -everything-, one piece at a time, not just the code.
So to your example: th
Re: (Score:2)
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 unk
Re: (Score:3)
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
Re: (Score:2)
Microservices are no more required than OOP. Or languages beyond assembly.
Microservice architecture It's a tool. It can be handy, or it can be awkward.
Off the top of my head, on the positive reasons include:
the scaling can be based on the work being done instead of just throwing more threads or a faster CPU at it and hoping for the best.
Three hard truths (Score:2)
1. The whipped cream in the bathroom is not whipped cream.
2. We cannot escape ourselves.
3. And sometimes, the cat door... is closed.
Some things to learn (Score:3, Informative)
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.
IT Costs Money (Score:2)
Plain and simple -- IT costs money. The people who operate and implement IT cost money. Every bit of IT that gets implemented, from email to that fancy CRM system require money to do right. Even if you move stuff to the cloud, outsource or push it out to front-line staff to do it themselves will always cost money.
The trick is to make that money you are putting toward IT to good use. You will spend it regardless if you make it your competitive advantage or not. So, the smart companies use technology as
Hard truths (Score:2)
You can't fix stupid.
Hard Truth: Be a lifelong learner or get out of IT (Score:5, 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.
Re: (Score:3)
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'v
Hot Take Below (Score:3)
Re: Hot Take Below (Score:3)
Budget (Score:2)
You are a red line on the budget. You are nothing but an expense Your department just beg and grovel to justify its existence at every turn.
When something breaks, and you fix it, the value of fixing it will not be seen by the company. They will only see this red line on the budget fucked up and expanded that red line even further.
2 of the hardest IT problems : poseurs and leeches (Score:2)
Cloud & Idiots (Score:2)
A June 2017 survey of 300 IT pros found that 80 percent said the cloud wasn't meeting their expectations due to problems with security, compliance, complexity and cost. According to a January 2017 survey by cloud management firm RightScale, from 30 to 45 percent of enterprise cloud spend is wasted.
No shit, Captain Obvious. The whole, "Giving The Keys to The Kingdom to Someone Else" idea (otherwise known as Cloud Computing) was idiotic from the start. Of course it was, is, and always will be, costly and inefficient. It boggles the mind that otherwise (presumably) smart people would be so stupid as to buy into that particular brand of snake oil.
The only surprising thing in this section is that RightScale stopped at 30 to 45 percent. In my experience, the waste (meaning absolutely no benefit for the
oh you know, (Score:2)
You are constrained by your circumstances only as much as you are willing to go out on a limb and risk failing.
And web management GUIs are a sickening fad of instability.and inconsistency.
None of our Operating Systems are Secure (Score:2)
Windows, Mac, Linux, you name it... it's not secure, by design. None of them implement the principle of least access (POLA). All of them are default permissive environments which makes it impossible to specify at run time the extent of side-effects allowable from a given process.
My running estimate is 10 more years before people wake up and start re-engineering things to shift paradigms. Until then, chaos will continue.
Hard truth: the /. we once loved will never return (Score:2)
It's not about you. (Score:2)
Unless you are in some kind of Internet business, you are not a line [wikipedia.org] department. You are a support department. just like the janitorial service. You are being paid, not to pursue your own ambitions, but to make other peoples' ambitions come true. Maybe you get to do some professionally interesting things along the way, but to be a professional you can't let that affect your decision-making.
Perhaps a better analogy than the janitors would be the organization's lawyers. Corporate counsel a highly skille
What Are Some Hard Truths IT Must Learn To Accept? (Score:2)
IT's Glory Days have come and gone.
IT security is not a beginner's game (Score:3)
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.
Bottom of the food chain (Score:4, Insightful)
IT is a support function - it's job is to keep the rest of the company moving.
Re:People matter most, and there aren't enough (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/... [wikipedia.org]
if I wasn't a lazy bastard I'd edit your page to flag it as a WP:PROMO.
https://en.wikipedia.org/wiki/... [wikipedia.org]
Where are the wikipedia nazis when we need them.
Re:People matter most, and there aren't enough (Score:5, Funny)
Where are the wikipedia nazis when we need them?
They became write supremacists .