talawahdotnet
Joined 11 years ago
Karma
509
Submissions
108
Member since
Sep 3
Recent submissions
Comment · 7 years ago
Great to see consolidation in this area. Observability is super important in the cloud/microservices era. Standardizing the collection of logs, metrics and tracing is a big win.
Comment · 7 years ago
In this equation you are valuing the bootcamp and career placement portion of their offering at $0. If you were to value it $10-15k then it is a different story.
At the end of the day they are offering a lot more than just 10k. They are offering training AND placement assistance. They are also assuming the costs of the people who fail to complete the program of get a job.
Comment · 7 years ago
I am still praying that some day soon AWS will announce that they are joining Opencensus (along with Google, MS, Datadog, Prometheus)[1] in the hopes that we can move towards standard tooling for observability.
They also seriously need to give CloudWatch a UI/UX overhaul.
1. https://opencensus.io/introduction/#partners-contributors
Comment · 7 years ago
Would be great to see global network performance comparisons with smaller providers like Digital Ocean and OVH. Everyone always knocks AWS on their bandwidth pricing, yet the pricing is in line with other major cloud providers and CDNs (GCP, Azure, Fastly). I would love to see what the actual trade-off looks like. Is there really that much of a difference in performance or reliability between them, or is it just a case of oligopoly pricing.
Would also be nice to see some stats for traffic within the same AZ as well. I generally see ping times between 0.1 and 0.2 ms within the same AZ on AWS, would be nice to know what that looks like on Azure and GCP.
Comment · 7 years ago
Yea, it definitely has limited immediate value compared to a database as long as it is on a closed network. However it does allow them to experiment with the technology in a controlled fashion. They could have done so quietly but, you know, marketing.
I think there is still value in Blockchain networks like Stellar[1] that are not fully decentralized, but are federated and diverse. If this is a first step towards them issuing a stable coin on a network like that then I welcome it.
Comment · 7 years ago
Yea I really am hoping their Chromium based browser gives them the combination of broad compatibility and enterprise integration needed bring about the end of IE 11.
Comment · 7 years ago
Private repos on Docker Hub is definitely a product, especially if you provide a seamless path for moving from source code on GitHub to images on Docker Hub to containers deployed in the cloud or on premise.
MS could certainly also do good business selling Docker's friendly Enterprise orchestration tools (including their new Kubernetes based tool) which check all the Enterprise requirements for security, policy, identity management etc.
Comment · 7 years ago
A little off topic, but I wonder how long it will be before MS acquires Docker Inc. Seems like an even better fit for them now that they own GitHub. GitHub + Docker Hub on the developer engagement side and Docker Enterprise on the traditional enterprise side.
Comment · 7 years ago
Lots of mention of CircleCI and Gitlab as the reason for Travis' downfall, which is very true. I also think GitHub announcing GitHub Actions[1] may have been the final nail in the coffin.
I think GitHub Actions will become a major force in the CI market in short order, it has so many things going for it
a) Everyone already has an account and lots of code already lives there. One less extra thing to worry about.
b) I trust MS/GitHub with my Cloud secrets more than I trust the various other CI providers.
c) The financial backing of MS to provide a significant free tier
d) The fact that actions can so easily be shared on GitHub is a killer feature. More are more projects/companies will build actions for their end users.
Comment · 7 years ago
Yea, there are quite a number of useful nuggets in there. I also liked this bit on complexity from the third post[1]
> A second important theme for decentralized systems is a common lack of appreciation for just how complex these systems are and how finely balanced they need to be to operate correctly.
I originally joined Bittorrent in 2007 to work on a decentralized CDN which aimed to do something like “tie together all the unused storage and bandwidth on people’s PCs into a content delivery network which had zero operating costs (for us)”.
In time it proved there were a number of things wrong with this ambition (most of which I won’t touch on here), although perhaps the most important one which we discovered the hard way was the cost of complexity.
1. https://medium.com/@simonhmorris/intent-complexity-and-the-g...
Comment · 7 years ago
This is a four part series of posts by former BitTorrent Inc employee Simon Morris. He makes a well reasoned analogy between the P2P revolution and the current Blockchain/Crypto craze, and provides insight into the powers and pitfalls of decentralized technologies and communities. There is a pretty decent TLDR summary at the end of the final post[1]
Key snippets:
> And this is the main conclusion — decentralization may be great for disruption, but if the experience of Bittorrent is anything to go by it is not at all clear that it has a role in whatever comes next. Blockchain architectures are great for unleashing unstoppable rule-breaking mobs, but we shouldn’t mistake the rule-breakers for the winners.
> Perhaps one of the most far-sighted winners here was Daniel Ek — CEO and Founder of Spotify — who preceded his Spotify success with the sale of the uTorrent client to BitTorrent Inc. Although early versions of Spotify used a Bittorrent-like P2P protocol to try to save money on bandwidth, they quickly realized that the main point of Bittorrent had little to do with saving money, and decentralization of their architecture was actually counter-productive to their aim. Perhaps it was apparent to them way back then that leading a revolution is exciting, but it’s far better to build the thing to save incumbents from the unleashed mob.
1. https://medium.com/@simonhmorris/decentralized-disruption-wh...
Comment · 7 years ago
Given the scale and popularity of DynamoDB and the distributed nature you would think that they could hire multiple teams just to work on improving it, but I guess it isn't as simple as that.
I would love to get a behind the scenes look at the process of gradually improving the components of DynamoDB with better technologies, while still maintaining reliability and performance.
Comment · 7 years ago
You think AWS has a reliability problem for their database products? That's news to me. AWS often launches products with limited features, but security, durability and reliability tend to be the standard.
Reliability is the trickiest of the three because it requires the customer to architect their solution with multi-AZ support in mind, but AWS always provides the foundation for that architecture.
Could they, and should they provide more features and a better developer experience around building fault tolerant solutions? Absolutely! But I certainly don't think they have a bad reputation for reliability.
Comment · 7 years ago
It definitely sounds like it sucks from the perspective of an internal AWS developer or SRE, but if the AWS systems are architected such that these internal failures aren't seen by end users then AWS's reliability reputation remains fully intact.
Customers are paying AWS so that their SREs don't get called, they don't care if the AWS SREs do as long as the system keeps running.
Based on the supporting quotes at launch from Capital One, Dow Jones and WaPo it sound like enough customers are ok with vertical write scalability and (pretty awesome) horizontal read scalability for now because it fits their use case and is better than what they had before.
Also consider that since the cluster management overhead has been removed from the customer, they can essentially "shard" by using a separate cluster for each sufficiently large service/org/dept, which might actually work out better for them in some respects.
Perfect is the enemy of good enough, the architecture might be laughable to you, but it is probably miles ahead of what the customer was using before.