[HN Gopher] It's Still About the Applications
___________________________________________________________________
It's Still About the Applications
Author : dsr_
Score : 41 points
Date : 2020-03-02 20:39 UTC (2 hours ago)
(HTM) web link (freethoughtblogs.com)
(TXT) w3m dump (freethoughtblogs.com)
| lastres0rt wrote:
| I guess this article counts as therapy, what with the whole line
| of "The goddamn vaunted databases of the government are NOT the
| stuff of conspiracy theories. In fact, they're just as shitty as
| you would expect."
| mrkeen wrote:
| This is all rings so true.
|
| Why do I have to swipe an access card and display a name badge in
| my building, when all the important data is outside the building?
|
| Why do we factor GDPR into our designs if we don't know where we
| store the data, and we'll never meet (nor be able to trust) the
| people who hold onto it for us. Can't we just encrypt it on our
| side then? I don't think we're getting homomorphically-encrypted
| relational databases anytime soon.
|
| My last month has been an effort of 'migrating' a service from
| another team to ours. The service stayed right where it was - the
| cloud - but we sank weeks into editing IAM files and deploy
| scrips to try to make it 'belong' to our team.
|
| We're programmers; we don't know about AWS's policies model,
| security groups or software-defined networking. Whenever I'm
| forced to interact with AWS I always feel like I'm doing
| significantly more work than the "managed" selling point of AWS
| would imply.
|
| I know my way around ssh, docker, iptables etc. But I miss having
| someone in the team whose actual job it is to be good at these
| things.
| [deleted]
| gliese1337 wrote:
| Why do I have to swipe an access card and display a name badge
| in my building, when all the important data is outside the
| building?
|
| So that angry customers can't walk in the front door, take the
| elevator up to the fifth floor, and hang out in the CEO's
| office.
| mrwnmonm wrote:
| Non-native English speaker here. Could someone write an easier
| summary, please?
| tabtab wrote:
| Sure: "The cloud doesn't solve common IT problems, only shifts
| them around, and makes some problems worse, such as more
| vendor-dependency. If you hire amateurs, you get amateurish
| results. Renting cloud-based amateurs has all the same problems
| as in-house (internal) amateurs."
| scarface74 wrote:
| And this "vendor dependence" is somehow different than
| government depending on Microsoft or even older systems that
| still depend on IBM mainframes.
| AndrewKemendo wrote:
| As one of the "Federal IT managers" actually doing this, there
| are too many broad statements here that the overall message ends
| up being misleading.
|
| If you were completely cynical, then you could find enough
| examples to make anything in here seem true.
|
| For example, this entire paragraph is wrong:
|
| _Here's something that will surprise you a lot: when it comes to
| government, cloud computing represents a huge shift of money from
| the public sector to the private sector. It's the privatization
| of of government data. Lock-in is completely ignored: how will
| government departments ever get their data back out of the cloud?
| "Not my problem," says the federal IT manager, "besides, there's
| nothing about lock-in in these Powerpoint slides."_
|
| There is realistically too much here to unpack in a comment, but
| I would say that the overall thesis of the article is pointing in
| the right direction.
|
| However it's not like failure is a forgone conclusion, if
| competent people (like a lot of you reading this are) join the
| government to actually help fix these things then we can actually
| do things correctly. I posted in the Who's Hiring Thread last
| month so we're ready whenever you are.
| thinkingkong wrote:
| Honestly this entire system is a mess. But it's working so nobody
| is going to change it, plus going "over the top" and building a
| better, more idealistic solution will have the same set of
| problems. Assuming you end up building something dramatically
| better or easier, getting market share means addressing more and
| more use cases, and you more or less end up as the n+1th protocol
| or standard.
|
| To me the only long term in dealing with this mess is going to be
| some shift in how we actually do computing on data. Leave the
| data at rest / in-situ and move more and more compute capacity to
| where it sits, then merge results together later. We're getting
| to the point where containers are common place, and FaaS is
| becoming comfortable.
| phkahler wrote:
| The best part is the elasticity of cloud storage. When the
| projects fail, they'll just keep all the data in the failed
| project achive. The next go will have it's own multiple copies of
| the same data and so on. They'll just keep paying incremental
| storage charges. Meanwhile, behind the scenes in the cloud -
| automatic, transparent deduplication....
| reggieband wrote:
| > the very fact that The Pentagon thinks that all its cloud apps
| are going to work under either AWS or Azure shows how ignorant
| they are
|
| I'm not sure why that is the case. I worked at a place that
| mandated minimum two cloud support and we were going down that
| road when I left. I didn't see any complete show-stoppers from a
| technical perspective although there were a few annoying issues.
| Maybe the author is just hammering home the incompetence angle,
| where the IT managers he lampoons are incapable of managing such
| a project. But at it's face, holding an expectation that systems
| be redundant across cloud providers seems reasonable.
___________________________________________________________________
(page generated 2020-03-02 23:00 UTC)