I'm a crypto skeptic, but I don't feel exceptionally informed of the other side of the argument(s). Can you recommend any posts/articles/summaries about the mistakes you're referring to?
I work with blockchain, but I stay the hell away for anything related to selling tokens or investing for future , sadly that excludes 95% of the blockchain world as it is today. But in that 5% there’s some really promising awesome projects.
We all understand the importance of databases and in general storing state. Do you know any other paradigm/system where a database is not controlled by a ‘root’ user with god powers?
That’s what blockchain is. If people are going nuts using it to create currencies and selling each other JPGS, that’s their business. Doesn’t deny the usefulness of the underlying paradigm.
Mind sharing what those use-cases are? Most of what I've heard of blockchains for non-cryptocurrency, non-token things are either cases where the blockchain is still permissioned (with some sort of root-like user with god powers), or could just as well be a DHT (like ipfs & bittorrent), or are things that sound interesting as a thought experiment but could never scale to their intended use-case, or something that is already solved by much simpler tech.
I'm open to the idea that blockchains are interesting as a tech but I have yet to see what they would be the best solution for besides illegal activity or speculation.
> But in that 5% there’s some really promising awesome projects.
This is exactly how I feel. Its very likely someone will someday create something uniquely awesome with the tech that really is transforming. I just don't think we've seen it yet
I've heard good things about the mobile OS, but with Mixer Microsoft missed the mark.
They did a decent job of copying the Twitch UI to make the transition familiar, but then had a number of unnecessary friction points that I'm sure drove folks away. As an example with my own experience: I was a somewhat regular Shroud viewer on Twitch. When he had his first Mixer stream I tuned in, only to find out that A) his overlay notifications hadn't been integrated and B) I couldn't even minimize the chat pane of the viewer without signing up for a Mixer account, which was an onerous process.
Not having a large streamers overlay integrations working prior to his debut stream tells me that MS does not understand how critically important community engagement is in live streaming.
Forcing me to sign up just to be able to control the viewer UI drove me away and removed any chance of me returning and finding organic reasons to sign up for Mixer.
That was the one and only time I watched Shroud after his move.
> Presumably in a company like Coinbase there is already an infrastructure team that runs the AWS instances, helps build the AMIs, etc. This team could re-tool and hire some k8s experts to help them make the shift.
The key is that there is a lot of additional services and interface points to handle. As the Coinbase article noted, you need extra pieces on top of k8s (storage, service mesh, config/secrets, etc) that need care and feeding. Even if the company moved 100% of their services into k8s there's now more work to be done for the same level of service.
: The control points that k8s exposes are not simple "drop in your provider here" bits of integration. You would likely still have the same core providers (ex: EBS for storage) but there is now more code running to orchestrate them, and more access control to implement and verify.
My personal experience (4 years on GKE in production) has been the opposite; running on k8s has abstracted away a number of things that I’d otherwise have to engineer.
Volumes just get attached (using PersistentVolumeClaims), and automatically migrate to a new node of the original pod dies. Vs. having to do some sort of rsync between nodes to keep disks in sync.
Secrets get encrypted by k8s and mounted where needed. I would agree that RBAC is a bit tricky but I don’t think it’s harder than IAM provisioned with Terraform.
If you are not using a service mesh for your VMs then you don’t need one in k8s. (I don’t use one, and rolled TLS to the pod in less effort than it would take to maintain TLS to the VM). The reason you want a service mesh is to abstract TLS and retry mechanics from the application layer - i.e. make your service authors more productive. If you don’t use a service mesh then you are back to managing TLS per-service, which is where you are with VMs already.
There are definitely more services you _could_ run, but in my experience these are additive, I.e. they are extra work, but give you a productivity boost.
Anyway, YMMV and I haven’t operated a system as large as Coinbase, so I could be missing something. Interested in hearing others’ experiences though.
> As the Coinbase article noted, you need extra pieces on top of k8s (storage, service mesh, config/secrets, etc) that need care and feeding.
The problem with that assertion is that it does not make any sense at all. For instance, storage and config/secrets is already supported out-of-the-box with Kubernetes. Even so, complaining about storage with Kubernetes is like complaining about EBS or EFs or arguably S3 in AWS. And if you feel strongly about service meshes then you really aren't forced to use them.
> Even if the company moved 100% of their services into k8s there's now more work to be done for the same level of service.
There really isn't. For example, if they go with managed Kubernetes solutions then the only thing they need to worry about is to actually design their deployments, which would be very strange if they couldn't pull off. That's a ramp-up project for an intern if the solution architecture is already in place.
> You would likely still have the same core providers (ex: EBS for storage) but there is now more code running to orchestrate them
There really aren't. Kubernetes' equivalent to EBS is either setting up a volume or a persistent volume claim on a persistent volume. Just state how much memory you want and you're set.
We're seeking an DevOps Engineer to help us maintain the reliability of our core services, grow our engineering processes as we build new applications, and automate as much as possible.
We are a small, close-knit, and enthusiastic team of hackers building analytics that measure the ROI of social media. Our engineering culture embraces data-driven decision making, failing fast, and abiding by the UNIX philosophy: building small, powerful tools with clean interfaces. Additionally, we live on our internal IRC server, relish an opportunity to discuss new technology, and have a bi-monthly board game night.
awe.sm is a small, tight-knit team of hackers building social media insight tools on top of busy APIs and years of data. We do closed loop social attribution allowing our customers to understand the real value of their social activity. Our team is a family, and we're looking for dedicated engineers to grow with.
Our engineering culture embraces data-driven decision making, failing fast, and abiding by the UNIX philosophy: building small, powerful tools with clean interfaces. We live on our internal IRC server, collaboratively building bots to manage our systems and provide stress relief.
We're seeking an operations engineer to help us grow our engineering culture while being the champion of uptime and deploy automation. Experience in architecting systems is a plus, we value operational insight for building reliable systems on unreliable clouds.
