grantlmiller

Kustomize is definitely a huge step forward for configuration management, more info on Kustomize here: www.kustomize.io

if you're running a SaaS or software company, we compiled an abridged version of the full GDPR text that is only 34 pages in this format, very easy to consume: https://www.enterpriseready.io/GDPR-abridged-text-for-SaaS-C...

if you want to read the full thing, we created a quick guide for understanding which sections you might want to skim: https://www.enterpriseready.io/gdpr/how-to-read-gdpr/

The problem is 2-fold, 1) a business/contract problem 2) a technology problem.

The business problem is that your on-prem customers need to accept the idea of being being upgraded to the latest version automatically or on a specific cadence (ie every day, week, month, etc). If they're not willing to accept this, they need to pay you more for the extended support (LTS) of an older version. Many enterprises will be hesitant to accept auto-updates b/c they fear that your application will break during update, you can alleviate that concern with technology as well.

The technology problem can be overcome by using a cloud-native architecture for your on-prem product. This will ensure that your product has the level of reliability that is needed for true modern on-prem deployments you're describing. It will allow customers to do canary updates, rolling updates that will minimize downtime (just like you do for SaaS based CD). Multiple repos, different components, no problem, package them as Docker containers and then deliver the new manifest (k8s, swarm etc) that includes the new images. The key to success here is automation. You have to have a level of rigor for automating every production change with automation (often packaged as a new migration container for the new version). There are other systems you can build to solve for this as well, including release channels that will allow you to push different versions to different customers or staging environments based on specific licenses for each customer.

We've spent the last 4 years turning this problem into a product: www.replicated.com and it currently powers the on-prem versions for Travis CI, CodeClimate, CircleCI, Terraform Enterprise, Gradle and many others who know a lot about CI/CD.

On-prem isn't the problem, building a crappy product is the problem. Atlassian's other products (Jira etc) over 50% of the revenue comes from on-prem customers. Same is true for GitHub: https://medium.com/@moritzplassnig/github-is-doing-much-bett.... It just turns out that offering an on-prem version is not enough to close the gap created by all of the other features, integrations and UX that their competitor had. On-prem is a great feature, but it isn't a silver bullet. Nothing is.

Your first point sort of misses the idea that multi-tenant SaaS applications could and have shut down their service overnight (see Smyte https://news.ycombinator.com/item?id=17371074). At least with HipChat On-prem the customers who are running that version can migrate on their schedule instead of just having the service turned off.

You can always make the argument that for this reason we should only write our own internal tools and use OSS. However, it is just as easy for an OSS project to be abandoned or neglected. Often times enterprise contracts will have a source code escrow clause that provide the enterprise with the source code in the event of a shut down (the same capabilities as a fork & take over maintenance anyway).

We don't actually know the plan for HipChat On-prem yet (do we?). Slack and Atlassian are both known for being customer centric so they will probably follow what Facebook did with Parse. Open source the entire thing, sunset the operations and development over the course of a year or two with minimal security updates/patches and no feature dev. This could be what the investment from Atlassian was tagged for... to make sure their customers are taken care of while most migrate to Slack.

This point is spot on, but often overlooked.

Check out the guide I wrote about your options for this: https://www.enterpriseready.io/features/deployment-options/

Docker/Swarm/Kubernetes is definitely becoming the standard for modern on-prem deployments. You keep the software in sync by delivering new versions of the manifest regularly (you can even have these automatically applied w/ zero-downtime if you're doing automation correctly).

This looks really interesting. Does anyone know if there are plans to open source the framework?

I think that a lot of this is actually being driven by new accounting standards (ASC 606 - Revenue Recognition), basically the new rules state that for subscription revenue to be recognized over time, the software must be materially disabled at the end of the period. This matters mainly b/c it has tax implications. If companies don't disable the software the entire value of the customer's contract must be recognized up front (as well as taxed upfront), this is true even if the payments are still made monthly. Paying taxes now on revenue that comes in later isn't good for cashflows and as such it creates a business problem that trickles down to consumers.

Yea, we can solve this the same way we solve just about every other minor problem, by making it a social norm. We should say something to people who leave them in this state (plus they should design the scooters to stay standing more easily, but these companies are likely as incentivized to do that as scooters that fall break and need repairs).

Side note, sidewalks are generally pretty terrible for people in wheelchairs... cars pulled in across in driveways, curbs without transitions (think of anytime you put the front wheels of your stroller on the curb and lift the back up... how does someone in a wheelchair execute that same move?... they can't), roots, the general disrepair that many sidewalks suffer (terrible in Venice).

I live in SM/Venice and the rise of e-scooters has been amazing. The only problem is that they can't keep up with the demand and as a result, sometimes deliver a poor experience (hunting for a working/charged one after 5pm can be tough).

The problem that people have with e-scooters is that they're new & different. So many people (and local governments) hate change and do what they can to control it. Officials and luddites alike complain about the problems that cars cause (like congestion, pollution, drunk drivers, etc). However, when the free-market offers a solution to the problem that consumers (locals and tourists alike) love, the folks who want to run our lives and tell us what we can and can't do, try to regulate them as much as possible (potentially killing the business or hurting the adoption).

Like most things you can get to the bottom of it if you follow the money (aka taxes). Cities (like SF) will offer e-scooter licenses (aka medallions) so they and their cronies can make these companies kiss the ring, limit the supply and take a big cut of the profits (which will ultimately hurt consumers... aka us).

Isn't it just as likely that this data is being sent to the app vendor's servers and then off to one or multiple third-parties?

Well, you're clearly thinking deeply about this and you seem to care. Which is great. I've been digging in deep on this the last few months so I have some thoughts. Respectfully (srsly), I think you might be misinterpreting the legislation (this resource is provides more concrete examples of how you should interpret it).

For example, Article 17(1) lays out the MANY grounds upon which a Data Subject can request erasure. If ONE of the mentioned criteria is met including the very broad Right to Object (Article 21) then it must be erased. 17(2) states you must fwd this request on to other online orgs. 17(3) provides the exceptions for which a Controller can object to the erasure.

It is important to note that the spirit of GDPR is one where Data Subjects rights (to their data, to object) are the default. Sort of like innocent until proven guilty. This is a big shift for most companies who would contend that they own the data & data exhaust from use of their application.

As for compliance demonstration... yes, this is still a mess. My only suggestion there is that if you're working with software companies, try to study what the leaders are doing and take some inspiration. https://www.enterpriseready.io/gdpr/preparing-for-gdpr/

Happy to hear your thoughts. Genuinely interested in other people's perspectives on this.

This is a great resource because it is from the EU, provides clear examples, cites the actual legislation and Article 29 Working Party Guidelines (which is the group that is tasked with preparing official opinions on GDPR).

I think that if you want to really comprehend something, you should go to the primary source. The GDPR legislation is far more approachable than it seems (as an official 261 page PDF). When the preamble and the mechanical bits about how the GDPR will be governed are removed, the parts that important to companies are only 34 pages long. You can use this to guide your reading: https://www.enterpriseready.io/gdpr/how-to-read-gdpr/

Interestingly, under GDPR EU citizens need to opt in to each of these, explicitly, and be able to toggle them off on an ad hoc basis. Additionally, PayPal is required to list each of these vendor's vendors (which could increase the number of vendors by 1 or 2 orders of magnitude). If companies actually follow the GDPR controls this is going to turtle all the way down.

The problem is that the initial, flawed findings fit the biased narrative that the many in the media (both traditional and social) prefer to perpetuate. As a result, the surveys and stories that support their biases get top billing as headlines for days or weeks. People are often so eager to hear claims that support their beliefs that they don't investigate the credibility of the claims.

When the truth comes out, the same media outlets will likely do nothing and at most will publish a small redaction (same goes for individuals who spread this on social media). I have no expectation that the true nature of this study will be widely reported or nearly as promoted as the initial false results.

The world needs more rational skeptics. We have to hold each other accountable by ask probing questions about the nature of "facts" that are presented us. Seek truth.

Providing different product packages that are usage and featured gated in order to enable SMBs to use the basic version while giving enterprises the functionality they need in the enterprise version is a core concept in going up market with SaaS. We called it "product assortment" based on a talk that Michael Dearing gave several years ago about pricing. An overview of the concept with some examples can be found here https://www.enterpriseready.io/features/product-assortment/

Points 5 & 6 are basically requests for change management (https://www.enterpriseready.io/features/change-management) features. This is SOOOO often overlooked by SaaS vendors.

this reminds me of what Snaptu was doing years ago to bring access to developing countries... worked out ok for them: https://techcrunch.com/2011/03/20/facebook-reportedly-acquir... Also, this is a great way to bring better comms to millions of people who are likely underserved today.

Check out www.enterpriseready.io to get a deep understanding of the standard features that enterprises require (ie SSO, RBAC, audit logs, on-prem deployment, reporting etc). Happy to talk through any of the features, I contributed about 80% of the content. We also built Replicated.com which powers the on-prem delivery for other applications like Travis CI, npm, CodeClimate, Circle CI and a bunch of others. We think about these problems all the time and how we can best help solve them. Happy to share what we've learned there as well.

I was really hoping to read that he plans to dedicate all the resources he made from the success of these companies to creating the solution. Did I miss that?

Maybe he's just trying to get a bit more attention for himself? (Also, feels like there is some amount of irony in the click-baity title and that he published this in an ad supported media outlet.) "I invested early in Google and Facebook and regret it. I helped create a monster." Original story: https://www.usatoday.com/story/opinion/2017/08/08/my-google-...

I love this overall concept. In LA a startup launched last year that will not only rent you the random stuff you don't need to buy, but they actually drop it off & pick it back up from you (www.joymode.com). They organize it all by experiences (ie not so much about tools) but instead here are things you need for backyard movie night, or camping, or pasta making etc. I'm a big fan of owning fewer things... frees people up to move more easily (not being able to move homes is huge cause of under-employment).

SPAs = Single Page Apps (not that everyone here wouldn't know that definition...but acronyms seriously suck ;). They create miscommunication and people who haven't been initiated yet are afraid to ask what it means. This one in particular has a lot of meanings: http://www.acronymfinder.com/Information-Technology/SPA.html (it likely means something completely different to a security person vs a network admin vs a front end dev.)

This law does not seek to keep people from being on-call 24/7... it aims to provide a new "right" to workers where they can expect to go home after 7 hours and if they miss something important after hours (even if it hurts the business dramatically) not be concerned about losing their job. Again, this is in a country that already has 23% unemployment for young workers. I just want to make sure the rest of the world doesn't see these as "progressive" moves, but rather "regressive" as they strip the opportunity for young (currently unemployed) workers.

This comment illustrates an important socialist fallacy... employees are not the biggest part of the economy, consumers are! Consumers win when the products and services they buy are less expensive & better (ie the people who produce them are more efficient).

Making it harder to fire employees for another reason might protect the existing jobs, but it lacks the foresight to understand that these practices simply disincentivize employers from making future hires in the country. As a result, this is another move by the French gov to protect the status quo. The French labor market has already been regulated to the point of anti-competitiveness. This immediately hurts younger workers who are willing to work harder than their entrenched counterparts, but instead find themselves unemployed at a rate nearing 25%. More business as usual for paternalistic government lawmakers.

A few other solid online resources for SaaS founders (hard to really call these "online communities", though most do have vibrant community events tied to them): http://www.saastr.com https://hitenism.com http://www.enterprisesales.nyc http://www.heavybit.com/library https://www.enterpriseready.io

Ha, makes sense... I didn't really take any offense.

I appreciate your level response. You're correct that these features are not absolutely, always necessary for success. I would caution that even with a an incredibly compelling core feature set, you still have to negotiate yourself out of not providing these features. Even when you win you might be creating a maintenance nightmare for someone down the totem pole within your customer's org. Part of what we're trying to do with EnterpriseReady is show that many of the non-core (yet common among many enterprise customers) features 1) aren't that hard to understand 2) can be built really well in a way that will delight your users.

* As the OP, when you say: "some are just something someone added to a list because they thought it sounded like a good idea" - I genuinely hope that I did not do that.

100% - Always be thinking about security.

I love this conversation. @ohstopitu thanks for asking great questions & @NeutronBoy thanks for providing great answers.