Scaling Mesos: A Perspective Featuring Mesosphere, Airbnb, Ericsson and Others - <AUTHOR> http://www.meetup.com/Bay-Area-Mesos-User-Group/events/216433322/

<comment><AUTHOR> Schedule:

6:30 - 7:00 Networking and Light Dinner

7:00 - 7:10 Announcements

7:10 - 7:40 Mesosphere: Deploying Docker Containers at Scale with Mesos and Marathon

Abstract: The norm these days is to operate apps at web scale. But that's out of reach for most companies. Marathon is an open source project that makes it considerably easier to deploy Docker containers at web-scale using Apache Mesos.

See how Mesos and Marathon can help deploy and manage Docker containers at scale and how the Mesos cluster scheduler builds highly-available, fault- tolerant web-scale apps.

Bio: Sunil studied Computer Science at the University of Cambridge, where he wrote his dissertation on delay-tolerant networking systems. After four months spent cycling across Africa he returned to London to join a major investment bank and then Last.fm as a Data Engineer. Last year his interest in robotics brought him to UC Berkeley, where he completed a Master of Engineering degree with a focus on distributed computing and unmanned aerial vehicles, working in his spare time on an UAV startup. After leaving Cal, he joined Mesosphere as a Distributed Applications Engineer and is currently working on easy deployment of Mesosphere clusters on Google Cloud Platform.

7:40 - 8:10 Airbnb: How we're using Mesos at Airbnb today

Abstract: Mesos is the operating system for Airbnb's data platform. We use Chronos, Marathon, Hadoop, and other frameworks for operating a complex system of data warehouse and analytics tools. In this talk, we'll discuss how some of the day-to-day operational problems are solved using these systems.

Bio: Brenden Matthews is a software engineer at Airbnb, working on the data infrastructure team. He is an Apache Mesos contributor, the primary maintainer for Chronos and Hadoop on Mesos, and has also contributed to related frameworks such as Storm, Spark and Marathon. Previously, he has given talks at about Mesos at Twitter, QCon, and MesosCon.

8:10 - 8:30 Ericsson: On the use of Mesos and Marathon for Multi-Datacenter Service Orchestration

Abstract: With the availability of numerous geographically distributed datacenters, there is an increasing need for highly distributed service orchestration. Apache Mesos and Marathon are valuable starting points for further exploration towards a system enabling such service orchestration while achieving high datacenter utilization and providing high availability. However, both frameworks are designed and used for (resp. on) a single datacenter.

In this talk I will present prospectives on leveraging Mesos and Marathon as building blocks to orchestrate Docker-based services across multiple datacenters.

Bio: Eugen is a Senior Research Engineer at Ericsson Research Silicon Valley Lab. He currently builds systems which leverage real-time big-data analytics for improved resource management in large-scale datacenters. Prior to that, he was a postdoc in the Data Intensive Systems Group of the Advanced Computing for Science Department at the Lawrence Berkeley National Lab (LBNL). He holds a PhD in Computer Science from the University of Rennes 1, France which he received while working in the Myriads INRIA project-team. During his PhD he worked on systems and algorithms for autonomic and energy-efficient resource management. Eugen received his Bachelor and Master of Science degrees in Computer Science from the Heinrich Heine University Duesseldorf (HHU), Germany. He was a student research assistant in the HHU operating systems group, interned in the Myriads INRIA project team and was a summer intern at the LBNL.

8:30 - 9:00 Common Q&A

</comment><comment><USER2> I'm very interested in how Mesos can serve up http in a Highly Available way to all these services that run internally in the cluster. Has that problem been solved and will that be on topic at the meetup?

<comment><AUTHOR> Marathon is a Mesos framework for long-running "always on" apps that can serve up http among other things.

It ensures that an app stays up even when machines or entire racks fail.

</comment></comment><comment><USER3> Awesome, curious to see how Airbnb used this with Hadoop</comment>


Waymo has raised $3B in the last two months - <AUTHOR> https://www.wsj.com/articles/waymo-adds-750-million-to-war-chest-as-driverless-cars-prove-tough-to-deploy-11589299200 <comment><USER3> Can anyone explain why does Waymo need to raise any money? Doesn't Alphabet have practically infinite pockets? If they are confident of Waymo, why would they want to share the profits with anyone else ever?

Even if Alphabet was reluctant to invest their own profits, can't they borrow cheaply too?

<comment><USER4> I think you answered your own question: _if they are confident of Waymo_

As I said a couple months ago, the "Waymo" name is a sign. If they really believed in the product, it would be called "Google Self-Driving Cars".

[https://news.ycombinator.com/item?id=22632588](https://news.ycombinator.com/item?id=22632588)

<comment><USER5> Different brands can make sense though. Youtube isn't called Google Video and Blogger isn't Google Blogs.

<comment><USER6> Google Video was an actual product, competing with Youtube. When they decided to acquire the much more successful Youtube, its brand already had a lot of value and recognition, so it survived.

[https://en.wikipedia.org/wiki/Google_Video](https://en.wikipedia.org/wiki/Google_Video)

<comment><USER7> Similar, on a smaller scale, for Blogger. Google acquired it.

<comment><USER8> Yet they applied the google name to nest? Android remains without a google moniker (other issues there).

Point being that google has quite a few inconsistencies in their naming (which is a thing in itself) and their not applying Google brand to Waymo at this point is any indication.

<comment><USER9> Android was also acquired.

</comment></comment></comment></comment></comment></comment></comment><comment><USER10> They've raised $3B in 2 months; this round was $750M. The original headline:

"Waymo Adds $750 Million to War Chest as Driverless Cars Prove Tough to Deploy"

<comment><USER11> That headline should also be the title for this submission.

<comment><USER12> headline police-- 'We protect and serve people who don't read articles'

</comment></comment></comment><comment><USER13> Meanwhile, Tesla continues to iterate on a production fleet with a (admit idly rough) new capability rolled out to allow autopilot to obey stop lights and stop signs.

If I were a investor that invested in individual stocks (which I am not), my money would be on Tesla over the long run here.

<comment><USER14> Waymo did considering the iterative method and decided against it intentionally. Putting aside the obvious danger of incrementally getting to L4 (the inbetween state where the system feels safe enough for users to not pay attention, but actually isn't), it's actually not obvious that there is an obvious smooth transition from L2 to L4.

Yes, Tesla may be getting more data in the field, but Waymo is still much further ahead with actual fully self-driving car without anyone at the wheel (within a small region + good weather). Also worth pointing out that the quality of the data also matters, not only the quantity.

<comment><USER15> > "Waymo is still much further ahead with actual fully self-driving car "

Tesla is ahead where it counts, sales. it feels like waymo was already 'successful' in small regions with good weather not requiring complex thought situations in 2018. meanwhile tesla is improving designs, expanding capabilities, and selling cars.

I'm not a tesla fan boy, but I definitely prefer their approach in terms of iteration (not sure if I agree with the tech choices).

<comment><USER16> > _Tesla is ahead where it counts, sales._

Where it counts for what? Tesla has demonstrated it can sell non-autonomous cars, Waymo has not, but the GP's point is it's not clear what bearing that has on making an autonomous car work.

<comment><USER15> Because you have to sell them, and they actually have a product in the market. if you don't intuitively understand that, there is nothing more to say because you just don't understand it to make an informed thought on it.

I'll give you a hint, the technology doesn't define the product.

<comment><USER14> > the technology doesn't define the product

Product here is "L4 self-driving technology", not "car" as you seem to be implying. Yes, Tesla is shipping cars, but they are nowhere close to L4 self- driving (aka no one at the steering wheel).

> they actually have a product in the market

No they don't. They have a _car_ on the market, and an L2 driving assistant. As I was implying above and again repeated by the post you replied to, there's no indication that you can transition from L2 to L4 in a gradual manner, so "L2 product in the market" means absolutely nothing.

Here's an analogy for you, I'm saying that Google is ahead of Intel in making a Quantum chip, and you tell me that Intel is right now shipping millions of classical chips, therefore they are closer to making quantum chips. My argument is that the jump from L2 to L4 is similar to classical vs quantum chips, and shipping millions of L2 cars does not mean you're any closer to L4 technology.

</comment></comment></comment></comment></comment></comment><comment><USER17> Does anyone else think that the massive decrease in driving (due to lockdowns) is a game-changer for the outlook on autonomous vehicles? Suppose we can embrace a society with fewer drivers, isn't that better for autonomous vehicles by most metrics?

<comment><USER18> I expect we will see gradual conversion of roads to be more amenable to autonomous driving - barriers for pedestrians, special markings, etc - <USER2> autonomous zones will become more and more commonplace.

On the other hand I think with the collapse of the economy and skyrocketing unemployment, the price for a human driver may plummet. Remains to be seen if the increased demand in deliveries is enough to offset the voids left in the rest of the economy.

<comment><USER19> I don't see it happening for the US that way. The increased cost of infrastructure would probably be too much? Unless the US figures out how to lower construction/maintenance costs reliably, I don't see those features being added. It feels like we're already pretty low on features... It takes years for faded lines to be repainted on the road.

</comment></comment></comment><comment><USER20> Unpaywalled: [http://archive.is/Beahs](http://archive.is/Beahs)

<comment><USER21> Is there a chrome extension or something that finds these links automatically?

<comment><USER22> Here's what I use: [https://github.com/iamadamdev/bypass-paywalls- chrome](https://github.com/iamadamdev/bypass-paywalls-chrome)

Not available on AMO or Chrome Webstore, unfortunately, but is very easy to install on Firefox, and requires just a bit of effort on Chrome.

<comment><USER23> thank you for posting this! in a mere 5 minutes of use you have earned a thousand thank-yous.

:thumbsup:

</comment></comment></comment></comment><comment><USER24> I dont understand Waymo and what they are doing. What is their path to making money on this?

They are not building their own cars, haven't partnered with any automakers either. In fact they discussed with a bunch of them and couldn't convince any company to partner with them. Most of the automakers already are investing heavily in their own autonomous tech stack. Unless they blow everyone out of the water with their technology I don't see them selling their stuff to automakers.

The only path then is an Uber competitor. That means they have to acquire a fleet custom made for their solution. That is a huge investment a large undertaking, not sure Waymo has it in them to do it. This is not Google wave to abandon so I am sure they will not do so, however I will not be surprised if people grow frustrated by the lack of clarity.

<comment><USER25> I get your frustration -- but at the same time, i'm darn glad they are doing "stuff" whatever it might be. Self driving cars will change the world in so many ways. Traditional industry was too close-minded to tackle the challenge and now we have non-traditional players (Google, Uber) leading the charge -- this has spurred traditional players to jump in. It also creates a statistical-ish way to spread strategy bets in approach. Hopefully some combination of the many approaches being used wins -- then we all win.

</comment></comment><comment><USER26> Can anyone explain the business model of a self-driving car company? We already have this service, except it's powered by humans. Humans who own the cars, store the cars, clean them, and take care of all the maintenance.

A self-driving car company will have to own a huge depreciating asset, and they'll still need staff to clean & take care of the cars in addition to an enormously expensive engineering team and/or licensing payments.

What business model are these companies trying to fulfill? It seems like they are trying to solve a problem that doesn't exist.

<comment><USER27> Except self driving trucks can drive 24/7 and never take a break. You've seen those truck stops where there's 30-40 trucks sitting idle while their drivers are sleeping and on mandated breaks? Wasteful.

If all cars are self driving we can eliminate red lights and traffic signals because of machine coordination.

Better utilisation of cars will lead to a 5x to 10x decrease in traffic, and route planning algorithms will optimise pickups and simultaneous package delivery.

Your car can go and ferry people around rather than sit idle taking up parking spaces while you're at work (copy paste this for 200,000 workers in the city) and make you money

The car can go fuel and charge itself and drive itself to servicing and cleaning.

<comment><USER28> Other than the trucking example, none of those are business models for self driving car companies.

<comment><USER27> The trucking model is profitable enough. Truck drivers is literally the most common job in the US.

And what if the ferrying people around part is a revenue share between the self driving car company and the car owner?

</comment></comment></comment></comment><comment><USER29> [https://archive.md/BhlFN](https://archive.md/BhlFN)

</comment><comment><USER30> I'm not sure I would be so pleased as an employee or share/optionholder in Waymo about the fundraising. In fact, people forget that fundraising isn't something really to be overly proud of. It's a loan, whether it's phrased that way, or as an equity stake.

It was all fine when they got free money from Google to power their experiments (cars, people, time). Now they're borrowing from their own value to pay investors for the loan.

I'd want to see some belt tightening from what is sure to be an overly large engineering team and lots of support staff, if there were ever to be the promise of becoming profitable (and to eventually pay for these loans from investors).

</comment><comment><USER31> It'll be interesting to watch Waymo try to make it on their own.

I predict they end up focusing on semi-autonomous trucks instead of cars for regular people.

</comment><comment><USER32> Title is misleading.

</comment><comment><USER33> y

</comment><comment><USER34> They primarily make software right? 3Bn seems like a lot of cash for a software company to need. That's 2m dollars per employee. What am I missing here? Am I just old and out of touch?

<comment><USER35> They also design hardware, and they run a fleet of 600 vehicles in Arizona by last count. They're also ramping up a new fleet of up to 20,000 no doubt very expensive vehicles.

[https://www.wired.com/story/waymos-self-driving-jaguars- arri...](https://www.wired.com/story/waymos-self-driving-jaguars-arrive-new- homegrown-tech/)

<comment><USER34> Thanks, I had no idea they were over 20 cars, let alone 600->20000.

20,000 seems like a proof of concept. If you have 20,000 cars and they're mostly on the road, you could open your own Uber in a city...

</comment></comment></comment><comment><USER36> One oft-repeated line about driverless cars was that they would improve the world by reducing car accidents, and possibly helping with congestion and parking problems.

The pandemic has proven that these goals and many more can be accomplished without any complicated, speculative AI technology, simply by taking full advantage of telecommuting and delivery. Obviously there is no profit to be made so it would make no sense for investors to do so, but I wonder what $3B could accomplish if it were put to the purpose of reducing the need to travel, rather than finding new ways to burn gasoline.

<comment><USER37> I'm pretty sure delivery drivers also get into car accidents.

<comment><USER36> Fewer miles, fewer accidents. One delivery truck can replace many personal car trips.

</comment></comment></comment><comment><USER38> I'm not a car owner but I wouldn't buy a car from Google or a car that is connected to the internet / saves data into logs that can be read in a garage.

I wouldn't buy a car from Google because of this [1]. Even if Google promised not to collect data I wouldn't believe them.

[1] [https://www.theverge.com/2017/11/21/16684818/google- location...](https://www.theverge.com/2017/11/21/16684818/google-location- tracking-cell-tower-data-android-os-firebase-privacy) _Google admits it tracked user location data even when the setting was turned off_

<comment><USER39> How do you feel about Tesla in this regard?

<comment><USER40> I wouldn't buy a Tesla and I wouldn't drive one if it was given to me free. Despite the legal property of a car title, you can't really own a Tesla, they control the software "activation" and "license" that it won't operate without. And even if you don't use the Autopilot sensors, Tesla uses them to collect data for itself.

Waymo would have all the same problems, except I doubt Waymo is targeting cars people would buy at all. Google seems set on delivering a transportation service. It's questionable if they'll ever sell their system at all.

<comment><USER41> They might disable supercharging for crashed vehicles but the software itself was never deactivated for anyone.

<comment><USER40> It's a little more than supercharging: [https://www.teslarati.com/think-twice- buying-salvaged-tesla-...](https://www.teslarati.com/think-twice-buying- salvaged-tesla-model-s/)

"However having Tesla Motors maker of the Model S activate the car's onboard computer and allowing it to drive"</comment></comment></comment></comment></comment>


The Return of Color - <AUTHOR> http://techcrunch.com/2011/09/21/color-targets-new-facebook-powered-app-exclusively-to-harvard-students-says-harvard-student/

<comment><USER2> At first glance I misread the title and thought it said: "the return of in living color" - that made me excited.

When I actually read the title correctly, and clicked through to skim the article - that made me 'meh'.

You know who else thought they could make money by turning themselves blue? Tobias Funke.</comment>


Introducing sphinx-js, a better way to document large JavaScript projects - <AUTHOR> https://hacks.mozilla.org/2017/07/introducing-sphinx-js-a-better-way-to-document-large-javascript-projects/ <comment><USER2> I use jsdoc2md[1] and Gitbook[2], with a plugin[3] to integrate the two. An example of docs automatically generated from JSDoc comments: [https://scriptare.gitbooks.io/compago/](https://scriptare.gitbooks.io/compago/)

[1][https://github.com/jsdoc2md/jsdoc-to- markdown](https://github.com/jsdoc2md/jsdoc-to-markdown)

[2][https://www.gitbook.com/](https://www.gitbook.com/)

[3][https://github.com/zandaqo/dmd-plugin- gitbook](https://github.com/zandaqo/dmd-plugin-gitbook)

</comment><comment><USER3> I've long held that there are two types of documentation.

\- One, like this and JSDoc, is structured documenting of the code interface. It's a reference tool.

\- Two, is a more free form documenting of _intent_. Commented source code tools like Docco serve this well.

Both are useful in different situations and don't replace each other. For 3rd party tools the former is more useful, for internal - the latter.

Unfortunately the parsers for each are usually mutually incompatible and I really wish there was a tool that supported both.

<comment><USER4> That's what I've always liked about Sphinx: you can get reference docs extracted from source code, but you can also surround them with more in-depth introduction or explanation.

For example, these are the reference docs to a package I used to maintain: [http://django- tidings.readthedocs.io/en/latest/reference.htm...](http://django- tidings.readthedocs.io/en/latest/reference.html). They're entirely extracted from the source.

However, most of the other pages in that manual are written expressly for new users, organized to teach. The magic of Sphinx is that those introductory pages can link effortlessly back into the reference docs. There are many examples on [http://django- tidings.readthedocs.io/en/latest/introduction....](http://django- tidings.readthedocs.io/en/latest/introduction.html).

And it doesn't stop at linking; you can also embed extracted docs into the midst of a contextualized explanation. See [https://mozilla.github.io/fathom/optimization.html](https://mozilla.github.io/fathom/optimization.html), which is JS code and so uses sphinx-js.

I missed all that power from the Python world; that's why I ported some of it to the nascent JS ecosystem.

<comment><USER3> It's certainly good at being descriptive but it's still very focused on the reference style interface.

Which is _fine_ of course, but it doesn't really help with the latter case as anything other than a secondary concern. That's _great_ when your primary usage is as a reference but suffers the same problem as JSDoc/etc when it isn't.

But it's a _better_ form of what it's doing, for sure.

<comment><USER5> You can write a book with ReST. Nobody's going to do that with Javadoc. The documentation generation features are all bolt-ons and not in any way central to how Sphinx works.

</comment></comment></comment></comment><comment><USER6> I think it is unfair that the article says there is only one other contender.

There exists for example esdoc [1] which is capable of compiling together written documents with generated documentation. I've just implemented this for two work projects with the return of many thanks from my team.

That said I will also check out sphinx-js because we also maintain python projects and already use sphinx for those.

[1] [https://github.com/esdoc/esdoc](https://github.com/esdoc/esdoc)

<comment><USER4> Author here. I just learned about esdoc this morning; thanks for mentioning it! But it doesn't appear to be much of an improvement over JSDoc for my purposes, as you still get little control over the organization of your content. It is alphabetical reference docs plus a few predefined bolt-on pages ([https://esdoc.org/#integration-manual](https://esdoc.org/#integration- manual)):

        Overview
        Design
        Installation
        Usage
        Tutorial
        Configuration
        Example
        Advanced
        FAQ
        Changelog

You can't add more. And, as far as I can tell (the documentation I can find is silent on the point), those pages are islands, with no ability to call content out of the code. (I'd love to be shown wrong. Did you find otherwise?) However, I do applaud esdoc's better support for more modern JS features!

<comment><USER6> Some of your assumptions are incorrect. Those names you list are documentation categories, under which you can publish any pages in your own order. The final docs do not actually display those category names, but some have different menu colours by default.

You can also link between written docs and API docs, though it is a bit manual/hacky (you need to know the rendered file paths).

<comment><USER4> Thanks for clearing that up!

</comment></comment></comment></comment><comment><USER7> I have yet to see anything that actually documents well other than code itself. Comments are _always_ subject to the problem of going stale or being poorly worded. I haven't played with it much, but Clojure's spec looks like a good tool for documenting how functions should behave. That plus a description in the docstring might be the best thing out there right now.

<comment><USER8> Have you seen Elixir's doctests[1]? They're docs with a code example that gets run by your tests, and if the example doesn't work, your tests fail.

[1][https://elixir-lang.org/getting-started/mix-otp/docs- tests-a...](https://elixir-lang.org/getting-started/mix-otp/docs-tests-and- with.html#doctests)

<comment><USER9> Python also has a similar concept: [https://docs.python.org/2/library/doctest.html](https://docs.python.org/2/library/doctest.html)

Sphinx also has additional doc testing methods that let you test the code examples in your actual docs: [http://www.sphinx- doc.org/en/stable/ext/doctest.html](http://www.sphinx- doc.org/en/stable/ext/doctest.html)

<comment><USER10> I was surprised (and pleased) to find out that Rust has doctests as well.</comment></comment></comment></comment>


Deadspin writers quit en masse over 'stick to sports' memo - <AUTHOR> https://nypost.com/2019/10/30/deadspin-writers-revolt-say-theyre-quitting-over-stick-to-sports-memo/ <comment><USER2> From another article the OP linked to:

> By Tuesday, rebellious staffers were filling the site with entirely non- > sports stories — and the site's deputy editor said he had been fired for > refusing to follow the directive.

Ok, so these journalists are refusing to ignore real news for the sake of solely covering sports. I can get behind that...

> Top postings on Tuesday included "Woman Furiously S—s on Floor of Tim > Hortons, Throws it At Employees," as well as "What Did We Get Stuck in Our > Rectums Last Year," and "The Hateful Life and Spiteful Death of the Man Who > Was Vig the Carpathian."

Oh.</comment>


Well-Architected Monoliths Are Okay - <AUTHOR> https://robertnorthard.com/devops-days-well-architected-monoliths-are-okay/ <comment><USER3> A recurring pattern that I have noticed: 1) a company the size of Amazon, Facebook, or Google runs into a problem that comes from their gigantic scale, or the fact that they're trying to do something very different (e.g. Google Maps compared to old-style web pages) 2) Big Company comes up with a new technology to solve their problem 3) Many, many small companies that will never become big enough to need this, and are doing far less exotic things that require it, will try to make their ordinary web page into a microservice single page app with a NoSQL backend, because that's what successful companies do.

Imitating success often makes sense; after all, we don't want to imitate failure. But your company is almost certainly not facing issues at all like Amazon, Facebook, or Google, and also does not have nearly as many programmers to do it.

<comment><USER4> I call this: Headline Driven Development

Another good example are monorepos. A decision maker sees a headline about Google and Facebook using monorepos and mandates his company to switch. Unfortunately, he or she didn't read or didn't understand the actual article that explains that it only works because of strict code reviews and extensive integration tests.

<comment><USER5> We call it Hype Driven Development which is just as bad as Marketing Driven Development... and yes, monorepos, don't even mention it, good heavens.

Another hype that keeps coming back is the magic of trunk based development (with a random po reading some flashy article about feature switches as the wonderous solution for a-b testing AND faster development).

Nowdays I even consider putting react and angular into this pack, since, you know, "if it's good enough for facebook/google then it must be really good" \- anyone ever tried to increase performance for a react site (and realizing that precompiling templates was not exactly a bad idea years ago) or hitting the wall with inline async helpers and rx magic might know my voes. But then again, give me a fast and reliable server rendered site over an unsteable trainwreck spa anytime and I will be happy.

<comment><USER6> >anyone ever tried to increase performance for a react site (and realizing that precompiling templates was not exactly a bad idea years ago)

I'm not sure I'm parsing this sentence correctly. Are you saying that precompiling templates and rehydrating them doesn't cut it anymore? If so, why not? I haven't used React much, but I've done some work in a framework with similar principles and I felt like proper precompiling, with basic HTML fallbacks cooked in where possible, provided all the performance of server rendered sites with the added bells and whistles of SPAs (including that most subsequent requests can load quicker than a full rerender, provided JS is present).

<comment><USER5> Afaik the render part is purely dynamic and the advocated style of creating closures with fat arrows to avoid scope binding (which is essentially the same if done in the render section) is quite expensive in terms of performance.

React and fiber tries to be smart about rendering with tree section diffing, but unless you use immutable, it's "not enough" to rely on - without immutable even in a smaller redux app there is a good chance that you have unintentional rerenderings triggered, which while may not create new tree branch renderings, still need to be evaluated.

This of course applies to the client, I don't have experience with nextjs or similar tools.

<comment><USER7> The issue with closures is easily solved, just declare it as class property (or a const variable outside the component if you're using SFC) and then use it instead of declaring it inside your render JSX. Any React-aware linter would not let you declare closures in JSX.

<comment><USER5> Can you recommend a tsx-friendly linter and its setting? The sites I worked with never followed this rule and whenever I tried to bring it up, it was too late to refactor things (at least from a roadmap/burndown po/sm perspective)

<comment><USER7> I use tslint and tslint-react, the rule is named "jsx-no-lambda"

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER8> Understatement of the month. Last I heard, the HN consensus was that it's better to delay microservices (personally I'd say wait until profitable or >100 engineers).

Even Twitter, probably the most successful performant microservice-at-scale company advocates waiting as long as absolutely possible to make microservices. They said "It fixes one problem, and makes every other piece of application development significantly harder."

<comment><USER9> The need for microservices has little to do with company size, they have to be the right tool for the job. People mistakenly use them for scalability, or to partition work between teams.

I'm in a small engineering org, and I split out a bunch of security critical code from an unsecure monolith and moved that into a microservice, running in a very tightly controlled and audited environment. A tiny part of my runtime needed different security from the rest of it, and a microservice was the easiest way to accomplish it. Now, I've traded a security problem for a latency problem, as everything that used to be handled internally is now an RPC - though this is an easy problem to solve.

<comment><USER10> Scalability is what microservices give you, at the expense of nearly everything else.

<comment><USER11> Independant deployment

Multiple languages

A/B testing at deployment fir small services

Less dependency to software specific stack

Security compartmentalizations

Strict programming by interface

Failure isolation

<comment><USER12> Independent deployment: Rarely needed. Multiple languages: No shared infrastructure. A/B testing at deployment for small services: Feature flags. Less dependency to software specific stack: More dependency to homegrown immature solutions. Security compartmentalizations: Isolated half-assed solutions with few people responsible. Strict programming by interface: Not unique to microservices, some people call this "static typing". Failure isolation: No shared infrastructure, blindsides, definitely not unique to microservices.

<comment><USER11> Independent deployment: having deployed hundreds of microservices, I can tell you it is a godsend. Quickly iterating on a specific microservice without running risk of down-time is useful right from the start. We would sometimes deploy the same microservice multiple times a day to improve performance or fix a critical bug. Apart from scaling, this is my number one reason to stay with microservices.

Multiple languages: the shared infra in this case is your Kubernetes yaml files and Docker build files, both of which can be shared easily. The rest is either RESTful or Kafka consume/produce. Python/R/Scala/Java/C#/Haskell/OCaml can all interface with that.

Feature flags are a possible solution. I worked with them in the past and, applied correctly, they can offer a similar experience. However, one often needs more than just a boolean filter: you need to have the logic in your application to route the requests to, say, two different implementations of the same interface. Do this on the micro-service scale, and you get a nice SoC at the proxy level. It moves A/B testing to be part of the infra, not the application logic.

More dependency to homegrown immature solutions: care to elaborate?

Isolated half-assed solutions with few people responsible: care to elaborate? My little micro-service component needs the bare minimum of access, which I can precisely provide to it. No memory is shared, no storage is shared... Often it is much easier to prove that the system stays within confidentiality and availability limits. Networking allows me to transparently monitor all data flowing through my services.

Strict programming by interface vs. static typing. Oh yes, I totally agree with static typing! Such a big advantage over dynamic typing, read my other comments on HN. However, there is no static typing across versions of your same software. Forward compatibility is hard to achieve when all components need to be upgraded at the same time. I still dread the days when we would upgrade 'a major version' and all kinds of database tables had to be changed, causing chicken-and-eggs problems. Not saying that this problem is completely eliminated with a micro-service architecture, but it forces developers to think what can be reasonable isolated, causing a higher SoC. It also prevents the humongous unmaintainable 300+ tables large RDBMSs, which are often the primary cause of stagnated development.

Failure isolation: I don't understand your reasoning, sorry.

</comment></comment></comment></comment></comment></comment><comment><USER13> Microservices move tranasactional concerns out of the database and between service boundaries. If you ever need to transactionally write data to two different microservices, you need to roll your own rollbacks. And unless you store this rollback state in a reliable datastore, there's no going back. The tooling to do this properly, as far as my research goes, does not currently exist.

I much prefer horizontally scaling a big old monolith backed by a sharding database like CockroachDb or Cassandra. Same scalability and you get to keep some ACID semantics.

Concerns about code size are overblown. Facebook's mobile app is utterly massive and it still runs mostly okay even on weak devices. The maximum practical code size for a monolithic server side app will probably never be reached. We're talking maybe 100 million LoC before you run into real problems, especially if you use a VM lanuage like Java or C# where hot and cold code can be dynamically swapped out and code is stored in a very space- efficient fashion

When you reach the scale where the codebase size is an issue you've probably already several rewrites to deal with such massive traffic volume.

<comment><USER14> And let's face it - you are never going to get your own rollback logic right. There will be simply too many edge cases to worry and test.

<comment><USER13> Yes. That's why I'm amazed there isn't some Zookeeper ish system out there for supporting microservices.

The fact is that microservice tooling is in it's infancy, and shouldn't be used in production unless you're willing to roll your own everything. I worked at a place that tried to use microservices+event sourcing+CQRS, predictably a massive disaster.

I still think the monolith+distributed database will win out . I've never heard of a time when horizontal scaling was a problem not related to the databse

</comment></comment></comment><comment><USER15> I often read about (Silicon Valley) companies saying things like "we have a thousand microservices" or "we have hundreds of microservices" and I really can't wrap my head around what all of these services do. As someone who has primarily worked on monoliths, service-oriented architecture seems like an intelligent idea to me, particularly with regard to scaleability. However, I can't see getting so fine-grained that you have that many services, especially considering that from what I've read each microservice should be backed by it's own datastore. Perhaps its just my own lack of first-hand experience showing, but it seems like it would eventually devolve into a confusing, fragmented, and non-performant mess.

<comment><USER16> What you need to keep in mind is that micro services have a huge fixed cost but the marginal cost of adding a new one is small.

In other words: Creating or migrating to a micro service architecture is very expensive but once it's in place, adding a new micro service is trivial. In Zalando the goal is that you can do so within half an hour, that is take an idea, implement it and deploy it to production.

This leads to architectural decisions no sane person would make at a smaller company. For example let's say you get data from an external company via SFTP and you make it internally available, so what do you do?

1\. You create a micro service that polls the SFTP of the supplier for new files and sticks them into an S3 bucket 2\. You create a micro service that takes the files from S3, parses, transforms into JSON and publishes events to Kafka. 3\. You create a micro service that takes those events enriches them with some other data and republishes new events. ...

Especially when you use Kubernetes, you also start thinking about infrastructure completely differently. Why use multiple threads or processes for example, when you can just run multiple instances of your application very cheaply and temporarily run further instances to handle background tasks?

<comment><USER17> And after 1 year running like this you have 50 micro-services by engineer. All of them undocumented, poorly named with unclear responsibilities using the bus to communicate with god knows who... I might be old fashioned by I would take a monolith over this over-engineered mess any day of the week.

<comment><USER16> In Zalando, every PR made must be reviewed by at least one other engineer. Every application must be registered which involves giving it name, a description and associates it with the team owning the service. APIs that cross team boundaries must further be reviewed by an API guild, a group of people that are experts in API design, this also applies to events.

Events go through Nakadi, which enforces a schema and authorization. You can further tell which services are subscribing to such events and through the before mentioned application registry who is responsible for them.

Additionally compliance with various laws and shareholder expectations requires regular reviews, to identify and fix issues such as missing documentation, monitoring, SLOs, data storage restoration tests (in production), load tests etc.

The scenario you describe is not possible or allowed. As awareness and adherence to these rules is also part of performance reviews, it's also not in any engineers in interest to do that.

You're right of course that one needs to be aware of that.

</comment></comment></comment></comment><comment><USER18> Er, but the description of a "well-architected monolith" here is a set of loosely coupled components (with specific criteria for where you at component boundaries) communicating over an external set of message queues, which, while it doesn't have all the features which define a microservice architecture, is itself a widely documented, well-known, older (heavily documented in the 1990s, possibly older) alternative to monoliths. I suppose this is being called a monolith because everything _except the message bus_ is implicitly jammed into a single process rather than each module being in its own process. But, even aside from the modularization being different from a monolith, bringing messaging out of process makes a huge difference compared to even a modularized single-process solution.

<comment><USER19> I'd argue you don't need an external message queue. You can use inprocess ones or an Actor based system.

<comment><USER20> I'd argue the message queue is, itself, likely not needed. Not directly.

I think, ideally, for a system to be successful, you need to understand all places that you either build up messages, threads, buffers, whatever. It ultimately doesn't matter which you do. Just don't do too many. And don't make migrating a solution from one type to another part of your critical path to launch. Logging, in particular, is something I've grown tired of people reinventing before they have even launched.

</comment></comment></comment><comment><USER21> Can anyone recommend good examples of monoliths in open source? Preferably in Go?

I inherited a bunch of micro services at my current job with a fairly small team. My feelings have been that the code had been prematurely micro-serviced considering the team is so small and every service was mainly just CRUD in front of then same Postgres instance.

I've slowly been demonstrating the benefit of modularlized "sub-apps" in a single monolith over lots of microservices that all reinvent the wheel. And I think I've convinced them that this is easier going forward. But I'm at a loss sometimes about what boundaries I should be putting in place such that we don't end up with a ball of mud in two years.

<comment><USER22> Kubernetes is a pretty large open-source Go project: [https://github.com/kubernetes/kubernetes](https://github.com/kubernetes/kubernetes)

Docker is, too: [https://github.com/docker/docker- ce](https://github.com/docker/docker-ce)

<comment><USER23> Is Kubernetes really a monolith ?

It isn't one codebase and when deployed there are multiple daemons running.

<comment><USER24> People confuse monolith and monorepo all the time. If you have a monolith where each independent module communicate via queue, like described in the article, you are so close to having a monorepo of horizontally scalable micro- services.

</comment></comment></comment></comment><comment><USER25> It's fashionable just now to hate monoliths, so much so that developers would probably be afraid to suggest anything other than creating a suite of microservices for fear of sounding backward or inexperienced. It's a bit like if anyone ever dared to suggest that they don't adopt Agile. You'd probably be chased out the room by an angry mob.

<comment><USER26> It's fashionable right now to like monoliths. It's "thought leaders" trying to one-up other "thought leaders," contradicting for sport. And who cares anyway? Software fashion is cargo cult nonsense pushed by people who probably struggle to ship anything that's robust or reusable. They're obsessed with keeping up with "thought leaders" on Twitter and Medium. They fly to speak at conferences and make a big name for themselves while the rest of us are busy grinding and limiting the damage they can do.

<comment><USER27> It may be fashionable to like monoliths on HN, but microservices is still the hotness if I judge by the recruiting emails I get.

<comment><USER26> Exactly, microservices are mainstream and boring now. Designing around services? You must be a pointy-haired boss!

</comment></comment></comment></comment><comment><USER28> So... keep modules separate, use queues and databases to communicate between modules, make sure the queues and databases are a separate process from the monolith.

This sounds a bit less like a monolith and a bit more like a bunch of microservices that you've welded together in one container. Which is great! If you're disciplined about maintaining that, it will be very easy to spin off these individual modules as their own microservices when the time comes.

But I'm not sure that this constitutes an argument for monoliths > microservices.

<comment><USER3> What is presented here as a monolith is, however, what the word "monolith" means in current design conversations that I hear in workplaces. Also, I don't think the article was trying to advocate monoliths > microservices, but rather more like "it's ok to use a monolith if that works, and at first it probably will". Because true microservices introduces a lot of infrastructure work at the very beginning, when you desperately need to be working on code for your basic product.

</comment></comment><comment><USER29> What's a monolith anyway? At this point just a straw man to pitch microservices against. There are many ways to modularize code; after all, (class-based) OOP is about code organization via modularizarion. In my experience, "REST microservices" is one of the worst, as it derives its working principles from the unrelated problem of loose coupling of web browser and web servers just because it has to use HTTP for unclear reasons, then applies these principles incorrectly, naively, religiously, and dogmatically, while mimicking a two-tier application model that isn't called for. It's really the mother of all antipatterns.

<comment><USER30> @honest_update: _We replaced our monolith with micro services so that every outage could be more like a murder mystery._

</comment></comment><comment><USER31> Worked for a place recently (and briefly) that claimed to be building a platform on micro services. When I got there I found that while they indeed had a bunch of independent processes hanging around they all relied on a single data source. All introducing micro services accomplished was a LOT more network overhead between processes and the main (SQL) data store. When you have a bunch of processes talking to the same data store, you still have a monolith whether you want to call it that or not, because you lack the freedom to refactor your schema without changing every service that relies on the store.

<comment><USER32> Ah yes, the distributed monolith antipattern.

</comment></comment><comment><USER33> I agree entirely. Microservices have advantages but they also bring along severe complexity. Many problems can be cleanly modeled as a monolith - <USER2> they should be. No architecture pattern is immune to abuse.

<comment><USER34> > Microservices have advantages but they also bring along severe complexity.

Worse, often the complexity they bring is undocumented because it lies in the relationships between applications, accounts, infrastructure, and so on, and does not lie within the boundary of a single application. Microservices are simpler to write because you can pretend a lot of the ecosystem does not exist.

<comment><USER35> On top of that, microservices often suffer from inadequate tooling. Companies like Amazon have been working on tooling for their services for literal decades, most companies have some half-assed attempts at tooling and don't understand why that's a problem. Consider deployment, for example, how do you know what's deployed at any given time? Well, the answer is usually something along the lines of "oh, that's just the head revision of all of the relevant repos/branches". And what about the staging and dev environments? And what about logging and history? How much work is it to figure out what code was running when certain bugs were filed?

<comment><USER36> That sounds like a monitoring problem and nothing to do with microservices vs. monoliths. If you have 10000 replicas of your monolith, how do you know what version they are running? If you can answer that question then you can also answer it for 100 replicas of 100 difference services.

</comment></comment></comment></comment><comment><USER37> I run into the microservices obsession very often in the high-growth startups I advise, so often that I wrote Enough With The Microservices ([https://adamdrake.com/enough-with-the- microservices.html](https://adamdrake.com/enough-with-the- microservices.html)).

I typically see people try to push microservices as a "best practice" for improving the delivery rate of software teams. They carve the codebase into separate services, but still leave all of the persistence in place so that all services are communicating with the same DB(s). The result is a tangled web of interdependent services, plus additional tooling like Docker, Kubernetes, etc. that actually makes the teams even slower than they were before.

I'm glad to see us as a community getting more pragmatic about these topics, and realizing that _best practices_ are highly context dependent!

</comment><comment><USER38> My angle on building products: Monolith to market.

Break it up and optimise where the sticking points are as customer base and feature set matures.

<comment><USER39> It's not that simple, and that's the problem with microservices. You'll learn that "break it up" means a huge investment in devops, logging, stats dashboards to understand what the problems are, etc. It's like transitioning dimensions from 2D to 3D, and that's the trap that most people fall into.

You cannot survive microservices without real-time dashboards and proper logging to understand the health of your environment, whereas with a monolith, it was fairly obvious because there's the server and usually a database, and that's it.

<comment><USER17> All true about monitoring and logging. Is is a huge cost and overhead. Consider it the other way around: micro-service to monolith. It seems to me it is as difficult, if not more difficult. Potentially different language or different build system are used. Different framework might be in place. Sometimes a merge is completely infeasible without a total rewrite. So going from micro-service to monolith is like going from 3D to VR. Splitting seems in a way way easier than merging back.

</comment></comment></comment><comment><USER40> I agree with this. However, for whatever reason, suggesting a monolith or (gasp!) not writing a spa for an app and using traditional ssr html seems to signal that you're antiquated and old fashioned. I've only been doing this for 3 years and it's ridiculous.

<comment><USER41> Yes this is the problem I am am facing just now (been doing this for 15 years). I care more about writing decent code than chasing trends, but it means my skillset looks stagnant.

</comment></comment><comment><USER42> This still looks like a micro service architecture to me, or very close. A monolith solution would probably be everything in a single process (1 tier). Queues decouple services, whether the code base includes the consumer & producer together or are separate doesn't matter, they are still deployed separately.

It's definitely not black/white, but a spectrum.

<comment><USER43> So, in micro-service architecture services don't have to be particularly small. They also don't need to actually be services. Do words not have meaning any more?

</comment></comment><comment><USER44> Microservices pundits have strategically (or accidentally) engineered the hate for non-microservice design. They chose the term "monolith" to disparage anything that wasn't SOA. "Monolith" has a natural negative connotation so right there, you're winning at the "tech pissing fest" at the bar after work.

The fact is that "monolith" applications can scale, and they can be deployed as a unit and they can still adjust to varying load using modern cloud infrastructure.

The enemy to scale, productivity and success isn't "monoliths". It's complexity! And an experienced and pragmatic developer will tell you that they fight daily to avoid complexity at every turn. Yes, sometimes it's necessary, but they weigh the pros and cons on a case-by-case basis to ensure that the gradient to complexity is always as low as possible.

<comment><USER11> And, how is complexity caused? What are the origins?

It is caused by bringing together unrelated things.

It is caused by violating the single responsibility principle.

So, we isolate state from communication. We separate interface from implementation. We see as many, where others see one. We try to see the network of dependencies, where others see a single line of code.

Using this new perception, we find that the large application entangles the change of (code) state of one part with every other through its deployment. The static typing guarantees only validate one specific instant in time, but nothing about the future or the past.

So, take a step back and see the deployment of code as a functional part of the code. Now the monolith forms complexity and the microservice isolates it to the minimal surface.

Take it one step further, and we see that the actor model is the exponent of this idea. Late binding, late dependency tracking, programming by behavioural contract.

<comment><USER45> >And, how is complexity caused? What are the origins? >It is caused by bringing together unrelated things.

It is also caused by wrongly separating things that are closely related and putting a network or something similar in between.

You cannot reduce software development to a formula.

<comment><USER11> No, so saying outright that microservices are better or worse is just that: a formula.

<comment><USER45> No, its a categorical consideration made without the needed context. Basically an opinion.

</comment></comment></comment></comment></comment><comment><USER46> I think we're just bad at predicting the future. You can go go fast and sling code at the wall because the odds of ever reaching FAANG scale is low and you want to be pragmatic, and then one day you accidentally do hit FAANG scale and you're in the news every week for security breaches and outages. You can also do everything DRY and micro-serviced from the beginning, run out of runway and crash. Or you could get to FAANG scale and realize you need to rewrite everything because you didn't foresee X, Y, Z requirements and technology has shifted 20 yards to the left. My approach is the gardener mindset. Think about organic growth up front when writing the code, but also be pragmatic and start with a "minilith" with interfaces in the right places.

<comment><USER47> if you keep yourself aware from day one about the issues in your codebase/service and what doesn't scale it is not that hard to switch from monolith to microserviced is the point of this article i think. there's a difference between a conscious decision to ship a monolith and code quick "ship it now" monolith most companies won't reach FAANG,they'll be lucky to even reach preferred local service

</comment></comment><comment><USER48> "Monolith" literately translates to "Einstein" in German, which can't be that bad. Or can it? ;-)

</comment><comment><USER49> I think there's something that people mostly forget. Most of the times we are compairing microservices with monoliths but forget that almost all monoliths are much older than whatever microservice someone have recently built. Also whoever built those mostly have the luxury of not making the inevitable mistakes you did when you built the monolith. So saying that microservice is better than a crappy monolith is kind of not true. You can argue all you want about whatever style but anything well build is still good. And it's easy to fuck things up in both scenarios.

</comment><comment><USER50> Undoing microservices at my current job has been nothing but positive.

</comment><comment><USER51> Both my current employer and last have fallen into this trap. Trying to do microservices with a small team and moderate to low complexity. Both built distributed monoliths with a shared core and were spending lots of money keeping it from falling over. They incur all the costs of microservices with none of the benefits.

Microservices are a siren song for many small/medium sized companies. What they need is clean separation between subdomains (composing domain level API functionality together in the user level APIs to implement business logic) and clean separation between domain and infrastructure code. There are a lot less complex ways to achieve this without microservices.

</comment><comment><USER52> Of course they are OK. It doesn't matter it is microserivce or monolith, what matters is how well your architecture executes the principle of separation of concerns. That is largely irrelevant of what philosophy you are choosing.

</comment><comment><USER53> I don't get it. The article argues that a "good monolith" is composed of a code base + RabbitMQ deployed in Docker. The code base probably needs a database too, let's say MySQL. You probably also need to serve static assets (JS and friends), so an nginx container might be handy.

Isn't this already an application composed of four micro-services: three micro-services are 3rd-party, while one is developed in-house?

</comment><comment><USER54> For anyone trying to put together a well architected 'monolith' using C#, I can recommend [https://github.com/realvizu/NsDepCop](https://github.com/realvizu/NsDepCop), which allows you to set up far more granular and useful dependency rules within your code than standard project references.

</comment><comment><USER23> The famous J2EE + ESB style pattern.

Many of us have worked on dozens of these before and sure they work but microservices were invented specifically to address the serious concerns with these patterns.

1) It's far too easy to create spaghetti code that spreads across multiple modules. And because they are so intertwined teams are very reluctant to do major refactors. Especially when the original authors eventually leave.

2) It's less flexible at scaling. In a monolith you have to horizontally scale the entire application behind some load balancer. So if you have an Email concern that needs to handle 100x more load what do you do ?

3) API contracts are far easier and safer to evolve than ESB ones. There are also clean mechanisms in APIs for handling versioning, capability discovery e.g. HATEOS, documentation e.g. Swagger, rate limiting, caching, analytics, billing, authentication etc.

4) Microservices are much easier to reason about, test, document, teach new starters about and most importantly replace. If I replace a microservice I just need to verify that the API contract is the same. In a monolith I need to basically retest everything since there is no guaranteed isolation.

I could keep going on. But not sure this blog post offers anything particularly insightful in how to deal with the negatives of a monolith architecture.

<comment><USER55> It seems that apart from scaling your concerns boil down to enforcing discipline? Perhaps there are methods of enforcing discipline that don't involve serializomg and deserializing a bunch of data several times per request.

<comment><USER56> > serializomg

I realize this was a typo but first thought it was an awesomely-named serialization library :)

<comment><USER57> I read it as an opinion on the cost of serializing

<comment><USER55> It wasn't. It is _now_ though.

</comment></comment></comment></comment></comment><comment><USER58> > a complicated microservice architecture

> Microservices are complicated to develop

> Microservices dependencies are difficult

Well, if you say so! Kind of hard to take this article seriously when the argument boils down to a tautology.

Microservices _may_ be hard! This article contributes nothing to that conversation, though.

</comment><comment><USER59> We need to define - what is a monolith before concluding - Well architected monoliths are okay.

</comment><comment><USER60> This is quite funny. People are basically saying 'think about your problem, do not follow the hype' and that feels like a revelation. Says something about state of the industry, doesn't it?

</comment><comment><USER61> It is also difficult to keep a monolith as "well architected" in reality. No matter what, we should start from a "well architected" monolith first as the last part of the article says.

</comment><comment><USER62> Didn't he say he runs the async queue consumer in another process? Doesn't it make it practically another "micro service"?

</comment><comment><USER63> This sounds like a great way to get most of the problems of monoliths and most of the problems of microservices at the same time.

</comment><comment><USER64> A reminder that the space of architectural possibilities is not merely a binary domain of {microservice, monolith}.

</comment><comment><USER65> What "well-architected" system is _not_ okay?

</comment><comment><USER66> And arbitrary micro service boundaries are a disaster.

</comment><comment><USER67> > they let development teams focus on delivering features

I agree, but later on, when the team and the codebase grows, you'll need to split it into smaller parts, and microservices (or any other similar architecture) gives you some guidance that can be shared across the team/s making architecture decisions more consistent and providing a common framework that improve reusability, but it's not an easy path!

</comment><comment><USER68> If you try to differentiate monolith acceptability based on "quality of architecture", you really have never understood why they are hated in the first place.

<comment><USER33> No architectual pattern can survive a lack of maintenance and grooming. Sprawling microservices written in a dozen different languages can be worse then a mangled monolith.

<comment><USER69> I always say if you can't design a monolith then don't bother with microservices. You shouldn't use microservices to cover up for a lack of design skills or a lack of communication between teams.

<comment><USER5> Every man is an island in the world of microservices.

Look, my microservice is clean and nice and has a 100% test coverage, I couldn't care less if you can't communicate with it from yours. Solve it somehow.

Now get off my lawn and let me rewrite the whole thing in scala.</comment></comment></comment></comment>


Logo Pizza: Hot and ready logos for sale - <AUTHOR> http://logo.pizza/ <comment><USER2> Fun site, the magic is this one line:

" Need a custom logo? Let's chat! firstname.lastname@example.com "

The chance of you needing one of the pre-existing logos is small, the chance of needing a logo period is higher, and seeing the portfolio of logos gives you a starting point to imagine things.

The only negative is that it might anchor you emotionally to a lower than average price if the current logo price is small enough.

The web site concept though seems to be exactly like a clothing store putting last years clothes out on the side walk for "cheap" and just getting people walking by to think about it and come in and browse. Which solves Internet company problem #1, "Nobody knows I exist."

<comment><USER3> It sorta reminds me of this one:

[http://www.horriblelogos.com/](http://www.horriblelogos.com/)

<comment><USER4> Well they're much better than the generic/overused logos[1] from my previous favourite logo-related HN discussion[2].

Hilariously (for me) after I sent that link to my sister, she revealed the recent purchase of an alleged custom-creation - a 'rainbow link of people' style logo that was almost a replica of one from that generic set.

Evidently logos are hard, but once you get past the biggest decision (should you bother to try to have one that reflects what you actually do / sell) finding a cheap one becomes much easier.

[1] [http://www.gtgraphics.org/genericlogos.html](http://www.gtgraphics.org/genericlogos.html)

[2] [https://news.ycombinator.com/item?id=8071383](https://news.ycombinator.com/item?id=8071383)

</comment></comment></comment><comment><USER5> Wouldn't it make more sense that the price would go down as more are purchased, as the most popular logos are already taken? Is someone really going to pay $1000 for 'Mr. Grin'

<comment><USER6> After spending much time among entrepreneurs I find that there are very few with a "business" mind. Great idea, horrible model. This pricing model is so far out of left field that I had to do some research to see if it's ever been successful.

It hasn't.

Although [https://github.com/metafizzy](https://github.com/metafizzy) is kinda interesting (what this websites UI is based off of)

<comment><USER7> > I had to do some research to see if it's ever been successful. It hasn't.

You failed at your research. In art, this is quite common. As an artist gains notoriety, their work goes up in price. How much do you think Picasso sold his early works for? How much do you think Picasso paintings are worth now?

Also, Minecraft started out cheap and got more expensive over time.

<comment><USER8> That's completely different. You're talking about a single piece of art gaining value over time as it's bought and sold. What's happening here is the price of _all_ remaining logos increases as sales on _any other logo_ happen.

<comment><USER9> No, artist will commonly price a collection this way to show there's a market and get buyers to act sooner that later. It's assumed that not all of the logos will sell, and some if not all may have been versions of another logo.

</comment></comment></comment></comment></comment><comment><USER10> Price goes up $40 per logo sold? So, after you sell 10 more logos, it'll be ($40*10) + $120(current price) = $520 per logo?

Seems like a strange pricing strategy. I guess it increases the "buy it now" urge, but at some point it will kill sales. I guess when it stabilizes you can just say "ok, that's what people are willing to pay for these". So perhaps it's a good way to explore pricing...

<comment><USER11> Let's say he sells the first for $40, the second for $80 etc…

The total he's trying to net is $40 * 50 (50 + 1) / 2 = $51.000

Not bad!

<comment><USER8> Except nobody's going to pay nearly $1,000 for the leftovers, so there is essentially a ceiling on the number of sales that will happen. Let's say the last logo sells for $400 (it's currently stopped at $320, so I don't think that's unreasonable); that's only $2,200 in total revenue for 50 logos.

<comment><USER12> It was at $360 when I found it, and they've sold two in the last 10 minutes. Up to $420 now.

<comment><USER13> Two hours later, now at $500, increasing by $20 per logo now.

<comment><USER14> $500 appears to be the ceiling.

</comment></comment></comment></comment></comment></comment><comment><USER15> We always have had a surplus of logos. When we design for a company, perhaps 3 to 5 decent ideas are sketched. Of course only one makes the final cut per client. We own any preliminary work, so we can offer these for use later. We would just change the name, revise slightly and change the color. Bam...new logo.

What we did finally was revise the ones we like (25 to 50 initially) and include them for free as part of a new web design project. A lot of clients have bad logos that can ruin a design. So it helps our designs and clients brands.

Clients could also purchase at a low flat rate if they liked one without a website. This has worked well too.

</comment><comment><USER16> Did anyone else expect this to be pizzas sold at a discount offset by having a company's logo burnt into the cheese?

<comment><USER17> Great idea. I'm stealing it. :D

<comment><USER16> Half-price pizzas? Take my money!

That reminds me of Flag: free printed photo (free shipping too) just with a sponsor's logo printed on the backside.

[https://itunes.apple.com/us/app/flag-worlds-best-photo- print...](https://itunes.apple.com/us/app/flag-worlds-best-photo- prints./id1079826301?mt=8)

</comment></comment></comment><comment><USER18> The pricing model could be the logical conclusion to some basic behavioural economics insights. Feeling of a loss >> feeling of a win. Thus you create an ever present feeling of that potential loss (missing out on the lower price) which forces potential buyers to act to lessen that feeling of possible pain as opposed to the standard approach of selling based on the feeling of a win (my nice and shiny logo). This idea could probably also be leveraged to combat procrastination somehow. It also has that novelty factor of the pay per pixel advertising from back in the day. Neat :)

I guess the only problem is that the last logo shouldn't sell easily (without adding more).

</comment><comment><USER19> I absolutely love this experiment with the incremental pricing, which creates a sense of urgency. Lovely artwork as well.

</comment><comment><USER20> This is a great idea! I'd actually sign up for a mailing list to get notified when new logos are added.

I'm aware of products like fiverr and 99Designs, but I'm worried about sinking a bunch of money into them only to get crap back. I like being able to view the logos and simply browse without any commitment.

<comment><USER21> Wow. I've used Fiverr twice. I used the same guy to do a mobile app icon and a logo for a different business. He did amazing both times. Total out of pocket expense was $11 each. I got exactly what I wanted and it really really really looked amazing. I got the psd too. Best 20 bucks I ever spent.

<comment><USER22> I tested out Fiverr by hiring 3 people to do simple T-shirt designs for $10-$15 each. Everything I got back was either stolen from somewhere else, extremely poor quality, or didn't fit my request at all.

I'm sure there are great people on Fiverr, but you have to do a lot of searching or get really lucky.

Upwork costs more, but I think the increase in quality and communication ability more than offsets the price.

<comment><USER23> Even with just 3 people at $10-15 each, you could sink more money into Fiverr and come out with a better logo than the predominately flat-UI only designs provided. However, Logo Pizza still has some (IMHO) great ones for sale

Just wondering - how were you able to tell the idea was stolen from somewhere else? Simple reverse-image searching, or did you have a better procedure?

<comment><USER20> That's not a great strategy to just continue to pump $15 into fiverr hoping to eventually get something good. Does that happen when you get to $500 or $5000. You don't know when you start so you could just waste your money.

<comment><USER23> I fully agree the strategy is unreliable.

But, for rapid development of prototype, or early stage products, I could see a few $15 injections going a much farther way than abandoning a project and having dropped $299 _or even more_ into a 99Designs (or 'higher-end') logo[0].

I would always double back and get a more professional looking design that is also coherent with the Web App look & feel or product page look & feel.

[0] [https://news.ycombinator.com/item?id=12488500](https://news.ycombinator.com/item?id=12488500)

</comment></comment></comment></comment></comment></comment><comment><USER24> With the per-logo price increasing by $40 every time a logo is sold, the final logo will cost $2000. But I wonder if it'll get that far. At that point, can't you find a decent graphic designer and get a logo exactly to your liking?

Quick edit: this is not a rethorical question, I honestly would like to know!

<comment><USER25> If you find something that fits well for your company, $2,000 can easily be worth it.

Working with a designer to create a logo for you can be time intensive. There can be a lot of back and forth with the designer as you refine the logo to something you like. Avoiding that time can surly be worth it for many companies with the right budget.

You can create a logo and pay a designer less than $2k but how much of your own time are you going to spend making that happen?

</comment></comment><comment><USER26> Maybe the owner doesn't know what the logos should sell for, runs this once, and then sets up a new site selling the logos for at or near the ceiling price from the unorthodox auction.

</comment><comment><USER27> Some of these look eerily familiar, and I wonder if they might infringe upon a Trade Mark...

<comment><USER28> For example:

Pizza's Horse Mane — [http://logo.pizza/horse-mane](http://logo.pizza/horse- mane)

eSports organization Team Liquid — [http://www.teamliquid.net](http://www.teamliquid.net)

<comment><USER29> As long as no one uses that logo to start something associated with gaming it's likely different enough to not cause issue. It's a somewhat common style for horse iconography.

</comment></comment></comment><comment><USER30> What is stopping someone from just taking the logo?

[http://logo.pizza/img/happy-cat/happy-cat.png](http://logo.pizza/img/happy- cat/happy-cat.png)

<comment><USER31> What's to stop you stealing anything?

<comment><USER30> Cops, usually

<comment><USER32> this wouldn't be your normal case of pirating a tv show. You use one of these logos and end up becoming a large successful company you will be paying when you get sued.

</comment></comment></comment></comment><comment><USER33> I like the idea of a website listing a lot of logos, me scrolling through them and picking something I need.

But I wish new logos would be added continously, priced separately, and definitely price increase on something that did not sold in the past is ridiculous. :D

</comment><comment><USER34> Using a .pizza domain and using "Hot & Ready" in the tagline might make the casual consumer think these are logos made out of pizza, or are on pizza with cheese in the shape of a logo, or would have to do with pizza in general.

</comment><comment><USER35> First reading the title I thought people were making pizzas with logos on them. Which would be a much more bizarre business.

</comment><comment><USER36> Some of those logos look familiar to me. Who says they don't infringe upon existing logos?

</comment><comment><USER37> Whoever buys the "A-Ok" logo is going to have a very rough internationalization experience if they try to bring their product to Brazil...

<comment><USER38> Could you elaborate? Not sure what you mean.

<comment><USER39> it's an obscene gesture, like the middle finger.

<comment><USER38> Haha, learn something new everyday.

</comment></comment></comment></comment><comment><USER40> Most of those logos remind me of 90's clipart programs on Windows.

<comment><USER23> They're flat design!

They are currently "trendy" in the front-end world, but for how much longer, I've been too far removed from front-end development to know. Here's an interesting read in the shift (semi-recently, mind you, _2013_ ) [0]

[0] [http://www.ucreative.com/articles/design-wars-flat-design- vs...](http://www.ucreative.com/articles/design-wars-flat-design-vs-realism/)

</comment></comment><comment><USER41> This makes it look like getting a logo is easy and quick. And it can be, probably.

It's not my area of expertise, but I would expect there are some pitfalls just like with company names, app branding and other branding/trademark stuff.

I would not want my logo to be too similar to somebody else, and researching that is probably tricky.

<comment><USER42> The person that made this site would probably be sued if he/she sold a logo to a company that's too similar to existing work, arguably not before the company itself gets sued. Hence, for new companies it's a gamble as the legal fees could put them out of business.

Maybe there is a disclaimer somewhere on the site, but I haven't found it.

Regardless, finding out whether or not a logo that you produced (or a design studio produced) is too similar to already existing work is difficult as images cannot be as easily searched as plain-text. This is hard for design studios too.

Also, and this is speaking as a layman, but initiating such a legal affair probably requires a trademark.

</comment></comment><comment><USER28> I wish there was a price on sold logos, so I can see what those were worth to someone.

</comment><comment><USER43> I wonder how many of the sales here are from this being on HN. It's a classic time-scarcity sales ploy, like the one-day sale websites. Don't fall for it.

<comment><USER44> Plus... I wonder how many of the sales are real :-)

Scarcity and social proof in one hit, awesome. But who knows what really got sold?

</comment></comment><comment><USER45> I think it might be useful to cycle in new sold/unsold sets of logos to give the effect that sales are taking place and business is moving ahead. otherwise, it looks like no business is being done. also, maybe instead of "sold" something like "to be sold" might work to give the impression that it isn't off limits yet.

</comment><comment><USER46> As of 8:20EST he has sold 17 logos for a total of $5560. Calculated at $40 a logo until $400 per logo, then $20 a logo.

</comment><comment><USER47> As of 1.24 PST he has sold 27 logos for a total of 7560 if each logo costs 20 dollars more.

</comment><comment><USER48> This is great! It's an interesting idea, a fun concept that isn't too serious, and in my opinion the work is really fantastic. Next time I need a logo I'm hitting up this guy/gal (I don't know what a metafizzy is).

</comment><comment><USER49> Not sure how this works against something like 99 designs which can get you a custom logo for $300-1200 bucks.

[https://99designs.com/pricing](https://99designs.com/pricing)

</comment><comment><USER50> Brilliant! However, they are quite pricey at 500$. I always thought making a custom logo would be expensive, but buying a ready made one could be much cheaper, any thoughts regarding the pricing?

<comment> swagasaurus-rex It goes up by $20 every time somebody purchases a logo. Not really a sustainable business model, but it seems to be working wonders this morning with the increased traffic coming from Hacker News.

<comment><USER51> Pinboard did the same thing in the beginning. Of course, Pinboard increased by a fraction of a cent with each new subscription, not $20.

</comment></comment></comment><comment><USER52> [http://www.brandcrowd.com/](http://www.brandcrowd.com/) has more selection and doesn't increase the price for every logo sold.

</comment><comment><USER53> This reminds me of stylate.com which was selling a logo and domain together for a reasonable price (hundreds instead of thousands). I'm not sure why the service ever shut down.

</comment><comment><USER54> I like it, throwing spaghetti at the wall and seeing what sticks!

</comment><comment><USER55> Cute idea. Note that it was just changed to go up by $20 per logo sold, but that still doesn't really solve the economic problems posed by some of the comments.

<comment><USER56> I'm wondering if it will continue to decrease as demand decreases. If the amount was eventually lowered to go up by something like $5, it might be sustainable for quite a while...

</comment></comment><comment><USER57> That's either a seal playing with a ball or a mermaid.

</comment><comment><USER58> You should make it so that the purchaser can have an option to sell their logo if someone else wants it more than them. Take a cut from the transaction

</comment><comment><USER59> Seems like all the components are in place to do automated domain-name, brand, and logo generation.

</comment><comment><USER60> Can anyone tell me what he used to get the logos to animate when filtered? CSS? (I'm a newb)

<comment><USER61> I suppose it uses Isotope ([http://isotope.metafizzy.co/](http://isotope.metafizzy.co/)), since it's the same author.

</comment></comment><comment><USER62> I was disappointed that this had nothing to do with any kind of Lego Pizza.

</comment><comment><USER63> To be honest, I expected the ability to have a pizza cut into my logo.

</comment><comment><USER64> This is an awesome idea with a very nice execution!

</comment><comment><USER65> Looks at seal logo... Looks at maria db...

</comment><comment><USER66> Just increased to $200, nice!

</comment><comment><USER67> More descriptive headline:

"Logo Pizza: Hot & ready logos for sale"

</comment><comment><USER68> I have a business question.

Has anyone on HN known anyone who actually bought a logo from this particular site?

I think the site is great. I just question the sold logos, but then again I don't understand the buying mentality of most people.

I'm not knocking the site, or logos; just doing research.

<comment><USER69> I saw it in /new this morning. Only one logo had sold. Bought a logo for $80. Saw logo go to sold and price go up. I received the vector assets on the next page. Seems legit. Although probably short lived in its current form. Perhaps with some tweaks could become an ongoing concern.

Not sure what I will use it on. I thought it was well done and I'm sure I'll put it to use at some point.

</comment></comment><comment><USER70> I feel like a lot of these logos are generic enough that you couldn't possibly enforce your exclusive rights to them.

</comment><comment><USER71> wow $500 for some clipart what a deal

</comment><comment><USER72> Does the price increasing also goes for custom logos? I am really interested in a custom logo...but the price increasing thing would really make it less attractive ;-)

<comment><USER29> I'm certain this designer charges $1000+ for custom logo design.

</comment></comment><comment><USER73> They are allowed to use the bower logo?

[http://logo.pizza/img/custom-logos2.png](http://logo.pizza/img/custom- logos2.png)

[https://bower.io/img/bower-logo.svg](https://bower.io/img/bower-logo.svg)

<comment><USER74> He's the creator of the bower logo. It baffles me that you excluded the most obvious reason before ranting.

<comment><USER73> I would hardly call my question ranting. I figured it was possible the author had created the logo, but I didn't know for sure.</comment></comment></comment>


Scientists create quick-charging hybrid supercapacitors - <AUTHOR> http://phys.org/news/2015-04-scientists-quick-charging-hybrid-supercapacitors.html <comment><USER3> This sounds great but eggheads have been claiming they've created such devices for years. The article contains very few real numbers. Does anyone know anything more about these supercaps that may legitimize or discredit this research?

<comment><USER4> Its one thing to research a product, and get it in a demonstrable form. This occurs time and again. Its another thing to have the ownership of the technology in the right hands, such that the technology can then be funded. Its then another thing to get the funding required to actually make the product happen.

Too often, those who would lose the most, are the ones with the biggest presence at each stage of this process. If you look, you'll see that petro- chemical/military-industrial giants have, in their portfolios, sufficient actually working technology to make major changes in the world. Its just not as profitable for them - nor as safe - as weapons manufacture, ramping up existing oil-infrastructure, etc.

Until we start controlling these entities properly - taxing oil and weapons manufacture at levels that make it more viable to let go of these antiquated economic control mechanisms - nothing will change.

That can't change, until you and I change, and stop depending on oil and weapons as a fundamental aspect of our culture. And the way I see it, the only viable way for that to occur is for the grass-roots to keep inventing new and feasible ways to disconnect from the petro-/military- industrial complex. The day we can grow our own batteries in a simple garden fish-tank .. we'll either have almighty peace on earth, or hellfire from above. Either way, keep trying to find that sweet spot.

<comment><USER5> Using taxation for behavior modification is wrong. This is how we've ended up in the mess of taxes we have today. Despite what politicians keep repeating, "good manufacturing jobs" are never coming back, and taxes and excessive regulations are near to the top of the list of reasons behind this. Don't believe me on this one, Steve Jobs himself told this to Obama directly. Just google it.

Taxes should only be used to raise money to support essential government work and worthy, efficient, well-justified, regularly reviewed programs with automatic expiration dates of no more than five years. The latter to make sure we get used to re-evaluate everything and make sure we run government as efficiently as possible.

</comment></comment></comment><comment><USER6> the first comment under the article claims energy density of about 10% of li- ion batteries, so it's not a battery replacement. still quite useful, though.

<comment><USER7> I bet there are several applications where you can charge frequently and the battery is there for the baseline

Hybrid Cars seems to be one, or even purely electrical ones on a combined approach (You have the supercapacitor for fast charges/discharges - <USER2> breaking/acceleration - and the battery for main storage)</comment></comment>


Do we need something other than medium.com? - <AUTHOR> I think world needs a website that allows you to write and read for free, but works like medium.
Medium is awesome because of
It allows us to write efficiently
It allows us to create new publications. (This is the power of it)
It allows us to customize publications and make the page a little bit our-like.
But, it is paid. (Until you use some illegal softwares like browser extensions to bypass)
So, I checked the internet whether there's some alternatives to medium and found this out. https://beebom.com/medium-alternatives/ But, any of this doesn't do the job clean as medium does.
So, Is it the time to create an open-source publications website? Or is there really one?
Happy to discuss>>> <comment><USER2> I'm making [https://epiphany.pub](https://epiphany.pub) , Medium + jupyter.

it supports github like collaboration, (pull request, fork)

it supports latex math,

live coding, in js and python

social publishing, similar to Medium.

<comment><USER3> It looks beautiful :- ) (looking at [https://epiphany.pub/post?refId=2684bc94f9fcb9ffe637ebfbeba2...](https://epiphany.pub/post?refId=2684bc94f9fcb9ffe637ebfbeba2af8c797c6ad9a66181026ee4bd3806b6f211) )

You have any example of a page with comments?

Who is the target audience? (Live coding? Is it mainly for software people?)

Social publishing — how does that work? (which features from Medium do you have in mind?)

Is it ok if I ask, does it have a business model?

Which rich text editor & Markdown editor libraries do you use? I'm thinking about using ProseMirror myself :- )

<comment><USER2> Thank you very much!

> You have any example of a page with comments?

[https://epiphany.pub/post?refId=3e123914a88818452d7f2c24fd8a...](https://epiphany.pub/post?refId=3e123914a88818452d7f2c24fd8ad079ad621a5e94f514cca5598fb9479d5342)

> Who is the target audience? (Live coding? Is it mainly for software people?)

This is a solo side project so far, but I really want to turn it into a startup. I started by scratching my own itch. As a tech blogger, I want a platform like medium, where I can connect with new interesting contents and interesting people, and I can have my work pushed to wider audiences. I also like the expressiveness of live programs, such as those on jupyter notebooks.

My initial targeted audiences would be tech bloggers, who could only show static images, prerecorded videos and embedded github snippets on their old platform. I want Epiphany to grow into a community like dev.to. Then I also want to attract academic content creators.

I'm attending YC startup school now. I badly need feedback on this idea to see if it has potential. I will appreciate if you could provide some feedback.

> Social publishing — how does that work? (which features from Medium do you > have in mind?)

I wrote tech articles on medium that one day I want to turn into a book: [https://medium.com/mlreview/l1-norm-regularization-and- spars...](https://medium.com/mlreview/l1-norm-regularization-and-sparsity- explained-for-dummies-5b0e4be3938a)

on Epiphany, anyone can start a "publish" in one of the two forms, a journal or a book. Then other bloggers could contribute to your journal or book. You can select a group of editors to proof read and approve the submissions.

> Is it ok if I ask, does it have a business model?

My initial focus is a digital textbook marketplace. Imagine professionals from all different places collaborate on a book about a latest technology with demonstrations in runnable programs, like blockchain. And Epiphany will be a market place for those contents. Students will subscribe with a monthly fee, which will distributed to the creators.

> Which rich text editor & Markdown editor libraries do you use? I'm thinking > about using ProseMirror myself :- )

The current version is based on the Monaco editor. But it's more ideal for programs, not so for writing markdown. I'm remaking the markdown editor with ProseMirror now, which should be deployed this week. The new editor supports realtime markdown, inspired by [https://typora.io/](https://typora.io/) . the markdown parser is markdown-it.

</comment></comment></comment><comment><USER4> Don't we have [https://write.as/](https://write.as/) as well?

We really need to get people to be able to type math and code.

Basically, bring back the proliferation of blogs! All the net needs is a standard API (non-disqus) which will allow people to discover and comment.

<comment><USER3> > All the net needs is a standard API (non-disqus) which will allow people to > discover

How can a discovery API work? Please describe :- )

\- What API endpoints are needed and what would they do?

\- How do they help with identifying good blogs?

\- How do they help people discover blog posts _they_ want to read, among all good blog posts?

\- How can cheating, be prevented? (like, pretending one's blog post got 999 999 visits & "upvotes", to boost it's populartiy score)

I'm interested because I'm developing an open source Disqus alternative. (It's called Talkyard Blog Comments. There's also Commmento, also open source under active development.)

<comment><USER4> Well, the ideal API would have JS endpoints, since that's easiest to work with. I envisage a sort of client-side validation system, instead of a central server. Something like dat ([https://dat.foundation](https://dat.foundation)). That would prevent cheating I guess. The idea is to not really aid discovery without having the current blog author endorse it. Either that or there might be a sort of voting system. What they want to read is something I would rather not work on. The discovery process should be for the site, not individual posts I guess. Talkyard is nice, I couldn't find Commento though..

</comment></comment></comment><comment><USER5> You should check at what's happening/the story behind Hacker Noon. I think it's an interesting read, whether you agree or not.

There's certainly a need to make an alternative, but I don't think the problem is easy to solve because it's not just technical. Creating the community is what Medium was able to do (and the "average" dev usually can't, me included), and this new payment model seems to be what's killing it. Time will tell, but finding the right balance doesn't seem a trivial task.

</comment><comment><USER3> > a website that allows you to write and read for free, but works like medium

I'd rephrase: A network of blogs, whose articles are discoverable in the same way as good articles at Medium. Somehow takes into account what people actually stop and read.

But _not_ a single website. It would, I think, sooner or later, go greedy and self destruct. A single point of failure.

(Maybe not noticeable until after many years, when there's an owner shift, and the new owners have different goals.)

> it is paid

Who pays? The blogger, or the readers? How does the money get distributed?

Interesting topic you brought up b.t.w. :- )

</comment><comment><USER6> Anything that helps kill medium is a good thing, IMO.

</comment><comment><USER7> It exists, [https://dev.to](https://dev.to)

<comment><AUTHOR> I'm a fan of dev.to as well as a writer. But, it's totally focused on development related things.

The super power that I see on medium.com is that it allows any topic to be published user-wise or publication-wise.

Dev.to doesn't allow us to create our own publication and make a community for a business which medium.com allows.

I'm totally in love with "publications" on medium which allows us to grow a "brand name".

But, I think reading and writing should be free :)</comment></comment>