-
A question for anyone who might have context – from this piece it seems like they have a cluster per restaurant, which doesn’t make much sense in terms of complexity versus payoff to my mind. The thing that would make more sense and be very interesting is if they’re having these nodes join a global or regional k8s cluster. Am I misreading this?
-
They seem to be using NUCs as their Kubernetes nodes, so the hardware cost isn’t going to be too great.
I imagine it’s down to a desire to not be dependent on an internet connection to run their POS and restaurant management applications, I’m sure the costs of a connection with an actual SLA are obscene compared to the average “business cable” connection you can use if it doesn’t need to be super reliable.
-
Still, restaurants have been using computers for decades. It looks as if they have a tech team that’s trying very hard to apply trendy tools and concepts (Kuberneetes, “edge computing”) to a solved problem. I’d love to be proven wrong, though.
-
-
While restaurants certainly have been using computers for decades the kind of per location ordering integrations needed for today’s market are pretty diverse:
- Regular orders
- Delivery services in area (Postmates, dd, caviar, eat24, ubereats)
- Native app ordering
- Coupons
- App coupons
If you run a franchise like Chick-fil-A, you don’t want a downtime in the central infrastructure to prevent internet orders at each location, as it would make your franchisees upset that their business was impacted. You also want your franchisees to have easy access to all the ordering methods available in their market. This hits both as it allows them to run general compute using the franchisee’s internet, and easily deploy new integrations, updates, etc w/o an IT person at the location.
I have a strong suspicion that this is why I see so many Chick-fil-As on almost every food delivery service.
Beyond that, it’s also easier and cheaper to deploy applications onto a functional k8s/nomad/mesos stack than VMS or other solutions because of available developer interest and commodity hw cost. Most instability I’ve seen in these setups is a function of how many new jobs or tasks are added. Typically if you have pretty stable apps you will have fewer worries than other deployment solutions. Not saying there aren’t risks, but this definitely simplifies things.
As an aside I would say that while restaurants have been using computers for decades they haven’t necessarily been using them well and lots of the systems were proprietary all in one (hw/sw/support) ‘solutions.’ That’s changed a bit but you’ll still see lots of integrated POS systems that are just a tablet+app+accessories in a nice swivel stand. I’ve walked into places where they were tethering their POS system to someone’s cell phone because the internet was down and the POS app needed internet to checkout (even cash).
-
-
Most retail stores like this use a $400/mo T1 which is 1.5mbit/sec (~185kb/sec) symmetrical – plenty for transaction processing but not much else. Their POS system is probably too chatty to run on such a low bandwidth link.
-
-
It could just be a basic, HA setup or load balancing cluster on several, cheap machines. I recommended these a long time ago as alternatives to AS/400’s or VMS clusters which are highly reliable, but pricey. They can also handle extra apps, provide extra copies of data to combat bitrot, support rolling upgrades, and so on. Lots of possibilities.
People can certainly screw them up. You want person doing setup to know what they’re doing. I’m just saying there’s benefits.
-
-
The sexist behavior of those guys at Sun was just disgusting. It’s good she wrote about this.
But at the first beer bust I went to, two of the sales guys were standing around rating the women…only they called them “units.
Bob Coe once told me he did not have to interview the candidates for his Administrative Assistant position. I should simply ask each candidate to link her hands behind her head with her elbows pointing forward and walk toward the wall. If her elbows were the first part of her anatomy to touch the wall, she was eliminated from candidacy. All applicants whose breasts touched first, he would interview
-
it really is beyond the pale of what I would consider possible in a professional work environment.
-
I’m really glad she kept with it after the blowback she got!
I wonder why we don’t hear these “horror stories” as much from HR folks (who presumably have far more visibility of them than engineers!) as often, but I suppose that it’s probably a much bigger career risk to call out this stuff publicly when your job description is basically to deal with all of it and make sure it doesn’t become a legal or PR issue.
-
-
-
I don’t think the opposite of “novelty for novelty’s sake” should be “tradition for tradition’s sake”. I like the choose boring technology post because that author allows that sometimes, the usual way of doing things is “expensive and difficult” and in those cases it makes sense to be more adventurous in solution choice. I wouldn’t necessarily always pick the same “boring except where you spent your innovation tokens” approach but it’s a position that is reasoned rather than reactionary.
-
Agreed, I was actually almost on the authors side until I read the examples, all of which are extremely subjective. Microservices, NoSQL, and SPA’s all make sense in some contexts, and both sides of those dichotomies can be architected well or terribly.
-
-
The first thing I’d say is that 10 people in a standup is way too many. I like to sit around 5 or less. Actually 10 people in an engineering squad is probably too many, and the group should probably be split in two at least, but how feasible that is is something I don’t know for your case.
I also like to not just focus on what we did/are doing but also how we’re blocked. Identifying blockers to solve “offline” is one of the great benefits of a daily standup. So each person, within 2 minutes or so, should outline what they did yesterday, what they’re doing today, and how they’re blocked for the future.
Beyond that, for generalities, I love this article.
-
rbn
2 months ago
|
link
| on:
How to write bulletproof code in Go: a workflow for servers that can’t fail
why to people have the need to use a framework for everything, like the BDD testing frameworks in this article. i really don’t see the value of it. it’s just another dependency to carry around, and i can’t just read and understand what is happening.
what is gained by writing:
Expect(resp.StatusCode).To(Equal(http.StatusOK))instead of
if resp.StatusCode != http.StatusOK { t.Fail() }-
I don’t use that particular testing framework, but the thing I’d expect to gain by using it is better test failure messages. I use testify at work for almost precisely that reason.
require.Equal(t, valueA, valueB)provides a lot of value, for example. I tried not to use any additional test helpers in the beginning, probably because we have similar sensibilities. But writing good tests that also have good messages when they fail got pretty old pretty fast.-
-
testify is nice because it isn’t really a framework, unless maybe you start using its “suite” functionality, which is admittedly pretty light weight. But the rest of the library drops right into the normal Go unit testing harness, which I like.
I did try your methods for a while, but it was just untenable. I eventually just stopped writing good failure messages, which I just regretted later when trying to debug test failures. :-)
testify is a nice middle ground that doesn’t force you to play by their rules, but adds a lot of nice conveniences.
-
-
-
The former probably gives a much better failure message (e.g. something like “expected value ‘200’ but got value ‘500’”, rather than “assertion failed”).
That’s obviously not inherent to the complicated testing DSL, though. In general, I’m a fan of more expressive assert statements that can give better indications of what went wrong; I’m not a big fan of heavyweight testing frameworks or assertion DSLs because, like you, I generally find they badly obfuscate what’s actually going on in the test code.
-
yeah, with the caveats listed by others, I sort of thing this is a particularly egregious example of strange library usage/design. in theory, anyone (read: not just engineers) is supposed to be able to write a BDD spec. However, for that to be possible, it should be written in natural language. Behat specs are a good example of this: http://behat.org/en/latest/. But this one is just a DSL, which misses the point I think…
-
However, for that to be possible, it should be written in natural language. Behat specs are a good example of this: http://behat.org/en/latest/. But this one is just a DSL, which misses the point I think…
I’d say that the thing behat does is a real DSL (like, with a parser and stuff). The library from the article just has fancy named functions which are a bit a black box to me.
Just a thought: One could maybe write a compiler for a behat-like language which generates stdlib Go-tests, using type information found in the tested package, instead of using interface{} and reflect. That’d be a bit of work though ;)
-
-
-
Maybe @steveno or someone else can ELI5 this to me why is this advantageous over traditional, platform-agnostic, and dependency-less symlinking in a bash script? Cf. my dotfiles and the install script.
-
Salt’s declarative nature means that you’re mostly describing the end state of a system, not how to get there.
So instead of saying “copy this stuff to this directory and then chmod” you say “I want this other directory to look like this”. Instead of saying “install these packages” you say “I want this to be installed”. You also get dependency management so if you (say) just want to install your SSH setup on a machine you can say to do that (and ignore your window manager conf).
If your files are grouped well enough and organized enough you can apply targeted subsets of your setup on many machines based off of what you want. “I want to use FF on this machine so pull in that + all the dependencies on that that I need”. “Install everything but leave out the driver conf I need for this one specific machine”
This means that if you update these scripts, you can re-run salt and it will just run what needs to run to hit the target state! So you get recovery from partial setup, checking for divergences in setups, etc for free! There’s dry run capabilities too so you can easily see what would need to change.
This is a wonderful way of keeping machines in sync
-
Looking at my repository right now, there isn’t any advantage. You could do everything I’ve done with a bash script. The beauty of this setup for me, and I really should have stated this initially, is that I can have multiple machines all share this configuration really easily. For example, my plan is buy a RaspberryPi and setup an encrypted DNS server. All I need to do is install salt on the Pi and it gets all of this setup just like my NUC currently has. I can then use salt to target specific machines and have it setup a lot of this for me.
-
The beauty of this setup for me, and I really should have stated this initially, is that I can have multiple machines all share this configuration really easily
You can also do this with a shell script.
All I need to do is install salt
With shell scripts you don’t need to install anything.
-
As I previously stated, given what’s currently in this repository, there isn’t anything here that you couldn’t do with a shell script. That’s missing the point though. Salt, or ansible, or chef, provide you with a way to manage complex setups on multiple systems. Salt specifically (because I’m not very familiar with ansible or chef) provides a lot of other convenient tools like salt-ssh or reactor as well.
-
-
If you’re targeting different distributions of linux or different operating systems entirely, the complexity of a bash script will start to ramp up pretty quickly.
-
-
I have a POSIX sh script that I use to manage my dotfiles. Instead of it trying to actually install system packages for me, I have a
./configctl checkcommand that just checks if certain binaries are available in the environment. I’ve found that this approach hits the sweet spot since I still get a consistent environment across machines but I don’t need to do any hairy cross-distro stuff. And I get looped in to decide what’s right for the particular machine since I’m the one actually going and installing stuff.
-
-
-
The beauty of this setup for me, and I really should have stated this initially, is that I can have multiple machines all share this configuration really easily.
Have to agree with @4ad on this one. I have to use remote machines I don’t have sudo rights and/or often are completely bare bones (eg., not even
gitpreinstalled.) My goal, in essence, is a standardized, reproducible, platform-agnostic, dependency-less dotfile environment which I can install with as few commands as possible and use as fast as possible. I don’t see how adding such a dependency benefits me in this scenario. I’m not against Ansible-like dotfile systems, but, in my opinion, using such systems for this task seems like an overkill. Happy to hear otherwise, though.
-
-
-
femiagbabiaka
3 months ago
|
link
| on:
Google Employees Resign in Protest Against Pentagon Contract
I hope to see more of this — if workers with as much leverage as we have don’t speak up against technology we create being used for evil, we can’t call ourselves engineers.
-
-
Exactly. It has to be a large number of people that damage their mission directly or indirectly with media pressure. Otherwise, it’s something with no impact. At least people are following their principles, though.
-
It has to be a large number of people that damage their mission directly or indirectly with media pressure.
Can you trust an engineering company who ignores the opinions of its engineers?
We are talking about one of the most celebrated company of western economy, often cited as an example of excellence.
Leaving Google for ethical concerns poses a serious burden on the employment of these engineers that will probably be marked as dangerous employees for the time being.
We can assume that this is something they knew, as Google don’t hire dumb guys.
So why they quit?
My bet is that the militar use of the Google’s artificial intelligence technology is so dangerous that these engineers felt obliged to leave the organization beyond any doubt.
Otherwise, it’s something with no impact.
Well, it’s a first step.
And a courageous one.
Its impact goes beyond the worldwide image of Google, beyond the direct issues in their production line.
It is an example.
-
Can you trust an engineering company who ignores the opinions of its engineers?
It doesn’t matter. What matters here is (a) the companies’ goals/incentives, (b) how successful they are at achieving them, and (c) if a tiny number of engineers quitting changes that. Note that (b) includes implicit support by the many people who use their products and services voting with their wallet. The stuff in (a) means they’re anywhere from apathetic to damaging for a lot of ethical issues around privacy and making money. Due to (b), actions to damage them have to put a huge dent in that or make them think it will. (c) doesn’t do that. So, (c) is probably irrelevant to Google. The article itself says as much:
“However, the mounting pressure from employees seems to have done little to sway Google’s decision—the company has defended its work on Maven and is thought to be one of the lead contenders for another major Pentagon cloud computing contract, the Joint Enterprise Defense Infrastructure, better known as JEDI, that is currently up for bids.”
I gave them credit in my other comment for standing up on their principles. That’s respectable. It’s just that a “dozen” or so people quitting a company with over 70,000 employees with people waiting to fill their positions doesn’t usually change anything. They’d instead have to campaign in media or government aimed at stopping those contracts or drone operations. At least half the voting public and current President support military action overseas. The other half didn’t convince their prior President to stop drone use or strikes. There are also not large swaths of Google customers threatening to stop using Google Search, Gmail, etc if Google doesn’t turn down government contracts.
So, quitting over this is pointless if the goal is to achieve something. At best, it’s a personal decision by those individuals to not be involved in something they disagree with that’s going to happen anyway. That’s fine but practically a separate thing from ending these contracts. If anything, we’ll just get a shift in Google employees from those who might leave over the contracts to people who range from favoring them or just griping about them continuing to work there. I think most will be in latter category.
-
It’s just that a “dozen” or so people quitting a company with over 70,000 employees with people waiting to fill their positions doesn’t usually change anything.
The fact is that fewer talented people will want to fill their position.
This is a pretty serious issue, if engineers are the core resource of your company.Now, I’d guess most Google engineers don’t feel as important to the company as they feel the company is important to them. This happens in many companies, and I would guess Google has turned this kind of internal narrative into an art.
The fact is that, instead, Google literally would not exists without those engineers.
These few have shown exactly that: that working in Google is not that important.
It’s a matter of time, but if Google do not take serious actions to avoid this general wake up, other engineers will follow. And the same might happen in Facebook, in Apple and in many other smaller IT companies.On the other hand, in Europe and everywhere else, people will start to ask why engineers from a company that operate in their territories, are so afraid for what the company is doing, to quit. To avoid the risk of being associated with the company future. To avoid sharing its responsibility.
Politicians will be less friendly to a company that might be doing something really evil for a foreign state.I agree that more engineers should follow their example, but I know that life is not that easy.
However people continuing to work there might organize to keep the company “on track”, and this might lead to the creation of a labor union.-
The fact is that fewer talented people will want to fill their position.
You have to prove that assumption. Google changed their Don’t Be Evil motto doing sneakier and sneakier stuff overtime. They’re a surveillance company that hires brilliant people to do interesting work for high pay and good perks. They’ve had no trouble that I’ve seen keeping new people coming in. Status quo has the evidence going against your claim: it’s a shady, rich company with in-demand jobs whose shady activities haven’t changed that for years. There’s also nearly 70,000 workers mostly in favor of it with more trying to get in.
“However people continuing to work there might organize to keep the company “on track”, and this might lead to the creation of a labor union.”
That’s a different issue entirely. Given I am in a union, I think it would be cool to see it happen. Unlike OP topic, that could happen with higher probability. Silicon Valley will do everything they can to stamp it out in mean time, though. Still a long shot.
-
The fact is that fewer talented people will want to fill their position.
You have to prove that assumption.
Not an assumption, but a deduction: people avoid cognitive dissonance, if possible.
A dozen people leaving a company cause of ethics, means that such company forced them too high on cognitive dissonance, and this will make Google relatively less attractive, in comparison to the alternatives: a talented engineer want to fix problems, not fool herself to avoid the pain of contradictions.
Our brain consume around 20% of our energy, after all.
This is the same reason that make me guess others will quit Google in the future.
Because now they have a new thinkable precedent.
A new, effective solution to reduce their cognitive dissonance.
-
-
-
-
-
-
I agree. But we also can’t rely on companies that we don’t own to incentivize us to act in a moral fashion – engineers need a governing body for that.
-
What about entering both US political parties and changing the policy? If you believe that killing people is wrong, maybe make it a law?
Sometimes the only way to advance your field is to step out of it and fix the external systems. And war zones are definitely not a good environment in which to build global information network to advance everyone’s wellbeing…
-
-
I think it’s definitely a factor. Many prominent business people would not like to be associated with payday loan companies, for example.
I think this is less about being the silver bullet for problems, and more about being one of the 20 or 30 things we need to be doing to make the world A Better Place(TM)
-
-
We can’t even speak up for honest pay for an honest day’s work–and that’s a lot less subjective than some arbitrary definition of “evil”.
-
Why not both?
-
At least the “evil” one is super cloudy.
Say you are an engineer working at a company that builds control software for missiles. You are a pacifist, and so you decide to introduce a minor bug (or fail to patch a discovered bug) that causes the missile to not detonate when it lands.
- Are you good for not facilitating the loss of life?
- Are you evil for misleading your employer about the labor of yours that they’ve purchased?
- If the missile lands on a poor grunt and severs their legs causing them to bleed out over minutes instead of detonating properly and just kinda instantly killing them, are you evil for prolonging suffering?
That’s just scratching the surface of morality in engineering.
-
That’s fair – and I should’ve been explicit earlier. I believe that there are (at least) two moral guidelines that should be taken into account.
The first is a professional code of ethics, similar to what ACM has here. Of course even this is cloudy – for example, in my opinion 1.2 “Avoid harm to others” would necessarily preclude working for a missile manufacturer in the first place. At the very least, if one views missiles and missile software as being a necessary “evil”, safeguards should be put in to protect human life at all cost, etc. etc. The minutiae of the professional code of ethics can and should be rigorously debated, because it provides a minimally viable base for how we should conduct ourselves. So for example, the question of whether or not working in the weapons manufacturing industry truly violates rule 1.2 should be an explicit discussion that is had in a professional organization (not a workplace per se).
The second guideline is in line with your own personal moral code. This is important because it provides for people who are religious (or not) or any other number of cultural influences that have caused a person to believe what they believe today. This, of course, has to be superseded by the professional code – for example, if I personally believe that discrimination based on what TV shows you enjoy is okay, that doesn’t mean that my personal morality should define what happens in a professional setting. But in the hypothetical case you provided, even if I don’t feel that writing that software goes against a professional code of ethics, if I am a pacifist, it goes against my personal code. I know from the professional code that purposefully writing bad or buggy software is wrong, and so my only option is to find another job in which both my personal and professional codes of ethics can be upheld.
-
Why discuss an unlikely hypothetical rather than the issue at hand? Why the need to logically define evil beyond any confusion? This is not even possible in the general case for anything. Can you logically define ‘fun’ such that everyone agrees? At the end of day, evil means what people talking about it think it means, and it’s better to work off of that than to halt all discussion until we achieve the impossible task of absolutely grounding natural language in logic.
-
It’s precisely because evil is so ill-defined that talking about it is difficult. As @mordae points out, it’s more effective to talk about other incentives.
And again, I’m not saying “halt all discussion”–quite the opposite! I’m saying that the issue is more nuanced than “don’t be evil”.
-
I certainly agree with that. I still think it’s worth going into, because at a certain point you’re likely to end up doing it anyway. For instance, if we start talking about incentives, we might end up talking about how to incentivize people towards good, or at least, some concept of “not evil”. I’m not saying it trumps incentives or that this is a more effective approach, I’m just saying we should still have the discussion.
I think a trap we as engineers often fall into is to attempt to build everything up from laws and axioms. That doesn’t quite work for morality, and the nebulous nature of it means it rarely gets discussed. The software industry in particular is very focused on “solving problems” and never asks questions like “should we solve this problem?”
I guess another scary thing about it is that we can’t really empirically verify what the right answer is, and depending on the issue we might even have multiple valid answers. But sometimes just asking the question is worthwhile, even if we don’t have an answer.
Perhaps tech companies should start hiring philosophers.
-
Perhaps tech companies should start hiring philosophers.
I’d argue that a good programmer is a philosopher almost by definition.
We talk like if our field was an engineering field but most of times we don’t build things constrained by the physical world (yeah I know what latency is… I said most of times :-D).
Or we talk like if our field was just applied math, pure and intangible, but then we talk about usability or we kill someone through a self driving car.
But ultimately we work with ideas.
The choice to ignore the ethics of our work is up to us.
But we have much more instruments to think about our role in the world than any “professional philosopher” hired to think for us (in the interest of the company).
-
if we start talking about incentives, we might end up talking about how to incentivize people towards good, or at least, some concept of “not evil”.
That’s how you do it. In Google’s case, a publicly-traded company, that means you have to hit them in the wallet in a way that knocks out the contract. Alternatively, convince their management to change their charter or use other legal means to block whole classes of action in the present and future that they agreed were evil. I’m not sure if that would even work in Google’s case but one can start businesses like that in nonprofit or public benefit form.
-
-
-
I think friendlysock was trying to illustrate the point with some examples. The comment succeeded given the other person understood the points. There’s nothing wrong with that. You said to instead work off claims about evil in this situation based on what people are saying. In this case, what does evil mean exactly to both those employees and various stakeholders in the United States? Based on the political debates, I know there’s quite a few different views on whether these programs are evil or not. Even within the main, political parties, in Silicon Valley, and in Google itself.
The only thing sure is that about 4,000 of Google’s 70,000 people plus some other folks writing a letter don’t like what Google is doing. Of the 4,000, only a dozen or so showed it’s worth not working for Google. So, that’s under under 1% of Google’s workforce. The others are continuing to support Google’s success, including that program indirectly, while protesting that program. They may or may not leave but I think most will stay: workers gripe more than they take action in general case, esp if employer’s actions is morally a mix to them or six digits are involved. If they leave, there’s a lot of people willing to take their place with no long term effect on Google. The remainder and some new hires collectively are apathetic to this or believe it’s morally acceptable.
Many of the people staying would probably tell you they’re decent people with Google doing a lot of good for the world (arguably true) despite this evil. We saw this in NeverAgain pledge. Others would tell you this kind of thing is inevitable enough that Google not doing it would make no difference. Some of them would even say it’s better if they do it so they can do it right minimizing harm. Yet another group will claim these programs prevent a larger number of deaths than they cause or prevent real damage vs hypothetical risks detractors talk about. People ranging from those developing software to those doing drone strikes might believe they’re saving lives in their work while the dozen that quit will be doing less valuable work in tech for their own benefit.
I don’t think there’s a clear answer of evil if I’m looking at the stakeholders in this discussion. They’re all over the place with it. The acting public is in a few camps: those doing a mix of opposing and tolerating drone operations who lost the election; those mostly supporting them whose party is in control; billions of dollars worth of users and businesses who don’t care enough to switch providers; tiny, tiny, tiny slice of revenue from those that will. Put in that light, nothing they’re doing will matter past their own conscience. Hell, those thinking the tech is evil might have been better off staying in there half-assing the programming on purpose to make it look like such tech just isn’t ready to replace people yet. There’s precedents for that with many of them in defense industry except for profit rather than moral reasons.
-
-
-
-
-
Am I the only one that thinks that all these netflix things are extremely over-engineered? The bulk of their content is not even served from AWS, but from boxes that are close to the eyeballs.
I am not saying, I could build one in a weekend or anything like it, but what do all these servers do? There is hardly any user interaction, except search and maybe giving a rating. The search is also not that big, given the size of the catalog they serve per country. The traffic comes from local caches. What is all this for, except keeping engineers in the bay area busy?
-
just a psa, I don’t and have never worked for Netflix, all of this is mostly conjecture from experience.
sure, I think that micro service bloat is probably a problem that they have. and many of the FANG companies suffer from NIH (not invented here syndrome), in some cases because of (IMO) broken promotion processes that require engineers to ship “impactful” work at all costs, and in others just because they have an unlimited amount of money to spend on engineering time.
That being said, even the most trivial problems become quite difficult at the scale that they’re working at – they have 125 million subscribers worldwide, which means peak time is almost all of the time. In addition, maybe you only use search and ratings, but what about admin UI’s? What do customer service teams use? What tooling do content creators use to get materials onto their platform, and what do they use to monitor metrics for content once it’s uploaded? What about ML and BI concerns, SOC2 concerns, GDPR concerns? I could go on forever perhaps. It’s very difficult to reconstruct all of the reasons for the way any platform evolved the way it did without getting a historical architecture overview. But! Their service is very reliable and their business is profitable, so they must be doing something right. (not that there isn’t always room for improvement)
-
There was a good presentation at StrangeLoop last year: Antics, Drift, and Chaos. The short version is “Netflix is a monitoring company that, as an interesting and unexpected byproduct, also streams movies.”
-
this is great! thanks for the link – I’ve got to get to strangeloop next year.
-
What kind of monitoring do they do, do you know?
-
-
-
The result and the press is not as important as the journey. Being able to failover that quickly such a huge infrastructure is impressive, but the most important part is how they managed to achieve this and improve their work-flow, resiliency, and many other things along the way!
-
I assume these other boxes are Very Important^TM for authorization and provides the search/indexing functionality of their service. The CDN boxes they ship out do nothing but host the videos, and not all videos exist on each box, so something would have to handle directing you to the correct node.
You can’t stream the videos if you can’t get authorization, so…
-
Those boxes they ship to ISPs only hold a subset of content. They still have to deal with routing a request to the closest node with the content they want, and update the ISP cache box with that content when there’s a spike in demand for something that isn’t cached locally. If your AWS nodes are down and nobody on the ISP requested Star Trek in the last N hours, you’re up shit creek with the customer requesting it unless you have a good fail over strategy.
I doubt those ISP cache nodes do local authentication or billing, either.
-
Do you know where the movie content lives though? I’d be surprised if any of it was served from AWS hosts, instead I’d expect it on a CDN somewhere. I don’t think @fs111 is saying that Netflix doesn’t do anything, but rather does their architecture actually make sense given what they do?
My two cents is that it is probably overengineered and that is probably because it happened organically because nobody really knew what they were doing. With hindsight we could probably say some things are needed or could be done simpler.
-
-
-
S3 isn’t geographically distributed at all. It’s RAID with a REST API. It’s nothing like a CDN – Netflix does all the CDN things (replication, dynamic routing-by-proximity, distributing content to multiple edges close to customers) at their own layer above the storage layer.
-
-
-
-
-
-
This is a pretty interesting take that I hadn’t thought of before. Some comments:
- In my mind, GDPR (hopefully) shouldn’t influence business behavior – whether or not your company delivers software via on-prem solutions or SaaS solutions is an outcome of some combination of headcount, cost, and other factors. Also anecdotally, selling SaaS products is much much easier.
- On that note, I see GDPR as the logical response to our SaaS world and ultimately an improvement of it. Having worked at a few SaaS companies that worked with medium to large data, I can say with a certainty that companies weren’t thinking about a full purge of data when a customer leaves, even if they request it. SOC2 and it’s ilk are arcane and very poorly enforced. Let’s hope this is better – things like recent Palantir stories in the news show how necessary legislation like this is.
- One last thought – I’m now wondering how GDPR will influence software that companies make their employees use. Could I as an employee request data a third party vendor is keeping regarding me on behalf of my employer?
I’m very happy with vgo after spending years frustrated with buggy, partially-broken third party tools: first glide (no way to upgrade just one package, randomly fails operations) then dep (100+ comment issue on not supporting private repos).
This comment from HN sums up my feelings on this post:
This is an extremely bad faith interpretation of events. Your words have an actual negative effect on people who have tried for a very long time to do the best they could to improve a bad situation.
Except Go is not (or at least doesn’t market itself as) BDFL-led. The core team has been talking about building and empowering the community for years (at least since Gophercon 2015, with Russ’ talk).
They were put in place by / with the blessing of the Go core team, so some authority on the subject was certainly implied.
You can certainly prefer Russ’s technical solution, that’s only part of the thing being discussed (and I think it’s fair to say it’s not the heart of the matter).
The rest of your quotes are just mean.
People don’t seem to realize that Go is not driven by the community, it’s driven by Google. It’s clear to me that Google doesn’t trust its programmers to use any advanced features, the code is formatted the same (again, don’t trust the programmer), everything is kept in one single repo and there is no versioning [1]. In my opinion, Google only released Go to convince a ton of programmers it’s the New Hotness (TM), get everybody using it so they can cut down on training costs and disappointed engineers looking for resume-worthy tech to work on [2].
So, any proposal for Go that violates Google’s work flow will be rejected [3]. Any proposal that is neutral or even helps Google, will probably be accepted. As far as I’m concerned, Go is a Google-proprietary language to solves problems Google has. The fact that it is available for others to use is intentional on Googles part, but in no way is it “communitty driven.”
[1] Because if you change the signature of a function, it is up to you to change all the call sites at the same time. Because the code is all formatted the same way, there does exist tooling to do this. At Google. Probably no where else.
[2] “What do you mean we got to use this proprietary crap language? I can’t put this on my resume! My skills will stagnate here! I hate you, Google!”
[3] Stonewalled. Politely told no.. But ultimately, it will be rejected.
To be fair, don’t trust the programmer, is a pretty good rule to follow when you design a language or API. Not because programmers are bad or incompetent but because they are human and thus predisposed to make mistakes over time.
hrm, I actually want to push back against this quite strongly. any BDFL making decisions in the absence of community input will quickly find themselves the BDFL of a project that has no users, or at least one that often makes poor technical choices. Also, framing this disagreement as a personal one where prestige and reputation are at stake rather than as a technical one is a characterization that nobody other than the involved parties can make, certainly not people uninvolved in the project at all. In particular, making character judgements about people you don’t know based on technical blog posts is something I expect from the orange website, but I’d like to think the community here is a bit better.
and as far as that technical disagreement goes, I’ve read through rsc’s rationale and I’m not any more convinced than I was in the beginning that jettisoning a well known package management path (SAT-solver) in favor of a bespoke solution is the correct decision. It is definitely the Golang thing to do, but I don’t know if it’s the best. Time will tell.