grantlmiller

i like it! and yes, that is correct :)

We’d love for this to be true... most images fill up with CVEs so fast in dependencies, we’re providing minimal images (much less surface area) and have the automation to rebuild the entire dependency graph at least daily, if not multiple times per day.

Hopefully everyone will run a "proper security program" someday!

well... our core users are ISVs (who distribute commercial software into enterprise controlled, self-hosted environments... think big banks, governments, tech companies). They care about supporting OSS (almost 1/2 of them are open core themselves) and their customers mandate that they care about closing out CVEs quickly in the software they're consuming from them.

the goal is going to be 6 hours!

thanks! say more about what you mean... you're saying instead of: Secure, Sustainable Open Source Partner with SecureBuild to offer secure, vulnerability-free builds of your open source project while generating recurring software revenue, no support contracts required.

we should say something different?

for those of us who haven't been through an "AI winter", it's really interesting to hear a debate about AI from nearly 40 years ago.

nice to see this on the front page of HN, I'm one of the creators of EnterpriseReady (and the host of the podcast: https://enterpriseready.io/podcast) happy to answer questions or take feedback!

I did this interview with Mitchell about 18 months ago (time flies), given their IPO yesterday it feels like a great time to look back at the early lessons learned from building an iconic open source, developer tooling company.

Honestly it depends. I've helped a two companies I've angel invested in wind down, it isn't fun and a lot of other investors walk away. As a founder you have a good amount of your reputation wrapped up in this company, so how you exit is how you'll be remembered. If you're the CEO, you should probably to stay on to wind it down, make sure you leave some cash to close out bills (lawyers etc). If you have revenue and a decent team you might be able to "soft land" it to a bigger co for about the amount of $ that you raised (in new co stock for investors) and retention packages for the team.

If you're not the CEO, you have less responsibility to stay (but might reduce the value in a soft landing), very situation specific. From your quick description of what you might do and what you've liked doing, you'll be a great resource to any team... but if you're technical and like spending time with customers you'll be VERY valuable to a technical company (on either the business or engineering side honestly).

If you are looking, would love for you to consider Replicated. We're 100% remote, deeply technical, recently raised a Series C and have lots of openings for technical folks: https://www.replicated.com/careers (and since our customers are other enterprise software companies, your experience is likely valuable). Feel free to email me directly: grant at replicated (same invite for other HN folks if this sounds interesting).

Co-founder of Replicated here, a bit late to the party but happy to answer questions. Also, very important to highlight the unique aspect of this program... we now reimburse a MONTHLY home office expense (using the IRS calculation % of square footage of home). We're paying a portion of your rent or your mortgage (as much as the IRS allows), plus other cool benefits.

This is great. I feel the same way, but have been trying to train the existing YT algorithm. I started using my work email youtube profile to actively subscribe/like/save videos that I want to see more of (about hiring, management, culture, Kubernetes, devtools etc). At the same time I aggressively choose "not interested" and "do not suggest this channel" when the algorithm isn't suggesting what I want (more detail: https://twitter.com/GrantM/status/1325471071265558532).

This title feels like click bait. The story is interesting, but this product never had real revenue (definitely not $20k/month). "At its peak, Graphite was pulling in $20,000 a month in grant money. The design of the grant program was such, though, that after a while money would be allocated to other applications built on the protocol offering the grants. All told, Graphite received about $130,000 in grants."

What else would you like to see? We launched a few GDPR resources a year or two ago: https://www.enterpriseready.io/gdpr/

This podcast episode with the founder of ScaleFT goes into the history of enterprise networking so you can understand the reasons for why they are like they are: https://www.enterpriseready.io/podcast/paul-querna-scaleft/

First-party SaaS meaning things like RDS, DBaaS, queues, LBs etc? Most of that I would sort of put into a IaaS controlled PaaS, rather than true IaaS SaaS. Yes, these are generally higher on the trust spectrum as they don't involve additional vendors accessing/managing/storing data.

I always find it important to separate "cloud" into 2 categories:

1. IaaS - Which I mainly define as the raw programmable resources provided by "hypercloud" providers (AWS, GCP, Azure). Yes, it seems that using an IaaS provider with a VPC can provide many benefits over traditional on-prem data centers (racking & stacking, dual power supply, physical security, elasticity, programmability, locations etc).

2. SaaS - I lump all of the other applications by the hundreds of thousands of vendors into this category. I find it hard to trust these vendors the same way that I trust IaaS providers and am much more cautious of using these applications (vs OSS or "on-prem software" versions of these apps). They just don't have the same level of security controls in place as the largest IaaS providers can & do (plus the data is structured in a way that is more easily analyzed, consumed by prying eyes).

This is pretty much all we do/think about. A few resources that we have created that will help: - https://www.enterpriseready.io/features/deployment-options/ - https://replicated.com - https://kots.io

Free, for everyone... even those without symptoms. It does feel like "number of tests administered" per region during said time period would be an important stat for context. But who am I to let details get in the way.

Looks cool, love the idea of using version control for video content. No mention of pricing that I could find easily.

I'm torn on this list. It is important to learn from the mistakes from others, so I like it (postmortems are great for this reason), BUT it feels like folks are using these examples as reasons to stay away from Kubernetes. There could be a significantly larger list of system failures where K8s is not involved. Similarly there could probably be a list of "Encryption Failure Stories" but that doesn't mean we shouldn't encrypt things.

As an industry, one of the things we do pretty well is identify the most viable patterns to solve a problem and then develop and adopt the best primitives of those patterns. This is what Kubernetes is for creating reliable, scalable, distributed systems.

We built this tool for use in some of our CI workflows. It solves the problem of not having to share secrets to a Docker registry for pull requests. It is a pretty simple service (and OSS) if you want to run it yourself: https://github.com/replicatedhq/ttl.sh (we'll be contributing a Kubernetes manifest soon to make it easier to deploy your own private instance).

First, I've loved that Google open sourced Tensor Flow Federated as a way to encourage the rest of the world to adopt this method of decentralized machine learning.

Second, I was a bit disheartened that this concept had to be explained with a comic strip to make it accessible because I hoped the benefits were clear to everyone.

Third, I read the comic strip, learned new things (secure aggregation protocol, wtf, amazing!), kicked myself for being smug and appreciated the huge amount of effort that someone invested to communicate this.

"If you’re analyzing data that comes from cloud data sources anyway, there’s really no sense in “deploying”."

- This is only true if the security controls that your team, application, infrastructure has in place is matches the major cloud providers (i.e. Salesforce, Google, AWS, Microsoft). Even then, spreading your data around to 1,000 different SaaS vendors increases the surface area for attack/loss by 1000x.

"Trying to build a vertical analytics offering on top of OSS increases the level of difficulty by 100x"

- 100x is hyperbole, it significantly harder before OSS was focused on operations, but now there is an HA Helm chart, or even an K8s operator for most of the popular OSS components. It might still be slightly harder today, but organizations that want to pull insights from THEIR data often value the proprietary nature of that data.

Generally agree on your broad point, but not on the architecture. I'm biased, but I would suggest that if you follow GitPrime's lead, you architect with OSS components that you can deploy on-prem as it was crucial to their success: https://blog.replicated.com/gitprime-enterprise-saas/

The pattern of Helm template + Kustomize is operationalized with Ship: https://github.com/replicatedhq/ship plus some other functionality to automate pull requests from upstream updates.

The inclusion of Kustomize[1] into kubectl is a big step forward for the K8s ecosystem as it provides a native solution for application configuration. Once you really grok the pattern of using overlays and patches, it starts to feel like a pattern that you'll want to use everywhere (even outside of the k8s ecosystem).

I'm excited to see that the kubectl docs[2] are actually recommending -k as the default solution (vs -f).

  Though Apply can be run directly against Resource Config
  files or directories using -f, it is recommended to run
  Apply against a kustomization.yaml using -k. The 
  kustomization.yaml allows users to define configuration
  that cuts across many Resources (e.g. namespace).

Really amazing work from everyone on this release.

[1]https://kustomize.io

[2]https://kubectl.docs.kubernetes.io/pages/app_management/appl...

EKM does not provide the same security as a password manager for the content (i.e. Slack messages and passwords). In this case Slack is still able to request a key from the KMS in order to perform operations over the messages (search, archive etc). Those keys generally have some sort of expiration on them by default (hour, day, etc) before they're rotated. However, during that window the key could be copied and used w/o the "reason" being logged. More realistically, the security threat is that there is a bug somewhere that while the data is unencrypted in memory it accidentally logs some proprietary data into a secondary system that is not encrypted with the same EKM system... EKM is a bit of shell game but everyone loves some good security theatre.

This has super broad applicability, beyond mobile, federated learning could become the answer to invasive, data hungry centralized applications that "need the data to make the system better"... no, you just need to learn locally & send a learning summary to a central system, not the data.

This is an excellent overview.

ya, this doesn't install anything in the cluster, you run the command on your cluster, sanitize the private image info out of it, then paste in the public image names & SHAs