I disagree, that's a price point concern not a market accessibility one. I strongly prefer to be able to sell to another 400M people than not have the option to do so.
143 karma · joined April 26, 2010
I run a small business (scanii.com) and I've noticed over the past year an increasing number of customers leaving us to European competitors, customers that have been happy with us for years, using our European region, but now have concerns over US foreign policy and are giving preferred treatment to EU suppliers. When I asked they said, I'm paraphrasing here, "happy with the product but management wants EU supplier".
What this means in practical terms is that, if the tide doesn't change, US entrepreneurs will have a potential buyer population that is roughly cut in half if they can only sell to US buyers. This will have a cascading negative effect in the number of startups that succeed - impossible to quantify at this point.
Large corps can skirt around this issue by establishing an EU entity and trying to buy goodwill that way but that's not an option easily available to small businesses.
I fear rough waters ahead.
It's hard, and some might argue impossible, to statically analyze reachability in a dynamic language like java that allows for runtime class loading and redefinition. As it turns out, Java is much closer to javascript than C++ in terms of dynamic runtime behavior.
With PGO you do a lot of deliberate work to profile your application under different conditions and feed that information back to the compiler to make better branch/inlining decisions. With a AOT cache, you do nothing up front, and the JVM should just dump a big cache to disk every time it exits just in case it gets stared again on the same host. In this case, training runs would just be a” run you did to create the cache". With that said, the big technical challenge right ow is that building the AOT cache is expensive hence performance impacting and cannot really be done alongside a live application - but that’s where I think the focus should be, making filling the aot cache something less intensive and automatic.
Another aspect this strategy would help with is “what to do with these big AOT cache files”, if the AOT cache really starts caching every compiled method, it will become essentially another so file possibly of a size greater than the original JAR it started off with. Keeping this is in a docker image will double the size of the image slowing down deployments. Alternatively, with the aot cache concept, you just need to ensure there is some form of persistent disk cache across your hosts. The same logic also significantly helps CLIs, where I dont’ want to ship a 100MB CLI + Jlink bundle and have to add another 50MB of aot cache in it - what I do want is every time the client uses my CLI the JVM keeps improving the AOT cache.
Thanks and good question. We don't really compete with virus total since it's more of a research tool and, for a while, their terms explicitly prohibited commercial use (but I think that has changed). Jotti is a similar thing, more of a research tool than a high performance API you can use to build commercial products on.
> Presumably you're now using commercial AV tools, rather than Clam? Did you have to get some kind of special license from them to use it like this?
Yeah the product has expended a bunch over the years and we use multiple detection engines [2] to catch all kinds of unsafe content. But you are right, we do license a commercial AV engine to act as a backup to our own to ensure best possible detection rates. The licensing process warrants a blog post of its own since it's not what I would call easy.
[2] https://docs.scanii.com/article/149-how-do-the-different-det...
Best of luck with your launch!
That is very kind of you, thank you.
> What did "getting it out there" consist of for you? How did you get it out there in the beginning?
For Scanii in particular, the original product was a thin wrapper around an open source AV engine, a hacked on a weekend UX, and a credit card processing integration to collect payment - the very minimal needed to find out if _anyone_ was willing to pay for this service.
With that said, what worked for me in this case is not what I would focus here since it depends on what kind of business you are trying to build. What I do believe is important is focusing on the economics of your space which, for IT, is all about productivity or, more succinctly, saving people's time - they pay you X for something that could cost them, in terms of people's time, Y to do.
So, what you want to ask yourself is whether signing up, paying and onboarding onto your product (the X in the equation above) is significantly lower than the next best alternative, either doing the same on a competitor product or building something themselves - the Y above.
For scanii, even at launch it saved people lots of time managing and operating malware detection engines which are cumbersome and hard to keep up to date. I had a feeling that would be the case when I launched but I couldn't be sure until our first customer voted with their credit card.
My advice to aspiring entrepreneurs: get it out there quick, listen to your customers and be ready to act on their feedback. Finding product/market fit is a journey even if you are selling into the most well understood vertical since it's not just about what the market expects it's about what your engineering talent/capacity can delver in a reasonable amount of time.
Building it was one of the best decisions I made in my life since it enabled me to make hard decisions at work that were not skewed by the fear of losing my job and not being able to provide for my family - I'm in engineering/product leadership.
But, do not be fooled, this also means I've had two jobs (albeit of unequal urgency) and that, obviously, equates to long work hours.
Little bit os background: writing pattern matching signatures is hard, adding a bunch of "known malicious" hashes to your malware database is easy.
So, company A with a staff of folks writing pattern matching signatures has its engine added to VirusTotal and virus total shares/sell hashes found by that engine to folks that pay for its API. Company B, without a staff of engineers writing pattern matching signatures, signs up for VirtualTotal API and creates its malware database based purely on the hashes other actual engines create.
Two important things to keep in mind, when this happens at the scale of VirusTotal (basically all real engines are participating) the end result "hash database" is, essentially, bullet proof since it's likely that any sample used to test its effectiveness will be run by VirusTotal first.
We (I run scanii.com a malware/content detection API service) run into this all the time with folks either abusing or just not understanding the reason VT exists.
So, alternatively, you could do something with DynamoDB event sources, where you have some sort of pub/sub table that your lambda functions listen on (basically a list of all the http requests that have to happen) - thus keeping a minimal 1 lambda dispatch per http request. The catch is you would need another system to manage that table (technically that system can be lambda itself).
Two important things, 1) I haven't used the dynamodb/lambda integration myself so be skeptical of my suggestion and 2) what I can say from our usage of the s3/lambda integration is that concurrency is not a problem with thousands of lambda dispatches/second being surprisingly quick to spin up.